[M3commit] CVS Update: cm3

[Jay K]

The problem was I declaring subranges to have the same type as their domain.
Which would often make them too large.
Which broke the sizes of fields.
This should be better shortly.

 - Jay


----------------------------------------
> Date: Sun, 3 Oct 2010 14:20:03 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
>
> 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.
>