[J-core] [RFC] SIMD extention for J-Core
rob at landley.net
Thu Oct 26 19:14:06 EDT 2017
On 10/25/2017 06:59 PM, Ken Phillis Jr wrote:
> I figure I will include my Idea for an easy to use SIMD Extension for
> the J-Core. In general this extension will be used for Three Types of
> number formats...
One of the blue sky J64 proposals Jeff mentioned (let me see if I can
remember the details) was 2 control bits per register letting you
specify that register contains 8/16/32/64 bit SIMD, meaning a single 32
bit control register could control SIMD state for 16 general purpose
registers. Then you use the normal operations to deal with
signed/unsigned, multiply, and so on.
The next question was how to deal with source/target size mismatches: in
theory a 64 bit source iterating over 8 bit targets could apply a single
64 bit source value to all 8 targets, a 32 bit source could go
1-2-3-4-1-2-3-4, etc. In practice what that makes the ALU look like is a
question that needs some code prototyping I think...
> New Registers: simd0 to simd15
> These Registers are 128-bits in size, and are used to perform a bulk
> of the SIMD Math.
Is there a way to do that and _not_ quadruple the size of the processor?
> SIMD Configuration Instructions:
> SIMD.IMODE - This configures the Integer Math mode of the Integer SIMD
> Operations. The accepted modes should include the following:
> * Integer Carry Mode - See ADDC and SUBC for example.
> * Value UnderFlow and OverFlow Mode - See ADDV and SUBV for examples.
> * Integer Type: Signed and Unsigned values with sizes of 8-bit,
> 16-bit, 32-bit, and 64-bits.
We're really short on instruction space. We fit j64 in, but had to
repurpose several existing instructions in 64 bit mode to do it.
> Data Loading/Conversion Instructions:
> Bulk Conversion From Integers to Floats, and Floats to integers is a
> must. That said, I'm not exactly sure how many Instructions are needed
> for this, but It would be reasonable to say that four to seven
> instructions may be required.
In Jeff's design you'd copy from register in one mode to register in
another mode, then do a rotate by enough bits you could do the next one,
and a rotate at the end if you needed to restore the register? (Hmmm,
that sounds like it would need an xor on the mode thing between those so
the rotate wasn't within the simd division? Possibly I misunderstood, it
was a while ago...)
More information about the J-core