Alright, I have a little 8086 assembler for my toy OS going now – or rather a proof-of-concept thereof. It only supports a tiny fraction of the instruction set. It was an interesting learning experience, but I don’t think trying to “complete” this program is worth my time.
The whole thing is just a learning project, I don’t want to actually make a usable OS. There are a few more things I want to have a look at and then I’ll eventually move on to 386/amd64 later this year (hopefully).
@movq@www.uninformativ.de Woohoo! You selected a turing complete instruction set, so all good. ;-)
@lyse@lyse.isobeef.org Yeah, what else does one need? 😅
I added more instructions, made it portable (so it runs on my own OS as well as Linux/DOS/whatever), and the assembler is now good enough to be used in the build process to compile the bootloader:
That is pretty cool. 😎
It’s still a “naive” assembler. There are zero optimizations and it can’t do macros (so I had to resort to using cpp). Since nothing is optimized, it uses longer opcodes than NASM and that makes the bootloader 11 bytes too large. 🥴 I avoided that for now by removing some cosmetic output from the bootloader.
The most valuable resource is Table B-13 at the end of Volume 2D of the Intel docs. It’s a very long but easy to understand table of instruction encodings – assuming you already know how that ModR/M stuff works.
@movq@www.uninformativ.de Oh, this is really awesome! :-) Hats off to you, that would take me forever to accomplish.
Haha, eleven bytes, how mean is that!? :-D But I already see you working on that as well at some point in the near future. :-)
@lyse@lyse.isobeef.org Heh, thanks, yeah, reading the Intel docs takes time. I’ve been doing that on and off since September (for this blog post), so I’m almost used to it now. But doing that for the very first time is quite gnarly. They’re not super well written.
I really think (this time) that I won’t add many more features. 😅 At the moment, the program is very “generic” and basically only does some pattern matching: If it sees a mov instruction followed by some 8 bit register and then some 8 bit number, then it encodes it as a 0xB0 byte using a certain mechanism (e.g., the register number might get added to 0xB0 and then the 8 bit number might just follow verbatim). That’s what the long list in the screenshot shows. “A cmp followed by two arguments of a certain type gets encoded as …” They’re all handled exactly the same.
Adding support for more instructions mostly just means adding more entries to that table.
If I were to add “optimizations”, I guess complexity would skyrocket. 😅
@movq@www.uninformativ.de Neat, that sounds like a clever design with a table implementation. :-)
Oh, for sure! Complexity will definitely go through the roof and beyond with optimizations, no doubt. Maybe with the very simplest of the easy ones it might be still reasonably straight forward, but I also imagine that this has the potential to escalate very quickly. :-D