It never really helped sort out the path issues when using build
directories. It worked well enough for single directory projects, but
things got messy very quickly, especially when mixing ruamoko libs with
external progs. A better method based on dwarf is coming.
Fixes#6
It turned out that the problem with @zero was caused by initial type
chaining occurring before the structures had been initialized and thus
the linker's @zero type encoding string was incorrect: {?=} instead of
{tag @zero-}, thus when the actual type encoding supplied by an object
file came along (with the correct encoding string), it wasn't found.
The server code is not yet ready for doubles, especially in its varargs
builtins: they expect only floats. When float promotion is enabled
(default for advanced code, disabled for traditional or v6only),
"@float_promoted@" is written to the prog's strings.
I was originally going to put it in the debug syms file, but I realized
that the data persistence code would need access to both def type and
certainly correct def offsets for defs in far data.
The encoding is 3:5 giving 3 bits for alignment (log2) and 5 bits for
size, with alignment in the 3 most significant bits. This keeps the
format backwards compatible as until doubles were added, all types were
aligned to 1 word which gets encoded as 0, and the size is unaffected.
qfcc now does local common subexpression elimination. It seems to work, but
is optional (default off): use -O to enable. Also, uninitialized variable
detection is finally back :)
The progs engine now has very basic valgrind-like functionality for
checking pointer accesses. Enable with pr_boundscheck 2
Simply "backed" and "virutal". Backed spaces have memory allocated to them
while virtual spaces do not. Virtual spaces are intended for local
variables and entity fields.
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.
After running across a question about lists of animation frames and states,
I decided giving qfcc the ability to generate such lists might be a nice
distraction from the optimizer :) Works for both progs.src and separate
compilation. No frame file is generated if no macros have been created.
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.
