SBCL Internals The pages on this CLiki-driven site can be edited by anybody at any time. No warranty of any kind can therefore be made; any implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed

The work falls into two halves: general changes to SBCL to give it a 64 bit lispobj, and the AMD64 backend itself. Some work has already been done on the former, using Alpha (because the backend exists, and access to the hardware is easy to arrange) to test. Issues identified so far -

• lispobj becomes 64 bits wide, and is aligned on 16-byte not 8 byte boundaries. This gives us an extra lowtag bit, so preserving the current pun that a naked machine-word byte offset (e.g. into a structure or array) has the same bit pattern as a fixnum whose value is the number of lispobj-sized words in the same offset. This assumption is made all over the place already.
  Fixnums become 61 bits wide.
  • Two lowtags are added for other-immediate objects, so that the widetag?s still fit in an 8 bit field.
  • There are six tags we're not using currently
  This is done. For the curious, lowtags are currently

  #define EVEN_FIXNUM_LOWTAG 0 /* 0x0 */
  #define INSTANCE_POINTER_LOWTAG 1 /* 0x1 */
  #define OTHER_IMMEDIATE_0_LOWTAG 2 /* 0x2 */
  #define OTHER_IMMEDIATE_1_LOWTAG 6 /* 0x6 */
  #define LIST_POINTER_LOWTAG 7 /* 0x7 */
  #define ODD_FIXNUM_LOWTAG 8 /* 0x8 */
  #define FUN_POINTER_LOWTAG 9 /* 0x9 */
  #define OTHER_IMMEDIATE_2_LOWTAG 10 /* 0xA */
  #define OTHER_IMMEDIATE_3_LOWTAG 14 /* 0xE */
  #define OTHER_POINTER_LOWTAG 15 /* 0xF */
  

• fops, cold-fops and genesis need reviewing and possibly changing. This is done to the extent that we can dump a core that the runtime starts executing. There may still be trouble with fixups

• type system changes: fixnum size, specialized arrays for ({un,}signed-byte 64) and similar objects. Works in outline, but arithmetic all needs review/rewrite: if fixnum arithmetic is not broken, bignum arithmetic certainly is. Other bugs will appear as surprises at the appropriate time

• foreign code: 64 bit saps (alpha has already) and alien support. Unix interface may also be affected.

• bignum code all needs revisiting: see above

• allocation and gencgc changes. It would be appropriate to use gencgc, simply because it makes it much easier to add thread support later. gencgc is mostly precise - despite the c in its name - and if we're going to partition the registers and use separate C and control stacks, we can actually drive it in a totally precise fashion. (We may not want to: the ability to pin pages makes some kinds of foreign call a lot simpler)

• what about sxhash and so forth: poss. relevant to caches etc

• New backend, probably based on a non-x86 (i.e. register-using) port. This means using registers for alloc-tn? and pseudo-atomic, precise GC, separate control/C stacks, etc
  • For comparison, there are 27 files in compiler/alpha
  • We expect the x86 instructions, assembler, and disassembler to be mostly still usable
  • Some of the x86 vops may still be applicable

• It would be nice to make 32-bit floats (still single-floats I assume) immediate, wouldn't it?

This page is linked from: CPU   x86  

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively