Looking for learning materials for low-level programming languages

Question

I wish to study bare-metal programming for writing drivers and firmware and other operating system stuff, but I cannot for the life of me find any good learning materials for learning those languages. The gems I found for asm were few and far-between, and I cannot find anything on programming in straight hexadecimal. When I say straight hexadecimal I mean the kind of stuff that you'd find in the firmware section of the Linux kernel. This is was the closest I've gotten with my two months of searching: http://www.omnimaga.org/index.php?topic=6272.0 and this tutorial has too little information and was not followed up on to my knowledge.

TL;DR: I wanna learn hex. Where?

Note: I do realize what a difficult, monumental, and masochistic endeavour this will be. You don't have to tell me. I'll fare better on this self-flogging journey with learning materials than I will without.

Second note: I already know a lot about the internal workings of an operating system, kernel and I/O devices, if but abstractly, as well as how memory works and is allocated, and I already have a basic grasp of flat assembly.

The inner geek in me is restless!

There's a reason you don't write machine code - it's highly specific to individual processors. A quick google turned up: http://www.programmersheaven.com/mb/pharabee/344751/344751/how-to-write-a-assembler/ — Sam Dufel, Feb 08 '13 at 23:50
Depending on the direction you want to go I recommend either the osdev wiki or a tutorial on Linux kernel module interfaces. — Dougvj, Feb 09 '13 at 00:13

score 3 · Answer 1 · answered Feb 08 '13 at 23:49

3

Well, if you want to know how to program x86 processors in hexadecimal, all the information you need is in the Intel Software Developer Manuals. Most specifically you want all the info in volume 2. Chapter 2 covers the general instruction encoding and chapters 3 and 4 cover all the specific instructions.

answered Feb 08 '13 at 23:49

Chris Dodd

119,907
13
134
226

Omg thank you! I needed a good opcode reference – Dylan LaCoursiere Feb 09 '13 at 17:04

score 3 · Answer 2 · answered Feb 09 '13 at 00:26

If this disappoints your restless inner geek I'm sorry, but I think you are misinterpreting both the purpose of these firmware blobs as well as their creation path.

The firmware files present in Linux are chunks of stuff that needs to be uploaded to an interface adapter and will be executed by whatever intelligence is present on that adapter. Quite often these are highly specific ASICs and there are several potential reasons why the firmware needs to be uploaded as a binary blob : the ASICs producer doesn't want to divulge the exact inner workings of the chip, or isn't willing (or able) to share the sourcecode or the necessary tools with the users.

However, this doesn't mean that the firmware blob is the result of some übergeek furiously punching in hex code all day long, these files most often start their lives in toolchains that support a workflow that is quite comparable to regular programming: source code is produced in some higher language (but not necessarily one of the common ones like C or C++) and that code gets compiled to a binary file - the firmware file.

So, although this may be a neat trick to wow people at the first barbecue of the summer, the practical applications of "programming hex" are close to nonexistent, if you really want to go deep, assembly is more than deep enough. Thanks to improvements in compiler technology nowadays even most microcontroller developments aren't done in assembly anymore, so your best bet might be to dig up old DOS software, you'll find lots of applications written in assembly code there.

score 1 · Answer 3 · answered Feb 09 '13 at 00:34

Go lookup processor Op-Codes for the CPU you are studying. These codes are the rosetta stone that converts assembly pnumonics to "hex" values and is a good deal of what an assembler does. Then despair ever using it. I have a strong background in assembly and still use it occasionally day to day when debugging release builds. But straight opcode reading and writing is not all that useful anymore. The last time I did that sort of thing was writing self modifying code back on the Color Gameboy for efficient palette fills during HBlanks. As I said, very, very speciailized and not useful in modern times with pesky caches getting in the way.

score 0 · Answer 4 · answered Feb 08 '13 at 23:52

Have you tried this doc, titled "Linux Assembly Tutorial"

http://docs.cs.up.ac.za/programming/asm/derick_tut/

It has, for example, a "hello world" which reads (copied verbatim):

section .data
    hello:     db 'Hello world!',10    ; 'Hello world!' plus a linefeed character
    helloLen:  equ $-hello             ; Length of the 'Hello world!' string
                                   ; (I'll explain soon)

section .text
    global _start

_start:
    mov eax,4            ; The system call for write (sys_write)
    mov ebx,1            ; File descriptor 1 - standard output
    mov ecx,hello        ; Put the offset of hello in ecx
    mov edx,helloLen     ; helloLen is a constant, so we don't need to say
                     ;  mov edx,[helloLen] to get it's actual value
    int 80h              ; Call the kernel

    mov eax,1            ; The system call for exit (sys_exit)
    mov ebx,0            ; Exit with return code of 0 (no error)
    int 80h

(The google query I got this from was: https://www.google.co.uk/search?q=how+to+write+drivers&oq=how+to+write+drivers )

Looking for learning materials for low-level programming languages

4 Answers4