[J-core] Hi - more info on Super-H advantages

[Dru Nelson]

Hi Rob,

Thank you for those write ups!
I didn't know it was a microcoded design. That is actually pretty neat!
What an interesting hybrid. I'm really glad you guys are doing this.

I still have to read all those other links, and now I will learn more about
these clever choices.


Btw - in the 90s, I was in several environments with DEC, SGI, SUN, and IBM
RISC workstations.
They needed a lot more memory. Once there was a decent unix for x86, it was
so much more cost effective.
(not as good in many ways... but good enough)


Last bit on the 68K mention.


SH-1/SH-2 CPU        Example for Other CPU
MOV.W @(disp,PC),R1  ADD.W #H'1234,R0
ADD R1,R0
 .........
DATA.W H'1234


I have only seen the .W or .B suffixes on Motorola assembly. I checked
PDP-11 assembly, and I didn't see them.
They just didn't have the '.'. It probably cost too many bytes back then.

Also, I know that (as you mention), Hitachi was a second source for many
moto products over the years. So it makes sense.

I will reply more to the other posts in this thread tomorrow.


Dru Nelson
Redwood City



On Fri, Jan 12, 2018 at 12:37 PM, Rob Landley <rob at landley.net> wrote:

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