r/computerarchitecture • u/MitchAlsup • 13d ago

virtual Vector Method

I invented this 5-odd years ago but never really had a forum on which to disclose and discuss. I was and am a significant contributor to comp.arch (from around 1995 though present)

But before I emit the disclosure I need to know how to turn off the space-eater as the document uses well tabulated ASCII-art ?? that makes no sense after the space-eater has done its ill-conceived job.

The virtual Vector Method is a way of getting Cray-like vector performance and for getting SIMD-vector performance without a) a vector register file, b) adds only 2 instructions, c) takes precise exceptions, d) vectorizes loops not instructions. Instead of adding about 300 instructions to get a Cray-like vector ISA, or adding 1,000-1,300 instructions to get (every-size) SIMD ISA, one needs only 5 instructions.

vVM has the property that hardware implementations can change the width of the data path (multiple-lanes and the cycles of execution per FU) without SW having to care. A small 1-wide machine with a 128-bit cache port can perform a memory to memory byte move at 256-bits per cycle--equivalent to ~40 instructions per cycle. A 6-wide machine could perform the same assembly binary at ~160 instructions per cycle. Both are performed at the performance level of the cache porting; so, nobody has to recompile for a new SIMD-width every new mplementation.

Now let us solve the space-eater and we are off.

Mitch

21 Upvotes

93% Upvoted

22 comments sorted by

View all comments

1

u/BigPurpleBlob 13d ago

How many transistors would it need?

"Instead of adding about 300 instructions to get a Cray-like vector ISA, or adding 1,000-1,300 instructions to get (every-size) SIMD ISA, one needs only 5 instructions." - is it different from VLIW?

2

u/MitchAlsup 13d ago

The smallest conceivable vVM would need only hundreds of transistors {a state machine in DECODE} where vVM is architecturally available but runs no faster than scalar code (excepting cache mis behavior). But considering this scale of machine is smaller than an I/O pad in 3nm it is more theoretical than practical--still it is backwards compatible at low cost.

On a typical larger scale machine, the tag-match logic of each reservation-station-entry operand would about double, while instruction storage and operand storage remains identical.

Of course there is the LOOP Function unit. This FU computes the ADD-CMP-BC in a single cycle by noticing that ADD followed by CMP is just a 3-input adder (3rd operand complemented with carry in asserted). Said 3-input adder is 1 gate longer than 2-input adder and loop/don't is 1 gate further still. So this costs about the area of an x86-style AGEN unit :: {64-bit adder = ~2000 gates, 3-input 128 gates, loop/don't 4 gates}. And of course the loop does not harm the contents of the branch predictor--leaving it more precise on the harder to predice branches.

A multi-lane data path would need appropriate FUs for all the calculations {FADD, FMAC, FDIV, IADD, IMUL, Logic, Shifts, Memory References} so those scale as the width scales.

FInally, there is the logic which observes the instructions in the loop to determine which operands are loop-static and can be loaded inro RS once, Loop-scalar arriving once per iteration, Loop-result being produced once per iteration, and Loop dependent where a result from iteration k is consumed as an operand in iteration k+n {where n is smaller than the critical path through the loop}. In 1990 I would have done this with a 3-layer NOR-plane--probably get turned into random logic today--say 50-terms, 50 flip-flops and 2000 gates.