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
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:
- 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
sorry, I missed a lot of this thread.
The only thing I can say for sure about emulator vs. x86 real mode is that I don't see any differences in wall-clock-time speed, except in those cases where the emulator is faster.
We did take in some changes, from another project, to reduce memory footprint. I sometimes wish we had not -- I think every problem we've had goes back to those optimizations. It's a little frustrating, and I'm having trouble right now on the sc520 -- user mode testbios works fine, linuxbios emulator does not.
maybe once my problem is fixed, yours will be too ...
ron
had goes back to those optimizations. It's a little frustrating, and I'm having trouble right now on the sc520 -- user mode testbios works fine, linuxbios emulator does not.
:) such is life on the bleeding edge. Just keep repeating "short term pain for long term gain" to yourself.
Getting the emulator small, tight and in-kernel will be a really "Good Thing" (TM)
-- Richard A. Smith
Hello, Mr, Nick Barker.
Is that possible to make vga init routine to stand alone elf command? Like ---- [Fedora@Epia-m]# /usr/sbin/epia-util --vga-init --resolution 1024x768 ----
If this is possible, especially if this can be done in parallel while booting other daemons up in /etc/rc.* files, requirement for speed stuff would be reduced in some measure.
But, anyway, 7secs is too slow...
--- Okajima, Jun. Tokyo, Japan.
On Wed, 2005-10-19 at 13:59 +0100, Nick Barker wrote:
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
Did you try the user space testbios? As you probably have known, the VGA BIOS tend to poll some register to wait for some envent, usually this lead to the same wall-clock time.