| Section 6.8.1 of the C-- spec states that form of a procedure call
| statement includes a calling convention, 'conv.' If the 'conv' is
| not specified, it is implicitly 'foreign "C--"'. Maybe the wording
| is a little too explicit: "C--" is the native calling convention so
| 'foreign "C--"' sounds like something different. There is no
| difference: all calls are "foreign" to the caller.
Again I'm confused. The form
x = %%foo( p, q )
in the C-- spec has *nothing* to do with foreign calls. Not a thing! Nor, does
it necessarily have anything to do with *calls*. It might be implemented by a
single inline machine instruction.
| As I (confusedly)
| understood it, the "runtime" might be as simple as a stack map;
| suspending the caller--saving the caller's state before a call--might
| mean that those parameters passed to the callee and any global
| variables not declared 'invariant' may change, especially their
| value. The C-- guarantee that primops do not have side-effects means
| that the caller state *never* has to be saved before the operation,
| while statements with side-effecting primops *may* require the caller
| state to be saved--for example, when the side-effect of the operator
| would potentially change the control flow. This is is where the Cmm
| implementation details come up: would the caller state *always* save
| (conversely, the %%op would generate a call) when the %%op contains
| code that might change the control flow? That would depend on how
| the control flow might change, as suggested in section 4.4 of your
| "C-- Extension..." paper, "Informing the optimiser." Does this sound
| correct?
I think I'm misunderstanding your question. Let me try again
* The primops in a C-- *expressions* have no side effects, and it's
unspecified what order they are done in.
* A %% op in a C-- *statement* (no more than one in one statement!) can have
side effects. The order in which C-- statements are executed is completely
specified by the control flow.
We don't need to speak of the C-- runtime at all in specifying this stuff.
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
