mwm@ucbvax.ARPA (Mike (I'll be mellow when I'm dead) Meyer) (06/10/85)
In article <118@LaBrea.ARPA> mann@LaBrea.ARPA writes: >The 68451 is utterly ridiculous garbage (please >look into how it works before flaming back at me). I've seen this kind of claim a lot recently, and would like someone to explain why the 68451 is "utterly ridiculous garbage" (one of the nicer things I've heard said about it). I do know how it works, and can see the problem with the 2 wait states and the (not enough) segment registers living on the chip. Ignore that. What I'm interested in is the basic design of the MM system. Is there something inherently broken about the double-mask technic the 68451 uses? It doesn't seem as if there is to me; other than that it won't work nicely with Unix (sensible of it). The chip would seem to have been made for use with a buddy system of memory allocation (which Mot. points out) in a non-paged environment. It can also simulate, without to much trouble, fixed-size pages for almost any power-of-two page size. If it had a second level underneath it to give paged segments, the MM architecture would seem to be a winner. So, could somebody let me know why the architecture the 68451 supports is so bad? Preferably someone who's tried to build an OS using the chip. Comparisons with both the 32XXX MMU (082?) and the Standford 68K MMU would probably help. Thanx, <mike -- After 5 years, a quote worthy of Netnews (and it works as disclaimer!): "Truth is variable."
edler@cmcl2.UUCP (06/11/85)
In article <7983@ucbvax.ARPA> mwm@ucbvax.UUCP (Mike Meyer) writes: >In article <118@LaBrea.ARPA> mann@LaBrea.ARPA writes: >>The 68451 is utterly ridiculous garbage (please >>look into how it works before flaming back at me). > >I've seen this kind of claim a lot recently, and would like someone to >explain why the 68451 is "utterly ridiculous garbage" (one of the nicer >things I've heard said about it). I agree, I'm tired of hearing general condemnation of the 68451. It works. We have built a multiprocessor prototype here with eight 68010's and 68451's, and I don't think we've found any bugs in the chip. We have developed a parallel version of UNIX for it, including the 68451-related code. It doesn't do a very good job of supporting a large number of relatively small fixed-size pages. But it can still support large virtual memory, fast memory allocation is easy, large page tables are not needed, and it is only one chip. There are a few disadvantages to it; it is kind of slow, internal fragmentation can increase memory waste, and there aren't very many segment descriptors. Does anyone use multiple 68451's ganged together to provide more descriptors? I think the cost (in board space) would tend to make such a configuration un-attractive. In the years ahead, with more programs requiring very large address spaces, I think variable-sized segments might be particularly advantageous because a new address space can be created very quickly -- it isn't necessary to initialize all those page table entries. In any case, not all mmu's need to be demand-paged mmu's. Jan Edler New York University cmcl2!edler edler@nyu