--
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/CAF4tt%3DCtyw7%2B8vbgVj3rkod7tOnPt-huj8v4WdKg%3DuhPY%3DtHxw%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/CAPweEDztKU_EXgNJTDYQcOEFWiat%2BM3zSYUNE%3Dw%3DQVO5Nf1-Cg%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+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/5B1B2FE1.8030809%40gmail.com.
-- Jacob
--
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/5B1B2FE1.8030809%40gmail.com.
So 4 possible levels of support:
- none
- swap instructions
- BigEndian load/store mode
- BigEndian load/store instructions
I doubt little vs big-endian is an issue for adoption. We see a lot of requests from China, admittedly less from Japan. But then Japan is considered conservative.
Instead of declaring new opcodes for big-endian access, wouldn’t declaring the memory space/region big-endian be sufficient? That could be endoded in the MMU record, the PMA and/or the PMP records.
This requires no changes to the CPU pipeline. The CPU then just always works in little-endian mode. There’s no need for new opcodes or additional byte-swap instructions. The data is just loaded/stored in little/big endian format.
Cheers,
Richard
--
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/CAF4tt%3DCw%3DgFgMckmV6yuJV8u2kzEoXL-YksfrS9N4MFSL%2BmqSQ%40mail.gmail.com.
For example, a TCP header could be a simple struct with
attribute((big_endian)) applied. GCC would then know to access
multi-byte fields in that struct using big-endian opcodes.
as regards something like this, I've never seen a convincing argument re performance that we need to tag data with endian attributes.And I'm mentioned as one of the guys who pushed such a bad idea in the now-withdrawn https://standards.ieee.org/findstds/standard/1596.5-1993.html, so in my dark past, I even believed in this kind of thing. Oops.
We did a test a few years back and as of gcc 6, it's pretty smart about turning certain sequences of byte access into single word load/store.As regards most code that thinks it needs to be endian-aware, this particular note is useful:I've found that Rob's note is correct far more often than not.
On 9/06/2018, at 9:54 PM, Andrew Waterman <and...@sifive.com> wrote:
On Sat, Jun 9, 2018 at 2:45 AM, Luke Kenneth Casson Leighton
<lk...@lkcl.net> wrote:
On Sat, Jun 9, 2018 at 10:30 AM, Andrew Waterman <and...@sifive.com> wrote:
My point is that there will be such a hit, no matter which approach is
taken. There's effectively no room in RVC to encode new big-endian
loads and stores. There's effectively no room in RVI to encode new
big-endian loads and stores with 12-bit offsets. So, you're left
either wider instructions or two-instruction sequences.
there is another option: the conflict-resolution scheme. it was
discussed a couple months back, and is "effectively" as if 32-bit (or
other sized) opcodes had been extended (by some hidden bits that are
set with a CSR).
using that scheme the actual meaning of existing opcodes may be
"redirected" to a completely different execution engine, *without*
impact on the pipeline speed or introducing extra latency [1], and,
crucially, allowing the processor to be switched back to "standard"
meanings very very quickly.
I agree that extending the opcode by a few bits will not materially
exacerbate decode latency.
But this issue isn't anywhere near important enough to merit such an
elaborate strategy. Either Sam's or my/Tommy's solution is
sufficient.
In general do not worship at the altar of legacy support !
On Sat, Jun 9, 2018 at 8:53 AM, ron minnich <rmin...@gmail.com> wrote:
> e.g., if you literally have this:
> char *a;
> uint32_t b;
> b = a[0] | a[1]<<8 | a[2] << 16 | a[3] << 24;
In real world code it is a lot more complicated than this.
That code effectively *is* an endianness tag, just obfuscated a bit to
fit in standard C.
2. Ldx, GRevI combination doesn't work for signed operands on an RV if X<xlen.
To support that you need to LD, GrevI, SRA. Combining GrevI with a sign extension option could work- but only by limiting the general case to the specific cases that matter ( so, it would remove the "General" part of the mnemonic)
So 4 possible levels of support:- none- swap instructions- BigEndian load/store mode- BigEndian load/store instructions
LOAD OPCODE: lb, lbu, lh, lhu, lw, lwu, ld, ldu
STORE OPCODE: sb, sh, sw, sd, sq
MISC-MEM OPCODE: fence, fence.i, lq
--
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/CAG5EYeXdNJuUDSW9OQGKHnANHDtZYzymNFjicdQQ5N5c4HFPuQ%40mail.gmail.com.
Not correct. For the signed extended sub-word case you only need two instructions. Eg. 32-bit:BSWAP rd, rs1SRA rd, rs1, 32
Even adding a single instruction like BSWAP cost something, and certainly in an FPGA softcore, havingit will affect the critical path and thus penalize _everything_ else. As
I repeat nearly every time set B isdiscussed: PLEASE QUANTIFY! I challenge everyone who cares about this to SHOW measurements from REALcode that a the feature they propose will reduce the instruction count by more than, say, 3%.
Hi Allen,One data point: RISC-V was originally bi-endian, but overwhelmingly the western world have settled on little and it greatly simplified the standard to drop it. I don't think adding native BigEndian makes sense but adding support for various swaps does make a ton of sense.TommyOn Jun 8, 2018, at 14:02 , Allen Baum <allen...@esperantotech.com> wrote:i've heard more than once that in Japan (and perhaps China), the overwhelming majority of microcontrollers and embedded processors are Big-Endian. This is, I believe, inhibiting the support of RiscV in those geopgraphies (not eliminating it, but certainly slowing it down ).The only support that I've heard of for big-endian is the currently defunct BitManipulation WG, and even there the support was for swapping bytes after they've been loaded and before they are store.a. Is that adequate?b. If not, do we expect anyone who wants native BigEndian support to develop their own custom extension?c. if not - have there been any discussions for a standard BigEndian discussion?
--
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/CAF4tt%3DCtyw7%2B8vbgVj3rkod7tOnPt-huj8v4WdKg%3DuhPY%3DtHxw%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/38C75B31-C0D0-4090-8B58-9F3F535F9522%40esperantotech.com.
On Sat, Jun 9, 2018 at 2:39 AM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:
> There is no room in the 32-bit opcode space to put big-endian LOAD/STORE,
> but an extension could easily add these as 48-bit or 64-bit opcodes.
the consequences of that are that it would make big-endian a "second
rate citizen"... although at this point it's almost too late.
https://en.wikipedia.org/wiki/Endianness#Bi-endianness seems to me to
imply that the equivalent of CSRs may have been used historically to
set endian-ness.
l.
Luke Kenneth Casson Leighton wrote:
On Sat, Jun 9, 2018 at 2:39 AM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:
There is no room in the 32-bit opcode space to put big-endian LOAD/STORE,
but an extension could easily add these as 48-bit or 64-bit opcodes.
the consequences of that are that it would make big-endian a "second
rate citizen"... although at this point it's almost too late.
https://en.wikipedia.org/wiki/Endianness#Bi-endianness seems to me to
imply that the equivalent of CSRs may have been used historically to
set endian-ness.
I do not see a serious problem here, since that proverbial ship has arguably already sailed: RISC-V program text is little-endian, and changing *that* would make a huge mess. Further, the use of additional big-endian memory access opcodes would make RISC-V truly bi-endian, with the big-endian/little-endian distinction being made at runtime and encoded into the program text, rather than being an implicit parameter. I argue that this is a better fit, since it would allow/require the expected byte order for data to be explicitly stated in the program.
Lastly, (and this ties back to the extensible assembler database I proposed earlier) standardizing big-endian memory access as 48-bit or 64-bit opcodes does not preclude implementations from "aliasing" those long-form standard opcodes into the 32-bit opcode space as non-standard encodings of standard instructions.
-- Jacob
I will add my stupid (probably, towards certainly) solution here.
It would be possible to construct 48bit instructions for BE operations LD/ST, that are a combination of:
1. 16 bit prefix indicating a 48bit BE instruction,
2. 32 bit for a normal LE LD/ST instruction.
The implementation could be simple enough, with minimal changes to instruction decoders.
The first part would set the load/store unit into big endian mode for the following transfer.
l.