
Ratification of the RISC-V Base ISA and Privileged Architecture Specifications - matt_d
https://riscv.org/2019/07/risc-v-foundation-announces-ratification-of-the-risc-v-base-isa-and-privileged-architecture-specifications/
======
monocasa
I wish they had waited until the riscv-formal work was a little farther on. I
have a distinct feeling we're going to uncover some goofiness in the spec from
that work.

~~~
fluffything
At some point you have to ship, and thanks to the awesomeness of semantic
versioning, they can always release RISC-VI :)

/s

~~~
panpanna
There is no reason "move fast and break things" should not work for hardware
too

/S

------
snvzz
While I haven't looked hard into it, I hope they didn't throw in assumptions
that affect context switch speed, particularly on pure microkernel multiserver
systems that depend on it and are used in critical applications that require
high assurance and low, bounded IPC and interrupt response times.

~~~
DSingularity
What are examples of such systems?

~~~
harry8
There are none of any practical use, but we live in hope.

~~~
p_l
If you use a phone with a Qualcomm modem you use one such system, based on
OKL4 (or at least they used to use OKL4 + L4 Linux for non hard RT parts)

~~~
harry8
Not a multi-server operating system. Source: worked on it.

Unless it changed, L4 is used with additional code co-located as the base-band
modem on its own cpu. Small RTOS is not a multi-server micro-kernel based os.

~~~
p_l
I suspect we might be using different meanings of multi-server microkernel OS,
unless the modem software is even more limited than I thought - I meant that
the system is composed of multiple communicating servers. Does the modem just
have few independent colocated "big" servers (like the ancient 4.2 BSD server
for Mach)?

EDIT: Also, had some fun in the past learning about the modem software on
Qualcomm modems, back before iPhone or Android so nice to meet someone who
worked on it :)

------
amluto
I haven’t read the latest version, but early versions had a mechanism for
kernel entries that was too simple. An interrupt that happened right after a
kernel entry but before any instructions executed would be unrecoverable. A
good CPU design should help enough with exceptions and interrupts that state
won’t be lost.

As an example of the wrong approach, x86’s SYSENTER just switches to kernel
mode and updates the program counter. x86’s interrupts are better — they push
all clobbered state to the stack.

------
ncmncm
I just hope it's not too late to make the ABI represent Boolean false with ~0.

We won't get another chance to do this right for a long, long time.

~~~
JoshTriplett
This would utterly break the expectations of anyone coming from another
platform, and a substantial amount of existing C code. (Whether that C code
was _allowed_ to make that assumption or not, it _did_.)

Leaving aside whether the behavior you propose qualifies as "right": no, I
don't think there is any chance to change the encoding of "bool", any more
than you can redefine the size of "char" or the value of CHAR_BITS. The world
uses 8-bit bytes, the world uses twos-complement (C recently wrote that into
the standard), and the world uses 0 for false and 1 for true.

~~~
nwallin
There is a concrete advantage to using a scheme where 0 is true and all other
values are false: error codes. True means the operation succeeded correctly,
or false because of insufficient permissions, false because there file doesn't
exist, false because of io error, false because of timeout etc. bash uses this
scheme.

However, this ship has sailed for general purpose programming languages. 0 is
false, all other values are interpreted as true, operations that create a bool
create 1. As you say, that's just how the world works.

False = ~0 is just zany though.

~~~
JoshTriplett
> There is a concrete advantage to using a scheme where 0 is true and all
> other values are false: error codes. True means the operation succeeded
> correctly, or false because of insufficient permissions, false because there
> file doesn't exist, false because of io error, false because of timeout etc.
> bash uses this scheme.

That works perfectly fine if you write the type as an integer type and define
0 as "no error". You can't call that a C "bool" though.

~~~
fluffything
> You can't call that a C "bool" though.

In hardware, C _Bool is just an scalar integer type (1 byte wide almost
everywhere these days).

If you define 0 for false, and true otherwise, you can emit much better
machine code for all scalar comparisons. For example, when doing scalar == 0
or scalar != 0 (e.g. in null pointer checks) the result is always the scalar
itself. The test is a nop, and with "branch on non-zero" instruction, you can
just directly branch.

If you define true to some value, you need to actually test whether the scalar
is zero, and give it some other value otherwise. That goes from zero
instructions to often two instructions (e.g. if the hardware comparison
returns 0xffff and you need to convert that to 1).

