--
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/5CEC97CF-A405-46F0-A873-20A646265C14%40livius.net.
--
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/8e24ac6a0de04b79bef647ffbac6785c%40HQMAIL103.nvidia.com.
> On 30 Nov 2017, at 05:32, Jacob Bachmeyer <jcb6...@gmail.com> wrote:
>
>> sure, if there are any free bits in the current encoding, it would be great to reserve some for an extended EBREAK that has an immediate value (ARM Cortex-M uses 8 bits, but I guess 2-3 bits would probably be enough).
>>
>
> We can easily get 10 bits using the rs1 and rd fields, or XLEN bits by using rs1 to refer to an actual register holding a function code. The immediate field in SYSTEM/PRIV is listed as "funct12", so it seems to be intended as a 12-bit function code.
yes, for the future, if Andrew agrees, I welcome such a solution (the mscratch magic is not a solution, it is a workaround), but for now, as long as the specs do not mention it, I doubt it is a safe choice.
Liviu
--
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/183F2952-832B-405A-BF45-7D03570DD6D2%40livius.net.
--
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/e63d43c5-d489-3f12-cf7a-fb0043b5e7d9%40gmail.com.
> On 30 Nov 2017, at 17:30, Bruce Hoult <br...@hoult.org> wrote:
>
> Passing in a register is definitely the simplest and most future-proof. ... So, it's pretty clear for syscalls.
how do you suggest to handle multiple ABIs?
with multiple ECALLs it is easy, you assign one for each ABI, and which may have completely different syscall numbers, registers, etc, and all work in parallel.
> But what about debugger traps? If you're going to insert breakpoints by replacing user instructions (rather than using hardware breakpoint address registers) then you'd like to replace as few bytes of them and as few instructions as possible.
if you really need to replace multiple user instructions with long magic sequences simply because the ISA does not support multiple BRKs, probably you selected the wrong ISA.
> Ideally you'd want a 16 bit debugger trap instruction with a few bits of literal, so you could replace a single RVC instruction. Or if the instruction is a bigger one, replace it with a 16 bit debugger trap instruction and one or more 16 bit NOPs.
that's correct.
> PLUS .. where do you find a register to put the constant for the debugger? ... Hence the suggestion to use odd-valued magic numbers in mscratch for this communication. But that also needs several instructions .. and looks like m mode only.
yes. also ugly and limited.
for the existing embedded RISC-V devices, which are M-mode only, that would not be a problem, but future devices might also take the ARM path, which is promoting dual mode embedded devices, with lots of security improvements (see large Cortex-M devices, especially M8), and in this case the mscratch workaround cannot be used. :-(
regards,
Liviu
regards,
Liviu
> On 29 Nov 2017, at 02:47, Andrew Waterman <and...@sifive.com> wrote:
>
> I don’t support adding additional EBREAKs, as placing odd-valued magic numbers in mscratch seems sufficient. There is an additional DBI (debug binary interface) constraint on mscratch, that it must be initialized on boot and in normal operation only hold aligned pointers or 0. But that is vastly preferable to an ISA modification.
yes, this constraint of holding aligned pointers and the set of allowed magic numbers must be clearly documented, with the additional consequence that mscratch must be cleared at reset.
I foresee a small problem with using the mscratch for magic numbers, the need to place the code in an interrupt critical section, i.e. disable interrupts, swap mscratch, ebreak, restore mscratch, enable interrupts. probably no longer reasonable for an inline function.
otherwise we risk entering an interrupt while mscratch does not hold an aligned pointer.
things get pretty messy, only to compensate in software what could have been an EBREAK with at least a 2-4 bits immediate value field. :-(
regards,
Liviu
--
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/F20283A0-513E-4F79-A33D-5C917986EAD5%40livius.net.
--
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/B22768AE-8174-4DA0-A543-5BDAEE068B05%40livius.net.
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/CAMU%2BEkzjEM37znrDFiwvzD%2B8AUz2%3D7CbMeK7M%3Dag3aKXCfGfew%40mail.gmail.com.
| 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/183F2952-832B-405A-BF45-
| 7D03570DD6D2%40livius.net.
| --
| 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 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/
| CAMU%2BEkxbQ44BVHCW7w4_t-MKeRR5L%2Bha3Xo01X8EKC2ee2NFDg%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/23072.4133.717648.855227%40KAMacBookAir2012.local.
--
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/170D47D5-B373-4BB3-923E-689D88F54D94%40livius.net.
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/170D47D5-B373-4BB3-923E-689D88F54D94%40livius.net.
--
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%2BPmGQMx12V-6cE8tyMVncdkxNO%2BjqMUED0vL02Gh5nOFyw%40mail.gmail.com.
if it identifies the semihosting BREAK, it performs the semihosting call and continues execution.
--
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/5A233EDA.4080503%40gmail.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+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/22583E1E-FF5E-443B-9A2B-59F4622843EC%40livius.net.
--
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/11574788-7A19-4ED6-9E32-B2E51EE6E3D4%40livius.net.
I agree making a single starting parcel (16 bits) of all ones be
illegal is probably preferable, even if it constrains longer
instruction encodings, as this is the smallest unit of instruction
fetch. Speed of trapping is irrelevant, but it is useful to be able
to have the last 16 bits of some unprogrammed instruction memory be
illegal, when unprogrammed state is all 1s.
As you say, messing with rd field will reduce regularity. Requiring
bit 15 (low bit of rs1) be zero in legal instructions is similarly
problematic. Reserving nnn=111 for single-parcel illegal instructions
is probably the least impactful choice:
xnnnxxxxx1111111 80+16*nnn-bit instructions, nnn != 11x
x110xxxxx1111111 >= 176-bit instructions
r111rrrrr1111111 reserved (rrrrrr!=111111)
1111111111111111 illegal
This does create 63 unused single-parcel encodings, but with different
length decode than standard instructions, so probably worth avoiding
their use (except as enumerated illegals maybe).
> 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/23112.35150.12448.434738%40KAMacBookAir2012.local.
--
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%2B6G0CEUyixwfxLCCNaP%2B%2BySjqyy69h17GeVvrGd37wgENwVA%40mail.gmail.com.
As several have pointed out, semihosting should really be handled via
ECALL. Multiplexing multiple ABIs onto ECALL just requires managing
the syscall number namespace (instead of managing the ECALL immediate
number namespace). The missing piece is that the current RISC-V debug
standard does not enter the debugger on an ECALL, and requiring that a
handler with EBREAK is installed at mtvec is apparently too intrusive
in some situations.
At the 7th workshop debug group meeting, we discussed these issues and
proposed adding a general "undelegate" feature to allow the debugger
to intervene on any exception (or interrupt). Andes mentioned they
already had this facility. I'd recommend the debug task group work on
adding this facility as an addition to the spec.
I agree making a single starting parcel (16 bits) of all ones be
illegal is probably preferable, even if it constrains longer
instruction encodings, as this is the smallest unit of instruction
fetch.