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
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (05/14/87)
I am just cross posting this to arch, because many people don't (won't) read comp.intel. ================================================================ 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 ? | |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 -- bill davidsen sixhub \ ARPA: wedu@ge-crd.arpa ihnp4!seismo!rochester!steinmetz -> crdos1!davidsen chinet / "Stupidity, like virtue, is its own reward"
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