8 ms·

Say Hello to X64 Assembly Part 3

134 points by valarauca1 12y ago

schappim 12y ago
I think I just found the perfect use for the Intel Edison (a tiny Atom (x86) + BLE + Wi-Fi module by Intel): https://www.sparkfun.com/products/13024 https://www.sparkfun.com/products/13024
- Narishma 12y ago
  Edison is 32-bit x86.
anjanb 12y ago
is there something equivalent for nasm on the OS X ?
- valarauca1 12y ago
  brew install nasm
- DigitalJack 12y ago
  yes, as someone commented already you can use homebrew. I think xcode might include nasm too, but I'm not sure if that is still true. There are some hello-world examples for 32bit and 64bit with nasm on osx here: https://gist.github.com/desertmonad/36da2e83569bc8b120e0 https://gist.github.com/desertmonad/36da2e83569bc8b120e0
- alecco 12y ago
  Nowadays yasm is quite better and backwards compatible to nasm.
Havoc 12y ago
I'm a little confused - why is ASM still an issue these days? Sure I can understand some in-line ASM for hardcore speed-critical code but beyond that...why bother? Even interpreted langs seem fast enough these days, so compiled should def be fast enough and resorting to ASM should imo be unnecessary. NB the above is a personal view & I'm not a programmer by profession...so if I missed something - no offence intended.
- sliverstorm 12y ago
  It's probably a pet project for fun & learning about the metal.
- ChuckMcM 12y ago
  It is the difference between passion and education. Someone who passionate about technology is really interested in all the bits and crevices, someone who is simply learned about technology classifies knowledge into 'useful' and 'not useful' parts. A common example is 'car people' who go through and re-design the fuel injectors for their car. It isn't "required" but they really like everything about all the pieces. So they persevere to understand it all.
  - bsoares 12y ago
    This is a very well thought statement. I was just thinking this morning how great is to understand low level logic and coding, but when discussing it with a co-worker, it was clear that there was no practical day to day benefit from knowing about the underpinnings of the higher level languages we use. That said, I am able to better overcome technical challenges when they arise due to my curiosity and passion for the details.
  - Havoc 12y ago
    I hear you. Though in the modern world I feel everyone is forced to triage on the useful/not useful front. There is too much info out there and not enough time.
- pjmlp 12y ago
  Someone needs to write bootloaders, OS drivers, compilers, interpreters, image processing algorithms, audio processing filters, ...
- xooxies 12y ago
  It's still a need to know if you work in the reverse engineering, security, vulnerability analysis, etc. realms.
- krylon 12y ago
pjmlp 12y ago
Thankfully the article uses Intel syntax. I had to port a code generation module from Intel syntax to AT&T. What a pain! Gas is so limited compared with what PC macro assemblers are capable of.
- alecco 12y ago
  yasm -p gas?
  - pjmlp 12y ago
    That would mean still using the AT&T syntax. I started coding x86 Assembly back when MS-DOS 3.3 was modern in PC world, so never got to love AT&T syntax. Specially after my porting experiment. I needed to change a compiler backend to depend only on binutils (gas & ld). So the existing NASM code had to ported. NASM macros couldn't be mapped to what Gas offers and I also had some issues getting my head around how to write the addressing modes. I was using a common trick for code generation. Generate bytecodes that are actually Assembler macros. A simple way to get static binaries, even if the performance is not optimal. In the end I gave up and made the backend generate the respective Assembly code directly.
- jwr 12y ago
  I find AT&T syntax to be completely impractical to work with, and I'm surprised people put up with it. But, as a side note, all PC assemblers are crap. They could do so much more. I don't know why I'm expected to handle register allocation, or think about inter-unit dependencies that cause stalls.
  - pjmlp 12y ago
    Personally I wouldn't like to have an Assembler re-arrange my code, specially since the issues you mention can even change between firmware revisions. On the x86, starting with the 486 and Pentium it wasn't possible any longer to fit all variations on the head. At least I can't. The porting I mentioned above was to make a compiler depend only on binutils. Other than that, my last 100% Assembly application was around 1995.
userbinator 12y ago
I think something isn't quite right with int_to_str/print; in int_to_str, each converted char is pushed onto the stack as 8 bytes, and while the total length is calculated correctly in print, the result is that 7 null bytes get written out with each char as well. What you see will depend on how your terminal interprets them, but they will definitely be there if the output is redirected into a file. There's also an extra "add rdx, 0x0" in int_to_str, a puzzling multiplication by 1 in print, and a confusion between the standard input (0) and output (1) fds.

