To ensure that the rendering system is being run in the main thread, I
added the concept of "Sync systems", so that when a system group is
created it's possible to specify whether it's possible to run it on a
separate thread or not.
By defining archetypes using SOAs (Zig has this data structure in `std`,
called std.MultiArrayList), the engine can iterate faster over commonly
defined entities avoiding cache misses since each component is aligned
with other components of the same entity.
Alhtough IR parsing is technically called while
parsing, since we lack the hability to parse
blocks or labels or if or any hard stuff really,
it does not affect code parsing. However it is
nice to have it there as zig compiles it :)
This proposal drops the memory alignment from u32
that is required by spec to a u16. But I think
u16 should be more than enough to represent any
real alignment.
Also this is closer to a custom asm than a IR but
whatever...
This is a proposal of a custom IR to run wasm.
At the moment only `ir.zig` has some parts related
to this IR. The idea of the IR is to be a subset
of the one defined in wasm. There are some gaps
(mostly in wasm instructions that have opcode
0xFC) but in wasm they don't use all of the
opcodes for some reason so maybe we could try to
utilize them and be a superset of wasm.
It now follows a more functional style but it
should be waaay easier to add functionality.
Probably the parser is a bit slower than the
previous one but the code is much cleaner and a
good enough compiler should be able to inline the
function calls and make it par with the previous
one.
As a TODO, runtime structs should not depends on
the parser, but I think that is a topic for
another commit.
