eric@plus5.UUCP (Eric W. Kiebler) (03/04/85)
Why does the Mac not have memory protection? It would seem that the "computer for the rest of them" might be a bit more robust if it could detect addressing errors and recover from them, as opposed to stomping on the screen handling routines and sending drivel to the debuging device (read "printer"). If apple is listening, PLEASE include some type of memory protection on future releases in the Mac line!!!! It may be hard to do, but it would be well worth it "for the rest of us." eric -- ..!ihnp4!wucs!plus5!eric ..!ihnp4!plus5!eric (314) 725-9492
bass@dmsd.UUCP (John Bass) (03/07/85)
I agree ... apple really messed the mac design up by not including a simple mmu. There are several designs that can be done under $50 if you are willing to have a modest sized allocation granularity in the range of 1k to 8k depending on memory requirements. My two favorite designs are: 1) ram lookup, static paging: ________ | | ---MMU REG R/W->| | | |---- <-Data Bus----->| XCVR | | | | | -------- | | -------- | ------------------ | | | | | -High Addrs---->|N x M | | | Memory System | |Mapping<--|--->| | -ENA & R/W----->|Ram | | | | | ---->| | -------- | ------------------ | -Low Addrs------------------ Can generally be implemented with 3 to 5 parts using a 8X1024 static ram(s), 74LS245 XCVR(s), and a PAL16L8. With an 8bit map you can get 4k pages and a 512k process size with write protect. With address independant code (like mac programs have) and remapping support in the kernel, the program/data size can be much larger with application driven mapping. With a second ram and xcvr you can have 128byte pages and a 2mb address space. With the two rams you can partition the map in 2/4 images by adding a partition number latch and increasing the segment size to 256/512 bytes. With a single ram you can divide the address space into banks. Either way you get memory protection. 2) the second easy solution is to use base & bounds segmentation. This is slightly more complex using 8 to 12 parts. My single board unix kit uses 2-74AS870's, 1-74AS885, 2-74S283's, 2-74LS240's, and a PAL16L8. This gives you 16 base & bounds pairs that can be parititioned into the address space as needed. I choose 3 sets of 3 user segments of text, data, and stack with kenel segments of text, data, stack, upage, and two general purpose. Either design can add between 50ns and 100ns to the memory timing, but doesn't need to add anything with careful design. You can use the low address lines to drive memory row addresses, and when the mmu translation is complete use the high addresses to drive the column addresses. This completely overlaps the translation time with the RAS timing in many design using 200ns memories. Volume end user cost increase is likely much less than $100 with care. Stuffing it into a gate array can give more functionality and lower cost. Not all systems need complex paging mmu's. When you evaluate on a cost of production and maintainance standpoint including software design, debug, and support the mmu design may have a much lower lifecycle cost. It would be interesting to know how much the LACK of an MMU has cost Apple and other software vendors in building quality software. While we are on the beefs with the MAC hardware ... they could have also added a serial number for software protection -- thus not requiring much of the current disk format kludges which prevent using a hard disk. -- John Bass DMS Design (System Performance and Arch Consultants) {dual,fortune,idi,hpda}!dmsd!bass (408) 996-0557
howard@amdahl.UUCP (Howard C. Simonson) (03/08/85)
> Why does the Mac not have memory protection? It would seem that the > "computer for the rest of them" might be a bit more robust if it could > detect addressing errors and recover from them, as opposed to stomping on > the screen handling routines and sending drivel to the debuging device > (read "printer"). If apple is listening, PLEASE include some type of > memory protection on future releases in the Mac line!!!! It may be hard to > do, but it would be well worth it "for the rest of us." > > eric I heartily agree. It amazes my wife and I, how some programs go waltzing on in there and generate a sure fire bomb. We haven't actually picked up Inside Macintosh yet but must soon so we get an idea of what's going on in there ( or maybe I should say wrong :-). For now, I just chalk it up to applications/DA's written without thought of interaction with other stuff. Don't get me wrong, I love the freeware as much as anyone... -- Do not walk in front of me, I may step on your heel. Howard C. Simonson Do not walk behind me, ...{dragon,hplabs,ihnp4,nsc}!amdahl!howard I may stop abruptly. Just walk beside me, and be wary of sharp turns. -- HamuS [ Opinion? What opinion. I think you have the wrong guy... ]