This is very hard to say with any measure of exactness. But I would say somewhere between 4 and 6. According to wikipedia: "the average performance for the Intel 8088 ranged from approximately 0.33–1 million instructions per second." Which would amount to something between 4 to 14 cycles. My guess is using 6 is probably safe for the bulk of instructions. That would give you about 0.8 MIPS. But this is all very hand wavey.

It will be far more than 4 on average. It takes 4 cycles just to load a single byte from memory.
Since most instructions are more than 1 byte, you tend to spend more than 4 cycles on just loading the instructions from memory.
And that's not including the access to memory that the instructions themselves might do... or the address calculation they may perform.

Problem is, it's a fundamental mistake to take an 'average' amount of cycles. Some instructions are WAY slower than others. The whole reason why all PC emulators suck so badly is because they are not representative of actual performance at all.
A single mul or div instruction can take 100 to 160+ cycles, while the fastest possible instruction would be a mov that runs from the prefetch buffer, at 2 cycles. Problem is, all instructions that can execute in 2 cycles are 2 bytes or more, so you won't fit a whole lot of them in your prefetch buffer. And as soon as you need to fetch a 2-byte instruction from memory, it adds 8 extra cycles.

So, there's no such thing as 'average', or 'one size fits all'.

Here is a histogram of executed instructions in my emulator. I got this after booting to DOS, then running Checkit, then playing ACE for a bit then starting AutoCAD. It seems between 0x8b (MOV Gv, Ev), 0x75 (JNZ) and 0x74 (JZ) you got about a third of all real instructions (0x26 is not an instruction as such, it is just ES: prefix).

I agree that there is no "size fits all" but if you want to give the "feel" of correct speed, without being accurate making every instruction take 6 or 8 cycles is still better than 1.

NOTE: forgot actually add the histogram:

10x0 441 
20x1 17798 
30x2 3256 
40x3 227913 ==========
50x4 693 
60x5 512 
70x6 103407 ====
80x7 94001 ====
90x8 23448 =
100x9 213 
110xa 158556 =======
120xb 140769 ======
130xc 279 
140xd 21 
150xe 76275 ===
160xf 0 
170x10 0 
180x11 105 
190x12 0 
200x13 20183 
210x14 0 
220x15 32 
230x16 68503 ===
240x17 3 
250x18 0 
260x19 0 
270x1a 5 
280x1b 2702 
290x1c 0 
300x1d 555 
310x1e 160119 =======
320x1f 187197 ========
330x20 140 
340x21 0 
350x22 20469 
360x23 18365 
370x24 6901 
380x25 187 
390x26 890998 ==========================================
400x27 0 
410x28 0 
420x29 300 
430x2a 6697 
440x2b 71390 ===
450x2c 2588 
460x2d 1934 
470x2e 386933 ==================
480x2f 0 
490x30 48 
500x31 2280 
510x32 72091 ===
520x33 124501 =====
530x34 135 
540x35 0 
550x36 638522 ==============================
560x37 0 
570x38 7138 
580x39 16847 
590x3a 205007 =========
600x3b 223241 ==========

