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

[Tony Hosking]

Why would the compiler know anything about jmpbuf in general?  (Yes, I  
know it is used for exception handling).  I would prefer that we had  
table-based exception handling as on SOLgnu for all targets, but that  
depends on support for stack unwinding for each target.  I would hate  
for the compiler to inject a type for something like jmpbuf which is  
an *internal* detail of the exceptions implementation rather than a  
language-defined type.  Also, there are advantages in the current  
approach, which decouples communication of information amongst the  
tool-chain components.

Why would you use setcontext, getcontext, etc. for exception  
handling.  setjmp/longjmp are perfectly adequate to the task.   
setcontext/getcontext are intended for user-thread switching, etc.

I think you'll find there already is a compiler mode that does not  
invoke cm3cg.

Antony Hosking | Associate Professor | Computer Science | Purdue  
University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484



On 8 Jan 2009, at 00:36, Jay wrote:

> duplication between compiler, m3makefile, and libraries.
>
>
> I propose that there should be reduced or no duplication
> among 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 bytes
> leaving 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, though
> not 100%. I didn't know the endianness of e.g. 88k, vax, and the  
> historically
> terse 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 modify
> or 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 and
> doesn't seem important).
>
> Reasonable ideas?
>
>
> Personally what I do is my Python scripts accept a target name  
> anywhere on the
> command 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 elevated
> into 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 becomes
> about 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/20090108/b0d6b21b/attachment-0002.html>