Cmm, signed 16-bit values and the PowerPC
simonmar at microsoft.com
Thu Jan 15 09:52:16 EST 2004
> Houston, we have a problem: the Cmm datatype doesn't contain enough
> information for proper PPC code generation.
> On the PowerPC, signed 16-bit-values are usually sign-extended when
> they are loaded into a register. The Mac OS X calling
> convention for C
> mandates this for 'short' parameters passed in registers. Unsigned
> short parameters must always have their high bits cleared.
> But neither the CmmLoad expression nor the CmmCall statement is
> annotated with the necessary signed/unsigned flags, so I'm stuck.
> Via-C code generation will probably work because the missing
> information about signedness/unsignedness can be supplied via
> function prototypes.
> I'd only need an annotation in one of those two places, but
> I'm not yet
> sure which place is better (I haven't yet decided whether it's better
> to sign-extend earlier or later :-) ). Also, who knows what
> needs other processors will have...
I think this is ok: the code generator (STG->Cmm) will need to do the
promotion of C call arguments. You'll see expressions like this: for a
call to a function "f" which takes a 16-bit signed argument:
CmmCall (Left "f") CCallConv [r]
[CmmMachOp (MO_S_Conv I16 I32) [...]]
i.e. the sign extension is explicit. On many architecture the code
generator can generate a single sign-extending load when it sees a sign
extension around a CmmLoad (eg. see the x86 code gen). Similarly for
the unsigned I16->I32 conversion.
I think the lack of signedness in MachRep is a win, it's certainly made
things simpler for the x86 code gen, and the backend is now much more
honest about the sizes of things.
More information about the Cvs-ghc