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