Kevin Lyda wrote:
Regarding the "less architecture support to save electricity"
argument, I'm not sure one follows the other. Computing power has
grown to a point that emulators are perfectly valid - particularly for
older systems.
I think a push to package and maintain emulators for many of these
older architectures would be beneficial in many ways. There's some
amount of this already - there are instructions for the simh simulator
for the VAX arch for instance. The obvious benefits I couldd see would
be:
1) You could spin up builds on them w/ little to no effect on electricity usage.
2) Even if the OpenBSD foundation's arch X machine dies, there would
still be infrastructure to maintain the port.
3) It would widen the possible number of developers if people could
spin up older architectures in an emulator.
4) It would make OpenBSD a valuable tool for accessing older media and
documenting older architectures.
I know emulators are not perfect, so a physical machine would be
superior. But if there was some encouragement for emulators for archs
I think those would be useful benefits.
Even if emulators did work, you still have a couple of problems:
*Instructions are executed as they should, not how they actually work
*instructions will, at best, take a two instructions on the host if
the architectures and endianness match; if not:
The instruction has to matched against a lookup table and if there
is a single equivalent instruction to do the same thing and you have
the same endianness, that is three processors cycles. If its
different endianness, then you now have between 32 and 128 more
instructions (convert to the host endianness then back for 16 to
64-bit archs)
Now if there isn't an equivalent instructions (welcome to the
difference between CISC and RISC machines) you are probably going to
have to run two all the way up to a couple dozen instructions to
emulate just one, plus you still have the same problem with
endianness like before
*assuming all the above works, you are still tripling the effort in
debugging because now you have to determine if the bug is in the
emulated environment, the emulator itself, or the host OS.
*Even if the above still works perfectly, you will still miss all the
bugs caused by memory alignment (the host will fix any of that), which
are the most common we find or the host ends up adding new ones.
But all this is ignoring the real purpose of running on real hardware
which is that the same code runs on all the boxes, so if one of them
outputs something unexpected from the other machines, we know something
is wrong.
The only way to reduce our power for the older archs is if someone were
able to re-build the entire system on more power-efficient,
bug-compatible chips
Support for multiple archs brings interest and exposes bad code in
ways limited arch support does not.
Exactly
Dropping that to save electricity
is not a valid reason with today's compute power.
Anyway, it's been a long time since I did stuff with OpenBSD, but I
think it would be a shame to drop such support. So I'll back up my
words with some cash. And if I get a roundtuit, perhaps some code or
docs as well.
Please continue to do this. Cash, code and correct docs help OpenBSD,
dreaming doesn't.
Kevin
And now to paraphrase Theo:
Shut up, donate, and hack.
