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

[Rob Landley]

On 10/26/2017 08:00 PM, Cedric BAIL wrote:
>     > 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.
> 
> For the needed addition, as they will not be used very often, having a
> prefix that enable a new instruction set temporary would limit the
> problem. Even then, the instruction space is quite limited and adding an
> instruction require careful thinking and testing different scenario.

Currently there are no prefixes. All the instructions are self-contained
and fixed length. That's one of the main advantages of the instruction
set. The way we do mode shifts is with control register bits.

In theory we could have a transient control register mask that gets
xored with the persistent control register but all its bits are zeroed
after some event (one instruction, next jump, etc). So you could have
something prefix-like, although it would probably make multi-issue more
complicated. But that's something that would have to be designed and
justified and isn't part of the current stuff so there's backwards
compatibility issues...

I.E. that's j64 territory. Right now j3 and j4 are _mostly_ specced as
following the path laid down by Hitachi 20 years ago. Two of the 3 "new"
j-core instructions are backported from j3. We regression test against
old sh2 binaries. We care that this is part of a _family_. (The "born
out of wedlock" jokes are left as an exercise for the reader.)

After sh4 Hitachi handed off the technology to a new company but kept
the design engineers, and the new team did a brand new sh5 instruction
set that nobody was interested in, and that's the point where we need to
forge our own path. So j64 introduces new design elements, although or
model is "what x86-64 did to x86, we're trying to do to shmobile".

So we _were_ discussing SIMD in context of j64. we're not sure whether
we need to move it sooner, or just bear down and get j64 out ASAP. (We'd
love to do the latter, we're working out how to clear engineering time
for it...)

j64 has a control register bit to switch between 32 bit and 64 bit
modes. 32 bit mode is scrupulously compatible with j4. 64 bit mode is
designed around the idea you're probably going to drop back to 32 bit
mode to run 32 bit code, which needs to preserve the high bits of the
registers unchanged and so on...

We're going to try to put together a better j64 proposal in November,
with actual details. (I haven't been back to tokyo since last November,
but my next flight there leaves tuesday morning. There's a backlog of
sitting down with people and writing up documentation...)

> One of the thing that killed the performance of early simd cpu was the
> lack of efficient way of shuffling bits around. I think there is still
> potentially patent on power pc shuffling instruction, but something that
> allow rotation by word step would go a long way (again that can be in
> the vector instruction space).

That is totally a Jeff question. I tried to explain what I remembered of
previous talks with him, and it turns out I don't remember enough. :)

> Cedric

Rob