Editing Intel iAPX 432 (section)

==Architecture==
The iAPX 432 instructions have variable length, between 6 and 321 bits.<ref name="IchikawaTsubotani1992">{{cite book|author1=Tadao Ichikawa|author2=H. Tsubotani|title=Language Architectures and Programming Environments|url=https://books.google.com/books?id=3vfbUGp4WfkC&pg=PA127|year=1992|publisher=World Scientific|isbn=978-981-02-1012-0|page=127}}</ref> Unusually, they are not byte-aligned, that is, they may contain odd numbers of bits and directly follow each other without regard to byte boundaries.<ref name="i8800"/> 

===Object-oriented memory and capabilities===
The iAPX 432 has hardware and microcode support for [[object-oriented programming]] and [[capability-based addressing]].<ref>{{cite book|first=Henry M.|last=Levy|chapter=Chapter 9: The Intel iAPX 432|title=Capability-Based Computer Systems|publisher=[[Digital Press]]|year=1984|url=https://homes.cs.washington.edu/~levy/capabook/|chapter-url=http://www.cs.washington.edu/homes/levy/capabook/Chapter9.pdf}}</ref><ref>{{Cite book |last=Organick |first=Elliott I. |url=https://www.worldcat.org/oclc/9110667 |chapter=Chapter 4: i432 Object Structures for Program Execution |title=A programmer's view of the Intel 432 system |date=1983 |publisher=McGraw-Hill |isbn=0-07-047719-1 |location=New York |oclc=9110667}}</ref> The system uses [[segmented memory]], with up to 2<sup>24</sup> segments of up to 64&nbsp;[[Kibibyte|KB]] each, providing a total virtual address space of 2<sup>40</sup> bytes. The physical address space is 2<sup>24</sup> bytes (16&nbsp;[[Megabyte|MB]]).

Programs are not able to reference data or instructions by address; instead they must specify a segment and an offset within the segment. Segments are referenced by ''[[Discretionary access control|access descriptors]] (ADs)'', which provide an index into the system object table and a set of rights ([[Capability-based security|capabilities]]) governing accesses to that segment. Segments may be "access segments", which can only contain Access Descriptors, or "data segments" which cannot contain ADs. The hardware and microcode rigidly enforce the distinction between data and access segments, and will not allow software to treat data as access descriptors, or vice versa.

System-defined objects consist of either a single access segment, or an access segment and a data segment. System-defined segments contain data or access descriptors for system-defined data at designated offsets, though the operating system or user software may extend these with additional data. Each system object has a type field which is checked by microcode, such that a Port Object cannot be used where a Carrier Object is needed. User programs can define new object types which will get the full benefit of the hardware type checking, through the use of ''type control objects (TCOs)''.

In Release 1 of the iAPX 432 architecture, a system-defined object typically consisted of an access segment, and optionally (depending on the object type) a data segment specified by an access descriptor at a fixed offset within the access segment.

By Release 3 of the architecture, in order to improve performance, access segments and data segments were combined into single segments of up to 128&nbsp;kB, split into an access part and a data part of 0&ndash;64&nbsp;KB each. This reduced the number of object table lookups dramatically, and doubled the maximum virtual address space.<ref>{{cite book|author=Glenford J Meyers|title=Advances in Computer Architecture|edition=2nd|publisher=Wiley|year=1982|isbn=978-0-471-07878-4|chapter=Section VI: Overview of the Intel iAPX432 Architecture}}</ref>

The iAPX432 recognizes fourteen types of predefined ''system objects'':<ref name=GDPRef>{{cite book|last1=Intel Corporation|title=iAPX432 GENERAL DATA PROCESSOR ARCHITECTURE REFERENCE MANUAL|date=1983|url=http://www.bitsavers.org/components/intel/iAPX_432/171860-004_iAPX_432_General_Data_Processor_Architecture_Reference_Manual_Feb84.pdf|access-date=Nov 16, 2015}}</ref>{{rp|pp.1-11–1-12}}
* '''instruction object''' contains executable instructions
* '''domain object''' represents a program module and contains references to subroutines and data
* '''context object''' represents the context of a process in execution
* '''type-definition object''' represents a software-defined object type
* '''type-control object''' represents type-specific privilege
* '''object table''' identifies the system's collection of active object descriptors
* '''storage resource object''' represents a free storage pool
* '''physical storage object''' identifies free storage blocks in memory
* '''storage claim object''' limits storage that may be allocated by all associated storage resource objects
* '''process object''' identifies a running process
* '''port object''' represents a port and message queue for interprocess communication
* '''carrier''' Carriers carry messages to and from ports
* '''processor''' contains state information for one processor in the system
* '''processor communication object''' is used for interprocessor communication

===Garbage collection===
Software running on the 432 does not need to explicitly deallocate objects that are no longer needed. Instead, the microcode implements part of the marking portion of [[Edsger Dijkstra]]'s on-the-fly parallel [[Garbage collection (computer science)|garbage collection]] algorithm (a [[mark-and-sweep]] style collector).<ref>{{Cite journal | doi = 10.1145/359642.359655| last1 = Dijkstra | first1 = E. W. | author-link1 = Edsger W. Dijkstra| last2 = Lamport | first2 = L. | author-link2 = Leslie Lamport| last3 = Martin | first3 = A. J. | last4 = Scholten | first4 = C. S.| last5= Steffens | first5 = E. F. M.| title = On-the-fly garbage collection: an exercise in cooperation| journal = [[Communications of the ACM]]| volume = 21| issue = 11| date = November 1978 | pages = 966–975| s2cid = 8017272 | doi-access = free}}</ref> The entries in the system object table contain the bits used to mark each object as being white, black, or grey as needed by the collector. The [[iMAX 432]] operating system includes the software portion of the garbage collector.<ref>{{cite web|url=http://bitsavers.org/components/intel/iAPX_432/172103-002_iMAX_432_Reference_Manual_May82.pdf|title=iMAX 432 Reference Manual|date=May 1982|publisher=[[Intel]]}}</ref>

===Instruction format===
Executable instructions are contained within a system "instruction object".<ref name=GDPRef />{{rp|p.7-3}} Due to instructions being bit-aligned, a 16-bit ''bit'' displacement into the instruction object allows the object to contain up to 65,536 bits (8,192 bytes) of instructions.

Instructions consist of an ''operator'', consisting of a ''class'' and an ''opcode'', and zero to three ''operand references''. "The fields are organized to present information to the processor in the sequence required for decoding". More frequently used operators are encoded using fewer bits.<ref name=GDPRef />{{rp|p.7-6}} The instruction begins with the 4 or 6 bit class field which indicates the number of operands, called the ''order'' of the instruction, and the length of each operand. This is optionally followed by a 0 to 4 bit ''format'' field which describes the operands (if there are no operands the format is not present). Then come zero to three operands, as described by the format.  The instruction is terminated by the 0 to 5 bit opcode, if any (some classes contain only one instruction and therefore have no opcode). "The Format field permits the GDP to appear to the programmer as a zero-, one-, two-, or three-address architecture." The format field indicates that an operand is a data reference, or the top or next-to-top element of the operand stack.<ref name=GDPRef />{{rp|pp.7-3–7-5}}