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

[Jay]

Is table-based exception handling close to being feasible on many targets?
I figured it was mostly a lost cause but wouldn't mind being wrong.
Perhaps the evolution of gcc has made it much easier these days?
You know, what with Ada and C++ exception handling support being whatever it is?
 
Imho target-specific information should be
  kept to a minimum
  kept to a minimum number of places/files 
  perhaps kept to a minimum distance from other target-specific information (places/files)  and like other information, not duplicated
 
 
If jumpbuf wasn't used by the compiler, then my position weakens.
However currently the size and alignment of jumpbuf is duplicated.
And endianness is duplicated. And wordsize is duplicated.
I wouldn't mind if jumpbuf was only, say, Csetjmp.i3, and wordsize was only in the config file.
But duplication bugs me.
 
 > why context for exception handling vs. setjmp/longjmp.
 
Just my ignorant questioning. If setjmp/longjmp suffice, ok.
They are just similar and perhaps if switch one, switch the other.
I realize that longjmp can only officially be called once per setjmp, and that contexts are "reusable" (can be swapped an arbitrary number of times).
 
 - Jay



From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Thu, 8 Jan 2009 13:46:58 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easingWhy 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 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 elementwhich 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/20090108/1c38ec60/attachment-0002.html>