> As the external-cmm syntax isn't fully tied down, we'll have to
> synchronise PprCmm.hs with the Cmm parser. What is the best way to do
> this, so that we emerge with a well-defined external
> representation for
> Cmm?
>
> Also, while we're here, a couple of questions:
>
> * So we want both an external Cmm representation, as well as
> a true C--
> code generator? So PprCmm is the external-cmm printer, but we also
> need a C-- generator?
Ok, so we need these output passes:
(a) Cmm -> .cmm
(b) Cmm -> .s
(c) Cmm -> .hc (registerised, mangled)
(d) Cmm -> .c (unreg'd, not mangled)
Now, we think that (c) and (d) can be the same (they currently are,
after all). However they will be considerably simpler than the current
PprAbsC, because Cmm is "macro-expanded" relative to the old AbstractC.
What you currently have as PprCmm could turn into the C-- code generator
in due course (and we'll also use it for general ppr activities).
We also need the parser:
(f) .??? -> Cmm
The question is, what syntax should we use for the parser: preferably it
should be a *superset* of one of the output formats, so that we can feed
the output back in as input again. I say superset, because the input
syntax will need to be able to use macros for info table construction,
closure construction, and many other things, which are expanded using
the Cmm "smart constructors". These won't be present in the output, of
course.
We have a choice between using .hc or .cmm for the input syntax. Since
we're not going to be feeding these files into either a C-- compiler or
a C compiler, it doesn't really matter which we choose. Given the C--
flavour of the backend choosing a C--ish syntax might be more
appropriate.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
