#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