std.Target: Remove more dead OS/architecture tags
#20870
Conversation
alexrp
force-pushed
the
target-cleanup-3
branch
2 times, most recently
from
e8e87bb to
f7bd88b
Compare
These were for very old OpenCL have been long abandoned in favor of SPIR-V. * https://github.com/KhronosGroup/SPIR * https://github.com/KhronosGroup/SPIR-Tools
What is `sparcel`, you might ask? Good question! If you take a peek in the SPARC v8 manual, §2.2, it is quite explicit that SPARC v8 is a big-endian architecture. No little-endian or mixed-endian support to be found here. On the other hand, the SPARC v9 manual, in §3.2.1.2, states that it has support for mixed-endian operation, with big-endian mode being the default. Ok, so `sparcel` must just be referring to SPARC v9 running in little-endian mode, surely? Nope: * https://github.com/llvm/llvm-project/blob/40b4fd7a3e81d32b29364a1b15337bcf817659c0/llvm/lib/Target/Sparc/SparcTargetMachine.cpp#L226 * https://github.com/llvm/llvm-project/blob/40b4fd7a3e81d32b29364a1b15337bcf817659c0/llvm/lib/Target/Sparc/SparcTargetMachine.cpp#L104 So, `sparcel` in LLVM is referring to some sort of fantastical little-endian SPARC v8 architecture. I've scoured the internet and I can find absolutely no evidence that such a thing exists or has ever existed. In fact, I can find no evidence that a little-endian implementation of SPARC v9 ever existed, either. Or any SPARC version, actually! The support was added here: https://reviews.llvm.org/D8741 Notably, there is no mention whatsoever of what CPU this might be referring to, and no justification given for the "but some are little" comment added in the patch. My best guess is that this might have been some private exercise in creating a little-endian version of SPARC that never saw the light of day. Given that SPARC v8 explicitly doesn't support little-endian operation (let alone little-endian instruction encoding!), and no CPU is known to be implemented as such, I think it's very reasonable for us to just remove this support.
This is a fairly small hobby OS that has not seen development in 2 years. Our current policy is that hobby OSs should use the `other` tag. https://github.com/zhmu/ananas
It's discontinued in favor of WASI. https://github.com/NuxiNL/cloudlibc
Revert this commit on the next glibc abilists update.
There was a problem hiding this comment.
Our current policy is that hobby OSs should use the
othertag.
Can you link to anything supporting that, and a rough definition for "hobby OS"? I think Haiku is widely regarded as one, and I have a feeling that the policy is actually looking at popularity :^)
I agree that some definitive wording to point to would be nice. In comparison, |
I do not know that we have an actual, objective definition. But see #3784. I think Ananas is an open-and-shut case, though. It's written in C, development has stalled for 2 years, and it only has 55 stars on GitHub. I think most would agree that it falls squarely in any reasonable definition of "hobby OS". It was only ever included in OTOH, Haiku seems to be actively developed and it seems to have an actual user base. For comparison, like Haiku, I didn't remove Hermit either. I think both of these have enough of a following that "hobby OS" is no longer an appropriate moniker. This is just my thinking, though; I don't know what Andrew considers a "hobby OS" in the context of #3784. |
|
Are |
They are mostly sorted according to the order they appear in LLVM. I assume it's done this way to make LLVM upgrades easier. I'd be fine with sorting them in a more 'sensible' way, but since Andrew is the one doing the LLVM upgrades, I'll defer to him on this. |
|
Regarding "other": this tag is intended to facilitate the use case when no other tag is appropriate. Maybe your OS did get added to the zig std lib but you're stuck on an old zig version for example. The policy about adding OS tags is that any active project is a candidate. If the project looks dead, it's fair game to remove; if the project looks alive, it's fair game to add. Old consoles should be kept because these are permanently alive thanks to emulator communities. In short summary, if any OS tag is desired, then it has a home in the std lib. Deleting a "dead" CPU arch or OS should never be controversial. And it's perfectly fine to sort them. |
Happened because I wrote ziglang#20869 before ziglang#20870.
Happened because I wrote ziglang#20869 before ziglang#20870.
Happened because I wrote ziglang#20869 before ziglang#20870.
See commit messages.