[M3commit] CVS Update: cm3

[Jay Krell]

CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	12/09/16 00:40:10

Modified files:
	cm3/m3-sys/m3back/src/: M3C.m3 

Log message:
	some struct reworking -- use the lame non-deal "standard structs",
	since we don't easily know the size of returned structs
	
	Pass structs by pointer, and copy into a local value.
	(Uplevel structs?)
	I don't want to do it this way..
	C has perfectly good by-value struct parameters and results,
	and we aren't ABI-compliant this way, if it matters.
	(need to check the other front ends -- "standard structs"
	is basically always at high risk of being non-compliant
	on modern systems, "standard" of course being another name for "usually wrong"!
	but yes I should know the ABIs better on all systems..)
	
	Notice how we cast to void* when passing structs,
	where otherwise we have no void* casts, always ADDRESS
	which is char* and we get types more correct in general..but not here..
	Need to confirm my observations here..need to get the Builder changes
	in so Tony maybe can look? (or redo it via config/quake to
	look like an existing mode.. maybe... I don't like the modes
	and now I've added another..)
	
	avoid #include math.h/string.h -- seems to speed it up
	still #include stddef.h unfortunately, need to try to fix that
	need to collect size_t and ptrdiff_t and typedef them ourselves
	where possible, else fallback to #include stddef.h
	declare the following ourselves, without #include:
	ceil, floor, memcpy, memmove, memset
	This might be a losing battle though.
	We could either bite the bullet and #include.
	Or #include if needed (making a second pass over the code).
	Or provide wrappers in m3core, losing inlining.
	
	add more min/max/abs wrappers, e.g. for REAL and EXTENDED
	(REAL needed, EXTENDED not)
	
	tentatively Var => M3CG.Var
	tentatively Proc => M3CG.Proc
	tentatively CVar => Var
	tentatively CProc => Proc
	
	compose structs of short/int/INT64, not just char, to try to
	raise their alignment
	
	fix typo internal_declara_param => internal_declare_param
	
	ongoing conversion to 4 space indentation
	
	change set operations between bit_size and byte_size
	correct now?
	
	fix fatal error in compare where it popped 1 instead of 2 (and
	then pushed, overall pop 1) this causes an access violation in TextLitInfo because it was
	writing into readonly memory; horrendous little problem, took
	a while to track down..need to be careful, the debugging costs
	are high...