mash@mips.COM (John Mashey) (03/01/88)
In article <1695@winchester.mips.COM> I wrote: ... >I assume this must be humorous: it is obvious that this architecture was >designed to be a microcontroller, to run limited-size, embedded, >and definitely, non-UNIX applications. It seems OK for that purpose, >but it obviously wasn't built for running UNIX or large applications >(and there's nothing wrong with that). I probably should have said more: I've gotten several mailings wondering why it is obvious ("This is Fermat's Last Theorem; the proof is left to the student as an exercise..." :-) and urging me to post more, so: The reasons were, in order of impact: 1) (architecture, critical) The MMU isn't appropriate for UNIX. 2) (fuzzy boundary between architecture and implementation, could be fixed, but probably with performance hit, and certainly with substantial redesign of bus interface, and maybe coprocessor interface). According to the information made available so far, the design treats the 128K of memory as THE memory, not as caches. If the size is limited by the number of SRAM chips that can be driven directly, the size limit grows with time, but is fairly small in comparison to that needed by workstations these days. ------------ 3) (architectural, but not critical) Performance tunings: these are NOT critical, in that they could still let you have a workstation with an RPM-40 as currently implemented. However, some of the design tradeoffs seem tuned in directions opposite those of programs found in general-purpose environments. (As appropriate, remember that they said it was for embedded environments.) -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
oconnor@sungoddess.steinmetz (Dennis M. O'Connor) (03/02/88)
An article by mash@winchester.UUCP (John Mashey) says:
] In article <1695@winchester.mips.COM> I wrote:
] ...
] >I assume this must be humorous: it is obvious that this architecture was
] >designed to be a microcontroller, to run limited-size, embedded,
] >and definitely, non-UNIX applications. It seems OK for that purpose,
] >but it obviously wasn't built for running UNIX or large applications
] >(and there's nothing wrong with that).
]
] I probably should have said more: I've gotten several mailings wondering
] why it is obvious ("This is Fermat's Last Theorem; the proof is left
] to the student as an exercise..." :-) and urging me to post more, so:
]
] The reasons were, in order of impact:
]
] 1) (architecture, critical)
] The MMU isn't appropriate for UNIX.
There is no MMU on the RPM40 CPU. What there is is a method of
providing seperate "process" address spaces. This method
can be used with an external MMU, or it can be disabled and
an external MMU used, or it neither can be used, or just
the "APHID" scheme can be used.
Many UNIX boxes exist using processors with no built-in MMU.
And an MMU can easily be added without slowing the RPM40
down, due to the CPU's generous memory timing scheme.
] 2) (fuzzy boundary between architecture and implementation, could be fixed,
] but probably with performance hit, and certainly with substantial redesign
] of bus interface, and maybe coprocessor interface).
] According to the information made available so far, the design
] treats the 128K of memory as THE memory, not as caches. If the size
] is limited by the number of SRAM chips that can be driven directly,
] the size limit grows with time, but is fairly small in comparison to
] that needed by workstations these days.
PLEASE, don't confuse what IS hooked to the CPU on the
CURRENT DEMONSTRATION BOARD to what CAN be hooked to it.
There is no reason that the 128K of RAM that last-year's
technology allowed us to put on the board couldn't be
a 128K cache ( well, two 64K caches actually ). Backed up
by as much "slow" 200ns RAM as you like.
] 3) (architectural, but not critical)
] Performance tunings: these are NOT critical, in that they could still let you
] have a workstation with an RPM-40 as currently implemented. However,
] some of the design tradeoffs seem tuned in directions opposite those
] of programs found in general-purpose environments. (As appropriate,
] remember that they said it was for embedded environments.)
NAME THEM! Can you ? I might be able to, but do you know the architecture
( and the requirments of a "UNIX" system ) well enough to do so ?
But go ahead, name the trade-offs that "tune" the RPM40 CPU "away"
from UNIX. That should cause a few "discussions" on the net !
] -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
--
Dennis O'Connor UUNET!steinmetz!sunset!oconnor
ARPA: OCONNORDM@ge-crd.arpa
(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)