Hal stated what came to mind first; the 8051 of all micro's is "biased" toward hardware and logic reduction consequently any analysis of "useful" code would be able to recognize the most common mechanisms by which the 8051 interacts with hardware.

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.

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.

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).

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

regards,
p