Commentary Cmm page (Observations and Areas for Improvement)

[Peter Tanski]

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