Nikodemus Siivola writes:
> Cool stuff! Looking at the patch very quickly, am I reading it correctly
> when I think that EBX is reserved only for Win32+threads?
Not quite. There's a combination of *features* which will use EBX for TLS
on Linux (or any other 32-bit x86 platform, not tested) as well (or just
reserve EBX for use for something else if you need it). Otherwise, yes.
It's lousy with conditionals, but it leaves almost everything the way it
found it if you don't enable them. I'd say it might come in handy if we run
into an x86 platform which doesn't let you use a segment register for TLS
and doesn't have quite as conveniently hijackable an exception-handling
mechanism as windows does, but it doesn't seem quite likely at this point.
> Also: at one point you pursued hanging TLS data onto the exception
> handler chain. I take that this is no longer on the agenda?
Actually, I'm thinking I might work up a tree with that approach later this
week, just to see how it goes. Certainly would be a smaller patch, due to
not having to move everything away from EBX. Basic impact would be most of
src/compiler/x86/cell.lisp, a touch in src/compiler/x86/nlx.lisp, covering
the FIXME in uwp-seh-handler or whatever it's called in
src/assembly/x86/assem-rtns.lisp, src/compiler/generic/objdef.lisp, and, of
course, src/runtime/x86-assem.S, instead of most of what's covered by
#!+x86-two-arg-passing-regs, #!+x86-reserve-ebx and #!+x86-ebx-threads now.
Wouldn't work on Linux, though, which would make -testing- it a little more
of a pain, and is part of why I did it this way first (I already had most of
the ebx-threads stuff working with an older SBCL).
> -- Nikodemus