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

[Ken Phillis Jr]

On Mon, Oct 30, 2017 at 10:11 PM, Rob Landley <rob at landley.net> wrote:
> On 10/29/2017 10:37 PM, Ken Phillis Jr wrote:
>> Information on the SH-3 Is not exactly sparse,
>
> We've noticed.
>
>> This processor has 3 main versions:
>> SH-3: The Feature added in this is MMU Instructions, and these are
>> generally in the System Control Instructions
>
> Yeah, that. Except Jeff decided not to use their MMU design because it
> takes up an unreasonable amount of space in an FPGA (more than doubling
> the size of the SOC). And we already backported sh3's barrel shift
> instructions, most of the rest of the instructions they added were for
> fiddling with the TLB or doing the DSP/FPU stuff.
>
> So j3 is adding _an_ MMU, but not necessarily the sh3 mmu. I'll see if
> we can get more detail posted about the j3 mmu design next month.
>
>> SH-3E: the SH-3 Instructions with 32-bit Floating Point Instructions
>> and registers added.
>
> The problem is 32 bit floating point instructions aren't hugely useful,
> everything interesting's a double. (Even printf("%f") is specced to take
> a double argument, not a float.) So when we do an FPU, we're most likely
> to jump straight to the 64 bit version (with maybe a compile time option
> to strip it down to 32 bits, but we'll see).
>


Not everything is interested in Doubles ( 64-bit floats). I know the C/C++
Library specification is geared to 64-bit floating point, but they do also
include definitions for 32-bit floating point values as well.

Anyways, it's important to offer 32-bit floating point for developers to
use since 95% of games and most major 3d specs use it...

OpenCL v1.2 - double precision floating point is optional.
3D graphics api - generally 32 bit floats are used by programs even though
the spec says 64 bit floats.

OpenGL ES 3.2 - essentially single precision floating point only. The word
double is only used once.
OpenGL ES 2.0 - all 32-bit floating point
OpenVG 1.1 - uses 32 bit floats


Bullet physics - this defaults to single precision floats

Box2D physics - I am fairly sure this also uses 32 bit floats.
>> SH3-DSP Core: SH-3 Instructions with Arithmetic DSP Instructions
>> added. In general these are mostly for Integer and fixed point math.
>
> I'm pretty sure we're not doing that. (I vaguely recall looking at that
> trying to find j64 instruction space, but those had _already_ been
> repurposed by later superh processors. I.E. even later superh didn't
> respect that, and we needed to support the "not that" uses of that
> instruction space in j64...)
>
> I think. Ask me again next week, the notes and people who wrote them are
> in tokyo. :)
>
> (That said, we may wind up adding another simple DSP to the DMA engine.
> Maybe something 8-bit and capable of driving ethernet checksumming, PTP,
> handling the mmc bus state engine... But that's not part of historical
> superh.)
>
>> Also, To see a comparison of the SH1, SH2, SH3, and SH4 lines of
>> chips, you can find the instruction set summary for these at:
>> HTML: http://www.shared-ptr.com/sh_insns.html
>
> Which is the second link at the top of the j-core.org page, and looking
> through a printout of that is how I was finding instructions to
> potentially repurpose for j64 last year. (Which I then pointed the
> actual engineers at so they could do the real research, I was just
> finding candidates.)
>
>> Github: https://github.com/shared-ptr/sh_insns
>>
>>
>> Also, You can find the Programmers manual for the SH3 by searching the
>> Renesas Website for the SH7705 chip, and looking for the following
>> Document:
>> SH-3/SH-3E/SH3-DSP Software Manual
> See the older japanese gentleman standing next to me in the second
> picture in https://lwn.net/Articles/647636/ wearing a red shirt? A
> couple decades back, he was the SuperH platform architect. He had
> _stories_ about SH3 development, and answered a lot of "why did they do
> X" questions. (Not recently, he's moved on to other things. Retired to
> California I think? I remember he still considered Microsoft Windows CE
> compatibility to be important because it was a big customer back when
> sh2 an sh3 were originally developed, so must still be relevant today
> because reasons. He made darn sure j-core ran a lot of old Windows CE
> binaries circa 2014 or so. *shrug* Mostly before my time. Yay
> compatibility testing I suppose.)
>
> Yes, back in the day, wince ran on sh:
>
> https://msdn.microsoft.com/en-us/library/ms882059.aspx
>
> Not currently a development focus of SEI, but if somebody else wanted to
> do stuff, it's open...
>
> Rob
>
> P.S. I'm not the expert on any of this, I'm just chatty. I try to keep
> up with the mailing list and with what everybody else is doing. we're
> trying to resurface from the last 18 months of crazy, and when we do
> I'll see if I can... I dunno, get Jeff to drop into the #j-core irc
> channel on freenode for half an hour each week or something. Keep in
> mind he's usually in japan so his day is US night.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20171031/f50558e9/attachment.html>