134 points by valarauca1 12y ago

I think I just found the perfect use for the Intel Edison (a tiny Atom (x86) + BLE + Wi-Fi module by Intel): https://www.sparkfun.com/products/13024 https://www.sparkfun.com/products/13024

Narishma 12y ago
Edison is 32-bit x86.

anjanb 12y ago

is there something equivalent for nasm on the OS X ?

valarauca1 12y ago
brew install nasm
DigitalJack 12y ago
yes, as someone commented already you can use homebrew. I think xcode might include nasm too, but I'm not sure if that is still true. There are some hello-world examples for 32bit and 64bit with nasm on osx here: https://gist.github.com/desertmonad/36da2e83569bc8b120e0 https://gist.github.com/desertmonad/36da2e83569bc8b120e0
alecco 12y ago
Nowadays yasm is quite better and backwards compatible to nasm.

Havoc 12y ago

I'm a little confused - why is ASM still an issue these days? Sure I can understand some in-line ASM for hardcore speed-critical code but beyond that...why bother? Even interpreted langs seem fast enough these days, so compiled should def be fast enough and resorting to ASM should imo be unnecessary. NB the above is a personal view & I'm not a programmer by profession...so if I missed something - no offence intended.

sliverstorm 12y ago
It's probably a pet project for fun & learning about the metal.
ChuckMcM 12y ago
It is the difference between passion and education. Someone who passionate about technology is really interested in all the bits and crevices, someone who is simply learned about technology classifies knowledge into 'useful' and 'not useful' parts. A common example is 'car people' who go through and re-design the fuel injectors for their car. It isn't "required" but they really like everything about all the pieces. So they persevere to understand it all.
- bsoares 12y ago
  This is a very well thought statement. I was just thinking this morning how great is to understand low level logic and coding, but when discussing it with a co-worker, it was clear that there was no practical day to day benefit from knowing about the underpinnings of the higher level languages we use. That said, I am able to better overcome technical challenges when they arise due to my curiosity and passion for the details.
- Havoc 12y ago
  I hear you. Though in the modern world I feel everyone is forced to triage on the useful/not useful front. There is too much info out there and not enough time.
pjmlp 12y ago
Someone needs to write bootloaders, OS drivers, compilers, interpreters, image processing algorithms, audio processing filters, ...
xooxies 12y ago
It's still a need to know if you work in the reverse engineering, security, vulnerability analysis, etc. realms.
krylon 12y ago

pjmlp 12y ago

Thankfully the article uses Intel syntax. I had to port a code generation module from Intel syntax to AT&T. What a pain! Gas is so limited compared with what PC macro assemblers are capable of.

alecco 12y ago
yasm -p gas?
- pjmlp 12y ago
  That would mean still using the AT&T syntax. I started coding x86 Assembly back when MS-DOS 3.3 was modern in PC world, so never got to love AT&T syntax. Specially after my porting experiment. I needed to change a compiler backend to depend only on binutils (gas & ld). So the existing NASM code had to ported. NASM macros couldn't be mapped to what Gas offers and I also had some issues getting my head around how to write the addressing modes. I was using a common trick for code generation. Generate bytecodes that are actually Assembler macros. A simple way to get static binaries, even if the performance is not optimal. In the end I gave up and made the backend generate the respective Assembly code directly.
jwr 12y ago
I find AT&T syntax to be completely impractical to work with, and I'm surprised people put up with it. But, as a side note, all PC assemblers are crap. They could do so much more. I don't know why I'm expected to handle register allocation, or think about inter-unit dependencies that cause stalls.
- pjmlp 12y ago
  Personally I wouldn't like to have an Assembler re-arrange my code, specially since the issues you mention can even change between firmware revisions. On the x86, starting with the 486 and Pentium it wasn't possible any longer to fit all variations on the head. At least I can't. The porting I mentioned above was to make a compiler depend only on binutils. Other than that, my last 100% Assembly application was around 1995.

userbinator 12y ago

I think something isn't quite right with int_to_str/print; in int_to_str, each converted char is pushed onto the stack as 8 bytes, and while the total length is calculated correctly in print, the result is that 7 null bytes get written out with each char as well. What you see will depend on how your terminal interprets them, but they will definitely be there if the output is redirected into a file. There's also an extra "add rdx, 0x0" in int_to_str, a puzzling multiplication by 1 in print, and a confusion between the standard input (0) and output (1) fds.