cruess@oakhill.UUCP (Michael Cruess) (02/25/85)
.
My experience has been that 24 bits is barely acceptable today as a
*physical* address. 28 bits is seen as preferable. However, 32 bits is the
desired *logical* address size, and this is reason that the MC68020 has 32
address pins.
As an aside, having 32 bit addresses designed into the M68000 Family from
the beginning has made the instruction set upgrade in the MC68020 easy. If
the original designers of the MC68000 had restricted the register width and
the instruction set to the number of address pins they had on the part, it
would have been very painful.
Michael Cruess {ihnp4,seismo,gatech,ctvax}!ut-sally!oakhill!cruessdavid@daisy.UUCP (David Schachter) (02/27/85)
Mr. Cruess (of Motorola) states that, in his experience, 24 bit addresses are
a bit squeezed and that 28 bits is better. Therefore, he concludes, the
MC68020 is better than the NS32032. In my experience, 24 bits is big enough
to hold us workstation vendors until late 1987 or 1988. Until then, given
the real-world capabilities of microprocessors (as opposed to the claims of
the marketing departments of the microprocessor vendors), anyone worrying
about putting >16 MB on a microprocessor is wasting time. You wouldn't
put a 300 gallon gas tank in a Honda Civic, would you? It would be overkill.
By the time you need >16 MB in a workstation, National Semi will either have
a part to handle your needs or be bankrupt. Until then, the NS32032 gives you
what you want (as does the Intel 80286) without paying for extra, unneeded
address pins and without wasting expensive printed circuit board real estate,
tranceivers, etc.
If you want to claim that a microprocessor can run multiple users and therefore
should be held to the trends in super-minis, go ahead. I don't believe it.
One CPU = One User, in the micro world. My CPU cycles are MINE and you will
have to pry them from my cold, dead keyboard before I'll give them up willingly.
Daisy's customers won't need more than 16 MB until late 1987 or 1988. Until
then, the NS32032 and the Intel 80286 are fine. The MC68020 is overkill.
[The opinions expressed above are my own. Daisy Systems bears no responsibility
for them. I have no connections whatsoever to Intel, Motorola, or National
Semiconductor. I have no connections to anyone. Everybody hates me.]
{If one man calls you an ass, ignore him. If two men call you an ass, get a
saddle.}jans@mako.UUCP (Jan Steinman) (03/01/85)
In article <342@oakhill.UUCP> cruess@oakhill.UUCP (Michael Cruess) writes: >As an aside, having 32 bit addresses designed into the M68000 Family from >the beginning has made the instruction set upgrade in the MC68020 easy... I know of a 68010 software project that DEPENDS on those bits being masked off chip. It uses the eight most significant bits of pointers to objects as flags that contain information obout those objects. Of course, if a usable Motorola MMU is available when they port to the 68020, they can simply fold that huge address space over... -- :::::: Jan Steinman Box 1000, MS 61-161 (w)503/685-2843 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
jww@bonnie.UUCP (Joel West) (03/01/85)
>As an aside, having 32 bit addresses designed into the M68000 Family from >the beginning has made the instruction set upgrade in the MC68020 easy. If >the original designers of the MC68000 had restricted the register width and >the instruction set to the number of address pins they had on the part, it >would have been very painful. > >Michael Cruess {ihnp4,seismo,gatech,ctvax}!ut-sally!oakhill!cruess Of course, hardware upward compatibility doesn't guarantee software compatibility. A number of 32-bit processors have been crippled by operating systems writers who, when they designed their software, saw only physical hardware with 16mb or less and said "we only need 24 bits". Typically the upper byte is used for the number of arguments or argument words. Gould's port of BSD 4.2 suffers from this malady, and IBM's 370-vintage MVS is riddled with 24-bit usages -- hence the painful transition now being felt to MVS/XA, which allows a 32-bit address space. So before you're done checking on a system, ask if the SOFTWARE supports all 32-bits (virtual or physical.) -- Joel West (619) 457-9681 CACI, Inc. - Federal 3344 N. Torrey Pines Ct La Jolla 92037 jww@bonnie.UUCP (ihnp4!bonnie!jww) westjw@nosc.ARPA "The best is the enemy of the good" - A. Mullarney
ksbszabo@wateng.UUCP (Kevin Szabo) (03/03/85)
In article <608@mako.UUCP> jans@mako.UUCP (Jan Steinman) writes: >I know of a 68010 software project that DEPENDS on those bits being >masked off chip. It uses the eight most significant bits of pointers to >objects as flags that contain information obout those objects. Of course, >if a usable Motorola MMU is available when they port to the 68020, they can >simply fold that huge address space over... Wow! Another IBM-like blunder in the making. It's been a while, but wasn't this the problem that haunted IBM when they tried to use the top eight bits of their 32 bit address register? Every tom dick & harry had used them to hold a few flags `cause no one will ever have a 32 bit address space'. History repeats itself, even before it's history! Kevin -- Kevin Szabo watmath!wateng!ksbszabo (U of Waterloo VLSI Group, Waterloo Ont.)
djc@sun.uucp (David J. Cardinal) (03/04/85)
There are people who believe that they need more than 24-bits of virtual addressing for processors the power of a 68020, and presumably for ones the power of a 32032. They believe this firmly enough to pay for it. We can either convince them that they are wrong (although they seem to think they know what they are doing, so this may be difficult), ignore them (there are not very many, so this will be easy for awhile), or sell them what they want. It is nice that some people are careful programmers and believe that 16Mb is enough for everything, but many workstation users are scientists, and the less they think about programming, the more science they get to do. Our job as the people who make computers is presumably to give them whatever tools they need, and not necessarily to explain to them why they should spend more time thinking about programming and therefore be able to use other tools. In this case, I have to agree with John Gilmore that the demand is minimal, but it is not non-existent or fantasized. There are definitely programs which make good use of 16Mb virtual on a 68010, and as much real as we can cram on there (as long as memory is faster than disk, memory will be desirable as a means of increasing performance), so it is reasonable to expect these numbers to increase with any higher-powered processor. You can't "prove" or "disprove" a user community. You can sell to them or ignore them. --dave c.
tmb@talcott.UUCP (Thomas M. Breuel) (03/04/85)
> Of course, hardware upward compatibility doesn't guarantee software > compatibility. A number of 32-bit processors have been crippled by > operating systems writers who, when they designed their software, > saw only physical hardware with 16mb or less and said "we only need > 24 bits". Typically the upper byte is used for the number of arguments > or argument words. Well, the argument is not "we only need 24 bits". The argument goes more like "if we use 32 bit pointers, then we need at least an extra word for type/number of argument information, and at least an extra memory access per operation. This means that our software will use at least 33% more memory and time than other people's software". If you are careful, btw, you can write your programs (in, say, 'C') in such a manner that implementation details like this don't make the code unportable. Thomas.