[M3devel] duplication between compiler, m3makefile, and libraries; cross build easing

[Jay]

duplication between compiler, m3makefile, and libraries.
 
I propose that there should be reduced or no duplicationamong the compiler, m3makefile, and libraries.
 
I propose that the compiler reveal (some) of what it knows.
 
For example, m3makefile shall not specify WORD_SIZE.The compiler should.Granted, this buys very little.
 
m3makefile shall not contain tables identifiying endianness.Compiler shall defined TARGET_ENDIAN to "BIG" or "LITTLE",or perhaps "big" or "little".Granted, this buys very little.
 
Libraries shall not define jumpbuf, in a sense.Compile shall define, something like:  TARGET_JUMPBUF_ELEMENT = "INTEGER" or "LONGINT".    aka jmpbuf alignment.  TARGET_JUMPBUF_SIZE = a decimal integer.
Leaving library to say:
 TYPE jmpbuf = ARRAY [1..size] OF element
which m3makefile shall produce.
 
or perhaps even compiler shall inject the type itself,as it injects a few things like INTERFACE Word functions.
 
or compiler shall define TARGET_JUMPBUF_ALIGN = 32 or 64,and TARGET_JUMPBUF_SIZE in bytesleaving m3makefile to map 32 to Ctypes.int and 64 to LONGINT itself.
 
The jumpbuf size/align bothers me more than word size and endianness.Word size and endianness are more widely known to humans I think.Endianness and word size are usually fairly obvious, thoughnot 100%. I didn't know the endianness of e.g. 88k, vax, and the historicallyterse names don't make it obvious.
 
However, let me not confuse "jumpbuf" with "Thread.State" or such.Assume user threads stops using setjmp/longjmp and modifyor generalize proposal accordingly.
Wonder if exception handling should use set/get/make/swapcontext also??Assume jumpbuf might remain on some platforms?
 ?
As well, one should be able to specify m3config on the command line.One should be able to specify target on the command line.Compiler shall take specified target and search /somehow/ for the right config file.Perhaps in path to cm3\..\config\target.Don't probe like crazy -- not like I have it coded in Quake currently.That really bites when there is more than one, and you edit the wrong one.
Probably something like,  probe for path to cm3\..\config\target.
but if defined $CM3_CONFIG_DIRECTORY, search instead $CM3_CONFIG_DIRECTORY\target.however this is perhaps colon or semicolon delimited, so maybe CM3_CONFIG_PATH.(In particular, I have nearly all my config files in m3-sys/cminstall/src/config-no-install,except NT386, which I'd really like to move, but will probably break something anddoesn't seem important).
Reasonable ideas?
 
Personally what I do is my Python scripts accept a target name anywhere on thecommand line, and if present, they set $M3CONFIG.So I have what I want via python already.You know, kind of a successful (imho) prototype, that should perhaps be elevatedinto the "real" stuff?
 
You know, make it easier and easier to contruct cross-capable installations,where switching targets is changing environment variables and/or command lines,and not editing/copying files.
 
If there isn't already, there should be a mode that doesn't run cm3cg.And possibly can still ship.That way /any/ system can do a bunch of cross-build "checking".And the file system layout for creating a "boot" archive becomesabout the same as the layout of a "real" system. Not like what I use -- I use one flat directory, since Modula-3 requires that every..basically ever .i3, .m3, .o file have a unique name.  (.i3 and .m3 can clash with each other, once each, that's it).
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090107/804d8be6/attachment-0001.html>