Changes between Version 5 and Version 6 of InternalsMiscellany

May 10, 2009, 2:07:37 PM (10 years ago)

More stuff


  • InternalsMiscellany

    v5 v6  
    12= Assorted internals tidbits =
    3536  * x86: the FS register contains a pointer to the current TCR.
    3637  * x86: the TCR is defined in lisp-kernel/x86-constants32.h (struct tcr)
     39=== Memory allocation ===
     40Explanation by gb:
     42  Memory allocation is per-thread; a thread conses within a private "chunk" of memory by decrementing a per-thread pointer that starts at the high end of its current chunk and comparing that pointer to the low end of the chunk; if the pointer's above the limit, we use the memory, otherwise we need a new chunk:
     45   [21]    (subl ($ 7) (@ (% fs) 132))  ; subtract the size of a cons - the tag of a
     47                                        ; from the per-thread pointer
     48   [30]    (movl (@ (% fs) 132) (% temp0)) ; load the per-thread pointer into a temp
     50   [38]    (cmpl (@ (% fs) 136) (% temp0)) ; compare to limit
     51   [46]    (ja L50)                        ; continue if above limit
     52   [48]    (uuo-alloc)                     ; trap, get a new chunk
     54   [50]    (andb ($ 248) (@ (% fs) 132))   ; clear tag bits in thread-local storage
     55   [59]    (movl (% arg_y) (@ 3 (% temp0))) ; store car
     56   [62]    (movl (% arg_z) (@ -1 (% temp0))) ; store cdr
     57   [65]    (movl (% temp0) (% arg_z))      ; return cons cell
     60== Exception handling ==
     61The manual has some information on this. Here's some more.
     63=== UUOs (by gb) ===
     65==== Origin ====
     66On the DEC PDP-10, the acronym UUO stood for "Unimplemented User Operation"; UUOs were used to invoke system services and/or to invoke what we'd think of as exception handlers. [...] As it's used in CCL, the term just means "an illegal instruction that'll ultimately cause a lisp-aware handler function to be called."
     68==== Implementation details ====
     69Executing an "int $n" (#xcd n) instruction transfers control to an
     70entry insome (incredibly complex and baroque) table of handlers
     71maintained by the chip.  The OS might use a few entries in this table
     72to implement system calls (though modern x86 CPUs often have faster
     73ways of doing system calls), and some entries are reserved for hardware-
     74related interrupts.
     76Trying to execute an "int $n" instruction that doesn't have a defined
     77entry in this table causes a General Protection Fault, and this
     78eventually causes (on Unix) a signal to be raised.  Exactly what
     79signal depends on the OS; there's a macro called SIGNUM_FOR_INTN_TRAP
     80defined conditionally in ccl/lisp-kernel/x86-exceptions.h that defines
     81this.  As you can see, it's generally overloaded on SIGBUS or SIGSEGV,
     82which usually indicates an addressing exception (yes, SIGILL would
     83make more sense, but since it involves a GP fault an undefined "int
     84$n" winds up taking the same path as a memory protection fault) and
     85we need to look at other arguments to the signal handler (as defined
     86by the IS_MAYBE_INT_TRAP macro: if IS_MAYBE_INT_TRAP is true, we believe
     87that we can look at the the byte that the PC in the signal context is
     88pointing to to see if it's #xcd; if not, the SIGSEGV or SIGBUS might
     89have been caused by trying to execute code at an unmapped address.)
     91We also use "ud2a" instructions (followed by a byte or more of data)
     92for similar purposes, but "int $n" is generally shorter; illegal
     93instructions that use the ud2a opcode (which generally -does- raise
     94SIGILL when executed) are sometimes called "xuuos" (eXtended UUOs).
     96Once in a while (when doing a port to a new OS), we've found that the
     97OS uses an interrupt that we've previously considered free for our
     98use, and have had to do things differently (reassign UUOs or avoid
     99emitting conflicting ones.)  I suppose that that could happen if we
     100ported to some other OS (NetBSD ?), but it's unlikely that x8632 OSes
     101will invoke new functionality via "int $n" (since other means of doing
     102system calls are generally faster/better.)  See the comment in x86-asm.lisp:
     104;;; DON'T use #xcd8x: doing so will make Mach angry and confused.