Re: Intel illogical syntax...

"Herbert Kleebauer" <klee@xxxxxxxxx> wrote in message
news:48AF30EC.67051CB5@xxxxxxxxxxxx
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?

As said previously, it's a matter of convenience to use a style that matches
what is used in Intel/AMD manuals. Having a different style increases the
work for the programmer if one uses the Intel/AMD manuals regularly.

No. The topic is: Intel syntax is illogical.

Acceptable.

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.

So you support decoding LAR/LSL to a 32-bit register according to the
current Intel manuals for 32-bit mode... Thanks. ;-)

The 32 bit x86
architecture has 8 (7 without the sp) general purpose registers.

9 GP with both (e)ip and (e)sp... ;-)

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

If all the "eax" registers (etc.) were numbered identically, but you know
that eax, ax, and al are numbered 0 while ah which is also part of eax is
numbered 4 (etc.). In other words, numbering them 0 to 7 works for 32-bit,
16-bit, but fails for 8-bit. You can't change their "illogical" or
historical decision...

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.

True. But, the register name represents what is used, and the seven values
are encoded/decoded (i.e., understood by the cpu logic as certain registers)
as 8-bit and 32-bit by default for 32-mode or 8-bit and 16-bit by default
for 16-bit mode.

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.

So, you're saying 16-bit 86's and 286's didn't exist... (?) The registers
existed as 16-bit at one point in time. Their names weren't "virtual" then,
but real names since 32-bit registers didn't exist yet. Although, they may
be "virtual" (using your description) on a 32-bit/64-bit machine today. So,
saying they don't make sense doesn't make sense.

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

No such claim. Again, I think that's argued in reverse of historical
perspective given the 8086 and 80286...

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

Reduces my workload. I can find an instruction which does what I need to do
in their manuals and use it. If I'm using GAS (GNU AS), and I've found an
instruction in the manual, sometimes GAS has a different name for it. It
can take some time to figure out which GAS instruction is the correct one.

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

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

Oh, sorry, it looks to me like you wrote (spaces added): lds l . l
Well, you did! I.e., I "see" a dot '.' between the two "size specifiers"...

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

True, but each corresponds to a register appropriate for that mode and
instruction:

0 eax ax al
1 ecx cx cl
2 edx dx dl
3 ebx bx bl
4 esp sp ah
5 ebp bp ch
6 esi si dh
7 edi di bh

32-bit and 8-bit are valid in 32-bit mode without any overrides, and 16-bit
and 8-bit are valid in 16-ibt mode without any overrides.

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?

Haven't used it yet... But, yes numerical naming like r8, r8d, r8w, r8b, is
a problem, IMO... for humans. The confusion from quite a few threads I've
already seen exhibited by people reading rax and r8 (sound similar...) etc.,
as the same register confirms this in my mind. Maybe people from a Motorola
68K background don't find the numbering awkward...

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.

What operator?
(instruction)(.)(size)(size)(<sp>)(operand)(,)(operand)

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

What about operations between two differently sized operands...?
(e.g.,movzx, movsx, arithmetic instructions w/imm8 to full register...)

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.

Because, I'm familiar with Intel/AMD syntax... I understand that certain
registers have certain "abilities": smaller instruction size, hardcoded to
use that register, etc. and I need to easily know which is which. I
understand that by default, the registers are 8-bit/16-bit or 8-bit/32-bit.
I also understand that the upper 8-bit registers (ah,bh,ch,dh) aren't
numbered with a value that represents the register that they are a part of.

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.

Are you saying you're representation is more logical than Intel's? Your
register numbers don't correspond to the bits used to encode/decode the
register number... ;-) Take a look (register number in parens, "upper"
8-bit registers with "parent"):

r0(0) r0(0) m0(4) r0(0)
r2(1) r2(1) m2(5) r2(1)
r1(2) r1(2) m1(6) r1(2)
r3(3) r3(3) m3(7) r3(3)
r7(4) r7(4)
r4(5) r4(5)
r5(6) r5(6)
r6(7) r6(7)

In Intel register notation:

eax(0) ax(0) ah(4) al(0)
ecx(1) cx(1) ch(5) cl(1)
edx(2) dx(2) dh(6) dl(2)
ebx(3) bx(3) bh(7) bl(3)
esp(4) sp(4)
ebp(5) bp(5)
esi(6) si(6)
edi(7) di(7)

In the notation I presented above:

ra .1(0) .w(0) .h(4) .b(0)
rc .1(1) .w(1) .h(5) .b(1)
rd .1(2) .w(2) .h(6) .b(2)
rb .1(3) .w(3) .h(7) .b(3)
sp .1(4) .w(4)
bp .1(5) .w(5)
si .1(6) .w(6)
di .1(7) .w(7)

Single register name, with a bunch of size modifiers... and you can tell the
"ra" corresponds to the "eax" group due to the "a", etc.

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


I think they wouldn't have implemented both... (ambiguity) Or, they'd take
one away... (redundancy)


Rod Pemberton

.

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: 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)
  • Designing my own architecture to be simulated in software - need help with the ISA
    ... I'm reserving the HO byte of the word for the instruction type, ... The register operands are half-bytes in length, ... defining an instruction set. ... sub - store the difference of two registers in a register ...
    (comp.arch)