[J-core] [RFC] SIMD extention for J-Core

Ken Phillis Jr kphillisjr at gmail.com
Thu Oct 26 21:58:19 EDT 2017

On Thu, Oct 26, 2017 at 6:14 PM, Rob Landley <rob at landley.net> wrote:
> 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...

I forgot that the SIMD.IMODE, and SIMD.FMODE Instructions is to avoid
added complexity of managing this information on a per-register basis.
In general I think a single Instruction for converting between
same-size types is more than enough....

SIMD.TypeConv - This instruction is a bidirectional conversion two and
from data types of the same size.  A few example conversions are as
* Signed Integer and Unsigned Integer
* Integers and Floats
* Fixed Point value(s) and floating point.

>> 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...)
> Rob

The SIMD registers are generally treated as General Purpose Registers.
This means that each register stores bytes, and does not contain any
information on what is actually stored. It is up to the Programmer to
properly manage the simd calls on their own. This is a feature that
generally is seen in MMX/SSE, and other types of SIMD Math systems.

More information about the J-core mailing list