The dags code isn't the only place that creates temporary variables, so
count them as they go into a statement rather than when they're created.
This fixes the temp underflows.
Nicely, the need for dag_gencode to recurse seems to have been removed.
At least for a simple case, correct code is generated :)
switch.r:49: case 1: *to = *from++;
003b loadbi.i *(from + 0), .tmp10
003c add.i from, .imm, from
003d storep.i .tmp10, *to
A node that writes to a var must be evaluated after any node that reads
that var, so for any node reading var, add that node to the edges of the
node currently associated with the var (unless the node is a child of the
node reading the var).
It doesn't make any difference yet, but that's because I need to add extra
edges indicating iter-node dependencies. However, the sort does seem to
work for its limited input.
Not adding them while creating the dag completely broke the dag as
node(deadvar) always returned null. Code quality is back to where it was
before the dags rewrite.
While things are quite broken now (very incorrect code is being generated),
the dag is much easier to work with. The dag is now stored in an array of
nodes (the children pointers are still used for dagnode operands), and sets
are used for marking node parents, attached identifiers and (when done,
extra edges).
Instead of storing the generating statement in the dagnode, the generating
expression is stored in the daglabel. The daglabel's expression pointer is
updated each time the label is attached to a node. Now I know why debugging
optimized code can be... interesting.
It now seems to generate correct code for each node. However, node order is
still incorrect in places (foo++ is being generated as ++foo). quattest.r
actually executes and produces the right output :)
flow_analyze_statement uses the statement type to quickly determin which
operands are inputs and which are outputs. It takes (optional) sets for
used variables, defined variables and killed variables (only partially
working, but I don't actually use kill sets yet). It also takes an optional
array for storing the operands: index 0 is the output, 1-3 are the inputs.
flow_analyze_statement clears any given sets on entry.
Live variable analysis now uses the sets rather than individual vars. Much
cleaner code :).
Dags are completely broken.
The types are expression, assignment, pointer assignment (ie, write to a
dereferenced pointer), move (special case of pointer assignment), state,
function call/return, and flow control. With this classification, it will
be easier (less code:) to determine which operands are inputs and which are
outputs.
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.
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.
Surprisingly, I don't yet have to "throw one out", but things are still
problematic: rcall1 is getting two arguments, goto and return get lost,
rcall2 got an old temp rather than the value it was supposed to, but
progress :)
This allows temporary variables that are used in multiple nodes to remain
in the dag, but also will allow more freedom when generating code from the
dag.
The root nodes of the dag need to be evaluated in execution order as some
roots may depend on the results of earlier roots (but then, this might also
be related to the problem of function calls not specifying all of their
parameters to the dag).
An instruction that both reads and writes the same variable will read the
variable before writing to it, so the instruction uses the variable rather
than defines it (for live-variable purposes).
First, it turns out using daglabels wasn't such a workable plan (due to
labels being flushed every sblock). Instead, flowvars are used. Each actual
variable (whether normal or temp) has a pointer to the flowvar attached to
that variable.
For each variable, the statements that use or define the variable are
recorded in the appropriate set attached to each (flow)variable.
The flow graph nodes are now properly separated from the graph, and edge
information is stored in the graph struct. This actually made for much
cleaner code (partly thanks to the use of sets and set iterators).
Flow graph reduction has been (temporarily) ripped out as the entire
approach was wrong. There was also a bug in that I didn't really understand
the dragon book about selecting nodes and thus messed things up. The
depth-first search tree "fixed" the problem, but was really the wrong
solution (sledge hammer :P).
Also, now that I understand that dot's directed graphs must be acyclic, I
now have much better control over the graphs (back edges need to be
flipped).
It turns out dot does not like cyclic graphs (thus some of the weird
layouts), but fixing it by flipping back-edges requires proper recording of
edge info (I guess that's what T is for in the dragon book).
The reduction is performed itteratively until the graph is irreducible, but
such that each reduction wraps the previous graph. Unfortunately, due
depth-first searching not being implemented, graphs that should be reduced
(ie, those with natural loops).
set_first() now returns a pointer to a setstate_t struct that holds the
state necessary for scanning a set. set_next() will automatically delete
the state block when the end of the set is reached. set_delstate() is also
provided to allow early termination of the scan.
They're now dot_sblock.c and print_sblock. The new names both better
reflect their purpose and free up "flow" for outputting the real flow
analysis graphs.
Much of the data recently added to sblock_t has been moved to flownode_t.
No graph reduction is carried out yet, but the initial (innermost level)
graph has been built.
Dot interprets escape sequences in non-html string, and needs the quotes to
be escaped, so quote the result of operand_string. Unfortunately,
operand_string uses quote_string and quote_string returns a static pointer,
so some hoop-jumping is necessary.
It seems the dag creation algorithm doesn't like "a = a op a", so use
"b = a op a" instead. Since I plan on fixing temp leaks anyway, this won't
be a problem (also, few people even use qfcc's v6 float modulo :P).
Because of the way it is used, the data in the type encodings space needs
to always be correct (ie, relocated), even for partially linked object
files.
Rather, only that it is neither external nor local. The idea was to catch
myself swapping the arguments to resolve_external_def, but for some reason
I decided type encoding defs would not be global (save game reasons?).
Fixes the bogus redefined errors when entity fields are used.
Also, rename extern_defs and defined_defs to extern_data_defs and
defined_data_defs (more consistent with the other tables).
The problem was caused by add_relocs and process_loose_relocs adjusting the
reloc offset based on the reloc's space's base address. This is fine for
most relocs, but as relocs for the type space have already been adjusted by
process_type_space, those relocs must be left alone by add_relocs and
process_loose_relocs. As a bonus, the duplicate code has been refactored
into a separate function :)
Now each encoding is copied across def by def using memcpy, with the
expectation that any references to other types will be handled via the
reloc system. Unfortunately, it seems there's an off-by-4 (hmm, suspicious
number...) in the reloc offsets, but I'll look into that after I get some
sleep.
defspace_alloc_loc can cause a realloc which will break the work qfo space
data pointers, so wrap it with alloc_data, which updates the appropriate
pointers and sizes.
The field/data def handling has been moved into process_data_def and
process_field def. The code for handling external defs has been moved into
its own function (extern_def()),
In passing, rename add_space to add_data_space, since it is limited to
handling data spaces.
For now, no other change has been made, but I'll be able to split up
process_def for data def vs field def processing and add a function for
processing type encoding defs.
First, the class def needed to be created before the class type, then the
def space indices had to be set early, otherwise the relocs wound up with
space 0 instead of the correct space.
All internal structs now have "proper" names, and fit the naming convention
(eg, obj_module (like objective-c's types, but obj instead of objc). Some
redundant types got removed (holdovers from before proper struct tag
handling).
Also, it has proven to be unnecessary to build internal classes, so
make_class and make_class_struct are gone, too.
When encoding a type to a qfo file, the type's encoding string is written
and thus needs to be valid prior to actually doing the encoding. The
problem occurs mostly in self-referential structs (particularly, obj_class)
because the struct is being encoded prior to the pointer to the struct.
This is similar to the problem with infinite recursion when encoding types.
The problem is with structs with self-referential pointers (eg, struct foo
{struct foo *bar}). The solution is to copy the type data to a buffer and
mark the buffer as transfered before actually processing the type. Further
processing of the type is done via the buffer.
As id and Class do not point to real objects as such, trying to get the
class from their types doesn't work, so instead send the message to a
"null" class that skips the method checks.
Now the classes are built "properly" (using the same tools as the parser
itself), and the structs (obj_object, obj_class and obj_protocol) are built
separately, but using the class ivars.
Even just before, type_obj_object, type_obj_class and type_obj_protocol
were a bit bogus (still are), but now the arrays used to list their ivars
are correct. I plan to create the above mentioned types using
class_to_struct to do it properly.
Type names are cleaned up, as is the creation. Also, the class pointer in
the type encoding now gets emitted. However, Still need to actually create
_OBJ_CLASS_Class and fix the type encoding reloc handling in the linker.
With the previous commit, the structures were being created before a valid
source file name was available and thus qfcc would segfault when trying to
generate a tag. Now, the tags look better anyway :).
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.
This required throwing out the primary rules that snax did up to help me
with conflicts many years ago, but they were now getting in the way. Now
the productions from primary are merged in with unary_expr.
It turns out no code was being generated for x = *y. Ouch. I suspect I need
to take a better look at expr_deref at some time in the not too distant
future.
Conflicts:
tools/qfcc/source/statements.c
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.
Structures (especially hard-coded ones) can be really nasty as they can
refer to themselves. Avoid the recursion by setting the type_def field of
the type before doing the recursive encodings in the structure encoder.
The encodings of static types were getting corrupted because their defs
were not necessarily in the same places between compilations when compiling
multiple files.
The result of parse_params needs to be passed through find_type before
actually being used. I guess I'd missed this back when I got things working
for qc.
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).
Return statements never flow to the next block (or any other block, for
that matter), so drawing arrows leaving them not only messes up dot's
graphs, but is quite missleading.
When mering if/goto (ie, if skipping a goto), the rest of the dead code
remover is used to delete the goto. That part of the code unuses the goto's
label. The if was getting the goto's label without the lable's used count
being incremented (the usaged temporarily increases by one). I have no idea
why the problem showed up randomly, but this seems to fix it (it fixes /a/
bug, anyway).
The naive implementation of the if/goto merging was letting the old target
of the if get dropped because the block would lose its label and thus be
judged unreachable because the preceeding goto block was still in the list.
Instead, when the if/goto are "merged", mark the goto block as unreachable,
the following block as reachable, and break out of the analysis loop to
force the removal of the goto block. Since the dead block removal function
loops until no action is taken, all other dead blocks will be removed.
The output can be controlled via --block-dot (not yet documented). The
files a named <sourcefile>.<function>.<stage>.dot. Currently, stage will be
one of "initial" (after expression to statement conversion), "thread"
(after jump threading), "dead" (after dead block removal), "final" (final
state before actual code emission).
Labels can be shared between multiple flow-control instructions, so use the
label's used counter to determine when to remove the label. This was
causing problems with the jump threading.
The common cause seems to be casting a cast (very common, and I'm not sure
just realiasing the expression would be right). It does't cause any harm
(particularly, it doesn't trigger alias def chains), so I won't worry about
it.
The actual bug might still be elsewhere, but at least now I know the alias
chains were coming from accessing .return and .param_N, which are unions
(not directly usable by the progs engine). Emitting a reference to a union
(or struct) would create an alias def, but an alias expression was created
in the expression tree to simplify return/param access. The double layer
(sometimes 3 or 4) alias isn't really neaded, so rather than layering the
aliases, just re-alias the alaised def.
It is inteded for flagging buggy conditions in the compiler, particularly
after having fixed the original bug (in case something comes back from the
dead).
v6 progs expects .zero to be only 1 word. The code actually tried to keep
vector out of .zero, but it seems I'd rearranged the structure defintion
without updating the code that kills the vector field. Problem spotted by
divVerent.
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)
Despair has things locked down such that running qfcc during a build fails
due to lack of read access to /usr/local/lib. This is actually a good
thing as accidentally hitting old includes/libs (when a file gets deleted
in the tree) hides bugs. Thus, --no-default-paths to turn off default
search paths.
The special token __INFINITY__, like __FILE__ and friends, will expand to
a floating-point expression containing a value the C compiler considers
infinite. Obviously, this assumes that the system has relatively modern
float hardware -- but if it doesn't, having Ruamoko be able to represent
float infinity is the least of your problems. :)
