Increased capabilities,
`architectural compatibility, and
`clearly defined interfaces were
`the chief architectural goals of
`Zilog's new ZBOOO microprocessor
`family. Here is an account
`of how those goals were met
`for two members of that family(cid:173)
`the ZBOOO CPU and the MMU.
`
`The Z8000 family is a new set of microprocessor
`components (CPU, CPU support chips, peripherals,
`and memories) which supports the Z8000 architec(cid:173)
`ture. The account of how architectural goals were
`selected and achieved for two key members of this
`family-=-the Z8000 CPU and the memory manage(cid:173)
`ment unit-illustrates how much of a challenge
`microprocessor architecture represents to the semi(cid:173)
`conductor industry. MOS technology shows enor(cid:173)
`mous potential, but it is still difficult to use because
`of limitations on pin count, power dissipation, speed,
`and complexity.1
`Since this discussion is restricted to technical
`issges, we will not allude to the many additional fac(cid:173)
`tors (marketing considerations, human considera(cid:173)
`tions, self-imposed restrictions, etc.) which make ar(cid:173)
`chitecture such a fascinating and difficult discipline.
`Furthermore, no attempt has been made to ex(cid:173)
`haustively describe the Z8000 architecture and com(cid:173)
`ponents. Interested readers should consult the
`specific manuals for a more complete description. 2•3
`
`The goals of the Z8000 architecture:
`increased capabilities, architectural
`compatibility, increased clarity
`
`The primary reason for introducing a new system
`~chitecture is to signifi~ntly improve the control
`and processing capabilities of microprocessors while
`maintaining their price/performance advantages.
`Technical advances have permitted the implementa(cid:173)
`tion of substantially increased processor power, but
`the most significant motivation for a new component
`family is generality. Only through such a family
`could we provide for architecturally compatibie
`growth over a wide range of processing power re(cid:173)
`quirements.
`
`Our approach was a staged system architecture
`which attempts to provide new components, enhanc(cid:173)
`ed features, and new functions, while protecting the
`user's investment in hardware and software. The
`Z8000 family supports a single unified architecture
`for all small, medium, and high-end user applications
`which are implemented using a mix of components
`within the same family.
`The goals of the Z8000 architecture can be grouped
`into three categories: increased capabilities, architec(cid:173)
`tural compatibility over a wide range of processing
`powers, and increased clarity. In all these cases the
`resulting architectural features apply either to the
`basic architecture (that seen by an applications pro(cid:173)
`grammer) or to system architecture (that seen by a
`system designer or an operating system program-
`mer).
`'
`
`Increased capabilities. All existing 8-bit micro(cid:173)
`processors and many 16-bit minicomputers suffer
`from having a small address space. So, one of our
`goals was to provide access to a large address space
`(8M bytes). A second goal was to provide more re(cid:173)
`sources in terms of registers (16 general-purpose
`16-bit registers), in terms of data types (from bits to
`32 bits), and in terms of additional instructions com(cid:173)
`pared to existing micropr~essors (multiply and
`divide, multiple register saving instructions,
`specialized instructions for compiler support etc.).
`To facilitate complex applications it was important
`to support multiprogramming with good hardware
`support of task switching, interrupts, traps, and two
`execution modes. Operating systems also required a
`good hardware protection system.
`Finally, we wanted to increase overall system per(cid:173)
`formance. This resulted in the choice of an implemen(cid:173)
`tation using a 16-bit-wide data path to memory.
`
`10
`
`0018-9162/79/0Q20-00!0$00.75 © 1979 IEEE
`
`COMPUTER
`
`APPLE EX. 1023
`Page 1
`
`

