I want to write something longer on the subject, but... why do people prefer RISC-V over SPARC? They're both FOSS ISAs, except SPARC is much more mature. And it's not like we don't have open source implementations to work from, UltraSPARC T1 and T2 had their verilog released under the GPL.

@techokami Isn't SPARC just old, obsolete, and abandoned? I mean, it still has delay slots. RISC-V has its flaws, but at least it's actively being developed.

@techokami The way SPARC burns way too much encoding space so that it's hard to add other instructions without expanding to a second word is probably one of the bigger reasons~

(IIRC I remember one of the designers stating that the above is indeed a goal of the design so uh)

There's also other quirks like register windowing and branch delay slots, while those probably wouldn't matter much in huge complicated optimizing cores those do make life a little bit more annoying for asm writers/emitters

But above all it's more that it appears at the right time in the right place - the way Linux "won" over other FOSS Unixes

@koakuma Register windowing actually looks really interesting if used right; it basically allows you to set up for subroutines and push a bunch of registers into storage and restore everything super quickly. But, of course, you could be silly and *not* use it, in which case you get p.much the same register count as RISC-V. Also, in Superintendent Chalmers' voice: "Yes, and you say that despite the fact that ARM does something similar."

Adding more instructions seems rather suspect IMO, since that could lead to fragmentation, which is a problem RISC-V has only recently solved.

I don't know what to say about Branch Delay Slots, but I hear it's some dark, evil magic that helps improve performance so uh, 🤷

@techokami Yeah, register windowing is very neat (at least from an user-mode asm writer perspective, it makes it so easy to set up prologues/epilogues)~

> Adding more instructions seems rather suspect IMO, since that could lead to fragmentation, which is a problem RISC-V has only recently solved.

Yes, but it also means that SPARC does not get to have any of the fun stuff like vector instructions or twinword atomics or other kinds of goodies that modern programmers have come to depend on for performance

Sure yes you can define a twinword encoding for all those extras but that would also mean that anyone who chose to use it will be punished by bad code sizes (and in reality the ISA died before any such effort got started so~)

> I don't know what to say about Branch Delay Slots, but I hear it's some dark, evil magic that helps improve performance so uh, 🤷

BDS is a thing that allows you to still have decent performance if your core lacks any predictors (like in tiny cores or transistor-limited 80s era chips), but if you do have one it mostly serves as an annoyance to asm writers (not to mention that oftentimes you have no choice other than to slot in a nop there).

@techokami i'm pretty sure it's lack of software support, compared to RISC-V

@koakuma @techokami also #UltraSparcT2 as cool as it was at release (including dual 10Gbit-NICs and hardware RNG on die) has a lot of things noone would want to deal with in 2024 (i.e. DDR2-FBDIMMs).

• Plus #RISCv unlike #SPARCv9 amd #OpenPOWER was designed on a clean slate in academia by people who had dealt with #RISC & #CISC architectures and needed something #OpenSource as they can't just violate NDAs nilly-willy for teaching.

Pretty shure @stman could write an entire curriculum on why #SPARC, #PowerPC, #s390x and even #ARM / #ARM64 should not be pursued and why #mc68k died alongside the unfixable-by-design mess that is #ix86 & #amd64.

• Plus RISCv's ISA has been an #OpenStandard from the get go, whereas the efforts by #Oracle nee #Sun and #IBM were mostly done in reaction to it and to keep the few invested licensees and co-designers onboard and not drop the platform entirely...

Look, I'd love to get my hands on some Sun SPARC Hardware but aside from making my room hot and noisy there isn't much to justify blowing likely over half a Euro per hour (electricity price: € 0,40/kWh) just to have it up and running, as compared to a #PiCluster like those @geerlingguy had built multiple times are more practical.

• For comparison: It's like driving a 2011 Ford CVPI-71 with a 11,9l SONNY'S SAR-729 engine for commuting from Leverkusen to Köln when there's ample of affordable, reliable and fast public transport that gets me faster from Opladen to Deutz than it takes to drive up the 15th deck of a parking garage just to find a spot to park that 5,7m long street yacht where one can climb out of it from the doors and not the trunk!

And that's just bottom-billing, low-cost ARM SoC tech designed for a price tag (to the point that until the #Pi5 they neither included a power button nor #RTC onboard!

• OFC RISC-V is still 5-25+ years behind #ARMv9 solely based off #patents, #budget and #PersonnelHours invested in it, so it's barely getting on-par with 10-20yr old ARM devices in terms.of power and support.

@getimiskon Linux has mainline support, as does OpenBSD

@kkarhan @koakuma @stman @geerlingguy wow uh, all I can say is that's a lot of hashtags and people. Also I have never seen anyone call the Motorola 68000 "mc68k", what does the C stand for?

@techokami @koakuma @stman @geerlingguy MC is the prefix for #Motorola Chips.

• Also I've seen it always abbreviated as #mc68k in #FLOSS...

@kkarhan @koakuma @stman @geerlingguy I've seen Debian and the BSDs mainly use m68k. Examples: https://wiki.debian.org/M68k https://wiki.netbsd.org/ports/
Which projects are calling it mc68k?

@techokami @koakuma @stman @geerlingguy seen it often enough

@kkarhan @koakuma @stman @geerlingguy also "Debian and the BSDs" would make a good band name

@techokami definitely less #cringe than "The #Azure Girls"!

https://www.youtube.com/watch?v=Zww2ivWdLas