<cousteau>
my experience is "pretty much everyone uses WhatsApp, until the Telegram nerds in the group chat decide to move it to Telegram"
<cousteau>
I'm always curious on how the RISC-V ISA could improve and will evolve, and if it has any weaknesses that could be easily identified and fixed
<cousteau>
for example, it's really missing the B extension, which I'm really looking forward to
<cousteau>
and... I saw someone complain about the lack of "add with carry" type of operations, which I understand can be useful for faster bigint arith implementations, but can't really be added to the ISA without breaking the overall design philosophy
motherfsck has joined #riscv
<cousteau>
I wonder if there are any studies of which instructions are used most often, and what's the 10% of the instructions that are used 90% of the time, and if it would make sense to focus on possible ways to optimize those
<cousteau>
or implement something like "advanced/trigonometric math functions" as an extension (would some machines benefit from that?)
X-Scale has joined #riscv
Esmil has quit [Ping timeout: 252 seconds]
aerkiaga has joined #riscv
Esmil has joined #riscv
cousteau has quit [Quit: ♫ I can't forget the day I shot that network down ♫]
cousteau has joined #riscv
cousteau has quit [Quit: ♫ I can't forget the day I shot that network down ♫]
<bjdooks>
that's been about for a month or two, not sure how good it will be
<muurkha>
it seems like this is still mostly aimed at digital stuff, but digital stuff in 180nm
<muurkha>
why would you want to use 180nm if you're doing digital?
<bjdooks>
yeah, so microcontroller arena
freakazoid332 has quit [Ping timeout: 255 seconds]
<muurkha>
180nm seems reasonable for analog stuff, but for whatever reason they seem to be focusing totally on digital
<muurkha>
if you're doing digital, wouldn't you be better off doing it with an FPGA fabbed in a ten-year-old process node like 32nm than something from literally the previous millennium?
<muurkha>
I mean, than an ASIC using a process from literally the previous millennium
motherfsck has quit [Ping timeout: 252 seconds]
motherfsck has joined #riscv
freakazoid332 has joined #riscv
frkzoid has quit [Ping timeout: 255 seconds]
Andre_H has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
<bjdooks>
hmm, did the vector state patches ever get into the kernel? if not, is there a fairly recent series to play with?
aerkiaga has quit [Ping timeout: 252 seconds]
aerkiaga has joined #riscv
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
rodrgz has joined #riscv
epony has quit [Ping timeout: 252 seconds]
epony has joined #riscv
Narrat has joined #riscv
prabhakarlad has joined #riscv
epony has quit [Remote host closed the connection]
epony has joined #riscv
pedja has joined #riscv
frkzoid has joined #riscv
freakazoid332 has quit [Ping timeout: 255 seconds]
freakazoid332 has joined #riscv
frkzoid has quit [Ping timeout: 255 seconds]
Guest605_ has quit [Changing host]
Guest605_ has joined #riscv
Guest605_ is now known as ln5
<palmer>
bjdooks: they're not yet merged but that was actually top of my TODO list right now, not sure what shape they're in though
<tusko>
Why is risc-v such a big deal? I mean this sincerely. Whatare the major selling points of an open architecture?
<muurkha>
well, there are really two questions there: what are the advantages of an open architecture? and what are the advantages of RISC-V?
<tusko>
Indeed. The best arguments I can think of for open architecture is to empower 'smaller', less well-funded entities to compete in hardware by removing issues own ownership and licensing from the IP (provided they create their own I suppose).
<tusko>
I'm not super well-versed on licensing wrt hardware.
<muurkha>
advantages of RISC-V do include being an open architeture, it's true
<muurkha>
but from my point of view the more appealing thing is that it's an extremely simple architecture to implement that nevertheless has reasonably high performance implementations — though there's not yet a RISC-V that delivers what people expect from a current cellphone or laptop, it's getting close
<muurkha>
and it's a supported target in GCC and LLVM, unlike the instruction set I invented last week
motherfsck has quit [Ping timeout: 252 seconds]
<muurkha>
I don't work at a hardware company (maybe someone who knows things can comment), but I think that quite possibly from hardware makers' point of view, a big part of the value proposition is that they don't have to pay the ARM tax on every chip
dor has quit [Remote host closed the connection]
<muurkha>
another possibility is that ARM licensing limits what extensions they can add to the instruction set
<muurkha>
and a big selling point for hardware vendors is that they don't have to rely on an overseas company like ARM or Intel for their CPU cores, which can be a big risk, as Huawei found out
jjido has joined #riscv
<bjdooks>
palmer: ok. I just applied the V10 set to my 5.17 wip kernel. Going to try it later in the week
<palmer>
cool, LMK if you run into any issues. I was aiming for something more recent, but I might just do a merge
<muurkha>
I think a big part of the appeal of RISC-V has nothing to do with it being open, though
motherfsck has joined #riscv
<bjdooks>
I like being paid
<muurkha>
it's an architecture designed around 02009-02015 with the benefit of hindsight on i386, amd64, SPARC, MIPS, Alpha, ARM (including Thumb and Thumb2), Cray, the CDC 6600, etc. and without any requirement for backward compatibility
<muurkha>
so it was able to avoid many of their blunders
prabhakarlad has quit [Quit: Client closed]
BootLayer has quit [Quit: Leaving]
<conchuod>
palmer: bjdooks: iirc I hit a couple build issues on the last revision of the vector patchset
<conchuod>
and iirc the feedback that was given to the version send in April or so never got applied
<dh`>
too bad the supervisor mode stuff is a blunder :-/
rodrgz has quit [Quit: WeeChat 3.7.1]
<muurkha>
some of it, I feel like the page table stuff is pretty nice, but I haven't actually tried using it
epony has quit [Ping timeout: 252 seconds]
<muurkha>
I don't know if you saw the other day, dh`, I was looking at the programming manual for this WCH chip
<muurkha>
which is RISC-V
<muurkha>
they implemented their own interrupt handling mechanism with a four-level hardware stack
loggervicky has quit [Ping timeout: 255 seconds]
epony has joined #riscv
zjason` has joined #riscv
<tusko>
02009-02015 is like an experimental ISA?
<dh`>
I think you mentioned that
zjason has quit [Ping timeout: 240 seconds]
<muurkha>
02009 is about the year the RISC-V project started
<dh`>
but the trap handling headroom is only the beginning of the things that, let's say, could have been done better
<muurkha>
oh?
<dh`>
not giving user and kernel separate address spaces is probably the biggest one, though to be fair that looked different before spectre
djdelorie has quit [Ping timeout: 250 seconds]
<muurkha>
Norm Hardy pointed out 25 years ago that this caused security bugs in Solaris
<dh`>
setting up the status register so it has to be possible to update it atomically (that is, there's both stuff you change on the fly and stuff that might change under you
<muurkha>
which status register?
aerkiaga has quit [Remote host closed the connection]
<dh`>
it should only cause security bugs if you do something stupid; mostly it's a stronger form of the SUM bit
<dh`>
mstatus/sstatus/(ustatus)
<muurkha>
oh
<dh`>
but also having separate address spaces for user and kernel makes a bunch of kernel and virtualization things easier
<muurkha>
empirically Norm observed that doing something stupid was easy when they share an address space though
<dh`>
at the cost of needing special instructions to access the other memory space
<dh`>
yes, that's why sharing the address space is not the best scheme
<dh`>
then there's the problem that a bunch of the control registers are mirrored in different places for different access levels, so any code you have to write has to know if it's m-mode or s-mode code
<dh`>
rather than having one register number that gets a different view based on privilege
<muurkha>
or have the m-mode code fake m-mode slowly for the benefit of the s-mode code, right?
<dh`>
yes, but you have to do that either way and it's all generally easier if there's only one location for the register
<dh`>
then they never managed to figure out how to make the user trap delegation work
<dh`>
which I think would have been easier if some of the above had been sorted
<dh`>
for simplicity if you're going to be running kernels in u-mode it is nice for u-mode to recursively look the same as s-mode
<dh`>
cuts down substantially on how much a hypervisor has to worry about
pedja has quit [Read error: Connection reset by peer]
pedja has joined #riscv
<dh`>
also, the scause register is sign-magnitude instead of two's complement so you can't use it to index a jump table of trap types without first branching on the sign bit
frkzoid has joined #riscv
djdelorie has joined #riscv
<dh`>
they appear to have thought that they ought to optimize for dispatching either interrupts or everything else, but making one table that points all the interrupt codes to the same place uses all of 64 bytes of memory and in most applications if you're going to do that at all you also want to dispatch on some of the exceptions as well
freakazoid332 has quit [Ping timeout: 255 seconds]
freakazoid332 has joined #riscv
<dh`>
and as we were discussing the other day it's reasonable to have separate entry points for u->s and s->s, or s/u->m and m->m (or u->u)
<dh`>
because for anything that isn't a very limited custom interrupt handler, or has an unusual kernel architecture, you are dumping to the stack and finding the stack is the first thing you have to do, and it's different in those cases
gianluca has quit [Remote host closed the connection]
frkazoid333 has joined #riscv
gianluca has joined #riscv
frkzoid has quit [Ping timeout: 255 seconds]
frkzoid has joined #riscv
<dh`>
oh, and also: the spec doesn't specify whether the access and dirty bits in page table entries are software- or hardware-managed, which mans that software has to be able to support both cases, which is a headache.
freakazoid332 has quit [Ping timeout: 255 seconds]
<dh`>
it is not effective that way and it would have been better to commit to software-managed if they didn't want to oblige implementations to do hardware-managed
ale96 has joined #riscv
frkazoid333 has quit [Ping timeout: 255 seconds]
<dh`>
anyway that's some of the issues
freakazoid332 has joined #riscv
frkzoid has quit [Ping timeout: 255 seconds]
frkzoid has joined #riscv
frkazoid333 has joined #riscv
freakazoid332 has quit [Ping timeout: 255 seconds]
frkzoid has quit [Ping timeout: 255 seconds]
frkazoid333 has quit [Ping timeout: 255 seconds]
gianluca has quit [Remote host closed the connection]
gianluca has joined #riscv
qwer has quit [Read error: Connection reset by peer]
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]
gianluca has quit [Quit: Leaving]
ale96 has quit [Ping timeout: 252 seconds]
jjido has joined #riscv
<muurkha>
dh`: agree that it would be nice for u-mode to look the same as s-mode
<muurkha>
I don't understand scause at all yet
<muurkha>
and agreed about the different stacks
<muurkha>
how could the access and dirty bits be software-managed if hardware handles the page faults?
<muurkha>
sorry if this is a dumb question
<muurkha>
I probably have some fundamental misunderstanding and should read the manual more carefully
<jrtc27>
one option: reading to/writing from/executing a page with the A bit clear, or writing to a page with the D bit clear, generates a page fault
<jrtc27>
another option: reading to/writing from/executing a page with the A bit clear results in the hardware setting the A bit, and writing to a page with the D bit clear results in the hardware setting the D bit
<jrtc27>
the former is software-managed, since software needs to then go and set the bits as appropriate and return
<jrtc27>
the latter is hardware-managed
<jrtc27>
in both cases the hardware is still doing the translation
<jrtc27>
it's non-trivial to do in hardware because of the atomicity requirements
<muurkha>
oh, I see! that should have been obvious. the atomicity requirements in a multi-hart system?
rneese has quit []
<dh`>
yeah
<dh`>
also it involves a read-modify-write cycle on the page table entry and that's potentially big deal
<dh`>
also it sucks anyway, because when the hardware updates those bits software has to scan the page tables to figure out which ones have been set
<dh`>
and that was one thing when we had 32M of ram and it's another thing entirely with 32G
<dh`>
whereas if you do it with a trap the fault handler has all the pieces it needs to move the page to the right page queue or whatever you're doing
rburkholder has quit [Quit: Leaving]
rburkholder has joined #riscv
<jrtc27>
A is particularly fun for I-caches
<jrtc27>
RISC-V doesn't let them be speculative
<jrtc27>
so you need to defer the atomic update until you go and execute the instruction
<jrtc27>
which may then fail because an earlier instruction in the pipeline, or something on another hart, went and modified the PTE
qwer has joined #riscv
<muurkha>
oh, ouch
jmdaemon has joined #riscv
<muurkha>
I'm not used to thinking about superscalar and speculative execution
bauruine has quit [Remote host closed the connection]
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]
epony has quit [Ping timeout: 252 seconds]
epony has joined #riscv
Narrat has quit [Quit: They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.]
<dh`>
also, setting the bits repeatedly on frequently-accessed pages creates a lot of unnecessary cache traffic, and while you can maybe avoid that doing so takes further work
<dh`>
so basically doing it in hardware kinda sucks for everyone except naive kernels on small systems
deus_ex has joined #riscv
bjoto has quit [Ping timeout: 246 seconds]
pedja has quit [Ping timeout: 252 seconds]
jjido has joined #riscv
<jrtc27>
who's setting the bits repeatedly?
<jrtc27>
they get set once and that's it
<jrtc27>
if someone goes and changes the page, including to clear the bits, then they need to sfence.vma
<jrtc27>
and kernels that want the traps can just go and clear read/write permission
<jrtc27>
(and set A/D when they set R/W)
<jrtc27>
in pseudocode it's `if (!pte.A) if (!cas(&pte, pte, pte | A) goto rewalk`
<jrtc27>
which I find funny because RISC-V doesn't give you CAS... except for PTE updates
elastic_dog has quit [Killed (platinum.libera.chat (Nickname regained by services))]
elastic_dog has joined #riscv
Noisytoot is now known as [
<muurkha>
haha
deus_ex has quit [Quit: Leaving]
aredridel has quit [Quit: Ping timeout (120 seconds)]
aredridel has joined #riscv
zjason` is now known as zjason
qwer has quit [Ping timeout: 252 seconds]
Andre_H has quit [Ping timeout: 248 seconds]
prabhakarlad has joined #riscv
qwer has joined #riscv
somlo_ is now known as somlo
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]