[M3commit] CVS Update: cm3
Jay Krell
jkrell at elego.de
Sun Oct 3 14:20:03 CEST 2010
CVSROOT: /usr/cvs
Changes by: jkrell at birch. 10/10/03 14:20:03
Modified files:
cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c
Log message:
read entire file into memory
Even if the file is large, they usually aren't,
our access pattern is linear, so virtual memory suffices.
This can help with some possible simplifications and speedups,
including the next item, which ends up separting the
buffer from any file.
To deal with circular types, which inhibit
us from building good type information in one pass,
introduce a mechanism where an opcode can request that it
be "replayed"; still, some amount of type information
must be created to make forward progress; this is not
fully fleshed out yet; what we need to do be sure to
create The node that will represent the types, even
if we don't fill in its details until later; and then, later,
retrieve the node, and fill in more. That is, during "replay",
we must not create brand new nodes.
e.g. records could be initially empty, then define all the
types of their constituent fields, including perhaps pointers
to the record itself, and then go back and fill in the fields
In general, due to circularities, there is not an ordering
that can work in one pass.
There are multiple examples in the tree where the declarations
come in in a non-working order (possibly there not being
a working order). sortedtableextras, for example.
To this end, of the "replay" feature, generally move "M3_TYPES" code
ahead of the m3gdb code, to avoid the m3gdb code running twice,
since I don't know if that will work.
The m3gdb code will be deferred until the M3_TYPES code has enough
information to complete.
disable all type code for now
put back all volatile
because something is amiss
neither of these edits are meant to last
remove the mechanism for altering return types
That which I recently cleaned up to stop widening
return types.
put in the missing builtin WIDECHAR
Should this be in RTBuiltin.m3x?
Put in UID_NULL as well.
These last two get us somewhat more complete typeinfo,
but there are still circularities we don't likely handle correctly yet.
(Not to mention not handling the various array types correctly.)
Use VOID_TYPE_P instead of comparison to t_void.
Probably no difference in Modula-3, but we were already inconsistent.
Make line number unsigned.
More information about the M3commit
mailing list