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