--
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/CAAVo%2BPmhXr_94XDKEc87%2B1Jsg-8Qo%3Dvd2CTFvB0C8-ShknxyCA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/em7d1804ed-5eb3-4948-97d2-61d5970df39b%40desktop-gfmadk4.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@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/CAAVo%2BPmhXr_94XDKEc87%2B1Jsg-8Qo%3Dvd2CTFvB0C8-ShknxyCA%40mail.gmail.com.
--
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+unsubscribe@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/em7d1804ed-5eb3-4948-97d2-61d5970df39b%40desktop-gfmadk4.
On Thu, Feb 15, 2018 at 11:36:31AM -0800, Jose Renau wrote:
> After misa.c is being cleared, if any instruction is miss aligned fetched
> it also raises an illegal instruction exception. The xEPC would fall in
> that class
That was one of the possible solution I proposed in october. See previous
mail in this thread (Message-ID: <20180215185716.GE19634@clifford.at>) for
- If PC is not 32-bit aligned; just continue executing, consuming 32b
instructions that are 16-bit aligned (since the CPU is already
capable of doing this to support C).
--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/CAJ9VFiF%3DbM7YWPOrzb1dmxFLPTw6s526Et02dCgrNDmG6GvuVg%40mail.gmail.com.
--
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+unsubscribe@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/CA%2B%2B6G0DX1c_gF%2BjDCgYPPeOuvamsM4unYSjM4rTpEHxzaY7Ytw%40mail.gmail.com.
On Tue, Feb 20, 2018 at 11:57 AM, Andrew Waterman <and...@sifive.com> wrote:
> This also seems like the cleanest solution to me: any attempt to execute an
> instruction with a misaligned PC raises a misaligned-instruction exception.
> This is easier to explain and simpler to verify than the other proposed
> alternatives. I withdraw my objection about increased cost from a few
> months ago, as it really only is a couple gates, and implementations that
> are pinching pennies can simply hard-wire misa.C.
It seems quite inconsistent to me that we would have two possibilities
for misaligned instruction exceptions:
1. After a JAL or JALR; mepc points to the JAL or JALR
2. After a write to MISA; mepc points *one after* the MISA write
Unless you meant that the trap would be taken with mepc pointing *to*
the MISA write?
This also doesn't address what happens to the *EPC registers if bit 1
of any of them is nonzero.
My preferences, ranked:
1. csrw misa raises a misalignment (or illegal) exception if any of
pc[1], mepc[1], sepc[1], bsepc[1], or uepc[1] is 1
2. csrw misa is a no-op if any of the above are 1
[rih] This makes no sense, on a CPU without C-extensions you want a mandatory C-extension instruction?
Also are you suggesting that all 48bit instructions must be followed by a C.NOP? That would effectively turn these into 64bit instructions. Then why not just use 64bit instructions?
What’s the advantage of 48bit instructions over 64bit instructions? Code density .. therefore if a system supports 48bit instructions, then that implies that instructions end up on 16bit boundaries. With similar issues as for the C-extensions.
Any effort to somehow avoid that seems odd.
Anyways, just my 2 cents…
Richard
For maximal consistency, any time IALIGN is 32, the hardware should
be required to act the same as an implementation that doesn't support
IALIGN = 16 at all. The only exception to this rule should be the
possibility of changing misa to cause IALIGN to be 16. Hence, any
time IALIGN is 32, the hardware should be required to treat bit 1 of
each of the *epc CSRs as hardwired to 0. As a consequence, it should
under no circumstance be possible for an *RET instruction to cause an
instruction-address-misaligned trap.
[...]
This is one valid implementation under the proposed specification.
--
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+unsubscribe@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/ef5f979f-8de1-4e3e-a20b-f8670b39bf07%40groups.riscv.org.
Note that there is a difference between having an "and" gate on a bit, and clearing the bit (the difference being that if the feature is disabled, then re-enabled, the old value reappears).
--
Regards,
- John Hauser
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/6740b050-3097-4af9-b010-194c45e138a5%40groups.riscv.org.
--
Regards,
- John Hauser
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/7297b9ab-e32b-4fd0-9e97-681e3e09b663%40groups.riscv.org.
On Fri, Mar 16, 2018 at 11:54 PM John Hauser <jhause...@gmail.com> wrote:> I’m not trying to be opaque here. I’m saying that our proposal revises
> this part of the spec to remove that guarantee.
Hold on, Andrew, you said more than that. You wrote:
> In any case, it was already implementation-defined which bits of mepc
> were writable.Me:
> Now that just can't be correct. The spec previously said:
>
> On implementations that do not support instruction-set extensions
> with 16-bit instruction alignment, the two low bits (mepc[1:0]) are
> always zero.Trying to give you the benefit of the doubt, I suppose you meant that,
for _some_ of the bits of mepc, it was already implementation-defined
that they might be writable. And now you've simply expanded that set
of implementation-defined bits. Is that what you meant?
Despite this detour, I remain convinced it's a mistake to allow bit 1
of the *epc CSRs to be nonzero when IALIGN = 32. Whatever convenience
this is supposed to provide, it's overwhelmed by the need to allow for
the possibility that the *RET instructions could cause an instruction
address misaligned trap.xRET doesn’t trap under the new proposal. As discussed earlier in this thread, that’s a very bad idea. The trap is raised on the subsequent instruction’s fetch, i.e., after the instruction has retired.
A program with a change to MISA.C that would leave the PC misaligned (from the 32-bit point of view) is indicative of malformed, dysfunctional code, and it's in M-mode no less (yikes!), if I understand correctly.Such code, being broken, should cause an orderly "machine check" exception or whatever you want to call it.
--
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+unsubscribe@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/463f49ea-816c-4b8f-9b37-7819efdb3ee5%40groups.riscv.org.
After further private discussions with Andrew Waterman and Krste Asanovic, the three of us have agreed to back a different way to handle changes to IALIGN. Andrew recently committed an update to the privileged spec; the diffs can be seen here: https://github.com/riscv/riscv-isa-manual/commit/0472bcdd166f45712492829a250e228bb45fa5e7
In summary: There are no longer any new instruction-address-misaligned traps. Only jumps/branches can cause such a trap, as originally. If a CSR instruction attempts to write to misa in such a way that IALIGN would change from 16 to 32, yet the following instruction isn't 32-bit- aligned, then the write to misa is suppressed entirely. misa is thus unchanged and IALIGN remains 16. (This is analogous to how writes to satp are ignored when they would result in an unsupported MODE setting.) When IALIGN = 32, the bottom two bits of each *epc register always appear as zeros. If an implementation supports both ALIGN = 16 and ALIGN = 32 (determined by misa), then bit 1 of each *epc register is writable, but, when IALIGN = 32, the bit is masked on reads so as to appear to be zero. Thus *epc bit 1 is updated on writes but is hidden on reads until IALIGN is 16 again. These choices were made to provide behavior that is both sufficient and maximally consistent across different implementations, with the least demands on hardware. Regards, - John Hauser
Hi folks,
I also have a problem with the proposal that the alignment of instruction N+1 will reach backwards in time and conditionally affect how instruction N behaves, if N is a particular CSR write. That's a little bizarre, at least in wording. Yeah, I know the endbyte address of instr. N will tell you what you need to know, since the CSR write isn't a control transfer. I guess you could re-state it as a constraint on the alignment of endbyte+1 and it wouldn't sound as wacky, and wouldn't imply that I-fetch needs to do anything at all with respect to instr N+1 itself.
--
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/f89ae9b8-b947-1dee-5fc3-5c49b034c055%40tesla.com.
Hi, On Sat, Mar 24, 2018 at 10:04:33PM -0500, Dan Hopper wrote:[..] This does mean the old value will magically re-appear if IALIGN is later changed back to 16-bits. This is not problematic behavior.
In my opinion it _is_ problematic. If the value of *epc after setting misa.C is not predictable from the state observalbe before setting misa.C then it becomes much harder to verify that an implementation is implementing setting of misa.C correctly, especially if you want to do it formally from a symbolic starting state.
I also have a problem with the proposal that the alignment of instruction N+1 will reach backwards in time and conditionally affect how instruction N behaves, [...]
As Alex Elsayed correctly pointed out, currecly IALIGN can only be changed using non-branching instructions that are 32 bit wide. So the next instruction is not aligned to 32 bits if and only if the current instruction is not aligned to 32 bits. So this is not an issue imo. regards, - clifford
Em 25-03-2018 00:04, Dan Hopper escreveu:
Hi folks,
I guess I have two problems with the current proposed changes. I agree with Clifford that *epc[1] should not be modifiable when IALIGN=32-bits. If *epc[1] is hard-wired to zero on a IALIGN=32-only CPU, then a more capable CPU in IALIGN=32 mode should have *exactly* the same read/write behavior for that register (or any other similar arch state). This is no different than not being able to modify bits 63:32 of r1-31 of a 64-bit core running in 32-bit mode. This does mean the old value will magically re-appear if IALIGN is later changed back to 16-bits. This is not problematic behavior.
From a software point of view, what matters is not the value of epc[1], it's the value of epc as a whole. The proposed rules are consistent from that point of view: (1) if a value is written to xEPC while IALIGN=32, the same value will still be in xEPC when IALIGN is changed to 16; (2) if a value is written to xEPC while IALIGN=16, then IALIGN is changed to 32 and back to 16, the same value will still be in xEPC.
Having an old value for epc[1] appear when the core is switched to IALIGN=16, even when software (or an interrupt, or a trap) had changed the EPC to point elsewhere, is asking for hard-to-debug bugs.
I also have a problem with the proposal that the alignment of instruction N+1 will reach backwards in time and conditionally affect how instruction N behaves, if N is a particular CSR write. That's a little bizarre, at least in wording. Yeah, I know the endbyte address of instr. N will tell you what you need to know, since the CSR write isn't a control transfer. I guess you could re-state it as a constraint on the alignment of endbyte+1 and it wouldn't sound as wacky, and wouldn't imply that I-fetch needs to do anything at all with respect to instr N+1 itself.
Since IALIGN can only be 16 or 32, and CSR writes are always 32-bit instructions (at least with the standard C extension), the alignment of instruction N+1 and instruction N will always be the same when N is a CSR write. IMHO, there should be a footnote mentioning that.
There's precedent for the address of instruction N+1 affecting the behavior of instruction N. In particular, JAL/JALR stores the address of instruction N+1 on a register. This also means that hardware already has a means of passing the address of instruction N+1 to the units which will execute the instruction, which explains why the cost of doing so won't be too high.
Conceptually, that CSR write alters the behavior of the whole core; you could think of it as stopping the core, exchanging a piece of it, and then resuming. On that model what's the value of pc while the core is stopped? The address of instruction N+1. It makes sense if you think of it as "switching the core is invalid if pc is not aligned; if it's invalid, do nothing".
On Sun, Mar 25, 2018 at 07:55:57PM -0500, Dan Hopper wrote:
> I don't see why it's a burden to require software to initialize
> 64-bit-only processor state when entering 64-bit mode. Or to initialize
> C-mode state when entering C-mode.
The issue here is _not_ burden to software. The issue is formal verification.
Persistent state that is invisible (or very hard to observe) is hard to
formally verify.