[Next] [Up] [Previous] [Next Section] [Home] [Other]

The Concertina II Architecture

Welcome to the home page of the Concertina II computer architecture.

The original Concertina computer architecture was originally intended as a simple example of a conventional old-style CISC architecture, to help explain how computers work. It was expanded over time to include many features from a wide selection of historical computer architectures, to explain those as well.

Concertina II was intended as an ISA that could conceivably be of practical use in an actual implementation. However, I cannot make ambitious claims for it, as my experience in this area is quite limited. This architecture went through quite a number of drafts before I felt that I had struck an acceptable balance between the various factors that had to be compromised to provide the architecture with the capabilities I sought.

However, I believe that the current version of the ISA is a sound basis on which to proceed, and I only expect to be changing it with minor tweaks as I continue to flesh out the architecture and describe its features.

Once I have it completed, it may serve as an alternative to RISC-V, even though the designer of that architecture is far more knowledgeable and experienced than I am. This is because I feel it may at least suit some people's tastes more than RISC-V does.

Introduction

What is the Concertina II ISA, and what choices were made in its design?


The Concertina II design is still unfinished; many parts of it are yet to be described, and, although I do not intend to tear it up and start afresh, as I no longer feel I will be able to do better, it is still subject to minor tweaks.

It will be freely available to all to implement without restrictions once completed, subject to export controls on computer technology.


The basic Concertina II instruction set is largely patterned after today's most popular type of ISA (instruction set architecture) design, RISC (reduced instruction set computing), but it does not qualify as a genuine RISC design by any reasonable contemporary definition of RISC, even the least puristic.

The basic instruction set consists of 32-bit instructions, but also adds the ability to use a pair of 16-bit instructions at any point in the sequence of instructions in place of a 32-bit instruction.

This allows increasing code density by using smaller instructions for many operations, without losing the simplicity of fetching and decoding instructions gained by having all instructions of the same length.

As in many RISC designs, there are two main register files, one for integer values (with registers that are 64 bits wide) and one for floating-point values (with registers that are 128 bits wide), each of which contains 32 registers.

Also, the memory-reference instructions are of the load-store variety, following standard RISC practice.

The following extensions to the RISC model are included in the most basic portion of the instruction set:

It is precisely because base-index addressing is provided by restricting potential index registers to registers 1-7, and potential base registers to groups of 7 (which group depends on the displacement length) that this design does not qualify as RISC, and instead could be called CISC in RISC clothing.

Typically, RISC architectures normally only allow two registers to be indicated in a memory-reference instruction. One is the destination register of the instruction, and the other one is the one the contents of which are added to the displacement to form the effective address, Since a base register is needed for any memory access when the displacement is not large enough to indicate any location in the available memory, this means that the advantage of having an index register isn't available, and array access require additional explicit arithmetic instructions to compute addresses.

Thus, since the use of arrays is a very common operation, full base-index addressing was considered a very important feature to add.

In order to make it possible to provide this feature, the integer registers were split up into groups of eight so that the index register and base register fields could be only three bits long instead of five bits long, thus allowing both to fit in an instruction.

Normally, if one allocates a block of memory containing 65,536 bytes, using a base register to point to that block, it is not useful to have addressing modes that can only access the first 4,096 bytes of that block. Therefore, separate groups of registers are used as the possible base registers for different sizes of displacement values.

Only one register serves as the implicit base register for 15-bit displacements; this is done to allow one larger block of memory to be used in conjunction with those accessed with 12-bit displacements. This permits more compact memory-reference instructions, and is inspired by the System/360 Model 20 computer.


The above summarizes how the basic instruction set of this computer was designed to take the basic RISC design, and offer important extensions to it, while still having instructions that fit in 32 bits.

But a number of other extensions are also offered. These require going beyond the somewhat RISC-like model of the basic instruction set, and instead recognizing that this architecture also has VLIW (Very Long Instruction Word) characteristics.

Instructions are grouped in blocks of 256 bits, each of which contains eight 32-bit instruction slots. If feasible, an implementation aiming for maximum performance should have at least a 256-bit data bus to main memory, permitting a block of instructions to be fetched at once.

