[Libre-soc-isa] [Bug 664] design SVP64 branch instructions (sv.bc)

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=664

--- Comment #10 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #9)

> wait, so you mean a function call inside a sv vertical-first loop? hmm...

uh-huhn :) at least, if not a public one (ABI compliant) a static one.
bare-minimum just above "some stuff went on the stack"

> anyway:
> imho we should limit SV vertical mode to just single loops,

ironically and hilariously doing so is more costly.
this comes down to the strict insistence of being barely
above scalar and on having context-switching rules

MyISA 66000 VVM on the other hand, written by Mitch Alsup,
that *is* a single ZOLC Vertical-First explicit concept.
it's an explicit instruction (a pair), only LD/STs may
be Vectorised, the LOOP instruction tags the counter, loop
invariants, and the registers to be used for LD/ST.

once in-flight the hw is permitted to analyse the RS allocations
and perform automatic SIMD merging of multiple Vertically-allocated
loops. that can only be safely done thanks to the tagging.

now *that's* complicated (and awesome, despite the limitations) :)

SVP64 is a completely different paradigm, with the absolute bare
minimum in hardware.

Vertical-First in SVP64 is literally one bit
that says "no" to incrementing srcstep/dststep, and lets just one
instruction get issued with GPR(RA+srcstep) rather than GPR(RA).

context-switching whether it be a function or it be an interrupt
is literally a matter of saving PC and SVSTATE. (a bit more if REMAP
is engaged, obviously, but that's software's problem to solve)

> otherwise we'll
> gain more features and end up with something that takes 500k gates just in
> the sv decoder...

surprisingly adding LSVR is not that gate-hungry.  it is completely
independent, and already the branch instructions have a different RM
Decode path, but the bit that's equivalent to LK is not tied *to* LK,
it's independent.

> we need to stop adding every feature we can think of to SV
> otherwise x86 will look at us and be proud that their spec is *only* 5000
> pages... (idk the real number, but you get the idea)

120 for everything including 32-bit instructions from bitmanip etc.

most of the effort involved here is stopping brain-melt. Cray
(Horizontal-First) *nobody* does function calls, it's too much.
Vertical-First is so close to scalar it's actually harder to
prevent fn calls, and would need explicit hardware and pretty much
a redesign to prevent.

now, ZOLC, that *is* going to be a whole new bundle-o-fun.  ZOLC
is definitely on the other side of a "large funding" fence.

-- 
You are receiving this mail because:
You are on the CC list for the bug.