OSDev.org

bubach wrote: Thats not a good point.
It takes like two minutes to memorize the register names for a new platform.

You still don't get any kind of an edge on others. The code is still illegible, since you don't know sh*t about the entire processor. It's like making sure that each verb starts with a #, after which somebody starts talking esparanto to you. You might be able to find the verbs, but it's not like it helps.

Brendan wrote: Hi,

My main problem with AT&T is that memory references can be both confusing and ugly. For example, compare "[eax*5+something]" to "something(%eax, %eax, 4)" - the NASM version looks like algebra while the AT&T looks like a C function. Even if AT&T only supported "(%eax*4+%eax+something)" I'd like it much more.


Cheers,

Brendan

I still can't really get my head arround that part, it just feels so alien being used to Intel Syntax (the rest isn't bad).

srg

well to me it sounds like at&t is a more portable asm but intel is more simplistic :-\

If I'm following correctly, it's basically that the Intel syntax is designed around the Intel processor instruction sets and so is specialised for them, whereas the AT&T syntax can be used for various other processors at the expense of being a bit harder to follow when you're trying to pick it up and not supporting things specific to certain processors.

I personally use the Intel syntax due to that being what my assembler uses and because I'm only developing for Intel processors (well... AMD ones, but it still counts ).

Brendan wrote: For example, compare "[eax*5+something]" to "something(%eax, %eax, 4)" - the NASM version looks like algebra while the AT&T looks like a C function.

Erm... if you want to compare, you should compare statements that do the same... and what are you doing, scaling by 5 in the Intel syntax?

I agree that the AT&T form takes some memorizing, but the section in the manual isn't that complicated:

An Intel syntax indirect memory reference of the form

section:[base + index*scale + disp]

is translated into the AT&T syntax

section:disp(base, index, scale)

where base and index are the optional 32-bit base and index registers, disp is the optional displacement, and scale, taking the values 1, 2, 4, and 8, multiplies index to calculate the address of the operand. If no scale is specified, scale is taken to be 1. section specifies the optional section register for the memory operand, and may override the default section register (see a 80386 manual for section register defaults). Note that section overrides in AT&T syntax must be preceded by a %. If you specify a section override which coincides with the default section register, as does not output any section register override prefixes to assemble the given instruction. Thus, section overrides can be specified to emphasize which section register is used for a given memory operand.

Hi,

Solar wrote:

Brendan wrote: For example, compare "[eax*5+something]" to "something(%eax, %eax, 4)" - the NASM version looks like algebra while the AT&T looks like a C function.

Erm... if you want to compare, you should compare statements that do the same... and what are you doing, scaling by 5 in the Intel syntax?

