Put read-only CSRs in the main address space

[Kelly Dean]

If there's CSR number space pressure, the space shouldn't be wasted for CSRs that the ISA spec says are always read-only (e.g. mvendorid, marchid, mimpid, mhartid), since they don't require atomic write or swap support. Instead, put them in a standard part of the address space, and read them using ordinary load instructions.

Then, since there's plenty of space for them, don't ever require probing to figure out platform config, or which CSRs are implemented, or which CSRs (or which parts of which CSRs, e.g. misa) are implemented as read-only vs. read/write when the ISA spec doesn't mandate one or the other. Instead, put in the ISA spec some new standard read-only meta-CSRs to record all that info, for all mandatory and optional CSRs for standard ISA bases and extensions, and for all standard platforms.

To avoid having to store a lot of data in the processor's on-board ROM, compress it by having a single 4-bit read-only master meta-CSR that stores an identifier to specify one of a few popular standard configurations, each of which fully specifies all the options that require probing in the current privileged architecture manual. Then the full meta-CSRs are only required for unusual configurations. Indicate that using master CSR value zero.

Also reserve part of the read-only CSR address space for custom use.

[Samuel Falvo II]

On Wed, Mar 21, 2018 at 8:01 PM, Kelly Dean <ke...@prtime.org> wrote:
> If there's CSR number space pressure, the space shouldn't be wasted for CSRs that the ISA spec says are always read-only (e.g. mvendorid, marchid, mimpid, mhartid), since they don't require atomic write or swap support. Instead, put them in a standard part of the address space, and read them using ordinary load instructions.

This would break backward compatibility.

I think a better idea would be to define a set of CSRs that serve as
indirect references to a larger CSR address space, should this ever
become a problem.

--
Samuel A. Falvo II

[Kelly Dean]

Samuel Falvo II writes:

> This would break backward compatibility.

Only with a privileged architecture proposal that hasn't even been frozen yet. Now is the time to fix things.

> I think a better idea would be to define a set of CSRs that serve as
> indirect references to a larger CSR address space, should this ever
> become a problem.

Yes, that makes much more sense than standardizing an arbitrary part of the address space. (It seems only two indirection CSRs would be needed: base address, and space size.) Though offsets within that indirectly referenced space would still serve as (alternate-domain) CSR numbers, so those offsets would still need to be standardized.

Anyway, don't wait until it becomes a problem. Read-only CSRs that become frozen into the CSR space now can't be removed later to make space for read/write CSRs.

Any thoughts on my idea of meta-CSRs to avoid probing?

[Paul Miranda]

I'd like to get rid of the CSR's completely. I've never understood why the base ISA requires an atomic access method different than the general method, and also requires special instructions to access CSRs instead of just memory mapping them.

Neither choice is very RISC.

[Cesar Eduardo Barros]

Em 22-03-2018 09:36, Paul Miranda escreveu:
> I'd like to get rid of the CSR's completely. I've never understood why
> the base ISA requires an atomic access method different than the general
> method, and also requires special instructions to access CSRs instead of
> just memory mapping them.
> Neither choice is very RISC.

Any proposal to get rid of all CSRs has to answer the following
question: what will happen to fcsr?

It can't be memory-mapped, since writes to it affect the following
floating-point instruction, and reads from it are affected by the
preceding floating-point instruction. Making it memory-mapped would mean
either serializing all memory reads and writes, or special-casing that
memory address and adding pipeline bubbles when it's seen (and if the
memory address is computed too late in the pipeline, it might mean
adding a bubble to every memory access).

>
> On Wednesday, March 21, 2018 at 10:03:36 PM UTC-5, Kelly Dean wrote:
>
> If there's CSR number space pressure, the space shouldn't be wasted
> for CSRs that the ISA spec says are always read-only (e.g.
> mvendorid, marchid, mimpid, mhartid), since they don't require
> atomic write or swap support. Instead, put them in a standard part
> of the address space, and read them using ordinary load instructions.

