[LinuxBIOS] Via Epia-m and VGA Bios emulation

Nick Barker nick.barker9 at btinternet.com
Wed Oct 19 14:59:01 CEST 2005


I now have some more information on running the VGA bios through the
emulator on the epia-m

I have implemented both real mode and emulated VGA initialisation. The real
mode brings up the vga properly, whilst the emulation does not. The emulated
version runs to completion and also returns with Carry Flag set which I'm
assuming means that it has given up trying.

Using TSC, a performance counter set to count instructions, and a simple
instruction counter in the main loop of the emulator, I have come up with
the following statistics for the vga initialisation sequence:

Real Mode
---------
CPU Clocks = 691,530,971    (600Mhz processor = 1.1 seconds approx)
Instructions executed = 16,481,875

Interestingly this gives a clocks/instruction ratio of about 43, which we
can put down to intensive I/O and which must stall the processor by many
clock cycles per I/O.


Emulation mode
--------------
CPU Clocks = 4,618,464,706   (= 7.7 seconds approx)
Instructions executed = 1,946,308,181
Emulated instructions = 13,756,300

This gives us 2 ratios of interest:
Average clocks per instruction = 2.37 (much less than real mode since the
emulation is much more memory intensive)
Average instructions per emulated instruction = 141

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.

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.

2) hard code the emulator memory base at 0, so that this addition is avoided
on every memory access (since linuxbios always sets it at 0 anyway)

3) Implement the primitive operations in assembler - as has been done in
prim_asm.h for the Watcom compiler, but this time for gcc

4) Investigate the emulated repeat move string operation to see if this is
done efficiently by the emulator

etc....

Nick Barker





More information about the coreboot mailing list