`
`Architectural compatibility. One of the important
`lessons learned from previous computer system
`designs is that the design of a new family architecture
`is a rare occurrence. One way to apply this lesson is to
`design a unified architecture compatible over a wide
`range of processing powers. If we anticipate user
`growth from small to large systems within a family
`architecture, then such an approach can significantly
`increase its life.
`The two versions of the Z8000 (a 40·pin
`unsegmented and a 48·pin segmented versionl are
`designed to achieve this goal, but many other
`features contribute indirectly to the family com(cid:173)
`patibility. For small aplications an unsegmented
`Z8000 with one or more 64K ·byte address spaces can
`be used. For medium applications, a segmented
`Z8000 and one memory management unit allows
`direct access to 4M bytes of address space. For large
`applications a segmented Z8000 and multiple pairs of
`MMUs allow the use of several 8M·byte address
`spaces.
`Since the segmented Z8000 can run in an unseg(cid:173)
`mented mode, both systems are compatible. Finally,
`to achieve even larger processing power through
`hardware replication, the architecture provides basic
`mechanisms for both multiprocessing and dis·
`tributed processing.
`
`Clarity. Clarity in an architecture is a measure of
`how well key interfaces are defined and specified.
`This is an elusive but important goal in a family
`where new and unforeseen components will be added
`during the life of its architecture.
`
`We felt bus protocols were so important
`that we developed an independent
`specification for the Z-bus along with the
`individual device manuals.
`
`Clarity in terms of the basic architecture means
`regularity and extendability of the instruction set, as
`well as the general and simple handling of the
`operating system interfaces. Clarity in terms of the
`system architecture means a well-defined method of
`communication between the various components.
`The key link between these components is the Z-bus,
`which is a shared system bus. In the section on com(cid:173)
`munication with other devices, we describe some of
`the various types of bus protocols. At· Zilog we felt
`this was so important that we developed an indepen(cid:173)
`dent specification for the Z-bus along with the in·
`dividual device manuals. 4
`·
`
`Comparison with other system architectures
`
`We are convinced that the differences between
`microprocessor system architecture and large com(cid:173)
`puter system architecture are not sufficient to re-
`
`February 1979
`
`quire a different design approach, although they cer(cid:173)
`tainly influence the details of design compromises.
`The last section of this paper deals with implementa(cid:173)
`tion tradeoffs and illustrates some particular com•
`promises. (In a few places we mix implementation
`considerations with descriptions of architectural
`tradeoffs. Despite the importance of separating an ar(cid:173)
`chitecture from its implementation, we found that
`this separation is often absent during the actual crea(cid:173)
`tion of a new architecture.l .
`Two differences between conventional computer
`systems and microprocessor systems have the
`greatest impact: price structure and component
`boundary differences. For high-end LSI systems, it
`makes sense to have one unified architecture, but
`unlike their computer family counterparts (IBM
`360/370, PDP-11l different implementations cannot
`be justified on a price/performance basis. Speed and
`performance are mainly dependent on the state of
`technology, and therefore, for a given application, a
`user will waste the speed willingly since another
`slower implementation would cost the same. This
`does not exclude different versions of one implemen(cid:173)
`tation, which reflect only different test and produc(cid:173)
`tion criteria such as package type, functional tem(cid:173)
`perature range, and even speed range.
`Most computer systems have both external and in(cid:173)
`ternal interfaces. External interfaces which define
`system boundaries are often standardized (e.g., the
`IBM channel interface or the DEC unibusl. The inter(cid:173)
`nal interfaces of most mini or large computer systems
`are essentially hidden. In contrast, the component
`boundaries of a microprocessor-based system repre(cid:173)
`sent actual interfaces, and most users must be famil(cid:173)
`iar with them as well as with external interfaces.
`Because the component interfaces are more visible
`and often must be more general, the microprocessor(cid:173)
`oriented system bus emerges as a key standardiza(cid:173)
`tion link to allow a wider mix of components and
`designs.
`
`The basic architecture
`
`Address space considerations. It is advantageous
`to have more than one address space, with each ad(cid:173)
`dress space as large as possible. In the Z8000,
`memory references and I/0 references are viewed as
`references to different address spaces. The 1/0 space
`is discussed in the section below on communication
`with other devices. Memory references may be in(cid:173)
`structions or data and stack accesses, with each type
`of access possible in either system or normal modes.
`The Z8000 distinguishes between each of these
`reference possibilities by using different combina(cid:173)
`tions of its status lines. Separating the various ad(cid:173)
`dress spaces can be used to increase the total number
`of addressable bytes and to achieve protection. The
`size of each address space depends on the versions of
`the Z8000 used. The 40-pin package version allows
`each address space to be at most 64K bytes, the
`48-pin package version allows each address apace to
`be at most 8000K bytes.
`
`11
`
`APPLE EX. 1023
`Page 2
`
`

`
`The 40-pin version is intended for systems, often
`used as dedicated systems, where the program and
`data spaces are small. In this case, relocation is not
`usually important. Using the different address
`spaces, one has a simple way to address in practice up
`to 4 x 64K bytes (with a maximum of 6 x 64K bytes).
`Some simple protection is achieved by separating
`these spaces in hardware.
`The 48-pin version with one or more MMUs is in(cid:173)
`tended for the medium to large applications where
`relocation and better memory protection are impor(cid:173)
`tant. 3 In these cases, status information can also be
`used to separate between address spaces by using
`multiple MMU s. But it is also essential to achieve the
`detailed memory protection required. (It is possible
`to use the 48-pin version without an MMU.) For these
`high-end applications, the address spaces are so large
`that one is unlikely to exhaust them. Experience with
`large computers shows that 8M bytes is probably
`adequate. The current implementation of the Z8000
`uses 8M-byte address spaces, but the architecture
`provides for 31-bit address (214 7M bytes).
`In both versions, the Z8000 allows direct acce!!s
`to each address space. Direct access means that the
`addresses used in instructions or registers have as
`many bits as the address space size requires. In other
`schemes the effective address is a combination of a
`shorter field in the instruction and other extension
`bits often found in an implied register. Despite the
`shorter address fields, we believe this "indirect ac(cid:173)
`cess" does not save bytes, because extra instructions
`must be used to load and save the implied registers,
`which are typically in short supply.
`
`Registers. The Z8000 is primarily a memory-to(cid:173)
`register architecture. This characteristic does not en(cid:173)
`tirely exclude other organizations, and mechanisms
`exist in the Z8000 to support them. For example,
`memory-to-memory operations are supported for
`strings, whereas stack operations are supported for
`procedure and process changes. This choice provides
`upward compatibility with the Z80. A register ar(cid:173)
`chitecture also results in good performance, since
`register accesses are made at a greater speed than
`memory accesses in the current implementation.
`Experience with register-oriented machines seems
`to confirm that four general-purpose registers are not
`enough and that a "proper" number is between eight
`and 32.5 The Z8000 supports bytes, words (16-bit),
`and long words (32-bit), and a few instructions even
`use quadruple-word (64-bit) data elements. If we
`choose 16, 16-bit registers allow eight 32-bit registers
`as well as four 64-bit registers (Figure 1). Since ad(cid:173)
`dresses are 32 bits, the necessity of at least eight
`32-bit registers was obvious. The impact of the 4-bit
`register field on the instruction format depends also
`on the number of address modes and operands. Six(cid:173)
`teen registers allowed a reasonable tradeoff, whereas
`32 registers would have resulted in too few one-word
`instructions.
`With one minor restriction any register can be used
`by any instruction as an accumulator, source
`, operand, index, or memory pointer. This regularity of
`
`the structure is so important that it is worthwhile to
`sacrifice any possible encoding improvements in in(cid:173)
`struction formats which could result from dedicating
`registers to special functions. Encoding improve(cid:173)
`ments based on instruction frequency, so that fre(cid:173)
`quent instructions use one word, are more effective in
`saving space without having a negative effect on the
`architecture.
`
`Why not have specialized registers? The
`difficulty lies in the fact that the
`restrictions caused by dedication are
`inconsistent with one another.
`
`Most applications dedicate the available registers
`to specific functions. For example, most high-level
`languages require a stack pointer and a stack frame
`pointer. Then why not, one might argue, have
`specialized registers? The difficulty lies in the fact
`that the restrictions caused by dedication are incon(cid:173)
`sistent with one another. If the architecture supplies
`only general-purpose registers, the user is free to
`dedicate them to specific usages for his application
`without restrictions. This is important in the context
`of microprocessors where user applications are not
`well known and where high-level languages are still
`used infrequently.
`For example, the Z8000 allows software stacks to
`be implemented with any register. There are also two
`hardware supported stacks, but the registers used
`are. still general-purpose and can participate in any
`operation. There is no allocated stack frame pointer,
`since any register can be used by means of the proper ·
`combination of addressing modes. The savings realiz(cid:173)
`ed by register specialization are unattractive when
`the given function can still be performed simply. The
`loss that would result from restricting the applica(cid:173)
`tions would be too great. In contrast, significant sav(cid:173)
`ings result from excluding RO from use as an index or
`memory pointer. This exclusion allows one to distin(cid:173)
`guish between the indexed and direct addressing
`modes which use the same combination of the in(cid:173)
`struction address mode field. The price is small, since
`RO still can be an acumulator or source register and
`15 others accumulator, index, and/or memory
`pointers are available. In this case the restriction
`madesense.
`·
`Another decision to be made about registers is their
`size. Since the architecture handles multiple data
`types we must have multiple data register sizes,
`which can hold each data type. The solution of the
`problem is implemented in the architecture by pair(cid:173)
`ing registers, two 1-byte registers make a word
`register, two word registers make a long word
`register, etc.
`
`Data types. Users would like to have as many
`directly implemented data types as possible. A data
`type is supported when it has a hardware representa-
`
`COMPUTER
`
`12
`
`APPLE EX. 1023
`Page 3
`
`

`
`RHO
`RH1
`RH2
`
`RH3
`
`RH4
`
`RH5
`RH6
`RH7
`
`ni.7
`!
`
`RLO
`RL1
`'RL2
`RL3
`
`RL4
`
`RL5
`RL6
`RL7
`
`ol
`0
`
`ROO
`
`R04
`
`GENERAL
`PURPOSE
`REGISTERS
`
`RRO {
`
`RR2 {
`
`RR4 {
`
`RR6 {
`
`RRB {
`
`RO 17
`R1 15
`R2
`R3
`
`R4
`
`R5
`R6
`R7
`R8!15
`R9
`
`RR10 { R10
`R11
`
`RR12
`
`RR14
`
`{ R12
`R13
`
`I.::··
`
`R15 ,
`R15
`
`....... : ... ....,
`
`SYSTEM STACK POINTER
`NORMAL STACK POINTER
`SYSTEM STACK POINTER
`f'JORMAL STACK POINTER
`
`I
`
`I
`FLAG CONTROL WORD
`PROGRAM
`STATUS
`PCSEGMENTNO. · ~
`I
`PC OFFSET
`
`SEGMENT NUMBER -~A\'illll
`UPPER OFFSET . . . . . . . .
`1514
`98
`It
`I
`
`RATE
`
`COUNTER
`
`}
`
`PROGRAM
`STATUS AREA
`POINTER
`
`}REFRESH
`
`0
`
`Figure 1. CPU registers (segmented version).
`
`tion and instructions which directly apply to it. New
`data types can always be simulated in terms of basic
`data types, but hardware support provides faster and
`more convenient operations. At the same time, a pro(cid:173)
`liferation of fully supported data types complicates
`the.architecture and the implementations.
`The Z8000 supports several primitive types in the
`architecture and provides expansion mechanisms.
`The basic data types are obviously the ones expected
`to be used most frequently. The extended data types
`are built using existing data types and manipulated
`using existing instructions.
`The basic data type is the byte, which is also the
`basic addressable element. All other data types are
`referenced using their first byte address and their
`length in bytes. The architecture also supports the
`following data types: bytes (8 bits), words (16 bits),
`long words (32 bits), bytes, ,and word strings. In addi(cid:173)
`tion, bits are fully supported and addressed by
`number within a byte or word. BCD digits are sup(cid:173)
`ported an!l represented. as two 4-bit digits in 1 byte.
`One consequence of this data type organization is
`that byte, word, and long-word registers are needed
`
`to support them. The Z8000 even provides quadruple
`register-another extension-used in long-word
`manipulation.
`,
`Other data types are supported by using one of the
`preceding data types; for example, addresses are
`manipulated as long words, and each element (seg(cid:173)
`ment number or offset) can be manipulated as a byte
`or a word. Instructions are one to five-word strings,
`the program status is four words, etc.
`As the family grows, support for new data types
`will be added. The architecture will need to support
`them in its registers or in memory if they do not fit in
`registers (as strings are implemented today). But
`most important, the architecture will have to support
`the addition of new instructions to its repertoire.
`
`Instructions. In designing an instruction format
`the architect must decide how to allocate a limited
`number of bits to the opcode field, address mode field,
`and other operand subfields. Instruction usage
`statistics are the best source of data to influence deci(cid:173)
`sions about instruction set format. 1• 6• 7 Behind their
`usage lies a strong technical position: we do not
`
`February 1979
`
`13
`
`APPLE EX. 1023
`Page 4
`
`

`
`LD
`LOB
`
`ADD
`ADDB
`
`MODE
`
`. OPCODE
`
`REG
`
`I
`
`MODE
`OPCODE
`~:g~ I 0 I 1 I 0 I 0 I 0 I 0 I 0 ~BI 0 I 0 I 0 I 0 I
`I
`DA
`
`I
`
`REG
`
`I
`
`REG
`I
`
`I ONE
`WORD
`
`I TWO
`I WORDS
`
`JR
`
`cc
`
`I
`
`OPCODE
`I ONE
`CCIRA j1 I 1 11 I 0 I
`WORD
`Figure 2. Examples of instruction formats (nonsegmented version).
`
`RA
`
`I
`
`believe that any one of the various instruction set
`structures-register oriented, memory oriented,
`stack oriented, symmetrical, or asymmetrical,
`etc.-are always better when used exclusively. Thus
`the task of the architect is to decide what his most im(cid:173)
`portant goiils are, and for each of them adapt the best
`features of the various structures so that on the
`average, and for his set of goals, an optimum solution
`can be found. We do not believe that the optimum will
`be very sharp; it will be more like a range of applica(cid:173)
`tions for which the resulting composite structure
`works well. We decided to use a register structure for
`compatibility, multiple word instructions for speed,
`memory-to-memory instructions for strings, stack
`structure for process control and procedure support,
`"short" instruction for byte density improvement,
`etc.
`
`Instruction fonnat consideration. The Z8000 has
`over 110 distinct instruction types; several instruc(cid:173)
`tion formats are illustrated in Figure 2. The opcode
`field specifies the type of instruction (for example,
`ADD and LD). The mode field indicates the address(cid:173)
`ing modes (for example, Register (R), Direct Address
`(DA). The data element type (W/B) and register
`designator fields complete the basic instruction
`fields. Long word instructions use a different opcode
`value from their byte or word counterpart. Frequent
`instructions are encoded in a single word, and less fre(cid:173)
`quent instructions which use more than two
`operands use two words. There are often additional
`fields for 'special elements such as immediate values
`or condition code descriptors (CC). Instructions can
`designate one, two, or three operands explicitly. The
`instruction TRANSLATE AND TEST is the only one with
`four operands and is also the only one with an implied
`register operand.
`Several restraints can guide the proper choice of an
`instruction format. A large number of opcodes (used
`or reserved) is very important: having a given in(cid:173)
`struction implemented in hardware saves bytes and
`improves speed. But one usually needs to concen(cid:173)
`trate more on the completeness of the operations
`available on a particular data type rather than on ad(cid:173)
`ding more and more esoteric instructions which, if us(cid:173)
`ed frequently, will not significantly affect perfor(cid:173)
`mance. Great care must be given to the problem of ex(cid:173)
`panding the instruction set so, for example, new data
`types can be added.
`
`14
`
`Addressing modes. The Z8000 has eight address(cid:173)
`ing modes: register (R), indirect register (IR), direct
`address (DA), indexed (X), immediate (IM), base ad(cid:173)
`dress (BA), base indexed (BX), and relative address
`(RA). Several other addressing modes are implied by
`specific instructions such as autoincrement or auto(cid:173)
`decrement.
`Although a very large number of addressing modes
`is beneficial, usage statistics demonstrate that not all
`combinations of operands, address modes, and
`operators are meaningful. 6 The five basic addressing
`modes of R, IR, DA, X, and IM are the most frequent(cid:173)
`ly used and apply to most instructions with more
`than one address mode. For two-operand instruc(cid:173)
`tions, statistics show that most of the time the
`destination is a register. Other cases of addressing
`mode combinations and less basic addressing modes
`are associated -with special instructions. Thus, the
`frequent combination of autodecrement for the
`destination operand with the five basic address
`modes for the source operand is provided by the PUSH
`instruction. The combination of autoincrement ad(cid:173)
`dressing modes for both source and destination
`operands is one of the block move instructions. In
`essence, the address mode field space has been traded
`for opcode field space. This allows more instructions
`and combinations while staying within a one-word
`format.
`·
`The price for this tradeoff is the infrequent occur(cid:173)
`rence of pairs or triples of instructions simulating a
`missing addressing mode. This situation occurs in
`most instruction sets in any case.
`
`Code density. Because current microprocessors are
`restricted to primitive pipeline structures, their
`speed is largely dependent on the number of executed
`i11-struction words. Therefore, code density is not only
`important because of program size reduction but also
`because of speed improvement. One would like to en(cid:173)
`code in the smallest number of bits the most frequent
`instructions. The basic instruction size increment
`was chosen to be a word for reasons dealing with
`alignment, speed penalties, and hardware complexi(cid:173)
`ty. Thus the most frequent one and two-operand in(cid:173)
`structions take one word in their register or register(cid:173)
`to-register forms. Less frequent instructions or in(cid:173)
`structions which use more than two operands use at
`least two words.
`The Z8000 goes even further by selecting several
`special instructions as "short" instructions which
`take only one word, when normally they would take
`two words. These instructions, such as LOAD BYTE
`REGISTER IMMEDIATE and WAD WORD REGISTER IM·
`MEDIATE (for small immediate values), CALL RELA·
`TIVE, and JUMP RELATIVE, are SO frequent statistical(cid:173)
`ly that they deserve such special treatment.
`A one-word JUMP RELATIVE and DECREMENT AND
`JUMP ON NON-ZERO also have a very significant impact
`on speed. The short offset mechanism used by ad(cid:173)
`dresses (and described below) is also designed to
`allow one-word addresses. Compared to previous
`microprocessors, the largest reduction in size and in(cid:173)
`crease in speed results from the Z8000's consistent
`
`COMPUTER
`
`APPLE EX. 1023
`Page 5
`
`

`
`and regular structure of the architecture and from its
`more powerful instruction set-which allows fewer
`instructions to accomplish a given task.
`
`(a)
`
`r-15~------------__,.:;0
`
`High-level language support. For microprocessor
`users, the transition from assembly language to high(cid:173)
`level languages will allow greater freedom from ar(cid:173)
`chitectural dependency and will improve ease of pro(cid:173)
`gamming.8 It is easy and tempting tp adapt a com(cid:173)
`. puter architecture to execute a particular high-level
`language efficiently;9 Most programming languages
`act as a filter and can be supported by a subset of
`available hardware with greater efficiency .10 But effi(cid:173)
`ciency for one particular high-levellangilage is likely
`to lead to inefficiency for unrelated languages. The
`ZBOOO will be used in a wide variety of applications,
`and we know that a large number of users will still be
`using assembly languages. Since the Z8000 is a
`general-purpose microprocessor, language support
`has been provided only through the inclusion of
`features designed to minimize typical compilation
`and code-generation problems. Among these is the
`regularity of the Z8000 addressing modes and data
`types. The addressing structure provided by segmen(cid:173)
`tation should support procedures that result from
`structured programming. Access to parameters and
`local variables on the procedure stack is supported by
`index with short offset address mode as well as base
`address and base indexed address modes. In addi(cid:173)
`tion, address arithmetic is aided by the INCREMENT
`BY 1 TO 16 and DECREMENT BY 1 TO 16 instructions.
`Testing of data, logical evaluation, initialization,
`and compt¢son of data are made possible by the in(cid:173)
`structions TEST, TEST CONDITION CODES, LOAD IM·
`idEDIATE INTO MEMORY, ,and COMPARE IMMEDIATE
`WITH MEMORY. Compilers and assemblers
`manipulate character strings frequently, and the in(cid:173)
`structions TRANSLATE, TRANSLATE AND TEST, BLOCK
`COMPARE, and COMPARE STRING all result in dramatic
`speed improvements over software simulations of
`these important tasks, especially for certain types of
`languages. In addition, any register can be used as a
`stack pointer by the PUSH and POP instructions.
`
`Segmentation. In order to provide for convenient
`code generation and data access, addresses must also
`be e11.sy to manipulate. Architectures with direct ac(cid:173)
`cess to memory tyPically use a linear address space,
`so that address arithmetic may be used on the entire
`address. In this case, addresses are manipulated as
`one of the data types of the same size. This removes
`the need to distinguish an address as a new data type.
`In contrast, the ZSOOO has a non-linear address space.
`Addresses are made of two parts: a 7-bit segment
`number and a 16-bit offset. Only the offset par(cid:173)
`ticipates in address arithmetic. The segment number
`is essentially a pointer to a part of the total address
`space, which can vary in size from 0 to 64K bytes. The
`hardware representation of a segmented address is a
`long word or a register pair (Figure 3), which allows
`the easy manipulation ofeach part of the address.
`The. segmented addresses are one of the key
`mechanisms useq to suppOrt both large and small
`
`February 1979
`
`6
`
`0 7
`
`0
`
`(b)
`
`._ I ~L-.1..-'--.L..:-l.' I _O._,F_._\S_ET,_I .J..I -'-..l..l --ll--'-...l-..11
`
`} REGISTER PAIR
`OR LONG WORD
`
`0
`0 7
`6
`111
`• 0
`I
`I
`'
`I
`I
`I
`•
`SEGMENTNO. - ·
`15
`._I _.__.__.___.__.__1-.J..?F...J~,_sE_._T...Ji-..J...._I-.J.....Ji-.J.....JI
`
`(c)
`
`6
`
`(d) I 0 I 'SE,GM,EN! N,O. I I ' SIHO,RT ,OF~S~T
`
`0 7
`
`0
`
`I
`
`Figure 3. ·Hardware representation of segmented addresses. Any non·
`segmented addr!!SS is one word, whether it is in a register, memory,
`or an instruction (Figure 3a). Segmented addresses are always two
`words in a register or memory (Figure 3b); however, Instructions can
`have one of two forms. The usual case (long offset) requires two
`words (Figure 3c); however, there Is also a short offset form that uses
`only one word (Figure 3d).
`
`memory systems efficiently. The two versions of the
`Z8000 implementation, the 40-pin unsegmented and
`the 48-pin segmented, allow the maintenance of the
`architectural compatibility and ease the growth be(cid:173)
`tween these two application groups. The segmented
`address space guarantees that each 64K-byte ad(cid:173)
`dress space of the 40-pin version becomes one of the
`segments of the 48-pin version. Each 4()-pin version's
`16-bit address becomes an offset within the segment,
`and a mode exists ~ the 48-pin package version in
`which 40-pin version code can be executed. Further(cid:173)
`more, compatibility with any current 8-bit micro(cid:173)
`processor such as the Z80 is easy, and a new micro(cid:173)
`computer such as the Z8 can address external data in
`a shared segment with the Z8000.
`The hardware performance of the ZSOOO is also im(cid:173)
`proved by address segmentation. Since a segment
`number does not participate in arithmetic, it can be
`put on the bus before the result of ari address com(cid:173)
`putation is available. This feature allows the use of
`MMUs with essentially no impact on memory access
`time by allowing it to function in parallel with the
`CPU. Indexing operations are also faster because on(cid:173)
`ly a 16-bit addition must be performed. Because of
`the distinction between the segment number and its
`offset, one can use shorter addresses without soft(cid:173)
`ware constraints. Short addresses can use a short off(cid:173)
`set (fewer than 256 bytes) ·and thereby reduce pro(cid:173)
`gram size (Figure 3).
`Finally, it is very easy to associate with each of the
`128 segments of the address space the protection and
`dynamic relocation features desirable for larger sys(cid:173)
`tems. Relocation allows a user to Write his application
`using logical addresses independent of any physical
`addresses. Relocation is essential, for example, in a
`disk-based general data processing system with
`several users. Relocation is not essential for
`dedicated applications with code typically residing in
`
`15
`
`APPLE EX. 1023
`Page 6
`
`

`
`6
`
`0
`
`15
`
`8 7
`
`0
`
`LOGICAL ADDRESS
`
`SEGMENT NO.
`
`fMEMoR~ ~-- ---
`l ~:~~AGEMENT,..--------"'-----,
`
`I
`I
`
`BASE
`ADDRESS
`MEMORY
`
`ADD
`
`15
`
`1 00000000 i
`
`23
`
`)'
`- --- - - ~~---__....
`Figure 4. Logical to physical address translation.
`
`ROM. Users whose total memory needs are small are
`also unlikely to need relocation.
`In summary, the choice of a segmented address
`space has provided-at low cost and with few prac(cid:173)
`tical limitations-a powerful solution to the problem
`of user growth, relocation, and protection as well as
`virtual memory implementation. We believe that a
`linear address space could have achieved these
`results but at a considerably higher price.
`
`The system architecture
`
`Protection facilities. The Z8000 protection
`facilities can be divided into system protection
`features and memory protection features. Ex(cid:173)
`perience with large computers has demonstrated the
`advantages of having at least two execution modes
`with different access rights to hardware facilities.
`The Z8000 provides the system and normal modes for
`this purpose. A simple protection system results
`from the presence of these two modes and their
`
`16
`
`associated stacks. A special class of "privileged" in(cid:173)
`structions is defined, which deals with 1/0, inter(cid:173)
`rupts, traps, and mode changes. Programs in normal
`mode which attempt to execute a privileged instruc(cid:173)
`tion will cause a trap and a change to system mode.
`The switch from user to system mode can also be
`caused by the system call instruction. These
`mechanisms enforce protection and help in designing
`reliable and efficien