[LinuxBIOS] Via Epia-m and VGA Bios emulation

[Richard Smith]

>
> The emulator is also running nearly 3 million fewer instructions, which
> could be down to it doing fewer loop iterations whilst waiting for things to
> come ready, or could also be attributed to the bios giving up early.

Since you say that the emulator doesn't work.  I suspect that this is
probably because the emulator causes the bios to take a different
path.  A quick example would be the video memory check.  If that's not
up properly then its going to bail out in the first few tests where
the one that works would go through a lot more.

Also if things are failing then your emulator path may be doing tons
more work.  The legacy bioses I've worked with try to figure out what
type of adapter they are by what memory range will pass the video
check.  So if your video ram is failing the bios may be going and
checking for a VGA, then EGA, then CGA, and then Monochrome.

Until the emulator actually works I don't think this comparison will be valid.

> I am now working on the hypothesis that the emulator has to be faster if it
> is going to work at all for the epia-m, which means fewer instructions per
> emulated instruction. I have a few ideas which I intend investigating and
> trying out:
>
> 1) embed/inline the memory read/write and io functions directly where they
> are used rather than having trivial subroutines accessed via arrays of
> function pointers. I believe that this processor is easily stalled by jumps
> to subroutines, and so inlining these should help.

Again what version of the emulator are you running?  There was a lot
of work done to the emulator recently to reduce its size so it could
be included in the the boot image.  One of the major things was moving
a lot of the individual functions into one single function with
different arguments.  There were numerous other things done to reduce
the size so make sure you are looking at the latest codebase.

Size and speed used to be inverse of each other but now due to
instruction caches smaller can sometimes run faster than inlined
"speed" optimized code.   You seem to have a good setup for running
comparison tests to determine all this.  That will be good info to
have.   I don't think anyone has run any qualitative tests with hard
numbers on emulator performance.

The first step though is figuring out why the emulator is failing.

--
Richard A. Smith