The fury lanugage has several compiler goals
v(not doing version control seriously at this stage) - produce binary code, for any subset of the language, for a platform, real or not.
v0.0 - minimal C-like language, most of the core type system, minus the abstract stuff. multi file handling, compiling on a real platform.
v1.0 - fully functioning compiler with all or most of the language shipped.
This is how builds will be done (eventually), just load files and pass them into a standard library "compile" function.
I think this'll blur the line between whether fury is a compiled or scripting language.
All operations are just described in the fury language as operations on bytes, meaning there are almost no assumptions about physical hardware.
the trade off here is that the ISA target has to be described in fury in the first place and that the compiler has to prove certain operations equivalent.
This description is intended to be part of a "backend library", obviously most people don't want to touch that to write a hello world.
I think this is ultimately a boon, since that means the compiler backend not only serves as a functional compiler, but also as documentation for the ISA.
I'm not yet sure how to encode the binary for each instruction, but this is a backend problem not a user one.
Things like pointers are not built in very intentionally, even though this is a low level language.
I want more direct control over hardware, in ways current hardware doesn't really support.
Such as direct control over the cache or in processor memories.
I think these kinds of hardware changes would dictate a new type of pointers for type of physical memory.
Beyond what you can do in other languages, syntax figured out, precedence still iffy.
operator byte myop my ( byte input ) op {/implementation/} as an example, the ternary would be written
operator byte ?: (byte a) ? (byte b) : (byte c) { if(a) return b; else return c; }
Operators are just functions with special calling syntax.
byte ( 1 byte )
dual ( 2 bytes )
quad ( 4 bytes )
oct ( 8 bytes )
struct ( like a C struct )
notice there are no pointers or strings here, those will be somehow built out of bytes, and operations on bytes, that is all.
This read me file is far from finished, just needed to get something down before it slipped my mind again.
I'll start putting more of my thoughts on this project/approach in writing.
Things I need to self host the compiler
pointers (AST does not exist without them)
syscalls (no file IO is possible without them)
some syntax magic for string literals so that I can use strings in a sane way. (technically a comfort feature, but needed)