> Is there a table of contents for the manual? I’m on my phone and I only see next/previous buttons, and that’s very tedious.
On desktop, should be on the left (like readthedocs). On mobile there should be a hamburger icon. I'll look into it (the MarkDown to HTML converter is my project too, https://gitlab.com/bztsrc/gendoc so you are right to blame me if this isn't working)
Most of it is standard (like "jmp", "jz", "jnz", "call", "ret" etc.), and for the rest I've used AT&T style type-in-suffix syntax, like "mulf" (float multiplication), "ldb" (load byte), "stw" (store word) etc. It's a RISC, about 60 instructions only, so it's pretty straightforward and easy to learn I believe.
> Was it inspired by something (6502)?
Not really. I invented the instruction set as I wrote the C compiler and the optimizer. My goal was to come up with a bytecode that plays nicely with the code generator and can be processed in the VM easily and efficiently.
Full disclosure, I've used 6502 (back in the C64 era, haven't touched it for a while). On the other hand I use x86 and AArch64 Assembly regularly and I also have a fair knowledge on VM bytecode (like Lua, Java, WASM) too, so these might have unintentionally affected some of my decisions. But I don't think any of these as direct inspiration.
> I assumed you were relying on an existing compiler.
Fair assumption, actually I was. Originally I wanted to port Bellard's TCC, but run into roadblocks: no real architecture abstraction layer as it generates machine code directly, so hard to port to a new CPU. Also it would be nearly impossible to add new languages like BASIC to that compiler.
> Very impressive!
Thank you very much, but I'm not so sure. C89 is a very simple language (the best ever in terms of provided expressivity and required compiler complexity IMHO).
TL;DR Problem only starts when you try to generate efficient code for an actual real hardware (which part I elegantly avoided entirely by designing the CPU myself), and when you start adding features from the later, increasingly more insane standards (C99, C11 etc.). K&R were geniuses, most of the restrictions they designed and were put in the basic ANSI C89 language makes it extremely easy to implement a C compiler.
And a little rant about integrating a 3rd party compiler, if you don't mind: it was much harder to integrate Lua. That's because Lua is a security nightmare, poorly documented and does not work the way as the doc says. For example:
- Lua might call abort() on your host application (seriously, not joking! And "lua_pcall" dares to throw an "isn't protected" error, resulting in calling that abort. I had to come up with an ugly continuity function and "lua_resume" workaround);
- lack of parameter verification, calling functions like "lua_getinfo" might segfault without any apparent reason;
- unless patched, execution of user provided strings as system commands is allowed;
- unless patched, provides full file system access outside of the sandboxed environment;
- ...and I still couldn't figure out how to get the faulting source line from an error event (which one might think to be obvious and trivial, but it really isn't).
So yeah, integrating Lua definitely took longer than implementing my own compiler :-)
> For Lua and file system access, is that only with the standard library? If not, that would be very surprising!
If by standard library you mean Lua's io package in baselib, then the answer is yes. For example, "dofile" or "loadfile" functions will work no matter baselib is removed or not.
In a nutshell, I've removed package, coroutine, io, os modules from baselib and all functions calling fopen or fread/fwrite (like "loadfile") and replaced these with the MEG-4 API. This way you have the same functions in Lua as in C. All the rest left untouched; eg. table, string, utf8, math, etc. modules are still available as usual.
1) Is there a table of contents for the manual? I’m on my phone and I only see next/previous buttons, and that’s very tedious.
2) What kind of assembly language does it use? Was it inspired by something (6502)?