The mhartid might be read-only, but it's different for each hart. That
is, it's a hart-local value. That makes it a natural fit for a CSR.

> Then, since there's plenty of space for them, don't ever require
> probing to figure out platform config, or which CSRs are
> implemented, or which CSRs (or which parts of which CSRs, e.g. misa)
> are implemented as read-only vs. read/write when the ISA spec
> doesn't mandate one or the other. Instead, put in the ISA spec some
> new standard read-only meta-CSRs to record all that info, for all
> mandatory and optional CSRs for standard ISA bases and extensions,
> and for all standard platforms.

From a certain point of view, the vendor/arch/etc ID are already sort
of a meta-CSR. Software might need to branch on them very early, before
even initializing the memory (or cache-as-memory).

> To avoid having to store a lot of data in the processor's on-board
> ROM, compress it by having a single 4-bit read-only master meta-CSR
> that stores an identifier to specify one of a few popular standard
> configurations, each of which fully specifies all the options that
> require probing in the current privileged architecture manual. Then
> the full meta-CSRs are only required for unusual configurations.
> Indicate that using master CSR value zero.

RISC-V is very flexible, "unusual configurations" will probably be the norm.

--
Cesar Eduardo Barros
ces...@cesarb.eti.br

[Liviu Ionescu]

On 22 March 2018 at 23:28:01, Cesar Eduardo Barros (ces...@cesarb.eti.br) wrote:

> The mhartid might be read-only, but it's different for each
> hart. That
> is, it's a hart-local value. That makes it a natural fit for a CSR.

the mhartid is a natural fit for a CSR, but I would not say that
necessarily because it is hart-local value, but rather because it is
preferable to have a fast way to access it, and from this point of
view I think that a CSR is the fastest.

otherwise hart-local values can very well be memory-mapped, with all
harts seeing the same memory window at the same address.

in the microcontroller profile, where the security concerns are much
weaker, I selected only a very limited number of CSRs for the
registers that need very fast access during interrupt critical
sections and context switches, and all other registers are either in a
Hart Control Block, where each hart maps its registers, or a Device
Control Block, for device wide peripherals and other system registers.

https://github.com/emb-riscv/specs-markdown/blob/develop/csrs.md


regards,

Liviu

[Kelly Dean]

Cesar Eduardo Barros writes:

> Em 22-03-2018 09:36, Paul Miranda escreveu:
>> I'd like to get rid of the CSR's completely. I've never understood
>> why the base ISA requires an atomic access method different than the
>> general method, and also requires special instructions to access
>> CSRs instead of just memory mapping them.
>> Neither choice is very RISC.
>
> Any proposal to get rid of all CSRs has to answer the following
> question: what will happen to fcsr?
>
> It can't be memory-mapped, since writes to it affect the following
> floating-point instruction, and reads from it are affected by the
> preceding floating-point instruction. Making it memory-mapped would
> mean either serializing all memory reads and writes, or special-casing
> that memory address and adding pipeline bubbles when it's seen (and if
> the memory address is computed too late in the pipeline, it might mean
> adding a bubble to every memory access).

Why doesn't this apply to other CSRs too? E.g. writes to misa can affect the following instruction, by changing whether it traps. What's special about fcsr in this regard?

And, why doesn't this apply to memory-mapped device registers too? Writes to them can affect the following load instruction, by affecting the value read (possibly even if the load is from a different address than the register).

[Cesar Eduardo Barros]

