Register windows and register files are the same thing.
Most RISC architectures have eschewed the register windows in favour of the register files coupled with the register renaming though.
Silicon is «wasted» (debatable) in high-performance CPU designs employing the register files but can be saved in low-cost designs by not implementing a register file at the performance penalty cost. Same is true for the designs with register windows.
The difference between the two is that with the register window the onus of tracking the dependencies in the data flow in registers is explicitly on the compiler (or on the developer) whereas with the register file the onus is on the CPU to track the dependencies, apply heuristics, allocate shadow registers from the register file, rename the in-use registers onto the shadow registers and vice versa.
Modern high-performance CPU implementations that do not employ the register windows typically come with large or very large register files (100-300 circa registers are common).
Calling register files (or register renaming) the same as register windows, is a significant stretch.
Renaming is important for OoO execution, register windows were used (in the original risc and sparc) to paper over the lack of a good register allocator. Later EPIC used a variant of it for software pipelining.
I'm confused about what is called modern here and why.
In any case I (and I am sure the vast majority) of consumers and application developers (system developers are of course in a different position) doesn't care one bit about the inner workings until some inherent security flaw like SPECTRE arises.
For pure performance per dollar, and even in terms of energy consumption, AMD64 CPUs are still doing great, and you don't have to worry about something not being ported yet because it's the defacto standard outside of phones and certain niches like automotive, etc; I couldn't care less about ARM in terms of compute for a workstation, gaming computer, or server, especially with things like QAT and various other accelerators.
What I really do care about, though, is all modern x86/AMD64 platforms are super complex and super proprietary; I have no way to trust them. And while ARM may not be quite as crazy as x86, it is pretty much just as proprietary, and so it doesn't solve my issue of being able to trust the hardware and firmware, or tinker with design.
RISC-V is cool. But going back to trust, it is a mountain of work to bootstrap from "bare metal" (UEFI or whatever else) on x86/AMD64 alone -- C++ has been my enemy; virtually everything ends up depending upon having a working C++ compiler at some point in the chain, including LLVM and any version of GCC not at least a decade old.
This means either cross-compiling GCC/LLVM for RISC-V from another system [which is problematic if you don't have a way to cross-compile from something already trusted and reproducible], or backporting/implementing RISC-V support into a ton of software.
Meanwhile, POWER has been around; it may not be as well supported as x86, but I think it's still far easier and significantly more realistic if you want to build a more-or-less trustable, reproducible system.
Plus, outside of root of trust paranoia, again, it's just far more realistic IMO as a workstation, server, or whatever else because of that much larger existing catalog of working software; you can get your proprietary Nvidia drivers for POWER if you want them, but I don't think they have any intention of supporting RISC-V.
Also, in general, I'm not totally convinced RISC-V offers significant enough improvements over POWER to really justify it. Maybe someone more familiar with RISC-V could offer compelling reasons that I'm not aware of, though.
EDIT: Lastly, RE: wasting silicon, there is also the aspect of "wasting" money and R&D building competitive designs relative to existing stuff -- I don't know when I'll be able to get my hands on a fast RISC-V system.
Probably fair about SPARC. I'm not familiar enough to have any real informed opinions about it. I've heard a fair bit of complaints about painful quirks, though. I guess one cool thing SPARC has had for a long time is memory tagging -- not sure if anything else other than ARM does, but I'm not sure how ARM's implementation compares to SPARC ADI [1].
I don't know of anyone really making modern SPARC designs either, though; pretty sure Fujitsu is focused on ARM now, and I don't know if Oracle is doing anything really, and I'm not super sure, but although Elbrus has built-in x86-translation of all things, I'm not sure any of MCST's relatively recent stuff can still run SPARC binaries.
I think SPARC mostly still alive because of legacy enterprise stuff and because there are existing radiation-hardened designs like LEON that get used for satellites and things like that [2], also I think MCST still produces some of their older SPARC stuff for Russian missile systems [3] since I imagine it takes forever for older stuff to get fully phased out and replaced entirely
> I don't know of anyone really making modern SPARC designs either,
Development seems pretty dead now. Maybe some telco-grade stuff, but that seems to be the whole of it. Not sure how long it'll last.
Unless I'm very wrong, their last releases were in 2017: the SPARC M8, T8 and Fujitsu's SPARC XII. It seems to have found a home in weapon systems though.
