"Complete exercise" of x86 example?

I am in need of a block of code that completely exercises the 8086 16-
bit instruction set (excluding 8086-specific and intel-specific quirks
such as POP CS and AAD/AAM with custom operand). While I can try to
go through the intel manual and code it up myself, I only consider
myself a novice at assembler and I'm afraid I would either miss
something, or screw up a lesser-known addressing mode, or some other
misstep.

I have a few BIOS listings that claim to test the CPU as part of POST,
but again I'm worried they aren't complete enough (or more accurately,
I would not be able to tell if they are complete enough).

Is there such a block of code in the wild somewhere that someone can
point me to?

On Aug 1, 11:26*am, Jim Leonard <spamt...@crayne.org> wrote:
> I am in need of a block of code that completely exercises the 8086 16-
> bit instruction set (excluding 8086-specific and intel-specific quirks
> such as POP CS and AAD/AAM with custom operand). *While I can try to
> go through the intel manual and code it up myself, I only consider
> myself a novice at assembler and I'm afraid I would either miss
> something, or screw up a lesser-known addressing mode, or some other
> misstep.
>
> I have a few BIOS listings that claim to test the CPU as part of POST,
> but again I'm worried they aren't complete enough (or more accurately,
> I would not be able to tell if they are complete enough).
>
> Is there such a block of code in the wild somewhere that someone can
> point me to?

I can think of two candidates at the moment:

1) Take a look at 'test-i386.c' (and related files) here:
http://svn.savannah.gnu.org/viewvc/t...sts/?root=qemu

2) Randy's 'testsuit' for HLA:
http://hla-stdlib.svn.sourceforge.ne...av1/testSuite/

Nathan.

On Fri, 1 Aug 2008 08:26:35 -0700 (PDT), Jim Leonard
<spamtrap@crayne.org> wrote:

>I am in need of a block of code that completely exercises the 8086 16-
>bit instruction set (excluding 8086-specific and intel-specific quirks
>such as POP CS and AAD/AAM with custom operand). While I can try to
>go through the intel manual and code it up myself, I only consider
>myself a novice at assembler and I'm afraid I would either miss
>something, or screw up a lesser-known addressing mode, or some other
>misstep.

Why?

To 'completely exercise' all the instructions in a 8086 would take
quite a few megabytes of code, and quite a lot of time.

Opcode 0x00, for example has about 4,735,232 (assuming I did the math
correctly) possible variations, not counting register setup and
results checking (which might be 5 or 6 instructions per), if you were
to "completely exercise" it. Not all opcodes are that bad, though.

Hmmm, that number is low. All possible variations is closer to
257,943,784,696 including all possible operand values and all possible
memory values, but NOT counting possible register values, which would
add several more orders of magnitude to the final value.

>I have a few BIOS listings that claim to test the CPU as part of POST,
>but again I'm worried they aren't complete enough (or more accurately,
>I would not be able to tell if they are complete enough).
Those usually only test to see if the cpu is there, and the registers
appear to not have any bad bits, and usually not much else.


>Is there such a block of code in the wild somewhere that someone can
>point me to?
???
--
ArarghMail807 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

Jim Leonard wrote:

> I am in need of a block of code that completely exercises the 8086 16-
> bit instruction set (excluding 8086-specific and intel-specific quirks
> such as POP CS and AAD/AAM with custom operand). While I can try to
> go through the intel manual and code it up myself, I only consider
> myself a novice at assembler and I'm afraid I would either miss
> something, or screw up a lesser-known addressing mode, or some other
> misstep.

> I have a few BIOS listings that claim to test the CPU as part of POST,
> but again I'm worried they aren't complete enough (or more accurately,
> I would not be able to tell if they are complete enough).

> Is there such a block of code in the wild somewhere that someone can
> point me to?

you may find 8086 code in really old BIOS and very early DOS versions.
I once started with disassembling DOS3.1 and 286-BIOS and learned at
least the usage of common instructions.
A complete set of all possible instruction variants and addressing
modes will rare occure within one single code block, therefore I
made myself a testfile to check my own tools. It had no functional
sense, it was just a shortened binary list of valid opcodes.

16-bit code doesn't have too many addressing modes,
just four groups of eight, where the first group mean registers
and the other three memory operands [w/o, 8-bit, 16-bit displacements].

in the CPUs order:
r/m mod=11 mod=00 mod=01 mod=10
000 AL AX DS:[BX+SI] DS:[BX+SI+s8] DS:[BX+SI+d16]
001 CL CX DS:[BX+DI] ... ...
010 DL DX SS:[BP+SI]
011 BL BX SS:[BP+DI]
100 AH SP DS:[SI]
101 CH BP DS:[DI] ... ...
110 DH SI DS:[mem16] SS:[BP+s8] SS:[BP+d16]
111 BH DI DS:[BX] DS:[BX+S8] DS:[BX+d16]

