On Fri, Mar 15, 2002 at 08:03:03AM +0100, Martin Atzmueller wrote:
> The attached patch does connect the definition of SAP-INT and
> the one of the primitive type used in the definition of the vops.
Thank you, but I decided not to merge the patch, for three classes of
First, as you quoted, I wrote
> > It would be reasonable to use SAP-INT-TYPE in the definition of the
> > VOP, but it's not used that way currently.
But that was because I had forgotten that the "type" arguments used
in VOP definitions are "primitive types" which aren't the same thing
as Lisp types, even though they share some features.
> However, it doesn't use the definition of SAP-INT in the vops, because
> this didn't work.
Forgetting the distinction between primitive types and ANSI CL types,
I thought the change would be a trivial substitution, but it's not.
Given the amount of work involved in constructing SAP-INT-PRIMITIVE
(as in your code for MAKE-SAP-INT-TYPESPEC) I'd now say that it's not
worth it, and probably we should leave things alone. The main reason
not to leave things alone would be if there's some existing Lisp-level
type (SB!VM::WORD or SB!VM::PRIMITIVE-UNSIGNED-NUM or something) which
corresponds to the new SAP-INT type and also to the old primitive type
UNSIGNED-NUM, in which case it might make sense to get rid of the
SAP-INT type in favor of SB!VM::WORD or whatever.
Second, I had some quibbles with the execution of the patch.
I never figured out why MAKE-SAP-INT-TYPESPEC was a macro instead of
I don't think it makes much sense to go out of our way to define the
Lisp type SAP-INT as a type like the one you label with [*],
(OR (UNSIGNED-BYTE 32) (UNSIGNED-BYTE 31) (UNSIGNED-BYTE 29))
because that Lisp type is equivalent to
and the SBCL implementation of the Lisp type system understands this
equivalence pretty well and imposes it immediately, when converting
from type specifier to CTYPE object:
(sb-kernel:specifier-type '(OR (UNSIGNED-BYTE 32)
=> #<SB-KERNEL:NUMERIC-TYPE (UNSIGNED-BYTE 32)>
So we'd go to a fair amount of trouble and confusion to construct a
complex type expression to use for SAP-INT, when it's trivially
equivalent to a much simpler type.
Finally, I'm very reluctant to do things which change the interface of
VOPs in X86 without making corresponding changes in the corresponding
VOPs in the other backends. You changed the :ARG-TYPES in the X86
SAP-INT VOP, but not in the SAP-INT VOPs in the other backends. If I
were merging the patch, I could try to tweak the other backends to
match, but it's not immediately obvious how to get it right for the
Alpha, given the mismatch between 64-bit machine addresses and 32-bit
Lisp tagged words.
In general, if you (or for that matter anyone else) have changes which
affect different CPU architectures differently, I encourage you to at
least make a draft of your changes for the other architectures. Even
if you can't test them, it will probably be helpful. (I did something
like this with the recent stack overflow checking code. I can't test
the stack-grows-upward case since I only have X86 machines, but at
least I tried to address the problem.) Or failing that, explicitly
bring up the omission on the mailing list and try either to get help
porting your change to the other architectures, or consensus that it's
OK to put in the change without bringing the other architectures up to
date on it immediately.
(Actually, you did write
> I've only tested this on X86, but I've tried to provide for the
> correct values in parms.lisp for sparc and alpha.
> E.g. on Alpha, SAP-INT should now be
> (OR (UNSIGNED-BYTE 64) (UNSIGNED-BYTE 63) (UNSIGNED-BYTE 29))
> and on Sparc, it should be the same as on X86.
> Could someone test this on Alpha and/or Sparc?
so maybe you just skipped the VOP changes accidentally, in which
case the reminder about the principle might be irrelevant.)
William Harold Newman <william.newman@...>
"Of course, if I dig my house foundations by biting the earth while banging
my own head with a spade, then upgrading to mechanical digger maybe won't
help..." -- Graham Perkins <gperkins@...> in comp.lang.eiffel
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C