Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly

Rod Pemberton wrote:
"Herbert Kleebauer" <klee@xxxxxxxxx> wrote in message

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...)

To say it with your own words:

Where's your proof? ......... said so?

Viktor: "Lucian is dead."
Singe: "According to whom?"


but by the author of the assembler.

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

You know? And you still disagree? Then maybe any further discussion
will not make much sense.


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. :-)

No. The topic is: Intel syntax is illogical. I very rarely posted
Windela/Lindela code lately, I mostly use NASM code (see my source
code posting from yesterday). Sadly the NASM macro system isn't powerful
enough to really "make" it a logical syntax.


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.

Therefore mostly the _name_ of a byte register is used to access an ascii
value stored in a register (sub al,'0'). But sometimes it is convenient to
use the _name_ of a 32 bit register (e.g. when using a look up table
mov al,[esi+eax] ). But this only makes sense, when the 32 bit register
really contains a 7 bit ascii value, which means the upper three bytes
are zero. To speak from a selector in a 32 bit register also only makes
sense when the upper word is zero.

But you still mix up the name of a register with the register itself
(which is a result of the illogical Intel syntax). The 32 bit x86
architecture has 8 (7 without the sp) general purpose registers.
Which one is used is mostly coded in a three bit field in the instruction
(which can hold values 0 - 7 and therefore it would be logical to call
them register0 - register7). There are not eight 32 bit (eax, edx, ..) and
eight 16 bit (ax, dx, ..) and eight 8 bit registers (ak, dl, ...) but only
this eight 32 bit registers. You use the name of a (not existing) 16 bit
register in the symbolic representation of an instruction to make it
obvious that only the lower half of the 32 bit register is used in the
operation ( add ax,dx ). It would be much more logical to use the names
of the real existing registers eax,edx (or even much better r0,r1) and
use an operator which makes clear, that only the lower halve of the
registers are used ( add.w r1,r0 ).

But if you prefer the virtual register names to specify which part
of the register is used, then you have to use "lsl eax, bx" to make
clear that only the lower halve of the ebx register is used in this
instruction.



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.

Sorry, that doesn't make any sense. The virtual names of the non existing
16 and 8 bit registers are introduced by the Intel syntax only to denote
the part of the existing 32 bit register which is used by the instruction.
If "lsl eax, bx" only uses the lower halve of ebx but you still want to use
the name ebx instead of bx, then you claim that it wasn't a good idea
to introduce the virtual 16 and 8 bit register names at all (which I
fully support).


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

Why? What makes the names Intel has chosen so preferable? But don't
say: "because they are from Intel".

2) a character between the instruction name and sizes to make recognizing
the instruction easy

There is a character between name and size: the '.'

3) same register order as Intel, not Motorola...

Intel uses the a three bit field for register numbering (0-7),
the cpu only understands this number an not eax,ebx,ecx,...


4) standard Intel register names *OR* some method other than r# so I know
which r# corresponds to eax,ax,al... etc.

Why should the eight physically existing register correspond to ascii
strings like "eax", "ebx", ... . Forget about this strings, the don't
make any sense. Which names do you use for the additional registers
in 64 bit mode?



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

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

That's even more illogical than the Intel way. You still specify
the size of the operands (.ww, .ll) but append it to the operator.
You should specify the size of the operation (.w, .l) and not of the
operands (there are only 32 bit registers, no 8 or 16 bit registers).


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

Why do you always insist that something like eax, ax, al exist at all.
All that exist are flip-flops (32 of them forming a register) and this
registers are addressed by a three bit number 000 - 111. It doesn't make
any sense to associate r0 with eax, r0 is register 0 but "eax" is an ascii
string without any meaning.


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.

Like r0 is hard coded in :
24 01 and.b #1,r0

But there is also:

80 e0 01 and.b #1,r0
80 e2 01 and.b #1,r1
80 e1 01 and.b #1,r2

So, if Intel had made a second shift instruction where the
shift count register is free selectable, then you would use

shl eax,cl for the implicit count register ecx, but

shl eax,eax
shl eac,edx
shl eax,ecx for the free selectable count register?

If not, why would you like to use "lsl eax, ebx"?
.

Relevant Pages

  • Re: [patch 5/8] Immediate Values - x86 Optimization (update)
    ... Any register accessible as rl. ... Immediate Values - x86 Optimization ... Intel states that unpredictable general ... * protection faults may result if a synchronizing instruction (iret, int, ...
    (Linux-Kernel)
  • Re: How does this make you feel?
    ... >> XOR instruction that applies to a 1M range of VM; ... > register gives a memory address, and the second gives a byte-count (up ... in a CPU that has one execution pathway. ... instruction set and the specifics of its addressing modes; ...
    (comp.arch)
  • Re: Designing my own architecture to be simulated in software - need help with the ISA
    ... > memory address range is limited to 16 bits. ... > I'm reserving the HO byte of the word for the instruction type, ... The register operands are half-bytes in length, ... > sub - store the difference of two registers in a register ...
    (comp.arch)
  • Re: Intel illogical syntax...
    ... of an instruction is not defined by the processor architecture ... what is used in Intel/AMD manuals. ... when the 32 bit register ... current Intel manuals for 32-bit mode... ...
    (alt.lang.asm)
  • Re: How does this make you feel?
    ... > instruction was added that allowed you to, for instance, extract a column ... >> + Maybe C and UNIX distorted CPU design, ... > supporting interrupts efficiently was a design goal for the transputer. ... behaviour of a conventionally conceieved register. ...
    (comp.arch)