[M3commit] CVS Update: cm3
jkrell at elego.de
Tue Sep 3 07:45:31 CEST 2013
Changes by: jkrell at birch. 13/09/03 07:45:31
raise the limits:
buf: 2K => 8K (bigger and we get warnings, ugh)
MaxKeeper: 10000 => TextLiteral.MaxBytes
I'd really just like to keep all the files in memory and
remove a bunch of code and likely be faster on modern systems,
and adequate on ancient systems, but I am scared by stuff like:
VAR ptr: UNTRACED REF ARRAY [0..MaxKeeper+1] OF CHAR;
how do I give it no limit?
UNTRACED REF CHAR?
Wr.PutString (lib_wr, SUBARRAY (ptr^, 0, f.size));
Is f.size limited to TextLiteral.MaxBytes?
Or maybe that is a compile-time limit but in reality
32bit code can create an array larger than 512MB?
(todo: try it)
TextLiteral.MaxBytes is another bug in our system.
It should be LAST(INTEGER), including being huge on 64bit
systems, or nonexistant, but instead it is much lower, like 512MB,
even on 64bit systems.
This is because it is a number of bits and for cross
builds it has to be in a 32bit integer.
LONGINT throughout will provide relief.
It was huge on 64bit systems. I'm the one who introduced
the cross build dependency, in my head and usage, not in the code.
And also, yeah, files can be larger than address space,
but that is yet rare for .objs/.libs.
I'll try later to keep everything in memory.
Memory mapped I/O would be appropriate here too.
Or, again, just deleting mklib and drastically limiting its role.
It could read in just one file at a time, write the .def file,
dump the file from memory, and then run link /lib @responsefile.
Providing the functionality ourselves theoretically gives a better
bootstrap -- we build .libs on arbitrary hosts -- but it is a
stumbling block to new ports (e.g. ARM_NT) and gets in the way of
using LTCG. Also I thought there were endian bugs here, but maybe not.
Look again later.
Until/unless we have more integrated backends AND an actual linker,
mklib doesn't really help.
More information about the M3commit