On Fri, 20 Dec 2024 09:09:02 PST (-0800), richard.guent...@gmail.com wrote:
Am 20.12.2024 um 17:49 schrieb Palmer Dabbelt <pal...@rivosinc.com>:
On Thu, 19 Dec 2024 15:01:26 PST (-0800), jeffreya...@gmail.com wrote:
On 12/19/24 3:08 PM, Palmer Dabbelt wrote:
I agree lacking B and V makes us very clearly uncompetitive in the space
where these sort of things matter (ie, binary compatible distros and
long term stability type things) -- the gap is just too big to close by
doing clever things in the hardware. Maybe just B and V isn't enough,
it's hard to tell, but lacking them seems pretty clearly uncompetitive.
I'm not sure B is so scary on the SW side of things, it's been mostly
performance issues we've been fixing. V is huge, though, and we've
generally found a bunch of V-related functional codegen bugs. Without
reliable hardware to test against (and do distro builds and such) it
just seems premature to declare that being as stable as the other ports
on the list.
It wouldn't take much to push me into agreeing to B -- it's not scary in
any way. There's just notable systems out there that don't implement B,
but I wouldn't mind leaving them behind for this change.
V has real performance concerns. I haven't tested it performance-wise
on the BPI recently, but when I last did the general rule of thumb was
the more vector you did, the worse it performed *especially* for FP.
Yep. TBH that's actually my biggest worry here: it might be that just V isn't
enough, which means we have another few generations of HW before all the V
add-on extensions coalesce into something that's widely implemented. I'm not
really sure there, though -- the HW guys can be pretty clever so maybe V gets
us close enough to be interesting.
Note we usually do Not restrict ports to a subset of the ISA, iff extensions
are not ready for prime time Id suggest to instead never enable those by
default.
Ya, I'd noticed that when writing it ;)
Right now we don't have any sort of autoconf-time
"--enable-experimental-extensions" type thing, so they're just all in
the mix and controlled by -march. We don't generate code for them by
default or anything, but users can enable them.
So as a result we have a few tiers of how good stuff is in the compiler.
I don't think we've sat down and though up anything formal, as right now
they're just all in there together, but I'd line them up as:
* rv64gc. This is pretty good: full distro builds, hardware, etc.
There's still bugs, but they're not earth-shattering.
* Things like rv32, soft-float, B. These all pass the smell test, but
we don't have the big breadth of examples where they work because
there's no hardware and thus no distro builds. So maybe they're fine,
or maybe we're just being optimistic.
* Things like V, which don't pass the smell test (like we've been
talking about in the thread).
* The vendor extensions. I think most of these will remain low quality
forever.
This sort of thing has come up a few times in different contexts, and
I've generally come to the conclusion that trying to support all this
stuff that's not actually implemented in hardware really just results in
us shooting ourselves in the feet. We've had this acceptance creep over
the years (first we required hardware, then just a spec, and now vendor
stuff) and it's just slowly built up hard to support code.
The problem is that doing anything else basically involves telling
everyone to go fork the software world, which I think is worse.
Note we might want to start documenting primary/secondary _hosts_ vs targets as
well. For a native compiler that might imply a select default ISA.
Richard
jeff
