-
Julian Seward authored
Add just enough infrastructure to the NCG that it can deal with simple 64-bit code on 32-bit platforms. Main changes are: * Addition of a simple 64-bit instruction selection fn iselExpr64 to MachCode. This generates code for a 64-bit value and places the results into two virtual registers, related thusly: * Add a new type VRegUnique, which is used to label Stix virtual registers. This type used to be a plain Unique, but that forces the assumption that each Abstract-C level C temporary corresponds to exactly one Stix virtual register, which is untrue when the C temporary is 64-bit sized on a 32-bit machine. In the new scheme, the Unique for the C temporary can turn into two related VRegUniques, related by having the same embedded unique. * Made a start on 'target metrics' by adding ncg_target_is_32bits to the end of Stix.lhs. * Cleaned up numerous other gruesomenesses in the NCG which never came to light before now. Got rid of MachMisc.sizeOf, which doesn't make sense in a 64-bit setting, and replaced it by calls to PrimRep.getPrimRepArrayElemSize, which, as far as I'm concerned, is the definitive answer to the questio `How Big Is This PrimRep Really?' Result: on x86-linux, at least, you can now compile the Entire Prelude with -fasm! At this stage I cannot claim that the resulting code is correct, but it's a start.
0d1a15fd