610x3c 41608 =
620x3d 32874 =
630x3e 328 
640x3f 0 
650x40 11923 
660x41 2338 
670x42 7682 
680x43 27350 =
690x44 0 
700x45 6 
710x46 233915 ===========
720x47 18144 
730x48 2085 
740x49 27500 =
750x4a 6900 
760x4b 14234 
770x4c 0 
780x4d 72 
790x4e 7905 
800x4f 5041 
810x50 338655 ================
820x51 159597 =======
830x52 157111 =======
840x53 171697 ========
850x54 348 
860x55 154891 =======
870x56 107747 =====
880x57 94746 ====
890x58 156773 =======
900x59 158545 =======
910x5a 158753 =======
920x5b 167913 ========
930x5c 0 
940x5d 154763 =======
950x5e 101667 ====
960x5f 94908 ====
970x60 0 
980x61 0 
990x62 0 
1000x63 0 
1010x64 0 
1020x65 0 
1030x66 0 
1040x67 0 
1050x68 0 
1060x69 0 
1070x6a 0 
1080x6b 0 
1090x6c 0 
1100x6d 0 
1110x6e 0 
1120x6f 0 
1130x70 0 
1140x71 0 
1150x72 393840 ==================
1160x73 218150 ==========
1170x74 741379 ===================================
1180x75 849663 ========================================
1190x76 4358 
1200x77 25650 =
1210x78 24542 =
1220x79 247 
1230x7a 0 
1240x7b 0 
1250x7c 14012 
1260x7d 3457 
1270x7e 5529 
1280x7f 5667 
1290x80 453451 =====================
1300x81 284544 =============
1310x82 0 
1320x83 465642 ======================
1330x84 175245 ========
1340x85 0 
1350x86 24798 =
1360x87 6677 
1370x88 287030 =============
1380x89 320770 ===============
1390x8a 398172 ===================
1400x8b 1256735 ============================================================
1410x8c 236163 ===========
1420x8d 43473 ==
1430x8e 473047 ======================
1440x8f 47616 ==
1450x90 399 
1460x91 3206 
1470x92 685 
1480x93 3593 
1490x94 0 
1500x95 22 
1510x96 284 
1520x97 55886 ==
1530x98 53509 ==
1540x99 1996 
1550x9a 103923 ====
1560x9b 0 
1570x9c 94029 ====
1580x9d 28846 =
1590x9e 259 
1600x9f 259 
1610xa0 84938 ====
1620xa1 61972 ==
1630xa2 63742 ===
1640xa3 116257 =====
1650xa4 9853 
1660xa5 294542 ==============
1670xa6 11337 
1680xa7 1032 
1690xa8 36189 =
1700xa9 693 
1710xaa 26518 =
1720xab 106002 =====
1730xac 10261 
1740xad 65728 ===
1750xae 40382 =
1760xaf 0 
1770xb0 8333 
1780xb1 3755 
1790xb2 3788 
1800xb3 195 
1810xb4 115172 =====
1820xb5 658 
1830xb6 8 
1840xb7 10182 
1850xb8 68429 ===
1860xb9 30007 =
1870xba 54500 ==
1880xbb 97007 ====
1890xbc 2606 
1900xbd 664 
1910xbe 23945 =
1920xbf 7341 
1930xc0 0 
1940xc1 0 
1950xc2 0 
1960xc3 399575 ===================
1970xc4 178661 ========
1980xc5 108033 =====
1990xc6 48042 ==
2000xc7 106361 =====
2010xc8 0 
2020xc9 0 
2030xca 35385 =
2040xcb 178968 ========
2050xcc 0 
2060xcd 61479 ==
2070xce 0 
2080xcf 86300 ====
2090xd0 181057 ========
2100xd1 471987 ======================
2110xd2 2113 
2120xd3 2382 
2130xd4 0 
2140xd5 0 
2150xd6 0 
2160xd7 1587 
2170xd8 0 
2180xd9 2 
2190xda 0 
2200xdb 2 
2210xdc 0 
2220xdd 0 
2230xde 0 
2240xdf 0 
2250xe0 15383 
2260xe1 0 
2270xe2 268488 ============
2280xe3 3735 
2290xe4 427 
2300xe5 0 
2310xe6 2427 
2320xe7 0 
2330xe8 488254 =======================
2340xe9 30352 =
2350xea 991 
2360xeb 494524 =======================
2370xec 185888 ========
2380xed 0 
2390xee 6524 
2400xef 0 
2410xf0 0 
2420xf1 0 
2430xf2 7363 
2440xf3 11568 
2450xf4 0 
2460xf5 1347 
2470xf6 180661 ========
2480xf7 24726 =
2490xf8 55977 ==
2500xf9 29468 =
2510xfa 88591 ====
2520xfb 125964 ======
2530xfc 38955 =
2540xfd 12 
2550xfe 120806 =====
2560xff 310209 ==============

reenigne was working on a PCB that could be used for measuring clocks per instruction on an 8088 for a cycle-exact XT emulator.
http://www.reenigne.org/blog/isa-bus-sniffer-update/
http://www.reenigne.org/blog/isa-bus-sniffer/
http://www.reenigne.org/blog/i-bought-an-xt/

