Contribute ARC feedback on Zilsd #45
Conversation
zilsd.adoc
Outdated
|
|
||
| NOTE: This definition permits LD and SD instructions giving rise to exactly one | ||
| memory access, regardless of alignment. | ||
| It also permits decomposing instructions with 4-byte-aligned effective |
There was a problem hiding this comment.
This seems redundante with the normative definition.
There was a problem hiding this comment.
I can get behind deleting this NOTE if you think it's unhelpfully redundant.
There was a problem hiding this comment.
I have tried to update the note to be less repetitive and also clarify that the accesses are atomic. Maybe this helps with @tovine's comment.
aswaterman
force-pushed
the
arc-patches
branch
from
929c0b9 to
eb5d9db
Compare
| === Exception Handling | ||
|
|
||
| For the purposes of RVWMO and exception handling, LD and SD instructions are | ||
| considered to be misaligned loads and stores, with one additional constraint: |
There was a problem hiding this comment.
I think this text is a bit confusing - this only applies in case the access is not 8-byte aligned, right? Right now it can read as if LD and SD are always considered to be misaligned accesses.
There was a problem hiding this comment.
It's deliberate, though. 8-byte alignment offers no special benefit for these instructions. (Of course, the uarch is likely to optimize them, but that's not the point here.) The only architecturally visible question is whether they're 4-byte aligned.
There was a problem hiding this comment.
So what you're saying is that implementations are free to consider them misaligned (and trap) regardless of actual alignment?
I'd very much hope that compilers will (or at least can) be instructed to make them 8-byte aligned, otherwise they bring almost none of the originally intended benefits over a pair of normal LW/SW.
One such intended benefit is to allow low-end MCU-class cores to better utilize the bus if they have one that is wider than the native machine width, but this is only possible if the wider access is then aligned, and those cores don't typically have the same kind of macro-op fusion capabilities as larger ones.
There was a problem hiding this comment.
This is just a rhetorical tactic to simplify the description of the semantics, not a means to recommend what implementations should do. Obviously it's a good thing for implementations to implement these ops as wide bus xacts when possible. That doesn't run afoul of anything in the spec.
zilsd.adoc
Outdated
|
|
||
| NOTE: This definition permits LD and SD instructions giving rise to exactly one | ||
| memory access, regardless of alignment. | ||
| It also permits decomposing instructions with 4-byte-aligned effective |
There was a problem hiding this comment.
I have tried to update the note to be less repetitive and also clarify that the accesses are atomic. Maybe this helps with @tovine's comment.
Co-authored-by: Christian Herber <christian.herber@oss.nxp.com> Signed-off-by: Andrew Waterman <aswaterman@gmail.com>
|
@christian-herber-nxp I'm OK with this tweaked version if you are. |
I think you have only accepted one of my three suggestions (I do not know of a way to make a suggestion for multiple lines at once. I guess you wanted to accept the suggestion, but I will wait for you on that. |
Co-authored-by: Christian Herber <christian.herber@oss.nxp.com> Signed-off-by: Andrew Waterman <aswaterman@gmail.com>
Co-authored-by: Christian Herber <christian.herber@oss.nxp.com> Signed-off-by: Andrew Waterman <aswaterman@gmail.com>
The ARC had no further feedback on the semantics, but we wanted to tighten up the exception-related language, rephrasing it in terms of existing terminology. We also thought the "software view" section was mostly superfluous and could be summarized in a non-normative note.