[Arm-netbook] riscv-basics.com

[Luke Kenneth Casson Leighton]

On Tue, Jul 10, 2018 at 10:11 PM, Richard Wilbur
<richard.wilbur at gmail.com> wrote:

>> On Jul 10, 2018, at 13:37, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
>>  interestingly the bullet-points 3 and 5 are *actuallly
>> legitimate concerns*.  the RISC-V Foundation is over-controlled by UCB
>> Berkeley,[0] via a structure that is similar to the failed Google Project
>> Ara ("it's open as long as you sign our secret agreement and don't
>> publish information we don't want you to").
>
> Are you referring to "Design Assurance"(as 3) and "Security"(as 5)?

 fragmentation risk and cost.

> Seems like an advertisement specifically against risc-v by and for ARM.

 indeed... one that that has been well-researched and partly has
merit.  other aspects definitely do not.

> I'm sorry to hear about those terms on a project with any pretensions of being "open".

 i know.  i was... extremely optimistic and hopeful when i started
hearing about RISC-V, particularly that it was intended to solve mny
of the issues and mistakes made in RISC design over the past 30+
years.

 however that quickly turned to shock, then puzzlement, and now i'm
wondering where to go from here, as i learned over time that the UC B
team behind RISC-V, although they have achieved absolutely fantastic
things, are... unable to let go of control of the development process,
shall we say.

 it comes down basically to them being technically brilliant.
sufficiently brilliant that they are unable to appreciate that other
people may have very good reasons for wanting to do something quite
differently from how they envisaged it should be done.

 there are many many examples from a huge range of levels of needs,
from a huge range of diverse contributors.  the MIT Team for example,
who want to do research into formally-secure processors,
*specifically* require "Total Store Order" memory semantics.  as in,
when a memory access (load or store) is requested, the order is
ABSOLUTELY guaranteed to be preserved (and speed and cacheing and
out-of-order execution can go take a running jump).

 however.... the RISC-V memory model was *specifically* designed by UC
B with some *specific* design criteria and *specific* optimisations
and a lot of research.... consequently MIT had to fight tooth and nail
just to get a single one-page chapter put into the specification.

 anyway.

 i'll be in Chennai next week, i'm giving a talk on the Libre RISC-V SoC.

l.