reddit-bot has quit [Remote host closed the connection]
justache has joined #riscv
justache has quit [Remote host closed the connection]
justache has joined #riscv
stolen has quit [Quit: Connection closed for inactivity]
naoki has quit [Quit: naoki]
junaid_ has joined #riscv
junaid_ has quit [Client Quit]
MaxGanzLaptop2 has joined #riscv
JanC has quit [Ping timeout: 268 seconds]
JanC has joined #riscv
ezulian has joined #riscv
ezulian has quit [Remote host closed the connection]
ezulian has joined #riscv
junaid_ has joined #riscv
Leopold_ has joined #riscv
Leopold has quit [Remote host closed the connection]
MaxGanzLaptop2 has quit [Ping timeout: 260 seconds]
crossdev has joined #riscv
davidlt has joined #riscv
rsalveti has quit [Quit: Connection closed for inactivity]
jacklsw has quit [Ping timeout: 260 seconds]
crossdev has quit [Ping timeout: 240 seconds]
puranjaymohan has quit [Excess Flood]
puranjaymohan has joined #riscv
davidlt has quit [Ping timeout: 268 seconds]
DynamiteDan has quit [Ping timeout: 256 seconds]
mlw has quit [Ping timeout: 260 seconds]
seds has quit [Ping timeout: 256 seconds]
mlw has joined #riscv
seds has joined #riscv
DynamiteDan has joined #riscv
junaid_ has quit [Ping timeout: 268 seconds]
Noisytoot has quit [Excess Flood]
Noisytoot has joined #riscv
iooi_ has joined #riscv
junaid_ has joined #riscv
iooi has quit [Ping timeout: 246 seconds]
iooi_ is now known as iooi
iooi_ has joined #riscv
iooi has quit [Ping timeout: 264 seconds]
iooi_ is now known as iooi
davidlt has joined #riscv
unlord has quit [Ping timeout: 260 seconds]
unlord has joined #riscv
MaxGanzLaptop2 has joined #riscv
davidlt has quit [Ping timeout: 246 seconds]
zBeeble has quit [Ping timeout: 268 seconds]
davidlt has joined #riscv
zBeeble has joined #riscv
junaid_ has quit [Ping timeout: 264 seconds]
hmw has quit [Quit: Bye.]
hmw has joined #riscv
hmw has quit [Client Quit]
hmw has joined #riscv
hmw has quit [Client Quit]
hmw has joined #riscv
junaid_ has joined #riscv
jacklsw has joined #riscv
ntwk has quit [Ping timeout: 256 seconds]
Tenkawa has joined #riscv
BootLayer has quit [Quit: Leaving]
jacklsw has quit [Ping timeout: 268 seconds]
heat has joined #riscv
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #riscv
BootLayer has joined #riscv
psydroid has joined #riscv
mlw has quit [Ping timeout: 256 seconds]
mlw has joined #riscv
handsome_feng has quit [Quit: Connection closed for inactivity]
marcj has quit [Ping timeout: 264 seconds]
junaid_ has quit [Quit: Lost terminal]
stolen has joined #riscv
junaid_ has joined #riscv
Stat_headcrabed has joined #riscv
MaxGanzLaptop2 has quit [Remote host closed the connection]
MaxGanzLaptop2 has joined #riscv
ntwk has joined #riscv
fuwei has quit [Ping timeout: 256 seconds]
fuwei has joined #riscv
Leopold has quit [Remote host closed the connection]
Leopold has joined #riscv
cousteau has joined #riscv
<cousteau>
Hi!
<cousteau>
Which RV architectures are supported by Linux? Only 64b ones, right? With which required extensions?
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<cousteau>
RV64IMAC? GC? Also needs S? (can't remember if S is an extension per se or a collection of extensions)
hightower3 has joined #riscv
<cousteau>
...ok, it wasn't listed right away but the Debian wiki does mention it uses RV64GC (with lp64d ABI, I don't know what the "d" means but I guess "pass double-precision floats using f registers")
Nixkernal_ has joined #riscv
<davidlt>
conchuod, d is double floats
<cousteau>
Yes, but I don't know what it means in that context
<davidlt>
Currently distros support old-school R64GC (lp64d), that's before Profiles happened, and before Platforms (well, there is only a server platform).
<cousteau>
lp64 means "long and pointer are 64 bits, int is 32", and d means... something to do with double-precision floats, that's for sure
hightower4 has quit [Ping timeout: 264 seconds]
JanC_ has joined #riscv
* cousteau
tries to google it
JanC has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
<davidlt>
ah, lp64 is soft float, lp64d is hardfloat, double precision)
<cousteau>
I see, thanks :)
<cousteau>
"Contrast with -march=rv64ifd -mabi=lp64f, which still allows the compiler to generate code that uses the F and D extensions but only allows fp values up to 32b long to be passed in registers"
<jrtc27>
depends what you mean by linux
<jrtc27>
you can do non-C and M-mode if you're building your own kernel + userspace and really want to
<cousteau>
So yeah, what I suspected. Without the d it can still use D instructions, but the ABI says that those values need to be passed as boring x registers, not directly as f registers
<jrtc27>
but of course if you want a distro then you should go check that distro's requirements
<cousteau>
jrtc27: I see... I guess I was thinking "a preexisting GNU/Linux distro", not "it's C code, you can build it wherever you like"
<cousteau>
Anyway, I guess my assumption that "Linux only supports 64-bit RV" isn't fully correct, it's "most Linux distros..."
<cousteau>
davidlt: "profiles" are related to "application/embedded profiles"? I remember hearing a lot about the cva5 and cva6 profiles (although my current understanding is that that refers to specific implementations or implementation families)
<jrtc27>
profiles are recommended sets of extensions
elastic_dog has quit [Ping timeout: 256 seconds]
elastic_dog has joined #riscv
heat has quit [Read error: Connection reset by peer]
heat has joined #riscv
<cousteau>
Oh
* cousteau
wonders why the first Google link for "risc-v profiles" appears highlighted in "visited purple" in his browser
<cousteau>
OK, so apparently the first time I heard of profiles I saw all these RVI20, RVA20 etc, then immediately after that I was introduced to CVE2, CVA6 and the two notations must have gotten mixed up in my head
<cousteau>
Lol, funny how they point out that "in the next century the year will use 3 digits" (e.g. RVA101 for year 2101). Meanwhile, I've worked with platforms that used a timestamp system designed in the early 2010s (or maybe 2000s) that stopped working on January 1st, 2022... talk about short foresight!
heat has quit [Read error: Connection reset by peer]
heat has joined #riscv
<cousteau>
Do 32 bit instructions have to be aligned to 32 bits? Ie, a sequence of 16-bit instructions must always contain an even number of them (possibly padded with nop) before the next 32-bit instruction?
<sorear>
cousteau: pre-profiles the target was RV64GC for all precompiled distros, RV32I or RV64I for compilers. Linux requires RV32IMA or RV64IMA (M and A were optional, but a protest was thrown during upstreaming).
<cousteau>
I see
<sorear>
cousteau: 32-bit instructions must be aligned to IALIGN, which is an implementation parameter. If the C extension is implemented, IALIGN must be 16 so you can have an odd number of 16-bit instructions, otherwise IALIGN can be 16 or 32
<cousteau>
M being optional would suck... And A as well for an OS, I bet. I doubt FD are needed at all on a kernel or OS; just a convenience for *some* applications
<sorear>
cousteau: debian and I believe alpine are targeting RVA20U64, which is basically the same as RV64GC with only minor added requirements (atomics must be supported in main memory, write/execute races on aligned 32-bit instructions are required to do something sensible). Fedora has expressed an intent to target RVA23U64 which adds bit-manipulation and vectors as things applications can rely on
<conchuod>
Certainly for a kernel you can do without them.
<sorear>
applications can always discover additional extensions through out of band mechanisms and use them
<conchuod>
Linux atm does not use the fpu at all
<sorear>
wasn't there a patchset to enable fpu in kernel space with a comment that amdgpu needs it, or did that never get merged?
<conchuod>
Not merged yet afaiu. Hellwig had some comments about making things more generic than Samuel had them.
<sorear>
linux doesn'
<sorear>
linux doesn't use M _that_ much, it doesn't even provide the ABI helper for "long long" division on 32-bit architectures
<cousteau>
sorear: gotcha [re: align]. I was reading a description of extension Ziccif, which claims that "any instruction fetches aligned to ... (i.e., 32b for RVA20) are atomic". This would mean that not every 32-bit instruction fetch would be atomic, since not every 32-bit instruction is aligned to 32 bits if C is present
<davidlt>
FPU mode patch is posted and there is a generic version, but that requires ACK from a lot of arch maintainer (will take time).
<jrtc27>
modern amdgpu does indeed use the fpu
<sorear>
A is kind of needed for anything multithreaded or with interrupts, unless you want to invent an entirely new ABI using restartable sequences for cmpxchg. I suspect that soon after Zalrsc and Zaamo are ratified the linux requirement will be lowered to Zalrsc OR Zacas instead of full A
<jrtc27>
specifically for the display controller
<jrtc27>
you can do pure compute without it, I believe
<cousteau>
I wonder what does it need it for
<davidlt>
jrtc27, IIRC, yeah, it's the display engine that needs it
<davidlt>
This is only for RNDA1/2/3/.. GPUs (anything modern).
<jrtc27>
go grep for DC_FP_START if you're curious
<sorear>
android hasn't committed to an ISA level yet, although they want vectors to be close to parity with arm 8.0-a
<sorear>
is anyone other than debian, fedora, alpine, and android shipping risc-v binaries?
<davidlt>
smaeul, thanks for the effort!
<conchuod>
In case I was misunderstood, by "linux atm" I meant that there's nothing you can build at at the moment that will use it. Not that there won't be soonTM.
<sorear>
cousteau: why not?
<conchuod>
smaeul: Ah I didn't see that series. The date being a factor I guess.
<cousteau>
I thought those were mostly for HPC stuff but kinda experimental yet
<jrtc27>
video codecs like vectors
<davidlt>
conchuod, vectors? Those are a requirement for server platforms and Android too
<cousteau>
I mean, *I* want vectors, but I'm sort of an HPC nerd
<sorear>
vectors are useful for anything that does regular compute, since they improve both performance and energy efficiency
<cousteau>
It doesn't help that your nick and mine start by the same two letters, have the same length, and (last I checked) are colored the same in HexChat
<jrtc27>
hexchat's hash function is nick[0:2]?
<davidlt>
Nah, they are very similar color but not the same
<conchuod>
palmer: are you gonna send more fixes for v6.8 or nah?
<sorear>
the vectors in video codes person here is courmisch, who I just had to check wasn't already in the conversation. it remains to be seen how actually useful risc-v vectors are for end to end transcoding workloads given that the hyperspecialized stuff like SAD is missing
<cousteau>
jrtc27: I don't think so because cousteau and cousteau_ are colored different
<jrtc27>
ah no its hash function is "sum all the characters and take it mod the number of colours"
<cousteau>
sorear: oh great, another person starting with cou :)
<cousteau>
jrtc27: cool!
<sorear>
does freebsd ship riscv64 binaries with interesting extension compatibility properties?
* jrtc27
always has to stop and thing which co* person is which
<jrtc27>
uh, elaborate?
<cousteau>
So cousteau and any anagram of cousteau would have the same colors?
<jrtc27>
yeah
<jrtc27>
also ac and bb are the same colour
Leopold has quit [Remote host closed the connection]
Pokey has joined #riscv
Leopold has joined #riscv
<sorear>
jrtc27: if I'm understanding correctly riscv64 and riscv64sf being tier 2 architectures means that there's no officially hosted binary packages
<jrtc27>
riscv64sf never really lived
<jrtc27>
riscv64 did have packages at one point
<jrtc27>
not sure why it's gone
<sorear>
on second look 13.x has an installation image for riscv64 (only, despite riscv64sf having the same support tier) which presumably contains rva20 binaries
<jrtc27>
riscv64sf only existed in theory
<jrtc27>
nothing was ever building or testing it
<jrtc27>
we deleted it from the tree last(?) year
<jrtc27>
so yeah, currently our target is rva20
<sorear>
rustup has precompiled toolchains for "riscv64gc-unknown-linux-gnu" which should be rva20
heat has quit [Remote host closed the connection]
heat has joined #riscv
<cousteau>
sf being soft-float?
<cousteau>
Or the Sf extension (whatever it is; something to do with Supervisor I presume)
<cousteau>
Oh yes, soft-float
<sorear>
without a previous "i" "e" "g" there is no reason for it to represent an extension
<cousteau>
True. Plus it says riscv, not rv
* cousteau
has yet again forgotten if soft-float means that the ABI doesn't use float regs in function calling, or that there's no FPU support at all
stolen has quit [Quit: Connection closed for inactivity]
<sorear>
at least the former, usually both
<cousteau>
hf = ABI, ?? = ISA only but no ABI, ?? = not even ISA supports floats (ARM called those hard, softfp, soft respectively)
<sorear>
in principle if you have a soft-float userland and a kernel+cpu with fpu support you can use "gcc -march=rv64gc -mabi=lp64" to compile soft-float-compatible code that uses the FPU
<sorear>
in freebsd "riscv64" is float ISA + float ABI, "riscv64sf" is non-float ISA + non-float ABI. please understand that this is freebsd specific terminology
<cousteau>
Thanks :)
<sorear>
gcc and llvm use separate march/mabi options. risc-v official documentation for the most part does not name ABIs. "riscv64" on all known binary distros currently implies rv64gc/lp64d
<cousteau>
Good to know
Tenkawa has quit [Quit: ... ... ... ... ...]
<cousteau>
What about supervisor / M/S/U modes? Are those required?
Tenkawa has joined #riscv
<sorear>
for what?
<cousteau>
For Linux
<cousteau>
Oh, and virtual memory (I'm not sure if that's even part of the ISA)
<cousteau>
*For typical Linux distros
<cousteau>
Maybe I should just ask at #debian-riscv on OFTC
<conchuod>
For regular distro stuff, ye you need supervisor mode and virtual memory.
<conchuod>
You can run a linux kernel in m-mode and without virtual memory, but that's gonna be a buildroot etc type of system.
junaid_ has quit [Quit: Lost terminal]
junaid_ has joined #riscv
cousteau_ has joined #riscv
cousteau has quit [Ping timeout: 260 seconds]
<cousteau_>
conchuod: OK thanks! I didn't see that listed on the Debian wiki so I wasn't sure
<sorear>
Most Linux applications will run fine on an M_MODE/MMU=n kernel, the exceptions being anything that relies on MAP_FIXED, handling of SIGSEGV, and position-dependent executables
<sorear>
"supervisor mode and virtual memory" is spelled "ss1p10_sv39" which is part of rva20s64; there's no extension name for 32-bit supervisor mode
<sorear>
if you have rva20s64 and supported devices, you can use a distro kernel
<cousteau_>
I was surprised to learn recently that most executables are position-independent. I was convinced that the main role of an OS was to load binaries at a random position and then virtualize the memory.
<jrtc27>
how do you fork in m-mode?
<cousteau_>
sorear: I see, thanks!
<jrtc27>
(AFAIK the answer is "you don't"
<jrtc27>
)
<cousteau_>
jrtc27: very carefully :)
<sorear>
i should add that to the list, posix_spawn is fine though
<jrtc27>
yeah posix_spawn is fine
<jrtc27>
ditto vfork?
<sorear>
historically fork predates MMUs but linux doesn't have a historically appropriate implementation
<jrtc27>
if you're willing to swap out memory
<jrtc27>
sure
<sorear>
(back in the "process-granular swap" era)
<jrtc27>
but an embedded system is unlikely to have enough secondary storage for that
<sorear>
OS means different things to different people
BootLayer has quit [Quit: Leaving]
davidlt has quit [Ping timeout: 240 seconds]
mlw has quit [Ping timeout: 264 seconds]
cousteau has joined #riscv
hightower4 has joined #riscv
cousteau_ has quit [Ping timeout: 256 seconds]
hightower3 has quit [Ping timeout: 264 seconds]
cousteau_ has joined #riscv
cousteau has quit [Ping timeout: 252 seconds]
cousteau_ has quit [Ping timeout: 272 seconds]
jfsimon1981 has quit [Remote host closed the connection]
junaid_ has quit [Remote host closed the connection]