[hoke_t]

How does one learn how to do this stuff? Low level programming interests me immensely but I can never find a good resource for how to learn. I know C, C++, Java, Javascript, Python, Objective-C, Swift, but the only reason I have been able to learn these languages and their technologies is because of the resources available. Can anyone point me in the right direction to become acquainted with low-level technologies/understanding?

[brudgers]

When the author describes the Amiga as an understandable system, he's reasonably accurate. Even the lowly Amiga DOS manual documented the Assembly instructions and the in-the-box Microsoft produced Amiga Basic allowed fairly direct access to the hardware.

These pale though in comparison to the two Amiga Rom Kernel Manuals and the Amiga Hardware Manual. [1] These were sold in the computer section of the shopping mall bookstore back in the day, and even today provide a detailed explanation of a multi-tasking operating system and simple graphics programming.

[Edit] Part of the reason why people continue to hack on it is because it is practical. The this-is-how-to-turn-it-on-and-use-the-mouse Introduction to the Amiga 500, it had schematics in the back; pinouts for all the ports; and pinouts and block diagrams for the important chips.

[1] https://computerarchive.org/files/comp/books/amiga/Amiga_Har...

[dsr_]

Start with an assembly language designed for teaching: MMIX.

http://mmix.cs.hm.edu/index.html

There are books, courses, homework, and lots of free resources -- in particular, emulators.

Then find a project that interests you, and learn what you need to do for that. 68000 assembly? Forth? Graphics on a VGA card emulated in a VM running MS-DOS? All of these things are entirely do-able.

Or find a project that is already in development and contribute to it. The important bit is your own motivation.

[jeffreyrogers]

I don't know if MMIX is that useful to learn honestly. It's RISC like, which is good, but the register saving convention is a bit weird and its not that similar to things that are already exist. Most assembly languages are pretty easy to learn (even x86), they just seem hard because they're so low level.

[sn9]

If you can program in C at the level of K&R, your first step is to work through Computer Systems: A Programmer's Perspective [0].

Coursera has a course called the Hardware Software Interface [1] which covers the same material if you want lectures and forums and the other benefits of a MOOC.

[0] http://csapp.cs.cmu.edu/

[1] https://www.coursera.org/course/hwswinterface

[Gargoyle]

One fun (if not particularly practical) path is to learn the Atari 2600 video game platform.

Documentation is readily available, along with source code to a number of classic games. There are several emulators and even a small community of people turning out new games for the platform.

The 2600 was/is quirky, and of course it's ancient history, but it does provide a path to learning some basics that still apply today. Most importantly, it's fun.

Start here as a resource - http://www.atariage.com/2600/programming/

[coupdejarnac]

Read the book Bebop to the Boolean Boogie. It's a fun, well explained introduction to computer engineering fundamentals. Also, the Art of Electeonics is a great resource.

[13of40]

If you use windows, I think Microsoft still has a DDK somewhere that contains the final version of MASM, their macro assembler. I assume there's a gnu option out there too. Get one of those and look on google for a hello world tutorial. Write some user mode stuff. Then try a boot sector / boot loader. Use a VM for testing and development. Get a book like The Ultimate PC Hardware Guide and start writing a hardware abstraction layer for your new OS...

[wolfgke]

> If you use windows, I think Microsoft still has a DDK somewhere that contains the final version of MASM, their macro assembler.

Even simpler: Install Visual Studio 2015 Community (the current version) and run the "VS 2015 x86 Native Tools Command Prompt" or "VS 2015 x64 Native Tools Command Prompt" (under Windows 7 in the Start menu under "Visual Studio 2015" -> "Visual Studio Tools" -> "Windows Desktop Command Prompts").

Now simply run

  ml

or

  ml64

(depending on the prompt that you opened). Voila - these are the current x86 or x64 versions (14.00.x) of the Microsoft Macro Assembler.

[groovy2shoes]

Neat! I've also had pretty good luck with nasm on several platforms, including Windows, Linux, OS X, and DOS. fasm also looks pretty neat, but I haven't done much with it aside from a few toys for Menuet OS. And then there's yasm, which I haven't used, but must be fairly popular given its inclusion in several distros.

There's GNU as (gas), which I've used quite a bit, but wouldn't really recommend because it uses strange "AT&T" syntax rather than the syntax you'll find in the Intel manuals. gas is also meant more as part of the GCC pipeline than as a standalone assembler, so even though it can function as one, it's not necessarily nice as one.

I've been meaning to play around with the LLVM assembly language. It looks neat, with the bonus of being reasonably portable, but I haven't yet found the time.

HLA (High Level Assembly) by Randall Hyde seems like an interesting way to slowly lower yourself into assembly language programming, but that's not how I cut my teeth, so I can't speak to its effectiveness.

[Annatar]

> There's GNU as (gas), which I've used quite a bit, but wouldn't really recommend because it uses strange "AT&T" syntax

All AT & T syntax is, is

move src, dst

rather than intel's

move into dst, src

as far as I know, intel is the only company which did that, and to me, it is intuitive to move something somewhere, rather than to somewhere move something.

[wolfgke]

