UCBARPA.dag@Ucb-C70@sri-unix (11/25/82)
From: UCBARPA.dag at Ucb-C70 (David Allen Gewirtz) Received: from UCBARPA.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A20677; 25-Nov-82 01:42:56-PST (Thu) To: harpo!ihnp4!ixn5c!inuxc!pur-ee!CSvax.Physics.els at Ucb-C70, Cc: UCBARPA.dag at Ucb-C70 Via: Ucb-C70; 25 Nov 82 6:14-EST Via: Brl; 25 Nov 82 6:18-EST Via: Brl-Bmd; 25 Nov 82 6:21-EST Via: Brl; 25 Nov 82 12:52-PST VERRY briefly...the 432 (Intel designation iAPX-432) is an interesting little chip. The thing has what's called an "object-oriented architecture". That means that data and memory aren't really data or memory as Von Neumann might have called them, but are generic things, or "objects". The objects can, in effect, be treated as the principle data type of the machine and consist of some form of information (program or data) coupled with a type classification that is used in describing the object. These objects are then treated as separate, discrete modules that contain a collection of related procedures and the data structures they operate on. The data inside these modules can only be accessed by some call to a procedure inside these modules and is controlled by a type manager. This object orientation, implemented in the hardware of the iAPX 432 promotes a great deal of abstraction in the treatment of data. Instead of two types of data that represent information and the manipulation of that information as two separate and independent creatures, the object oriented system is based on the object, which represents both. Objects can be manipulated like data, but describe manipulation, like procedures. Data in the object is manipulated by sending a "message" to the object that specifies a type of manipulation for some data in the object. The message is a specification only, the actual manipulation is inherent in the definition of the object, and when the object receives a message, it determines how to manipulate itself. As an example, think of the driver of an automobile, who sees a red light at the intersection. The driver is the object, who manipulated data corresponding to the automobile. The traffic light is the message sender and the message is that the light is red. It is up to the driver to do something about the message, either stop or possibly hit something. All this neat stuff is controlled by Type Managers, who check ou the types of messages for validity to the receivers. Getting back to the 432, it can be broken down in the following manner: PHYSICAL PROCESSOR: Fetches and executes instructions (not an object) =================== (in memory space and hardware recognised) PROCESSOR OBJECT One for each processor Contains processor status daignosis information A reference to the process currently being executed PROCESS OBJECT: One for each process in the system Contains info like processor status scheduling information A reference to the context currently being executed. CONTEXT OBJECT: One for each instance of the procedure Contains info like: instruction pointer for this context stack pointer for this context references to all objects that can be accessed by this context The context object can be seen as referencing both instruction objects and data objects. INSTRUCTION OBJECT: Contains no data, only instructions This is the only type of data that the processor will use as the source of instructions to be fetched and executed. =================== (not explicitly hardware recognised) DATA OBJECT: Contains data. There are also things called port objects used for dispatching messages and processes and processors. These are called the "communications port" and "dispatching port" respectively. The above doesn't tell you anything about the really neat uses of the 432 or that it's slower than most of the better conventional microprocessors. What it should do is whet you interest for more information. I've included a short list of references that will give you more information about the 432 and papers on related architecture. Enjoy, David Gewirtz ========== Fabry, R.S., "Capability Based Addressing", CACM, July 1974 Introduction to the iAPX 432 Architecture, Intel, 1981 Izatt, W.T. "Domain Architecture and the ICL 2900 Series". SP&E Vol.10, 1980 Lampson, Butler W. and Howard E. Sturgis, "Reflections on Operating System Design", CACM May 1976. Myers, G.J. and B.R.S Buckingham, "A Hardware Implementation of Capability Based Adddressing", ACM Comp. Arch. News. Oct 1980. Rattner, Justin and George Cox, "Object Based Computer Architecture", ACM Comp. Arch. News, Oct 15, 1981 Wulf, W. et. al. "HYDRA: The Kernel of a Multiprocessor Operating System" CACM June 1974. Zeigler, Stephen, et.al., "Ada for the iAPX 432 Microcomputer", IEEE Computer, June 1981.
txr.usc-cse@Udel-Relay@sri-unix (11/28/82)
Well! I can see the marketing hype has gotten at least some of the people. But don't be fooled. There's a big difference between data encapsulation (like the iAPX432) and being object oriented (which the iAPX432 isn't). Either the designers of the 432 didn't really understand the term, or the marketing people at Intel just went wild with the buzzword of the eighties. Don't get me wrong, I'm not trying to diminish the 432 or the efforts of its designers. The 432 architecture should make a great ADA machine -- that's what data encapsulation is all about. But the 432 would make a lousy Smalltalk machine, and that's what object orientation is all about. I could go on, but I think it's been said before better. See, for example, "Object Oriented Programming," in the September 1982 SIGPLAN, which also has references to a lot of the other literature on object oriented programming and the whole bit. Let's not have "object oriented programming" be just another buzzword (like structured programming in te seventies). (In spite of the difference of opinion, I appreciated receiving both the text and the bibliography, they were well done. I hope other people publishing on these mailing lists will set their sights as high.) Cheers, Tim Rentsch
buzc (11/29/82)
There is a big difference between object oriented programming, and object based architectures. Unless I've been reading the literature incorrectly, Intels claim is that they have an object based ARCHITECTURE -- which I tend to agree with...
donald (11/29/82)
Re: "object-orientedness" vs "data encapsulation" and the iAPX432. I beg to differ with Tim Rentsch. I see very little difference between the meaning that lies behind the recent buzz-term "object-oriented" and the fairly old concept of data encapsulation/abstraction. Object-orientness appears to be a buzzword promulgated by the Smalltalk (LRG) group at Xerox PARC for the purpose of confusing the public into the belief that they've discovered a new a wonderful concept. After reading the rather vague descriptions in a BYTE issue (which seems to be the only readily available reference on Smalltalk), I've come to the conclusion the concepts in Smalltalk are actually fairly mundane-- it's just that the imagery and terminology used by its creators is quite strange. Just as one example, "message passing" between objects in Smalltalk is hailed as a novel approach to control flow, but it is absolutely isomorphic to a procedure call, where "message" is a fancy name for routine name + parameter list! "Multiple Inheritance Subclassing" is merely "parameterized abstract data types" by another name. Don't get me wrong-- I think Smalltalk is an interesting language/system, what with its lisp-like aspects, run-time typing, and unified view of objects, but it irks me that LRG couldn't find a paradigm for their system that maps more naturally into the rest of the universe. It seems that LRG had severe philosophical problems. The iAPX432 may make a good Smalltalk machine, mainly because it has an unbelievable amount of hardware support for high-level constructs and run time gyrations. This may be important for Smalltalk because the language defers almost everything until run time. For example, static type-checking is impossible is Smalltalk, but the 432 provides very good facilities for run time type checking. Paradoxically, I think the 432 would make a POOR Ada machine for the very reason that it has so much run time overhead when Ada was designed to be a compiled language. The high-level features of Ada may be "compiled away" so to speak, whereas those of Smalltalk seem inherent to the language. Down with Object Orientedness! Don Chan
mwm@Okc-Unix (12/02/82)
From: Mike Meyer <mwm@Okc-Unix> Intel seemd to think that the 432 would make a good Ada machine. Last time I looked, they were working on IMax-432 (their OS) in `Extended Ada' (GACK!). <mike