Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site oakhill.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!ut-sally!oakhill!davet From: davet@oakhill.UUCP (Dave Trissel) Newsgroups: net.arch,net.micro.16k,net.micro.68k Subject: Re: 24 bit vs. 32 bit address space (verifying lost address bits) Message-ID: <354@oakhill.UUCP> Date: Thu, 7-Mar-85 12:08:10 EST Article-I.D.: oakhill.354 Posted: Thu Mar 7 12:08:10 1985 Date-Received: Mon, 11-Mar-85 11:08:18 EST References: <983@watdcsu.UUCP> <2385@nsc.UUCP> <730@amdcad.UUCP> Reply-To: davet@oakhill.UUCP (Dave Trissel) Organization: Motorola Inc. Austin, Tx Lines: 80 Xref: watmath net.arch:933 net.micro.16k:254 net.micro.68k:639 Summary: In article <303@petrus.UUCP> hammond@petrus.UUCP writes: >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. > The original MC68000 has always had all 32 bit address lines on the die including bonding pads. Of course, the packaging problems of the times precluded the availability of all 32 address lines externally. At that early date it was too premature to tackle the problem of the missing address bits since future MMU and pinout configurations could not have been foreseen. However, during later M68000 family developments we still chose to ignore the case of the "dirty bits" in the high order portion of the address. This is because the issue rarely came up as a concern by our customers. Off the top of my head I can think of three situations where dirty bits can occur: 1) a pointer variable is set to garbage via a programming error 2) an invalid subscript causes the generation of an illegal address and 3) by software convention high order bits are used for some purpose Note that all static addresses via assemblers, high level languages and linkers should never be dirty since they are verified before execution ever commences. Therefore, we are left with the dynamically generated cases of 1 and 2 above. Of these cases, a certain amount of "wrong" addresses will not fall outside of the 24-bit addressing range. These pointers must depend on an MMU to trip them up or for "wrong alignment" exceptions to occur. Notice that if the bad pointer points within legally accessable ranges there is nothing that the architecture can do to detect errors here. Subscripts, on the other hand can be completely checked by comparing bounds before usage. Both the Motorola and National families have instructions to do this and of course regular compare and branches can be used here also. This checking requires extra overhead, though, so its a tradeoff which the user must decide upon. If no subscript range checking is used it would seem to me that most invalid subscripts would occur near the array itself and usually well within the 16 Megabyte physcial address space. Now I am not saying that there is no need for such dirty bit checking. It is obvious that there are definite programming errors which would be caught by it and microprocessors would be that much more robust. I'm just saying that most of (Motorola's) customers just haven't seen fit to complain about it and consequently we haven't seen fit to fix it. (The problem disappears with the MC68020.) Concerning case 3 above, back in the early days (all of four years ago) I can see where someone may have wanted to cheat and use the extra bits in the top of the address. After all, there weren't any >24 bit plans on the horizon and 16 Megabytes of physical address seemed unlimited (no virtual memory yet.) However, nowhere in the M68000 family literature is there any indication that a programmer is allowed to use these bits for anything other than a legal address. I compare this problem to that of BCD arithmetic. The MC68000 provides several BCD operations, however it does NOT verify that each byte of two BCD digits are actually valid decimal numbers. Now, in the future we may want to make BCD more robust and have these instructions verify the data being used. I would submit that it would be foolish for anyone to intentionally set funny flags in their BCD numbers 1) because the current instructions are not garanteed to work correctly and 2) validity checks may foil such schemes in the future. I don't see any difference between this and the dirty address bits above. >.. 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. Again in summary: I don't think that that many of the errors encountered would be caught by detecting illegal addresses at the high end of the address map. CHECK instructions are available for subscripts and pointers can only be partially checked via MMU protection schemes. Of course, comments welcomed. Motorola Semiconductor Inc. Dave Trissel Austin, Texas {ihnp4,seismo,gatech,ctvax}!ut-sally!oakhill!davet