Re: My view on this "Is blah an assembler"

From: C (blackmarlin_at_asean-mail.com)
Date: 08/16/04 

Date: 16 Aug 2004 11:34:52 -0700

"Beth" <BethStone21@hotmail.NOSPICEDHAM.com> wrote in message news:<WOQTc.1198$Xu.828@newsfe4-gui.ntli.net>...

[snip]

> You're actually criticising "type casting"...legitimately because it _is_
> an often horrid thing to have to include in a syntax...HLA merely, like
> every other assembly language, picks up the nastiness of this...it's not at
> all unique to HLA...other assemblers start to look horrid when you start to
> get into "mov [ stringstr ptr ebx ].memberA, byte ptr 34" style of syntax
> too...

Hmm, in Luxasm that would be (assuming ebx is typed as 'stringstr') ...

  mov ebx->memberA:1, 34

Shorter, tidier, but still ugly.

[snip]

> I'm not sure that C (the person, not the language) picked up my suggestion
> of this for LuxAsm syntax or not...but I was thinking that we see lots of
> assemblers use things like the following: "stos operand" versus "stosb",
> "stosw", "stosd"...or "push dword" versus "pushd"...or, of course, somewhat
> univeral is "jmp" (tool to decide size with "jump optimisation"), "jmp
> near", "jmp far" (explicit sizes, used regardless of "jump optimisation"),
> etc...

Well, I did not pick up on your suggestion, but I have had similar
ideas myself -- have a look in the /document/ directory on the Luxasm
CVS -- there are some files noting ideas for a logically consistant
syntax, which could be used as an alternate to the default Intel
style syntax, possibally by changing namespaces. So you would have
something like...

  add ax, bx -> add.w a, b
  mov ax, bx -> mov.w a, b
  mov cs, dx -> mov.sw c, d
  movzx eax, bl -> mov.db a, b
  movsb -> mov.ab
  paddb mm0, mm1 -> add.xb r0, r1
  paddb xmm0, xmm1 -> add.vb r0, r1

[snip]

> I think C worked out a ":2" / ":4" convention or something...nice - perfect
> for the "constant" issue - but it's a bit "non-standard" and
> "non-Intel-syntax"...putting "b", "w" and "d" as a suffix on the mnemonic
> is a scheme already being used for other instructions in the "Intel" style
> already...extending that to, basically, the rest of the instruction set
> (except for those instructions where such a thing doesn't make
> sense...wouldn't need it for "movq", for example ;)...

The idea for the ':2' / ':4' convention is an alternate to the
Intel syntax 'word ptr' / 'dword ptr' which is generally agreed
as both ugly, wasteful to type and adding little to the read-
ability of the code. However, as you said, this syntax is
unsuitable for mneumonics (mainly because it would cause a
parsing conflict with the label definition syntax, though, as
Luxasm is not a context free grammer, this problem my be solvable).
But using a straight 'b', 'w' or 'd' is also not possable as
Intel have already stimied this by having different instructions
with those names -- though using '.b', '.w' or '.d' can work.
A better solution, I believe, is to redesign the instruction set
from scratch (much like Herbert has done), but keep that set as
a seperate mode, so a more familiar Intel set is available by default.

[snip]

> Oh, note, C, Frank, that one thing to consider about LuxAsm and "data
> typing" is that if we do have it (which C appears to want a loose scheme of
> and I'd be completely behind that idea :)...

For anyone who does not know, the syntax I am using is a system of
'type recording' which does little more than noting the label of
the type -- infact that label may be anything, as the assembler
makes virtually no use of that label. The 'type recording' comes
into play with the macro library, allowing powerful macros to be
built which make use of the extra information which may be
recorded with each label. For instance you could write a 'mov'
macro which checks the recorded type of a register matches the
recorded type of a variable. (Luxasm also provides a '->'
operator which does a text substitution based on the recorded
type, the user may of course elect not to use this operation.)

There is one other use for 'type recording', that is you can do...

#equate dword, 4 ; set dword as number 4
#label my_label : dword ; define label as current pos
#d 0xdeadbeef ; define initial value of label
mov [ my_label ], 42 ; move a new value to label

Which would use the equate to determine the size of 'my_label'
as no other type has been provided, but this would only work
when the type label has been equated to some value.

C
2004-08-16