edmoy@ucbopal.CC.Berkeley.ARPA (01/16/85)
I've been playing around with sumacc C programming and had to do a little programming in assembly language to handle some special cases. I've noticed that the high byte of an address (the 68000 only uses the bottom 24 bits) is used alot in the Mac for special purposes. However, even when I do a Load Effective Address (lea) command, the high byte is sometimes non-zero and I have to clear it out. Does anyone know if the hardware in the Mac uses that high byte for something? Edward Moy Computing Services University of California Berkeley, CA 94720 edmoy@ucbopal ucbvax!ucbopal!edmoy
rpw3@redwood.UUCP (Rob Warnock) (01/17/85)
+--------------- | I've been playing around with sumacc C programming and had to do a little | programming in assembly language to handle some special cases. I've | noticed that the high byte of an address (the 68000 only uses the bottom | 24 bits) is used alot in the Mac for special purposes. However, even when | I do a Load Effective Address (lea) command, the high byte is sometimes | non-zero and I have to clear it out. Does anyone know if the hardware in | the Mac uses that high byte for something? | Edward Moy | edmoy@ucbopal | ucbvax!ucbopal!edmoy +--------------- <Anguished Flame> NO, NO! SAY IT ISN'T SO! If they have done this, it's going to be a major disaster when they go to a 68020, where those bits are significant. Don't we learn ANYTHING from our mistakes in this industry? Wasn't it enough that all those 360 programs had to be re-written for 370s???????? I don't expect the front line troops to remember (they're too young in many cases), but doesn't Management ever come to design reviews? Using "spare" bits for cutesy tags is simply too dangerous to consider (unless the usage is tightly confined to a few SMALL modules you plan on replacing in the next generation). ((...and even then, clever users will discover them, use them, and be greatly upset when you take them away...)) Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
guy@rlgvax.UUCP (Guy Harris) (01/18/85)
> I've noticed that the high byte of an address (the 68000 only uses the bottom > 24 bits) is used alot in the Mac for special purposes. Well, let's hope that no future Mac software ever desires >16MB of address space (which will probably be true for quite a while) - a certain big blue computer company started doing this ~20 years ago on a certain line of their computers; now that they're running out of address space, they had to introduce a mode bit into their machines, and a whole new version of the OS to handle it, and the trade tabloids are *still* talking about the hassles of converting to MVS/XA. The 68012 and 68020 don't have mode bits, although if the upper 8 bits don't do anything other than leave the chip on appropriate pins, this can be handled in off-chip logic (i.e., run those lines to /dev/null). Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
jwp@utah-cs.UUCP (John W Peterson) (01/18/85)
The reason the high byte gets trashed in SumacC code has nothing to do with the Mac hardware, but instead is a side-effect of the Sumacc relocation scheme. Unlike the Lisa/Workshop Pascal compiler, Sumacc does not generate position independant code. Since C compiler and loader have no way of knowing where the code will be loaded (this is decided dynamicly by the Mac memory manager), addresses are resolved every time a Sumacc program starts up. To resolve addresses at startup time, Sumacc uses a "clever" scheme of run-length encoding relocation info into the high order byte of addresses that need relocating. The gory details of how this works can be found by looking in crtmac.s in the Sumacc lib/ subdirectory.
edmoy@ucbopal.CC.Berkeley.ARPA (01/20/85)
>The reason the high byte gets trashed in SumacC code has nothing to do >with the Mac hardware, but instead is a side-effect of the Sumacc >relocation scheme. You are quite correct about sumacc method, which I am aware of. My question had to do with the 68000 Load Effective Address (lea) instruction itself. When I wrote some assembly language code to support my C code, it seemed that the lea instruction itself was putting something in the high byte. So after I did a lea to an address register and then moved it to a data register, I found I had to clear the high byte to use it the way I wanted or otherwise the high byte would screw things up. Edward Moy Computing Services University of California Berkeley, CA 94720 edmoy@ucbopal.ARPA ucbvax!ucbopal!edmoy
gnu@sun.uucp (John Gilmore) (01/21/85)
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.
tim@callan.UUCP (Tim Smith) (01/23/85)
In article <130@redwood.UUCP> rpw3@redwood.UUCP (Rob Warnock) writes: >+--------------- >| programming in assembly language to handle some special cases. I've >| noticed that the high byte of an address (the 68000 only uses the bottom >| 24 bits) is used alot in the Mac for special purposes. However, even when >+--------------- >NO, NO! SAY IT ISN'T SO! If they have done this, it's going to be a major >disaster when they go to a 68020, where those bits are significant. Don't They could always just leave the upper eight address lines unhooked on the 68020, thereby staying compatible! :-) -- Duty Now for the Future Tim Smith ihnp4!wlbr!callan!tim or ihnp4!cithep!tim