--
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.