steckel@Alliant.COM (Geoff Steckel) (04/16/88)
Do either of the new Intel chips support either limited or general MMUs? The press notes are contradictory on this point. I know that the '960-MC has some sort of fancy paging ability, but at $2000+ per, it's moot. I'm interested in the reduced 80386 (80376?) and the non-militarized 80960s. By 'support a MMU' I mean, using either on or off-chip MMU hardware: 1) Allow multitasking with process relocation (e.g. a flat address space for each process, with each process at 'logical 0 (or 0x20000 or...)) Segment registers a la 8086 need not apply (:-). Remember base regs on 360's? If they must be used, can I set them all to 0 (or some such) and have a flat space? Can they be used to avoid/alter access restrictions? (see 2 below) 2) Allow an OS or other supervisory software to arrange that a process will be suspended in a restartable state **before** a reference to memory or I/O resources is passed off-chip (for on-chip MMU) or beyond the off-chip MMU. This supports demand paging. Failing the above, ability to have some method to probe a space in a predictable manner. All other 'prohibited' references should be aborted, not necessarily in a continuable manner, but before any reference modifies any resource. This was the method used to run a 3-segment (code, data, stack) V7 UNIX on a 68000 with external MMU. This version of Unix did not page, but swapped whole segments, and only required the stack to auto-extend. A sacrificial probe instruction was compiled in the standard subroutine prologue. The OS checked all 'bus error' PCs for a 'tstb -n(FP)' and assumed that the 'n' was an implicit request to extend the stack. Grotesque, but it works. Failing all of the above (and just barely better than stone axes) (:-) an external signal which causes a non-restartable trap and aborts the current memory cycle before logical completion of the cycle or instruction. This is not the RESET line - I'd really like to know the error PC! This is for damage control - keepa you process offa my data! (:-) This questions are not just 'can I run Unix/Mach/whatever on it?' Most complex applications needing the power of a 32-bit CPU are multitasking applications, even if they are simple ones. No, you don't necessarily want a multi-user system, but you DO want confidence that tasks can't clobber each other. Having used memory protection on a number of 'embedded control' applications I found it reduces debugging effort by weeks at a time. Using 'NMI' or other interrupt hackery just isn't enough (or doesn't work!). For this reason I specify 68000-family chips wherever possible for embedded applications. The 'BUS ERROR' pin is just TOO useful. It would be nice if Intel chips could compete here. geoff steckel (steckel@alliant.COM)
mcg@omepd (Steven McGeady) (04/18/88)
In article <1599@alliant.Alliant.COM> steckel@alliant.COM (Geoff Steckel) writes: >Do either of the new Intel chips support either limited or general >MMUs? The press notes are contradictory on this point. I don't know what 'press notes' you are referring to, but it is likely that the view that you're going to get from the media is going to me short on detail. As for the Intel-generated press releases, they too are short on detail, as their function is basically to get you to go to our sales force and get detailed, interactive information relevant to your application. Regardless of what I say here, I strongly urge you to contact you local sales office. They can probably get an FAE ("Field Application Engineer") out to you to answer your questions in detail. I won't address 376 details here, not because the 376 isn't interesting, but because I'd probably screw up the details. > I know that the '960-MC has some sort of fancy paging ability, but > at $2000+ per, it's moot. I'm interested in the reduced 80386 (80376?) > and the non-militarized 80960s. I urge you to ask your salespeople about 80960MC-class components. Just because something doesn't exist today doesn't mean it won't ever exist. Just because it's quoted at 'X' doesn't mean it will always cost 'X'. >By 'support a MMU' I mean, using either on or off-chip MMU hardware: > >1) > Allow multitasking with process relocation (e.g. a flat address space > for each process, with each process at 'logical 0 (or 0x20000 or...)) > The MMU on the 80960MC handles this admirably. The page tables include user/supervisor read/write protection bits, as well as 'dirty' bits. > >2) > Allow an OS or other supervisory software to arrange that a process > will be suspended in a restartable state **before** a reference to > memory or I/O resources is passed off-chip (for on-chip MMU) or > beyond the off-chip MMU. This supports demand paging. On the 80960MC, a process will be suspended with a Page Fault if it makes an access to a non-resident page, as in any such scheme. On the 80960KA and KB, a 'Bad Access' fault is signalled to the running program when an external device (i.e. memory subsystem) asserts the BADACC pin. Unfortunately, the program state cannot be reliably recovered following an error of this sort. > Failing the above, ability to have some method to probe a space in > a predictable manner. All other 'prohibited' references > should be aborted, not necessarily in a continuable manner, but > before any reference modifies any resource. All processor implementations (i.e. the KA and the KB, as well as the MC) support 'synchronous load' and 'synchronous store' instructions, which perform load and store operations, setting the condition codes if the operations fail. These instructions (which have many uses) set a condition code bit if the memory access fails (i.e. if the BADACC pin on the edge of the chip changes state during the reference), and could be used much like the Vax 'probe' instruction. These instructions are exempt from causing the BADACC fault mentioned above. > This was the method used to run a 3-segment (code, data, stack) V7 UNIX > on a 68000 with external MMU. This version of Unix did not page, but > swapped whole segments, and only required the stack to auto-extend. > A sacrificial probe instruction was compiled in the standard subroutine > prologue. The OS checked all 'bus error' PCs for a 'tstb -n(FP)' > and assumed that the 'n' was an implicit request to extend the stack. > Grotesque, but it works. This could be done with the synchronous store instructions, or with a normal load/store instruction and a 'synchronize faults' instruction. > Failing all of the above (and just barely better than stone axes) (:-) > an external signal which causes a non-restartable trap and aborts the > current memory cycle before logical completion of the cycle or instruction. > This is not the RESET line - I'd really like to know the error PC! > This is for damage control - keepa you process offa my data! (:-) > This is the Bad Access fault mentioned above. >This questions are not just 'can I run Unix/Mach/whatever on it?' >Most complex applications needing the power of a 32-bit CPU are multitasking >applications, even if they are simple ones. No, you don't necessarily want >a multi-user system, but you DO want confidence that tasks can't clobber >each other. This is the class of application that the 80960MC was designed for. If it best suits your application, don't dismiss it because of the initially-quoted price. We all know what happens to semiconductor prices! Beat on your salesman for a commerical part. >Having used memory protection on a number of 'embedded control' applications >I found it reduces debugging effort by weeks at a time. Using 'NMI' or other >interrupt hackery just isn't enough (or doesn't work!). For this reason I >specify 68000-family chips wherever possible for embedded applications. >The 'BUS ERROR' pin is just TOO useful. It would be nice if Intel chips >could compete here. As noted, the 80960 competes handsomely here. The blanket condemnation of Intel is undeserved here, I think. S. McGeady Intel Corp. For the record, again: the views presented above do not necessarily represent the views of Intel Corporation in any way. They are mine and mine alone.