[M3commit] CVS Update: cm3
jkrell at elego.de
Sun Sep 16 00:40:10 CEST 2012
Changes by: jkrell at birch. 12/09/16 00:40:10
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.
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
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
More information about the M3commit