mcg@omepd (Steven McGeady) (04/18/88)
In article <949@ima.ISC.COM> johnl@ima.UUCP (John R. Levine) writes: >In article <3363@omepd> mcg@iwarpo3.UUCP (Steve McGeady) writes: >>> 4) what about memory management? >>... The 80960MC implements the 80960 ... and also includes an on-chip memory >>management unit which supports a standard virtual memory management system. >>... This processor is available in a mil-spec package, and is targeted at >>military and high-reliability embedded applications that require hardware >>protection of concurrent processes. > >I would be fascinated to hear about high reliability embedded applications >that use virtual memory. Seems to me you'd need a pretty artful designer to >come up with a system that satisfies the sort of real-time constraints >generally present in embedded systems while handling page faults. > >Or perhaps you could have a system with Unix, vi, and troff and X windows >... fighter pilots can type up their reports on the way home ... >using only an eye-tracking mouse equivalent built into the helmet. ... John is taking a poke at me which is well-deserved. Clearly realtime systems will not make use of page-faulting virtual memory schemes. However, memory *protection* is an important aspect of high-reliability systems. The 80960MC allows isolation of (e.g.) Ada tasks so that the amount of interference caused by the failure of one software subsystem does not interfere with other important subsystems. One doesn't want an infinite loop in the coffee-maker control program to cause the engine controls to fail ... I failed to mention that the 80960MC also supports some underlying support for tasking (process) control. This is decidely non-RISCy, I know, but the 80960 is not an ideological processor, it is a pragmatic one. The forthcoming Ada compiler from Tartan Labs will use this support. And finally, in response to someone who complained about the $2k+ price for the 80960MC, remember that price is for a *militarized* part. If there is demand for a commercial part with memory management, I'm sure the price will be competitive. S. McGeady Intel Corp.
rroot@edm.UUCP (uucp) (04/20/88)
From article <3383@omepd>, by mcg@omepd (Steven McGeady): > > In article <949@ima.ISC.COM> johnl@ima.UUCP (John R. Levine) writes: > I failed to mention that the 80960MC also supports some underlying support > for tasking (process) control. This is decidely non-RISCy, I know, but > the 80960 is not an ideological processor, it is a pragmatic one. The Oh god, not again!. I hope that the 80960 does a better job of task switching than the 80286 did. I'm starting to SERIOUSLY doubt the utility of hardware assist in areas like this given the following examples: 1: the 8086's string manipulation instructions.. said to give it such a big advantage over the 68000. If you do cycle counts, though, it turns out that a 68000 move/dbcc loop is faster than the intel equivalent. 2: 80286 task switching: touted as such a great advancement, but from all I've heard, task switching on the '286 seems to be "phenomenally slow". 3: On an amdahl V8, the mvcl (move character long), which allowed string moves up to memory size (then 16MEG) in one instruction, was actually SLOWER than coding a loop with the more limited MVC (256 bytes max) instruction. The person who (did and) told me about the benchmarks alluded to the fact that MVCL was even worse on some of the older machines. In summary: don't add a whole stack of 'useful' instructions if it just slows things down. (I think I'm starting to sound like a RISCer). -- ------------- Stephen Samuel {ihnp4,ubc-vision,vax135}!alberta!edm!steve or userzxcv@uqv-mts.bitnet
sedwards@esunix.UUCP (Scott Edwards) (05/05/88)
From article <266@edm.UUCP>, by rroot@edm.UUCP (uucp): > Oh god, not again!. I hope that the 80960 does a better job of task > switching than the 80286 did. I'm starting to SERIOUSLY doubt the utility > of hardware assist in areas like this given the following examples: > 1: the 8086's string manipulation instructions.. said to give it such a > big advantage over the 68000. If you do cycle counts, though, it turns out > that a 68000 move/dbcc loop is faster than the intel equivalent. It is not the instruction that is slow, it's the way it is implimented in the 8086, if you check the string instructions in the '286 they are very fast, much faster than a move/dbcc loop. -- Scott