max@Neon.Stanford.EDU (Max Hailperin) (08/31/89)
I recently tried building CScheme 6.1.2 on a pmax (DecStation 3100). When
I defined UNSIGNED_SHIFT, scheme would die with an illegal type code in
gc_loop. Not defining this symbol made the problem go away. This happened
repeatably, though by changing what I did in scheme (from the usual cold-load
stuff) I could change when the illegal type code appeared and what it was.
In no case did the illegal type code have it's high-order (sign) bit on.
This is highly peculiar, for at least the following reasons:
1) UNSIGNED_SHIFT works fine on a mipsfair (DecServer 5400), which should
be essentially the same.
2) Wsize tells me that UNSIGNED_SHIFT should work.
3) The 7.0.0 beta release comes with a pmax configuration, complete with
UNSIGNED_SHIFT.
4) The only thing that UNSIGNED_SHIFT controlls is whether the shifted-down
type code gets masked with 0xFF in case it was sign-extended. However,
none of the type codes currently in use has the high-order bit on (since
fewer than 128 are defined). Thus, it should be irrelevant whether
sign extension happens or not. I confirmed this by (on the mipsfair)
changing the OBJECT_TYPE macro to explicitly force sign extension, by
casting the pointer to a *signed* long before shifting. Sure enough, it
still works fine.
Although scheme is now running, I am troubled by this both because I may
be paying a performance penalty for masking and also because anything that is
this peculiar may be hiding a bigger problem.
So, at long last, my question: has anyone else seen anything like this, ever?
What turned out to be the cause?
Thanks very much.