Support for mstatus MBE, SBE

[MuhammadHammad001]

Hi
I am currently writing the test for little and big endianess in the virtual memory verification.
I was trying to write the mstatush.SBE to enable big endianess for loads/stores but I am unable to do so.

mem[X,0x80000A98] -> 0xA073
mem[X,0x80000A9A] -> 0x3102
[643] [M]: 0x80000A98 (0x3102A073) csrrs zero, 0x310, t0
CSR 0x310 -> 0x00000000
CSR 0x310 <- 0x00000000 (input: 0x00000010)

I went through the sail code to figure out what is wrong and I saw the following comment here:

  /* We don't currently support changing MBE and SBE. */
  if xlen == 64 then {
    Mk_Mstatus([m.bits with 37 .. 36 = 0b00])
  } else m
}

Is there any plan to add the support for this or am I missing something?

[Timmmm]

No plans but you're welcome to add support if you like. Do you know of actual users of this feature? I mean does any hardware actually exist that implements it?

[jordancarlin]

The OpenHWGroup CVW core implements support for switching endian modes using MBE/SBE. Would be a great feature to get into the Sail model eventually, but I don't think it's been that high on anyone's priority list.

[Timmmm]

Has anyone actually taped it out with support for big endian though? Kind of feels like CVW is trying to support every feature of RISC-V regardless of whether anyone wants it (which is fine), and I would be mildly surprised if anyone really wants big endian! I guess someone asked for it though; the spec says it was added to support legacy code.

Anyway feel free to try. It might not be too invasive; you probably just need to modify mem_read_priv_meta and mem_write_value_priv_meta to swap the bytes (unless Typ is Execute).

It may interact awkwardly with #49 - maybe have a skim of Alasdair's PR there before doing anything.

[jordancarlin]

You're not wrong that CVW is trying to support most RISC-V features in at least one of its configurations.

I might look at adding endian support down the road, but probably won't get around to it for a while so if you're interested feel free @MuhammadHammad001.

[MuhammadHammad001]

@Timmmm @jordancarlin Sure, I can work on this

[allenjbaum]

Big Endian is there for a reason: there are other architectures that work that way, and this greatly reduces porting effort for SW. This is important for the Japanese market, I believe, and probably networking markets as well. Having said that: I am unaware of implementations that allow this (either as a static -always big Endian - or a dynamic setting.

…

On Tue, Dec 3, 2024 at 4:58 AM Tim Hutt ***@***.***> wrote: Has anyone actually taped it out with support for big endian though? Kind of feels like CVW is trying to support every feature of RISC-V regardless of whether anyone wants it (which is fine), and I would be mildly surprised if anyone really wants big endian! I guess someone asked for it though; the spec says it was added to support legacy code. Anyway feel free to try. It might not be too invasive; you probably just need to modify mem_read_priv_meta and mem_write_value_priv_meta to swap the bytes (unless Typ is Execute). It may interact awkwardly with #49 <#49> - maybe have a skim of Alasdair's PR there before doing anything. — Reply to this email directly, view it on GitHub <#632 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJQ7NJAZVRO3H5NS2ML2DWTGVAVCNFSM6AAAAABS4MNBIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJUGQ4TEOBWGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jordancarlin]

@MuhammadHammad001 Is this something you ended up working on/are planning to work on? If not I might take a stab at it soon after all.

[MuhammadHammad001]

Hi Jordan, I actually completed this work a while ago but could not find the time to send a PR. I will send it today.

…

On Wed, Feb 12, 2025 at 6:57 AM Jordan Carlin ***@***.***> wrote: @MuhammadHammad001 <https://github.com/MuhammadHammad001> Is this something you ended up working on/are planning to work on? If not I might take a stab at it soon after all. — Reply to this email directly, view it on GitHub <#632 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBJGGUHFC63WK4THSVCF4NL2PKTADAVCNFSM6AAAAABS4MNBIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJSGQ3DQNJTGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jordancarlin]

I actually completed this work a while ago but could not find the time to
send a PR. I will send it today.

Fantastic!