A small portion of the opcode space for instructions is dedicated to codes which represent headers instead of instructions.

Headers, if any, are processed before the instructions in a block are decoded.

After the headers are processed, or after it is determined that the block does not begin with a header, the computer has the information required to decode all the instructions in the block in parallel.


One of the most important features that having headers provides, which is still considered part of the basic instruction set of the Concertina II architecture, is pseudo-immediate values.

Some register-to-register instructions may have a source register specification replaced by a five-bit byte pointer to an address within the current instruction block, which points to an operand for that instruction.

This capability is supported by headers which contain a three bit decode field, which indicates that some of the eight 32-bit instruction slots in the current block are to be ignored during instruction decoding, and skipped over in execution, so that pseudo-immediate values can be placed in them.


What are pseudo-immediate values, and why are they included in this ISA? Essentially, they are inspired by the Heads and Tails design of Heidi Pan. As Mitch Alsup has reminded us all in the design of his "My 66000" ISA, immediate mode instructions have the advantage that a constant value can be used in a calculation without requiring an additional fetch of data, with all the delays and overhead of memory accesses in modern architectures, where DRAM is slow compared to processor logic.

This is because the immediate value is part of the instruction itself, and thus has already been fetched as part of the instruction stream.

But since data items come in several widths, comprehensive support of immediate values means that instructions must come in many different lengths, and I felt this would complicate their decoding to an unacceptable extent.

With pseudo-immediate values, the length of the instruction doesn't have to be changed. A pointer to the value only takes up the same space as a register specification.

But if the value is fetched from a location indicated by a pointer, it isn't an immediate value any more. Hence the term "pseudo-immediate" - given that instructions are fetched from memory in 256-bit blocks, and the data to which the pointer refers is within the same block as the instruction itself, even though the values are not actually immediate values, they still offer the same basic advantage as immediate values. (To some extent, of course, this depends on how the implementation handles the instruction stream. Specifically, to gain the full advantages of this, the entire block needs to be buffered within the processor during instruction decoding.)


In addition to pseudo-immediate values, headers allow two basic sets of features to be added to the ISA that go beyond the RISC model.

Thus, while the architecture initially has the appearance of a conventional RISC architecture, it is intended to combine the basic features and advantages of RISC, CISC, and VLIW architectures.

Note, however, that by VLIW, I mean modern VLIW architectures, such as the Itanium or, even more particularly, the Texas Instruments TMS320C6000 chip, and not the type of classic VLIW architecture the term was originally concieved of as referring to, such as that of the Control Data Cyber 200 computer.

Given that both the Itanium and the i860 were failures in the marketplace, despite being backed by the might of Intel, it is understandable that some might doubt my sanity in proposing a VLIW design in this day and age.

However, instead of including a break bit in every instruction, the break bits are in an optional header at the beginning of a 256-bit block of instructions. Implementations don't need to be designed around VLIW operation, but they can be, if they are aimed at a niche where a VLIW design is appropriate.

The Architecture

There are 32 integer general registers and 32 floating-point registers, and those instructions that perform arithmetic or logical operations include a bit for enabling changes to the condition codes as a result of those instructions. These are characteristics found in RISC architectures.

Having register banks of 32 registers allows different calculations to be intertwined in the code, and being able to control if instructions affect the condition codes allows more intervening instructions between an instruction that sets the condition codes and a branch instruction that makes use of those results. Both of these things allowed code to be designed to offer some of the same benefits as are obtained from out-of-order execution, without the hardware overhead. However, at the microprocessor clock rates in use today, these measures normally are not enough to be effective: however, if code written this way is combined with simultaneous multi-threading (SMT), then there is still the potential for competing with out-of-order execution.

Also, the architecture provides extended register banks of 128 integer registers, 64 bits in width, and 128 floating-point registers, 128 bits in width, which will also promote efficient VLIW operation.

Block Organization

Instructions are organized into 256-bit blocks which contain eight 32-bit instruction slots.

These blocks are always aligned on the boundaries of aligned 32-byte areas in memory, so an instruction slot that may contain the initial header of a block must have an address the last five bits of which are zero.

When a block header makes provision for instructions longer than 32 bits, it is possible that these instructions may cross block boundaries, depending on the rules applicable to the particular block header format in use. Specifically: the Type I block header does allow instructions to cross block boundaries; as these block headers support related instruction sets, it is also possible for instructions to cross from a block beginning with one of these three types of header into an instruction block beginning with this kind of header. In this case, the instruction set available is determined by the nature of the block in which the instruction begins; that it may continue into a block in which an instruction of its type cannot be indicated is not to interfere with its successful execution in a conformant implementation.

The instruction set is organized so that the computer is able to fetch a 256-bit block of instructions, and, after processing any block header within the block, to determine what, if any, special processing is required, immediately begin decoding each 32-bit instruction slot independently of the others in the block.


A block which does not have a block header, such as are shown in a diagram to follow shortly, may contain 32-bit instruction slots the contents of which begin with the bits 1111100. In which case, the first eight bits in the instruction slot have the meanings:

11111000 The first half of a 48-bit instruction
11111001 The second half of a 48-bit instruction

which allows 48-bit instructions to be included in code without headers. Only code blocks with no headers may include long instructions in this form, which may cross block boundaries, as long as both blocks involved do not have a header. A different coding scheme will be noted below that allows 48-bit, 64-bit, or longer instructions to be included among the instructions within blocks having Type II, IV, and Type V headers, which do not themselves provide for variable-length instructions. This only applies to Type II headers if the M bit is not set.


There are seven different types of block header, which are shown in the diagram below.

Seven types of header are illustrated in this diagram. Three of them, types I, II, and IV, are required to provide the primary functionality that will be described here. The seventh one, although described here, is not a part of the architecture as currently defined; it may be added in future to permit an expansion of the instruction set. The third one is for the purpose of adding an emulation feature to the architecture. The fifth and sixth ones are to allow a mode of operation which, while not involving the emulation of any other instruction set, still facilitates the conversion of programs for certain other instruction sets, at least at the high-level language level, by causing instructions to work with data of sizes associated with an alternative memory width.


The first type of header allows for instructions of different lengths to be freely mixed. This is achieved by having fourteen two-bit prefix fields in the header, each of which corresponds, in order, to the remaining 16-bit halves of the seven remaining instruction slots in the current instruction block.

These fields each indicate what is contained in the corresponding 16-bit area of the instruction block, and are interpreted as follows:

00 A 17-bit instruction starting with 0
01 A 17-bit instruction starting with 1
10 The start of an instruction 32 bits in length or longer
11 Not the start of an instruction

Note that the prefix value of 10 must always be followed by the prefix value of 11. An invalid combination where this is not the case, 11111010, is used to distinguish the remaining types of header, so as to avoid the need for additional opcode space for those headers, and another invalid combination where this is not the case, 1111100, is used, as noted above, to distinguish 48-bit instructions in the body of code without headers.

Also note that the prefix code 01 may also indicate the start of an additional instruction longer than 32 bits which is located within some opcode space not used by the 17-bit short instructions.


The second type of header provides supplementary information which allows the computer to provide VLIW functionality.

The primary feature of this type of header is to provide for VLIW features which can be used to accelerate the speed of instruction execution, particularly on lightweight implementations of the architecture which lack out-of-order execution.

There are seven bits marked B, for break; they correspond to the seven remaining 32-bit instruction slots in the block, and if a bit marked B is set, this indicates that the instruction in its corresponding instruction slot may not be executed in parallel with the instructions that precede it.


Important note: it is intended that this ISA may be implemented in a number of ways. Specifically, in relation to the VLIW feature of the break bit, these three classes of implementations are possible:

  • Implementations without superpipelining (that is, pipelining of the execution of instructions; a pipeline that breaks instructions into fetch, decode, and execute, performing fetch and decode of subsequent instructions in parallel with the execution of one instruction is still possible) or superscalar capabilities, which simply execute instructions serially one after another, and thus ignore the break bit as they cannot execute instructions in parallel;
  • Implementations where the break bit materially speeds up execution, by allowing more efficient pipelining of instructions;
  • Implementations which have out-of-order execution, guided by a full set of interlocks, which do not require explicit guidance from break bits for the optimum execution of a sequence of instructions.

