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.