On Fri, Jan 17, 2014 at 8:23 PM, Christopher Ahrens <n...@leviacomm.net> wrote: > *Instructions are executed as they should, not how they actually work
That's a bug to be filed against an emulator. And it's easier to do that *now* when the older hardware is around to test for bug compatibility. And it's not full emulator if it doesn't emulate the bugs. > *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) All true, but kind of meaningless for faster newer machines. Following Moore's law, a current machine is likely at least 256 times faster than a 12 year old machine. And nearly every older architecture has a machine that is 12 years old. If supporting older architectures for the full lifespan of that arch you're going to get to a point where all the hardware versions of that machine are in production. You'll eventually have a choice between an emulator or nothing. The last machine of arch X running OpenBSD will not be running on the OpenBSD Foundation racks. And note I'm talking about emulators, not architecture optimised virtual machines. They're probably not ideal for coding device drivers (and even that's not completely true), but they're fine for doing userland and higher level kernel development. You'll find endianess, alignment, cross-arch pointer and int/float size bugs with an emulator just as easily as you can with hardware. The two remote bugs that were found in OpenBSD were both ones that were high enough up the stack that they could be debugged / hacked at on an emulator. And as machines get faster/cheaper you'd have the option of running a small network and run network fuzz testing within a single machine. And I must admit the resistance to this is weird. My point was that the "use less electricity means less ports" argument was wrong. That emulators provide a way forward with all architectures that *increases* developer interest (unlike removing them with reduces it). I'm not saying switch to all emulators all the time for all development *today*, I'm saying think about going that direction now when it's easier (hw bug compatibility testing, etc). It's a lot easier to ask for $X/year if there's a plan for X to reduce. Emulators are hardly some radical view - this is exactly what OpenBSD supports and advertises for the oldest hardware it supports. Am I really saying something new by pointing out to all older archs, "this is your future"? > Please continue to do this. Cash, code and correct docs help OpenBSD, > dreaming doesn't. Yelling at the forward march of time doesn't help either. Diodes don't live forever. Kevin -- Kevin Lyda Galway, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