In consequence, any programs which would produce a different result on the first two types of implementation listed above are to be considered to be invalid programs which have been written incorrectly.

Thus, the architecture specification requires implementations to execute code which does not contain any explicit indications of parallel execution with sequential consistency.

When code does contain such indications, implementations may follow those indications, or they may execute the code sequentially, even if different results are produced in the two cases; it is the programmer's responsibility, if consistent model-independent execution of programs is desired, only to indicate parallelism where it does not lead to results different from those of completely sequential code.


In this header format, there is also a four-bit flag field. This indicates which of the sixteen flag bits may be used for predicating instructions in this block. A seven-bit predicated field indicates which instruction slots contain an instruction the execution of which is conditional, based on that flag bit. There is also a bit marked S, for sense; if that bit is zero, a predicated instruction will execute if and only if the selected flag bit is set (equal to 1); if it is one, the predicated instruction will instead execute if and only if the selected flag bit is cleared (equal to 0).

The decode field has its usual meaning in this header.

The M bit, if set, indicates that the executable code in the current 256-bit program block is in a modified form of the instruction set in which opcode space is created, by limiting the options for some instructions, for paired short instructions of the following form: in a 32-bit instruction slot, one floating-point operate instruction and one integer operate instruction are placed; as these each use a different ALU and a different register bank, they may always execute in parallel, and thus conform well to the objectives of code using the Type III header, which is aimed at obtaining faster execution by explictly indicating opportunities for parallel execution.


There is a provision for allowing the execution of instructions longer than 32 bits in blocks with this type of header; it is not particularly efficient, but it avoids the complexity of defining an additional header type. Since the extended register banks of 128 registers are particularly useful in code designed to be efficiently pipelined without the use of advanced out-of-order execution techniques, and many of the instructions designed to make full use of those registers are 48 bits long, it appeared that this feature was useful to provide.

To execute an instruction that is 48 bits or longer within a block with a Type II, Type IV, or Type V header, the following is required:

The executable 32-bit instruction slot corresponding to the place in the instruction stream where this long instruction is to be executed shall contain:

This technique is possible since instructions 48 bits in length or more are distinguished from regular 32-bit instructions by their first few bits within blocks with a Type I header, where they normally occur; specifically, they always start with 1111. This excludes the group of 48-bit instructions associated with the prefix bits 01 in a Type I header.

The five bit pointer is in units of bytes, thus 0 refers to the start of the current 256-bit instruction block, 1 to the next 8 bits, up to 31 for the last 8 bits in the instruction block. The first few possible values, of course, would never be used; 0, 1, 2 and 3 are within the header, and 4, 5, 6, and 7 are within the first possible executable instruction, so they can never be valid.

The three zero bits can be replaced by 001, 01x, or 1xx to permit the specification of additional long instructions, or (which takes priority) the five-bit pointer can be replaced by 00xxx to allow the specification of additional instructions which remain entirely within the 32-bit instruction slot.

Such additional instructions, if defined, will serve specialized purposes such as privileged operations.

In the case of a block with a Type II header, the M bit must not be set to use this technique.


The third type of header is used to assist with emulation and emulation-related tasks.

The instruction start field and the E bit are used to permit variable-length instructions, with a granularity of a 16-bit unit, to be used with this type of block. Each bit in the instruction start field corresponds to one of the 16-bit areas in the remainder of the block, in order, and if it is a 1, it indicates that the 16 bits to which it corresponds are the first 16 bits of an instruction.

The X bit is used to exclude 16-bit areas of the block from decoding, performing the same function as the decode field in other headers. It does so as follows: if the X bit is a 0, then no 16-bit areas are excluded; all are decoded. If the X bit is a 1, then the last 16-bit area in the block is not decoded, and as well, all 16-bit areas in the block, if any, corresponding to bits in the instruction start field which are part of a continuous string of bits, all having the same value, 0 or 1, as the last bit of the instruction start field, and including that last bit as part of the string of bits, are also not decoded. In this way, the last bit of the portion of the instruction start field which corresponds to a 16-bit area that is decoded may have either value, 0 or 1.

