[M3commit] CVS Update: cm3

[Daniel Alejandro Benavides D.]

Hi all:
if a pre processor is more powerful than the language we are designing is a design mistake or we are not getting the whole picture here, the language code generator is to maintain portability in one way using different code generator for each platform.
Other approaches are not recommended for this scenario (but are possible), or if you want why you don't use C Code Generating - Modula-3 compiler (it will make compiler faster?), you can remove the m3cg step and be quicker if you might on that agreeing in that M3CG is minded for light weight fast turn around backend or slow high quality back-end compiler.
Why do you think writing high quality compiler is better in C than in Modula-3? Of course C is far better to hack, but if you can write **same** purpose compiler in Modula-3, that's better IMHO.
What do you think Jay? See M3CG interface generator speed versus C compiling speed perhaps using a standard complexity test of grammars will tell the truth. I believe that's the idea in M3CG to make the lowest complexity making biggest speed up, I believe the same for C but not for the speed but for space of memory, that was its design goal.
SO if you ask about expressive power of the language both are about the same, but for speed and complexity (in grammar terms is an open question:
http://event.cwi.nl/pem/2011/2011-02-24-Zaytsev.pdf

) due its different scenario is not fair to compare
Thanks in advance




--- El vie, 21/9/12, Jay Krell <jkrell at elego.de> escribió:

De: Jay Krell <jkrell at elego.de>
Asunto: [M3commit] CVS Update: cm3
Para: m3commit at elegosoft.com
Fecha: viernes, 21 de septiembre, 2012 21:20

CVSROOT:    /usr/cvs
Changes by:    jkrell at birch.    12/09/22 02:20:37

Modified files:
    cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 

Log message:
    significant work in progress on data structures
    useful to backends -- storing up all the m3cg
    in memory, to be looped over/played back, in order
    to get it into the order needed
    
    This is a LOT of tedious work.
    It was SO much easier to do in m3cc via the preprocessor.
    A macro processor can be incredibly useful. Really.
    
    Three or so modes are allowed for (which does increase the tedium).
    One can loop over the array of refs and use ISTYPE/NARROW/LOOPHOLE.
    ISTYPE/NARROW would be unnecessarily slow, LOOPHOLE would be fast
    One can loop pver and switch on a type tag (not all filled in).
    One can pass in a M3CG and the data will all be passed to
    its appropriate functions (work in progress).
    And then pass in a different M3CG, that shares state with the first.
    Like, "mini" M3CGs that do nothing (inherit from M3CG_DoNothing)
    but pay attention to only a few functions, like e.g. to accumulate
    a list of all struct sizes.
    
    I will probably use that last option.
    
    This will give us the power to fix several things:
    - support arbitrary struct sizes as parameters
    - pass and esp. return structs by value letting the C compiler do the work,
    as well as being ABI compliant (what we haven't isn't a violation per se,
    for our code, as you can write your C this way; it is a violation for <*extern*> though.)
    - only declare/implement static helper functions that we use
    - support uplevel locals in nested blocks -- to enable building the whole system!
    - forward declare all imports ahead of all functions, and therefore
    - just once
    - honor begin/end_block; stop tacking numbers onto identifiers
    - maybe honor free_temp
    - generate valid C++ for the module globals (w/o an extra indirection)
    - possibly use real structs and infer real field accesses
    - maybe more (there is more to improve, not sure if this stuff
    needed for it; e.g. move globals out of the "segment" would be nice
    remove obviously unused functions; fix shifts by greater than size
    (requires symbolic expressions instead of strings)
    - much better stock debugging! (due to the structs)
    `

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20120924/fa4c80ce/attachment-0002.html>