[M3commit] CVS Update: cm3

Jay Krell jkrell at elego.de
Tue Sep 3 07:45:31 CEST 2013


CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	13/09/03 07:45:31

Modified files:
	cm3/m3-sys/mklib/src/: Main.m3 

Log message:
	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));
	
	Another hazard?
	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.
	Or Target.Int.
	
	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 mailing list