|
Re: [RISC-V] [tech-config] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
A very, very old version of the Priv spec apparently talked about config strings (based on the preface for v1.9.1).
Paul just pointed out to me that the 'dataaccess' field in the 'hartinfo' Debug
|
A very, very old version of the Priv spec apparently talked about config strings (based on the preface for v1.9.1).
Paul just pointed out to me that the 'dataaccess' field in the 'hartinfo' Debug
|
By
Greg Favor
·
#738
·
|
|
Re: [RISC-V] [tech-chairs] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
OK, if there is no decoding advantage to alignment, then the only reason is to reserve the low order bits for some future use - this I will readily concede.
I don't believe there is a decoding
|
OK, if there is no decoding advantage to alignment, then the only reason is to reserve the low order bits for some future use - this I will readily concede.
I don't believe there is a decoding
|
By
Allen Baum
·
#737
·
|
|
Re: [RISC-V] [tech-config] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
I am merely reporting verbatim from the debug spec. I don't remember where or if it exists there.
I am misremembering about the shadowing; it could be, but the spec doesn't specify it; its an
|
I am merely reporting verbatim from the debug spec. I don't remember where or if it exists there.
I am misremembering about the shadowing; it could be, but the spec doesn't specify it; its an
|
By
Allen Baum
·
#736
·
|
|
Re: [RISC-V] [tech-chairs] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
For cost-sensitive embedded designs the RVM profile spec or the M platform spec is free to place a 4B, 8B, or whatever desired alignment constraint (and require all the lsb's to be hardwired to
|
For cost-sensitive embedded designs the RVM profile spec or the M platform spec is free to place a 4B, 8B, or whatever desired alignment constraint (and require all the lsb's to be hardwired to
|
By
Greg Favor
·
#735
·
|
|
Re: [RISC-V] [tech-config] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
Where? The Priv spec does not discuss configuration strings. And the Unpriv spec only discusses ISA naming strings.
Trigger Module registers are only CSR-mapped, and Debug Module registers are
|
Where? The Priv spec does not discuss configuration strings. And the Unpriv spec only discusses ISA naming strings.
Trigger Module registers are only CSR-mapped, and Debug Module registers are
|
By
Greg Favor
·
#734
·
|
|
Re: [RISC-V] [tech-chairs] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
The cost of an artificial alignment is, as you say, at most 3 or 7 bytes, out of no less than hundreds of bytes (and probably no less than thousands).
I would go further and say that an alignment
|
The cost of an artificial alignment is, as you say, at most 3 or 7 bytes, out of no less than hundreds of bytes (and probably no less than thousands).
I would go further and say that an alignment
|
By
Allen Baum
·
#733
·
|
|
Re: [RISC-V] [tech-chairs] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
The latter. Reserving two lsb's of an address register soley for other unknown future potential non-address purposes would be a new and atypical thing to do in RISC-V architecture. And if there is
|
The latter. Reserving two lsb's of an address register soley for other unknown future potential non-address purposes would be a new and atypical thing to do in RISC-V architecture. And if there is
|
By
Greg Favor
·
#732
·
|
|
Re: [RISC-V] [tech-config] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
and to add more detail to Tin's comment: the debug spec has 4 debug registers (which are not aCSRs) which hold the address of the configuration string:
When confstrptrvalid is set, reading this
|
and to add more detail to Tin's comment: the debug spec has 4 debug registers (which are not aCSRs) which hold the address of the configuration string:
When confstrptrvalid is set, reading this
|
By
Allen Baum
·
#731
·
|
|
Re: [RISC-V] [tech-chairs] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
Allen,
I would like to avoid any artificial alignment, especially if it is introduced only for some undefined future extension.
This CSR points to a sequence of bytes, which makes its natural
|
Allen,
I would like to avoid any artificial alignment, especially if it is introduced only for some undefined future extension.
This CSR points to a sequence of bytes, which makes its natural
|
By
Philipp Tomsich <philipp.tomsich@...>
·
#730
·
|
|
Re: [RISC-V] [tech-config] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
I'd like to add that there are technical reasons why the reset state of CSRs not be some fixed (non trivial) value, especially in high end systems that have large physical register files.
Some small
|
I'd like to add that there are technical reasons why the reset state of CSRs not be some fixed (non trivial) value, especially in high end systems that have large physical register files.
Some small
|
By
Allen Baum
·
#729
·
|
|
Re: [RISC-V] [tech-chairs] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
I'm unclear whether you are objecting to 4 byte alignment, or reserving the low bits for something else in the future.
In any case, I am not seeing why 4 byte alignment should cause any issue even
|
I'm unclear whether you are objecting to 4 byte alignment, or reserving the low bits for something else in the future.
In any case, I am not seeing why 4 byte alignment should cause any issue even
|
By
Allen Baum
·
#728
·
|
|
Re: [RISC-V] [tech-config] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
Now we’d need to save $a5 somewhere we can get at it later on… with a CSR, the value can be retrieved whenever needed. Note that I’d love to have a sane C runtime (with at least a stack
|
Now we’d need to save $a5 somewhere we can get at it later on… with a CSR, the value can be retrieved whenever needed. Note that I’d love to have a sane C runtime (with at least a stack
|
By
Philipp Tomsich <philipp.tomsich@...>
·
#727
·
|
|
Re: Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
Fair enough. We can invent other mechanisms for future use if needed.
Tim
|
Fair enough. We can invent other mechanisms for future use if needed.
Tim
|
By
Tim Newsome <tim@...>
·
#726
·
|
|
Re: [RISC-V] [tech-config] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
Couldn't the reset state itself just have a5=<pointer>? I don't see why that would be substantially harder to implement than a reset state with CSR[0x750]=<pointer>.
Jonathan
|
Couldn't the reset state itself just have a5=<pointer>? I don't see why that would be substantially harder to implement than a reset state with CSR[0x750]=<pointer>.
Jonathan
|
By
Jonathan Behrens <behrensj@...>
·
#725
·
|
|
Re: [RISC-V] [tech-config] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
The issue is that coming out of reset, early M-mode software needs to be able to find the config structure. If the pointer is in a GPR, who sets the correct value into that register and how does that
|
The issue is that coming out of reset, early M-mode software needs to be able to find the config structure. If the pointer is in a GPR, who sets the correct value into that register and how does that
|
By
Greg Favor
·
#724
·
|
|
Re: [RISC-V] [tech-chairs] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
In any case (and reversing an earlier response I made to Tim), since this extension is not specifying an overall discovery method and is just specifying one small generic ISA hook, any special added
|
In any case (and reversing an earlier response I made to Tim), since this extension is not specifying an overall discovery method and is just specifying one small generic ISA hook, any special added
|
By
Greg Favor
·
#723
·
|
|
Re: [RISC-V] [tech-config] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
I'm not sure I follow. I understand that the low-level and high-level discovery mechanisms are different, but is there a reason that the pointer to the low-level discovery method needs to be passed
|
I'm not sure I follow. I understand that the low-level and high-level discovery mechanisms are different, but is there a reason that the pointer to the low-level discovery method needs to be passed
|
By
Jonathan Behrens <behrensj@...>
·
#722
·
|
|
Re: [RISC-V] [tech-chairs] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
I think we can extend meaning of that CSR register (for future) by allowing write of some 'keyed/secret' value into it.
Keeping it 'clean address' is IMO better for now.
|
I think we can extend meaning of that CSR register (for future) by allowing write of some 'keyed/secret' value into it.
Keeping it 'clean address' is IMO better for now.
|
By
Robert Chyla <Robert.Chyla@...>
·
#721
·
|
|
Re: [RISC-V] [tech-chairs] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
Note that in an earlier discussion with Greg, I had proposed all-ones as the escape, as a single-byte message can not be valid.
|
Note that in an earlier discussion with Greg, I had proposed all-ones as the escape, as a single-byte message can not be valid.
|
By
Philipp Tomsich <philipp.tomsich@...>
·
#720
·
|
|
Re: Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
Good point. As far as having two extra bits for the future, that future situation may need just one or two bits, or may need many bits.
This point - of requiring an aligned pointer or not - should be
|
Good point. As far as having two extra bits for the future, that future situation may need just one or two bits, or may need many bits.
This point - of requiring an aligned pointer or not - should be
|
By
Greg Favor
·
#719
·
|
