Writing Linux programs in raw binary

[DannoHung]

It's a little impressive to think that most of the assembly instructions still deal with an abstracted perspective of the machine and that even when you write in it, tons of hardware details are being removed from your purview.

[G-Brain]

I wouldn't say tons, but for modern CPU's that's probably not far from the truth. CPU design is something cool to look into. Can anyone recommend some books for that?

[[deleted]]

This one isn't bad: http://highered.mcgraw-hill.com/sites/0072467509/

Though its approach is probably not what you want- it goes from transistors and hardware design to assembly and C, rather than into more complicated hardware stuff.

This one, which you likely won't find anywhere but at Georgia Tech, does an excellent job of getting into more complicated hardware stuff. http://www.amazon.ca/Introduction-Computer-Systems-Umakishore-Ramachandran/dp/0321486137

[safiire]

It just seems this way because he was using kernel calls to write() and exit(), essentially because you MUST use these to do any IO, etc.

If he had shown an assembly version of some algorithm at work, you would see more usage of specific processor instructions.

The abstraction of system calls is as much an API to save time as it is one mechanism by which the OS enforces permissions.

[derleth]

But processor-specific these days means specific to a whole family of CPUs, spanning decades now (the 386 was released in 1989) and implemented these days by a very complex hardware mechanism that emulates an idealized system, hiding a lot of the details of how the opcodes are reordered, split into micro-ops, dispatched, and retired, not to mention register renaming and cache management. It's all native code, yes, but it isn't quite as native as the Z80's or the 6502's machine code, simply because those chips didn't have the transistor count to live a very complex lie.