The E bit, if set, indicates that the last instruction starting in the current block is complete within the block, and so may be decoded and executed before the next program block is read.

The iset field indicates the instruction set to which the instructions in the remainder of the block belong.

The possible values are:

00 The normal instruction set, as used with a Type I header or with no header, with the exception
   that 17-bit short instructions are excluded;
01 A modified form of the normal instruction set in which opcode space is reserved for 16-bit
   short instructions;
10 An instruction set applicable to certain legacy mainframe systems; and
11 An instruction set used with certain popular home computers which retain a following to this
   day.

The two instruction sets indicated by 10 and 11 consist of instructions of differing lengths, where each length is a multiple of 16 bits.

The C bit, if set, indicates that the Compatible floating-point type, rather than the Standard floating-point type, is the primary floating-point type for the code in this block. For iset values of 00, 01, and 11, this causes the Compatible and Standard floating-point types to be swapped in each applicable instruction if it is set. For the iset value of 10, however, it causes the two types to be swapped when it is cleared.

The R bit, if set, changes the interpretation of references to floating-point registers 0 through 15. References to floating-point registers 16 through 31 are unaffected.

Normally, it will only be used for an iset value of 10, although it may be used with other iset values, primarily to permit exchange of values in registers with code in that instruction set with this feature enabled.

When this bit is set, for the instructions starting in the block, the first sixteen floating-point registers, as seen by the program, are changed from 128-bit registers to 64-bit registers, and they are placed in pairs in the first eight actual 128-bit floating-point registers of the machine. Registers 16 through 31 are not changed.

This affects instructions operating on both the Standard and the Compatible floating-point formats.

The purpose of this is to enable code with this header type to interface with code running in emulation mode for one particular computer architecture.

The locations of the 64-bit registers within the 128-bit registers are shown in the table below:

128-bit   64-bit
register  registers

0          0, 2
1          4, 6
2          8,10
3         12,14
4          1, 3
5          5, 7
6          9,11
7         13,15

This arrangement stems from the historical characteristics of the architecture being emulated; originally, it only had four floating-point registers, and they were numbered 0, 2, 4, and 6, and so when a register pair was needed to contain floating-point numbers 128 bits in length, of a type later introduced, only even-numbered registers were available out of which to build the register pair that formed an effective register 128 bits in length.

A pictorial representation of this arrangement is shown below:

The rightmost portion of the image is after Figure 2-2 on page 2-5 of the Ninth Edition of Enterprise Systems Architecture/390 Principles of Operation, publication SA22-7201-08, by IBM.

A block header with this bit set also modifies the behavior of floating-point instructions involving the Standard floating-point type in another important way. Since the first sixteen registers are now only 64 bits long, floating point values in these registers will be in the same form as they are kept in main memory, and will not be converted to internal form on being loaded, and from internal form on being stored.

The conversion will remain in place for registers 16 through 31, since the purpose of this block format is to facilitate communication between programs running in emulation mode and ordinary programs. Thus, instructions operating on 128-bit floats in the Standard floating-point type will continue to use the internal form of floats without a hidden first bit, rather than the IEEE 754 standard format for 128-bit floats.

The bit marked T, if set when the iset field contains 10, will cause all floating-point instructions, except (in the case of those for the Compatible floating-point format) those associated with the High Accuracy Arithmetic feature (an RPQ offered by IBM for certain models of the IBM System/370 computer), to produce truncated results instead of rounded results; if set when the iset field contains 01, it will do also do this for all floating-point instructions for operands in the Compatible floating-point format only.

In the case of floating-point operations with the Stanard floating-point type, while operations within the code 10 instruction set do exist which perform truncation, this is due to a two-bit field in the instruction indicating a rounding mode; there is no case where truncation is preferred so as to be given shorter instructions to perform operations which truncate, and so it is not useful to allow the T bit to have an effect on these operations when iset is 10.