(dots mean I'm lazy)
almost all general purpose instructions can use all of the above for
destination and/or source, but only one memory operand is possible.

So you got only 2(byte/word)*32*24 = 1536 basic variants in 16 bit code.
But then there are some possible segment override prefixes.
(086 ? ...286 had four segment-registers, 386 and above got six)
This means several thousand lines just for all ADD-instructions.

And the number may grow beyond imagination when prefix bytes 66/67
for 32-bit operand-size and/or 32-bit address-mode join in (+386).

More practical is to just remember the basic rules of the story and
forget about a complete (phone book sized) list of all variants.
__
wolfgang

On Fri, 01 Aug 2008 19:35:04 -0500, ArarghMail807NOSPAM
<spamtrap@crayne.org> wrote:

<snip>
>
>Hmmm, that number is low. All possible variations is closer to
>257,943,784,696 including all possible operand values and all possible
>memory values, but NOT counting possible register values, which would
>add several more orders of magnitude to the final value.
>

All possible variations is closer to 2.31492071519263D+18 when you add
in all possible register values. :-)

Some opcodes are worse. :-)

<snip>
--
ArarghMail807 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

On Aug 1, 7:35 pm, ArarghMail807NOSPAM <spamt...@crayne.org> wrote:
> Why?

I'm writing an x86 benchmark. It is for a very specific purpose, so
please no discussion of how all benchmarks suck :-)

> Hmmm, that number is low. All possible variations is closer to
> 257,943,784,696 including all possible operand values and all possible
> memory values, but NOT counting possible register values, which would
> add several more orders of magnitude to the final value.

No, no, I just need to test each opcode once per addressing mode, not
once for every single valid value it can process. I just want to
cover all of the operational bases.

On Aug 1, 9:27 pm, "Wolfgang Kern" <spamt...@crayne.org> wrote:
> More practical is to just remember the basic rules of the story and
> forget about a complete (phone book sized) list of all variants.

Practical advice indeed. Thanks for the note and explanation.

I will most likely hand-write something that simply uses every
instruction.

On Aug 1, 7:33 pm, ArarghMail807NOSPAM <spamt...@crayne.org> wrote:
> On Fri, 01 Aug 2008 19:35:04 -0500, ArarghMail807NOSPAM
>
> <spamt...@crayne.org> wrote:
>
> <snip>
>
>
>
> >Hmmm, that number is low. All possible variations is closer to
> >257,943,784,696 including all possible operand values and all possible
> >memory values, but NOT counting possible register values, which would
> >add several more orders of magnitude to the final value.
>
> All possible variations is closer to 2.31492071519263D+18 when you add
> in all possible register values. :-)
>
> Some opcodes are worse. :-)

And it's not just the (general-purpose) registers. The behavior
depends on the contents of the system registers and in-memory data
structures as well.

Alex

On Aug 1, 8:26 am, Jim Leonard <spamt...@crayne.org> wrote:
> I am in need of a block of code that completely exercises the 8086 16-
> bit instruction set (excluding 8086-specific and intel-specific quirks
> such as POP CS and AAD/AAM with custom operand). While I can try to
> go through the intel manual and code it up myself, I only consider
> myself a novice at assembler and I'm afraid I would either miss
> something, or screw up a lesser-known addressing mode, or some other
> misstep.

Bugs are inevitable. In tests, too. Coding up a test like that will
take 6+ months and result in > 20 KLOC. Actual numbers will depend on
your definition of "exercising". If it's just generation of most
relevant input states and little to no checking of the output states
(with the exception of crashes and hangs), it's one thing. If you want
to test the code functionally, it's another (much more test code
needed). Yes, you can code it up. But it's quite a project.

Alex

On Fri, 1 Aug 2008 20:29:28 -0700 (PDT), Jim Leonard
<spamtrap@crayne.org> wrote:

>On Aug 1, 7:35 pm, ArarghMail807NOSPAM <spamt...@crayne.org> wrote:
>> Why?
>
>I'm writing an x86 benchmark. It is for a very specific purpose, so
>please no discussion of how all benchmarks suck :-)
Hmmm, originally you said 8086. Now, x86. Quite different.


>> Hmmm, that number is low. All possible variations is closer to
>> 257,943,784,696 including all possible operand values and all possible
>> memory values, but NOT counting possible register values, which would
>> add several more orders of magnitude to the final value.
>
>No, no, I just need to test each opcode once per addressing mode, not
>once for every single valid value it can process. I just want to
>cover all of the operational bases.
Perhaps not, but you should need to make sure that each bit of the
registers and data busses works in both directions (0/1), and a single
test won't tell you that it works for sure. Trying all possible
combinations shouldn't be necessary, but testing each bit should be.

Better, get a block diagram of all the data paths in an 8086, and just
test that all work. Assuming you can figure out which instruction
uses which path. It shouldn't be too hard, the 8086/88 was kinda
dumb.

There appears to be a data sheet at:
http://www.datasheet4u.com/html/8/0/...Intel.pdf.html

Writing this kind of diagnostic is something I would NOT try.

IMO, it is something that sould be done by the chip & motherboard
designers, who should have more insight to possible problems such
signal crosstalk.


Personally, I wouldn't worry about it. If the system finishes the
Bios Post routine, I would figure that the processor works. Now,
memory is a horse of a different color. That I would test the hell
out of.
--
ArarghMail808 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.