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

[Tony Hosking]

On 8 Jan 2009, at 14:50, Jay wrote:

>  > 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
>
> The compiler and runtime are unavoidably somewhat interdependent on  
> each other.
>   You know, that the compiler generates calls to RTHooks.i3.

Yes, of course they are, but we want to keep the interface between  
them as narrow as possible.

> If you want the ability to retarget the compiler to a slightly  
> different runtime, then the runtime should
> inform the compiler, and not the other way around, but they remain  
> interdepenent.

Not sure how you would achieve that.

>  There are similar issues here probably regarding RT0.i3 and  
> RTBuiltin.c.

Here be dragons...

> I guess you don't want the compiler to clutter the global type/ 
> modulespace, as a communications channel, to share information.

Precisely.

> But I think language and library are somewhat murky.

True.  Java has a simple core language, but lots of powerful libraries.

> Is INTERFACE Word in the language or the library?
> Is LOCK language or library?
> These are both in-between.
> INTERFACE Word is in the "standard library", and I think it is only  
> in the compiler as an implementation specific optimization. LOCK is  
> necessarily in both.
>
>  - Jay
>
>
>
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] duplication between compiler, m3makefile, and  
> libraries; cross build easing
> Date: Thu, 8 Jan 2009 03:44:40 +0000
>
> 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.edu
> To: jay.krell at cornell.edu
> Date: Thu, 8 Jan 2009 13:46:58 +1100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] duplication between compiler, m3makefile, and  
> libraries; cross build easing
>
> 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/6db89270/attachment-0002.html>