[ The type-vop stuff did magically start working when I added the
appropriate line - or seems to have done at least. I guess I should
have read the def-type-vop definition before asking ]
Current alpha progress: it's back where it was before I decided to
update from 0.6.5 to CVS, but now it has new-style signals code.
It's using the old two-space copying GC, which creates a certain
amount of confusion (in my mind at least) as to exactly what's going
on: it would probably be useful if you could avoid any further
squash-the-second-dynamic-space work until I figure out how it's
supposed to work. It's not actually GCing _at all_ right now, so it
runs out of memory fairly quickly in warm load (like, halfway through
the second PCL file) because some fool built it with a 64Mb heap.
But with any luck it will be safe to turn GC on after this rebuild ...
William Harold Newman <william.newman@...> writes:
> On Fri, Jan 26, 2001 at 12:40:35AM +0000, Daniel Barlow wrote:
> > My 2 cents: this is Unix. Neat taxonomies don't work when you have to
> > model the duck-billed platypus.
> I can appreciate this more fully after redoing the signals code for
> the OpenBSD port. The underlying developmental taxonomy must resemble
> the primordial orgy around the roots of the current consensus
> evolutionary tree: "and the mitochondria were absorbed, and begat the
> borogoves, then verily retrovirii from the heathen archaebacteria did
> lie with them in the night, and from them came chromocytin J, but the
> other genes they did reject, except perhaps wherever the heck those
> other transposons came from.."
I've been thinking about this since, and I wonder if the more-nearly
Right Thing would be to do autoconf-style feature tests instead of
basing everything on the features that we _think_ the system has on
the basis of what uname says. Of course, it would need to be
overridable, because autoconf doesn't exactly get it right either.
Incidentally, code/signal.lisp contains a whole bunch more constants
at least some of which are bogus for Linux/Alpha. I'd far rather
write a little C program that generates Lisp than I would fix it by
hand, though - that's what I did for the dev-t, off-t etc in the stat
> > native_cpu_word is exactly what u32 is _not_. u32 is a 32 bit integer
> If so, the current usage doesn't seem very consistent to me. That's no
Yes, I see your point. I can assure you that u32 is definitely a 32
bit quantity on the Alpha just as it is everywhere else, but the
intent behind declarations is sometimes "this must be 32 bits" and
sometims "this is a pointer that we're casting to an integer (but it
happens that all our printf format strings are sized to assume it's a
To be honest, I'd rather rewrite the latter to cope properly with
pointers that have stuff in the top 32 bits: even if Lisp is stuck in
the low 2Gb, SAPs could be pointing anywhere.
(Signal handling still needs checking in this respect. If our signal
handler gets called with a ucontext pointing above 2Gb, does it still
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources