<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Thank for the pointers to m3gdb -- it kind of confirms my belief that the system isn't great.<BR>Even if there is a bootstrapping problem, it seems wrong for each backend and m3gdb to pay for it.<BR>Just m3front/m3front should have this hardcoded information.<br>There is an m3front -emit option to ... i think provide the information..but it fails.<BR>I suspect it used and works when building just m3core.<BR>I have to look more.<BR> <BR>For now I'm punting on paying any attention to type information in the C-backend-in-progress.<BR>Just like the other backends ignore it all also.<BR>(ok..gcc uses it in the wierd way for m3gdb...)<BR> <BR> <BR> - Jay<br> <BR><div>> Date: Fri, 17 Aug 2012 14:28:53 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] m3 backends and builtin types?<br>> <br>> <br>> <br>> On 08/15/2012 09:07 PM, Jay K wrote:<br>> > > There is a bootstrap issue here isn’t there?<br>> ><br>> > I am not sure. I don't understand the system enough. :(<br>> ><br>> ><br>> > I suspect, but am not certain, the ultimate source of this information is/can-be m3front/builtinTypes.<br>> > The compiler does for example construct the type BOOLEAN out of lower level pieces.<br>> > Can it not then proceed to compute its typeid, and inform the backend about it?<br>> ><br>> ><br>> > Other examples appear to include...wait.where did I get this list?<br>> > At some point, I was verifying that gcc/gcc/m3cg/parse.c was "informed" about every typeid that it later recieved a use of.<br>> > Like, declare_array/declare_open_array/declare_enum/declare_typename should all precede declare_local, declare_param, declare_procedure (the return type).<br>> > I built up the following list:<br>> ><br>> ><br>> > UID_INTEGER = 16_195C2A74; (* INTEGER *)<br>> > UID_LONGINT = 16_05562176; (* LONGINT *)<br>> > UID_WORD = 16_97E237E2; (* CARDINAL *)<br>> > UID_LONGWORD = 16_9CED36E7; (* LONGCARD *)<br>> > UID_REEL = 16_48E16572; (* REAL *)<br>> > UID_LREEL = 16_94FE32F6; (* LONGREAL *)<br>> > UID_XREEL = 16_9EE024E3; (* EXTENDED *)<br>> > UID_BOOLEAN = 16_1E59237D; (* BOOLEAN [0..1] *)<br>> > UID_CHAR = 16_56E16863; (* CHAR [0..255] *)<br>> > UID_WIDECHAR = 16_88F439FC;<br>> > UID_MUTEX = 16_1541F475; (* MUTEX *)<br>> > UID_TEXT = 16_50F86574; (* TEXT *)<br>> > UID_UNTRACED_ROOT = 16_898EA789; (* UNTRACED ROOT *)<br>> > UID_ROOT = 16_9D8FB489; (* ROOT *)<br>> > UID_REFANY = 16_1C1C45E6; (* REFANY *)<br>> > UID_ADDR = 16_08402063; (* ADDRESS *)<br>> > UID_RANGE_0_31 = 16_2DA6581D; (* [0..31] *)<br>> > UID_RANGE_0_63 = 16_2FA3581D; (* [0..63] *)<br>> > UID_PROC1 = 16_9C9DE465; (* PROCEDURE (x, y: INTEGER): INTEGER *)<br>> > UID_PROC2 = 16_20AD399F; (* PROCEDURE (x, y: INTEGER): BOOLEAN *)<br>> > UID_PROC3 = 16_3CE4D13B; (* PROCEDURE (x: INTEGER): INTEGER *)<br>> > UID_PROC4 = 16_FA03E372; (* PROCEDURE (x, n: INTEGER): INTEGER *)<br>> > UID_PROC5 = 16_509E4C68; (* PROCEDURE (x: INTEGER; n: [0..31]): INTEGER *)<br>> > UID_PROC6 = 16_DC1B3625; (* PROCEDURE (x: INTEGER; n: [0..63]): INTEGER *)<br>> > UID_PROC7 = 16_EE17DF2C; (* PROCEDURE (x: INTEGER; i, n: CARDINAL): INTEGER *)<br>> > UID_PROC8 = 16_B740EFD0; (* PROCEDURE (x, y: INTEGER; i, n: CARDINAL): INTEGER *)<br>> > UID_NULL = 16_48EC756E; (* NULL *)<br>> ><br>> ><br>> > Surely these aren't all fundamental??<br>> ><br>> ><br>> > Eventually I decided that declare_array/typename/open_array/enum don't come in a nice order anyway, and I changed parse.c to loop until it could "resolve" all typeids -- loop such that declare_<type> preceeds declare_local/param/field.<br>> ><br>> ><br>> > That still bugs me, but I haven't verified just what the front end is doing, and if there aren't ultimately possibly circularities that make a sort impossible anyway...consider:<br>> ><br>> ><br>> > TYPE Record1 = RECORD REF Record2 END;<br>> > TYPE Record2 = RECORD REF Record1 END;<br>> ><br>> > If there is only declare_record followed by declare_field, it will "never work" the way I wanted -- you'll always have to see a ref to a type before seeing the type defined. Ok. So I have to deal with an arbitrary order.. I guess I'll go and write the required loop -- and hold everything in memory... at least for a later pass at this stuff. The initial version doesn't need great type info, just as the existing backends don't need it...eh..I guess I can do without fixing the original issue first therefore..<br>> ><br>> ><br>> <br>> This is a fundamental problem. There are ways perfectly legitimate programs need recursive<br>> definitions and declarations, your M3 example being one. Modula-3's rule that all declarations<br>> in a scope are made "simultaneously" is an unusual (maybe unique) way of supporting this,<br>> along with separate rules explicitly disallowing certain forms of recursive declarations<br>> that would be troublesome. E.g., deleting both occurrences of "REF" above would give<br>> records of infinite size. You might say the language uses "opt-out" for certain recursive<br>> declarations.<br>> <br>> Most languages use an opt-in strategy. The default rules is declare-before-use. For select<br>> kinds of declarations, there is some kind of "forward" declaration that declares the name<br>> and only some of its properties. After that, the name then can be used in limited ways (most<br>> interestingly, in other declarations). Eventually, there has to be a complete declaration that<br>> give the name again and supplies the remaining properties. After that it can be used in all<br>> legal ways.<br>> <br>> A lot of intermediate languages, e.g. the input language(s) of gdb tend to use the declare-before-<br>> use strategy with a system of forward declarations. My impression is that gcc is this way,<br>> but poorly documented.<br>> <br>> Will it give enough hints to just look at the front end output for selected recursive declaration<br>> sets like this example? It would at least give something known to be acceptable to gdb. Or<br>> is gdb changing the rules with new releases?<br>> <br>> > - Jay<br>> ><br>> ><br>> > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>> --<br>> > From: hosking@cs.purdue.edu<br>> > Date: Wed, 15 Aug 2012 19:58:23 -0400<br>> > To: jay.krell@cornell.edu<br>> > CC: m3devel@elegosoft.com<br>> > Subject: Re: [M3devel] m3 backends and builtin types?<br>> ><br>> > There is a bootstrap issue here isn’t there? You need the compiler to inform the runtime of information that the compiler needs...<br>> ><br>> > On Aug 15, 2012, at 6:11 PM, Jay K <jay.krell@cornell.edu <mailto:jay.krell@cornell.edu>> wrote:<br>> ><br>> > Something seems off to me in the current implementation.<br>> > Like, I don't think the backends are ever informed of various "builtin" types, such as integer, word, char, widechar, boolean, mutex.<br>> > I hardcoded knowledge of them in parse.c and M3C.m3.<br>> > That seems wrong.<br>> ><br>> ><br>> > Either that, or they are used before they are defined -- which might not be avoidable in general, but could easily be avoided for most types.<br>> ><br>> ><br>> > Shouldn't m3front inform the backend via m3cg of these types?<br>> > It is doable using the existing interfaces?<br>> ><br>> ><br>> > More so,RTBuiltin.mx <http://RTBuiltin.mx>ought not exist, right?<br>> > Whatever data it contains should be built up like any other type data?<br>> > Part of the same problem?<br>> ><br>> ><br>> > - Jay<br>> ><br>> ><br>> ><br>> ><br>> > Antony Hosking|Associate Professor | Computer Science | Purdue University<br>> > 305 N. University Street | West Lafayette | IN 47907 | USA<br>> > Mobile+1 765 427 5484<br>> ><br>> ><br>> ><br>> ><br>> ><br>> <br></div> </div></body>
</html>