For technical reasons (programmer laziness), qfcc does not fix up local
def type encodings when writing the debug symbols file (type encoding
location not readily accessible).
The debug subsystem now uses the resources system to ensure it cleans
up, and its data is now semi-private. Unfortunately, PR_LoadDebug had to
remain public for qfprogs because using PR_RunLoadFuncs would cause
builtin resolution to complain.
It is now set to 0 when progs are loaded and every time
PR_ExecuteProgram() returns. This takes care of the default case, but
when setting parameters, pr_argc needs to be set correctly in case a
vararg function is called.
PR_SaveParams() is required for implementing the +initialize diversion
used by Objective-QuakeC because builtins do not have local def spaces
(of course, a normal stack calling convention would help). However, it
is entirely possible for a call to +initialize to trigger another call
to +initialize, thus the need for stacking parameter stashes. As a
bonus, this implementation cleans up some fields in progs_t.
The engine now requires non-v6 progs to store the log2 alignment for the
param struct in .param_alignment.
PR_EnterFunction is clearer and possibly more efficient.
Only as scalars, I still need to think about what to do for vectors and
quaternions due to param size issues. Also, doubles are not yet
guaranteed to be correctly aligned.
I've decided that setting pr.max_edicts and pr.zone_size as part of the
local progs initialization rather than in PR_LoadProgsFile makes more
sense. For one, it is unlikely for the limits to change every time progs is
reloaded. Also, they seem to be a property of the VM rather than the progs.
However, there is nothing stopping the caller from updating max_edicts and
zone_size every call.
While scan-build wasn't what I was looking for, it has proven useful
anyway: many of the sizeof errors were just noise, but a few were actual
bugs (allocating too much or too little memory).
The offset to compensate for st++ was missing.
Obviously, the code has never been tested. Found while looking at the
jump code and thinking about using 32-bit addresses for the jump tables.
I'd forgotten that ED_ConvertToPlist mangled light into light_lev and
single component angle values into a vector. This fixes much of the
breakage in qflight (but not the light levels)
It was pointed out by Blub\w (gmqcc) that OP_MUL_FV and friends were buggy
when the operands overlapped (eg, x = x.x * x) as the result would become
'x.x*x.x x.y*x.x*x.x x.z*x.x*x.x' (note the x.x squared for y and z). On
testing, sure enough the bug was present (and is a nice demonstration that
QF's VM does NOT have strict-aliasing bugs). As a very nice benefit: the
code produced by the fixes is actually faster than the broken version :).
The ruamoko code used for testing:
void (string fmt, ...) printf = #0;
vector foo (vector x)
{
x = x * x.x;
return x;
}
vector bar (vector x)
{
x = x.x * x;
return x;
}
int main ()
{
vector x = '2 3 4';
vector y = foo (x);
vector z = bar (x);
printf ("x=%v y=%v z=%v 2*x=%v\n", x, y, z, 2*x);
return 0;
}
Need to up the precision by one due to the difference between g and e, but
much prettier. Might need to rename that function :P I wish I'd thought to
check if g would work, but thanks to divVerent for the suggestion.
Normally, the order doesn't matter, but when tracing code, it becomes very
difficult to tell where the trace ends and the dump begins. Printing the
message first puts the message between the trace and the dump: much easier
:)
Aliasing the jump table to an integer broke statement_get_targetlist with
the new alias def handling, and was really wrong anyway. I probably did
that due to being fed up with things and wanting to get qfcc working again
rather than spending time getting jumpb right.
Using "=" was rather confusing, so changing it to "<CONV>" seems to be a
good idea. As the string is used only for selecting opcodes at compile
time, only qfcc is affected.
Certain versions of qcc (fteqcc comes to mind :P) strip the names from
builtin functions. This breaks saved games that happen to have a builtin
function in a saved function variable. The earlier builtin name
reconstruction patch happened to fix the writing of save games for such
progs, and this one fixes the reading.
That is, the descriptors loaded from the progs file. Some compilers (eg,
fteqcc :P) strip builtin names from the progs, which makes debugging
difficult.
Rather than checking the raw edict count in the entities file against the
progs' max_edicts, check the allocated entity's number. This allows loading
of sophisticated maps (eg, digs04) that prune many of their entities.
There will normally be only one unnamed field (if any), and it's always the
null field. This will put an eventual end to the "'' is not a field"
messages.
o All instances of LIBADD/LDADD have a corresponding DEPENDENCIES
specificatiion.
o libraries now use a lib_ldflags macro to keep things consistent
o duplication of source/lib names has been minimized (particularly in
the libraries; more work needs to be done for the executables)
o automake spec blocks have been organized (again, more work needs to be
done for the executables)
qcc always used vector stores to load values into the function parameters,
but if the location of the value is too close to the end of the global data
block (the vector spans the end of the block), it would trigger the bounds
check code. Thus, allow such instructions without a murmer, so long as it
actually is a parameter write.
In the original save gave format, global vectors were saved as individual
components rather than as a single vector, using the _x/_y/_z tags on the
vector name. However, recent qfcc completely dumped vector components as
separate defs, so old save games would have trouble loading with progs
built with a recent qfcc. Thus, do the component translation if necessary.
I was wondering why that parrot was dead.
Not realizing that negke's coag3 map had too many entities really ruined
the pleasure of playing it, so it's best to treat such situations as an
error (max_edicts can be bumped up to 32000 if need be, but 2048 is plenty
for his map).
