simonpj:
> Don
>
> Thanks for your work on PprC
Of course! It's very satisifying coding.
>
> | Add pprMachOp_for_C.
> |
> | ToDo: how are we going to generate (void*) casts, when there is no
> | NatP in the MachRep's?
>
> Would you care to describe the problem more explicitly? Or have you
> already solved it?
Well, I was working on the various pprMachOp's. In the old PprAbsC we
can generate casts like "(void *)", because we could distinguish NatP's.
For example, in the old ppr we have:
pprMachOp_for_C MO_NatU_to_NatP = text "(void*)"
But now there seems to be no easy way to know when the MachRep is really
a pointer. Here is the casting machop:
-- Conversions. Some of these will be NOPs.
-- Floating-point conversions use the signed variant.
| MO_S_Conv MachRep{-from-} MachRep{-to-} -- signed conversion
| MO_U_Conv MachRep{-from-} MachRep{-to-} -- unsigned conversion
So at the moment I'm assuming the C backend isn't going to generate any void*
casts. But I'm not certain this is the case.
> Are you ok about C macros? I saw a commit and a reversion last night..
I was walking through PprAbsC, looking for things that could be ported
across to Cmm directly. cCheckMacroText and friends looked like
candidates, until I checked that we don't have those macros in Cmm.
cCheckMacroText HP_CHK_NP = SLIT("HP_CHK_NP")
So HP_CHK_NP isn't defined in Cmm. I don't fully understand how to
convert this code to the Cmm situation, at the moment. But I've
allocated the next few weeks to backend-hacking.
-- Don
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
