Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!shelby!polya!Neon.Stanford.EDU!max From: max@Neon.Stanford.EDU (Max Hailperin) Newsgroups: comp.lang.scheme.c Subject: UNSIGNED_SHIFT wierdness on DecStation 3100 with 6.1.2 Message-ID: <11610@polya.Stanford.EDU> Date: 31 Aug 89 16:49:18 GMT Sender: USENET News System Reply-To: max@Neon.Stanford.EDU (Max Hailperin) Organization: Stanford University, Computer Science Dept. Lines: 31 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.