Средства и методы разработки

The iAPX 432 instruction had variable length, and peculiarly were bit rather than byte aligned,[5] with an instruction taking between 6 and 321 bits.[16] Object-oriented memory and capabilities[edit] The iAPX 432 has hardware and microcode support for object-oriented programming and capability-based addressing.[17] The system uses segmented memory, with up to 2^24 segments of up to 64 KB each, providing a total virtual address space of 2^40 bytes. The physical address space is 2^24 bytes (16 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 Access Descriptors (ADs), which provide an index into the system object table and a set of rights (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 program can define new object types which will get the full benefit of the hardware type checking, through the use of Type Control Objects (TCO). 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.