Programming with Ones and Zeros(hanshq.net)
hanshq.net
Programming with Ones and Zeros
http://www.hanshq.net/ones-and-zeros.html
5 comments
ah I found it! http://www.ousob.com/ng/iapx86/index.php "norton guide" is apparently the magic word for it
Computers up until the early 80s had "keys" to flip bits directly in memory, from the hobbyist Altair 8800 and its clones ( see the close up panel image at the bottom of http://www.vintage-computer.com/altair8800.shtml ), the DEC PDP series ( http://home.earthlink.net/~n1be/pdp11/PDP11.html ), Data General Nova...
And back in ye old times, the legendary Seymour Cray cold-booted the CDC 1604 for the first time directly from the keys on the front panel before any OS or software existed to run on the machine.
And back in ye old times, the legendary Seymour Cray cold-booted the CDC 1604 for the first time directly from the keys on the front panel before any OS or software existed to run on the machine.
If I run the fib example on a Linux 64bit install and forget the -m32 flag (both GCC and Clang) it will return 0 for each call (the earlier return 42 example worked thou), add the flag and it works. Curious to know what change caused that?
It's because of the difference in how arguments are passed to functions in 32-bit vs 64-bit mode.
In the System V AMD64 ABI, the first integer argument to a function is passed in the rdi register.
The fib function however, being written for 32-bit mode, is expecting the argument on the stack, and loads it from esp+4, so it gets a garbage value.
The value on the top of the stack is the return address, which is probably somewhere around 0x0000000000400000 (the default entry point). Loading from esp+4 gets the high bits which are all zeros, so that's what goes into %ecx.
If you build the program as a position-independent executable (gcc -fpic -pie), it will get loaded at a random address and it will print a different value.
In the System V AMD64 ABI, the first integer argument to a function is passed in the rdi register.
The fib function however, being written for 32-bit mode, is expecting the argument on the stack, and loads it from esp+4, so it gets a garbage value.
The value on the top of the stack is the return address, which is probably somewhere around 0x0000000000400000 (the default entry point). Loading from esp+4 gets the high bits which are all zeros, so that's what goes into %ecx.
If you build the program as a position-independent executable (gcc -fpic -pie), it will get loaded at a random address and it will print a different value.
As soon as I read that, it was an o of course moment, especially with the time the orginal author spent talking about the ABI. Cheers
I have been personally diving into compilers lately, and the amount of research which obviously went into this is pretty high (there are at least 3-4 independent resources which are required to find the right opcodes and ordering and...).
Well done and presented!
Well done and presented!
Very cool! Nice descriptions and presentation (and the movie reference at the end is great).
I look forward to going through this in finer detail.
I look forward to going through this in finer detail.
I can't remember the exact resource I used for the opcodes and their encodings, but it was the best resource ever. It included cycle information, a description of what the opcode did, and what flags and registers it affected. I haven't been able to find that resource though in a couple years at least. It followed some common template that was used for a number of other topics as well (including DOS interrupts and some obscure programming language)
One of the other fun things I did was craft some self-modifying code... although I once had a bug in it and that was almost impossible to debug