gnu@l5.uucp (John Gilmore) (12/03/85)
This issue came up in January in net.micro.mac; now that we have a new crop of people writing for a new crop of machines, let me reiterate what Dale Luck (of Amiga), Rob Warnock (ex of Fortune, now independent), and I (ex of Sun, now independent) have been saying: "Don't use the top byte of a 32-bit address as anything but a piece of the address. I saw the IBM 360 folks get burned by it and don't intend to let any enterprise I'm associated with do it again. This kind of usage does NOT automatically break when you install a 68020 (the way it did in the IBM systems), since 24-bit addressing is not part of the instruction set (it was defined as 32 from the start). Instead, it breaks if you ever hook up more than 24 address wires to any 68000 family member (eg 68012, 68020) that brings these bits out to pins. It DOES decrease cache performance in the 68020, since the same piece of code can be accessed at addresses which the cache thinks are different. In a machine with a data cache that doesn't deal well with aliasing, it could also cause incorrect results. (Data caches are often used to get maximum speed out of e.g. 20MHz 68020s)." This whole topic has previously been discussed in net.micro.68k. The CSA/Amiga board is a great example: > >Well, the 68020 puts out all 32 bits. But does the system use them? If > >it doesn't, then it should be ok to play games with these bits. > CSA's amiga/68020 board has 256k of memory. It was configured to be > at 7f000000-7f03ffff. This caused a hickup in one of our libraries since > it was internally using some of the 8msb as some flags. That got changed > REAL FAST. We advise all those that wish to write software that is > hoped to run on compatible but more powerful products to assume that all > pointers are 32 bits. Sun-3's check to make sure you aren't using any of those bits, so that when larger models come along (currently 256MB address space, but there are four whole unused bits up there!) any software that now runs won't break. Happily, few folks writing Sun-2 software had screwed this up, so much of it runs on Sun-3's without trouble.
radford@calgary.UUCP (Radford Neal) (12/06/85)
> This issue came up in January in net.micro.mac; now that we have a > new crop of people writing for a new crop of machines, let me reiterate > what Dale Luck (of Amiga), Rob Warnock (ex of Fortune, now independent), > and I (ex of Sun, now independent) have been saying: > > "Don't use the top byte of a 32-bit address as anything but a piece of > the address..." I don't want to rekindle the whole discussion, but I thought I'd put in the other side of the argument, at least as it existed in net.arch: "Use the top byte of a 68000 address for something else (like the type of the object pointed to) if this is sufficiently important to your application that it's worth sacrificing expandability of memory past 16MB. Don't be surprised if this isn't very portable to other 68000 systems." I don't advocate this usage just to save 10% on data space for your program. It's more for something like a Lisp interpreter where tag bits can greatly enhance performance and implementation simplicity. You ought to be prepared to think of the processor, not as a 68000, but as some new micro with a 16MB address space and nifty typed pointers. Radford Neal
peterson@utah-cs.UUCP (John W Peterson) (12/11/85)
When we originally implemented PSL (Portable Standard Lisp) on the Apollo's, we too saw that 16M machine with the "nifty typed pointers". Boy, did we get screwed two years later when the 010's came out. It took YEARS to track down all of the places where the high order byte contained a tag when it was used as an address. On the particular machines where this happened, it would only fail if a page fault actually occured - thus the bugs were not repeatable and very difficult to isolate. Moral - don't do it.
tim@ism780c.UUCP (Tim Smith) (12/13/85)
[ Discussion is about using upper byte of an address to contain data] Note that I am NOT advocating immoral use of the high byte. I am just curious... In article <3570@utah-cs.UUCP> peterson@utah-cs.UUCP (John W Peterson) writes: >Boy, did we get screwed two years later when the 010's came out. It >took YEARS to track down all of the places where the high order byte >contained a tag when it was used as an address. On the particular >machines where this happened, it would only fail if a page fault >actually occured - thus the bugs were not repeatable and very difficult >to isolate. > I don't understand. The 68010 still only has a 24 bit address bus, so those bits shouldn't matter. The page fault handler has to mask them off before deciding what virtual address to page in, but that should be an easy thing to do. Where else does it not work on a 68010 but work on a 68000? -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim