KombuchaKip has quit [Read error: Connection reset by peer]
aerkiaga has quit [Remote host closed the connection]
deflated8837 has quit [Ping timeout: 240 seconds]
vagrantc has joined #riscv
danilogondolfo has quit [Quit: Leaving]
djdelorie has quit [Remote host closed the connection]
cwebber`` is now known as cwebber
cwebber has joined #riscv
cwebber has quit [Changing host]
KombuchaKip has joined #riscv
deflated8837 has joined #riscv
Leopold_ has quit []
knolle has quit [Remote host closed the connection]
knolle has joined #riscv
BootLayer has quit [Quit: Leaving]
frkazoid333 has joined #riscv
prabhakarlad has joined #riscv
Tenkawa has quit [Quit: Was I really ever here?]
junaid_ has joined #riscv
paulk-bis has quit [Ping timeout: 240 seconds]
junaid_ has quit [Remote host closed the connection]
paulk has joined #riscv
dh` has quit [Ping timeout: 245 seconds]
zjason` has joined #riscv
sakman has quit [Remote host closed the connection]
zjason has quit [Ping timeout: 264 seconds]
pabs3 has quit [Ping timeout: 252 seconds]
<sorear_>
conchuod: no k210
sorear_ is now known as sorear
<sorear>
muurkha: the real puzzle is loongarch64. there's an obvious (mostly legal) case for switching to riscv64, an obvious (mostly ISA maturity) case for switching to aarch64, an obvious (mostly inertia) case for sticking with mips64... I cannot see how making a new ISA is anything other than the worst of all three worlds.
<muurkha>
sorear: it's a matter of degree, I think
pabs3 has joined #riscv
<muurkha>
like, you do need some kind of toolchain for your new ISA. but if you're Russ Cox you can probably bring up a toolchain for a new ISA in a few person-weeks
<muurkha>
but C compiled with it will run a third as fast as handwritten assembly
<muurkha>
getting to usually within epsilon of handwritten assembly is going to take another ten person-years
<muurkha>
and there's a long tail of bugs the users will have to cope with during those ten person-years
<muurkha>
depending on how demanding your users are about toolchain quality, that might be a better option than whatever you have to suffer from dealing with an architecture someone else designed
<sorear>
straw poll: should riscv_hwprobe provide a single point of truth for "which ISA extensions can I use in my ifunc-selected library" or should things like V be punted to other interfaces?
pabs3 has quit [Ping timeout: 240 seconds]
<sorear>
gonna throw a [RFC PATCH] in the next day or so and hope that we get an answer (in either direction) in time for 6.5
pabs3 has joined #riscv
<jrtc27>
what's more important is the user interface
<jrtc27>
there needs to be *something* in userspace that is just "what should my ifunc use"
<jrtc27>
that doesn't need arbitrary LKML-assigned IDs
<jrtc27>
(because vendors, for one)
<jrtc27>
*I* want that to be const char * -> unsigned, that takes an extension name and gives back the version, if implemented, in the same encoding that the C preprocessor macros use
<jrtc27>
but I'll take other interfaces too that meet the requirement
<sorear>
is it still the case that ifunc resolvers are called before relocation processing and you can't, in general, call external functions from them?
<jrtc27>
I don't know about other OSes, but FreeBSD does a two pass process
<jrtc27>
so on FreeBSD at least you're guaranteed that all your non-IFUNCs, and everything you depend on, have been processed already
<jrtc27>
which seems like a sane model to me
<jrtc27>
(or will be processed by lazy binding if that's enabled)
<jrtc27>
(possibly with an obscure edge case around the legacy LD_DYNAMIC_WEAK=1 behaviour when calling a weak function)
<sorear>
is there any third party you would accept to allocate names?
<sorear>
after the last few years of ISA string changes I trust LKML more than RVI
<muurkha>
names, as opposed to small integers or letters, can usually be allocated without a central authority
<muurkha>
as long as it isn't in anyone's interest to confuse their thing with somebody else's thing
<jrtc27>
it would have to be an OS-independent body
<jrtc27>
because "what LKML devs feel like" isn't a standard
<sorear>
I don't think there currently _is_ a grammar for ISA strings, the rules in the unprivileged spec are unambiguous as long as people don't start putting digits in extension names but...
<jrtc27>
as much as they want to make it one with DT, and cause pain and suffering for the rest of us in the process
<jrtc27>
(which hacks me off; just because linux wants to throw the baby out with the bath water and completely remove riscv,isa doesn't mean everyone should, but it does, because they define what a devicetree is)
<muurkha>
ugh
<jrtc27>
(contrast with UEFI and ACPI which, whilst they have their own flaws, at least have an independent standards body you have to go through)
<jrtc27>
(so now every OS has to deal with whatever LMKL's encoding du jour is)
<sorear>
if device tree development moved somewhere other than vger.kernel.org and they made a press release claiming neutrality, would that make them acceptable to you
<jrtc27>
yes
<jrtc27>
and there's been mumblings of something like that for *ages*
<jrtc27>
but it's never happened
<sorear>
really? the hostname is the problem?
<jrtc27>
no, the lack of neutrality
<jrtc27>
there are those who consider other OSes these days, which is progress
<jrtc27>
but at the end of the day it's driven by what LMKL devs think and want
<jrtc27>
and non-Linux devs are second-class citizens in the process
<jrtc27>
and have to subscribe to all the noise of Linux mailing lists (though maybe dt-specific lists aren't so bad?)
<jrtc27>
that was *supposed* to be an initial step in making DTs independent of Linux
<jrtc27>
AFAIUI
<muurkha>
UEFI and ACPI are not where I would look for exemplary standards
<muurkha>
power management used to work in Linux with APM
<muurkha>
since the switch to ACPI it's never worked
<muurkha>
except on Android, which doesn't use ACPI
<jrtc27>
that's an entirely separate conversation
<jrtc27>
about the technical content of the specifications and their implementations (both sides)
<jrtc27>
I'm talking solely about the sociopolitical side
<muurkha>
the technical content is produced by the sociopolitical side
<muurkha>
I'm not convinced that an "independent standards body" has improved the sociopolitical side in a sense that produces working technical content
<muurkha>
with UEFI, well, I guess my machine does boot
<muurkha>
I think it's at least plausible that having an independent standards body has enabled people to have a voice in the process who shouldn't have
<muurkha>
and the result is that the standards are orders of magnitude more complex and error-prone than they should have been
<jrtc27>
more likely it's second system syndrome
<jrtc27>
going from BIOS+APM to UEFI+ACPI
<muurkha>
could be
<sorear>
the C is far more important than the P and I don't care about PC compatibles
<muurkha>
only genuine IBM computers for you?
<sorear>
i only care about ACPI in the context of SBBR
<muurkha>
oh, not even amd64 machines at all
<muurkha>
I pretty much only care about it in that context because that's the context where it fucks me over on a weekly basis and has been for 20 years
<jrtc27>
"orders of magnitude more complex and error-prone than they should have been" - so like the instruction set you're running it on? (:
<muurkha>
jrtc27: yes!
<muurkha>
very much so
<muurkha>
(in the context of IBM-PC-compatibles, I mean, not the context of SBBR)
<jrtc27>
then you'll be sad to hear we're fleshing out our CHERI-x86 story...
<jrtc27>
(although likely embracing x86s or whatever it's called; we'd already culled some legacy stuff in our spec)
<dh`>
cheri-x86 seems completely useless
<dh`>
since you need to recompile and need custom hardware anyway, what does it buy to use x86?
<jrtc27>
you can run your legacy binaries
<dh`>
a small amount of badly written software that'll never work with cheri anyway
<jrtc27>
games?
<dh`>
you're intending to provide both cheri and non-cheri modes?
<jrtc27>
that's always been a feature
<jrtc27>
backwards-compatibility is vital
<jrtc27>
at least in the non-embedded case
<jrtc27>
for embedded, sure, everyone has their own proprietary software stack for their own custom ISA (or these days increasingly just RISC-V if they're not doing Arm-M) and they can just rebuild it all
<dh`>
I guess; in my world it seems reasonable to recompile everything
<sorear>
there's probably a viable niche for running a mix of proven-correct software that takes advantage of small pointers and CHERI for everything else
<jrtc27>
in my world we've had users of morello hardware try and run proprietary freebsd/amd64 binaries on their morello boxes and come to us asking what the error when they do so means
<jrtc27>
(at least they know freebsd isn't linux?..)
<jrtc27>
to be a little fair, they were just labeled as "FreeBSD (64-bit)" or some such, no mention of them being amd64, but it doesn't take much thought to figure out that that's surely what they are, what the error means and that you could verify what type of file it is
<sorear>
would be nice if there was something better than qemu tcg
<sorear>
caught up on everything since Jun 1. I'm not going to attempt to go further back, if you have something unanswered re-raise it
<jrtc27>
better than qemu tcg for what?
<muurkha>
what would it mean for CHERI-x86 to flesh out without embracing x86?
<sorear>
I think that was «embracing x86s», where x86s is a subset name
<sorear>
unsure if it's the same as what intel announced recently
<muurkha>
oh, I thought "embracing x86s" meant "embracing x86 (plural)"
<jrtc27>
there's also the exceptionally-named FRED that cleans up some of the exception model
<jrtc27>
("Flexible Return and Event Delivery")
<jrtc27>
... pun not intended re "exceptionally", but, uh...
<muurkha>
Intel spells it "x86S", which is a little less confusing I guess
<muurkha>
heh
<jrtc27>
intel also used to call 64-bit processors IA-32e but nobody's going to type it like that on IRC...
<jrtc27>
anyway, yes, that thing, call it what you will
frkzoid has joined #riscv
<sorear>
_most_ of that thing is just deleting microcode with no impact on the parts that matter, but I'm glad to see they're getting rid of the fourth input to the address generation adder
<muurkha>
heh
<sorear>
does intel do single-cycle access to configuration registers yet?