qfcc isn't meant to be long running, so I'm not super worried about memory
usage, but definitely lost memory blocks when compiling just a single
function seems a tad sloppy.
Now, for each compilation, or before linking, only InitData needs to be
called. Fixes the double chaining internal error when compiling and linking
in the same command.
The base of the type encodings block is given by the .type_encodings def.
The block begins with a "null" type (4 words of 0), followed by the first
type encoding.
At some stage, I will need to add information for extended def information
(32 bit offset, type encoding, other?), but this is good for initial
testing.
The encodings of static types were getting corrupted because their defs
were not necessarily in the same places between compilations when compiling
multiple files.
Since gnu bison and flex are required anyway, no harm in using their api
prefix options. Now, qfcc can compile both QC/Ruamoko and Pascal files
(Pascal is (currently?) NOT supported in progs.src mode), selecting the
language based on the extension: .r, .qc and .c select QC/Ruamoko, .pas and
.p select Pascal, while anything else is treated as an object file (as
before).
There is much breakage, but qfcc now produces a progs.dat from either
progs.src or object files. Better yet, the progs.src result is passed
through the linker, removing much duplicate code.
Pointers to the void type descriptor looked just like null pointers and
that was terribly confusing. Avoid that confusion by pre-allocating a
small amount of data in order to reserve space for a null descriptor.
Separate compilation will take fixing object files.
The generated code is broken due to various relocation fixups being
broken, and float immediates seem to be badly broken.
Debug information is broken too.
Since there is now a proper symbol table, defs are now just references to
memory locations and the symbol table takes care of duplicates.
Also, start using far data for ObjQC structures.
The qfo functions have been stubbed out until I figure out what to do with
object files in the new scheme.
That which isn't rewritten is horribly broken. However, this does include a
nice mechanism for building QC structs for emitting data.
emit.c has been gutted in the spirit of "throw one away".
There is much work to be done to get even variables emitted, let alone
code. Things should be a little more fun from here on.
