x86 assembly doesn’t have to be scary (2018)

For example, the codegen for some C++ that was discussed a few days ago [1]

[0] https://godbolt.org/

[1] https://godbolt.org/z/cfYKqajMd

This website also has another article which explains how a C++ code can be understood in terms of C code. https://www.avabodh.com/cxxin/cxx.html

I also wrote another article which explain how C++ code can be understood in terms of C code: https://www.avabodh.com/cxxin/cxx.html

but I started in my first job dissassembling 68000, very easy to work with

Then I read some of the Intel stuff. OMG.

That's maybe a little spun. The separated address/data registers (there are two kinds of registers, and memory operations need to use one from each to combine to a final address) played hell with optimizer strategies for years.

In fact 68k compiler output was significantly sub-par pretty much throughout its lifetime. The "cobbled-together mess" had (post-386 anyway) a significantly more orthogonal instruction set and was just plain easier to optimize, even for humans.

A lot of the performance gains over the last couple decades haven't come from machine code changes, but rather from various forms of pipelining and superscaling. Rather than run one instruction at a time, CPUs run hundreds of instructions at a time. The complexity of doing that is that many instructions often depend on the result of instructions immediately before them, and so the CPU needs a lot of shortcut paths internally to keep from stalling out.

You could get to Ghz speeds with a custom ASIC, and you could use base RISC-V as a modern, not crufty ISA. It still won't be anywhere near as fast as a high end x86 or ARM CPU, though, unless it's similarly pipelined and superscaled.

Underneath the covers, however, the underlying hardware complexity is an inherent property of modern performance. For example, branch prediction.

It's confusing as a beginner to encounter the "di" and "dx" registers, and to understand why the 8-bit version of "r13" is "r13b" but the 8-bit version of "rdx" is either "dh" or "dl".

It would be certainly a smaller tutorial, but historical perspective might be valuable for understanding cruft layers of design decisions that made sense decades ago and addressed problems that have ceased to exist.

https://github.com/torvalds/linux/blob/master/arch/x86/entry... (subject to change, see your specific kernel source)

I think more fun is doing assembly on a µC without OS with some interesting peripherals and many MCUs have an instruction set inspired by x86.

Maybe this is just a case of having learned and written 32-bit x86 assembler for years in my youth, but I strongly prefer it to x86_64.

It's basically "Writing an Operating System from Scratch for Dummies".

I actually wrote my own graphical x86 OS starting from the code in there.

Generally, they do lots of inlining, and then once you inline you can get some more optimizations in, rinse and repeat. Ends up pretty optimal. (This is C++, can't speak for other languages.)

We work on very perf-sensitive code and we never drop down to assembly. For hot loops, we usually inspect the generated assembly and if it's not great, it's fairly easy to "nudge" the compiler towards the better-performing solutions by tweaking the source code. Also some manual unrolling might be needed to better saturate the vector processing cores of modern CPUs.

And when you're working with signed integers, you still have to do stuff like a >> 1 instead of a / 2 :)

Here's an example that looks like magic at first glance where the compiler converts manual bit twiddling code to a popcnt instruction (with the right compiler setting), but do the bit counting any other way, and the whole thing falls apart:

https://www.godbolt.org/z/KaM6jWjdx

It is a bit less obvious, in fact.

Motorola never looked at 68k CPU's as a serious business, more like toying around with the CPU's all the time or looking at them as a less important spin-off of the main business. Their main sources of income were defence contracts (e.g. specialised or hardened microchips), microcontrollers, DSP's (which were pretty cool, by the way, – all implementing the Harvard architecture), memory chips (I think), radios and the field radio equipment and later mobiles.

They carried largely the same attitude to 88k RISC and PowerPC CPU lines (albeit trying to compete more seriously for a while), but ultimately failing to catch up and leading to the eventual PowerPC demise. After that failure, they spun off anything CPU, DSP and microcontroller related into Freescale, and the rest is now history.

There was a recent thread [1] optimizing some very primitive trig functions.

I recently watched a djb interview where he talked about the importance of fully utilizing available hardware [2 at 5:15]. That can be a good starting point, although at work its usually easier to just consume more resources than to use what you've got more efficiently.

[1] https://news.ycombinator.com/item?id=28209097

[2] https://www.youtube.com/watch?v=1svxNxG6hHc

  ; To build:
  ;   nasm -fobj hello.asm
  ;   alink -oPE -subsys con hello -entry main

  bits 32

  import imp_CreateFileW      kernel32.dll    CreateFileW
  import imp_WriteConsoleW    kernel32.dll    WriteConsoleW
  import imp_CloseHandle      kernel32.dll    CloseHandle
  import imp_ExitProcess      kernel32.dll    ExitProcess
  import imp_GetLastError     kernel32.dll    GetLastError

  extern imp_CreateFileW
  extern imp_WriteConsoleW
  extern imp_CloseHandle
  extern imp_ExitProcess
  extern imp_GetLastError

  %define CreateFile      [imp_CreateFileW]
  %define WriteConsole    [imp_WriteConsoleW]
  %define CloseHandle     [imp_CloseHandle]
  %define ExitProcess     [imp_ExitProcess]
  %define GetLastError    [imp_GetLastError]

  global main

  section .text use32
    
  main:

    push dword 0 ; hTemplateFile = 0
    push dword 0 ; dwFlagsAndAttributes = 0
    push dword 3 ; dwCreationDisposition = OPEN_EXISTING
    push dword 0 ; lpSecurityAttributes = NULL
    push dword 2 ; dwShareMode = FILE_SHARE_WRITE
    push dword 0x40000000 ; dwDesiredAccess = GENERIC_WRITE
    push dword filename 
    call CreateFile
    mov [handle], eax
    
    push dword 0 ; lpReserved = NULL
    push dword nChars ; lpNumberOfCharsWritten
    push dword 16; nNumberOfCharsToWrite
    push dword hello ; lpBuffer
    push eax ; hFile
    call WriteConsole

    mov eax, [handle]
    push eax
    call CloseHandle
    
    push dword 0
    call ExitProcess
    
  err:

    call GetLastError
    push eax
    call ExitProcess

  section .data use32

  filename:   db      __utf16__('CONOUT$'), 0, 0
  hello:      db      __utf16__('Hello Console!'), 13, 0, 10, 0, 0, 0
  handle:     resd    1
  nChars:     resd    1

What browser are you using?