[M3devel] higher level m3cg?

[Daniel Alejandro Benavides D.]

Hi all:
It might need some pre-processor but C is supposedly superior in performance than C# and Java by far, I mean we are not talking about using C, we are talking about generating object code from UNSAFE code, but it shouldn't be that bad in terms of assembly level compile and link time process compared to those systems, if not then why every body wants their software be written in (e.g us) Modula-3, but compiled in a C environment it must be something about engineering causes of who wrote that  thing first, and C is much older, so there is better support for that UNSAFE level code (instead look C3 and Java, lame), and that's for me more important in this matter.
Probably C is referred as a high-level assembly (like DEC-SRC first versions), instead of a low-level assembly language like here we are trying to do.
In fact if we were able to generate C from M3CG we can gain better portability, for instance my project of compare cross-boots would be more easily than by itself now.
Thanks in advance

--- El mar, 21/8/12, Dirk Muysers <dmuysers at hotmail.com> escribió:

De: Dirk Muysers <dmuysers at hotmail.com>
Asunto: Re: [M3devel] higher level m3cg?
Para: "Jay K" <jay.krell at cornell.edu>, "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 21 de agosto, 2012 06:18



 



*** 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/f0b9cb98/attachment-0002.html>