<div dir="ltr">Hi Rob,<div><br></div><div>Thank you for those write ups!</div><div>I didn't know it was a microcoded design. That is actually pretty neat!</div><div>What an interesting hybrid. I'm really glad you guys are doing this.</div><div><br></div><div>I still have to read all those other links, and now I will learn more about these clever choices.</div><div><br></div><div><br></div><div>Btw - in the 90s, I was in several environments with DEC, SGI, SUN, and IBM RISC workstations.</div><div>They needed a lot more memory. Once there was a decent unix for x86, it was so much more cost effective.</div><div>(not as good in many ways... but good enough)</div><div><br></div><div><br></div><div>Last bit on the 68K mention.</div><div><br></div><div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">SH-1/SH-2 CPU        Example for Other CPU</font></div><div><font face="monospace, monospace">MOV.W @(disp,PC),R1  ADD.W #H'1234,R0         </font></div><div><font face="monospace, monospace">ADD R1,R0 </font></div><div><font face="monospace, monospace"> ......... </font></div><div><font face="monospace, monospace">DATA.W H'1234</font></div></div><div><br></div><div><br></div><div>I have only seen the .W or .B suffixes on Motorola assembly. I checked PDP-11 assembly, and I didn't see them.</div><div>They just didn't have the '.'. It probably cost too many bytes back then.</div><div><br></div><div>Also, I know that (as you mention), Hitachi was a second source for many moto products over the years. So it makes sense.</div><div><br></div><div><div>I will reply more to the other posts in this thread tomorrow.</div></div><div><br></div><div><div style="font-size:12.8px"><br class="gmail-Apple-interchange-newline">Dru Nelson</div><div style="font-size:12.8px">Redwood City</div></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 12, 2018 at 12:37 PM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/11/2018 03:58 PM, BGB wrote:<br>
> (outsider perspective / thoughts; my efforts are independent from those<br>
> of the J-Core project, so sentiments may differ).<br>
<br>
</span>It's an open source project, and the original poster was asking<br>
questions about superh which was developed ~20 years ago and has been<br>
out in public for a while, we're by no means the only people who know<br>
about it. :)<br>
<br>
I don't remotely speak for the whole of the j-core project either, I'm<br>
mostly working on Linux code that runs on it and a bit of documentation.<br>
I've helped debug deep into the guts of the hardware, worked with the<br>
devs to get SMP working, and been to japan to hang out with the hardware<br>
guys a half-dozen times over the past 3 years. So I can pass on a lot of<br>
stuff I learned from other people (some of whom do not speak english as<br>
a first language). But they're the experts...<br>
<span class=""><br>
> On 1/11/2018 5:06 AM, Dru Nelson wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I saw a video of the announcement of the j-core project a while back.<br>
>> The project impressed me, and I made a note to learn more.<br>
>><br>
>> Without that presentation, I would not have known about the advantages<br>
>> of the SH architecture.<br>
>> For example, I would not have known about the code-density of the SH.<br>
>> I would have just assumed it was like all the other RISCs. (32 bit<br>
>> instructions)<br>
><br>
> luckily, code density is pretty good if compared with 32-bit RISCs.<br>
><br>
> but, it comes with a drawback in frequently needing to execute longer<br>
> sequences of instructions for many operations, which partly works as<br>
> counter-balance to the shorter instructions in some cases.<br>
<br>
</span>That was the downside of conventional RISC. SuperH used microcode so a<br>
single instruction could take multiple clock cycles when it had<br>
something complicated to do. That's built into the code density metrics<br>
we use, mostly "Compile this, what's the resulting binary look like?"<br>
<span class=""><br>
> in my own testing, it is loosely comparable to x86 (but varies a fair<br>
> bit by compiler and other factors though;<br>
<br>
</span>Um, so does x86?<br>
<span class=""><br>
> and comparison requires<br>
> compensating for the relative sizes of the C libraries and similar).<br>
<br>
</span>Is there an architecture this isn't true for?<br>
<span class=""><br>
> Thumb2 is a fair bit more formidable in code density though, and<br>
<br>
</span>He asked about the development of superh. Thumb came after superh (and<br>
licensed superh patents). Thumb2 was a second iteration developed years<br>
after the original thumb, which has at least a decade to go on its patents.<br>
<br>
(I'm still waiting for a cortex-m with mmu. Last I checked thumb2 still<br>
hadn't shipped as an independent instruction set with mmu, only as<br>
extension of arm chips with mmu.)<br>
<span class=""><br>
> generally gives a better performance relative to the total number of<br>
> instructions executed (this is a weak area for the basic SH ISA vs<br>
> Thumb2 or RISC-V's RVC coding or similar).<br>
<br>
</span>Things developed after superh do other things, sure. J-core added<br>
cmpxchg so we could do proper modern SMP and futexes, for example.<br>
Should I talk about j64 or our proposed vector extensions here? I didn't<br>
think that was relevant to the original question...<br>
<br>
(We have a "j0" project under consideration that involves yanking<br>
unused/underused instructions to get a really _tiny_ chip. Our general<br>
idea is "if j2 runs j0 code then it's the same family". But all<br>
optimizing is optimizing _for_ something. For example, power consumption<br>
to performance tradeoffs have been a big thing for a while, readahead<br>
and speculative execution and register renaming and such do work that's<br>
sometimes discarded, gaining performance at the expense of power<br>
efficiency. The are other tradeoffs of die size, auditability, what's<br>
involved in fabbing an asic (on which process with which manufacturing<br>
partners), an entire landscape of IP claims... heck, the j-core build<br>
has three versions of some files optimized for ghdl, fpga, or asic,<br>
depending on what you configure it to build.)<br>
<span class=""><br>
> experimentally, it is possible to improve the ISA on both factors<br>
> (making it both smaller and getting more work done in fewer<br>
> instructions),<br>
<br>
</span>I.E. he's been posting on here about his own home-grown architecture<br>
that's not related to j-core. It's a bit like posting about llvm on the<br>
gcc list because they're both C compilers, or netbsd on the linux kernel<br>
mailing list because they're both unixes. (Well, more like a developer<br>
going "I wrote my own kernel from scratch, it also implements posix<br>
system calls so you can compile some linux software for it, I'm on the<br>
only contributor and I haven't got a mailing list for this project but<br>
let me tell you what I did instead of procfs...")<br>
<br>
Alas, there isn't a "superh" mailing list the same way there isn't a<br>
"unix" mailing list where linux and darwin and openbsd and solaris are<br>
all on an equal footing. (Well, not since the usenet days.) So he posts<br>
here. It kind of annoys the developers at SEI (the company that<br>
sponsored j-core development through its open source release), who have<br>
have been shipping real products to customers for years. (Not in nearly<br>
the _volumes_ they'd like, but still.)<br>
<br>
I suppose if he could get Linux to run on his project he could start<br>
talking about his thing on the linux-sh kernel mailing list instead? It<br>
would be slightly less off-topic than posting about it here...<br>
<br>
It's nice that other people are interested in the superh instruction set<br>
again. Even Renesas has started investing in it again (as far as I can<br>
tell, on the logic that if the j-core guys see value there, they must<br>
have missed something, but everything I've heard there is thirdhand).<br>
<br>
But j-core is a specific development project. (Which really really<br>
REALLY needs to get the code up on github already, the last tarball's<br>
over a year out of date. It's our fault we haven't been able to take<br>
proper advantage of the community contributions...)<br>
<span class=""><br>
> decided mostly to leave out specifics for 32 vs 64-bit ISA variants<br>
> (as-is there are several 64b variants, still TBD which will be<br>
> "canonical"),<br>
<br>
</span>Jeff has had it written down in a folder in his office for something<br>
like 2 years now?<br>
<br>
Oh, you're still referring to your emulator.<br>
<span class=""><br>
> in my case, the project to do an FPGA implementation of these is still<br>
> ongoing, but is going slowly; basically, the amount of work required to<br>
> make something work plausibly, and synthesize with a plausible resource<br>
> cost; is a fair bit harder than what one may experience writing code in<br>
> C or similar (combined with my relative inexperience here, and being new<br>
> to CPU design, ..., is making this project go a bit slowly).<br>
<br>
</span>And what would work in an fpga can be very different from what would<br>
work in an asic, and that's before you get to "floorplan" work to<br>
optimize for specific fabs or FPGA models...<br>
<span class="HOEnZb"><font color="#888888"><br>
Rob<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
J-core mailing list<br>
<a href="mailto:J-core@lists.j-core.org">J-core@lists.j-core.org</a><br>
<a href="http://lists.j-core.org/mailman/listinfo/j-core" rel="noreferrer" target="_blank">http://lists.j-core.org/<wbr>mailman/listinfo/j-core</a><br>
</div></div></blockquote></div><br></div>