On 10/28/2025 11:44 AM, Kaz Kylheku wrote:But it didn't correctly determine that, as proven by Kaz's code.On 2025-10-28, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:Yet that is just cheating.But most of all I'm surprised PO's trace buffer would fill up, unless there is an infinite loop in>
the picture. (Your "infinite tower" would constitute such a loop, I guess, but then by the time you
need to compress, isn't it clear there's such an infinite loop, so no point going further?
The execution trace quickly fills up because when you have a doubly
nested simulation, it takes many instructions of the first level to
simulate each instruction of the second level.
>
Each interpretation level in an interpretation tower is vastly less
efficient than the one above.
>
The x86emu is particularly inefficient because it performs a detailed
simulation unconcerned with efficiency (executing as few host
instructions as possible to complete a target instruction).
>
Say that the interpretation ratio is 100: 100 instructions of host
for one instruction of target. To simulate just 100 instructions of the
second traced level, the first traced level has to execute 10,000
instructions.
>
If we could actually use "reckoning" to simulate the infinite tower
indefinitely, we could be counteracting this interpretation ratio,
because when the "reckoning" module takes over an abandoned simulation,
it effectively hoists it to its own level (the top level).
>
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
Once H correctly determines that its
simulated D cannot possibly reach its
own simulated "return" statement
Les messages affichés proviennent d'usenet.