[GHC] #8287: exploring calling convention changes and related engineering for 7.10

[GHC]

#8287: exploring calling convention changes and related engineering for 7.10
-------------------------------------+------------------------------------
        Reporter:  carter            |            Owner:
            Type:  task              |           Status:  new
        Priority:  high              |        Milestone:  7.10.1
       Component:  Compiler          |          Version:  7.6.3
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Rocket Science
       Test Case:                    |       Blocked By:  8299
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by rwbarton):

 I did a port of ghc to "real x32" with the following characteristics:

 * produces x32 executables (these are 32-bit ELF files containing x86-64
 object code and relocations, that use the x32 versions of system calls)
 * in particular, the entire address space of the process lives below 4GB
 * executables (and object files loaded by ghci) must be mapped below 2GB
 to avoid over/underflow in x86-64 rip-relative addressing, but the heap
 can use the full remaining space below 4GB (untested)
 * dynamic Haskell libraries are not yet implemented
 * Int is 32 bits, as is Addr#
 * heap layout is just like on i386: everything on the heap is 4-byte
 aligned and pointer tagging uses two bits
 * now with integer-gmp, using 64-bit limbs!
 * features a fairly small number of bizarre testsuite segfaults and other
 errors

 Effectively, it is like i386, but faster (**much** faster when doing large
 Integer computations due to being able to do 64-bit arithmetic, but still
 often faster when not), and with more crashes (but those could presumably
 be sorted out) and a more awkward system library situation (there is no
 libx32gmp10 package yet on Ubuntu, so I have to set LD_LIBRARY_PATH when
 running ghc's x32 executables).

 I attached nofib results comparing amd64 vs. x32 and i686 vs. x32; x32 is
 about 15% faster on average than either.

 I call this "real x32" because the compiler produces actual x32
 executables. One could imagine a rather different set of design choices:

 * produces x86-64 executables
 * no address space limitations
 * Int is 64 bits, as is Addr#
 * heap layout is just like on x86-64 (in particular, closures are 8-byte
 aligned) **except**: all pointers to other closures are stored as 4 bytes
 rather than 8 (possibly using "compressed references", e.g., address an 8
 GB heap by storing a pointer to a closure at address `p` as `p >> 1`, with
 the two lowest bits used for pointer tagging)

 This would be less time-efficient than "real x32", but still give much of
 the space savings, while allowing a larger heap. Good for computations
 that need between 1 and 2 billion pointers' worth of storage, like
 compiling modestly complex Agda programs.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8287#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler