<div dir="auto">On Mon, Oct 30, 2017 at 10:11 PM, Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br>> On 10/29/2017 10:37 PM, Ken Phillis Jr wrote:<br>>> Information on the SH-3 Is not exactly sparse,<br>><br>> We've noticed.<br>><br>>> This processor has 3 main versions:<br>>> SH-3: The Feature added in this is MMU Instructions, and these are<br>>> generally in the System Control Instructions<br>><br>> Yeah, that. Except Jeff decided not to use their MMU design because it<br>> takes up an unreasonable amount of space in an FPGA (more than doubling<br>> the size of the SOC). And we already backported sh3's barrel shift<br>> instructions, most of the rest of the instructions they added were for<br>> fiddling with the TLB or doing the DSP/FPU stuff.<br>><br>> So j3 is adding _an_ MMU, but not necessarily the sh3 mmu. I'll see if<br>> we can get more detail posted about the j3 mmu design next month.<br>><br>>> SH-3E: the SH-3 Instructions with 32-bit Floating Point Instructions<br>>> and registers added.<br>><br>> The problem is 32 bit floating point instructions aren't hugely useful,<br>> everything interesting's a double. (Even printf("%f") is specced to take<br>> a double argument, not a float.) So when we do an FPU, we're most likely<br>> to jump straight to the 64 bit version (with maybe a compile time option<br>> to strip it down to 32 bits, but we'll see).<br>><br><br><br>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. <div dir="auto"><br></div><div dir="auto">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...</div><div dir="auto"><br></div><div dir="auto">OpenCL v1.2 - double precision floating point is optional.</div><div dir="auto">3D graphics api - generally 32 bit floats are used by programs even though the spec says 64 bit floats. </div><div dir="auto"><br></div><div dir="auto">OpenGL ES 3.2 - essentially single precision floating point only. The word double is only used once.</div><div dir="auto">OpenGL ES 2.0 - all 32-bit floating point</div><div dir="auto">OpenVG 1.1 - uses 32 bit floats</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Bullet physics - this defaults to single precision floats</div><div dir="auto"><br></div><div dir="auto">Box2D physics - I am fairly sure this also uses 32 bit floats.<br>>> SH3-DSP Core: SH-3 Instructions with Arithmetic DSP Instructions<br>>> added. In general these are mostly for Integer and fixed point math.<br>><br>> I'm pretty sure we're not doing that. (I vaguely recall looking at that<br>> trying to find j64 instruction space, but those had _already_ been<br>> repurposed by later superh processors. I.E. even later superh didn't<br>> respect that, and we needed to support the "not that" uses of that<br>> instruction space in j64...)<br>><br>> I think. Ask me again next week, the notes and people who wrote them are<br>> in tokyo. :)<br>><br>> (That said, we may wind up adding another simple DSP to the DMA engine.<br>> Maybe something 8-bit and capable of driving ethernet checksumming, PTP,<br>> handling the mmc bus state engine... But that's not part of historical<br>> superh.)<br>><br>>> Also, To see a comparison of the SH1, SH2, SH3, and SH4 lines of<br>>> chips, you can find the instruction set summary for these at:<br>>> HTML: <a href="http://www.shared-ptr.com/sh_insns.html" target="_blank">http://www.shared-ptr.com/sh_<wbr>insns.html</a><br>><br>> Which is the second link at the top of the <a href="http://j-core.org" target="_blank">j-core.org</a> page, and looking<br>> through a printout of that is how I was finding instructions to<br>> potentially repurpose for j64 last year. (Which I then pointed the<br>> actual engineers at so they could do the real research, I was just<br>> finding candidates.)<br>><br>>> Github: <a href="https://github.com/shared-ptr/sh_insns" target="_blank">https://github.com/shared-ptr/<wbr>sh_insns</a><br>>><br>>><br>>> Also, You can find the Programmers manual for the SH3 by searching the<br>>> Renesas Website for the SH7705 chip, and looking for the following<br>>> Document:<br>>> SH-3/SH-3E/SH3-DSP Software Manual<br>> See the older japanese gentleman standing next to me in the second<br>> picture in <a href="https://lwn.net/Articles/647636/" target="_blank">https://lwn.net/Articles/<wbr>647636/</a> wearing a red shirt? A<br>> couple decades back, he was the SuperH platform architect. He had<br>> _stories_ about SH3 development, and answered a lot of "why did they do<br>> X" questions. (Not recently, he's moved on to other things. Retired to<br>> California I think? I remember he still considered Microsoft Windows CE<br>> compatibility to be important because it was a big customer back when<br>> sh2 an sh3 were originally developed, so must still be relevant today<br>> because reasons. He made darn sure j-core ran a lot of old Windows CE<br>> binaries circa 2014 or so. *shrug* Mostly before my time. Yay<br>> compatibility testing I suppose.)<br>><br>> Yes, back in the day, wince ran on sh:<br>><br>>   <a href="https://msdn.microsoft.com/en-us/library/ms882059.aspx" target="_blank">https://msdn.microsoft.com/en-<wbr>us/library/ms882059.aspx</a><br>><br>> Not currently a development focus of SEI, but if somebody else wanted to<br>> do stuff, it's open...<br>><br>> Rob<br>><br>> P.S. I'm not the expert on any of this, I'm just chatty. I try to keep<br>> up with the mailing list and with what everybody else is doing.  we're<br>> trying to resurface from the last 18 months of crazy, and when we do<br>> I'll see if I can... I dunno, get Jeff to drop into the #j-core irc<br>> channel on freenode for half an hour each week or something. Keep in<br>> mind he's usually in japan so his day is US night.</div></div>