I'm the student that contacted Miod and the one hosting these emails.
No one has questioned this, but I got Miod's permission before sharing.
I think his stance is reasonable. About a year ago, he converted the mips port to mips64 (lower case to denote the actual port names), removing MIPS32 support. If there were reasonably strong developer backing for a mips32 port, I bet it would happen. Obviously, a single curious undergrad doesn't qualify. Here's a great set of slides about this:
In regards to the Chromebook comment: there are MIPS Chromebooks in the pipeline. I remember digging through the relevant Linux commits looking for indicators of whether they'd be 32-bit or 64-bit, but I don't remember what I found.
See this email and the associated thread for more information:
Well, to be fair, he's right. 32-bit is only interesting in the embedded space. If you're running a "real" operating system, there is almost zero cost to running a 64-bit processor instead nowadays.
I'd go further than him, though. OpenBSD has limited resources. Those resources are better deployed on security enhancements which filter out to other operating systems that support less common architectures.
"Embedded" is too vague to use for this. Tons of STB's have SOC's with MIPS cores and Linux kernels (and uclibc). The cost could be the cost of the transistors used up by the CPU cores that could go to valuable functions like codec support. The cost could be RAM interface circuitry. The cost could be a dozen things and Linux is adopted in this category of system. It's almost like OpenBSD is defining itself as too good for use in economical, workaday products. I'm sure that would be a misunderstanding by me.
Any estimate how much the cost of the TLB management is compared to the cost of cache/memory clogging caused by carrying 64-bit pointers around all the time?
It's hard to say and would probably vary significantly depending on the workload. 64-bit pointers could theoretically take twice as much space, whereas TLB management, since the MIPS has a software TLB, is also expensive because the TLB interrupt handler needs to run, which means more icache usage (and also has effects on the instruction pipeline, comparable to any other interrupt.)
According to this[1] paper the fact, that you effectively double your data cache with 32bit pointers leads to a performance increase of up to 30% in real world applications. I don't believe the comparatively rare context switches caused by TLB management interrupts cause a speed penalty that high. Hence I still don't understand why people want desperately go to 64bit. Just because some kernel programmers find it too stressful to bother with some minor memory management details?
The Loongson 3 devices are hard to get, although apparently you can get them from China; the 2f devices are slow and a wierd version of mips, dont recommend.
The easy to obtain cheap Cavium is the erlite-3 but it has the most non standard usb which means you are pretty much stuck with a tiny amount of storage.
Soft cores are a bit slow, although have seen CHERI running and it is cool. (Risc-V runs NetBSD, at least partial port, not FreeBSD yet).
So there is no useful easily obtained dev device for under $200 (although Imagination did seem helpful on twitter on helping get stuff).
You can always try to use QEMU for OS development when a dev board is not available. The latest version implements Release 6 for 32- and 64-bit MIPS CPUs.
When it comes to development boards, we are working to expand the Creator family to include more options at the high- and low-end.
For those asking if MIPS is dead, my sincere answer is a loud no. We've had a record quarter in shipments, registered over 800m devices last year using the architecture (which represents a 10% increase YoY, by the way).
Tell them to get us a MIPS64 that we can afford. That way people can have their OS's that refuse to deal with MIPS32 issues. Maybe an insanely cheap Warrior core that gives people a taste of its capabilities but can't hurt Imagination's sales in servers/embedded due to configuration of board it comes with. A few benchmarks on that thing and open-source tool development might help increase adoption. Same with MIPS64 board in general though.
Meanwhile, people might have to play with soft-cores such as Plasma and Cambrige's MIPS64 BERI core. FreeBSD already runs on BERI, so that should help. Full cores are still way cheaper to license than ARM, too. ARM pricing is horrific and is about the ecosystem more than the CPU performance/cost.
Ah you were the person on twitter... All three main BSD projects could use hardware - all three support edgerouter lite3 but I think only FreeBSD has more useful hardware. Most of the NetBSD dev is on really old hardware. I am a NetBSD developer, can provide contact (email in profile).
Qemu is pretty annoying for development - it tends to emulate obsolete hardware and it is the drivers that takes time; we already have general architecture support, it is real hardware that is useful. Also qemu is not generally bug for bug compatible and it is slow. It is ok if you are paying someone, but giving away hardware is better to incentivize people who are doing something for free.
Speaking of 32-bit systems with small amounts of memory, is OpenBSD being used for / developed for embedded devices, especially IoT? Given IoT devices' security issues and their minimal OS feature needs, it seems like it could be a good fit and a great opportunity for OpenBSD. (But given my minimal understanding of both, I could be way off base.)
I posted it because I had no idea of this limitation (quirk?) of the MIPS32. I guess that's why the 64-bit R4000 (MIPS III instruction set) came pretty early in the 64-bit cycle.
I don't know anything about Miod, but my understanding is that OpenBSD devs work on what interests them. They don't feel any need to justify it beyond that. So if they have devs who want to maintain a VAX build, they will.
What the original post described was whether the project would consider picking up the end result of a student project and carrying it forward. Why would they do that?
maybe that a statement like "xxx is dead" is perhaps too much in line to the bully joke "bsd is dead" that was prominent from linux jocks many years ago, more mature nowadays and not seen that `joke` in a while myself (though don't read /. much these days either).
Also when the the CPU is still in use today in places, again hardly constructive and with that probably the glibness of the whole statement without qualifiers that found disfavour.
In the context of the conversation, it was a true statement about OpenBSD's supported platforms (mvme68k was discontinued in 5.5, mac68k in 5.1). Also, given the parent of the post was being a bit rude to a specific person, its an appropriate response.
Using the old slashdot troll against a BSD person is a new one.
> Also when the the CPU is still in use today in places, again hardly constructive and with that probably the glibness of the whole statement without qualifiers that found disfavour.
Its not in use by OpenBSD which is the topic of conversation
It is zero cost for linux kernel to just keep an optional feature and quite a problem for openbsd to accept and maintain another arch after that student is done with his project and moved on.
Well, it looks like the code would have to be special purposed unless they just didn't support over 512MB. I would imagine the work would be far in excess of what is normal. NetBSD tries to run everywhere. OpenBSD has retired some platforms.
No one has questioned this, but I got Miod's permission before sharing.
I think his stance is reasonable. About a year ago, he converted the mips port to mips64 (lower case to denote the actual port names), removing MIPS32 support. If there were reasonably strong developer backing for a mips32 port, I bet it would happen. Obviously, a single curious undergrad doesn't qualify. Here's a great set of slides about this:
http://www.openbsd.org/papers/ven05-niallo-uwe/slides.pdf
In regards to the Chromebook comment: there are MIPS Chromebooks in the pipeline. I remember digging through the relevant Linux commits looking for indicators of whether they'd be 32-bit or 64-bit, but I don't remember what I found.
See this email and the associated thread for more information:
https://marc.info/?l=openbsd-misc&m=144012041817764&w=2