Live data from Hacker News

Introduction to x64 Assembly

software.intel.com

31–40 of 78 posts

Re: Introduction to x64 Assembly

#31
post #19

For those of you that went through Z80, 6502, 68000, x86 macro assemblers like myself, it is just me or does the AT&T syntax just suck? I recently had to convert some code from Intel syntax with NASM macros to GAS with AT&T syntax, and boy what a pain.

I agree that indexing looks way better in Intel ("[ebx+3]") than in AT&T syntax ("2(%ebx)").

However, for me, AT&T's "mov X Y" for "move X to Y" feels better for me than Intel's "mov Y X" for "move Y from X" (who says that?). If they wanted to things in reverse, they should have named the instruction differently, for example as "load Y X" for "load Y from X" (as in "LDA #0xFF" from the 6502)

As for movl instead of mov, I like the 68K version (MOVE.L) better.

Re: Introduction to x64 Assembly

#32
post #28

"Intel stores bytes "little endian," meaning lower significant bytes are stored in lower memory addresses." I would like to meet the person that doesn't know what endianness is, but can still understand that explanation.

It's even worse trying to explain Gulliver's Travels (and the origin of Endianness) to engineers that do know it in the data-storage sense.

Please try. I've no idea what you're talking about.

Re: Introduction to x64 Assembly

#33
post #19

For those of you that went through Z80, 6502, 68000, x86 macro assemblers like myself, it is just me or does the AT&T syntax just suck? I recently had to convert some code from Intel syntax with NASM macros to GAS with AT&T syntax, and boy what a pain.

Not only that, sometimes the instruction names between AT&T/Intel are totally different! http://blog.reverberate.org/2009/07/giving-up-on-at-style-as...

Since all of the official docs use Intel syntax, I think that using AT&T syntax is a mistake.

Re: Introduction to x64 Assembly

#34
post #28

"Intel stores bytes "little endian," meaning lower significant bytes are stored in lower memory addresses." I would like to meet the person that doesn't know what endianness is, but can still understand that explanation.

It's even worse trying to explain Gulliver's Travels (and the origin of Endianness) to engineers that do know it in the data-storage sense.

Speaking of which I think this is one of my fav papers to read from an historical computing pov:

ON HOLY WARS AND A PLEA FOR PEACE - Danny Cohen 1 April 1980 http://www.ietf.org/rfc/ien/ien137.txt

Re: Introduction to x64 Assembly

#35
post #31
post #19

For those of you that went through Z80, 6502, 68000, x86 macro assemblers like myself, it is just me or does the AT&T syntax just suck? I recently had to convert some code from Intel syntax with NASM macros to GAS with AT&T syntax, and boy what a pain.

I agree that indexing looks way better in Intel ("[ebx+3]") than in AT&T syntax ("2(%ebx)"). However, for me, AT&T's "mov X Y" for "move X to Y" feels better for me than Intel's "mov Y X" for "move Y from X" (who says that?). If they wanted to things in reverse, they should have named the instruction differently, for example as "load Y X" for "load Y from X" (as in "LDA #0xFF" from the 6502) As for movl instead of mo…

I always read

mov x, y

with coma being a synonym for equals, like mov x = y, hence it feels more natural to me.

But the biggest issues are address modes, specially the more complex ones and the macros seem very light weight in features when compared to the Intel world.

Re: Introduction to x64 Assembly

#36
post #35
post #31

Earlier quoted context omitted.

I agree that indexing looks way better in Intel ("[ebx+3]") than in AT&T syntax ("2(%ebx)"). However, for me, AT&T's "mov X Y" for "move X to Y" feels better for me than Intel's "mov Y X" for "move Y from X" (who says that?). If they wanted to things in reverse, they should have named the instruction differently, for example as "load Y X" for "load Y from X" (as in "LDA #0xFF" from the 6502) As for movl instead of mo…

I always read mov x, y with coma being a synonym for equals, like mov x = y, hence it feels more natural to me. But the biggest issues are address modes, specially the more complex ones and the macros seem very light weight in features when compared to the Intel world.

I love this comment. It shows how powerful the right metaphor can be in understanding something, which is something we obsess over at Dev Bootcamp when teaching students. It also shows how tiny affordances (http://en.wikipedia.org/wiki/Affordance) make us "think" specific thoughts. I mean, it's called "mov" so something must be moving, which means there must be a subject, object, and possibly an indirect object, right?

This is what Piaget meant when he talked about "schemata." (http://en.wikipedia.org/wiki/Jean_Piaget#Schemata) So, thank you for the new schema. :)

This particular one had never occurred to me and makes it way easier to internalize.

Sorry for gushing -- few things get me more excited than a new way to explain something. :)

Re: Introduction to x64 Assembly

#39
post #36
post #35

Earlier quoted context omitted.

I always read mov x, y with coma being a synonym for equals, like mov x = y, hence it feels more natural to me. But the biggest issues are address modes, specially the more complex ones and the macros seem very light weight in features when compared to the Intel world.

I love this comment. It shows how powerful the right metaphor can be in understanding something, which is something we obsess over at Dev Bootcamp when teaching students. It also shows how tiny affordances ( http://en.wikipedia.org/wiki/Affordance ) make us "think" specific thoughts. I mean, it's called "mov" so something must be moving, which means there must be a subject, object, and possibly an indirect object, ri…

No problem! I enjoyed reading your post. :)
Post reply on HN