Consider changing the bit-order in a byte from right-to-left to left-to-right

[gintominto5329]

RISCV should changing the bit-order in a byte ,to left-to-right ,from right-to-left . Multi-byte order is already Little-endian ,but completely opposite for single-byte ,due to history

Example

-------------------------------------------
|  Value  |   Current     |   Proposal    |
-------------------------------------------
|     1   |   0000 0001   |   1000 0000   |
|    15   |   0000 1111   |   1111 0000   |
|   128   |   1000 0000   |   0000 0001   |
|   254   |   1111 1110   |   0111 1111   |
-------------------------------------------

History

• The latter was decided to resemble Big-endian ,which was designed to resemble the decimal/hindu-indic number-system
• Later Little-endian was found to be more suitable/natural for computing operations ,and allowing great flexibility through simple casting (to different sizes)

Why ?

• This would simplify the programming for the platform ,by merging the single-byte and multi-byte order ,instead of diversion due to historical reasons
• This would solve the only issue of Little-endian ,which is intuitivity ,while analyzing/manipulating raw-memory (although tooling can create artificial views ,but its has very-bad experience)
• right-to-left is indeed sensible for decimal number-system ,because its actually read by humans ,but memory is completely hidden/abstracted from the programmer ,hence switching to a side fully is the correct approach ,instead of both-legs-in-separate-boats
• This is crucial ,because otherwise we leave a place for improvement ,possibly digging own eventual grave

Isn't it a Breaking Change ?

Not necessarily ,because byte swapping (on load/store ? or as opcodes ?) is already under-consideration ,for Big-endian ,so why not make it definitive(complete inversion ,instead of per-byte/partial)

Its too-late now ?

so RISCV is outdated ,before even releasing fully ? Bound to be replaced ,too soon .

Related

• http://groups.google.com/a/groups.riscv.org/g/isa-dev/c/9tg4gGg8w-c/m/ADy-5lrHAgAJ

[Wren6991]

This is not a programmer-visible detail of any RISC-V machine. If you want to draw out your bitfield diagrams with the LSB on the left, or maybe even number the bits starting with 0 at the MSB like in an IBM manual, then you're free to do that.

I don't think RISC-V even stipulates that memory stores bytes with a binary representation; it just requires that register values survive a round-trip through memory, and states the correspondence between byte address and numerical significance (i.e. the endianness). You can think of memory as being base-256 rather than base-2, and then any confusion about bit order goes away.

[aswaterman]

Right, if memory is byte-addressed, this is a presentational detail that is not visible to software. So if you prefer to think about it that way, that's fine, it's compatible with RISC-V.

As a separate matter, I think most people find the current presentation more intuitive, in large part because Arabic numerals in English are written with the MSD on the left.

[gintominto5329]

This is not a programmer-visible detail of any RISC-V machine.

AND

if memory is byte-addressed, this is a presentational detail that is not visible to software.

What about bit-shift(and other bit-wise) operations of programming languages ,aren't they exposing a big-endian order ,even on little-edian computers ?

Note : the ISO-C standard does not define the order ,hence processor-registers must be exposing it ,although shifting is fully regulated (as << for mul. ,and >> for div.) .

[gintominto5329]

I think most people find the current presentation more intuitive

How can inter-mixing be more intuitive ,than consistency ;its simply stockholm-syndrome

because Arabic numerals in English are written with the MSD on the left.

I acknowledge it in my post ,that it resembles decimal-number-system ,but by that logic ,shouldn't the endianness be Big ,instead of Little for multi-byte and Big for single-byte

[gintominto5329]

@aswaterman please reply ,

and also if RISCV cannot be changed now ,what are the available options to present the order as fully little-endian ,in a programming lang. like c ,other than software emulation (which would be too expensive)

[gfavor]

Ratified arch extensions (including the base RV32 and RV64 ISAs) cannot be changed. RISC-V natively is a little-endian architecture and is expected to remain so (although it does provide support for big-endian data accesses).

Past that, as @Wren6991 and @aswaterman noted in earlier posts, your issue is a presentational detail that is transparaent to software and ISA semantics (and hence not an architecture matter). Hence, as far as who to take this issue up with, I'm not sure.

[gintominto5329]

thanks for your actually-useful reply .

RISC-V natively is a little-endian

this is what im stating ,that why settle for "partial little-endian" ,instead of full support ,for both single-byte(bits of a byte) as well as multiple bytes (as already supported)

Ratified arch extensions (including the base RV32 and RV64 ISAs) cannot be changed

so how are necessary but breaking fixes get delivered ?

thanks