[M3devel] higher level m3cg?

Tue Aug 21 16:53:37 CEST 2012

Hi all:
target dependency is essential in this process, so a good backend must target an quintessential machine,  so I don't agree a given machine will give us lot of optimization without lot of work:
http://irclog.perlgeek.de/parrot/2010-07-25#i_2605776

M3CG can be converted to a virtual machine as an emulator of an automaton, but studying that automaton complexity will give us the real facts (instead on believing stories), I don't want to fight wars among languages, but by practice we now know that C is far easier to code low level stuff than everything else, so .. if we want a radical change let's study why we do it first.
Thanks in advance

--- El mar, 21/8/12, Antony Hosking <hosking at cs.purdue.edu> escribió:

De: Antony Hosking <hosking at cs.purdue.edu>
Asunto: Re: [M3devel] higher level m3cg?
Para: "Dirk Muysers" <dmuysers at hotmail.com>
CC: "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: martes, 21 de agosto, 2012 09:10

I concur strongly with Norman's analysis. We should be focusing on llvm. That will still require lifting the level of m3cg slightly, viz getelementptr. 
Sent from my iPhone
On Aug 21, 2012, at 7:18, "Dirk Muysers" <dmuysers at hotmail.com> wrote:

*** A warning ***
Norman Ramsey's opinion (in stackoverflow) on 
possible compiler backends:

Code generation is my business :-)
Comments on a few options:

  CLR: 

    Pro: industrial support 
    Con: you have to buy into their type system pretty much completely; 
    depending on what you want to do with types, this may not matter 
    Con: Only Windows platform is really prime-time quality

  LLVM:

    Pro: enthusiastic user community with charismatic leader 
    Pro: serious backing from Apple 
    Pro: many interesting performance improvements 
    Con: somewhat complex interface 
    Con: history of holes in the engineering; as LLVM matures expect the 
    holes in the engineering to be plugged by adding to the complexity of the 
    interface

  C--

    Pro: target is an actual written language, not an API; you can easily 
    inspect, debug, and edit your C-- code 
    Pro: design is reasonably mature and reasonably clean 
    Pro: supports accurate garbage collection 
    Pro: most users report it is very easy to use 
    Con: very small development team 
    Con: as of early 2009, supports only three hardware platforms (x86, PPC, 
    ARM) 
    Con: does not ship with a garbage collector 
    Con: project has no future

  C as target language

    Pro: looks easy 
    Con: nearly impossible to get decent performance 
    Con: will drive you nuts in the long run; ask the long line of people 
    who have tried to compile Haskell, ML, Modula-3, Scheme and more using this 
    technique. At some point every one of these people gave up and built their 
    own native code generator.
Summary: anything except C is a reasonable choice. For the 
best combination of flexibility, quality, and expected longevity, I'd probably 
recommend LLVM.
Full disclosure: I am affiliated with the C-- project. 

From: Jay K 
Sent: Thursday, August 16, 2012 4:21 PM
To: m3devel 
Subject: [M3devel] higher level m3cg?

Should m3cg provide enough information for a backend to generate 
idiomatic C?
(What is idiomatic C? e.g. I'm ignoring loop constructs and 
exception handlinh..)

Should we make it so?

Or be 
pragmatic and see if anyone gets to that point?

But, look at this 
another way.
Let's say we are keeping the gcc backend.

Isn't it 
reasonable to have a better experience with stock gdb?

What should 
m3cg look like then?

Matching up m3front to gcc turns out to be 
"wierd".
As does having a backend generate "C".

In particular, 
"wierd" because there is a "level mismatch".

m3cg presents a fairly 
low level view of the program.
  It does layout. Global variables are 
stuffed into what you might call a "struct", with
no assigned field names. 
Field references are done by adding to addresses and casting.

Too low 
level to provide a "good" gcc tree representation or to generate "normal" 
C.

One might be able to, by somewhat extraordinary means, make 
due.
That is, specifically one could deduce field references 
from
offsets/sizes. But maybe it is reasonable for load/store
to include 
fields? Maybe in addition to what it provides?

As well, it appears to 
me, that

given TYPE Enum = {One, Two, Three};

the m3cg is 
like:

declare enum typeidblah
declare enum_elt One
declare enum_elt 
Two
declare enum_elt Three
declare_typename typeidblah Enum

One 
kind of instead wants more like:

declare enum typeidblah 
Enum
declare enum_elt One => rename it Enum_One
declare enum_elt Two 
""
declare enum_elt Three ""

However I understand that {One, Two, 
Three} exists
as anonymous type independent of the name 
"Enum".

One could just as well have:
given TYPE Enum1 = {One, Two, 
Three};
given TYPE Enum2 = {One, Two, Three};

Enum1 and Enum2 
probably have the same typeid, and are just
two typenames for the same 
type.

likewise:
given TYPE Enum1 = {One, Two, Three};
given 
TYPE Enum2 = Enum1;

but, pragmatically, in the interest of generating 
better C,
can we pass a name along with declare_enum?

I ask somewhat 
rhetorically. I realize there is the answer:
  enum Mtypeid { 
Mtypeid_One, Mtypeid_Two, Mtypeid_Three };
  typedef enum Mtypeid 
Enum1;

Also, enum variables I believe end up as just UINT8, 16, or 
32.
Loads of enum values I believe end up as just loads of integers.
Can 
we pass along optional enum names with declare_local/declare_param?
And 
optional enum names with load_int?
Or add a separate load_enum 
call?

Really, I understand that the current interface can be pressed 
to do
pretty adequate things. I can infer field references. The way enums 
work
isn't too bad.

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