[M3devel] m3 backends and builtin types?

Sun Aug 19 09:14:23 CEST 2012

Thank for the pointers to m3gdb -- it kind of confirms my belief that the system isn't great.Even if there is a bootstrapping problem, it seems wrong for each backend and m3gdb to pay for it.Just m3front/m3front should have this hardcoded information.
There is an m3front -emit option to ... i think provide the information..but it fails.I suspect it used and works when building just m3core.I have to look more. For now I'm punting on paying any attention to type information in the C-backend-in-progress.Just like the other backends ignore it all also.(ok..gcc uses it in the wierd way for m3gdb...)   - Jay
 > Date: Fri, 17 Aug 2012 14:28:53 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3 backends and builtin types?
> 
> 
> 
> On 08/15/2012 09:07 PM, Jay K wrote:
> >   > There is a bootstrap issue here isn’t there?
> >
> > I am not sure. I don't understand the system enough. :(
> >
> >
> > I suspect, but am not certain, the ultimate source of this information is/can-be m3front/builtinTypes.
> > The compiler does for example construct the type BOOLEAN out of lower level pieces.
> > Can it not then proceed to compute its typeid, and inform the backend about it?
> >
> >
> > Other examples appear to include...wait.where did I get this list?
> > At some point, I was verifying that gcc/gcc/m3cg/parse.c was "informed" about every typeid that it later recieved a use of.
> > Like, declare_array/declare_open_array/declare_enum/declare_typename should all precede declare_local, declare_param, declare_procedure (the return type).
> > I built up the following list:
> >
> >
> > UID_INTEGER = 16_195C2A74; (* INTEGER *)
> > UID_LONGINT = 16_05562176; (* LONGINT *)
> > UID_WORD = 16_97E237E2; (* CARDINAL *)
> > UID_LONGWORD = 16_9CED36E7; (* LONGCARD *)
> > UID_REEL = 16_48E16572; (* REAL *)
> > UID_LREEL = 16_94FE32F6; (* LONGREAL *)
> > UID_XREEL = 16_9EE024E3; (* EXTENDED *)
> > UID_BOOLEAN = 16_1E59237D; (* BOOLEAN [0..1] *)
> > UID_CHAR = 16_56E16863; (* CHAR [0..255] *)
> > UID_WIDECHAR = 16_88F439FC;
> > UID_MUTEX = 16_1541F475; (* MUTEX *)
> > UID_TEXT = 16_50F86574; (* TEXT *)
> > UID_UNTRACED_ROOT = 16_898EA789; (* UNTRACED ROOT *)
> > UID_ROOT = 16_9D8FB489; (* ROOT *)
> > UID_REFANY = 16_1C1C45E6; (* REFANY *)
> > UID_ADDR = 16_08402063; (* ADDRESS *)
> > UID_RANGE_0_31 = 16_2DA6581D; (* [0..31] *)
> > UID_RANGE_0_63 = 16_2FA3581D; (* [0..63] *)
> > UID_PROC1 = 16_9C9DE465; (* PROCEDURE (x, y: INTEGER): INTEGER *)
> > UID_PROC2 = 16_20AD399F; (* PROCEDURE (x, y: INTEGER): BOOLEAN *)
> > UID_PROC3 = 16_3CE4D13B; (* PROCEDURE (x: INTEGER): INTEGER *)
> > UID_PROC4 = 16_FA03E372; (* PROCEDURE (x, n: INTEGER): INTEGER *)
> > UID_PROC5 = 16_509E4C68; (* PROCEDURE (x: INTEGER;  n: [0..31]): INTEGER *)
> > UID_PROC6 = 16_DC1B3625; (* PROCEDURE (x: INTEGER;  n: [0..63]): INTEGER *)
> > UID_PROC7 = 16_EE17DF2C; (* PROCEDURE (x: INTEGER;  i, n: CARDINAL): INTEGER *)
> > UID_PROC8 = 16_B740EFD0; (* PROCEDURE (x, y: INTEGER;  i, n: CARDINAL): INTEGER *)
> > UID_NULL = 16_48EC756E; (* NULL *)
> >
> >
> > Surely these aren't all fundamental??
> >
> >
> > 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.
> >
> >
> > 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:
> >
> >
> > TYPE Record1 = RECORD REF Record2 END;
> > TYPE Record2 = RECORD REF Record1 END;
> >
> > 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..
> >
> >
> 
> This is a fundamental problem.  There are ways perfectly legitimate programs need recursive
> definitions and declarations, your M3 example being one.  Modula-3's rule that all declarations
> in a scope are made "simultaneously" is an unusual (maybe unique) way of supporting this,
> along with separate rules explicitly disallowing certain forms of recursive declarations
> that would be troublesome.  E.g., deleting both occurrences of "REF" above would give
> records of infinite size.  You might say the language uses "opt-out" for certain recursive
> declarations.
> 
> Most languages use an opt-in strategy.  The default rules is declare-before-use.  For select
> kinds of declarations, there is some kind of "forward" declaration that declares the name
> and only some of its properties.  After that, the name then can be used in limited ways (most
> interestingly, in other declarations).  Eventually, there has to be a complete declaration that
> give the name again and supplies the remaining properties.  After that it can be used in all
> legal ways.
> 
> A lot of intermediate languages, e.g. the input language(s) of gdb tend to use the declare-before-
> use strategy with a system of forward declarations.  My impression is that gcc is this way,
> but poorly documented.
> 
> Will it give enough hints to just look at the front end output for selected recursive declaration
> sets like this example?  It would at least give something known to be acceptable to gdb.  Or
> is gdb changing the rules with new releases?
> 
> >   - Jay
> >
> >
> > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  --
> > From: hosking at cs.purdue.edu
> > Date: Wed, 15 Aug 2012 19:58:23 -0400
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] m3 backends and builtin types?
> >
> > There is a bootstrap issue here isn’t there?  You need the compiler to inform the runtime of information that the compiler needs...
> >
> > On Aug 15, 2012, at 6:11 PM, Jay K <jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>> wrote:
> >
> >     Something seems off to me in the current implementation.
> >     Like, I don't think the backends are ever informed of various "builtin" types, such as integer, word, char, widechar, boolean, mutex.
> >     I hardcoded knowledge of them in parse.c and M3C.m3.
> >     That seems wrong.
> >
> >
> >     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.
> >
> >
> >     Shouldn't m3front inform the backend via m3cg of these types?
> >     It is doable using the existing interfaces?
> >
> >
> >     More so,RTBuiltin.mx <http://RTBuiltin.mx>ought not exist, right?
> >     Whatever data it contains should be built up like any other type data?
> >     Part of the same problem?
> >
> >
> >       - Jay
> >
> >
> >
> >
> > Antony Hosking|Associate Professor | Computer Science | Purdue University
> > 305 N. University Street | West Lafayette | IN 47907 | USA
> > Mobile+1 765 427 5484
> >
> >
> >
> >
> >
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120819/b00e441d/attachment-0002.html>