aburgess has quit [Remote host closed the connection]
aburgess has joined #riscv
heat has quit [Ping timeout: 258 seconds]
dinklebink has joined #riscv
GenTooMan has quit [Remote host closed the connection]
GenTooMan has joined #riscv
jacklsw has joined #riscv
handsome_feng has joined #riscv
GenTooMan has quit [Ping timeout: 272 seconds]
dinklebink has quit [Quit: Leaving]
prabhakarlad has quit [Quit: Client closed]
crabbedhaloablut has joined #riscv
admiral_frost has joined #riscv
cousteau has quit [Ping timeout: 255 seconds]
cousteau has joined #riscv
GenTooMan has joined #riscv
davidlt has joined #riscv
cousteau has quit [Ping timeout: 240 seconds]
cousteau has joined #riscv
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Read error: Connection reset by peer]
Furry has joined #riscv
davidlt has quit [Ping timeout: 260 seconds]
zBeeble42 has joined #riscv
zBeeble has quit [Ping timeout: 240 seconds]
zBeeble42 has quit [Read error: Connection reset by peer]
zBeeble42 has joined #riscv
mlw has joined #riscv
BootLayer has joined #riscv
Furry has quit [Quit: Leaving]
admiral_frost has quit [Quit: It's time]
admiral_frost has joined #riscv
mlw has quit [Ping timeout: 260 seconds]
mlw has joined #riscv
handsome_feng has quit [Quit: Connection closed for inactivity]
elastic_dog has quit [Ping timeout: 272 seconds]
junaid_ has joined #riscv
elastic_dog has joined #riscv
Jackneill has joined #riscv
notgull has quit [Ping timeout: 240 seconds]
GenTooMan has quit [Ping timeout: 260 seconds]
notgull has joined #riscv
davidlt has joined #riscv
GenTooMan has joined #riscv
admiral_frost has quit [Quit: It's time]
Gravis has quit [Ping timeout: 240 seconds]
Gravis has joined #riscv
notgull has quit [Ping timeout: 245 seconds]
ezulian has joined #riscv
danilogondolfo has joined #riscv
notgull has joined #riscv
clemens3 has quit [Changing host]
clemens3 has joined #riscv
jacklsw has quit [Ping timeout: 272 seconds]
cousteau has quit [Ping timeout: 272 seconds]
prabhakarlad has joined #riscv
junaid_ has quit [Ping timeout: 255 seconds]
cousteau has joined #riscv
junaid_ has joined #riscv
ntwk has joined #riscv
dabg has joined #riscv
billchenchina has joined #riscv
cousteau has quit [Ping timeout: 248 seconds]
cousteau has joined #riscv
esv_ has quit [Remote host closed the connection]
ezulian has quit [Quit: ezulian]
ezulian has joined #riscv
<wmat>
courmisch: fwiw, the vector branch of riscv-isa-manual repo has the vector spec integrated as a chapter as well
<wmat>
cousteau: fwiw, the vector branch of riscv-isa-manual repo has the vector spec integrated as a chapter as well
<wmat>
courmisch: sorry, autocomplete bit me there
esv has joined #riscv
junaid_ has quit [Remote host closed the connection]
BootLayer has quit [Quit: Leaving]
heat has joined #riscv
hightower3 has quit [Ping timeout: 264 seconds]
jfh has joined #riscv
heat has quit [Remote host closed the connection]
heat has joined #riscv
JanC has quit [Remote host closed the connection]
JanC has joined #riscv
jacklsw has joined #riscv
<cousteau>
wmat: nice, thanks :) Easy to remember, too
agent314 has joined #riscv
cousteau has quit [Quit: Quit]
mark4o has joined #riscv
billchenchina- has joined #riscv
markh has quit [Read error: Connection reset by peer]
mark4o is now known as markh
billchenchina has quit [Read error: Connection reset by peer]
aredridel has quit [Read error: Connection reset by peer]
ZipCPU has quit [Ping timeout: 272 seconds]
ZipCPU has joined #riscv
BootLayer has joined #riscv
mlw has quit [Quit: Lost terminal]
mlw has joined #riscv
<courmisch>
wmat: how dare thou hilight me for naught!! :)
Andre_Z has joined #riscv
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<wmat>
heh, ;) I suppose if your interested in ISA specs with integrated extensions, it's not for naught
<courmisch>
I have mixed feelings. The spec is going to get unwieldly long.
* courmisch
looks at DDI0487 page count
<wmat>
courmisch: i'm working on a plan to conditionally include whatever someone wants
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Read error: Connection reset by peer]
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<muurkha>
courmisch, wmat: I think it's very helpful to have RV32I in a single, short chapter, but if you're using a CPU with multiple extensions, it'd be nice to have a single index with all the instructions you have
<muurkha>
the alphabetical listing in ARM and Intel manuals that mixes ADD, LEA, MOV, and IMUL indiscriminately with not just CPUID but DPPD, BNDMK, FSUBR, and HSUBPS
<muurkha>
is not helpful
<muurkha>
it's like a strategy to make it as hard as possible to learn the instruction set
<muurkha>
also a single index by instruction *encoding* would be pretty useful
<muurkha>
probably the optimum for most uses is not to put every single ratified extension into the same manual
<muurkha>
also it would be pretty useful to have a manual that also documents T-Head's nonstandard way of implementing the V extension, because honey badger don't care if it's not ratified, they're shipping it anyway (and nobody is shipping the ratified version apparently?)
jacklsw has quit [Quit: Back to the real world]
<courmisch>
having spent a LOT of time trying to backport RVV code to 0.7.1, it sucks. Don't use that hardware, at least not for vectors.
vagrantc has joined #riscv
<courmisch>
and besides, newer T-Head designs implement RVV 1.0.0, so I'm almost certain that they themselves will drop any semblance of SW support for RVV 0.7.1 very soon
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #riscv
<sorear>
pretty much every manual has an "index by instruction encoding" but the utility varies widely, likely with some influence from the design of the instruction set itself
<courmisch>
I think I already posted it earlier, but if anyone really cares about RVV 0.7.1 differences from 1.0, I have tried to summarise them there https://www.remlab.net/op/riscv-v-draft-1.shtml
<sorear>
z/architecture principles of operation appendix B and intel sdm vol 2 appendix A on the better end
<courmisch>
ARM has one but it is really hard to follow
<courmisch>
or it's just cause I'm a lazy moron
<sorear>
i find ddi0487's structure quite confusing in general
<courmisch>
gotta keep revision A which was almost legible
<courmisch>
the moment they added E2H, it was over
<courmisch>
128-bit PTEs and GCS promise to make this a whole new labyrinth difficulty setting
<muurkha>
sorear: structure or lack thereof?
<sorear>
i'm not so arrogant as to say that just because I can't see the structure there isn't any
<muurkha>
courmisch: that's a relief, hopefully you're right
<courmisch>
muurkha: sorry what?
<muurkha>
about T-Head dropping 0.7.1
<muurkha>
(sorry for lack of context)
<courmisch>
C908 is RVV 1.0, this was announced already 2-3 months ago
<courmisch>
I think (?) it also has proper Zba and Zbb in addition to T-Head partially overlapping custom set
<sorear>
do we have a source handy for the possible availability this year of C908 low-volume dev boards? (mostly asking because of UXL/COMPAT support and khem's rv32 musl work)
<courmisch>
the rules for dev boards application made it clear that boring multimedia devs unlike AI cryptoblockchain devs needed not apply
<courmisch>
so I did not try
<courmisch>
but there *was* process to apply for dev boards last month
<courmisch>
I think it's closed now
<courmisch>
sorear: is there even a point in RV32 support in CPU? it should be trivial to implement an x32-style ABI on RV64, so I don't get why the hardware should care
<muurkha>
a point in RV32 support in a 64-bit CPU, you mean?
<courmisch>
yeah
<sorear>
*falls off chair laughing*
<sorear>
conceptually straightforward, maybe
<courmisch>
ARM is *dropping* 32-bit support from new high-end CPUs to rededicate the area to more useful functions
<muurkha>
at the same time, the vast majority of ARM's CPUs are 32-bit-only
<courmisch>
why RV, which has zero 32-bit binary compatibility to worry about, would add dual bit-width in 2023?!
<sorear>
it'll be years of work to get a usable riscv64ilp32 ABI and the lack of broad support for x32 and aarch64ilp32, despite vastly more funding...
<sorear>
we don't even have consensus that it's acceptable to allocate an ELF flag for riscv64ilp32
<muurkha>
but it's probably pretty rare to need hardware support for emulating a microcontroller on your laptop
<muurkha>
if you don't need consensus you could do it in a week
<courmisch>
muurkha: that...
<sorear>
my quest over the past few years to get people to use __SIZEOF_POINTER__ instead of __riscv_xlen if they want to know how big void* is has met with mixed success
<muurkha>
QEMU works fine for emulating a microcontroller on your laptop
<courmisch>
it should be fairly easy to write an RV32 emulator for RV64 if it comes to that
<muurkha>
you lose about an order of magnitude in performance when you're emulating ARM32 on amd64 with QEMU, but I suspect the penalty for RV32 should be a lot less than that
<muurkha>
maybe someone has measured
<muurkha>
but you typically have more than an order of magnitude of performance to spare in those situations anyway
<sorear>
rv32 userspace on rv64 is like 50 gates; all of the rv32 instructions are also in rv64, so you just need to change some of the decoding and truncate virtual addresses
<muurkha>
and verify the silicon
<muurkha>
the utter failure of actual x32 to get any adoption at all seems to show that the 64-bit tax isn't important enough except in very niche applications
<muurkha>
(on amd64 I mean)
<sorear>
i'm not ignoring the verification cost but courmisch specifically talked about "rededicate the area"
<muurkha>
yeah, I agree with your assertion that the area cost is unimportant
<courmisch>
well, ARMv7 is very different from ARMv8
<muurkha>
boy howdy
<courmisch>
no comparison with RV32 vs RV64 there
<muurkha>
more like i386 vs. amd64, but more extreme
mwette has joined #riscv
<sorear>
instead of using x32, you can build for i686+sse2 and have vastly better software support
<courmisch>
but my point was that if ARM is dropping it, it's odd for T-Head to be adding it
<muurkha>
T-Head does a lot of odd things
<sorear>
at the cost of half as many registers, but if you were considering x32 in the first place you were probably memory BW limited and losing a few registers will have no marginal effect
<muurkha>
odd things like shipping working RISC-V silicon with reasonable performance
ntwk has quit [Quit: ntwk]
<muurkha>
sorear: you have a good point that if you have hardware support for emulating the smaller architecture then x32-equivalents lose most of their appeal
<courmisch>
there's no legacy applications for RV32 though
<sorear>
no one cares about legacy applications, but a lot of hardware still has <4G memory
<sorear>
you can either spend years coordinating the standardization of a riscv64ilp32 ABI, or half an hour setting up an rv32 buildroot
<sorear>
or $1/unit adding more memory to store the upper halves of pointers
<courmisch>
i386 is all about running old games and business apps
<courmisch>
I'm not questioning the suitability of RV32 for cheap microcontrollers
<courmisch>
just the usefulness of supporting RV32 on RV64 IP
<sorear>
supporting rv32 on the c908 means that you can use the c908 on cheap microcontrollers
<muurkha>
hmm! I hadn't thought of that
<muurkha>
can you really?
<courmisch>
eh, does it even make sense to take a C908 for microcontroller
<courmisch>
it's not just the production costs, what about say energy consumption?
<muurkha>
a lot of microcontrollers don't care about energy consumption
<muurkha>
everything in industrial equipment and, in theory, automotive
<sorear>
i'm talking about the 32MB-2GB market segment where a paging OS is somewhat useful, not the 32kB market segment
<muurkha>
though Cortex-R automotive parts do often have low enough power consumption we used them in satellites
<muurkha>
but does C908 scale down small enough to be appealing for a 32MB system? I guess that's on the order of 4 million gates before the controller area starts to be a significant part of the overall system area. except that you're probably using Samsung DRAM made in some super-tiny process you can't afford to use for the microcontroller
<sorear>
didn't DRAM stall at 28nm because of leakage currents
admiral_frost has joined #riscv
<muurkha>
hmm, I don't actually know?
<muurkha>
but 28nm was 13 years ago, and DRAM has gotten a lot cheaper since then
junaid_ has joined #riscv
Leopold has quit [Quit: No Ping reply in 180 seconds.]
Leopold has joined #riscv
ezulian has quit [Ping timeout: 258 seconds]
<Esmil>
sorear: "rv32 userspace on rv64 is like 50 gates.." you'd also need some logic to mask out the upper 32bit of each register right?
<courmisch>
you only need to zero-extend the address operands AFAICT
<courmisch>
for ALU, you can just use the circuitry that already exists to for *W instructions
<mwette>
What's the user mode mechanism for invoking a system call (like `sc' op on ppc)?
<heat>
ecall
<mwette>
thx
<heat>
mwette, np. also args are in a0 - a5 and the syscall nr in a7
<mwette>
Thanks. I was digging in glibc source and didn't find it (sysdeps/sysv/linux/riscv/).
<muurkha>
it had different mnemonics in older RISC-V versions
<sorear>
grep for "scall" if "ecall" doesn't work
jfh has quit [Quit: Client closed]
<muurkha>
I forget, was there an mcall?
prabhakarlad has quit [Quit: Client closed]
<mwette>
thx
<sorear>
i don't think so
<sorear>
there was an eret, though
danilogondolfo has quit [Remote host closed the connection]
ntwk has joined #riscv
admiral_frost has quit [Quit: It's time]
agent314 has quit [Ping timeout: 255 seconds]
junaid_ has quit [Remote host closed the connection]
mlw has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 258 seconds]
admiral_frost has joined #riscv
zjason` has joined #riscv
zjason has quit [Ping timeout: 240 seconds]
BootLayer has quit [Quit: Leaving]
zBeeble42 is now known as zBeeble
hightower2 has joined #riscv
heat has quit [Remote host closed the connection]
heat has joined #riscv
Jackneill has quit [Remote host closed the connection]