<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 10/31/2017 1:34 AM, Ken Phillis Jr
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACiKS=TBGy0OSGGbgn9yKHSubUok992rGSYb19EZyUv36xV6dw@mail.gmail.com">
<div dir="auto">On Mon, Oct 30, 2017 at 10:11 PM, Rob Landley <<a
href="mailto:rob@landley.net" target="_blank"
moz-do-not-send="true">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>
</blockquote>
<br>
yes, basically true from what I have seen (namely, 32-bit single
precision being the more dominant type in-use in-practice).<br>
<br>
it is possible to have an FPU that does both, eg, by up-converting
to double internally and then down-converting the result. this is a
modest cost if one skips over supporting denormals (it is mostly
bit-twiddly, which is fairly cheap). though, an alternative is
having the main "unit" have a single/double flag, and
unpacking/repacking the output into the desired format directly
(sparing some details here).<br>
<br>
usual advantages to single being that it supports doing a lot more
numbers without eating as much memory.<br>
<br>
for similar reasons, half-float can often be pretty useful (even
when not supported by hardware), though a case could (possibly) be
made for an instruction to handle F16 <-> F32 conversion
(rather than doing it using function calls and explicit bit-twiddly;
newer x86 and ARM have special instructions for this).<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CACiKS=TBGy0OSGGbgn9yKHSubUok992rGSYb19EZyUv36xV6dw@mail.gmail.com">
<div dir="auto">
<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>
</div>
</div>
</blockquote>
<br>
supporting double probably wouldn't mean a lacking single (in any
sane world).<br>
<br>
OTOH: not supporting double could mean either a performance hit (due
to emulating it in cases where it is used), or potentially
unacceptable loss of precision or other issues (in cases where a
double is actually needed).<br>
<br>
there is some uncertainty, for example, when mixing precision in
expressions. the normal C rules specify a slower but more precise
route (namely to always promote to double), whereas cheaper (and
sometimes done by compilers in-practice) is to quietly demote the
double to float in cases where the result will need to be float
(such as assigning the result to a float variable).<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CACiKS=TBGy0OSGGbgn9yKHSubUok992rGSYb19EZyUv36xV6dw@mail.gmail.com">
<div dir="auto">
<div dir="auto">>> 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" moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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>
</div>
</div>
</blockquote>
<br>
interestingly, although VS2015 seems to lack an SH cross compiler
(and WinCE+SH is basically EOL'ed), its other tools are apparently
still able to work with WinCE SH objects/binaries.<br>
<br>
was also able to build binutils for WinCE before, but GCC proper
also seems to have since dropped support (could probably be revived
if someone wanted to beat on it enough).<br>
<br>
though, it is possible a lot of this still exists somewhere "in the
wild" though.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CACiKS=TBGy0OSGGbgn9yKHSubUok992rGSYb19EZyUv36xV6dw@mail.gmail.com">
<div dir="auto">
<div dir="auto">> 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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
J-core mailing list
<a class="moz-txt-link-abbreviated" href="mailto:J-core@lists.j-core.org">J-core@lists.j-core.org</a>
<a class="moz-txt-link-freetext" href="http://lists.j-core.org/mailman/listinfo/j-core">http://lists.j-core.org/mailman/listinfo/j-core</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>