jstopard

This isn’t an advertisement, simply a suggestion that data vectorisation has no future, and that a move needs to be made to execution-level ‘vectorisation’.

I will comply with your wishes and stop posting about this.

Hardware pipe-line

The pipe-line stages are as follows: fetch, decode, virtual stream assignment, operation, memory, write-back.

Nested streaming

It is not possible to nest a SIMS streaming context within another context, if the inner context is conditional. Nevertheless, it would be prudent to permit nested for loops to be ‘streamed’, granting a significant increase in performance. Using a bizarre technique called ‘outlining’ to remove a loop code block and place it into a separate function body, it is possible to emulate streaming on nested loops when the inner loop is conditional.

Software pipe-lining

SIMS supports pipe-lining and uses manual register rotation, but it is not necessary to encode a prologue or epilogue; instead, one of two techniques might be used to mask instructions that would otherwise function within prologue/epilogue: the first involves simple instruction masking, the other involves side-effect masking using tagged values that indicate whether state should be modified.

Stackless programming with cached register rotation

It is not necessary to write register values to the stack when running out of registers; instead, the CPU can stream register values to and from a register caching system (which itself can dynamically stream to and from RAM); in addition, these cached values can be properly rotated as necessary to support software pipe-lining. Lastly, the floating-point padding bits normally found in registers can be cached along with register values.

Virtual static scheduling

VLIW is not used in SIMS. The compiler emits a static schedule, and the CPU is expected to conform to the semantics laid out in this schedule; however, the CPU can dynamically assign fewer or more functional units to virtual compute units, if needed.

Control-flow

While traditional control flow is used, this is intended only to support flexible flow of control around/between convergence points. A point of convergence is where two sub graphs connect. You can think of a sub graph as being like an EBB, although EBBs are not actually used in this architecture.

Data-flow

Data-flow is a term that only makes sense in terms of software pipe-lining; the data flow through the operations specified in the software pipe-lining kernel, but the instructions execute in parallel.

Execution modes

The modes are as follows: SIMS only; SIMS and software pipe-lining; Single stream and software pipe-lining

Graph-flow

Graph-flow occurs within a sub graph, but this type of control flow isn’t achieved by using JUMP instructions; instead, the CPU maintains a real graph representation of the program, and a binary array is used as a look up table to determine which graph node needs to be executed next within a compute unit.

Software pipe-lining kernel

The compiler emits a software pipe-lining kernel in cases where it’s possible; the CPU is required to respect program semantics, but can dynamically adjust execution behaviour within CUs, and can borrow functional units if necessary.

Vectorisation

There is no vector size in the SIMS architecture; instead, it is the program execution that is ‘vectorised’. The number of program execution streams active at once can be any number up to the CPU limit. If the user acquires a new CPU with a larger compute unit count, it is not necessary to recompile the program.

Recently, there has been a trend in the market towards less well optimized code for computer games (particularly in the code running on graphics cards); which may have happened as a consequence of a lack of willingness to perform optimizations, or an expedient decision stemming from an assumption that optimizations are not as important because modern graphics cards have a lot more power available.

Furthermore, individuals with an interest in computer games have apparently opted out of buying new games, and have bought and played many more older games or remakes. In addition, it can be demonstrated that in many cases it is difficult to optimize for SIMT (the architecture used for the shader compute element of GPUs).

Is it possible that one could see a resurgence of software graphics for computer games in the future, and how likely is it that one could see custom CPU designs based on data-flow and software pipe-lining?

(As I can’t find the edit button, I have opted to post my rewritten version of my original post, here.)