toluene has quit [Read error: Connection reset by peer]
toluene has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
jacklsw has joined #riscv
dramforever__ has joined #riscv
dramforever_ has quit [Ping timeout: 268 seconds]
dramforever__ has quit [Remote host closed the connection]
handsome_feng has joined #riscv
motherfsck has quit [Ping timeout: 268 seconds]
<muurkha>
so I read Andrew Waterman's dissertation last night when I couldn't sleep, which was pretty awesome
<muurkha>
it covers most of the same material as the current RISC-V unprivileged spec, but it's better written and more enjoyable
<muurkha>
unfortunately it's out of date and not licensed in such a way as to be updatable
<muurkha>
it goes into more detail on a few things, like compressing prologues/epilogues with millicode
<muurkha>
one of the differences I noticed, in particular because I was thinking about the ridiculously bad byte-swapping code I got out of GCC, was that at the time RISC-V was specified to support unaligned access, like i386
<muurkha>
and now the RISC-V spec fobs that decision off on the specification of the "EEI"
<muurkha>
so I'm wondering where the riscv64-linux-gnu EEI is specified and whether it guarantees unaligned fetch support
<muurkha>
because if I were a compiler emitting byte-swapping code starting from return 0 | (u32)p[0] << 24 | (u32)p[1] << 16 | (u32)p[2] << 8 | (u32)p[3]
<muurkha>
I feel like it would be Extremely Bad to emit code that on some machines would cause unaligned access exceptions that kill your program
<muurkha>
but only slightly bad to emit code that runs ridiculously slowly if your big-endian fetch is unaligned and your RISC-V implementation has chosen to support unaligned fetches through a trap to S-mode
<muurkha>
maybe that's too Pollyannaish and that would be totally unacceptable for other uses, but generally when I have big-endian things I want to fetch they are already properly aligned
motherfsck has joined #riscv
aerkiaga has quit [Remote host closed the connection]
djdelorie has quit [Quit: Leaving]
djdelorie has joined #riscv
<jrtc27>
unaligned fault emulation is only marginally less bad
<jrtc27>
it works but you really do not want to use it if you can at all avoid it
<jrtc27>
you either want unaligned accesses to be guaranteed fast or guaranteed to fault IMO
<jrtc27>
anything in between just creates a mess
<muurkha>
jrtc27: that sounds reasonable, but I don't think anything in RISC-V is guaranteed fast, is it?
<jrtc27>
nope
<jrtc27>
trap and emulate is a valid implementation of any instruction
<muurkha>
and 16kHz is a valid clock speed
<jrtc27>
as far as userspace is concerned
<jrtc27>
well, fast relative to aligned accesses
<jrtc27>
ie not trap and emulate
<jrtc27>
(slightly slower due to cache line shenanigans is fine)
<muurkha>
also on Linux it's common for any random memory access to take 10,000,000 nanoseconds because spinning rust
<muurkha>
it would be great to have *aligned* accesses to be guaranteed fast, but that means you can't swap
<muurkha>
even swapping from an SSD might take over 1000 ns
<jrtc27>
that's different, and hopefully amortised
<muurkha>
I wrote a recursive search program in C once that used longjmp() once it found a solution
<muurkha>
it did a lot of searches, not just one
<muurkha>
a friend reported that it ran 10 times slower on his Mac than it did on my Linux box, even though the Mac was newer
<muurkha>
turned out MacOS had implemented longjmp() in some way that required a system call (maybe because they implemented it as siglongjmp()? memory is vague)
<muurkha>
ideally it's different and amortized, but a lot of my most annoying experiences with Linux have been when it turned out not to be different or amortized :(
<muurkha>
and even if it's amortized it only takes one 10,000,000 nanosecond delay in your mouse tracking to cause user-perceptible jankiness
dramforever has joined #riscv
dramforever_ has joined #riscv
dramforever has quit [Ping timeout: 276 seconds]
jack_lsw has joined #riscv
jacklsw has quit [Ping timeout: 244 seconds]
dramforever__ has joined #riscv
dramforever_ has quit [Ping timeout: 264 seconds]
dramforever_ has joined #riscv
dramforever__ has quit [Read error: Connection reset by peer]
dramforever__ has joined #riscv
dramforever_ has quit [Read error: Connection reset by peer]
<dh`>
longjmp is traditionally siglongjmp on bsd
BootLayer has joined #riscv
dramforever_ has joined #riscv
dramforever__ has quit [Remote host closed the connection]
<la_mettrie>
every visionfive device with own driver code (listed on the pastebin) requires those codes to work? https://pastebin.com/raw/nmgUnnys
dramforever__ has joined #riscv
dramforever_ has quit [Read error: Connection reset by peer]
foton has quit [Quit: %Bye, bye, ...%]
foton has joined #riscv
dor has joined #riscv
dramforever_ has joined #riscv
dramforever__ has quit [Read error: Connection reset by peer]
bauruine has joined #riscv
jmdaemon has joined #riscv
<muurkha>
dh`: that would explain it
jack_lsw has quit [Quit: Back to the real world]
<Esmil>
la_mettrie: you'd want the clock, reset and pinctrl driver to most things, but they're already upstream. the patches to the serial driver is not needed for a serial console. the audio clocks are not needed if you don't want to use the audio peripherals and the rest of the drivers are also for specific things
<Esmil>
the stuff in drivers/dma/dw-axi-dmac-starfive/ was never used and i deleted it from the latest visionfive branch
<la_mettrie>
audio clocks are needed to get some sound out for the first place?
<Esmil>
yes, the pwmdac fx. needs the audio clocks
<Esmil>
la_mettrie: you can look at arch/riscv/boot/dts/starfive/jh7100.dtsi and see which peripherals has a reference to &audclk
<Esmil>
cool, will do. i also forgot the fixes tag when first sending this which probably didn't help
loggervicky has joined #riscv
<palmer>
Ya, I generally look for "fix" in the subject but when there's no fixes tag and I'm slammed for time I frequently don't look closer
dramforever__ has joined #riscv
___nick___ has quit [Ping timeout: 276 seconds]
dramforever_ has quit [Read error: Connection reset by peer]
dramforever__ has quit [Remote host closed the connection]
dramforever__ has joined #riscv
loggervicky has quit [Quit: loggervicky]
dramforever_ has joined #riscv
dramforever__ has quit [Ping timeout: 268 seconds]
crabbedhaloablut has joined #riscv
<drewfustini>
I'm using a soc that is using PLIC with "sifive,plic-1.0.0". I'm a little confused as to why the interrupts on the PLIC chip show 'edge' in type file under /sys/kernel/irq/ Shouldn't that be level, not edge?
<palmer>
drewfustini: there's a patch on the list
<drewfustini>
related to Renesas?
<drewfustini>
do mean that it may just be that the /sys/kernel/irq/n/type is mislabelled?
<palmer>
it used to be that the PLIC didn't really define edge vs level, but that probably wasn't a good idea
<palmer>
so if you're seeing either without those patches it's wrong, as it's just undefined
<drewfustini>
Thanks, yes, I see one of the patches adds:
<drewfustini>
.irq_set_type= plic_irq_set_type
jobol has quit [Quit: Leaving]
<drewfustini>
I had never thought about it too much before but I'm on an SoC that implements the SiFive PLIC and no PLIC interrupts ever trigger a handler so I've been looking more closely at how it works on existing SoCs
<drewfustini>
Good to know that the interrupt type in /sys/kernel/irq doesn't mean anything currently
Starfoxxes has joined #riscv
jmdaemon has joined #riscv
dramforever__ has joined #riscv
dramforever_ has quit [Read error: Connection reset by peer]