I was refering to NASM syntax (and probably should have compared it to GAS rather than AT&T in general). NASM will accept "[eax*5+something]" (it's equivelent to "[eax*4+eax+something]") and will also convert things like "[eax*2]" into it's shorter form "[eax+eax]".

I'm not sure about other Intel syntax assemblers - I've never used them (except a86, a long long time ago).


Cheers,

Brendan

Brendan wrote:I was refering to NASM syntax (and probably should have compared it to GAS rather than AT&T in general). NASM will accept "[eax*5+something]" (it's equivelent to "[eax*4+eax+something]")...

No, it's not equivalent! If we assume [tt]something = 0[/tt], the first statement gives you 5, 10, 15, ... while the second (and the GAS tidbit) gives 5, 9, 13, ...!

Edit: Look what happens when you type without major parts of your brain paying attention.

Or rather, the GAS statement will most likely give you an error as GAS only accepts scales of 1, 2, 4, and 8 (as 5 would result in unalligned memory access).

...and will also convert things like "[eax*2]" into it's shorter form "[eax+eax]".

I don't really know what GAS makes of such an optimizable statement in machine code. Have you tested both assemblers for this?

Hi,

Solar wrote:

Brendan wrote:I was refering to NASM syntax (and probably should have compared it to GAS rather than AT&T in general). NASM will accept "[eax*5+something]" (it's equivelent to "[eax*4+eax+something]")...

No, it's not equivalent! If we assume [tt]something = 0[/tt], the first statement gives you 5, 10, 15, ... while the second (and the GAS tidbit) gives 5, 9, 13, ...!

Are you suggesting that "[tt]eax*5[/tt]" isn't equal to "[tt]eax*4 + eax[/tt]", or that "[tt]eax*4 + eax[/tt]" does equal "[tt]eax*4 + 1[/tt]"? Either way I'd be confused...

Solar wrote:Or rather, the GAS statement will most likely give you an error as GAS only accepts scales of 1, 2, 4, and 8 (as 5 would result in unalligned memory access).

Of course - GAS won't handle it, but NASM will except any valid equivelent, for e.g.:

[tt] [eax*9] = [eax*8 + eax]
[eax*5] = [eax*4 + eax]
[eax*3] = [eax*2 + eax]
[eax*2] = [eax*1 + eax][/tt]

I also fail to see what "unaligned memory accesses" has to do with anything - I often use this sort of thing and "LEA" to multiply by a constant (where there is no memory access), at times an unaligned memory access is needed (e.g. 24 bits per pixel video), and it can also be used for reading/writing bytes (e.g. "[tt]mov al,[eax*5+something][/tt]").

Solar wrote:

...and will also convert things like "[eax*2]" into it's shorter form "[eax+eax]".

I don't really know what GAS makes of such an optimizable statement in machine code. Have you tested both assemblers for this?

From "GNU assembler version 2.15.92.0.2" using the code "[tt]lea (,%eax,2),%eax[/tt]", and then using "objdump -d a.out", I get the following:

[tt]Disassembly of section .text:

00000000 <.text>:
0: 8d 04 45 00 00 00 00 lea 0x0(,%eax,2),%eax[/tt]

From "NASM version 0.98.39 compiled on May 25 2005" using the code "[tt]lea eax,[eax*2][/tt]", and then using "ndisasm a", I get the following:

[tt]00000000 66678D0400 lea eax,[eax+eax][/tt]


Cheers,

Brendan

Solar wrote:

Brendan wrote:I was refering to NASM syntax (and probably should have compared it to GAS rather than AT&T in general). NASM will accept "[eax*5+something]" (it's equivelent to "[eax*4+eax+something]")...

No, it's not equivalent! If we assume [tt]something = 0[/tt], the first statement gives you 5, 10, 15, ... while the second (and the GAS tidbit) gives 5, 9, 13, ...!

Or rather, the GAS statement will most likely give you an error as GAS only accepts scales of 1, 2, 4, and 8 (as 5 would result in unalligned memory access).

Yes it is equivalent. EAX will have the same value in both instances and increase each time, so they are damn well equivalent. Even the GAS tidbit, if actually equivalent, MUST give the exact same result, being 0, 5, 10, 15 etc.

...and will also convert things like "[eax*2]" into it's shorter form "[eax+eax]".

I don't really know what GAS makes of such an optimizable statement in machine code. Have you tested both assemblers for this?

Well... it's either in SIB encoding eax + eax or 2*eax+0, for which the first is shorter. Both should choose the first one. The second is, depending on encoding, between 1-4 bytes longer. I expect GAS to take your stuff literally, IE, (0, %eax, 2) to be the longer version and (%eax, %eax, 1) to be the shorter version.

Re: Equivalency of the two statements... ignore me, of course I've been uttering complete BS. Sometimes I type faster than I think, and when I miss the opportunity to think again, stuff like that happens. ::) :-\ :'(

Think fast
type slow

But I daresay neither of us is holy, eh?

beyond infinity wrote: Think fast
type slow

But I daresay neither of us is holy, eh?

If they're correlated as such, I'd better start typing a lot slower

From "GNU assembler version 2.15.92.0.2" using the code "lea (,%eax,2),%eax", and then using "objdump -d a.out", I get the following:

[tt]Disassembly of section .text:

00000000 <.text>:
0: 8d 04 45 00 00 00 00 lea 0x0(,%eax,2),%eax[/tt]

From "NASM version 0.98.39 compiled on May 25 2005" using the code "[tt]lea eax,[eax*2][/tt]", and then using "ndisasm a", I get the following:

[tt]00000000 66678D0400 lea eax,[eax+eax][/tt]


Cheers,

Brendan

You have an address size and opcode size prefix on the NASM-generated instruction (did you assemble for 16 bits)?

Hi,

Guest wrote:

[tt]00000000 66678D0400 lea eax,[eax+eax][/tt]

You have an address size and opcode size prefix on the NASM-generated instruction (did you assemble for 16 bits)?

Yes - if I assembled to 32 bit it'd be 3 bytes instead of 7.


Cheers,

Brendan

Brendan wrote: Yes - if I assembled to 32 bit it'd be 3 bytes instead of 7.

I think you meant "Yes - if I assembled to 32 bit it'd be 3 bytes instead of 5."