NL9100598A - Microprocessor circuit with extended and flexible architecture - provides separation between data transfer and data processing operations - Google Patents

Abstract

Data transport is completely separated from operations on the data. This separation enables the available transfer capacity to be used more effectively. The separation gives great freedom of choice in the implementation of function units, allowing `pipelining schemes' to be used throughout. Cycle times can also be cut to a min. i.e. time needed to transfer the data to be worked on.

Description

MOVE: A Flexible and Expandable Architecture for Designing

Processors 1 Introduction

One of the most important developments in the design of computer systems has been the use of RISC instead of CISC design principles [1]. The most important lesson was that extra hardware (eg for implementing complex instructions) does not always result in faster execution; on the contrary, it can increase the total execution time. Possible causes for this are; 1. Additional hardware functionality can increase the critical time frame, leading to an increased cycle time.

2. Complex instructions are rarely used in general calculations. Spending hardware on this can perhaps be used more effectively for other improvements.

3. Complex instructions are difficult to pipelin.

4. Sometimes software solutions for more complex instmctions are even faster than the corresponding hardware solution; in particular if compiler optimizations partially eliminate the software overhead.

5. Complex hardware increases development time and therefore makes it impossible to use the latest technological improvements.

Apart from these causes, the implementation of complex functions reduces design flexibility. These features can determine the design to make future improvements difficult.

Currently, most CPU manufacturers provide RlSC-based computer systems with comparable performance. The performance is dominated by the technology used. Since the basic complexity of a RISC processor is rather limited, it can be easily integrated into a VLSI design environment for the creation of application-specific processors ([2]). Theoretically, a RISC system achieves a performance of 1 CPI (cycle per instruction); in practice it is slightly larger due to penalties caused by load and branch assignments. Efficient use of RISC systems requires compilers capable of minimizing these penalties by means of placing instructions in delay slots; this can be considered as a limited form of scheduling of parallel instructions.

To achieve an even greater performance improvement than is possible only with faster technology, we distinguish two important architectural techniques: 1) the use of deep pipelines, and 2) the use of multiple independent function units (FUs). The first technique reduces the cycle time, the second the CPI. Both techniques require extensive code parallelization at the instruction level. The next section discusses these developments. It also explains why the resulting architectures have a number of drawbacks, which greatly limit their applicability.

The invention described here concerns a very different architecture, called the MOVE architecture, which completely separates the data transport and the data operations. Section 3 describes this invention while section 2 describes recent architectural developments and the MÖVE competitors. Section 4 compares the MOVE architecture with these competing architecture implementations and shows the superiority of the described invention. Section 5 contains the conclusions, section 6 the figures and the last section contains a glossary and a bibliography.

2 Recent Architectural Developments

To increase the speed of single processors, different architectural techniques are used [3], namely:

Superpipelining: Dividing existing pipeline stages into süb stages, allowing a shorter cycle time. This is an extension of the RISC-pzpe / z '«e principle; there the execution internship covered 1 more cycle, while it is now divided into several internships. Superpipelining will slightly increase the effective CPI due to the increased number of delay slots, however this effect is offset by the decreased cycle time. Examples can be found in [4,5].

Functional parallelism: Adding independent function units to exploit the operation parallelism results in the effective CPI becoming less than one. Superscalars [6.7] and VLIWs [8,9,10,11,12] are representatives of the application of this technique. Superscalars apply dynamic detection of operation parallelism, while VLIWs have this done completely by the compiler (static). While Superscalars also require intensive compiler support to achieve reasonably efficient execution, they can also execute non-shed code; they can therefore be object code compatible with architectures that are not implemented with functional parallelism.

Superscalars have a strong limitation in the amount of parallelism to be exploited. The hardware needed for runtime parallelism detection limits the size of the decode window to a few instructions. Further hardware reduction is possible by limiting the number of instructions that can be combined (eg maximum 1 integer, 1 floating point, 1 loadlstore and 1 control instruction). The compiler is much more capable of discovering possible parallel statements than is ever possible with hardware (a possible exception is detecting address dependencies in memory operations). A favorable consequence of dynamic detection is that the size of the code does not increase due to the insertion of empty instructions (NOPs). In short, superscalars are good for limited performance improvements of existing systems, but require compiler support.

VLIW and Superpipelined architects have higher parallel execution potential than Superscalars. The benefit will be limited for scalar applications (due to the sequential nature of the calculations); however, for specific and vector applications, a much greater speed increase can be achieved.

Ideally, we want to combine VLIW and Superpipelining techniques. This would provide an architecture that provides high vector performance, which can be tailored for specific applications and also shows good scalar performance. However, as we will demonstrate in section 4, this architecture has a number of drawbacks that result in complex organization, inefficient hardware usage, difficult-to-change functionality, and limited extensibility. Therefore, it is not ideal for use in an application specific processor design framework. The invention described in the next section does not have these drawbacks.

3 The MOVE architecture

The required performance, and the allowed design and manufacturing costs determine the number and type for VLIW and for Superpipelined the depth and type of the function units to be used. The communication bandwidth between function units is determined solely by the number and type of function units. units; it must be designed for the worst-case situation. Likewise, the instruction bandwidth is tailored to the worst-case situation, i.e. that all function units are in use at the same time. Even if this is the case, the required communication bandwidth will rarely be a worst case.

In this section we describe an invention of an architecture (the MOVE architecture), which greatly reduces the above-mentioned problems of overdesign. In the next subsection, we develop this architecture from the point of view of VLIW and Superpipelining architectures. Subsequently, issues such as pipelining, handling of exceptions, and the necessary support mechanisms, necessary for an efficient depiction of higher programming languages and operating systems, are discussed.

3.1 From VLIW and Superpipelining to MOVE

If we choose VLIW and Superpipelining as a starting point, the development of the MOVE architecture can be seen as a 6-step process: 1) reduction of register-file communication bandbid, 2) programming the bypass, 3) reducing the oypim connectivity, 4) the separation of transport and operations, 5) reduction of the transport capacity and 6) the programming of the transport.

Reduction of the register-file-communication bandwidth Figure 1a shows the internal communication structure of a (super-) pipelined organization. A set of function units (FUs) is connected to a bypass unit containing operand and bypass registers. The bypass unit is connected to a register file. Similarly, Figure 1b shows the communication structure of a VLIW. This VLIW organization will be used as a starting point from now on.

In addition to operand registers, the bypass contains a number of bypass registers for temporary results. The latter are organized as FIFOs. The operand registers read their data from the register file, the FIFO, or the outputs of the FUs. The writing of results can be done in all FIFO registers, depending on the time an FU operation takes. This writing is accompanied by the writing of the regisler identifier. This identifier serves to write in the register file and to identify the temporary results in the bypass. A result which leaves the FIFO is written in the register file. The bypass is not visible at the architecture level.

With respect to the required bandwidth between the register file and the bypass, we can give 2 observations: 1. More than 50% of the data in the bypass registers is no longer used after writing this in the register file . Deeper FIFOs can increase these percentages even more.

2. Many instructions do not use all possible register operands. E.g. a branch instruction does not generate a result; monadic statements use only 1 source operand. So these instructions do not use the full register file bandwidth.

The compiler can detect all these cases of incomplete use of registry bandwidth. We can therefore construct an organization in which the register transport is fully checked by the compiler. As Figure 2a shows, the register file now becomes a function unit with far fewer read and write ports.

Programming the bypass In the situation that has now been created, it is more efficient to make the bypass visible at the architecture level. The bypass now becomes an explicitly addressed top level of the memory hierarchy. Writing values in the register file is now no longer affected by the FIFOs; it is completely under the control of the compiler. All bypass registers (from now on including the operand registers) can be written and read by all FUs (see Figure 2b). The advantages of this are: • Simpler design of the register file.

• Simpler bypass design (no FIFOs, no identifier matching).

• Smaller operand identifier fields in the instructions.

Reduction of bypass connectivity Since reading and writing the bypass registers is part of the FU execution, this should be done as efficiently as possible. One way to achieve this is to reduce the number of connections and thus the read and wnite load. Application of this principle to the visible bypass for the number of read and write connections results in the organizations drawn in Figures 2c and 2d, respectively.

The simplest method of reducing the number of read connections is to use private register sets for all FU inputs. These sets can be described by all FUs (see Figure 2c). The LIFE processor [13] uses this organization. To avoid multiple write ports per register set, LIFE limits writing per register set to one FU at a time.

Another method is to reduce the number of write connections. Each FU writes in its own bypass register. The Cydra-5 [12] uses this organization. Figure 2d shows an organization with 2 private result registers per FU.

Separation of transport and operation Reduction of both the number of read and write connections is illustrated in Figure 3a. All bypass registers are now classified as private FU result and FU operand registers. The entire operation now takes place in the FU, the transport outside. Transport and operation are therefore separated.

Reduction of transport capacity The transport network from figure 3a is still not fully utilized; after all, not all FUs will deliver a result every cycle. The transport capacity of this network must be better attuned to average use; i.e. the number of buses must be reduced (or equivalent, with the same number of buses more FUs can be served). Figure 3b shows 3 FUs that must share 2 buses together.

The main implication of this organization is that we have to schedule both operations and transportation. From a VLIW point of view, operations are scheduled by the compiler (static) and the transport network by the hardware (dynamically).

Programming the transport The next logical step is to have the compiler also schedule the transport. The compiler can potentially outperform the hardware here; With regard to hardware, the compiler can view the entire program. Now the transport becomes visible at the architecture level. This means that operations do not have to be specified separately, they act as a side effect of the transport. As a result, the programming model has been reversed:

Traditional: Programmed operations, operations trigger transport.

MOVE: Scheduled transport, transport triggers operations.

The MOVE architecture is based on this concept; it can be seen as a non-uniform register set connected by a poinMo-point or point-to-multipoint or other type of network l. The register set contains FU input and FU output registers, and general-purpose registers. The input registers are divided into 2 types: operand and trigger registers. Writing data in the trigger register starts an FU operation, in which the 'Using only move instructions is not new (see, inter alia, [14]). Move architectures, where all functionality is memory-mapped, have been known for a long time. However, the use of a full register-mapped functionality, where multiple guarded transport commands can be executed in parallel, is new. This method leads to all kinds of surprising advantages as described in section 4.

data from a number of (O or more) FU-specific operand registers contain the other input operands. As a result, the MOVE architecture contains only 1 type of statement: the move. A move contains at least a source and a destination identifier. It specifies a transport from one register (or FU) to another (or multiple multicast transport) register (or FU), possibly triggering 1 or more operations.

For a traditional addition operation, the MOVE architecture requires 3 moves, the first for loading the operand register, the second for triggering the operation (transporting the second source operand) and the third for reading. the result. In practice, this last move will often also trigger the next operation.

The transport network can have any topology, as long as transport orders can be executed. The network does not require full connectivity. The task of the compiler is to optimize the transport for a given topology. Limited connectivity can reduce capacity and therefore cycle time. The MO VE prototype, which realizes the MOVE architecture on a single chip, contains a regular fully connected bus structure, where 4 move commands are executed in parallel.

3.2 Pipeline alternatives

The MOVE architecture does not require the FUs to be pipelined, however optimal FU utilization requires maximum FU pipelining. If we combine pipeline latches with logic, we can reduce the number of ports per pipeline stage to 2. In practice (see [15]), clock skew and data skew can provide a higher lower limit. When implementing pipelines, we have a number of alternatives: • Continue always In this case, the data in the pipeline is shifted to the next stage at regular intervals (usually every clock cycle). This is implemented in the Cydra-5 VLIW processor [12] and in most vector machines. This is easy to implement, however, as will be shown later, it requires many additional registers.

• Push / Pull Here the data in the pipeline is only pushed through if a subsequent instruction uses the same pipeline [5]. Note that the distinction between push or pull only makes sense if traditional operations are split into separate moves.

• Hybrid This solution means that data in the pipeline can usually be passed on, except in the event that data from previous operations threatens to be overwritten, for example because the results have not been read in time. So block pipeline internships as late as possible.

In the MOVE architecture, most FUs have a hybrid pipeline implementation. The first solution requires that the results are read exactly at the right time. This not only reduces the scheduling capabilities of the MOVE machine, but also means loss of data in case of blocking (think cache miss or an exception). This is not the case if the pipeline is only 1 stage deep.

The second alternative leads to large code size for scalar applications; additional dummy instructions are needed, only to extract results from the pipeline.

The hybrid alternative is slightly more difficult to implement because stages are allowed to move conditionally, however it combines simple exception handling, small code size and additional scheduling freedoms (see section 4).

3.3 Exceptions

Exceptions can be divided into three categories: 1. Exactly. Handling these exceptions requires that the source operands of the operation giving rise to the exception are still available. Examples are loads, stores and floating-point operations (according to the IEEE 754 floating-point standard). After the objection has been processed, the execution must be able to continue.

2. Not exactly. These exceptions do not require that the source operands are still present for the handling of the exception, but they do require execution to continue after treatment. Examples are exceptions caused by integer arithmetic2.

3. Fatal. Contrary to the previous two, this exception does not require that execution be resumed.

Precise exceptions are partially implemented using the so-called inexact exception condition. FUs try to verify as soon as possible whether an exception can occur. Before this condition is verified and even if this condition is true, we must ensure that the source operands are not overwritten. This can be achieved in four ways: 1) by means of compiler agreements, 2) by immediately initiating locking until it is known that the inexact condition is not valid, or until it is known that the exception has actually occurred, 3) by initiate locking when the source operands are in danger of being overwritten, or 4) by rescuing the source operands in the FU itself. It will be clear that solution 3, along with a rapid generation of the inexact condition, is preferable. This combination has therefore been implemented for most FUs from the MOVE prototype.

In order to recover from an exception, the processor must be placed in a state that guarantees a possible recovery. There are roughly three methods for this: 1) restart, 2) completion, 3) blocking.

Restart In the case of multi-cycle operations with out-of-order termination, restarting unfinished instructions is practically impossible. In that case, the PC and other processor state must be saved for many cycles, which requires a huge hardware investment.

Completion Many superpipelined and VLIW processors are designed to finish the work that the various FUs are doing (completion) after an exception. These processors do not have the ability to block the FUs during exceptions3. As a result, all unfinished instructions are still completed after the exception is detected. This in itself implies that the compiler is forced not to use the result registers of multi-cycle operations for other operations during the calculation of this multi-cycle operation. In the event that exceptions need to be detected precisely, this inefficient registry usage will only get worse: the source operands must now also be protected against overwriting during the operation on these operands. In the Cydra-5 [12], the compiler guarantees this, by declaring a register as in use from the beginning of the operation to the moment when all the operations using the written value have ended. For software pipelined loops this gives a fairly disastrous increase in registry usage. Don't forget that all the register ^ / es in Cydra-5 have to be designed for worst case situations.

Blocking In the MOVE architecture, the FUs automatically block as a result of an exception, as this mechanism is already built in to provide an additional degree of .sc / redWMg flexibility. The MOWE pipelines freeze automatically when the result is not read. Register destinations are therefore never overwritten. In fact, a destination cannot be overwritten because the FUs do not know what 2Some LISP systems can use precise exceptions for integer arithmetics. As a result of an overflow on fixnum operations, the representation can be changed to bignum.

3 An exception to this is Intel i860 f5]. The pipelines of the i860 must be emptied by push and pull instructions.

(outside the FU result register) is the ultimate destination. Saving and restoring the FU state can be particularly complex in current VLIWs. There are three reasons for this: 1) internships can have complex data formats, 2) destination identification must be saved and restored and 3) data and destination identification must be restored in the correct pipeline stage. For the MOVE architecture, blocking is much easier to implement. 1) it is not necessary to keep intermediate results, only final results are necessary. 2) because the instructions are split into components for loading operands and reading result, the only destination is the FU result register, so it is not necessary to keep the destination identification. 3) since the number of cycles between starting an operation and reading the results is not determined by the FU latency, only restoring the correct order of operations in an FU is important; the exact position in the FU pipeline is irrelevant. The FU therefore does not need a complex organization to enable this recovery process, only one unit operation per FU is sufficient to effect recovery (eg +0, xl, etc.).

3.4 Support mechanisms

The MOVE architecture separates transport from operation and is programmed by specifying only the transport. A processor based on this architecture requires a number of support mechanisms to support higher programming languages and operating systems. Figure 4 shows a possible re-realization of both the move and the support mechanisms, as realized in the prototype. The move mechanism consists of the transport network and the move identifier bus. The support mechanisms are the guard, locking and exception mechanisms.

Conditional execution Only supporting conditional execution by means of a compare and branch mechanism is less acceptable for VLIW and super pipelined machines. A better approach is to use guards, which allow conditional execution of some or all transport operations. Some (or all) moves contain a guard selector, which selects the value of a guard as a condition, or specifies a combination (boolean expression) of these guards. The semantics of a move are such that if the move is true, the move operation has no consequences 4.

The guard mechanism is integrated in an FU. This FU processes the guard selector as specified in the move statements. For each specified guard selector, this FU activates the corresponding guard line. This FU also implements the operations for setting the guards. The guard mechanism in combination with the separation of trigger and result move makes speculative start-up of an FU operation easy. The removal of unwanted results (possibly including unwanted exception condition) is done in the prototype using a move to a dummy register.

Locking Compile-time synchronization of all move operations is not possible if FU latencies cannot be determined by the compiler (eg in case of a cache miss), and is not efficient if insufficient operations can be found to FU latency to be bridged igv a RaW hazard. Both problems are solved by hardware synchronization. In general, synchronization implies that producer and consumer can lock each other if one of the two is not yet ready for the transaction. Locking can also be implicit if the transport network is executed using self-timed logic.

In the MOVE architecture, locking leads to 2 types of transport locks: 1) a read lock, as long as a result (in an FU) is still underway, and 2) a write lock, as long as the FU is not yet available. The read lock makes scheduling result moves independent of the FU latency, the write lock is a 4 One possible exception, which we have not implemented in the prototype, is that this move still reads a value from an FU pipeline , but does nothing with this, and also suppresses possible exceptions; this in support of speculative execution.

efficient implementation of precise exceptions. Locking extends the time of the move operation so that it can be completed.

Exceptions The exception support mechanism allows the FU to identify 3 types of exceptions (see section 3.3). A recoverable exception means that the current transport order has not been completed, but can be completed after the exception has been processed. The trap and return mechanism depends on the implementation of the exception FU. The prototype uses the identifiers on the move-identifier bus to form the address of the correct exception routine within one cycle. This allows very fast emulation of non-implemented functionality. For speculative execution, it is possible to settle inaccurate exceptions at a later date. This is possible by adding an exception bit to the data. Testing of the exception condition now takes place programmatically.

4 Comparison of MOVE with architectural trends

The previous two sections describe recent architecture developments and our alternative, MOVE architecture. In this section, we compare these recent developments with the MOVE architecture from different points of view. The main reason for this equation is the justification for the characteristics of the MOVE architecture as presented in the previous section. Comparisons are made in the following areas: 1) utilization of the hardware; 2) suitability for adapting the MOVE to the requirements of specific applications; 3) pipelining of functional units; 4) implementation of the consequences of exceptions; and finally, 5) performance aspects such as speed and code size.

4.1 Utilization of the processor hardware

When valuing the MOVE architecture with regard to hardware usage, we need to look at the different components in a MOVE processor. As shown in figure 3a, a MOVE processor consists of a transport network and functional units. Registers can also be described as function units, but we consider these separately.

Transport network In section 3.1 it was explained that a MOVE processor uses the internal transport capacity more efficiently than a VLIW comparable to the MOVE. Compared to the VLIW, this means that with the same amount of interconnection metal we can address more functional units and keep them busy. This simplifies integration on a single chip, as there is less interconnection overhead.

Function units Function units (called FUs) in the MOVE architecture are almost completely separated from the data transport network. The FUs only have to comply with an FU transport interface description. This means, for example, that we can make the pipelining of function units dependent on the function and use. The only restriction imposed by the network is the time between triggering operations; this time is a multiple of the data transport time5.

Register use The number of registers required in a MOVE architecture can be greatly reduced compared to other architectures. There are three reasons for this: 5This even allows wavepipelining. Wavepipelines do require data to be read from the pipeline in time. Support for exceptions therefore means that the pipeline must end in a number of so-called run-out registers.

1. Less temporary values need to be kept. Many of these temporary values go directly from FU to FU without being written into the general-purpose register.

2. Effectively, it appears that Pipeline sections and FU operand and FU result registers are used to replace general-purpose registers. In the MOVE architecture, a regular RISC instruction is split into its three basic transport components and these components are scheduled separately. A result generated by an FU, but which cannot be used directly (by the same or another FU), may remain temporarily in the generating FU, except, of course, if it blocks results that are needed earlier. In the latter case, a register is required to keep this result for a while. Likewise, we can use an FU source registry to temporarily store a value before performing the operation on this source operand.

3. Blocking exceptions. We have chosen to automatically block the pipeline stages within an FU when the results have not yet been removed. As a result, this does not require a compilation strategy in which registers are reserved for a long time.

4.2 Performance

For the performance comparison we look at: cycle-time constraints, scheduling freedom, code size and suitability for processing scalar and vector applications.

Cycle time Most processors based on the RIS C design philosophy use different pipeline stages for fetching instructions (IF), executing the operation (EX or ALU) and memory access (MEM). The cycle time of these processors is now limited by the time required for cache access (IF and / or MEM) or for operation (ALU). Both cache access and operation can be split into multiple pipeline stages (super pipelining). The cache access can be split into a decoding, a look-up and a tag-vcrgdijk stage. It is also possible to apply interleaving to the cache if the look-up stage is the critical path in the cycle time (the look-up stage can become critical if too many cache lines need to be read).

The operational stage consists of reading the source operand latches, going through the combinatorial logic, going through the bypass multiplexers and then writing a bypass register and possibly a source operand latch. In principle, we can also place a pipeline latch directly after logic and before the multiplexer ^. As previously described ([15]), the minimum amount of logic between staging registers depends on amount of data and clock stov. The relationship between the write time via the multiplexer and the write load is linear (see [16]). This load is proportional to the number of multiplexer inputs, so the write time becomes θ (η) where n is the number of multiplexer inputs6. Writing n possible sources to 1 destination may become the critical path in heavy gcpipelinedc processors. This has the consequence that reading from a register file (which is also an n to 1 transport) or passing through a complex bypass circuit can sometimes determine the cycle time. In addition to designing for a minimum of data and clock skew, both the size of the register file and the size of the bypass should be limited. As already indicated, the MOVE architecture is superior in limiting the number of registers required. The bypass circuit has been replaced by the transport network and the number of connections within the network is much less compared to a VLIW architecture. It is our belief that when transport becomes the critical path in the cycle time, the MOVE architecture has no real competition.

6Using larger drivers makes no sense because capacity loading increases proportionately with the dwv / ng capacity. Using a driver tree limits the time to 0 {log {n)). However, a tree is much more difficult to wire in VLSI.

Scheduling freedom The performance of a VLIW depends crucially on the quality of the scheduling of the code. In the MOVE architecture, a typical VLIW-RISC operation is split into one or more data transport operations (called moves). A 3 operand RISC instruction, for example, corresponds to 3 moves', one for the transport of the first operand (operand-move), one for the transport of the second (and last) operand (trigger-move) and one to to transport the result of the operation to the ultimate goal (result-move). The instruction that transports the last operand also causes the start of the operation (trigger). Combined with hybrid pipelines (see 3.2) in FUs, this breakdown in transport components causes new degrees of freedom for scheduling that have never been seen before. Both the transport of operands and results are separated from the transport of trigger operands. Splitting a traditional instruction into its transport components has several advantages: 1. The elimination of common subexpressions (CSE) can be applied to the transport of operands. If an operand does not change between two operations using the same FU, this operand only needs to be transported to the FU once.

2. The removal of unnecessary transport to general-purpose registers because a result does not have to be consumed immediately. For example, if the second operand for an operation is not yet available, the first operand must be kept in a general-purpose register. Provided the FU that produces this operand is not immediately needed, within the MOVE architecture this storage can also be done in this FU itself by postponing the operand move.

3. Obtain better initiation intervals in software pipelined loops. As noted in [17], it is often desirable to add delay stages in pipe // ne reservation tables in order to obtain optimal initiation intervals. For MOVE this means that transport from a result register must be delayed. Again, this is only possible for those FUs that are not used at full speed.

Code size The shift from CISC to RISC caused the object code to increase by about 50%. This increase is acceptable in view of 1) the capacity increase of RAMs and 2) the use of large instruction caches to compensate for increased instruction traffic. However, the use of VLIW architectures can easily lead to a code explosion due to 1) the (average) large number of unused operation s / ots and 2) the code duplication required for advanced compiler techniques. In principle, MOVE instructions are even less compact than the comparable RISC instructions. After all, a 3-operand RISC instruction translated into three moves. In our MOVE prototype, a MOVE instruction costs 16 bits, which equates to 48 bits for three moves or 50% extra instructions. Fortunately, there are several reasons why this 50% is an upper limit, which on average is much lower: 1. Many moves transport data from FU to FU. Ideally, this would cause 1.5 move per 3 operand RISC instruction; a code reduction of 25%.

2. There are instructions with less than three operands (branch / jump / monadic).

3. Eliminating common subexpressions (CSE) also removes unnecessary operand moves.

Measurements using our prototype compiler, which only performed scheduling on basic-block mvtm without CSE, show that for some large benchmarks the average number of moves per RISC instruction is approximately 2.2. The next version of the compiler will most likely match the RISC instruction density. We expect that with regard to code density, the MOVE architecture is comparable or even better than a RISC.

Compared to a VLIW the MOVE architecture is superior in code density. First, the number of unused instruction slots has been reduced due to the shared-transport network (see section 3) and second, it is possible to avoid completely empty instructions using pipeline blocking (which is essential for scalar code).

Scalar and vector applicability The MOVE architecture is designed to allow extensibility in number and type of FUs. In combination with the almost unlimited possibilities for implementing FUs and the efficient use of the data transport network, the MOVE architecture is ideal for use in vector and other special applications. One of the problems of many vector machines is the imbalance between the vector and the scalar performance. Amdahl's law therefore limits the utility of these machines for general vector applications. VLIW architectures combined with smart compilers are able to improve the performance of both vector and scalar code. Although the performance improvement for scalar code is limited to a factor of 2 & 4.

The MOVE architecture improves a standard VLIW in 2 aspects, 1) as already mentioned, the code extension is less dramatic and 2) additional FUs can be easily added without requiring changes in the transport network and without changing the instruction format . In standard VLIWs, less used functions are combined in a single FU (e.g. integer, logic, shift and branch). In MOVE all these functions can be separated without much cost (only extra operand latches). As a result of this separation, these functions can also be used in parallel and thus lead to an improvement in performance for the scalar performance.

Compared to a RISC processor, the MOVE architecture seems to have an inherent drawback to scalar code. As shown in figure 5, an extra cycle (lost cycle) is created between two dependent operations. In both cases the amount of work per instruction is comparable: propagation by combinatorial logic and latching the result (see section 4.2). The difference lies in the fact that the MOVE architecture is latched twice instead of once (immediately after logic, and immediately after transport). However, the FU result tofc / r can be combined with combinatorial logic (using Earl or Polarity hold latches),

It is also possible to reduce the number of cycles in the same way as in a RISC by removing the trigger latch (see Figure 6). However, this last solution for the lost cycle contradicts the aim of minimizing cycle time and placing useful moves in the lost cycles. In this case it is therefore preferable to implement less transport capacity and thus obtain a better filling degree for these unloading cycles. All in all, we expect a MOVE processor with two moves per instruction to perform better than a standard RISC.

4.3 Applicability for designing application specific processors

Starting from state-of-the-art silicon compilers, with facilities for the use of parameterized VLSI cells, the rapid modification of a processor becomes a real possibility. A processor is suitable for adapting to specific applications if the architecture is both flexible and extensible and the design is simple.

Flexibility The retargeting process requires that the functionality can be changed flexibly. VLIWs have a clear disadvantage here; adding FUs includes: 1) changing the instruction format and 2) adding additional buses (which reduces the entire register file layout). The MOVE architecture does not have this drawback. The MOVE architecture also does not limit the number of operands and results from specific FUs.

Extensibility in performance ...... In addition to the possibility to easily change and adapt the functionality, it is extremely important that the performance can be adapted to the requirements of the application. The MOVE architecture has an extra degree of freedom here; besides adding FUs, it is possible to independently increase the transport capacity. For example, the transport network can be implemented using a number of parallel buses generated by parametrizable VLSI library cells. Adding a bus is easy, although this addition changes the instruction format. However, this change is predictable and therefore easy to implement in the compiler (for example, the number of move buses as a compiler parameter). Changing the pipeline gr & ad is another way to adjust performance.

Design time Two issues play an important role in the design of ASPs: the performance cost maintenance and the development time (time to market); Design time is critical on both issues. A long design time causes high design costs and lower performance because the design is based on outdated technology. However, the number of design limitations inherent in the MOVE architecture is very low; changing FUs, adding FUs and changing the transport network can all be done independently. We believe the MOVE architecture is ideal for the rapid generation of ASPs using existing VLSI design environments.

Claims (21)

1. An architecture of a Central Processor Unit (CPU) in which data transport of operands and all, or most important, operations on these operands are disconnected. The operations on operands are performed by so-called function units (FUs); the data transport takes place over a data transport network. Programming of this architecture takes place by means of specifying data transport operations. 1 or more of these transport operations are specified for each instruction. Each transport operation specifies one source and one or more destinations. An architecture as specified under claim 1, wherein a hierarchical bus structure is used for the data transport. An architecture as specified in claim 1, wherein the data transport operations are performed conditionally. An architecture as specified under claim 3, wherein the conditions are specified by one or more guards. An architecture as specified in claim 4, wherein the specification of the guards is part of the specification for the data transport operations. 5 Conclusions An architecture as specified in claim 5, wherein the specification of the use of the guards consists of boolean expressions, with the specification of 1 or more guards in this expression. An architecture as specified in claim 1, wherein the data transport is implemented by single-cycle data transport instructions. An architecture as specified in claim 1, wherein the data transport is implemented pipelined. The data transport is separated into a read cycle and a write cycle. An architecture as specified in claim 1, wherein the data transport is implemented through a combination of 1, 2 or more cycles of data transport operations. A data transport operation of 3 or more cycles consists of a read cycle, 1 or more transport cycles, and 1 write cycle. Data transport operations implemented through multiple cycles are used to allow clusters of function units to communicate with each other. An architecture as specified in claim 1, wherein the transport netweik and / or one or more FUs are implemented with self-timed logic. An architecture as specified in claim 1, wherein a so-called hybrid pipeline scheme is used for one or more function units. An architecture as specified in claim 1, wherein one or more function units are implemented using wave pipelining. An architecture as specified under claim 11 or claim 12, wherein for the purpose of exceptions one or more function units are equipped with run-out registers. These function units can be used directly for the exception code during an exception. After returning from an exception, the run-out registers are automatically read when reading results from these function units. An architecture as specified in claim 1, wherein precise exceptions are supported by means of the so-called inexact exception mechanism. An architecture as specified in claim 1, wherein during reading from a function unit of an inaccurate exception result, an exception is not directly generated, but the exception propagates as an extra condition with the data over the transport network. This exception can be handled at a later time determined by the compiler. An architecture as specified in claim 1, wherein the correct exception vector is determined within 1 cycle. The transport identification number of the transport operation that causes an exception is used for this determination. An architecture as specified in claim 16, wherein functionality not implemented by means of an emulation mechanism is emulated. An architecture as specified in claim 1, wherein the transport network automatically blocks as long as 1 of the data values to be transported cannot yet be supplied by the function unit calculating this value, because the calculation of this data value is not yet complete. As soon as this calculation has been completed, the blocking is canceled. An architecture as specified in claim 1, wherein a function unit to which a data value is to be transported blocks the data transport network as long as it cannot wither this data value. An architecture as specified in claim 1, wherein the instruction unit behaves like a standard function unit, i.e. similar to most other function units. The operands of this function unit, the instruction register and the program counter are accessible via the data transport network. Immediate data values can be read directly from the instruction register. The transport network is managed by a so-called bus controller; it has access to the instruction register and the program counter via the data transport network or via a separate transport network. An architecture as specified under claim 1 and claim 20, wherein multiple instruction units are present and connected to the data transport network. The bus controller can select instructions from multiple instruction registers to use for controlling the data transport network.