Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: 8086 instruction exerciser

  1. #11
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,006
    Blog Entries
    18

    Default

    I meant an 8086 licensed from Intel. Remember the Intel vs. NEC copyright lawsuit? The V20 doesn't execute some x86 instructions the way a real 8088 does, but it didn't seem to hurt sales. Similarly differences in the way shift counts are treated in the 8086 vs. everything else didn't seem to bother anything when later CPUs came along.

    The more interesting question is "can one emulate an 8086 not only with respect to instructions, but also with respect to real-world timing?" In other words, can your emulated 8086 run at precisely the same speed as an 8 MHz 8086?

    I'm not optimistic about that one. However, there is an FPGA implementation of an 8086/8088 running at 4.77 MHz. It's apparently done by running a simple 7-instruction 32-bit core at 100MHz. He claims it as a drop-in replacement and offers BIU modules for both the 88 and 86.

  2. #12

    Default

    Quote Originally Posted by Trixter View Post
    The search space can be reduced considerably by using bit patterns commonly used for memory testing: 55h, CCh, 00h, 01h, FEh, both by themselves as well as rotated 0-15 times as appropriate (ie. there's no point in rotating 00/FF, or CC more than 3 times, etc.).
    The existing 8080/Z80 exercisers use a "test vector" (instruction bytes, register values including flags, a memory operand) and two additional vectors: One which is combinatorically explored, and one where every bit is flipped once. So a trade-off between coverage and execution time is possible. On the other hand, I think that covering the complete (relevant) search space is necessary to some extent: The 8080 exerciser was still able to uncover bugs even after all contemporary test programs were happy (the aux carry flag is hard to get right).

    Quote Originally Posted by Trixter View Post
    If you did this, you could test every opcode, not just the ALU.
    I do not aim for complete opcode coverage. Some instructions must work for the exerciser to successfully work in the first place (e.g. JMP, Jxx), others depend on the envonment (e.g. I/O, INT/IRET) or behaviour beyond the application (e.g. TRAP flag). Also, the existing exerciser structure does not work well for most addressing modes.

    Quote Originally Posted by daver2 View Post
    Practically, you would either use a statistical testing method or break the problem down into smaller 'blocks' assuming that the blocks didn't interact too much (if at all).
    I have looked at a few emulator designs, but am by no means smart. My approach is strongly table-driven, trying to unify as much of the instruction behaviour. Others approaches treat each opcode separately, implementing similar behaviour in many places (either manually or through macros). Then, there are JIT approaches, which generate code at runtime, possibly fusing instructon groups. All of these cases will result in different degrees of interaction between blocks.

    Quote Originally Posted by daver2 View Post
    It would be good for someone to come up with an x86 validation test I must admit...
    I don't think that is feasible. The x86 space is far more varied than the 8080/Z80 space is, and behaviour varies a lot between vendors and implementations (e.g. CPUID or RDTSC). Specifically, I only care about a subset of 16-bit real mode - and trying to ignore implementation differences.

    Quote Originally Posted by Trixter View Post
    Is the goal of the 8086 exerciser to find bugs in emulation?
    Partly. The main goal is aiding the implementation of an emulator. I wouldn't be surprised to uncover bugs in existing emulators, either. My main project requires an x86-compatible CPU core to run a few DOS applications in a restricted environment. I do not plan on being PC-compatible (not more than necessary) or to even support evil software tricks - there are other projects better suited (PCem comes to mind). Basically, some form of DOSBox tailored to my specific needs.

    Quote Originally Posted by Trixter View Post
    If so, then you'd need more than an ALU opcode tester. For example:

    REP with segment overrides doesn't resume properly after an interrupt
    POP CS is possible on 8086
    Interrupt behavior after MOV SS vs. MOV any_segment_register
    Behavior of 8D C2 ("LEA AX, DX") (See Raúl Gutiérrez Sanz's comments here: http://www.os2museum.com/wp/undocume...ge-1/#comments )

    ...etc.
    I agree, but none of these behaviours are easily testable within the existing exerciser framework. Also, they test for very specific behaviour of the 8086, which is only useful if you want to accurately emulate that very specific processor including all of its quirks. Software written to run on x86 (rather than 8086 or "IBM 5150") should not rely on these behaviours at all. Also, I will exclude any attempt at testing timing behaviours or limitations with self-modifying code (outside of the exerciser itself, that is).

    Quote Originally Posted by Chuck(G) View Post
    I suspect that you're not interested in a stress test, as you're working with an emulator.
    No, although I will need to be able to run the exerciser on a real machine in order to get "known good" results. I won't be able to test on a true 8086 either - only a single 80186 and 80486SX each (possibly an 80486SL if I get the machine to work).

    Quote Originally Posted by Chuck(G) View Post
    How about Sandsifter for exposing non-documented features? Run it on a "real" 8086, then run it on your emulator. Compare results.
    The approach taken by Sandsifter relies on invalid instructions and page faults, neither of which exist on 8086/80186. Again, this is interesting and useful work if one wants to recreate a "true" CPU, but this is not my goal.

    Quote Originally Posted by Chuck(G) View Post
    The more interesting question is "can one emulate an 8086 not only with respect to instructions, but also with respect to real-world timing?"
    I don't see any reason why this shouldn't be possible. Technically, it should be feasible to simulate the whole PC platform as a whole, starting from the 14.3 MHz main crystal by now.

    Quote Originally Posted by Chuck(G) View Post
    In other words, can your emulated 8086 run at precisely the same speed as an 8 MHz 8086?
    Nope, not even trying. The emulator is far from done (hence this side-project), but I already now know that the Trap Flag does not behave correctly. Also, any undefined or FPU instruction (including POP CS) will instantly kill the core and additional inaccuracies will definitely appear as well.

    My 8080 core was originally written in AVR assembly. That version fits into 3 KB of flash memory and should run about as fast as a 2 MHz 8080 (which I cannot verify). If I can squeeze an 8086/80186 core into the same size region, it could be used to run an original VGA BIOS...

  3. #13
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,006
    Blog Entries
    18

    Default

    I'm having a bit of trouble determining your real objective, please forgive my density.

    Why not use the DOSBox code as a starting point, if you want to emulate a complete PC or part thereof?

  4. #14
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,001
    Blog Entries
    1

    Default

    Quote Originally Posted by Svenska View Post
    I do not aim for complete opcode coverage
    ...
    I only care about a subset of 16-bit real mode - and trying to ignore implementation differences
    ...
    My main project requires an x86-compatible CPU core to run a few DOS applications in a restricted environment. I do not plan on being PC-compatible (not more than necessary)
    Your stated goals conflict with the whole point of writing an opcode exerciser (to be as accurate as possible). Why not just fork DOSBOX and be done?
    Offering a bounty for:
    - The software "Overhead Express" (doesn't have to be original, can be a copy)
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  5. #15
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,006
    Blog Entries
    18

    Default

    Well, while an AVR might be a decent choice for an 8080 emulator, I'm not sure that it's the best fit for an 8088 with its preponderance of 16-bit operations.

    MOHO only.

  6. #16

    Default

    Quote Originally Posted by Chuck(G) View Post
    Why not use the DOSBox code as a starting point, if you want to emulate a complete PC or part thereof?
    Because DOSBox misses a crucial functionality (SHARE support without booting DOS). It cannot be implemented easily either.

    Quote Originally Posted by Trixter View Post
    Your stated goals conflict with the whole point of writing an opcode exerciser (to be as accurate as possible).
    Please look at the existing exercisers, their use and limitations. Neither suffices in fully reproducing their targeted CPUs, yet they are extremely valuable tools when implementing emulators for said CPUs. On the other hand, it is impossible to accurately exercise all opcodes without also requiring the complete environment within which the CPU operates. Especially from within the system itself.

    The requirements of my main project (i.e. the emulator itself) are independent of the exerciser. If there was a good way to verify that I did not **** up the flag handling (as an example), then I would not need to bother in the first place - see the original post.

    Quote Originally Posted by Trixter View Post
    Why not just fork DOSBOX and be done?
    Because it isn't that easy. Also, where'd be the fun? The prototype (which runs CP/M) consists of a 23 KB executable and requires 260 KB of memory.

    Quote Originally Posted by Chuck(G) View Post
    Well, while an AVR might be a decent choice for an 8080 emulator, I'm not sure that it's the best fit for an 8088 with its preponderance of 16-bit operations.
    It wouldn't need to be fast to be useful. After all, the VGA BIOS is mainly used for initialization and modesetting. The alternative involves tracing the hardware accesses and reproducing them within the AVR - which is always card-specific.

  7. #17
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,006
    Blog Entries
    18

    Default

    I'm still having trouble sussing out your eventual goal. But good luck with whatever it is.

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •