Hi Andreas, > POWER and MIPS. > [...] > They won't be missed.
This is certainly not so here in my project where POWER and MIPS are the primary available options, and dropping them would be pretty much equivalent to discontinuing GEM5 altogether. What feels even more sad, is that I can see how the very presence of this discussion within the Overton window could be used by certain closed-source advocates to undermine our "community support" argument and thus try to weaken the position of not only our choice of GEM5 but some neighbouring open-source choices as well. > users submitting patches for them This one should easily exclude MIPS and POWER from candidates for phasing out, well at least I do submit MIPS and POWER patches which get merged into origin. > Ecosystem: We should phase out ISAs that don't have compiler > support. Being able to run code isn't very useful if you can't > compile code for the platform. True; and the above's implied connection to MIPS and/or POWER, sounds disturbing to me. Unless we assume a Redmond-like position that there is one OS and one compiler and one software stack (based on an 80% bell curve argument?), different people do different things and so the definition of "compiler support" varies from project to project. For example, in retargetable compilers (which is what I am interested in) there is more than a single project based on ArchC processor descriptions, and in that world, it's pretty much a three-ISA world of ARM, MIPS and POWER. I certainly hope SPARC to be equally usable soon too, but right now it's just barely limping; Alpha, yes there is a one-in-a-million chance; RISC-V, that's a very sweet dream indeed; and x86 seems even less likely. So yeah, three ISAs with compiler support that I could use, and like I said above, losing two of the three would not be much different from giving up on GEM5 altogether. > We should phase out ISAS that don't support full-system > unless there is a clear plan to add that support. > (The NULL ISA is an exception) > Users expect to be able to run an OS if an ISA is supported. From my chair it appears like this: In another kingdom far away, there are those other people doing those other extremely exciting things (including FS). For me, the catastrophic showstopper was broken remote debugging (gdb failing to even initiate the session) on every platform I tried, so I had to fix that. This was the majority of the defining discriminator between "working" and "not working"; FS didn't even enter into the picture. On the other hand, I do completely agree with you about functional verification: I need to run a tall enough software stack (such as an OS kernel) to believe in the simulation. But I can have enormous stacks completely in SE. E.g. Java would serve as a good illustration (not that's what we use here) of such a huge SW stack having no relation to FS. I guess our situation here, is similar across the board: there is Jakub's system on SPARC which is obviously tall enough but not quite ready yet; then there is our stack which isn't there yet; and then I wouldn't be surprised to learn about other people with nontrivial workloads which are not the FS Linux kernel. > It reduces confusion among users. Having a handful of architectures > that are clearly incomplete and don't support full-system is not > very helpful to anyone. Does enabling projects which result in new compilers being written and papers being published in journals, count as helpful? A number of these things definitely wouldn't have happened if GEM5 lacked MIPS and PPC. Boris _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
