[M3devel] m3 backends and builtin types?

[Rodney M. Bates]

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
>
>
>
>
>