Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!cbosgd!ihnp4!zehntel!hplabs!hpda!fortune!amdcad!amd!pesnta!qumix!qubix!sun!gnu From: gnu@sun.uucp (John Gilmore) Newsgroups: net.micro.mac Subject: Re: high byte of address question Message-ID: <1960@sun.uucp> Date: Mon, 21-Jan-85 01:33:01 EST Article-I.D.: sun.1960 Posted: Mon Jan 21 01:33:01 1985 Date-Received: Thu, 24-Jan-85 07:06:26 EST References: <224@ucbopal.CC.Berkeley.ARPA> <130@redwood.UUCP> Organization: Sun Microsystems, Inc. Lines: 30 I'm in total agreement with Rob Warnock on the use of upper bytes of 32-bit addresses. 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 it's not part of the instruction set. 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 data-cache based machine that doesn't deal well with aliasing, it could also cause incorrect results. This whole topic has previously been discussed in net.micro.68k. A few comments on the SummacC relocation stuff (without knowing it personally): 1. It was probably expedient and it certainly worked. 2. It was easier than changing the C compiler. 3. It is not portable to larger machines. 4. There will be Mac-class machines with >16MB within 5 years. 5. There's nothing as permanent as a temporary kludge. 6. At least they could have cleared the high bytes after doing the relocation, so the running program would not know the difference. A side comment, the 'LEA' instruction, like all address arithmetic in the 68000 family, operates on a full 32 bits. In the 360, the equivalent "LA" instruction cleared the high byte; this was a major problem ten years later.