Re: OpenBSD MIPS32 Support(sccs.swarthmore.edu)
sccs.swarthmore.edu
Re: OpenBSD MIPS32 Support
http://www.sccs.swarthmore.edu/users/16/mmcconv1/others/miod-mips32.txt
6 comments
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.
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.
The cost of an SoC is almost insensitive to the size of the CPU core. Only RAM and Flash matter.
I'm not joking, here's an STM32F103VGT6 (Arm Cortex M3--not even an A-series which you normally use to run Linux). https://en.wikipedia.org/wiki/File:STM32F103VGT6-HD.jpg
Note that this is a little flash heavy (1MB) but pretty mainstream with RAM (96KB).
The RAM and flash absolutely DWARF the core. You could double the size of the core (32 to 64 bit), and that would still be true.
The writing is on the wall for 32-bit on anything running a "real" operating system.
I'm not joking, here's an STM32F103VGT6 (Arm Cortex M3--not even an A-series which you normally use to run Linux). https://en.wikipedia.org/wiki/File:STM32F103VGT6-HD.jpg
Note that this is a little flash heavy (1MB) but pretty mainstream with RAM (96KB).
The RAM and flash absolutely DWARF the core. You could double the size of the core (32 to 64 bit), and that would still be true.
The writing is on the wall for 32-bit on anything running a "real" operating system.
The OpenBSD project will not (cannot) prevent you from developing your own mips32 port.
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?
[1] http://www.sciencedirect.com/science/article/pii/S1877050913...
[1] http://www.sciencedirect.com/science/article/pii/S1877050913...
It would be nice if MIPS produced a nice 64 bit development board.
There's always the Loongson devices:
https://en.wikipedia.org/wiki/Loongson
They have quite a bit more support in FOSS than Cavium's Octeon processor boards. Which are also cool:
http://www.cavium.com/OCTEON-III_CN7XXX.html
CHERI project modifies open-source BERI core on Terasic device:
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
Note: Barely gets more open and extensible than that outside RISC-V, etc. Those don't run FreeBSD, IIRC.
So, MIPS is far from dead even if MIPS32's limitations sucked. :)
https://en.wikipedia.org/wiki/Loongson
They have quite a bit more support in FOSS than Cavium's Octeon processor boards. Which are also cool:
http://www.cavium.com/OCTEON-III_CN7XXX.html
CHERI project modifies open-source BERI core on Terasic device:
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
Note: Barely gets more open and extensible than that outside RISC-V, etc. Those don't run FreeBSD, IIRC.
So, MIPS is far from dead even if MIPS32's limitations sucked. :)
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).
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).
Regards, Alex.
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).
Regards, Alex.
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.
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.
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.
I'll see what I can do in terms of sending a few boards. Will ping you an email shortly.
Thanks for reality check on 2f and Cavium's USB. Good to know those limitations.
"Soft cores are a bit slow, although have seen CHERI running and it is cool."
You can put it on an Achronix to get around 1.4GHz potential speed. They're only $10,000. So much more reasonable than an ASIC with same specs!
http://www.achronix.com/products/speedster22ihd.html
Mortgage your house and buy one now before they get acquired. ;)
"Soft cores are a bit slow, although have seen CHERI running and it is cool."
You can put it on an Achronix to get around 1.4GHz potential speed. They're only $10,000. So much more reasonable than an ASIC with same specs!
http://www.achronix.com/products/speedster22ihd.html
Mortgage your house and buy one now before they get acquired. ;)
I don't think MIPS exists anymore. They were bought a few years back by Imagination (the makers of PowerVR GPUs used in mobile devices).
Yeah, the Mips bit of Imagination then.
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.)
Why is this on the front page?
Well maybe for the entertainment value or the aspect that Theo was not involved in the exchange. But probably the best highlight for me was:
In the year 2015, it is a complete nonsense to produce new 32-bit system designs. It's the new ``640KB of memory will be enough for everybody''.
> Also, would it change your mind if Google starting releasing 32-bit > MIPS Chromebooks?
Of course not. They can release crap hardware if they want to, this doesn't mean we have to support it.
In the year 2015, it is a complete nonsense to produce new 32-bit system designs. It's the new ``640KB of memory will be enough for everybody''.
> Also, would it change your mind if Google starting releasing 32-bit > MIPS Chromebooks?
Of course not. They can release crap hardware if they want to, this doesn't mean we have to support it.
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.
There's a workaround called Enhanced Virtual Addressing (EVA) that was added in revision 3.5 of MIPS32:
https://marc.info/?l=openbsd-misc&m=144012041817764&w=2
I don't know whether it's a realistic solution, though.
https://marc.info/?l=openbsd-misc&m=144012041817764&w=2
I don't know whether it's a realistic solution, though.
Remember, this is Miod.
Ask him why they support VAX still.
Or his 68k side projects.
Or contrast it with how Linux is managed:
https://lkml.org/lkml/2015/1/20/50
https://lkml.org/lkml/2015/1/20/50
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.
I hope you're not implying from that reference that Linux is managed better.
Who knows how much test coverage they even have for odd architectures in Linux. Just because they say it's "supported" means nothing.
Who knows how much test coverage they even have for odd architectures in Linux. Just because they say it's "supported" means nothing.
I was first and foremost thinking about the style of communication and the friendly attitude.
I just thought it was worthy of comparison.
I just thought it was worthy of comparison.
because they find bugs and keep cleaner code?
and MIPS32 wouldn't?
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.
68k is dead.
Don't know why your getting downvoted since OpenBSD killed the 68K port in 5.1.
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.
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
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
I've been writing m68k asm code and building gcc-based toolchains until two months ago for the computer architecture exam.
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?
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?
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