Em 28-03-2018 14:18, Kelly Dean escreveu:
>
> Cesar Eduardo Barros writes:
>
>> Em 22-03-2018 09:36, Paul Miranda escreveu:
>>> I'd like to get rid of the CSR's completely. I've never understood
>>> why the base ISA requires an atomic access method different than the
>>> general method, and also requires special instructions to access
>>> CSRs instead of just memory mapping them.
>>> Neither choice is very RISC.
>>
>> Any proposal to get rid of all CSRs has to answer the following
>> question: what will happen to fcsr?
>>
>> It can't be memory-mapped, since writes to it affect the following
>> floating-point instruction, and reads from it are affected by the
>> preceding floating-point instruction. Making it memory-mapped would
>> mean either serializing all memory reads and writes, or special-casing
>> that memory address and adding pipeline bubbles when it's seen (and if
>> the memory address is computed too late in the pipeline, it might mean
>> adding a bubble to every memory access).
>
> Why doesn't this apply to other CSRs too? E.g. writes to misa can affect the following instruction, by changing whether it traps. What's special about fcsr in this regard?

It does apply to misa too, if it's not read-only.

> And, why doesn't this apply to memory-mapped device registers too? Writes to them can affect the following load instruction, by affecting the value read (possibly even if the load is from a different address than the register).

The memory ordering rules for memory-mapped devices is a whole another
can of worms. Depending on the particulars of the I/O region, bus, and
device, you might need an I/O fence between the store and the load,
otherwise the load can reach the device before the store.

For strongly-ordered I/O regions, the load will wait until all preceding
writes to the same I/O region have reached their target device. Of
course, it would be a performance disaster if this happened for every
memory load, but since loads and stores are executed at the same
pipeline step, the memory address of all preceding writes should be
already available (assuming in-order; an out-of-order processor is much
more complicated), so loads to different I/O regions (or the main
memory) don't have to wait for the I/O writes.

[Allen J. Baum]

Note also that:
- making them MMIO would require the A-extension to be useful (else you can't set/clear a field without a non-atomic R-M-W sequence
- it would likely require a physical address range to be permanently carved out of the address space (else, how do you find where it is? By reading a CSR in the address space?)
- that carved out address space would have to be in the +/-2K region - the only region that can be accessed without loading a base register- and that region is already used for the debug spec for exactly the same reason

>--
>You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
>To post to this group, send email to isa...@groups.riscv.org.
>Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
>To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/780b7f7a-afb1-6768-01d0-15f1fef773cb%40cesarb.eti.br.


--
**************************************************
* Allen Baum tel. (908)BIT-BAUM *
* 248-2286 *
**************************************************

[Evan Cox]

You would just require the programmer to fence the store.

[Evan Cox]

Note: I'm not necessarily in favor of ALL CSRs being moved into a memory mapped region. Some may be applicable as CSRs, some may not. But having memory-mapped registers that affect execution doesn't mean you lose all memory-level-parallelism.

[ron minnich]

From an interview: 

Cocke: .... One of the worst ideas we found involved having registers be addressable as part of memory. The justification for that was to make things “clean”—that’s the worst word in computer architecture. Say we had a store instruction. You can’t figure out what is affected by the store. This screwed up all hopes of writing a decent register allocator.

I've always thought he had a good point. 

ron

--

You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/db0f3ab8-f22b-44fe-b200-8b03f857f727%40groups.riscv.org.

[Liviu Ionescu]

On 29 March 2018 at 20:49:35, Evan Cox (evan...@maximintegrated.com) wrote:

> I'm not necessarily in favor of ALL CSRs being moved into a memory
> mapped region. Some may be applicable as CSRs, some may not.

fully agree.

for various reasons (security, speed, etc) a very limited set of
registers should probably remain CSRs, but the bulk of them,
especially the read only ones, can very well be memory mapped.

this is also the approach used by the RISC-V microcontroller proposal:
time critical registers, used to implement interrupt critical regions
(enable/disable interrupts, interrupt threshold) and stack registers
(base and limit, for both thread and interrupt stack) are better as
single cycle csr instructions. all other are memory mapped.


regards,

Liviu

[Paul Miranda]

Probably way too late to change, but in the last micro I built I gave every field its own addressable location (many just single bytes, some were larger and took whole 2- or 4-byte aligned locations) and therefore didn't need any shifting or masking operations.