This is somewhat ironic. Part of the reason RISC V is so good in
this space is that all the parts on the chip can use RISC V. Instead
of a SOC having 10 different instruction sets, all the parts can use a
single language making it easier to develop embedded products.
yes - although the licensing cost of those various CPUs is also
a key decision factor (a plus). however it's not quite that simple.
take for example a company i know of that has developed its own
RISC-V embedded core: they added a custom instruction to it,
and then to binutils, and then to gcc, which greatly improved
performance. that means that for *that one core*, there is a
custom gcc/binutils toolchain that *only* works with that one core.
now repeat that exercise for all 10 (proposed, above) cores.
but, hey, it's a proprietary product, so it's the product development
team's problem to deal with the 10 incompatible versions of
binutils/gcc.
I'm no expert on RISC V, but I recommend you look at forums with
experts who can rebut the claims you linked as they are not valid.
Looking at one side is never a good idea.
you may not be aware that i have been working with ISA standards
development now for over 4 years, and am now a member of the
Power ISA Working Group, developing instructions and RFCs for
dramatically upgrading the Power ISA.
And as I said, with regards to HPC, which is what you talked about
in your original post,
ah - i didn't, specifically, but it's a good example as any. adrian_b
used libgmp as a good example
the ability to add extra instructions is
essential to the success. They are part of the intentional design of
RISC V.
i know. proponents of RISC-V parrot the kool-aid that there are
only two scenarios: the embedded one (uncontrolled custom area)
and the linux/unix/posix one (tightly controlled by the RISC-V ISA WG).
these two areas are conflated: there are misunderstandings even
amongst the RISC-V Founders and their supporters. or, more like:
they know exactly what the problems are but are not willing to admit
them publicly.
As for middle level stuff, like phones, I also see no problem with
RISC V. For example, Apple and Google have custom chips and have a
full stack of tools to compile for that hardware. There is no issue
with binaries for a range of reasons.
the Java Compilation is where Android will be able to avoid problems.
but that's *only* Android. here, yes, absolutely you are right about the
majority of apps (those that are released as java bytecode): the java
bytecode will be JIT compiled *on the device* to utilise whatever custom
opcodes are on that hardware.
but you missed that i mentioned (or i forgot to mention, apologies!) that
the low-level libraries will still be hopelessly incompatible, as will any
apps compiled directly for that android device. got a great native app for
the Xiantue910? want to make it general-purpose and run on other
devices? tough: you can't use the custom Xiantue910 opcodes because
*other devices don't support them*. users then download your app
for the Xiantue910 core and complain "this is s***! performance is 50%
lower!!!"
yeh? you see how that goes?
the staggering increase in performance by those rogue instructions
is so compelling (50% increase in performance) that other hardware
designers will be forced to implement them. that literally destroys -
takes over - the custom opcode space as a de-facto uncontrolled,
unmanaged, unauthorised standard, completely defeating the purpose
of having reserved custom opcode space.
this is the middle-ground - the 3rd scenario - that absolutely nobody
wants to hear. it's happened in the past (with other ISAs), it's going
to happen here, but the fact that it's a complex scenario that *hasn't*
happened - yet - is why nobody is listening to what i'm saying.
In general, for things like PCs, it might be a bit of a burden to
recompile, but it's doable.
for products for which source is available? mmm... yes.... but... you're
familiar with the fire-and-forget manufacturing paradigm, and how
DRM and GPL violations are endemic?
for products for which source is *not* available? no chance.
bottom line: it's going to get... messy.
If there are big advantages then people
will not mind. For less important stuff, the basic instructions will
still work, just as we see with things like SSE instruction.
indeed. and what happens when the performance of the non-basic
instructions (the custom ones) is so great that there are actual
user complaints and loss of sales?
let's say that there are two such products - both using the exact
same Custom opcode space. once silicon is out the door, that's
it: you can never go back. that's product out there for the next
decade or more that will "interfere" with binary interoperability.
many ISAs have made this mistake, and been through this
non-interoperability hell. and it's *baked in* to the RISC-V ISA!
it's *permitted* according to the actual RISC-V ISA License that
anyone can cause this absolute havoc!
For the embedded space, as you mention, RISC V has already won.
While it takes years for things to hit the market, the pipeline is
already dominated by RISC V for a range of reasons.
it's a pipeline that (apart from in the embedded proprietary area)
is still yet to spit out actual public useable mass-volume products.
the first commonly-used, mass-volume public high-profile
end-user-programmable product isn't a problem (because the de-facto
dominance of the custom opcode space has no competitor).
it's when you get TWO commonly-used, mass-volume public high-profile
end-user-programmable products, both competing in the same space,
and both using the same Custom binary Opcodes for INCOMPATIBLE
purposes, that the shit hits the fan.
this is what people don't want to hear, don't want to listen. and it hasn't
happened "yet" therefore it can be ignored. standards don't work that
way. the responsibility of a Standards Writier is precisely to think through
these long-term nightmare scenarios and come up with ways to nullify
them. you get one chance and one chance only to get a Standard right.
one mistake and in the Silicon World you're literally living with it for
20+ years. it's... pretty mind-melting.