Re:

[William.Lott@CS.CMU.EDU]

It appears that SysV does not have the signal features that we make
extensive use of.  Specifically, the sigcontext structure was not
defined in the include file you sent me.  I've sent a query off to a
friend of mine who has much more experience with SysV, and I'll pass
along any info as I get it.  In the mean time, if you could send me a
copy of the ``signal'' man page, it might indicate whether or not it's
possible to do what we are trying to do.

Klaus Daessler <ztivax!dae@relay.EU.net> writes:
> 1) We don't have a suitable Lisp to run genesis.
>    So we are trying to use the kernel.core directly. Later on we want
>    to run genesis in this first system.
>    We are now analyzing the core file.
>    We "relocated" the objects due to the space problems of our swapping
>    system.
>    We disassembled the code vectors and found out, that only assembler routines
>    are addressed by the J and JAl instructions.

There are also quite a few places where pointers to random C symbols
exist.  As most of these exist as a LUI/ADDI instruction pair, they
will be very hard to distinguish from other random constants.

>    There are quiet a lot of BREAK instructions inside the code. For which pur-
>    pose are they used ? Are they used for error exits ? Can you tell us some-
>    thing about the memory word immediately following such a BREAK instruction?

The break instruction is used for three different things.  The data
field in the break instruction is used to distinguish them.  The most
common is signaling low-level errors.  There are two different flavors
of errors, regular (10) and continuable (11).  The bytes following the
break instruction are used to indicate what the error was and what
registers hold the operands.  (``Continuable'' error breaks are always
in a branch delay slot, so the data never gets executed.)

The second most common use of the break instruction is to implement
our ``pseudo-atomic'' construct.  When we want to execute a sequence
of code atomically, but we don't wish to pay the overhead of a couple
of system calls to shut out signals, we make the code pseudo-atomic.
When we enter a pseudo-atomic region, we set a flag.  If we take a
signal while that flag is set, we set a different flag and return
without handing the signal.  At the end of the pseudo-atomic region,
we clear the first flag and check the second.  If the second is set,
we hit the break instruction, which causes a new signal to be
delivered.  The handler for that signal notes that we are trying to
handle a defered signal, and calls the handler for the original
signal.

The last use of the break instruction is to halt the entire lisp
system.  This is only done where there is no other choice (e.g. the IO
system is failing, so we can't even print out the error message). 

>    Do you see any problem (beside those you already wrote about) to get the
>    kernel.core running ?

Many.  The offsets of many C variables/functions are linked into the
core at genesis time, and there is no easy way to distinguish them
from random constants.  You would have to look for any place where any
of the values in the orignal ldb.map occur, and change them to the
corresponding value from your ldb.map.

There are two other possible approaches that would be much easier.
You could port genesis to some other lisp you already have running.
This would not be very hard.  Genesis does use MACH routines to
allocate and deallocate memory, but it would be easy to change it to
use regular lisp vectors.

Or you could just have us run genesis on one of our machines for you.
All you would have to do would be to supply us with your version of
ldb.map.

> 2)
> > So if you are staying with a processor that we already have a compiler
> > backend for, almost all of the work is in fixing ldb to work with your
> > operating system.  The exceptions are the few places operating system
> > dependencies actually exist in the lisp code.  I can only think of one
> > off hand, and it would take about 15 minutes to fix.
> 
>    Can you give us some hints for the "few places of operating system
>    dependencies" ?

Oops, I guess I should have been more specific in the first place.  In
the file .../code/alieneval.lisp there are a few routines called
something like allocate-system-memory and deallocate-system-memory.
They try to call vm_allocate and vm_deallocate (MACH routines)
directly.  If you wrote some C functions that took the same number of
args as vm_allocate and vm_deallocate you wouldn't have to change the
lisp code.

> 3) We want to give you some more details about our question concerning the
>    scope of declarations (see CLtL2, 9.1 Declaration Syntax, page 219):
> 
>    ... An important change from the first edition is that "initialization"
>    forms are specifically not included as part of the body ...
> 
>    Did you already change it ?

I don't know, Rob will have to answer this one.

> 4) Scott Fahlman wrote , PCL would be ported to the Phyton-compiler.
>    Is this work done and what PCL - version do you take? (We have some  
>    experience with the may-day - version.) 

I'm not sure, but I believe it's the latest version of PCL that we
have up and running.  We are going to be working on a native version
of CLOS that should be much better than PCL.