|
Jonathan Behrens wrote: Couldn't you just change the wording to be "disabled" when referring to
having misa.H=0 and leave "unimplemented" to mean having misa.H hardwired
to 0? It seems obvious, right? :^) A small problem is that most of the extensions are actually defined in the unprivileged ISA document, which speaks a few times of extensions being "implemented". It's hard to change the word there to "enabled", given that the unprivileged ISA doesn't know about misa or any other way to enable/disable extensions. - John Hauser
|
|
|
My response to Allen's post and my use of "unimplemented" in quotes was referring to the H extension spec's statement that "When misa[7] is clear, the hart behaves as though this extension were not implemented." The key point is that the "disabled" values for the CSR bits/fields in question must match their "unimplemented" values.
Greg
On Mon, Jun 22, 2020 at 6:16 PM Jonathan Behrens < behrensj@...> wrote: Couldn't you just change the wording to be "disabled" when referring to having misa.H=0 and leave "unimplemented" to mean having misa.H hardwired to 0?
Jonathan
While I would have to go through all the bits/fields affected by the H extension to double-check, the main issue are bits/fields that were previously reserved (and hardwired to zero). So there isn't the general issue of what the "unimplemented" read values should be. Similarly, the "unimplemented" behavior for CSR's added by the H extension is straightforward.
Greg And we should be careful to define the corner cases, e.g. the values that are in the registers when the features are enabled: the values they last held, or undefined, or.... something else.
On Mon, Jun 22, 2020 at 4:08 PM Greg Favor < gfavor@...> wrote: Thanks. This is the interpretation we expected to be correct.
For the sake of some future readers of the spec that may not apply the broadest meaning of "behaves" when reading "behaves as
though this extension were not implemented", it may be worth a few words to note that "behaves" also means that new CSR bits/fields defined by the extension must have simple read/write behavior the same as when the extension is not implemented (i.e. not just that these bits have the same effect or lack of effect as if the extension is not implemented).
Greg On Mon, Jun 22, 2020 at 2:58 PM John Hauser < jh.riscv@...> wrote: Greg Favor wrote:
> The Hypervisor extension adds bits to some of the existing M-mode CSR's.
> When this extension is not implemented, these bits are hardwired to zero.
> When the extension _is_ implemented these bits become either read/write or
> (in a few cases) hardwired to one.
>
> On the one hand the hypervisor spec says that when misa.H=0 (i.e. the
> extension is "disabled"), "the hart behaves as though this extension were
> not implemented". But where these various added M-mode CSR bits are
> described, they are defined to exist when "the hypervisor extension is
> implemented".
>
> The former statement implies that these new bits must appear to be
> hardwired to zero when misa.H=0, while the latter statement implies that
> these new bits appear to be read/write or hardwired to one irrespective of
> misa.H (although presumably they have no functional effects when misa.H=0).
>
> Which is the correct architectural intention?
The overriding statement in the document is this one:
When misa[7] (bit H) is clear, the hart behaves as though this
extension were not implemented, ....
I sympathize with the desire to enforce an intuitive view that, if
misa.H is writable and set to 0, the hypervisor extension really _is_
implemented, just disabled. However, I believe the statement above
is clear that when misa.H = 0, the hardware must act the same as when
the hypervisor extension is not implemented. If that statement didn't
override an intuitive interpretation of _implemented_ everywhere in the
chapter, then the statement would be null-and-void, and that can't be
right.
Allowing "implementation" to be configurable at run-time may be
non-intuitive, but I claim the hypervisor chapter is consistent with
similar other uses in the document. For example, concerning the FS
field in mstatus, the document says:
In systems that do not implement S-mode and do not have a
floating-point unit, the FS field is hardwired to zero.
What about when misa.F and misa.S are both writable and set to zero?
In that case I believe the specification requires that mstatus.FS
be read-only zero, the same as when the F extension and S mode are
not implemented. So what does the document really mean by "do not
implement S-mode" and "do not have a floating-point unit"?
If anything, I think the hypervisor chapter is being slightly more
careful to document the consequences of modifying misa.
- John Hauser
|
|
|
Jonathan Behrens <behrensj@...>
Couldn't you just change the wording to be "disabled" when referring to having misa.H=0 and leave "unimplemented" to mean having misa.H hardwired to 0?
Jonathan
While I would have to go through all the bits/fields affected by the H extension to double-check, the main issue are bits/fields that were previously reserved (and hardwired to zero). So there isn't the general issue of what the "unimplemented" read values should be. Similarly, the "unimplemented" behavior for CSR's added by the H extension is straightforward.
Greg And we should be careful to define the corner cases, e.g. the values that are in the registers when the features are enabled: the values they last held, or undefined, or.... something else.
On Mon, Jun 22, 2020 at 4:08 PM Greg Favor < gfavor@...> wrote: Thanks. This is the interpretation we expected to be correct.
For the sake of some future readers of the spec that may not apply the broadest meaning of "behaves" when reading "behaves as
though this extension were not implemented", it may be worth a few words to note that "behaves" also means that new CSR bits/fields defined by the extension must have simple read/write behavior the same as when the extension is not implemented (i.e. not just that these bits have the same effect or lack of effect as if the extension is not implemented).
Greg On Mon, Jun 22, 2020 at 2:58 PM John Hauser < jh.riscv@...> wrote: Greg Favor wrote:
> The Hypervisor extension adds bits to some of the existing M-mode CSR's.
> When this extension is not implemented, these bits are hardwired to zero.
> When the extension _is_ implemented these bits become either read/write or
> (in a few cases) hardwired to one.
>
> On the one hand the hypervisor spec says that when misa.H=0 (i.e. the
> extension is "disabled"), "the hart behaves as though this extension were
> not implemented". But where these various added M-mode CSR bits are
> described, they are defined to exist when "the hypervisor extension is
> implemented".
>
> The former statement implies that these new bits must appear to be
> hardwired to zero when misa.H=0, while the latter statement implies that
> these new bits appear to be read/write or hardwired to one irrespective of
> misa.H (although presumably they have no functional effects when misa.H=0).
>
> Which is the correct architectural intention?
The overriding statement in the document is this one:
When misa[7] (bit H) is clear, the hart behaves as though this
extension were not implemented, ....
I sympathize with the desire to enforce an intuitive view that, if
misa.H is writable and set to 0, the hypervisor extension really _is_
implemented, just disabled. However, I believe the statement above
is clear that when misa.H = 0, the hardware must act the same as when
the hypervisor extension is not implemented. If that statement didn't
override an intuitive interpretation of _implemented_ everywhere in the
chapter, then the statement would be null-and-void, and that can't be
right.
Allowing "implementation" to be configurable at run-time may be
non-intuitive, but I claim the hypervisor chapter is consistent with
similar other uses in the document. For example, concerning the FS
field in mstatus, the document says:
In systems that do not implement S-mode and do not have a
floating-point unit, the FS field is hardwired to zero.
What about when misa.F and misa.S are both writable and set to zero?
In that case I believe the specification requires that mstatus.FS
be read-only zero, the same as when the F extension and S mode are
not implemented. So what does the document really mean by "do not
implement S-mode" and "do not have a floating-point unit"?
If anything, I think the hypervisor chapter is being slightly more
careful to document the consequences of modifying misa.
- John Hauser
|
|
|
While I would have to go through all the bits/fields affected by the H extension to double-check, the main issue are bits/fields that were previously reserved (and hardwired to zero). So there isn't the general issue of what the "unimplemented" read values should be. Similarly, the "unimplemented" behavior for CSR's added by the H extension is straightforward.
Greg
And we should be careful to define the corner cases, e.g. the values that are in the registers when the features are enabled: the values they last held, or undefined, or.... something else.
On Mon, Jun 22, 2020 at 4:08 PM Greg Favor < gfavor@...> wrote: Thanks. This is the interpretation we expected to be correct.
For the sake of some future readers of the spec that may not apply the broadest meaning of "behaves" when reading "behaves as
though this extension were not implemented", it may be worth a few words to note that "behaves" also means that new CSR bits/fields defined by the extension must have simple read/write behavior the same as when the extension is not implemented (i.e. not just that these bits have the same effect or lack of effect as if the extension is not implemented).
Greg On Mon, Jun 22, 2020 at 2:58 PM John Hauser < jh.riscv@...> wrote: Greg Favor wrote:
> The Hypervisor extension adds bits to some of the existing M-mode CSR's.
> When this extension is not implemented, these bits are hardwired to zero.
> When the extension _is_ implemented these bits become either read/write or
> (in a few cases) hardwired to one.
>
> On the one hand the hypervisor spec says that when misa.H=0 (i.e. the
> extension is "disabled"), "the hart behaves as though this extension were
> not implemented". But where these various added M-mode CSR bits are
> described, they are defined to exist when "the hypervisor extension is
> implemented".
>
> The former statement implies that these new bits must appear to be
> hardwired to zero when misa.H=0, while the latter statement implies that
> these new bits appear to be read/write or hardwired to one irrespective of
> misa.H (although presumably they have no functional effects when misa.H=0).
>
> Which is the correct architectural intention?
The overriding statement in the document is this one:
When misa[7] (bit H) is clear, the hart behaves as though this
extension were not implemented, ....
I sympathize with the desire to enforce an intuitive view that, if
misa.H is writable and set to 0, the hypervisor extension really _is_
implemented, just disabled. However, I believe the statement above
is clear that when misa.H = 0, the hardware must act the same as when
the hypervisor extension is not implemented. If that statement didn't
override an intuitive interpretation of _implemented_ everywhere in the
chapter, then the statement would be null-and-void, and that can't be
right.
Allowing "implementation" to be configurable at run-time may be
non-intuitive, but I claim the hypervisor chapter is consistent with
similar other uses in the document. For example, concerning the FS
field in mstatus, the document says:
In systems that do not implement S-mode and do not have a
floating-point unit, the FS field is hardwired to zero.
What about when misa.F and misa.S are both writable and set to zero?
In that case I believe the specification requires that mstatus.FS
be read-only zero, the same as when the F extension and S mode are
not implemented. So what does the document really mean by "do not
implement S-mode" and "do not have a floating-point unit"?
If anything, I think the hypervisor chapter is being slightly more
careful to document the consequences of modifying misa.
- John Hauser
|
|
|
Allen Baum
And we should be careful to define the corner cases, e.g. the values that are in the registers when the features are enabled: the values they last held, or undefined, or.... something else.
On Mon, Jun 22, 2020 at 4:08 PM Greg Favor < gfavor@...> wrote: Thanks. This is the interpretation we expected to be correct.
For the sake of some future readers of the spec that may not apply the broadest meaning of "behaves" when reading "behaves as
though this extension were not implemented", it may be worth a few words to note that "behaves" also means that new CSR bits/fields defined by the extension must have simple read/write behavior the same as when the extension is not implemented (i.e. not just that these bits have the same effect or lack of effect as if the extension is not implemented).
Greg On Mon, Jun 22, 2020 at 2:58 PM John Hauser < jh.riscv@...> wrote: Greg Favor wrote:
> The Hypervisor extension adds bits to some of the existing M-mode CSR's.
> When this extension is not implemented, these bits are hardwired to zero.
> When the extension _is_ implemented these bits become either read/write or
> (in a few cases) hardwired to one.
>
> On the one hand the hypervisor spec says that when misa.H=0 (i.e. the
> extension is "disabled"), "the hart behaves as though this extension were
> not implemented". But where these various added M-mode CSR bits are
> described, they are defined to exist when "the hypervisor extension is
> implemented".
>
> The former statement implies that these new bits must appear to be
> hardwired to zero when misa.H=0, while the latter statement implies that
> these new bits appear to be read/write or hardwired to one irrespective of
> misa.H (although presumably they have no functional effects when misa.H=0).
>
> Which is the correct architectural intention?
The overriding statement in the document is this one:
When misa[7] (bit H) is clear, the hart behaves as though this
extension were not implemented, ....
I sympathize with the desire to enforce an intuitive view that, if
misa.H is writable and set to 0, the hypervisor extension really _is_
implemented, just disabled. However, I believe the statement above
is clear that when misa.H = 0, the hardware must act the same as when
the hypervisor extension is not implemented. If that statement didn't
override an intuitive interpretation of _implemented_ everywhere in the
chapter, then the statement would be null-and-void, and that can't be
right.
Allowing "implementation" to be configurable at run-time may be
non-intuitive, but I claim the hypervisor chapter is consistent with
similar other uses in the document. For example, concerning the FS
field in mstatus, the document says:
In systems that do not implement S-mode and do not have a
floating-point unit, the FS field is hardwired to zero.
What about when misa.F and misa.S are both writable and set to zero?
In that case I believe the specification requires that mstatus.FS
be read-only zero, the same as when the F extension and S mode are
not implemented. So what does the document really mean by "do not
implement S-mode" and "do not have a floating-point unit"?
If anything, I think the hypervisor chapter is being slightly more
careful to document the consequences of modifying misa.
- John Hauser
|
|
|
Thanks. This is the interpretation we expected to be correct.
For the sake of some future readers of the spec that may not apply the broadest meaning of "behaves" when reading "behaves as
though this extension were not implemented", it may be worth a few words to note that "behaves" also means that new CSR bits/fields defined by the extension must have simple read/write behavior the same as when the extension is not implemented (i.e. not just that these bits have the same effect or lack of effect as if the extension is not implemented).
Greg
On Mon, Jun 22, 2020 at 2:58 PM John Hauser < jh.riscv@...> wrote: Greg Favor wrote:
> The Hypervisor extension adds bits to some of the existing M-mode CSR's.
> When this extension is not implemented, these bits are hardwired to zero.
> When the extension _is_ implemented these bits become either read/write or
> (in a few cases) hardwired to one.
>
> On the one hand the hypervisor spec says that when misa.H=0 (i.e. the
> extension is "disabled"), "the hart behaves as though this extension were
> not implemented". But where these various added M-mode CSR bits are
> described, they are defined to exist when "the hypervisor extension is
> implemented".
>
> The former statement implies that these new bits must appear to be
> hardwired to zero when misa.H=0, while the latter statement implies that
> these new bits appear to be read/write or hardwired to one irrespective of
> misa.H (although presumably they have no functional effects when misa.H=0).
>
> Which is the correct architectural intention?
The overriding statement in the document is this one:
When misa[7] (bit H) is clear, the hart behaves as though this
extension were not implemented, ....
I sympathize with the desire to enforce an intuitive view that, if
misa.H is writable and set to 0, the hypervisor extension really _is_
implemented, just disabled. However, I believe the statement above
is clear that when misa.H = 0, the hardware must act the same as when
the hypervisor extension is not implemented. If that statement didn't
override an intuitive interpretation of _implemented_ everywhere in the
chapter, then the statement would be null-and-void, and that can't be
right.
Allowing "implementation" to be configurable at run-time may be
non-intuitive, but I claim the hypervisor chapter is consistent with
similar other uses in the document. For example, concerning the FS
field in mstatus, the document says:
In systems that do not implement S-mode and do not have a
floating-point unit, the FS field is hardwired to zero.
What about when misa.F and misa.S are both writable and set to zero?
In that case I believe the specification requires that mstatus.FS
be read-only zero, the same as when the F extension and S mode are
not implemented. So what does the document really mean by "do not
implement S-mode" and "do not have a floating-point unit"?
If anything, I think the hypervisor chapter is being slightly more
careful to document the consequences of modifying misa.
- John Hauser
|
|
|
Greg Favor wrote: The Hypervisor extension adds bits to some of the existing M-mode CSR's.
When this extension is not implemented, these bits are hardwired to zero.
When the extension _is_ implemented these bits become either read/write or
(in a few cases) hardwired to one.
On the one hand the hypervisor spec says that when misa.H=0 (i.e. the
extension is "disabled"), "the hart behaves as though this extension were
not implemented". But where these various added M-mode CSR bits are
described, they are defined to exist when "the hypervisor extension is
implemented".
The former statement implies that these new bits must appear to be
hardwired to zero when misa.H=0, while the latter statement implies that
these new bits appear to be read/write or hardwired to one irrespective of
misa.H (although presumably they have no functional effects when misa.H=0).
Which is the correct architectural intention? The overriding statement in the document is this one: When misa[7] (bit H) is clear, the hart behaves as though this extension were not implemented, .... I sympathize with the desire to enforce an intuitive view that, if misa.H is writable and set to 0, the hypervisor extension really _is_ implemented, just disabled. However, I believe the statement above is clear that when misa.H = 0, the hardware must act the same as when the hypervisor extension is not implemented. If that statement didn't override an intuitive interpretation of _implemented_ everywhere in the chapter, then the statement would be null-and-void, and that can't be right. Allowing "implementation" to be configurable at run-time may be non-intuitive, but I claim the hypervisor chapter is consistent with similar other uses in the document. For example, concerning the FS field in mstatus, the document says: In systems that do not implement S-mode and do not have a floating-point unit, the FS field is hardwired to zero. What about when misa.F and misa.S are both writable and set to zero? In that case I believe the specification requires that mstatus.FS be read-only zero, the same as when the F extension and S mode are not implemented. So what does the document really mean by "do not implement S-mode" and "do not have a floating-point unit"? If anything, I think the hypervisor chapter is being slightly more careful to document the consequences of modifying misa. - John Hauser
|
|
|
The Hypervisor extension adds bits to some of the existing M-mode CSR's. When this extension is not implemented, these bits are hardwired to zero. When the extension _is_ implemented these bits become either read/write or (in a few cases) hardwired to one.
On the one hand the hypervisor spec says that when misa.H=0 (i.e. the extension is "disabled"), "the hart behaves as though this extension were not implemented". But where these various added M-mode CSR bits are described, they are defined to exist when "the hypervisor extension is implemented".
The former statement implies that these new bits must appear to be hardwired to zero when misa.H=0, while the latter statement implies that these new bits appear to be read/write or hardwired to one irrespective of misa.H (although presumably they have no functional effects when misa.H=0).
Which is the correct architectural intention?
Greg
|
|
|
