<lkcl>
so when various ****wits in the RISC-V Foundation told us, "go shove your stupid 3D extensions into the Custom opcode space, where they belong, you moronic stupid little Free Software loving religious zealots", we weren't very happy
<lkcl>
not because they were being unbelievably rude, but because Custom Extensions are *specifically* prohibited from being upstreamed into gcc and binutils mainline.
<lkcl>
the first time that ever happens it basically means that whoever "wins" that one becomes the de-facto standard definition for the RISC-V Custom-Extension opcodes
<lkcl>
by complete contrast the OpenPOWER Foundation has been extremely supportive of our efforts to extend OpenPOWER.
<lkcl>
we still have to go through an "Approvals" process, however they've actually said, clearly, that they're happy to do that and would welcome it.
<lkcl>
even more interestingly: people proposing OpenPOWER ISA extensions do *not* actually have to join the OpenPOWER Foundation to do so.
samlittlewood has quit [Read error: Connection reset by peer]
<d1b2>
<dub_dub_11> what's the difference between ISA extensions and custom opcodes?
samlittlewood has joined #nmigen
peepsalot has joined #nmigen
peeps[zen] has quit [Ping timeout: 260 seconds]
<Sarayan>
ISA extensions are public custom opcodes
<d1b2>
<dub_dub_11> oh
<d1b2>
<dub_dub_11> so if you make a custom opcode public how can they stop it being an extension 🤔
<Sarayan>
17:31 <lkcl:#nmigen> not because they were being unbelievably rude, but because Custom Extensions are *specifically* prohibited from being upstreamed into gcc and binutils mainline.
<Sarayan>
that is how, by making it really inconvenient
<lkcl>
RISC-V (and OpenPOWER) are Trademarked.
<lkcl>
if you try to bring them into disrepute, then the owners of those Trademarks can sue you for material damages
<d1b2>
<dub_dub_11> oh, so the openly available compiler won't support your custom extension, only your fork of it?
<lkcl>
and "dominating the custom opcode space" would... yeees, exactly, dub_dub_ll
<d1b2>
<dub_dub_11> I see
<lkcl>
which places a massive burden on a very small team to not only maintain a permanent hard-fork of gcc, binutils and llvm
<d1b2>
<dub_dub_11> that does sound like a pain
<lkcl>
but entire OS distros as well - recompiled with the new custom extensions
<d1b2>
<dub_dub_11> right...
<lkcl>
so much of a pain that the total intransigence of the RISC-V Foundation, in direct violation of Trademark Law, meant that we were forced to abandon RISC-V entirely
<d1b2>
<dub_dub_11> 😦
<lkcl>
their loss. they did us a huge favour. OpenPOWER ISA has IBM behind it, for goodness sake
<d1b2>
<dub_dub_11> lol
<Sarayan>
How complicated is power though?
<Sarayan>
or did you just license a core?
<lkcl>
that's a really interesting question. the original POWER1 paper explains that the "RISC" part is based on 5 register broadcast "Lanes", RS/T/A/B/C
<lkcl>
where the "shift/mask" operation is shared with the "load/store" to save a huge number of gates
<lkcl>
Sarayan: you can have a look here to get an idea of the complexity, for yourself
<lkcl>
the ADD operation is utterly cool. there's only actually one ADD, but by Micro-Coding it you can put "neg-A" and "neg-output" plus "Carry-in = CA/0/1" and so on to create SUB, NEG, and a boat-load more operations, all from the one single "ADD" pipeline.
<d1b2>
<dub_dub_11> isn't that normal for a RISC core? to only have a single adder
<lkcl>
that one "ADD" pipeline, with its carry-in, carry-out and neg-A and neg-out pre- and post- processing, turns into something mad like 60+ opcodes!
<d1b2>
<dub_dub_11> oh wow
<d1b2>
<dub_dub_11> that is something extra special then
<lkcl>
dub_dub_ll: 60 opcodes in front of a single ADD pipeline ain't normal for RISC! :)
<Sarayan>
nice
<lkcl>
but it all "makes sense" once you get into it.
<Sarayan>
it's all in nmigen?
<lkcl>
the designers really, *really* thought about it
<lkcl>
Sarayan: yyep.
<Sarayan>
nice, so maybe even usable on a fpga
<lkcl>
yep it is. the current implementation, even though it's similar performance to picorv32, is around 18k LUT4s in an ECP5
<lkcl>
here's that "pre-processing" to neg-A (and neg-B)