There are much more differences (sources: http://www.imada.sdu.dk/Courses/DM18/Litteratur/IntelnATT.ht..., http://stackoverflow.com/a/9951916/497193)

In Intel syntax instructions are not suffixed. In AT&T there is a suffix (q, d, w, b) depending on the operand size. For example (assuming 32 bit register) mov (Intel) gets movl (AT&T). Also the argument order is changed. Constants have to be prefixed by $. Hexadecimal values are prefixed with 0x instead of suffixed with h. Registers are prefixed with %. With this we already have

  mov     eax,1
  mov     ebx,0ffh

vs.

  movl    $1,%eax
  movl    $0xff,%ebx

But also the notation for accessing memory is different: For encoding the SIB (Scaled Index Byte) (+ disp[lacement], if desired), Intel uses [base+disp+index * scale], while AT&T uses disp(%base, %index, scale). Thus we have

  mov edx, [ecx]
  mov eax, [ebp-4]
  mov eax, [ebp-4+edx*4]
  lea eax, [eax*4+8]
  lea eax, [eax*2+eax]

vs.

  movl (%ecx), %edx
  movl -4(%ebp), %eax
  movl -4(%ebp, %edx, 4), %eax
  leal 8(,%eax,4), %eax
  leal (%eax,%eax,2), %eax

Edit: On the other hand, when the size of the operand can't be concluded from the instruction, in Intel syntax you have to add 'BYTE PTR', 'WORD PTR', 'DWORD PTR' or 'QWORD PTR' to disambiguate the situation. For example

  mov [ebx], 2

is not unique, so in Intel's syntax you have to write respectively

  mov BYTE PTR [ebx], 2
  mov WORD PTR [ebx], 2
  mov DWORD PTR [ebx], 2

[Annatar]

Coming from MOS 6502 / 6510 / Motorola MC680## background,

movl -4(%ebp), %eax

is intuitive to me. On the Motorola MC68000 family, it would have been

move.l -4(sp), a0

so I can hit the ground running with AT & T syntax.

The first time I saw

mov eax, [ebp-4]

I wanted to take a hammer and beat the idiotic IBM PC tin-bucket into oblivion. Did the square brackets have any special meaning? Who the hell knows! What do they mean?!? Completely unintuitive.

With AT & T syntax, I can even hit the ground running reading SPARC assembler:

mov 5, %g31

moves five to global register 31. Perfectly logical and intuitive, and I didn't even have to know anything about SPARC assembler.

Then there is the deadbeefh instead of $deadbeef or 0xdeadbeef syntax. Everybody else either used $deadbeef or 0xdeadbeef, but not intel, oh no! intel just had to be different. Irritating to no end. Again, taking a hammer to the PC bucket was a temptation...

Only intel could come up with something which does not relate to anything.

[pjmlp]

Intel's syntax is most common, not the AT&T one.

You only see it everywhere nowadays thanks to the rise of GNU/Linux and other open source UNIXes.

If you translate mov into =, the syntax makes much more sense than AT&T.

I mean

mov dst, src

is similar to

dst = src

[wolfgke]

> Intel's syntax is most common, not the AT&T one.

I'd be a little bit more careful with such a statement: Under Windows (and formerly DOS) Intel syntax is the common one, while under GNU/Linux and OSX the AT&T one is used.

> If you translate mov into =, the syntax makes much more sense than AT&T.

Though I prefer the Intel syntax, I'd be careful with "makes sense" here: According to http://stackoverflow.com/a/4119217/497193 people who grew up with MIPS seem to prefer the AT&T syntax since it is much more similar to MIPS assembler.

[Annatar]

> Intel's syntax is most common, not the AT&T one.

No, intel is an exception, not the norm. Amstrad, Atari, Commodore 64, Amiga, Sun (both Motorola and (Ultra)SPARC) all use "move src, dst", $ or 0x... only intel diverges from the norm.

[Narishma]

I think most popular assemblers use dst,src not just Intel. I know z80, 68k, PPC and ARM do at least.

[Annatar]

PPC and Motorola 680## series, as well as (Ultra)SPARC all use src, dst.

[phodo]

I would also say understand the basics of digital logic design.

[e12e]

Others have given hints for how to get started on Windows. On Linux, assembly for x86_64 is actually rather pleasant, and it looks like a project that was announced on hn a good while back has been fleshed out quite a bit:

"Say hello to x64 Assembly, part 1" https://news.ycombinator.com/item?id=8245581

https://github.com/0xAX/asm

(Incidentally, I did a fork of the early stuff just to see what it would look like with gas syntax - the standard for gcc. Now that there's more code in the parent repository, maybe it's time to revisit): https://github.com/e12e/asm/tree/gas-syntax/hello

Another quick intro to 64-bit assembly: https://cs.nyu.edu/courses/fall11/CSCI-GA.2130-001/x64-intro...

A book (I haven't read), but looks ok, from a quick glance at the examples: http://rayseyfarth.com/asm/

http://www.amazon.com/Introduction-Bit-Assembly-Programming-...

For a long time, the best resources were (arguably still are) for 32 bit x86 assembly -- but IMNHO it's rather unpleasant in terms of segmented memory, limited registers, and the C call abi is also a bit "clumsy" if you want to work in assembly as much as possible (again, this has to do with limited registers). That said, Randall Hyde has some great resources on 32 bit assembly:

http://www.plantation-productions.com/Webster/

An older resource, for 32bit assembly: http://www.drpaulcarter.com/pcasm/ I have an old print-out of this on my bookshelf - it's a pretty straight-forward introduction to how one might go about to combine C and assembly. It'd be great to see an updated version for 64bit though.

An operating system in assembler. 32bit version GPL, the 64bit version is as far as I can gather under a more restrictive, source-available license:

http://menuetos.net/

Then there's BareMetal Os (I couldn't find any License.txt): https://github.com/ReturnInfinity/BareMetal-OS

There's also a wiki on OS dev: http://wiki.osdev.org/X86-64

I would recommend going through the first tutorial listed above, to get a feel for things. Assembly can be a lot of fun - but I think you'll in general will have a hard time doing better than gcc/clang if speed is your goal. Still useful for stuff like boot loaders and such. If you want to play with OS/boot-loader development, it is easier now than ever before thanks to emulators like Qemu: http://wiki.qemu.org/Main_Page