X86 assembly doesn’t have to be scary
blog.benjojo.co.uk
blog.benjojo.co.uk
I was talking to a couple of guys about what I had been doing on my C=64, and when I mentioned the assembly stuff I was writing, one of them said, "How can you possibly write anything with only three registers?!" (just the accumulator and x/y registers). I was wondering what the big deal was since that was the only architecture I had known at that point. Every game and utility I had were only using three registers, so it was already proven to me that three were "enough".
It's funny how you can just adapt and work with whatever is available, and that becomes your norm. Especially when you don't even realize there are other options out there.
Those were the days!
AFAIK you can even go down to 1 register, which is how stack machines work. You might even say it’s 0 registers because it’s not something you can directly access.
A true stack machine does not have any registers, so that would be 0.
Wikipedia has a section on accumulator machines: https://en.wikipedia.org/wiki/Accumulator_(computing)#Accumu...
Assuming Wikipedia's article on the PDP-8 is correct, the PDP-8 had just two public registers: the program counter, and the general-purpose 'accumulator' register.
When I switched to the PC I had great hopes but outright hated it after a short while. All this restrictions on the registers were confusing. The segment modell even more. And good graphics required programming the VGA cards bitplane modes [1] which still makes me dizzy when I think about it. Wished I had an Amiga.
Programming the 6510 and VIC and SID was so smooth in comparison.
[1] In these modes the bits making up a single pixel where not in the same place. To manipulate a single pixel you had to manipulate several bits in different places of the RAM without affecting the adjacent bits in the respective words. Crazy stuff.
Edit: found some info on DCTV: https://retrocomputing.stackexchange.com/questions/2201/how-...
Another example of this, also quite relevant to the article, is the 64K address space of a 16-bit segment; to anyone who is used to HLLs, 64-bit address spaces, and gigabytes of RAM, it seems impossibly small. Even more so when you take a modern C++ compiler with all its default settings and produce a 72KB(!) "Hello World" binary.
One of the things you quickly realise when you work with Asm is that it's not impossibly small; everything is os just horribly bloated --- piles of abstractions upon abstractions, using gargantuan statically-linked library functions of which a tiny fraction of the bytes is actually executed, etc. Try writing a nontrivial utility in 16-bit realmode Asm, where a "Hello world" is around a dozen bytes, and you'll find that 64KB is actually quite a lot already. In particular, look at the 256b and below DOS categories in the demoscene:
http://www.pouet.net/prodlist.php?type%5B%5D=32b&type%5B%5D=...
Those effects were accomplished using fewer bytes of machine instructions than the text of this post, which is already over 1KB. Really makes you think.
Smart linking is related to GC. Not all the conditional and indirect edges in the control flow graph can be skipped by the linker's graph traversal, so you usually end up with lots and lots of unused code. And then there's all the sledgehammers being used on peanuts, just because they're there, like xpath to retrieve config values.
> Hello world in real mode is leveraging a bunch of code and data from the BIOS
Not necessarily, you can avoid the BIOS calls by just copying the string directly to video memory:
mov ax, 0xB800
mov es, ax
xor di, di
mov ah, 0x07
mov si, hello
;; Load character, if zero, jump to end otherwise store
;; character and color in video memory
@@: lodsb
test al, al
jz @f
stosw
jmp @b
;; Halt and wait for interrupt
@@: hlt
jmp @b
hello: db 'Hello, World!', 00h
By contrast, the Prime minis had a Multics architecture with virtual memory (no overlay swapping!), something like 8MB of memory, a 32MB disk drive (16MB fixed, 16MB removable cartridge) and could support 2 vector displays on 1 computer. Happy days!
So yeah, for us oldsters (I'm 58), modern software often seems very bloated.
Different times, I know.
https://github.com/linker3000/Historic-code-PC-Pascal-and-AS...
Granted, I had a little experience with assembler on a C=64, but, I learned _that_ in a similar way.
That's the exact opposite mindset of someone trying to "not scare newbies away."
Newbies like me are more frustrated by thinking there's no path from introductory material to something useful or realistic. Something that's more immediately friendly would be a simplified virtual machine with no or trivial peripheral hardware, like Redcode in Core War:
http://vyznev.net/corewar/guide.html
The death of education is "So What?": "OK, I've learned to play Core War and I know enough to write a warrior that can occasionally beat other warriors written by beginners. So far, so good... so what? I want to program computers in assembly, not play games using assembly programs, so where's the path from where I am now to where I want to be?"
In this case, the pathway from VM opcodes to native opcodes is hardware interface and, while the IBM PC has some funky hardware, it's heartening to know that your code could, in principle and barring emulation errors, run unmodified on real hardware and do something. Not something useful, but you can get to useful. You can ramp up to it, now that you have the pathway in front of you. It might be a long pathway, but it's there.
This might sound odd, but as someone who's done some assembly programming under Linux, it usually isn't different enough from C to be worth the effort. Even if you eschew libc, the kernel APIs are still fairly high-level and, more to the point, there are no new concepts relative to C: You have pointers and pointer arithmetic, you have fixed-size buffers, you have ints and doubles, and the rest is just syntax.
The exception is doing something like a really tight high-performance kernel using SIMD opcodes, which necessarily involves learning a lot about the specific SIMD hardware and data organization to optimize cache use and other details C can't express.
"Sshtalk: An SSH-based chat made in assembler" : https://news.ycombinator.com/item?id=15829206
The library comes with a lot, but network stuff and Unicode support to name a few:
And surely the whole spectre issue could be lessened if we could be less reliant on CPUs having to guess what to keep in cache, which code paths are most likely, etc?
i think thats a potentially very fruitful approach, but would it have helped the spectre situation in any way?
oh, what you're suggesting in an analog for compiler driven speculation? that may have helped, and is also probably worth thinking about
Presumably a compiler could put cache-lookups and/or cache-waits in non-predictably (perhaps choosing to do so when it suspects a cache-miss anyway).
No matter how good your compiler I'll put my money on using hardware to solve Spectre.
In the future I'd expect caches to gain some kind of exclusive tagging or set-aside a per-core reorder area. Fetches will have to go there until the instruction that performed the fetch is retired successfully, then the entry can be made visible. Other threads or cores won't observe any changes to cache state based on speculative execution. It will be complicated, cost some transistors, and have a minor but measurable performance impact.
The perf impact being having to fetch the same memory address multiple times, possibly all the way from RAM, because the instruction that fetched it before you hasn't retired yet. I don't know what impact that will have on cache traffic. If we're all very lucky, it won't be possible to use L3/L2 as side channels and we can ignore them (we probably aren't that lucky).
https://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_w...
Speculation is part of out of order execution, which is logic to execute code passages when their inputs are ready, as opposed to strictly in program order, while maintaining the program visible effects of executing in program order. It works the same in ARM, MIPS etc. Not doing OOO execution roughly halves CPU throughput on your average code. AFAIK OOO without speculation is possible, but loses maybe half of its efficacy.
Actual experts may want to correct my numbers.
Fire up anything electron based, and you are looking at scripts being JITed inside a "VM", sitting on top of an OS that abstract away the hardware, sitting on top of hardware that is pretending to be something from the 80s/90s.
Electrons are arguably at the very base of the whole pyramid (I know, I know :). But then again, there's these pieces of Si pretending to be transistors, etc...
Well, the fact that we were able to abstract it out into an ISA, and still make progress would indicate that it isn't holding us back!
>And surely the whole spectre issue could be lessened if we could be less reliant on CPUs having to guess what to keep in cache, which code paths are most likely, etc?
Why would consumers purchase CPUs that performed worse? The only reason to use branch prediction is because it works and is a huge benefit.
Just because something works doesn't mean it works well. Imagine if x86-64 ditched the variety of non-32/64-bit modes. Would x86 be able to better compete with ARM in power consumption?
In what way? Do you mean instruction decoding? There is very little separation between x86 and ARM on that. x86 is optimized like crazy for the common instructions.
https://en.wikipedia.org/wiki/CPU_cache#Micro-operation_(%CE...
You could probably change the ISA in various ways to save power, or make other uarch or arch changes - but cutting out say the 16-bit modes isn't really one of them.
I've got no idea (obviously) but it seems that maintaining compatibility with legacy hardware shouldn't be all that cheap. If it is, kudos to Intel.
These backwards compatibility modes don't need to be super fast (after all, current chips are perhaps 1000x the speed of the old 16-bit chips), so they don't need to get a ton of gates thrown at them: they just need to work.
If there were no backwards compatibility concerns, I'm sure Intel and AMD could like to get rid of this stuff: not so much because it uses a lot of space, but just because the design and validation effort to make sure these old ISAs keep working is probably considerable.
It's the same kind of situation with all the old effectively obsolete instructions: supporting them takes minimal space, especially when they are allowed to be slow. The encoding space they take up is more of a problem - but that can't be changed now...
Newer/Simpler architectures should be easier to validate.
Sure, is there any CPU feature that this does not apply to?
>I wouldn't want to see it removed but I would like to see better documentation and a more transparent interface onto it, so that those rare programs that do need precise control over it (e.g. security code) can have it.
Its hard to parse what your exact request is here. Branch predictors on various Intel/AMD/etc CPUs work slightly differently from each other, and so even if you had access to the design documents, you would have to write programs specific to each CPU instead of targeting x86/x86-64. Not to mention that microcode updates could alter the implementation. Or do you want to just disable it? But then there are other places where bugs can hide. DMA Controller bugs, side channel attacks on caches, or basic DRAM attacks like Row Hammer,etc. Letting external programmers access CPU internals is only going to open another HUGE can of worms.
Sure, though hopefully that's something a compiler could do. What I'd like is to be able to write a compiler that could understand the difference between as-fast-as-possible code (most code) and constant-time code, and build the latter correctly.
> But then there are other places where bugs can hide. DMA Controller bugs, side channel attacks on caches, or basic DRAM attacks like Row Hammer,etc. Letting external programmers access CPU internals is only going to open another HUGE can of worms.
There are other holes, sure. That's not a reason not to fix the biggest hole. We'll fix the smaller holes in turn.
If you want your compiled code to rely on the internal design of the CPU then its going to be tightly coupled to one particular CPU. CPU Upgrade -> code no longer works. Oh you ran the software on your laptop which has Core i5 instead of Core i7 -> Code no longer works. Oh your S/W Vendor went out of business and you purchased a new machine with a different CPU -> No working code for you.
>There are other holes, sure. That's not a reason not to fix the biggest hole.
OK, please propose a solution then. Or are we merely arguing over hypotheticals and lamenting the fact that stuff isn't secure? If so, yeah, stuff isn't as secure as any of us would like it to be! That doesn't get us anywhere though.
Indeed. Better that than CPU Upgrade -> silently leak your private keys, which is what we currently get.
> OK, please propose a solution then.
I've been proposing a solution this whole thread: publish enough information about exact CPU behaviour to allow a (specialised) compiler to produce reliably constant-time code, even if only for a single CPU model at a time.
But when you compare high-end cores, you always see the same picture, regardless of ISA. Large surface area (~1/3 of the core) used for insn fetch/decode/schedule; they look all the same, whether it's POWERn or the latest Sandy-Bridge/Haswell rehash... people claim that other ISAs would be a lot easier/faster/more efficient to decode, but that doesn't seem to be true in practice. It seems to me that any difference that might be there gets dwarfed by the sheer complexity of OoOE and speculative execution.
What we do know is outside some niches (like DSPs, where VLIW reigns king) static techniques essentially do not work for application code, because it's impossible to predict statically.
What is LRB?
Interesting, why is VLIW is so predominant in DPS chips?
Thanks, that's what I was missing - the access patterns of signal processing is what makes VLIW a good fit.
Is there any other use case where VLIW architectures are prevalent or are DSPs the primary use case?
No, because what the CPUs have is the advantage of being able to have specialized circuits with the new answers in each clock, every instruction in every pipelne stage and so fast adaptation to the use in run time.
x86 decode to micro-ops is a trivial amount of die. It is constant (not completely true but true enough for all useful purposes) while transistor count has gone through many doublings. In some cases x86 is a slight win, as it can function as a form of instruction compression, slightly reducing i-cache pressure.
There may be architectural limitations (like strong store ordering) that are relevant but in practice it hasn't made a huge difference.
I did go there, briefly, about ten years ago. It was wicked fun. But all in all, I may have written maybe 20 or 30 instructions of assembly in total. I did try to rewrite a few small, heavily-used functions from our code base in assembly only to discover that the code I came up with was practically identical to what the compiler emitted. At that point I figured that the people who told me that "you can't beat the compiler" were probably right and called it a day[0]. Alas, I never had the hardcore performance requirements that would make go back there. But it was fun to get a taste of it.
[0] At the same time, I was kind of proud that I did not get beat by the compiler. Then again, those functions were fairly trivial.
On that subject...my understanding [0] is:
These days, the best bet for beating the compiler is to use vendor intrinsics (for SIMD, encryption, bit-twiddling, etc). Shaving an instruction off the inner loop might give you a few percent; using SIMD lets you operate on 256 or 512 bits per instruction instead of 8, 16, 32, or 64. You might be able to show your inner loop is memory-bound (and thus prove further improvements have to come from algorithmic improvements / better cache locality, rather than continuing to fiddle with instructions).
The compiler automatically uses SIMD sometimes, but it can't do so reliably:
* The transformations require things the compiler isn't allowed to do, like increasing alignment of key variables or altering the larger algorithm.
* code that might run on older processor revisions needs multiple implementations selected at runtime. I think gcc has some magic extension ("target_clones"?) to do this relatively easily; otherwise you might need to write your own logic to decide which function pointer to use.
Note that each "vendor intrinsic" matches one assembly instruction, and it's valuable to understand assembly while writing them, but the actual code you check in can end in .cc (C++) or .rs (Rust) or whatever. Doing so means it can be inlined into functions written in the higher-level language, you don't have to encode knowledge about the platform's calling convention into your code, etc.
[0] Not from personal experience. Corrections welcome.
Automatic compiler use of SIMD is rarely that great unless you're in a nice big loop doing nice regular things. I've pretty much never seen it on the stuff I do.
Using intrinsics gets you 95% of the way there. I reach for asm only when I absolutely have to. It is a huge PITA. My irritation at the "bro, just write a .s file" people peaks when I'm trying to write a 200LOC function with 10 different variants based on (say) pipeline depth and unroll width. Yeah, because I'd like to spend the next year doing register allocation by hand.
The compiler is really good at doing routine stuff, and when I hand-edit the asm to do things that better fit my idea of regalloc and scheduling I usually make things worse. Where the compiler falls down is instruction selection and stuff that borders on algorithm design.
For example, I built a shift-or string matcher in SIMD where a first-stage was OK to have false positives (positives in shift-or are represented by zeros in the bit vector). I was able to get a big performance boost by tolerating these false positives when shifting SIMD bits and bringing in some zeros, but no compiler is going to know that a few false positives are OK in that circumstance.
IMO the best way to work is with intrinsics, a tiny bit of embedded asm for things that you can't get intrinsics for (I had to resort to gcc asm blocks to make a cmov happen) and close inspection of your object file (at least on the hotspots) to ensure that the code you're getting is what you think you're getting. It's possible to make minor screwups and suddenly see dozens of extra instructions pushing everything in and out of memory for no good reason.
The other place you can beat the compiler is by doing deeper/wider pipelining of branch free code. This is a dark art. Often going branch free is 10-20% worse than branchy when you have 1 iteration happening at a time but it will scale better when you are going lots of stuff at once - if you have (say) 12 different copies of your loop body happening in one iteration, and there's a mildly unpredictable branch per loop body, the branch miss on one iteration stops all the others from progressing too!
I occasionally blog on these things at branchfree.org and have some more low-level stuff brewing shortly.
Well, I would not count that as "beating" the compiler so much, but as "using it", "helping it", or something like that. ;-)
Anyway, when I still wrote C code for a living, we were using the OpenWatcom compiler, and as far as I could figure out at the time, it made no effort whatsoever to support SIMD, and the only way to use them was to drop to assembly. (OpenWatcom's support for inline assembly and even inline binary code was very nice, though.)
During my programming socialization, assembly was always characterized as this terrible thing they did back in the 1960s, so I was reluctant to even try to begin with. Secondly, I had read quite a bit about how nowadays, compilers were so good, it was not worth the effort.
My initial motivation to even give assembly a try was not performance, but accessing CPU-specific features (RDTSC).
Higher level languages let you skip most of the 'menial' work of laying out the code, so your brain power gets spent a pretty different way. I like each. Obviously some languages are better suited to certain tasks.
I don't have a point; I'm just sharing what sprang to mind when I read your comment.
I will say that for something like C, having some experience with assembly makes it a lot easier to get a feel for pointers, the stack. I genuinely think everybody should try it at least once; it's just enjoyable talking almost-directly to the machine.
Beating the compiler is made easier if you can look at the compiler's answers.
Then one can follow up with some MS-DOS classics.
https://www.amazon.com/Peter-Nortons-Assembly-Language-Book/...
https://www.amazon.com/Advanced-S-DOS-Programming-Microsoft-...
https://www.amazon.com/Peter-Norton-Programmers-Bible-progra...
https://www.amazon.de/PC-Intern-Programming-Encyclopedia-Dev...
It covers a wide range of interrupt routines, both DOS and the BIOS ones. Also, some PCJr sound chip programming got snuck in.
https://www.amazon.com/Zen-Assembly-Language-Knowledge-Progr...
https://www.amazon.com/Zen-Graphics-Programming-2nd-Applicat...
https://www.amazon.com/Zen-Code-Optimization-Ultimate-Softwa...
Zen of Asm is also online, I think a few of the other works, too.
It's safe to say Abrash's book had a big impact on me.
Norton's books also make me nostalgic, so thank you for that, GP.
As I recall, he was going to write a sequel but, by then, it would have been fairly pointless.
Sigh.
I did once contact the current copyright owners (DK or Penguin, I think) to see if it could be re-released or released for free, but the paperwork scared me off. Hopefully someone has more luck one day.
It’s not scary just nasty.
[BITS 16] ;tell the assembler that its a 16 bit code
[ORG 0x7C00];Origin, tell the assembler that where the code will
;be in memory after it is been loaded
mov ah, 0x0A ; Set the call type for the BIOS
mov al, 66 ; Letter to display
mov cx, 3 ; Times to print it
mov bh, 0 ; Page number
...
TIMES 510 - ($ - $$) db 0 ;fill the rest of sector with 0
DW 0xAA55 ; add boot signature at the end of bootloader
BL is not set because it is irrelevant. How you clear/save a register was up to you. https://en.wikipedia.org/wiki/INT_10H
.text is a section of executable format, but what you got is a boot loader. It doesn’t have sections, it’s just a first 512-byte boot disk sector that is loaded at 7C00h by BIOS and directly jmp’d into.
I forgot what exactly $-$$ is, but one of those is “current” address and another should be ORG address, but I’m not sure, so this expression turns into e.g. TIMES 410 DB 0, if 100 bytes used by so far.
AA55 is a boot sector end marker, something like canary value. Never looked into that in detail.
Assemblers were mostly case-insensitive, like Pascal and BASIC. Case is up to you, if you have any preference.
Edit: oh, this code is from the article. Bad habit of reading comments first, sorry!
- Intel CPU programming guide https://www.intel.com/content/dam/www/public/us/en/documents...
- Calling conventions https://en.wikipedia.org/wiki/X86_calling_conventions https://en.wikibooks.org/wiki/X86_Disassembly/Calling_Conven...
- Web compiler output viewer https://godbolt.org/
- Operation code (opcode) reference http://ref.x86asm.net/
- Disassembler/debugger https://github.com/eteran/edb-debugger, https://x64dbg.com
- Disassembler/Reverse engineering tools http://hte.sourceforge.net/ https://github.com/radareorg/cutter
And this: https://github.com/codilime/veles (binary analysis tool)
A good introduction to syscalls, with some explanation is "The Linux Programming Interface", http://man7.org/tlpi/ (book)
If you are at CMU you should definitely take this course, as long as your pain tolerance is high.
This course teaches students to write a preemptive operating systems kernel from scratch. It is quite an experience (I TA'd it after finishing my PhD while trying to figure out what to do next).
The kernels the students wrote used to be able to boot on standard (but old) PC hardware. Sadly the modern USB stack is so complex that a conformant thing to talk to a USB keyboard is pretty much as complex as the student's whole project (but less educational). So non-legacy hardware that lacks a PS/2 keyboard no longer has this nice easy path to read/write stuff to console without a lot of setup.
It most certainly does. See the chapter on 8086 emulation in the Intel Software Developer's Manual, Volume 3.
How much bytes do you think one requires for an OS loader? The complex part is loading all the code into memory from a file on disk partition without having a MB-sized fs driver, stdlib and loader in it yet. 16, 32 or 64 it doesn’t really matter.
I'm speaking, of course, of the wonderful Prince of Persia and its delights. So many treasures to be discovered for anyone interested in even a little bit of assembly-language programming.. it definitely sharpens my chops, anyway:
http://fabiensanglard.net/prince_of_persia/index.php
PRINCE OF PERSIA CODE REVIEW.
In many cases some basic routines used in qbasic was actually faster than their counterparty interupts in asm. A grand example of this would be using mode 13h (320x200) and interupt 10 to set all pixels on a screen to a single color, which could take up to 2 seconds using machine code and bios interupts (as it verifies vertical and horizontal refresh prior to setting the pixel). Using interupts however is relativly painfree as the author pointed out.
Here's macOS Hello, world code I see floating around a lot, and I can't make heads or tails of it:
global start
section .text
start:
push dword msg.len
push dword msg
push dword 1
mov eax, 4
sub esp, 4
int 0x80
add esp, 16
push dword 0
mov eax, 1
sub esp, 12
int 0x80
section .data
msg: db "Hello, world!", 10
.len: equ $ - msgThe assembler breaks down as:
push dword msg.len
push dword msg
push dword 1
mov eax, 4
sub esp, 4
int 0x80
add esp, 16
push dword 0
mov eax, 1
sub esp, 12
int 0x80
msg: db "Hello, world!", 10
.len: equ $ - msg
cat hello.c
#include <unistd.h>
char str[] = "Hello, World!\n";
int main() {
write(1, str, sizeof(str)-1);
return 0;
}
.file "hello.c"
.intel_syntax noprefix
.globl str
.data
.align 8
.type str, @object
.size str, 15
str:
.string "Hello, World!\n"
.text
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
push rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
mov rbp, rsp
.cfi_def_cfa_register 6
mov edx, 14
lea rsi, str[rip]
mov edi, 1
call write@PLT
mov eax, 0
pop rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident "GCC: (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0"
.section .note.GNU-stack,"",@progbits
You can compile and run with:
gcc -std=c11 hello.c && ./a.out
Prouduce hello.s from hello.c with: gcc -std=c11 hello.c -S -masm=intel
Going piece by piece: on x86, each register has several sizes. For instance, rax is a 64-bit register, with its lower 32-bit half being eax, its lower 16-bit half being ax, and its lower 8-bit half being al (for historical reasons). So when a register name starts with "r", it's the 64-bit variant. Therefore, "rip" is the 64-bit address of the next instruction.
The instruction "mov rsi, str[rip]" would get the 64-bit address of the next instruction, add to it a fixed offset (which the assembler and linker compute for you, as the exact offset you need to get to the data at the "str" label), load 64 bits from that address, and put the result in the "rsi" register. And that's not even the most complex addressing mode; you can get a register, add to it another register multiplied by 2, 4, or 8, add to it a constant, and use it as the memory address to load, store, or even modify in-place.
The "lea" instruction (load effective address) is a way to get directly at the power of that complex address calculation logic for your own uses. Instead of using the computed memory address to get at the memory, it's the memory address that's put in the register. Therefore, where "mov rsi, str[rip]" would read from memory, "lea rsi, str[rip]" would put in rsi the memory address the "mov" would have read from.
This also allows for a few tricks. For instance, you can use "lea" to multiply a number by five, without using the multiplier: just use a register and the same register scaled by 4 (and you can also add a constant to the result, still in a single complex instruction).
1. It's much easier to study the disassembly of object files than executables. Or better yet, use -S to ask the compiler to emit assembler.
2. Don't use hello world as your first program. Those involve either library calls or system calls. Strings too, and strings are not so straightforward in any systems programming language. Start with single functions (not called main) that take two arguments and add them/subtract them/multiply them.
3. Try learning x86-64 first. It's easier to learn because you don't have to know about the stack to understand and write simple arithmetic functions, if they take no more than six arguments.
4. It usually helps to pass -Os to the compiler to have it generate more compact code. You won't see lots of superfluous code to load/store things to the stack (for debugability) but you also won't see autovectorized code.
It aligns quite well with the study (in diagrams and commented assembly) of x86 in POC || GTFO starting in pocorgtfo04.pdf chapter 3 provided by Shikhin Sethi.
https://github.com/nebulet/nebulet/blob/master/wasm/fibonacc...
https://github.com/Hanks10100/wasm-examples/blob/master/simp...