[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