The use of the T and C bits permits, should it be so desired, the use of the instruction set associated with the iset value of 10, in which the 16-bit floating-point operate instructions only work with the Compatible floating-point format and which produce truncated results to be effectively replaced by floating-point instructions that work with the Standard floating-point format and/or produce truncated results, so that if this type of floating-point operation is more desired, greater code compactness may be obtained.

The bit marked A indicates that a scheme of address modification is in use, so that programs which include branch addresses can be placed in these blocks without modifying those addresses to reflect the fact that the program code is no longer fully contiguous, but is interrupted by headers. Addresses are modified, or not, when this bit is set depending on which base register is in use.

An address is modified if the base register specified in the instruction generating the address contains a 1 as its first bit. The value in the register exclusive of that first bit is what is used in generating the address.

That which is added to the base register value is what is modified, as formed from the displacement in the instruction, and the contents of the specified index register, if indexing is specified.

Modification proceeds as follows:

The least significant bit of the address, indicating which byte of a 16-bit halfword is selected, is passed through unchanged to form the least significant bit of the modified address.

The remainder of the address (which can be considered to have been shifted one bit right) is multiplied by the binary constant 100100101. This involves adding together four copies of the address at different shifts. This binary constant is 256 plus 32 plus 4 plus 1, or 293.

The last nine bits of the product are then converted to a value according to the following table:

From       to         Result
000000000  000100100  0001
000100101  001001001  0010
001001010  001101110  0011
001101111  010010011  0100
010010100  010111000  0101
010111001  011011101  0110
011011110  100000010  0111
100000011  100100111  1000
100101000  101001100  1001
101001101  101110001  1010
101110010  110010110  1011
110010111  110111011  1100
110111100  111100000  1101
111100001  111111111  1110  

The previous part of the product, concatenated with this four-bit value, concatenated with the last bit, produces an address within the last fourteen halfwords of a given instruction block. Sometimes the last halfword is skipped.


The fourth type of header also functions as a two-operand register-to-register operate instruction, as well as a header which, with its decode field, specifies the number of 32-bit instruction slots at the end of the block which are not decoded as instructions, but are instead reserved for other purposes, such as the data values for pseudo-immediates.

The decode field is used to indicate the number of 32-bit instruction slots that are reserved for data other than instructions, such as pseudo-immediate values, for which no attempt is to be made to decode them as instructions. A value of 000 in the decode field indicates that all the remaining instruction slots are to be decoded as instructions; a value of 001 indicates the last instruction slot is to be reserved, and not decoded, and so on.

An immediate value in an instruction allows it to perform an arithmetic operation involving a constant without having to perform a fetch of data from memory in addition to the fetching from memory already performed as part of reading in the instruction stream.

An important design goal of the Concertina II architecture has been to drastically simplify the decoding of instructions; once a 256-bit instruction block has been checked for a header, and that header, if present, has been processed, all the instructions in the block can be decoded in parallel independently. The varying lengths of different data types mean that including a wide selection of instructions with immediate values would conflict with this.

A pseudo-immediate is addressed by a pointer in the instruction, which seems to be the same thing as a memory-to-register instruction making use of a constant value stored somewhere else. However, the pointer is a short-range one, which only points to a location within the same 256-bit instruction block as the current instruction is contained in.

Therefore, although it involdes a pointer reference, and thus is not "really" an immediate, hence the name "pseudo-immediate", it provides the same advantage of the constant argument having been fetched as part of the instruction stream!

This fourth type of header reserves space for these constants which therefore won't be decoded erroneously as instructions, and because the header is also an instruction, it lets these three bits of information be provided without the overhead of using a full 32-bit instruction slot for a header and nothing else.


The fifth and sixth types of header contain a length field, which relates to the primary purpose of these header types.

The length field is interpreted as follows:

Field    Integer Type Widths         Floating Type Widths    Addressing
Value                                                        Unit Width

000        8   16  32  64             48  32  64  128          8

010        6   12  24  48             72  48  96 (192)         6
011        6   12  24  48             48  36  60  120          6