I don't have an XT(Nor do I think I'll ever have), so all I can rely on for now is the information I can find on the internet.

I've just set it up to use 8 cycles/instruction on 80(1)86/88 CPUs and the old 4 cycles/instruction on 286+ CPUs. 8088 MPH worked somewhat(end credits music) with 4 cycles, still need to test on 8 cycles.

Edit: Just tested running 8088 MPH. The music sounds kind of correct (recognisable), but it still stutters (CPU running at ~71% speed according to the CPU indicator when enabled, thus explaining the missing audio chunks (every second only being filled ~70% of 44100(samplerate) samples instead of all that's needed, since all audio output generation (except MIDI SF2 emulation) is tied to the CPU core emulation(the clock cycles reported to have run by the CPU for the current instruction))).

Test results of a Intel i7 4790K@4.0GHz (not overclocked due to stock cooling, using the x86EMU commit of 2016/02/19 02:25):

MIPS 1.10 is reporting: Default: 250 cycles:
General Instructions: 2.07 0.84
Integer Instructions: 3.62 1.48
Memory to Memory: 2.49 1.02
Register to Register: 3.31 1.35
Register to Memory: 1.92 0.79
Performance rating: 2.44 1.00

With 8 cycles applied to the Default setting(newly hardcoded in the emulator for pre-286 CPUs, 286+ still use 4 cycles).

According to 8088 MPH deviating 6% with 250 cycles setting. Better results are when the cycles setting is at ~595 cycles (Set while playing though(shouldn't make a difference to the software?). )Dosbox-style cycles, e.g. 1 cycle/instruction). Although there's still a high pitched noise between the music.

Edit: I've also decreased EMS to 2MB according to the emulated board, and MMU(RAM) memory on 80(1)86/88 to 1MB. This makes the app use less memory(which is basically unaddressable or simply unused in the case of the EMS memory board(128/256 pages used by the driver)).

superfury wrote:

Although there's still a high pitched noise between the music.

That is the nature of the PWM technique of playing samples.
Since you generate pulses at a fixed rate, this automatically creates a 'carrier' frequency for every start of the pulse.
On real hardware, the end tune of 8088 MPH runs at ~16.5 KHz, so you should hear a carrier frequency of 16.5 KHz in the music.
Unlike most PWM routines, it is not synchronized to the PIT, but the code is 'free-running'. That is, the time between samples is padded with nops (or nop-like instructions) so that the time between the out-instructions of playing a sample is exactly 288 cycles (since 4.77 MHz / 288 == ~16.5 KHz).
Which means your emulator needs to execute these instructions at exactly the same speed as well, to get proper results.

If your emulation runs slower, then the frequency will also be lower, and it will be more noticeable (16.5 KHz is near the limit of hearing of a grown human... it's also near the limit of a real PC speaker).

One little question: if the carrier is at ~16.5kHz, won't the samples be distorted with high tones(above 16.5 / 2 = 8.25kHz frequencies in the song, when sampled at 16.5kHz?)

Also, I'm still thinking on how to apply the different combinations of cycles in instructions universally to my instruction execution.

superfury wrote:

One little question: if the carrier is at ~16.5kHz, won't the samples be distorted with high tones(above 16.5 / 2 = 8.25kHz frequencies in the song, when sampled at 16.5kHz?)

Well, because of Nyquist, you can't have tones above 8.25 KHz anyway. And indeed, it all sounds rather grainy and distorted, especially in the high frequencies (there's also considerable quantization noise, since we only have ~6 bits of precision, and samples are quantized before mixing, so you effectively have only 17 unique values of amplitude per channel, if I'm not mistaken. And no interpolation for any resampling either, of course. In a way it's amazing it sounds as good as it does, given how limited the precision is 😀).
The videos we made of 8088 MPH on YouTube were tapped directly from the PC speaker output of a PC. So that is what it sounds like exactly (although it seems the YouTube encoding process has filtered off most of the carrier whine. I could extract a raw .wav file from my capture, if you like).

That .wav file would come in handy for comparing with the output of my emulator. It might be giving 'correct' output with 8088 MPH after all (Recording emulated output is also possible using it's sound menu option in the BIOS settings menu)? It's giving about correct results with the new Default setting(8 CPI@4.77MHz). At least it sounds correct, considering the output lag(audio output clearing buffer faster than the emulated CPU fills it?)

Btw CPI=Cycles per instruction.

I implemented 9 cycles with 8088 (to get 8088 MPH to properly produce sound) and the original 8 cycles for the 8086. 8088MPH credits now seem to work fine, with a low LFO-like sound going through it.

I tried it with 8 cycles, but 9 cycles results in better sound quality with 8088 MPH. 10 cycles makes it barely hearable (falling into the background of (white) noise).

Check out my latest x86EMU release for this version (x86EMU build 2016/02/22 14:52).

(Although according to a simple calculation, 288 cycles both divides by 8 and by 9 cycles, so both could theoretically work. It doesn't divide cleanly by 10, so that would explain the quality loss? I don't know yet why 9 cycles gives better audio quality than 8 cycles? Maybe the 8088 MPH demo takes a bit longer than 8 cycles to perform it's PWM loop? 8 cycles most of the time with sometimes 9 cycles on average? This would explain why 9 cycles gives better audio.)

Scali, recorded playback of 8088 MPH: http://www.filedropper.com/recording10
Is this what you meant by the carrier that's filtered out on Youtube? (PWM starts at 10:40)? Or is this just my high pass filter messing up?

Scali wrote:

It will be far more than 4 on average. It takes 4 cycles just to load a single byte from memory. Since most instructions are mor […]
Show full quote

It will be far more than 4 on average. It takes 4 cycles just to load a single byte from memory.
Since most instructions are more than 1 byte, you tend to spend more than 4 cycles on just loading the instructions from memory.
And that's not including the access to memory that the instructions themselves might do... or the address calculation they may perform.

Problem is, it's a fundamental mistake to take an 'average' amount of cycles. Some instructions are WAY slower than others. The whole reason why all PC emulators suck so badly is because they are not representative of actual performance at all.
A single mul or div instruction can take 100 to 160+ cycles, while the fastest possible instruction would be a mov that runs from the prefetch buffer, at 2 cycles. Problem is, all instructions that can execute in 2 cycles are 2 bytes or more, so you won't fit a whole lot of them in your prefetch buffer. And as soon as you need to fetch a 2-byte instruction from memory, it adds 8 extra cycles.

So, there's no such thing as 'average', or 'one size fits all'.

Quite correct - certain instructions take more clock cycles, while others can execute in fewer cycles. It also depends on the CPU model and mode of operation - in writing my own 80386 CPU emulator, and from reading the Intel 80386 Programmer's Reference in the process, I have found that instructions can just as easily have different clock cycles depending upon whether they happen to be running in Real Mode, Protected Mode, or Virtual 8086 Mode.

PCE, the emulator that I am basing my own emulator on, is what is called a cycle-accurate emulator. That is, it implements the correct clock cycles for the 8086 and 80186 CPUs, and in just the same way, my own projects will likewise implement the correct clock cycles for the 80286, 80386, and higher CPUs. PCjs is also cycle-accurate for the 8086, 80286, and 80386 CPUs.

SoftPCMuseum_ wrote:

PCE, the emulator that I am basing my own emulator on, is what is called a cycle-accurate emulator. That is, it implements the correct clock cycles for the 8086 and 80186 CPUs, and in just the same way, my own projects will likewise implement the correct clock cycles for the 80286, 80386, and higher CPUs. PCjs is also cycle-accurate for the 8086, 80286, and 80386 CPUs.

I hate to break it to you, but, no, they aren't cycle-accurate. Namely:
1) Although these emulators make some effort in incorporating the cost of each instruction, they are just ballpark figures. They do not account for all the variables that affect the speed of execution of each instruction.
2) The only thing they try to emulate in terms of clock-cycles is the CPU itself, and only a fixed cost per executed instruction. They do not emulate things like the prefetch buffer, the data bus, or other hardware which may steal cycles or add wait states (such as DMA refresh or CGA memory).

A proper cycle-accurate emulator emulates the system as a whole. For good cycle-accurate emulators, take a look at VICE or UAE.
No such thing exists for PC yet (and it can't exist yet, because the exact behaviour of the 8088 CPU and the interaction with the supporting hardware at the cycle-level has never been fully documented so far).
Which is why 8088 MPH breaks all emulators.

superfury wrote:

I tried it with 8 cycles, but 9 cycles results in better sound quality with 8088 MPH. 10 cycles makes it barely hearable (falling into the background of (white) noise).

The thing with PWM is that the amplitude is a function of the replay speed (unlike PCM). You program the duty cycle of your wave for every PWM sample you emit.
Now, the duty cycle here of each sample here is fixed... But the replay rate is not. The result is that when your CPU runs too quickly, it will reprogram the timer before the previous sample finished playing. This can lead to all sorts of weird aliasing.
If the CPU runs too slowly, then the timer will sit idle for longer than you anticipated when you converted your samples to duty cycle values. As a result, the amplitude is lower than expected.

superfury wrote:

Scali, recorded playback of 8088 MPH: http://www.filedropper.com/recording10

I can't seem to download this file.

It was still there when I uploaded it. It seems to have been removed for inactivity or something like that? Unfortunately the laptop cooling ventilation I'm using this weekend seems to go wrong(it makes metallic jumping noises, like some loose metal's gotten in the fan, with little smoke coming out of it. It smelled like a bit of solder vaporizing(which is poisonous). I immediately shut down the laptop, maybe my father can look at it next week in order to repair it. Although the laptop's getting old(6-8 years old Intel Core Duo x64@2.0Ghz), so it might be better to start looking for a new one?). This happened first about 2 weeks ago, when the laptop fell from about 0.5m on it's right side(ventilator is on the left side). It's a Acer Aspire 7741ZG laptop.

Scali wrote:

I hate to break it to you, but, no, they aren't cycle-accurate. Namely: 1) Although these emulators make some effort in incorpor […]
Show full quote

SoftPCMuseum_ wrote:

PCE, the emulator that I am basing my own emulator on, is what is called a cycle-accurate emulator. That is, it implements the correct clock cycles for the 8086 and 80186 CPUs, and in just the same way, my own projects will likewise implement the correct clock cycles for the 80286, 80386, and higher CPUs. PCjs is also cycle-accurate for the 8086, 80286, and 80386 CPUs.

I hate to break it to you, but, no, they aren't cycle-accurate. Namely:
1) Although these emulators make some effort in incorporating the cost of each instruction, they are just ballpark figures. They do not account for all the variables that affect the speed of execution of each instruction.
2) The only thing they try to emulate in terms of clock-cycles is the CPU itself, and only a fixed cost per executed instruction. They do not emulate things like the prefetch buffer, the data bus, or other hardware which may steal cycles or add wait states (such as DMA refresh or CGA memory).

A proper cycle-accurate emulator emulates the system as a whole. For good cycle-accurate emulators, take a look at VICE or UAE.
No such thing exists for PC yet (and it can't exist yet, because the exact behaviour of the 8088 CPU and the interaction with the supporting hardware at the cycle-level has never been fully documented so far).
Which is why 8088 MPH breaks all emulators.

First, you realize of course that when developing a "cycle-accurate" emulator, the clock cycles are normally taken directly from the CPU reference manuals for each instruction, which at least is what I do when developing my own emulated Intel 80386 CPU from the PCE source code.

Second of all, PCE actually does emulate the prefetch queue (and so does IBMulator too for that matter), among other things, so you should really check the source code out yourself before making such statements.

And finally, at least for the 80386, you can easily find the individual clock cycles in the Intel 80386 Programmer's Reference Manual (1987).

SoftPCMuseum_ wrote:

First, you realize of course that when developing a "cycle-accurate" emulator, the clock cycles are normally taken directly from the CPU reference manuals for each instruction, which at least is what I do when developing my own emulated Intel 80386 CPU from the PCE source code.

Second of all, PCE actually does emulate the prefetch queue (and so does IBMulator too for that matter), among other things, so you should really check the source code out yourself before making such statements.

And finally, at least for the 80386, you can easily find the individual clock cycles in the Intel 80386 Programmer's Reference Manual (1987).

That is not what I see in the source code of your release (from cpu/e8086/pqueue.c)

1/*
2 * Before an instruction is executed the prefetch buffer (pq_buf) is
3 * filled up to pq_fill bytes. After the instruction is executed
4 * the instruction bytes are discarded and the remaining bytes up
5 * to pq_size are copied to the front of the queue. Bytes between
6 * pq_size and pq_fill are discarded (and possibly read again from
7 * RAM).
8 *
9 * The prefetch buffer is filled with pq_fill instead of pq_size bytes
10 * so that there is always at least one entire instruction in the
11 * prefetch buffer. Yes, this is ugly.
12 */

That is not how the prefetch buffer is working at all. Like Scali said, I also do not know of any cycle accurate emulator (maybe MESS, does MESS do a better job?).

The other problem is, on 8088 (especially IBM PC and XT) it is somewhat easier to develop an almost cycle accurate emulator but when it comes to 80386 all bets are off, as by that point the number of motherboards was pretty large each with its own peculiarities, with and without cache, memory types, ISA/EISA bus, etc such that a proper cycle accurate emulator is nigh-impossible.

SoftPCMuseum_ wrote:

Second of all, PCE actually does emulate the prefetch queue (and so does IBMulator too for that matter), among other things, so you should really check the source code out yourself before making such statements.

I checked the code, and didn't see anything that actually emulates the data bus. The prefetch queue does its prefetching in cycles where the data bus is idle. If you do not emulate the data bus, you do not emulate idle cycles, and as such, you do not actually emulate the prefetch queue.
Much like how you don't actually do cycle-exact emulation if you just use hardcoded values for each instruction (the manuals do explain how data access and calculation of EA's etc affect timing, so most of what I said is already in the CPU manuals. Not that those manuals are any kind of excuse not to emulate the rest of the system's effect on the CPU, such as DMA refresh, wait states from memory or other devices etc).

Come back when your emulator can run 8088 MPH, *then* we're talking about cycle-exact emulation.

Of course a perfectly written CPU manual is the absolute truth for the CPU. But only for the CPU.

From what you say in your first point, it appears you think cycle accurate means only the CPU. To me and many others, cycle accurate emulation means the whole computer system (PC, arcade cabinet, console, handheld) as a whole, including other peripherals as well, like video and sound generation, that have to be in sync with CPU execution, or the screen drawing or sound generation could fail spectacularly.

Different memory areas can have different wait states (fetching from BIOS ROM could be slower than RAM, writing to RAM could be faster than video memory), so accessing different memory areas can cause different execution times with same instruction.
The CPU is not also the only thing that uses the bus, as there will be things that occasionally prevent the CPU from accessing the bus which causes extra cycles to instructions. For example things like periodic DRAM memory refresh cycles, and DMA cycles if a sound card is using DMA to play something.

I bet there is no exact information in the manuals how a given CPU works, if for an opcode X running on the Yth cycle the bus is busy for Z cycles. Normally these of course don't have to be emulated, but to fully run 8088 MPH, just emulating the CPU in a cycle accurate way is not enough, it needs to emulate at least timer hardware (for memory refresh timing and sound generation) and video adapter timing as well. Why? Because it is built to run on specific hardware configuration, so that a given code block executes at given point of drawing the screen for example.

edit: had a too long break in writing, many people said approx the same things.

Well for one thing, this topic DID say "8086 average clocks per instruction", which implies that it was talking only about the CPU alone (by implying the Intel 8086 specifically by name). That was why I replied the way that I did. If the title made it clear that it was talking about the entire machine, then I would have replied differently.

Second of all, nowhere was I denying that the PCE code had issues that needed to be addressed. And nowhere did I say that its emulation of the prefetch queue was necessarily perfect either. What I simply said, was that it emulates the prefetch queue (as opposed to simply not having one at all).

Third, I'm already considering adding in support for the Intel 8288 bus controller once I get to that area of the IBM PC Technical Reference manual, but right now, I still at the ROM BIOS listing.