kong@ucla-cs.UUCP (05/12/87)
Here is a interesting issue,
What are the pros and cons of object based (or capability based) systems, say
iAPX 432, in terms of protection mechanisms compared to the contentional system,say 80286, from the architecture's point of view ?
Here are some comparisons between them,
1. protection granularity
80286 uses segments as the basic protection unit.
432 uses objects.
2. protection implementation
80286 uses global and local descriptor tables(GDT and LDT) to define
the rights to access the segments. Each memory reference has to check
those access rights.
432 uses Access Descriptors (actually, capabilities) to define the
access right the user's process has.
3. protection hierarchy
80286 uses ring structured protection hierarchy. The inner most ring is
the most trusted OS kernel, the outer ring is the user's process. Each
ring has a privilege level which defines the current process privilege,
the privilege level will change as the process call a function which
resides at the inner ring.
432 uses plain object spaces. There is no hierarchical structure. User
can access every objects as long as he has the right capability.
4. instruction set
80286 has certain privileged instructions which can only be executed
in the kernel mode. This is the direct consequence of the ring structure and use the segment as the basic protection unit.
in 432, you can execute every instructions as long as you have the right capability to access the instruction object.
5. sharing
80286 uses some sharable LDT or aliases to share some data or
instructions between some processes. Or you can put them into GDT to be
shared by every processes in the system.
432 sharing is achieved by passing capabilities to the sharable object.
*** It seems the conventional architecture such as 80286 has different
approaches for different problems (i.e. privilege level, ring,...).
Sometimes it seems that the conventional architecture can't guarantee
a true protection. On the other hand, the architecture of 432 is very
uniform; it solves each problems by using the same approach (I.e.
the object model), but it has severe ovehead for object access. As we
know, the 432 suffers from the slow performance problems which is a
direct consequence of this "safest" object model. As a matter of fact,
every object based systems has this kind of problems. So, what should
be our choice ? a conventional architecture whose performance is
acceptable but sometimes has protection problems, or a object based
system which has less protection problems but an (unacceptable ?) poor
performance ?
'Kong
UUCP : ..!{sdcrdcf,ihnp4,cepu,trwspp,ucbvax}!ucla-cs!kong
ARPA : kong@cs.ucla.edu tim@ism780c.UUCP (Tim Smith) (05/13/87)
< the object model), but it has severe ovehead for object access. As we < know, the 432 suffers from the slow performance problems which is a < direct consequence of this "safest" object model. As a matter of fact, < every object based systems has this kind of problems. So, what should < be our choice ? a conventional architecture whose performance is < acceptable but sometimes has protection problems, or a object based < system which has less protection problems but an (unacceptable ?) poor < performance ? Just because everyone in the past who has built object based systems has produced a slow system is no reason to assume that all object based systems must be this way. Try posting your questions to comp.arch. There are people working on fast object oriented machines who read that group ( Hi Fritz! ). -- Tim Smith "Froh wie seine Sonnen fliegen sdcrdcf!ism780c!tim Durch des Himmels praecht'gen Plan, Laufet, Brueder, eure Bahn, Freudig wie ein Held zum Siegen"
fritz@polecat.caltech.edu (Fritz Nordby) (05/14/87)
In article <5981@shemp.UCLA.EDU> kong@CS.UCLA.EDU writes: >Here is a interesting issue, >What are the pros and cons of object based (or capability based) systems, say >iAPX 432, in terms of protection mechanisms compared to the contentional system,say 80286, from the architecture's point of view ? > ... [some discussion of consequences of capability-based protection] ... >*** It seems the conventional architecture such as 80286 has different > approaches for different problems (i.e. privilege level, ring,...). > Sometimes it seems that the conventional architecture can't guarantee > a true protection. On the other hand, the architecture of 432 is very > uniform; it solves each problems by using the same approach (I.e. > the object model), but it has severe ovehead for object access. As we > know, the 432 suffers from the slow performance problems which is a > direct consequence of this "safest" object model. As a matter of fact, > every object based systems has this kind of problems. So, what should > be our choice ? a conventional architecture whose performance is > acceptable but sometimes has protection problems, or a object based > system which has less protection problems but an (unacceptable ?) poor > performance ? > >'Kong >UUCP : ..!{sdcrdcf,ihnp4,cepu,trwspp,ucbvax}!ucla-cs!kong >ARPA : kong@cs.ucla.edu The article quoted above appeared in comp.sys.intel, but it seems to me that it would be of interest to the folks in comp.arch as well, so this article is cross-posted. I would first like to comment that capability-based addressing and protection schemes have been around for quite a while; for those unfamiliar with the topic, a good place to start is R.S. Fabry, "Capability-Based Addressing," CACM, vol. 17, no. 7, July 1974 Second, I would like to point out that capability-based protection and object-oriented machine organization are really orthogonal issues. It is indeed possible to make a capability-based conventional mamchine, or a non-capability object-oriented machine; however, the characteristics of object-oriented machines are often perceived as making capabilities the most natural protection system. Finally, and most important, I would like to take issue with the claims made regarding performance of object-vbased or capability-based systems. First my qualifications in this regard: I am currently lead designer and architect for a project here at Caltech which is developing a machine, called the Caltech Object Machine (COM). Now let me state my position: IT IS NOT NECESSARILY TRUE THAT OBJECT-ORIENTED ARCHITECTURES NEED TO BE SLOW; INDEED, IT IS POSSIBLE TO BUILD OBJECT-ORIENTED MACHINES WHICH OUT-PERFORM CONVENTIONAL MACHINES WHICH EMPLOY A SIMILAR HARDWARE INVESTMENT. It is true that almost every object-oriented system built to date has suffered from poor performance; but much of this performance detriment is due to the methods of implementation. (For all of you hardware types out there, take a look at "Smalltalk-80: Bits of History, Words of Advice" by G. Krasner, and tell me how many different things you can find that are software implementations of what has traditionally been hardware: address translation and page replacement in LOOM, method lookup caches, etc.) To see what can be done in a simple object-oriented machine, take a look at the project I'm working on: for simple benchmarks (Ackermann's function and the sieve of Eratosthenes), the COM running Smalltalk out- performs a VAX-11/780 running C by a factor of between 2 and 10. (The wide range of these numbers is a result of the stack caches and the speed of method call in the COM.) In summary: (1) Capability-based protection and object-oriented architecture are two different things. (2) Object-oriented machines are not necessarily slow; don't blame the speed (or lack of speed) of the 432 on it's use of objects, blame the implementation of objects (and of the machine). Fritz Nordby. fritz@vlsi.caltech.edu seismo!cit-vax!fritz
chuck@amdahl.amdahl.com (Charles Simmons) (05/15/87)
In article <2688@cit-vax.Caltech.Edu> fritz@polecat.Caltech.EDU (Fritz Nordby) writes: >It is true that almost every object-oriented system built to date has >suffered from poor performance; but much of this performance detriment >is due to the methods of implementation. It has also been suggested that the 432 performed poorly on many benchmarks because the software was written in ADA and compiled with an extremely poor compiler (i.e. no optimizations were performed on the source code at all...) -- Chuck