Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site unc.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!houxm!whuxl!whuxlm!akgua!mcnc!unc!gda From: gda@unc.UUCP (Greg Abram) Newsgroups: net.arch,net.micro.16k,net.micro.68k Subject: Re: 24 bit vs. 32 bit address space Message-ID: <172@unc.UUCP> Date: Fri, 8-Mar-85 09:22:55 EST Article-I.D.: unc.172 Posted: Fri Mar 8 09:22:55 1985 Date-Received: Mon, 11-Mar-85 11:28:23 EST References: <983@watdcsu.UUCP> <2385@nsc.UUCP> <730@amdcad.UUCP> Reply-To: gda@unc.UUCP (Greg Abram) Organization: CS Dept., U. of N. Carolina at Chapel Hill Lines: 17 Xref: watmath net.arch:946 net.micro.16k:267 net.micro.68k:649 Summary: >> What I do object to is simply saying that one should be careful >> not to use the upper byte of an address. >> >> On the 68000, 68010, 68012, 32016, and 32032 the chip should be designed >> to provide some sort of trap if a memory address was invalid... > >I think this is going a bit far. There are quite valid reasons for using >the un-used top eight bits on a 68000. The only gain from the error check >would be the detection of programs which unintentionally use the top bits, >which looks like it must be fairly rare to me. Well, at least one more: Transportability, if and when the machine is augmented to allow more than 24 bits of address. Ask the IBM people about this; played havoc with their software when they went to the longer addresses. I have in fact heard an original 360 architect label their failure to trap this a great mistake. And the failure (I think) of a Load Address instruction to zip out the upper 8 bits.