[M3commit] CVS Update: cm3

[Jay Krell]

CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	10/10/03 08:38:34

Modified files:
	cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c 

Log message:
	enable debugging of enums, in stock gdb
	
	start code for debugging of globals, which are always embedded in global structs
	
	debugging of structs has the indirection off wrong, for example:
	
	t.r1 := 2;
	t.r2 := 3;
	t.r3 := 10;
	
	(gdb) p *t
	$4 = (struct Main.T1 *) 0xa32
	
	oops. To be fixed shortly.
	
	There are probably many cases that don't debug correctly,
	because typenames, subranges, and esp. packing probably
	aren't handled correctly. The code is careful given
	an untyped integer, not to assign it a type of a different
	types.
	
	That is, when the frontend gives us:
	
	TYPE typecode = BITS 20 FOR [...]
	VAR tc:typecode;
	
	and it tells backend tc is a word32 of type typecode,
	we ignore the stronger type and just say it is word32.
	Not doing that was caused me a lot of grief/debugging/staring
	at code.
	
	Since this is a subrange and not an enum anyway, not clear
	we should do anything different. Subranges aren't really types,
	unless, e.g. you wanted the backend to generate the range checks
	(which isn't crazy, as it could optimize away redundant checks).
	
	As well, what does it mean:
	
	TYPE Color={Red,Blue};
	TYPE T1 = BITS 2 FOR Color;
	TYPE T2 = BITS 8 FOR Color;
	TYPE T3 = BITS 800 FOR Color;
	
	Currently enum names are probably wrong, they show as Red, Blue
	in this example, probably should be Interface.Color.Red.
	
	same some pointer overhead in backend
	
	0 => NULL a bit more
	
	add function m3_make_integer_type for maybe future use, that
	can create integers of any number of bits from 1 to 64
	
	remove some more signed math