100        9   18  36 (72)            54  36  72 (144)         9
101        -   15  30  60             45   -  60  120         15
110       10   20  40 (80)            60  40  80 (160)        10

as it applies to operate instructions which do not reference memory.

Where the width of operands in the long integer type or the extended floating-point type is enclosed in parentheses, this means that such operands are associated with register pairs rather than single registers.

In the case of the Type V header, the bits in the affected field indicate, when they contain a 1, that the instruction in the corresponding instruction slot operates on data with the alternate width as indicated by the length field. This is always true for operate instructions with a Type VI header.

The Type VI header allows for instructions of varying widths in the same fashion as the Type I header.

In the case of memory-reference instructions, the operand and memory widths which apply to them are determined by the contents of the base register in use for the instruction. In the case of the Type V header, this takes precedence over the bits in the affected field, and in both the Type V and Type VI headers, it also takes precedence over the length field in the header. The most significant four bits in base registers (for all displacement sizes, 12, 15, 16, or 20) have the following format:

The first, most significant, bit must be 1 to permit an alternate width to be used.

The next three bits are coded in the same fashion as the length field of the header. In addition, if those three bits are 111, then the base register contents, including the leading four bits, are included in the address, and the instruction operates with the standard widths. This is so that I/O operations can be performed normally on addresses in the highest portions of the memory address space.

When an alternate data width is specified within a base register, the least significant 60 bits of its content are an address in an alternative address space. Memory belonging to these address spaces, for whatever data withs a program may use, is provided to programs by the operating system through the memory paging feature of the processor. The means by which different memory widths are simulated are model-dependent.

Note that it is possible that the base register used with a Jump instruction could indicate that the branch is to take place into memory with an alternate width. It is for this eventuality that the iset field is provided in the block header; it indicates, for each specific memory width option, which instruction set is to be emulated going forward after the branch.

If the iset field contains 000, this indicates that branches to memory with an alternate width are errors, and are to cause an exception.


The seventh type of header, should it come to be used, will function as follows:

The decode field may contain a number from 0 to 24, indicating the number of bytes reserved at the end of the current 256-bit instruction block for pseudo-immediates or other supplementary data.

The instruction start field contains one bit corresponding to each remaining byte in the current instruction block after the header. Normally, if a bit in this field is a 1, it means that byte begins an instruction. However, there is an important exception to that rule. Remember that short instructions in this architecture are 17 bits long, rather than 16 bits long. Since there are no 8-bit instructions, a 17-bit instruction can be unambiguously indicated by immediately following the 1 which indicates the start of the instruction by another 1.

This same technique is applicable to other lengths of instructions. So this type of header increases the opcode space available for instructions in several ways:

The bit marked E is a 1 if the block is followed by either

The purpose of this bit is to permit the immediate decoding and execution of the last instruction in the block if it is complete within the block, but no subsequent instruction starts within the block to unambiguously indicate that it is complete.

The bit marked P is 1 only if the block is preceded by a block with a header of Type V, and the portion of the instruction start field in that block not excluded by that block's decode field from those which correspond to bytes containing instructions ends in an odd number of ones.

The purpose of this bit is to simplify the use of the instruction start field in the current block for instruction decoding by preventing apparent ambiguities at the beginning because of it not being possible to easily distinguish, when there are several 17-bit instructions starting with 1 in a row, whether it is the 1 bits in even or odd positions which start new instructions.

Registers and Data Formats

The basic complement of registers included with this architecture is as follows:


There are 32 integer registers, each of which is 64 bits in length, numbered from 0 to 31.

Registers 1 through 7 may be used as index registers.

Register 8 serves as a pointer to a table of pseudo-operations, if this feature is used.

Registers 9 through 15 may be used as base registers, each of which points to an area of 1,048,576 bytes in length. This addressing format is used for 48-bit extended memory-reference instructions.

At least part of the area of 3,072 bytes in length pointed to by register 16 will normally be used to contain up to 384 pointers, each 64 bits in length, for use in either Array Mode addressing or Address Table addressing.

Registers 17 through 23 may be used as base registers, each of which points to an area of 4,096 bytes in length.

Register 24 serves as a base register which points to an area 32,768 bytes in length.

