Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site petrus.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!petrus!hammond From: hammond@petrus.UUCP Newsgroups: net.arch,net.micro.16k,net.micro.68k Subject: Re: 24 bit vs. 32 bit address space Message-ID: <303@petrus.UUCP> Date: Tue, 5-Mar-85 12:15:48 EST Article-I.D.: petrus.303 Posted: Tue Mar 5 12:15:48 1985 Date-Received: Wed, 6-Mar-85 04:27:54 EST References: <983@watdcsu.UUCP> <2385@nsc.UUCP> <730@amdcad.UUCP>, <2393@nsc.UUCP> <295@cmu-cs-spice.ARPA> <133@v1.UUCP> <181@redwood.UUCP> Organization: Bell Communications Research, Inc Lines: 19 Xref: watmath net.arch:923 net.micro.16k:247 net.micro.68k:633 I have no objections to simply bringing less than the full 32 bits off of the chip. 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. On the 32016 and 32032 this could simply be a test that the upper byte is all zeros. On the 68k series, the MSB and the 23 lowest address bits should have been brought out, since the absolute short addressing mode was signed. Then the test would have been that the 24th through 31st bits were either all zeros or all ones. Note that leaving this test to the software is relatively painful, at least if you're programming in C or assembler. I'm willing to bet that the vast majority of code running on 68000's is in fact in those two languages. Probably on the 32000 series also. Rich Hammond [decvax | ucbvax | ihnp4] ! bellcore ! hammond