segments and Unix

[Daniel M. Frank]

In article <13802 at amdcad.UUCP> phil at amdcad.UUCP (Phil Ngai) writes:
>Suppose every data structure were in its own segment.
>
>Would this be worth doing? Of course, it would complicate the OS's
>memory management duties. But think about it.

   I think this was called the iAPX432.  Anyone remember the 432?

   Seriously, though, this is the old RISC-vs.-CISC argument, or the
old capabilities-vs.-addresses argument.  Here are the problems, as
succinctly as I can put them:

   1) Given a fast, simple instruction set, why not just let the 
	  compiler put in checks (in languages where such checks make
	  sense)?  Then, once you "trust" your program, you can turn
	  them off.  Capabilities are forever.

   2) If you have a segment (translate "capability") for every
	  data object, you have to store the capability info (permissions,
	  real address, size) somewhere and, because it is very inefficient
	  to keep it in main memory, you'll want to cache it.  This is
	  effectively what the 286 does:  every time you do a segment register
	  load, a bunch of hidden information is associated with the register.
	  With lots of capabilities, you will have to maintain a capability
	  cache, and the size of that cache will have to be very large to
	  efficiently support programs with lots of data objects.

   3) The religious argument of the RISC folks is that, even if you
	  can solve problem (2), which is difficult, you pay an extra
	  performance cost for the complexity you have to build into 
	  the processor.

   4) Virtual memory is a real problem for capabilities.  They tend
	  to be very small, so it's not clear what you want to swap.
	  Do you want to swap individual capabilities in and out, or
	  do you want lay capabilities over a paged memory, and manage
	  the memory with no knowledge of capabilities?

   One compromise would be to use the 286 architecture, but build a
compiler that can be told to put objects above a given size in their
own segments.  You have to be careful, though, not to exceed the size
of the local descriptor table for the process.

-- 
    Dan Frank
    uucp: ... uwvax!prairie!dan
    arpa: dan%caseus at spool.wisc.edu