On Nov 21, 2006, at 11:31 AM, Simon Peyton-Jones wrote:
Peter Tanski wrote:
... going from the C-- Spec., statements may not produce side-
effects... while I suggested the "addc" because it might be a nice
introduction to Cmm.)
Right.
* Expressions in C-- and Cmm (a) have one result, (b) have no
effects.
* There may well be operators in official C-- that aren't
implemented in Cmm. That should be fixable, simply by adding new
primops
A relatively easy task; in some ways easier than adding an out-of-
line PrimOp to GHC, except that Cmm primops separate into those
without side effects and those that emulate side effects (CmmCalls).
A tutorial for adding these would be a useful addition to the Cmm
language wiki page. (This is in progress.)
* There is provision in C-- for primops that (a) may have more
than one result, (b) have effects. This is done by the %% syntax,
described at the end of Section 6.3 of the C-- spec.
* However this feature is ill-specified by the C-- spec; indeed
no %% operators are described at all
I did not understand that reference when I read it the first time.
Section 6.8.1 mentions 'foreign "C--"', which until now did not make
sense to me. Now I realise that C-- has a basic runtime system so
primitive operators must leave the runtime system in order to produce
side effects. Interesting workaround--reminiscent of mutable
variables in Haskell. The big question is whether all those extra
foreign calls may be reduced to the proper assembler mnemonics
instead of creating special procedures.
* Some of what you have in mind is described in Section 4.3 of
http://cminusminus.org/abstracts/c--pldi-00.html
Serves me right for not checking the Publications page. This would
make a great road map for bringing low level exceptions into Haskell,
Control.Exception to be exact. There is much to discuss regarding a
possible Cmm implementation; it is probably best to leave that for
another day. For now, I will summarise some comments I originally
wrote into this email and then deleted:
* some types of exceptions, notably processor-generated floating
point exceptions, may be enabled at the programmer's discretion and
better handled in something besides the catch-all IO Monad--perhaps a
Continuation Monad would do;
* exceptions that rely on a global "variable" in an already-extant
register, such as the Floating Point Status and Control Register
(FPSCR) on the PPC, would be faster and more efficient if that
register were kept as an invisible (but queryable, settable, etc.)
global in machine code rather than copying the value into the Haskell
runtime as a MVar; and,
* while the evaluation function ('E') would be a good abstraction
for Haskell, it should be reducible to as few machine instructions as
possible--I am not sure whether this is what you or Norman Ramsey had
in mind when you wrote the paper.
I hope this makes it clearer? Perhaps you can write up the outcome
of all this on the Cmm language wiki page?
This clarifies things greatly. Thank you. I have already begun
writing this for the Cmm language page.
Cheers,
Pete
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
