deflated8837 has quit [Remote host closed the connection]
deflated8837 has joined #riscv
pecastro has quit [Ping timeout: 246 seconds]
iooi has quit [Read error: Connection reset by peer]
iooi has joined #riscv
brazuca has joined #riscv
jacklsw has joined #riscv
Tenkawa has quit [Quit: Was I really ever here?]
catern- is now known as catern
rurtty has quit [Quit: Leaving]
<geist>
question: is it fairly safe to say that any 64bit riscv implementation will a) fully support unaligned accesses without needing to trap to machine mode and b) will do it fairly efficiently?
<geist>
it's my understanding that the architecture allows for unaligned, as long as software/firmware emulates it, but that would be sub optimal for say a memcpy/memset routine that assumes unaligned accesses are efficient
<geist>
i think it may be safe to say that rv32 may be an embedded core, which possibly doesn't do unaligned efficiently, so it may make sense to have a more unaligned friendly routine there
<muurkha>
I don't think you'd ever want to do unaligned access in memcpy, would you?
<muurkha>
oh, I guess you would
<geist>
right, yeah if the source/dest are not similarly aigned, if the cpu natively supports it reasonably well, it's generally assumed that you just align to the destination and then let it deal with it
<geist>
vs a more complicated read/shift/or/etc logic which is probably slower
<muurkha>
right, that's what finally percolated through my skull
<muurkha>
just not soon enough to prevent my first IRC line from coming out :)
<geist>
haha no worries
<geist>
so i can see having two implementations of each, but was wondering if it's probably 'safe' to just assume rv32 is probably embedded and probably wants to not do unaligned, but anything rv64 can probably deal with it natively better
<geist>
actually upon further reading, looks like at least the sifive cores up through u74 dont do misaligned accesses in hardware either, so really the assumption that rv64 == unaligned accesses is not true
freakazoid332 has joined #riscv
frkzoid has quit [Ping timeout: 252 seconds]
billchenchina- has joined #riscv
JanC has quit [Remote host closed the connection]
JanC has joined #riscv
<geist>
and yeah can confirm that on sifive hardware at least opensbi is indeed silently trapping and emulating. took me a while to grok the opensbi unaligned trap handler code, since of course there's not any comments at all
billchenchina- has quit [Remote host closed the connection]
<geist>
interesting, uses mstatus.mprv to access data in the lower modes. dunno precisely what happens when traps happen there, etc
<geist>
but presumably it reflects those down to supervisor mode, i guess
<geist>
but that's annoying: the unaligned accesse are silently handled without any ability for the supervisor mode OS to even know it's happening. i get the idea, but seems like there should be a way to request SBI not do it, or at least get some sort of counter of how many times it's happening. maybe the latter is via the performance counter stuff
lagash has joined #riscv
billchenchina has joined #riscv
<geist>
benchmarking wise of course trapping an unaligned access are many orders of magnitude slower than not
pabs3 has joined #riscv
brazuca has quit [Quit: Client closed]
billchenchina- has joined #riscv
foton has quit [Ping timeout: 255 seconds]
billchenchina has quit [Ping timeout: 240 seconds]
<Molorius>
I have a design question. I am also working on misaligned access - for an M-mode build. This cpu can read/write/execute on one address space but only if 4-byte aligned, but has a different address space that goes to the same RAM that can read/write (not execute) on any alignment. For easier code it would be better to add a configurable offset (default 0) to traps_misaligned.c, but for portability it would probably be be
<Molorius>
tter to create 4-byte handling functions. Which way would be better for the kernel?