[Openmcl-devel] Couple Impl questions

[Gary Byers]

On Fri, 2 Apr 2010, Jon S. Anthony wrote:

> Hi,
>
> I've tried finding where things like .SPbuiltin-aref1 and such are
> implemented.  I know about the definitions in (for X86xx)
> x86..-arch.lisp, and see that this produces a set of structs, but not
> sure where the code for them is created/exists.  I thought they may be
> in the C code, but I didn't find them there (but I could certainly have
> missed it somehow).  Thanks in advance for any pointers.

"subprimitives" are assembly-language runtime routines; their source
is in "ccl:lisp-kernel;*spentry*.s".  (There's a single file for ppc32/ppc64,
with the differences between those architectures hidden by macrology; there
are separate "x86-spentry32.s" and "x86-spentry64.s" files.)  Confusingly,
there are also some assembly language source files with the string "subprims"
in their names; they generally just contain thread startup/shutdown code
these days.

The actual subprimitives are called via a jump table of some sort that
resides at a known address; the lisp-side code in the *arch.lisp files
basically just builds a model of that jump table.  (The jump table itself
is defined in ccl/lisp-kernel/*spjump*.s, and the lisp model should match
that exactly.)

The assembler source files are preprocessed by m4 and make fairly heavy
use of m4 macros (see m4macros.m4 and *macros.s); just about every line
of code is a "call" to an m4 macro named '__', whose sole purpose is
to generate line number information (for GDB) when this can't be done
automatically.

>
> Second question is simpler: are ivector elements always stored unboxed?

Yes.  As Matt noted, it'd be reasonable to store fixnums and characters
as boxed lisp objects in vectors specialized to those types.  Boxing
and unboxing fixnums and characters isn't hugely expensive but isn't
entirely free either; I don't know whether or not this adds up to being
a compelling reason to change, but it's likely worth thinking about.
(There's a little bit of code somewhere that BLTs character codes between
lisp strings and foreign "pointers to UTF-32-in-the-right-endianness", but
there's not enough of that code and it's not enough of a bottleneck to make
keeping the status quo particularly compelling, either.)

>
> /Jon
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>