Re: emulation has fewer bugs than certain hardware
> Some interesting points:
> - 68k emulation has been going on for more than 10 years.
Far more than that (10 years ago the 68k Macs were already being replaced
by PPC Macs, and a 68k Mac emulator was available for some time then (not
to mention Apple's own efforts )
> - http://www-gatago.com/linux/debian/ports/68k/34992877.html seems to
> indicate that even last year there was an MMU bug in ARAnyM (unstable)
> that was promptly fixed. This seemingly was when Linux was first
> starting to run on it. Another person at that link said Motorola also
Yep, running Linux on ARAnyM sure helped in showing up bugs. We cannot
necessarily conclude that there are no more bugs, though :-)
> made MMU mistakes though.
There's been broken 68LC040 revisions I know of. That's been exception
handling, not necessarily MMU related.
> - The discussion about adding emulated buildds has been going on for
> many years now.
We've only had working emulation for about a year now. The discussion on
cross-compiling has been going on for a lot longer.
> I think 10+ years of CPU instruction support (vMac, UAE, Basilisk(2)...)
> and a very responsive upstream emulator group make ARAnyM an attractive
> alternative when native hardware is too slow or not available. Even when
> native hardware is fast enough and available, emulation might provide
> additional benefits such as check-pointing.
Combine this with a good debugger / profiler, and we can work on the nasty
bugs like r-base hanging up the system.
> It is probably useful to compile things on a wide range of hardware in
> order to look for driver and hardware problems. That said, finding
> problems that are due to hardware failure are probably less useful. It
> is nice to know failure modes though. I guess ideally everything would
> get compiled on every sufficiently unique system including an emulator.
Ideally we'd have a massively parallel cluster of Amigas, Macs and Ataris
to do that. Right now, we'd be more than happy if additional machines
(real or emulated) could take up some of the backlog at times. We'd need
to prevent an emulated system attempting to build a CPU intensive package,
and for that we'd need a build time estimate up front. Not implemented
yet.
> Practically, some buildd related software would would need to be done to
> even use an emulator as a backup unless porters explicitly move hardware
> related failures?
Hardware related failures are usually resolved manually. For anything else
we'd need changes to the build system.
Michael
Reply to: