<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Is table-based exception handling close to being feasible on many targets?<BR>
I figured it was mostly a lost cause but wouldn't mind being wrong.<BR>
Perhaps the evolution of gcc has made it much easier these days?<BR>
You know, what with Ada and C++ exception handling support being whatever it is?<BR>
<BR>
Imho target-specific information should be<BR>
kept to a minimum<BR>
kept to a minimum number of places/files <BR>
perhaps kept to a minimum distance from other target-specific information (places/files)<BR> and like other information, not duplicated<BR>
<BR>
<BR>
If jumpbuf wasn't used by the compiler, then my position weakens.<BR>
However currently the size and alignment of jumpbuf is duplicated.<BR>
And endianness is duplicated. And wordsize is duplicated.<BR>
I wouldn't mind if jumpbuf was only, say, Csetjmp.i3, and wordsize was only in the config file.<BR>
But duplication bugs me.<BR>
<BR>
> why context for exception handling vs. setjmp/longjmp.<BR>
<BR>
Just my ignorant questioning. If setjmp/longjmp suffice, ok.<BR>
They are just similar and perhaps if switch one, switch the other.<BR>
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).<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
From: hosking@cs.purdue.edu<BR>To: jay.krell@cornell.edu<BR>Date: Thu, 8 Jan 2009 13:46:58 +1100<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] duplication between compiler, m3makefile, and libraries; cross build easing<BR><BR>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.<BR>
<DIV><BR></DIV>
<DIV>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.</DIV>
<DIV><BR></DIV>
<DIV>I think you'll find there already is a compiler mode that does not invoke cm3cg.<BR>
<DIV><BR>
<DIV><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV style="WORD-WRAP: break-word"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV><FONT class=EC_Apple-style-span color=#0000ff><FONT class=EC_Apple-style-span face="Gill Sans"><SPAN class=EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans"><SPAN class=EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans">Antony Hosking</SPAN></SPAN></FONT></FONT><FONT class=EC_Apple-style-span face="Gill Sans"><SPAN class=EC_Apple-style-span style="FONT-FAMILY: Gill Sans"><SPAN class=EC_Apple-style-span style="FONT-FAMILY: Gill Sans"> | </SPAN></SPAN><SPAN class=EC_Apple-style-span style="FONT-FAMILY: Gill Sans"><SPAN class=EC_Apple-style-span style="FONT-FAMILY: Gill Sans">Associate Professor</SPAN></SPAN><SPAN class=EC_Apple-style-span style="FONT-FAMILY: Gill Sans"><SPAN class=EC_Apple-style-span style="FONT-FAMILY: Gill Sans"> | Computer Science | Purdue University</SPAN></SPAN></FONT></DIV>
<DIV><FONT class=EC_Apple-style-span face=GillSans-Light><SPAN class=EC_Apple-style-span style="FONT-FAMILY: GillSans-Light">305 N. University Street | West Lafayette | IN 47907 | USA</SPAN></FONT></DIV>
<DIV><FONT class=EC_Apple-style-span face="Gill Sans" color=#0000ff><SPAN class=EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans"><SPAN class=EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans">Office</SPAN></SPAN></FONT><FONT class=EC_Apple-style-span face=GillSans-Light><SPAN class=EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"><SPAN class=EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"> +1 765 494 6001 | </SPAN></SPAN></FONT><FONT class=EC_Apple-style-span face="Gill Sans" color=#0000ff><SPAN class=EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans"><SPAN class=EC_Apple-style-span style="COLOR: rgb(0,0,255); FONT-FAMILY: Gill Sans">Mobile</SPAN></SPAN></FONT><FONT class=EC_Apple-style-span face=GillSans-Light><SPAN class=EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"><SPAN class=EC_Apple-style-span style="FONT-FAMILY: GillSans-Light"> +1 765 427 5484</SPAN></SPAN></FONT></DIV>
<DIV><FONT class=EC_Apple-style-span face=GillSans-Light><BR class=EC_khtml-block-placeholder></FONT></DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN><BR class=EC_Apple-interchange-newline></SPAN></DIV></SPAN></DIV><BR>
<DIV>
<DIV>On 8 Jan 2009, at 00:36, Jay wrote:</DIV><BR class=EC_Apple-interchange-newline>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">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></DIV></SPAN></BLOCKQUOTE></DIV><BR></DIV></DIV></body>
</html>