
Re: OpenBSD MIPS32 Support - protomyth
http://www.sccs.swarthmore.edu/users/16/mmcconv1/others/miod-mips32.txt
======
mmcco
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:

[http://www.openbsd.org/papers/ven05-niallo-
uwe/slides.pdf](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](https://marc.info/?l=openbsd-
misc&m=144012041817764&w=2)

------
bsder
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.

~~~
cardiffspaceman
"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.

~~~
bsder
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](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.

------
sprash
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?

~~~
userbinator
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.)

~~~
sprash
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...](http://www.sciencedirect.com/science/article/pii/S1877050913005371)

------
justincormack
It would be nice if MIPS produced a nice 64 bit development board.

~~~
nickpsecurity
There's always the Loongson devices:

[https://en.wikipedia.org/wiki/Loongson](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](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/](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. :)

~~~
justincormack
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).

~~~
alexvoica
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.

~~~
justincormack
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.

~~~
alexvoica
I'll see what I can do in terms of sending a few boards. Will ping you an
email shortly.

------
hackuser
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.)

------
maaku
Why is this on the front page?

~~~
Zenst
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.

~~~
FreeBaSeD
Remember, this is Miod. Ask him why they support VAX still. Or his 68k side
projects.

~~~
tedunangst
68k is dead.

~~~
protomyth
Don't know why your getting downvoted since OpenBSD killed the 68K port in
5.1.

~~~
Zenst
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.

~~~
protomyth
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

