| * lkcl waves to segher | 17:53 | |
| lkcl | would be interested to hear your thoughts on whether jacob's noticing that MIPS added "-elf-" options, disabled by default, to switch on IEEE754-2008 mode, RISC-V doing something similar | 17:55 |
|---|---|---|
| lkcl | if you thought that was sane / safe to do (adding to ELF v2 ABI, no need for new triplets) | 17:55 |
| lkcl | or is it more along the lines of "hmmm" :) | 17:56 |
| programmerjake[m | more specifically adding another flag to elf files, handled by the loader, linker, and dynamic linker | 17:57 |
| lkcl | nice. do you happen to know any concrete examples (i mean actual source code) with that? | 17:58 |
| lkcl | just found this for example https://gcc.gnu.org/legacy-ml/gcc/2015-11/msg00068.html | 18:01 |
| programmerjake[m | I think I found a good example: https://patches-gcc.linaro.org/patch/4834/ | 18:11 |
| programmerjake[m | iirc the RISC-V E ABI doesn't allow using r16 through r31 | 18:12 |
| rsc | lkcl: just asking...are you attending the embedded world digital trade fair? | 21:37 |
| lkcl | programmerjake[m: excellent | 21:58 |
| lkcl | rsc: didn't know it was running! | 21:58 |
| lkcl | that looks to me like it's an actual new ABI. ilp32e | 22:04 |
| lkcl | to check whether that's true: is it the case that a program compiled for lpl32e will run entirely fine on a current (standard linux) RV32GC ilp32 system? | 22:06 |
| programmerjake[m | yes | 22:06 |
| lkcl | cool! | 22:06 |
| programmerjake[m | however, not the other way around | 22:06 |
| lkcl | and can you compile a dynamic library for ilp32e and have it be used by ilp32 programs? | 22:07 |
| lkcl | interesting about "not the other way round" | 22:07 |
| lkcl | that would make sense | 22:07 |
| rsc | lkcl: it's not yet running, in 1.5 weeks or so. Not sure if it could be interesting for you/the project. | 22:08 |
| lkcl | ah the CfP was sep 30 2020 https://call-for-papers.weka-fachmedien.de/frontend/index.php?sub=278 | 22:09 |
| programmerjake[m | used by ilp32 programs: often, as long as the code doesn't use too many argument registers... | 22:09 |
| lkcl | programmerjake[m, _great_. that's _great_ news | 22:10 |
| programmerjake[m | the "not the other way around" is because there are RISC-V cpus with only 16 registers, they implement rv32e instead of rv32i | 22:11 |
| lkcl | because it means that there's a good example where registers were removed, inaccessible from an ABI, and yet still the ABI did not need a new triplet to do it. it was a modification of an *existing* ABI | 22:11 |
| rsc | lkcl: well, yes, CfP is over, you just can attend now ;-( | 22:11 |
| programmerjake[m | so the other registers just don't exist | 22:11 |
| lkcl | rsc: it's not a hard rule, but just empirically, there are no technical conferences i've attended in 25 years where i have not also been a speaker | 22:12 |
| programmerjake[m | i think they use a new triplet anyway for riscv32e | 22:13 |
| rsc | lkcl: heh. Maybe for 2022 ;-) the trade fair (with a conference) is dedicated to embedded hard/software, thus I thought it could be interesting maybe | 22:13 |
| jn__ | ahh, to go to conferences again... | 22:14 |
| sorear | triplets unfortunately don't mean anything technically | 22:15 |
| lkcl | jn__: sigh :) | 22:16 |
| lkcl | sorear: interesting. can you say more? we're currently being recommended that modifications to ELF v2 to remove the (mistaken, mandatory) use of SIMD will need a new triplet, and a new ABI, and therefore an entire new distro port for debian, ubuntu, fedora, everything. | 22:18 |
| lkcl | total nightmare | 22:18 |
| sorear | something like "i686-unknown-linux-gnu" hides hundreds of possible ABIs | 22:18 |
| sorear | well ABI/ISA combinations | 22:19 |
| lkcl | but the flaw there is in "remove". we're looking for a way for ELF v2 to *dynamically* include code-that-has-VSX and code-that-does-not in the exact same ELF v2 ABI | 22:19 |
| programmerjake[m | sorear: not entirely the case for risc-v since the triplet contains the list of ISA extensions enabled by default: riscv32gc == g + c == i + m + a + f + d + c, riscv32imac == i + m + a + c | 22:19 |
| sorear | -mfp=sse? -D_FILE_OFFSET_BITS=64? -mavx2? etc etc | 22:19 |
| sorear | programmerjake[m: I've done OS porting and the only triplets I've seen there are "riscv64-unknown-linux" and "riscv32-unknown-linux"; I have never seen "riscv32gc" even when it would make sense | 22:20 |
| lkcl | sorear: if you compile something up that doesn't have any one of those options, does the program still run? does it still work, on a distro that's built for i686-unknown-linux-gnu? | 22:20 |
| lkcl | or even if it does :) | 22:20 |
| sorear | correction I have seen "riscv32gc" in exactly one place, the Rust target list | 22:21 |
| sorear | gcc, llvm, debian, fedora? nah | 22:21 |
| sorear | lkcl: maybe? good luck | 22:22 |
| lkcl | :) | 22:22 |
| sorear | this is why LSB happened | 22:22 |
| lkcl | i think those features drop down onto glibc6 HWCAPS, in x86 | 22:22 |
| programmerjake[m | sorear: hmm, maybe that's where I'd seen it, but I recall it being part of the RISC-V spec somewhere that riscv32gc is how you specify a cpu that supports g + c | 22:38 |
| programmerjake[m | I was under the incorrect impression that llvm supported parsing that info from the target triple | 22:38 |
| lkcl | programmerjake[m: ahhh... i just realised something else about the rv32e system | 22:39 |
| lkcl | let's say you have an rv32e processor | 22:39 |
| lkcl | you download a current debian rv32gc ISO | 22:40 |
| sorear | programmerjake[m: those are ISA strings, which are only tangentially related to triples | 22:40 |
| lkcl | will it work? | 22:40 |
| sorear | no | 22:40 |
| sorear | rv32gc uses 31 integer registers because gc includes i | 22:40 |
| lkcl | sorear: that's what i expected, and that's the situation we have to "make work" | 22:40 |
| lkcl | (for A2O, A2I, microwatt *and* LibreSOC, in the OpenPOWER world) | 22:41 |
| lkcl | i think getting that to work involves first getting ELF v2 to support non-SIMD (and non-QFP) | 22:41 |
| lkcl | then having libraries *dual compile* just like apple does. did | 22:42 |
| programmerjake[m | iirc elfv2 doesn't require 128-bit fp, it does require simd | 22:42 |
| lkcl | their "universal binaries" | 22:42 |
| programmerjake[m | well, good luck with that, it didn't happen last time: see fatelf | 22:43 |
| lkcl | it's fine if that multilib-like / universal thing takes a while to propagate through | 22:44 |
| lkcl | ahh interesting | 22:44 |
| programmerjake[m | iirc fatelf was rejected from the linux kernel | 22:44 |
| lkcl | i would expect only certain *functions* to be replaced (those that have a different ABI signature) | 22:45 |
| programmerjake[m | fatelf is similar to macos fat binaries in that a fatelf file is just multiple elf files glued together | 22:45 |
| programmerjake[m | I'd expect multilib to have a much better chance, since it's already widespread | 22:46 |
| lkcl | it looks however like fatelf was designed to plug together completely separate CPU architectures | 22:47 |
| lkcl | yyeah but multilib is literally a total new library, totally new ABI, again totally new triplet | 22:47 |
| programmerjake[m | ^ exactly what macos universal binaries do | 22:47 |
| programmerjake[m | first one: powerpc + x86, second one: x86 + arm | 22:48 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!