x64 is so much nicer than x86 --- ip-relative addressing, more (mercifully, numbered) registers, and (best of all) a register-based calling convention.
Introduction to x64 Assembly
41–50 of 78 posts
Re: Introduction to x64 Assembly
#42Earlier quoted context omitted.
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.
For those not familiar with the history of England, the tome of Western literature (and the genre of satire), or soft-boiled eggs, I've gotten some confused looks when trying to explain this origin. Plus, it doesn't really add anything at all to the understand of endianness in the computer hardware sense.
Re: Introduction to x64 Assembly
#43One thing to watch out for people learning IA-32(e) asm is that there are two syntaxes: Intel and AT&T. Intel, unsurprisingly, uses Intel syntax. GCC, however, mostly uses AT&T syntax (for historical reasons, and that's all I'll say).
You can find a reference to the GAS syntax at http://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax. I wouldn't use it for a reference to any of the instructions (for that grab the linked Intel manuals in this article), but that should get you familiar with the differences if you decide you'd like to write GAS.
You do have the option to set GAS to use Intel syntax with a directive, but if you're modifying legacy code or just want to be consistent with a lot of other GAS code, you may want to use AT&T.
Re: Introduction to x64 Assembly
#44That 3D "cross" graphic (Figure 1, "General Architecture") might be the worst illustration of a programmer's model for a CPU I've ever seen. I'm sure it makes sense after you've read the accompanying paragraph a sufficient number of times (once didn't cut it, for me), but not so sure it helps in that understanding. I guess it's a funny hint that the x86's architecture is complex, when a figure that's just trying to d…
Re: Introduction to x64 Assembly
#45"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.
Re: Introduction to x64 Assembly
#46Earlier quoted context omitted.
I haven't tried it; but how about Yasm? http://yasm.tortall.net/ https://github.com/yasm/yasm/
Thanks. Looks like it requires Visual Studio in Windows. Was hoping to find a simple "ASM" -> "Windows EXE" tool. I might try WinASM again at home.
Going assembly straight to .exe sounds convenient for learning, but isn't very useful in practice, so not many assemblers implement it. The most common use case for assembly language these days is to write a few functions that get called from some higher level language, and that's done by having both the compiler(s) and assembler spit out object files that are linked together by the linker. I suspect WinASM is just hiding the steps, and it'd be easy enough to create a Makefile that did the same.
The closest thing to assembly->exe that I know of is the "flat" binary output from Yasm. It's similar to really old DOS .com executables. I'm not sure they'll run on modern Windows, though.
Re: Introduction to x64 Assembly
#47I learned by working through the software developers' manuals. Many years ago, they used to ship them as physical copies. Nowadays they just send CDs. PDF copies: http://www.intel.com/content/www/us/en/processors/architectu...
Re: Introduction to x64 Assembly
#48Earlier 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…
Just like how I was taught the difference between "". Our teacher drew the rest of Pac-Man around the "" so that we'd think of "" like the mouth of Pac-Man. It wants to eat the larger number. But that was back around 1983 when Pac-Man was all the rage (when I was drawing Pac-Man eating ghosts on my folders).
Re: Introduction to x64 Assembly
#49Earlier 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.
Re: Introduction to x64 Assembly
#50Is there a good Windows assembler that doesn't get flagged by anti-virus software? UPDATE: I just ran across JWAsm and haven't encountered any problems so far. http://sourceforge.net/projects/jwasm/
Intro at: http://msdn.microsoft.com/en-us/magazine/cc301368.aspx
Ecma spec at: http://www.ecma-international.org/publications/standards/Ecm...