sorear changed the topic of #riscv to: RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv | Matrix: #riscv:catircservices.org
pecastro has quit [Ping timeout: 260 seconds]
jn has quit [Ping timeout: 255 seconds]
jn has joined #riscv
jn has joined #riscv
jn has quit [Changing host]
EchelonX has quit [Quit: Leaving]
psydroid has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
Trifton has quit [Remote host closed the connection]
Trifton has joined #riscv
heat has quit [Ping timeout: 255 seconds]
wingsorc has quit [Ping timeout: 245 seconds]
mwette has quit [Quit: ERC 5.4 (IRC client for GNU Emacs 28.2)]
vagrantc has quit [Quit: leaving]
edr has quit [Quit: Leaving]
jacklsw has joined #riscv
davidlt has joined #riscv
BootLayer has joined #riscv
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #riscv
dlan has quit [Ping timeout: 255 seconds]
dlan has joined #riscv
junaid_ has joined #riscv
shamoe has quit [Quit: Connection closed for inactivity]
crabbedhaloablut has joined #riscv
billchenchina has joined #riscv
justyb11 has quit [Ping timeout: 272 seconds]
Jackneill has joined #riscv
junaid_ has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 240 seconds]
jacklsw has quit [Ping timeout: 255 seconds]
psydroid has joined #riscv
billchenchina has quit [Remote host closed the connection]
paddymahoney has quit [Remote host closed the connection]
paddymahoney has joined #riscv
pecastro has joined #riscv
awita has joined #riscv
awita has quit [Remote host closed the connection]
junaid_ has joined #riscv
davidlt has joined #riscv
junaid_ has quit [Remote host closed the connection]
davidlt has quit [Remote host closed the connection]
davidlt has joined #riscv
shamoe has joined #riscv
Andre_Z has joined #riscv
aredridel4 has joined #riscv
aredridel has quit [Ping timeout: 255 seconds]
aredridel4 is now known as aredridel
wingsorc has joined #riscv
Noisytoot has quit [Ping timeout: 260 seconds]
BootLayer has quit [Quit: Leaving]
jacklsw has joined #riscv
Noisytoot has joined #riscv
KombuchaKip has quit [Ping timeout: 255 seconds]
Noisytoot has quit [Excess Flood]
Maylay has quit [Read error: Connection reset by peer]
Maylay has joined #riscv
BootLayer has joined #riscv
Noisytoot has joined #riscv
heat has joined #riscv
<courmisch> is there a pseudo-instruction to synthesize a floating point value?
<courmisch> in principles, if you know the 32-bit/64-bit presentation, you can use li then transfer to f-reg, but manually encoding a float is as tedious as it gets
Andre_Z has quit [Quit: Leaving.]
jOSUser has joined #riscv
<jOSUser> what is the best risc board
<courmisch> it depends
<jOSUser> for gamin
<jOSUser> g
<courmisch> it depends on the kind of gaming
<jOSUser> just simple
<courmisch> that's pretty vague
<jOSUser> For a TOP SECRET buisness. I am making a console for gaming running on vulkan
<courmisch> anything with working VK drivers then?
<heat> you're probably screwed "for gaming"
jOSUser has quit [Remote host closed the connection]
<heat> anything short of apple ARM64 SoCs does not have great x86 compat/performance
jOSUser has joined #riscv
jOSUser has quit [Remote host closed the connection]
jOSUser has joined #riscv
<jOSUser> do you think it is possoble
<jOSUser> do you think it is possible
<heat> do you mean risc or riscv?
<jOSUser> i don't know tehe difrence
<heat> RISC is a type of ISA (architecture), riscv is a RISC architecture
<heat> ARM is also a RISC architecture, but it's not RISCV
<jOSUser> ok
Noisytoot has quit [Excess Flood]
<jOSUser> thanks
<la_mettrie> in another words, RISC refers to architectures with (supposedly) reduced instruction set, RISC-V is one of them
<jOSUser> is risc-v or arm better?
Noisytoot has joined #riscv
jacklsw has quit [Ping timeout: 240 seconds]
<heat> ARM is a lot more mature, with more mature hardware and is literally everywhere (including your phone)
<heat> if you want to make a RISC gaming thing, ARM is your best bet probably
<heat> it has been done before
Leopold has quit [Remote host closed the connection]
<mps> heat: is the ARM 'true' RISC (I'm asking because I'm not sure)
<heat> no
<heat> neither is riscv honestly
<mps> yes, I think so also
<heat> 'pure' RISC falls apart as soon as you need performance
<mps> but good enough is that ARM and riscv are not x86
Noisytoot has quit [Ping timeout: 248 seconds]
<mps> first CPU I used seriously was 6502, which is not risc but not much "far away" of risc
<mps> s/used/worked/
<jOSUser> check out milkv duo it is a good cheap risc-v board
<heat> the differences between modern RISC and modern CISC aren't really many
Leopold has joined #riscv
<heat> it's largely the same. x86 just has some weirder legacy stuff (like the BCD instructions)
<muurkha> heat: why isn't RISC-V "true RISC"?
Noisytoot has joined #riscv
<mps> also I noticed in last decade some convergence
<mps> but I think x86 is still at opposite side
<jOSUser> check out milk v milkv.io
<heat> muurkha, because you have a lot of instructions (through extensions etc) that are not a pure load/store thing with an ALU attached
<muurkha> heat: hmm, so the core RV32G and RV64G are, but there are extensions that aren't?
<muurkha> or are you thinking about A or something?
<jOSUser> can you give me thoughts on milkv milkv.io
<muurkha> jOSUser: I like milk with tea
<jOSUser> milkv not milk with tea
<mps> jOSUser: I would by milkv if it is not soooo much money
<mps> s/by/buy/
<mps> for now I mostly use qemu-user on powerful x86_64
<heat> muurkha, i'm not entirely sure about the core G stuff. but the bitmanip extensions, crypto are all obviously not RISC
<mps> and sometimes on apple silicon
Noisytoot has quit [Excess Flood]
Noisytoot has joined #riscv
<heat> i'm pretty sure 90s RISC purists would have a stroke over an instruction for CRC32 calculation (i don't think riscv has this yet? but arm64 and x86 do) or counting the 1's in a word
<heat> and all the funny SIMD instructions...
dzaima[m] has joined #riscv
<dzaima[m]> here's a whole bunch for AES and SHA: https://github.com/riscv/riscv-crypto/tree/main/doc/scalar/insns; and then there are some vector crypto instructions too
<dzaima[m]> CRC32 is in a funky space where IIRC on x86 or arm a manual SIMD implementation is competitive with the built-in instruction for it
<heat> i'm not sure about SIMD, but it was like 8x faster than a SIMD-less lookup table last time I benched it
<muurkha> heat: it sounds like you think what's to be reduced in RISC is the set of instructions
<muurkha> but after 40 years the consensus has been that it's not reducing the set of instructions that matters, but reducing what each instruction does
<heat> muurkha, no
<muurkha> no microcoded instructions, variable-length instructions, instructions that overwrite multiple input registers, etc.
<muurkha> that is, it's a set of reduced instructions, not a reduced set of instructions
KombuchaKip has joined #riscv
<heat> x86 does not have many of those instructions
<muurkha> if you won't listen to me, maybe you'll listen to John Mashey: https://yarchive.net/comp/risc_definition.html
<heat> sha512sum0 is not RISC
<muurkha> sha512sum0 (X(rd) = ror64(X(rs1), 28) ^ ror64(X(rs1), 34) ^ ror64(X(rs1), 39)) fits very comfortably into Mashey's RISC category
<dzaima[m]> https://github.com/riscv/riscv-crypto/blob/main/doc/vector-allrounds/insns/vaesd128.adoc appears to be a single instruction that does a 10-iteration loop where each iteration operates over 128-bit states, and does that multiple times depending on vtype configuration (up to 8 on a VLEN=128 impl)
<muurkha> I mean it's just a three-way XOR
<muurkha> dzaima[m]: yeah, that's
<muurkha> dzaima[m]: yeah, that clearly isn't RISCy :)
<heat> and, to be clear, i don't find RISC to be anything. this whole debate is silly because 'RISC' or 'CISC' are meaningless. when push comes to shove, and you need performance, you'll find it by breaking those pure design guidelines
jOSUser has quit [Quit: Leaving]
<heat> as seen in many of those instructions
<muurkha> heat: John Mashey comprehensively disagrees with you in that thread
<heat> good for john mashey
<muurkha> though perhaps things have changed since 01995
<dzaima[m]> the LMUL>1 stuff in RVV in general hits the "instructions that overwrite multiple input registers", reading up to 25 vector registers and writing up to 8 in one instruction
<muurkha> dzaima[m]: agreed!
<dh`> does the "v" in that stand for "vax"?
<muurkha> I didn't realize the crypto extensions had that kind of thing either
<muurkha> *too
<muurkha> dh`: haha
<dh`> as I've probably said before a transmeta-style vax core wrapped around a riscv would be a fun silly project
<muurkha> yeah!
<heat> ew :(
<muurkha> dh`: NetBSD VAX support just got a lot better btw
<muurkha> new GCC fixed most of the VAX backend bugs
<heat> i mean, if you do it well enough, a RISC backend == a CISC backend
<heat> as seen in amd zen
<muurkha> heat: John Mashey comprehensively disagrees with you in that thread, which I see you still haven't read
<heat> good for john mashey
<heat> i don't know what else to tell you?
<heat> how can this last statement be disproven given it literally happened IRL, a few years ago?
<muurkha> it did not literally happen IRL
<heat> AFAIK zen took huge huge chunks out of K12 such that it got a lot of new instructions and features required for the ARM64 ISA
<heat> every new instruction they made up was just an arm64 ripoff
<dh`> muurkha: good to hear
<muurkha> heat: irrelevant
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #riscv
<courmisch> dzaima[m]: Leaving aside the tricky cases with mixed width, LMUL is really just a way to reduce the number of vector registers in exchange for making them larger. It does not make instructions touch multiple register in that understanding
stolen has joined #riscv
EchelonX has joined #riscv
BootLayer has quit [Quit: Leaving]
<dzaima[m]> courmisch: right, but it still does end up touching multiple registers, and it's possible to afterwards to back to a lower LMUL and read the individual parts of them
davidlt has quit [Ping timeout: 245 seconds]
<courmisch> dzaima[m]: What characterise RISC is that there is only one destination operand register, and it's always coded as a 5-bit value at the same point in the 32-bit opcode.
<courmisch> RVV instructions are no exception to that rule. If they introduce an exception, it's actually something else: the destination operand is sometimes also a source operand (e.g. in FMA and in reductions)
<muurkha> that is a definition of RISC that excludes MIPS, SPARC, Alpha, ARM, the IBM 801, and, with the C extension, RISC-V
<muurkha> so possibly it wasn't what you intended to say
<courmisch> muurkha: I mean on the single destination register argument
<courmisch> (which indeed is not respected by ARM, with 32-bit LDM or 64-bit LDP)
<muurkha> yeah, I think it's reasonable to say that ARM's LDM instruction and (to a smaller extent) autoincrement addressing modes are not RISC
<muurkha> they're departures from RISC, and they've been responsible for a lot of the difficulty ARM has had in improving performance over the years
<courmisch> hmm, isn't the A32 condition code the worst bit there?
prabhakarlad has joined #riscv
<muurkha> I don't have any idea
<courmisch> well, neither the condition code nor LDM made it into A64, figures[3~
<muurkha> yup
<muurkha> incidentally, the Pulp implementation of RISC-V also adds autoincrement, because for a lot of code it doubles performance on an in-order implementations
<courmisch> you mean post-index?
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<muurkha> yeah, either pre- or post- or both
TMM_ has joined #riscv
<muurkha> I think Pulp only adds post--
<muurkha> though maybe macro-op fusion would be an alternative?
<muurkha> has anyone done an in-order RISC-V with macro-op fusion actually?'
<courmisch> I'm not sure if post-index is all that useful. On a typical function it saves just one instruction in the prologue and another one in the epilogue
<courmisch> to shift the stack pointer
<courmisch> maybe compilers have gotten better
Jackneill has quit [Remote host closed the connection]
<muurkha> oh, the case where it's useful is things like for (i = 0; i < n; i++) { int r = 0; for (j = 0; j < m; j++) r += a[i+j] * k[j]; } a[i] = r; }
<muurkha> the inner loop reads a new sample from the input and multiply-accumulates it with a weight from the kernel
<muurkha> you can strength-reduce that to pointer arithmetic but it makes a big difference if you have autoincrement instead
<muurkha> and unroll it, sometimes
<muurkha> but inner loops like that are common across SDR, ANNs, solving linear systems, 3-D rendering, etc.
<muurkha> image processing, audio processing, CFD, endless etc. the kind of stuff you'd buy a Cray or use the V extension for :)
<muurkha> uh, s/ instead/ in order to do that/
<muurkha> disclaimer, though: my experience with this stuff is pretty spotty, so I might be getting something important wrong
<muurkha> oh and obviously s/} a/ a/
<muurkha> most recently I've been appreciating auto-increment in ARM for things like bytecode interpreter dispatch
heat has quit [Read error: Connection reset by peer]
heat_ has joined #riscv
<muurkha> also it's useful for things like memcpy, in the absence of things like DMA controllers you can press into service, LDM/STM, or the V extension
jfsimon1981_c has joined #riscv
<jfsimon1981_c> Good evening
jfsimon1981_c is now known as jfsimon
<muurkha> bonne nuit
<jfsimon> Do you know why there's no li instruction in the isa, load immediate is i understand, a pseudo instruction doing lui and (addi ?)
<jfsimon> Bonsoir Muurkha
<muurkha> a 32-bit immediate field doesn't fit inside a 32-bit instruction format with any bits left over for the opcode
<jfsimon> i see, i don't get into which instructions the pseudo instruction li is translated to
<muurkha> lui and addi, as you said, or just addi for small constants
<jfsimon> it's a combination of lui and which one ? ok
<jfsimon> lui/addi.
<jfsimon> Thank you
<muurkha> sure
<muurkha> I forget what gas does for constants bigger than 32 bits
<muurkha> I mean you can use auipc;lw to get them from an ARM-like constant pool but I don't remember if gas does that for you automatically
<jfsimon> What's gas sry
<muurkha> the GNU assembler, sorry
<muurkha> the one the LLVM assembler emulates
<mps> muurkha: :)
<muurkha> :)
<jfsimon> ok
<mps> you made me to smile
<mps> good joke
<mps> and true
<muurkha> the best jokes are all true
<mps> yes, right. here we have saying "in every joke there is a little of joke" (so most is truth)
Kedleston has quit [Ping timeout: 240 seconds]
<muurkha> Serbia?
<mps> hm, how do you know?
<muurkha> "Stanić" sounds Serbian, so I thought it was a reasonable guess
<mps> yes, but how many people in the world know that is sounds Serbian, I wonder
<muurkha> I mean obviously it would be an incorrect guess for, say, Krste Asanovic
<muurkha> not sure. unfortunately the most famous -ić name is "Milosević" :(
<mps> one Asanović family are my neighbors and one was in my class in school
<mps> but not Krste, or I don't remember :)
Jackneill has joined #riscv
<mps> Krste could be Serbian or Croatian origin
ntwk has joined #riscv
<mps> I thought most famous is Nikola Tesla
<jfsimon> muurkha it does 4 ins: lui, addi, slli, addi, on compiler i use
<jfsimon> it is GAS indeed
Jackneill has quit [Ping timeout: 252 seconds]
stolen has quit [Quit: Connection closed for inactivity]
notgull has quit [Ping timeout: 260 seconds]
notgull has joined #riscv
crabbedhaloablut has quit []
psydroid has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
<jfsimon> Do you know manufacturer for risc-v cores, i seem have difficulties find them
<jfsimon> i see esp32
EchelonX has quit [Quit: Leaving]
vagrantc has joined #riscv