Re: Windela

"Herbert Kleebauer" <klee@xxxxxxxxx> wrote in message
news:48ADCE8A.E3652C2@xxxxxxxxxxxx
Intel/AMD define the processor architecture, including the
instruction set and opcode map. But the symbolic representation
of an instruction is not defined by the processor architecture
(and therefore not by Intel/AMD)

I disagree. (I've said that to you previously...)

but by the author of the assembler.

I know. (You've stated that previously...)

This symbolic representation should be as logic as possible (which
therefore excludes the use of the symbolic representation used by
Intel/AMD in the processor manuals).

And, now we're onto your favorite topic: syntax for HK's Windela. :-)

Now, a selector has a size of 16 bit. So if you have to specify
a register which holds the selector, it's "logical" to use the name
of a 16 bit register (lsl eax, bx) and not a 32 bit register name
(lsl eax, ebx).

Okay, lets work through your example for data which isn't a selector. Now,
an ASCII char has a size of 7 bit. So if you have to specify a register
which holds the ASCII char, it's "logical" to use the name of a 7 bit
register ... Hmm, that doesn't seem to work. Perhaps, we're looking at the
problem in reverse: trying to fit data of a specific size to a standard
register size and then when the instruction doesn't support that size
register attempting to forcing the instruction to use that size. Shouldn't
we be looking at the problem the other way around: seeing what sizes of
register the instruction supports and then decide on one that will also fit
the data? What I'm trying to say is that when it comes to selectors
everyone is trying to match the register to the data instead of trying to
match the data to the register. This seems to be the opposite of what one
normally does.

But even more logical it would be, to put the size to the
instruction and not to the register;

I have no real issues with this. (I've mentioned this previously... too.)

ldsl.l r3,r0

The things I like to see here (most of which I've mentioned previously...
also):

1) standard Intel instruction names
2) a character between the instruction name and sizes to make recognizing
the instruction easy
3) same register order as Intel, not Motorola...
4) standard Intel register names *OR* some method other than r# so I know
which r# corresponds to eax,ax,al... etc.

E.g., (changing instruction from lds to adc...)

adc.ll eax,ebx
adc.ww ax,bx
adc.bb al,bl
adc.bb ah,bh
adc.bb ah,al

But, since there is some redundancy and you don't like redundancy, if "ra"
is eax,ax,al:

adc.ll ra,rb
adc.ww ra,rb
adc.bb ra,rb (b for lower byte)
adc.hh ra,rb (h for upper byte)
adc.hb ra,ra

I think that is fairly clean. I can still tell that "a" is for eax,ax,al,ah
and "b" is for ebx,bx,bl,bh without having to have continuously read a full
register list showing r0 is eax,ax,al and r1 is edx,dx,dl, etc. I also
don't have to switch to m# from r# for upper half 16-bit register as it's
specified by the "h" register size. The instruction matches what I know for
instruction memonics. The sizes aren't appended onto the instruction making
the instruction easily recognizable. And, I can map to and from Intel
registers without a list.

It's the same as with the shift instruction. You use

"shl eax,cl" and not "shl eax,ecx" because cl better
fits to the 5 bit shift count than ecx.

CL is hardcoded. It's not part of the bits used to encode/decode the
instruction.

But also here
the logical way would be:

lsl.l r2,r0

Since CL is hardcoded, you only need to specify CL to distinguish it from
other forms: imm8, or hardcoded ",1" etc. You don't need to specify the
size:

lsl.l eax,cl
lsl.w ax,cl

lsl.l ra,rc
lsl.w ra,rc

But, it might serve as a useful reminder if the byte register is specified:

lsl.lb ra,rc
lsl.wb ra,rc


Rod Pemberton

.

Relevant Pages