Native compiler and C interop

[vitiral]

Here are some thoughts I have for the first native backend/compiler

• IR/etc will be a stack machine, not a register machine. Leaning towards just use spor directly.
• Will compile to do stack operations. I.e. will keep a separate data stack with memory protected bounds via a global or pass-ed local variable.
  • Will observe C calling conventions. Stack access will be through a "global" variable (or probably a passed-in local). External C function need to use WS_ADD and WS_POP to interface.

Basically I am going to make things as simple as possible while still having fairly good performance, C-interop and fngi VM interop. Functions will be able to be immediately compiled and then executed as "fngi native" functions.

[vitiral]

A little more about this in reference to #18 point 3:

I think it makes the most sense for the first compiler's goal to essentially be C interop, but with the architectural knowledge that this should not be permanantly tied to C. That is the main reason why I wrote civc: to create a library with an API for fngi to match (with Roles used for files/allocators). It allows C code to interface directly with fngi without fngi needing to get bogged down in the C architecture conventions (such as malloc and direct file-descriptor access).

It's possible we will never need a linker, because it's possible that fngi will essentially "compile at boot time." It all depends on how we want the OS to be architected. I'm not opposed to a linker, I just don't want to make any assumptions. When running on a unix our "backend" will just generate one or more .o files which the unix linkers can have fun with.