On Nov 22, 2006, at 3:40 AM, Simon Peyton-Jones wrote:
* 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.
Now you've confused me! The form
x = %%op( p, q, r )
has the *form* of a call, and it *may* generate a call, but it also
fine for the C-- compiler to generate a single, inline machine
instruction. Indeed that is what GHC does for the memory-barrier
op, I think.
Got it. Just to clarify (especially for the Cmm language page):
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. 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?
'MO_WriteBarrier', the memory-barrier op, does generate a single
instruction (of a sort): it is used in two places, in the sections
for i386_TARGET_ARCH and x86_64_TARGET_ARCH of compiler/nativeGen/
MachCodeGen.hs. In both places it generates a no-op.
Cheers,
Pete
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
