[M3devel] m3 backends and builtin types?

[Jay K]

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


 - 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> 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 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 University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120816/9c311ce4/attachment-0002.html>