[M3devel] a "need" for multi-pass m3cg (or different order of calls)

Antony Hosking hosking at cs.purdue.edu
Thu Sep 6 23:13:14 CEST 2012


I’ll respond to this in more detail, but briefly, I object strongly to a multipass m3cg.  If you need multiple passes then you probably need a different internal representation (just like m3cg has a different internal representation).  M3CG is a simple single-pass linear representation of a program.  If you need multiple passes to understand it then that is your problem.  I imagine that any backend will itself need to be multipass anyway (if it is to do something useful).  I think your C backend should be multipass too.  It certainly will need to read M3CG IR and import it into some reasonable internal representation. This is exactly the strategy I am taking with M3CG to LLVM IR.  I will have some minor tweaks to M3CG just to lift its level of abstraction slightly (to better communicate typed indexing of arrays and fields, for example).  But I see no need to make M3CG do any more heavy lifting.

On Sep 6, 2012, at 4:40 AM, Jay K <jay.krell at cornell.edu> wrote:

> /* The following is legal C but not C++: */
> 
> 
> struct Foo_t;
> typedef struct Foo_t Foo_t;
> static struct Foo_t Foo; /* illegal C++; C forward/tentative definition */
> 
> int F1(void) { return *(int*)&Foo; }
> 
> struct Foo_t { int i; };
> static Foo_t Foo = { 123 };
> 
> 
> This is a reason that either
> 1) I "need" to make M3C.m3 "multi pass"
> 2) or at least buffer everything in memory
> in multiple pieces and then concat at the end
> 
> 
>   I could also make it less efficient:  
> 
> 
>   struct Foo_t; /* segment */ 
>   typedef struct Foo_t Foo_t;  
>   static struct Foo_t * /*const*/ Foo;  
> 
> 
>   int F1(void) { return *(int*)&Foo; }  
> 
> 
>   struct Foo_t { int i; };
>   static Foo_t _Foo = { 123 };  
>   static Foo_t* /*const*/ Foo = &_Foo;
> 
> But that seems unfortunate.
> 
> 
> I will want to generate C++ at some point, for efficient portable exception
> handling. But that comes later.
> 
> 
> Also later, the C code needs a reordering in order to refer to fields in "segments".
> 
> 
>  - Jay

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


More information about the M3devel mailing list