---
The simulation would not be anymore complicated if you analysis ignored the "work that was done" and instead looked at the 8051 mechanisms (setb, clr, movx, jnb) by which 8051 performs.
---

I didn't mean to find code that doesn't do any hardware interfacing; something like an LCD is easy enough to simulate (typically just need an acknowledge/ready in response to commands). We're trying to stay away from code which communicates with a complex bidirectional protocol, simply because of the time it'd take to write code to simulate the other end of the protocol. However, if we find compelling code, we'd take the time.

-----
Also i would be interested in your result as more signal processing occurs using 8051's (mostly variants) than people would like to admit and determinism is the name of the game there.
-----
It's interesting that you say that, because I don't think I've seen any publicly available code for the 8051 that's in the signal processing area. Do you have any pointers to this sort of thing?

As long as timers can be used to trigger data collection, and the data collection rate is low enough compared to processor speed, there shouldn't be much of an issue handling DSP.
Granted, I don't know how realistic those assumptions are.

----
The std "read a key", "write the LCD", "interpret the state" algorithm code path could tolerate quite a bit of indeterminancy but if you were really implementing an full 8051 hardware implementation the peripherals would fall apart if they were indeterminate (i.e. serial ports that performed at +/- 15% of intended bit rate).
----
Yes, we realize that we can't quite implement a 100%-standard 8051. For example, we can't do RS232, as it requires a stable clock signal. However, we can do I2C, since its clock line can apparently be run at a variable rate. The ports will be somewhat of a headache, but for many applications it shouldn't matter too much if there's variability in how fast an input on a port is processed.

----
You may have chosen the wrong processor to implement. Unless your indeterminacy was small was simply related to code execution (and was small).
----

The processor will run as fast as it can given the op and the operands. Simple ops will run much faster than complex ones; the system is deterministic in the sense that the same op with the same operands (with the same supply voltage, temperature, etc) will take the same time to execute each time.