Registers 25 through 31 may be used as base registers, each of which points to an area of 65,536 bytes in length.


There are 32 floating-point registers, each of which is 128 bits in length, numbered from 0 to 31.

Floating point numbers in IEEE 754 format have exponent fields of different length, depending on the size of the number. For faster computation, floating-point numbers are stored in floating-point registers in an internal form which corresponds to the format in which extended precision floating-point numbers are stored in memory: with a 15-bit exponent field, and without a hidden first bit in the significand.

As 128-bit extended floating-point numbers are already in this format in memory, all floating-point numbers will fit in a 128-bit register, although shorter floating-point numbers are expanded.

However, the 32 floating-point registers may also be used for Decimal Floating-Point (DFP) numbers. These numbers will also be expanded into an internal form for faster computation, but that internal form may take more than 128 bits.

This is dealt with as follows: Only 24 DFP numbers that are 128 bits in length may be stored in the 32 floating-point registers. When such a DFP number is stored in an even-numbered register, it is stored in that register, and the first 32 bits of the following register. When it is stored in a register the number of which is of the form 4n + 1 for integer n, the first 84 bits of the internal form of that number are stored in the last 84 bits of that register, and the remainder of the internal form of that number is stored in the last 84 bits of the second register after that register.

In this way, the same principle that storing double-length numbers in two adjacent registers is respected: numbers too long to be stored in a given register are stored in that register, and in another register of the same register file that is nearby. But the method is extended to allow more efficient use of the available space.

This technique is also required for handling the new 128-bit floating-point type included in the latest IEEE 754 standard; this type is similar to the 32-bit and 64-bit types in having a hidden first bit, and is not the same as this architecture's usual 128-bit floating-point type. And a similar technique will also be required for handling the new 256-bit floating-point type also in the latest IEEE 754 standard.


There are 16 short vector registers, each of which is 256 bits in length.

Each of these registers may contain:

As well, they may contain sixteen 16-bit short floating-point numbers in one of two formats.

These numbers all remain in these registers in the same format as that in which they appear in memory.

The entire set of 16 short vector registers can contain a table of bits used for bit-matrix-multiply operations on 64 bit binary words. As well, the short vector registers may also be used as four string registers, each 128 bytes in length.

This is done, rather than using them as two string registers, each containing 256 bytes, because four registers are the minimum number of registers required for the general register style of operations, at least as claimed in advertising literature for the Data General Nova. Having these strings only half the maximum length of those available to memory-to-memory string operations is presumed to be accessible, since strings "really" only have to be at least 80 characters long, as everyone knows.


In addition to the basic set of registers, two other larger sets of registers are also included in the architecture:

A set of 128 64-bit integer registers, and a set of 128 128-bit floating point registers.


A set of 8 vector registers, each of which contains 64 storage locations for floating-point numbers, each one 80 bits wide. This allows the computer to process vectors of 72-bit floating-point numbers in addition to vectors of 64-bit floating-point numbers, if the optional variable memory width feature is included.


As for how data values are stored in memory:

Signed integer values are stored in binary two's complement format.

Floating-point numbers are stored in IEEE 754 format, but in addition there are instructions for processing data in the format originally used by IBM's System/360 computers, including the Extended Precision format introduced on the Model 85.

The architecture is big-endian: the most significant bits of a value are stored in the byte at the lowest numbered address.

As well, there are 16 flag bits which are used for instruction predication, and of course there is a 64-bit program counter. The program status quadword includes eight alternate sets of condition codes in addition to the normal set of condition codes, and the program counter and flag bits are also part of the program status quadword.

Branch Targets

In general, as with most other computer architectures, instructions are provided to jump to a specified location in memory to continue execution.

In this architecture, instructions are considered to fall on 16-bit boundaries.

The normal rule for branch instructions is that their targets must be executable instructions. There are exceptions to that principle, as well as another special consideration, which apply to this architecture, however.

Athough these points might seem obvious, it should also be obvious that it is advisable to state them explicitly to avoid the possibility of confusion.


[Next] [Up] [Previous] [Next Section] [Home] [Other]