Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #133775 > unrolled thread
| Started by | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| First post | 2025-10-26 05:29 +0000 |
| Last post | 2025-11-05 10:56 -0600 |
| Articles | 20 on this page of 115 — 8 participants |
Back to article view | Back to comp.theory
x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-26 05:29 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-26 09:52 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-26 15:20 +0000
Re: x86utm with "reckoning" code: git repo with published commit. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 12:37 -0700
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-26 20:30 +0000
Re: x86utm with "reckoning" code: git repo with published commit. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 13:43 -0700
Re: x86utm with "reckoning" code: git repo with published commit. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 13:49 -0700
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-26 21:46 +0000
Re: x86utm with "reckoning" code: git repo with published commit. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 22:16 -0700
Re: x86utm with "reckoning" code: git repo with published commit. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 22:17 -0700
Re: x86utm with "reckoning" code: git repo with published commit. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-10-31 04:51 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 05:18 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-10-31 15:38 +0000
Re: x86utm with "reckoning" code: git repo with published commit. olcott <polcott333@gmail.com> - 2025-10-31 11:14 -0500
Re: x86utm with "reckoning" code: git repo with published commit. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-10-31 16:35 +0000
Re: x86utm with "reckoning" code: git repo with published commit. olcott <polcott333@gmail.com> - 2025-10-31 11:55 -0500
Re: x86utm with "reckoning" code: git repo with published commit. Richard Damon <Richard@Damon-Family.org> - 2025-10-31 13:51 -0400
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 18:03 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Richard Damon <Richard@Damon-Family.org> - 2025-10-31 14:10 -0400
Re: x86utm with "reckoning" code: git repo with published commit. olcott <polcott333@gmail.com> - 2025-10-31 11:23 -0500
Re: x86utm with "reckoning" code: git repo with published commit. Richard Damon <Richard@Damon-Family.org> - 2025-10-31 13:19 -0400
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 17:37 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-04 18:04 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 18:36 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-04 18:59 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 19:36 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-04 21:03 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 21:58 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-05 01:20 +0000
Kaz does not understand his own code. olcott <polcott333@gmail.com> - 2025-11-04 20:14 -0600
Re: Kaz does not understand his own code. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-05 02:43 +0000
Re: Kaz does not understand his own code. olcott <polcott333@gmail.com> - 2025-11-04 21:06 -0600
Re: Kaz does not understand his own code. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-05 03:33 +0000
Re: Kaz does not understand his own code. joes <noreply@example.org> - 2025-11-05 07:47 +0000
Re: Kaz does not understand his own code --- I AM PROVED EXACTLY CORRECT olcott <polcott333@gmail.com> - 2025-11-04 21:51 -0600
Re: Kaz does not understand his own code --- I AM PROVED EXACTLY CORRECT Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-05 05:12 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-04 23:23 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-05 07:01 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 08:55 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-05 17:35 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 12:17 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-05 13:43 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 19:24 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-05 20:39 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 19:43 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 01:56 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 20:21 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 04:36 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 23:12 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-06 07:54 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 09:19 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-06 16:39 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 11:10 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 17:16 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 11:26 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-06 12:34 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 11:58 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-06 13:01 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 12:04 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-06 13:15 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 18:37 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-06 20:03 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 14:24 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 21:16 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 21:39 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 22:10 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 14:04 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 20:45 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 14:57 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 18:14 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 12:27 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 18:46 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 14:10 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 21:03 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 19:54 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-05 21:08 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 20:24 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-05 22:05 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 21:15 -0600
Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-05 22:18 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-05 21:27 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-05 22:32 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-05 21:38 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-05 22:39 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-05 21:50 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-05 22:53 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-05 19:57 -0800
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-05 21:57 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-05 23:04 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-05 22:15 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-05 23:25 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-05 23:00 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-06 07:51 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-06 09:16 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-06 10:22 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-06 10:08 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-06 11:26 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-06 10:49 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-06 11:56 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-06 11:16 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-05 13:49 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. joes <noreply@example.org> - 2025-11-05 18:55 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 19:23 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. joes <noreply@example.org> - 2025-11-06 14:33 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 09:13 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-05 21:38 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 19:15 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 19:41 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-05 20:45 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-05 18:39 -0800
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-05 12:04 -0800
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. joes <noreply@example.org> - 2025-11-05 07:42 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 05:33 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-05 16:43 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 10:56 -0600
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2025-10-31 13:19 -0400 |
| Message-ID | <3d6NQ.1331735$xYr1.684878@fx14.iad> |
| In reply to | #134508 |
On 10/31/25 12:23 PM, olcott wrote: > On 10/31/2025 12:18 AM, Kaz Kylheku wrote: >> On 2025-10-31, Mike Terry >> <news.dead.person.stones@darjeeling.plus.com> wrote: >>> Hmm, one thing I wondered was whether your resumption code would >>> correctly recognise a simulation >>> that had actually terminated prior to resumption. [Thinks: the >>> final ret instruction will have >>> been stepped in such a simulation, so god only knows what the EIP >>> will be in the slave_state >>> structure! >>> It wouldn't be the end-of-code address as its "gone past" that. >>> Well, PO's simulations >> >> I happen to know the exact answer for that from the typical way Halt7 >> sets up the simualtion, and believe that to obe consistent across >> different H functions and versions. >> >> The initial slave_stack is primed in such a way that when >> the last RET instruction at code_end of the simulated function is >> executed, it will return to the last instruction of the simulator > > You don't even know the difference between > H calling D and H simulating D. > > Even when H1 simulates D as soon as D reaches > its "return" statement there is no address on > its stack that D can return to. If H1 didn't > catch this it might crash the x86utm operating > system. Popping from an empty stack probably > can only return garbage. And the proper solution would be to setup the stack so there *IS* a special return address on the stack (perhaps 0 would be a good special value). You should not use an address that is in the executable space of the program, like any address of the simulator, since the simulated program includes the simulator. This is of course, part of your problem that you don't clearly define memory spaces and thus don't have the needed independence. A proper fully generic simulator puts the code to be simulated inside a virtual address space so EVERY access in the simulation gets mapped the same. The key is that "Simuated Addresses" and "Simulator Addresses" are distinct things, even if the simulated machine uses the simulator, as it really needs to have its own instance of it, even it if just happens to be the same code, or the simulated code isn't actually a seperate program. > >> (the relevant H function). RET returns to RET. No idea what for. >> >> Needless to say, that is hokey and we don't want to be looking for >> that. >> >> We can just use ESP to detect terminated simuations. >> >> No, not extra-sensory perception (haha, I bet that got a twinkle >> out of Olcott's eye there!) but the stack pointer. >> >> When the first instruction of a new simulaton is observed, we can >> record the stack pointer. Then we can tell from the slave_state >> that it has popped up out of that context. >> >> The reckoning module can remove such simulations from the list. >> >> What you hae to be careful in the reckoning module is not to resume >> simulating something which has not been abandoned. If any simulation has >> a parent that is also in the list, we must not step it, but its parent. >> Unless that parent still has a parent and so on. Only the thing with no >> living parent---an abandoned orphan---must be stepped. >> > >
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-31 17:37 +0000 |
| Message-ID | <20251031102806.648@kylheku.com> |
| In reply to | #134508 |
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
> On 10/31/2025 12:18 AM, Kaz Kylheku wrote:
>> On 2025-10-31, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>>> Hmm, one thing I wondered was whether your resumption code would correctly recognise a simulation
>>> that had actually terminated prior to resumption. [Thinks: the final ret instruction will have
>>> been stepped in such a simulation, so god only knows what the EIP will be in the slave_state
>>> structure!
>>> It wouldn't be the end-of-code address as its "gone past" that. Well, PO's simulations
>>
>> I happen to know the exact answer for that from the typical way Halt7
>> sets up the simualtion, and believe that to obe consistent across
>> different H functions and versions.
>>
>> The initial slave_stack is primed in such a way that when
>> the last RET instruction at code_end of the simulated function is
>> executed, it will return to the last instruction of the simulator
>
> You don't even know the difference between
> H calling D and H simulating D.
Yah, /that's/ what i don't know. Uh huh!
> Even when H1 simulates D as soon as D reaches
> its "return" statement there is no address on
> its stack that D can return to.
Well there isn't one that you actually /rembember/ coding up,
due to your failing memory and congitive decline.
But you could always, you know, look at the fucking code.
Does this line ring a bell?
// Inside HHH:
Init_slave_state0((u32)P, End_Of_Code, slave_state, slave_stack); // 2024-06-16
look at the second paraemeter, what is that?
Inside INit_slave_state0:
Top_of_Stack = StackPush(slave_stack, End_Of_Code); // Return Address in Halts()
The primed return address of the simulated subject points to the
end-of-code label in Halts which compiles to the RET instruction.
(which I know from the studying the disassembly.)
In your DebugStep loop, you actually step DD past its RET instruction.
Why? BEcause you do do the code_end step //after// running the
instruction.
At the top of Decide_Halting's step loop you have this:
u32 EIP = (*slave_state)->EIP; // Save EIP of instruction to be executed
DebugStep(*master_state, *slave_state, *decoded); // Execute this instruction
if (EIP == code_end) // last instruction of P "ret"
return 1; // input has halted
The current instruction is first put through DebugStep, and /then/
the original EIP is checked for code_end.
So what happens is that DD's (or D's) RET branch is taken,
and the EIP ends up pointing at the RET inside HHH.
Why do I knwo this? Because my report informed me of that!
After I found that DDD terminates, I dumped information about it
including its EIP. I was surprised to find that it's pointing into HHH.
Moreover at the last instruction in HHH. I scratched my head for a
second: how can I be? So then I went in detail into the stack priming
code, and gained the above undersatnding.
> catch this it might crash the x86utm operating
> system. Popping from an empty stack probably
> can only return garbage.
Luckily, a person you evidently no longer remember knew a thing or two
about priming the stacks of newly executing threads, and applied it to
x86utm simulation.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-04 18:04 +0000 |
| Message-ID | <10edf6q$3r1an$1@dont-email.me> |
| In reply to | #134458 |
On 31/10/2025 04:51, Mike Terry wrote:
> On 26/10/2025 05:29, Kaz Kylheku wrote:
>> There you go:
>>
>> https://www.kylheku.com/cgit/x86utm/commit/?id=2cd60805c4fb6dc46d7ccfcac2509ec8821a838d
>>
>> All further arguments against the idea that DDD simulated by HHH(DDD)
>> is antyhing but halting must refer to the code, with patches.
>>
>> No more bullshit about liar paradoxes, incorrect questions or ChatGPT
>> says this and that.
>>
>> If the result is wrong, show me where the flaw is.
>>
>> If DDD is non-halting, what is going wrong to make it look halting?
>>
>> Propose a /patch/ to fix it, and argue why the patch is correct.
>>
>
> Just letting you know I tried out your code from GIT. It built as expected, and ran against the
> halt7.obj in the repository [main calls HHH(DDD)] pretty much like I described in a previous email.
> As noted there, there are indeed huge problems due to PO's misuse of global variables, specifically
> **execution_trace.
>
> I did spot something I hadn't considered. You mentioned that PushBack () had been amended to cater
> for the trace buffer filling up, and elsewhere I noted that would surprise me, because there are
> really not that many entries written to it, even with considerable simulation nesting, because it is
> heavily filtered. [Basically, just instructions inside DDD*(), so say half a dozen per level of
> simulation/ and the buffer is enough for 10000 entries...]
>
> So I wasn't expecting that code path to be hit, but indeed it was! But looking closer it was due to
> another of those global data problems :( Basically, Decide_Halting_HH[1] was being stepped, and due
> to **execution_trace (global) having been reset to 0x90909090 [by HHH[2]?? I forget now] it was
> trying to PushBack () trace entries (generated by DDD[2] as it was exiting), but specifying a trace
> table at 0x90909090. That memory is all zeros, and that is interpreted as there being no space
> left, and your compression code jumps in and somewhat splats some memory near 0x90909090. As luck
> has it, that memory was unused, so no disaster occured.
>
> So in this case at least, the "real" trace table(s) hadn't filled up, but I don't know if it
> legitimately fills up in other test cases.
>
> I think I'll integrate your code into my play-code version of PO's code, as that has a number of
> improvements/fixes and I don't see why your code wouldn't work entirely as originally envisioned,
> and with better output being generated as well. Assuming I find the time I'll post any new output
> traces that result.
>
> Hmm, one thing I wondered was whether your resumption code would correctly recognise a simulation
> that had actually terminated prior to resumption. [Thinks: the final ret instruction will have
> been stepped in such a simulation, so god only knows what the EIP will be in the slave_state
> structure! It wouldn't be the end-of-code address as its "gone past" that. Well, PO's simulations
> of interest are all abandoned, so not #1 priority...]
>
>
> Mike.
>
So I integrated your code into my play-code version of PO's program. No big surprises to report!
Below are 3 traces with different inputs. I'm sure you'll have run the first two yourself, but the
third will be new (but not surprising...) I modified your code somewhat to make it resume all the
outstanding simulations (until interrupted), and to integrate with my "simulation depth" reporting -
that's the SIM column on the left of the traces. Also my play code has "rationalised" log output so
your resumptions show the (filtered) trace instructions executed. [That came for free without
changing your code.] So I'd say the traces below are clearer than previously posted, if only
because you can see which simulation level is producing the various output messages! PO once added
code to add the simulation level to the instruction trace output, but then removed it, saying it
confused people!
Trace 1: Latest HHH(DDD). HHH[0] decides non-halting. Resumed simulations exhibit periodic
behaviour:
DDD[1] ends, after HHH[2] detects "infinite recursion" and returns.
DDD[2] ended naturally during DDD[1] resumption
DDD[3] ends, after HHH[2] detects "infinite recursion" and returns.
DDD[4] ended naturally during DDD[3] resumption
DDD[5] ends, after HHH[2] detects "infinite recursion" and returns.
DDD[6] ended naturally during DDD[5] resumption
...
Trace 2: Latest HHH(DD). HHH[0] decides non-halting. DD[1] loops.
DD[1] LOOPS, after HHH[2] detects "infinite recursion" and returns,
causing HHH[1] to decide HALTS, and then DD[1] to "do the opposite"
and loop. [LOL, HHH[0] was "right"!]
DD[2] ended naturally during DD[1] resumption
DD[3] we never get to this because DD[1] never halts
...
Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but
without the global variable misuse. HHH[0] decides non-halting.
Resumed simulations all halt with same behaviour as HHH[n] deciding
non-halting (like HHH[0]) then DDD[n] returning.
DDD[1] ends, after HHH[1] detects "infinite recursion" and returns 0.
DDD[2] ends, after HHH[2] detects "infinite recursion" and returns 0.
DDD[3] ends, after HHH[3] detects "infinite recursion" and returns 0.
DDD[4] ends, after HHH[4] detects "infinite recursion" and returns 0.
...
Traces 1 & 2 are ultimately nonsense, showing only how PO's misused global variables interact.
Trace 3 is meaningful, with each simulation level behaving the same etc.. and shows your infinite
tower as you envisioned it, I'd say!
Mike.
Traces follow:
==================================================================
Trace 1: [Latest HHH(DDD)]
_DDD()
[0000208c] 55 push ebp
[0000208d] 8bec mov ebp,esp
[0000208f] 688c200000 push 0000208c
[00002094] e813fcffff call 00001cac
[00002099] 83c404 add esp,+04
[0000209c] 5d pop ebp
[0000209d] c3 ret
Size in bytes:(0018) [0000209d]
_main()
[0000210c] 55 push ebp
[0000210d] 8bec mov ebp,esp
[0000210f] 688c200000 push 0000208c
[00002114] e893fbffff call 00001cac
[00002119] 83c404 add esp,+04
[0000211c] 50 push eax
[0000211d] 68c3060000 push 000006c3
[00002122] e845e6ffff call 0000076c
[00002127] 83c408 add esp,+08
[0000212a] 33c0 xor eax,eax
[0000212c] 5d pop ebp
[0000212d] c3 ret
Size in bytes:(0034) [0000212d]
S machine stack stack machine assembly
I address address data code language
M (before) (after) (after)
= ======== ======== ======== =============== =============
[0000210c][0010375a][00000000] 55 push ebp
[0000210d][0010375a][00000000] 8bec mov ebp,esp
[0000210f][00103756][0000208c] 688c200000 push 0000208c
[00002114][00103752][00002119] e893fbffff call 00001cac ; _HHH
RECK: test case allocated new simulation [1]: 00103766:00000000:00103786:001037c2:001037fe
New slave_stack at:1037fe
--Allocate (0003a980) --> 00113806
Begin Local Halt Decider Simulation Execution Trace Stored at:113806
RECK: 0000208c is _DDD
RECK: newly executing [1]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 001037FE
[1][0000208c][001137f6][001137fa] 55 push ebp
[1][0000208d][001137f6][001137fa] 8bec mov ebp,esp
[1][0000208f][001137f2][0000208c] 688c200000 push 0000208c
[1][00002094][001137ee][00002099] e813fcffff call 00001cac ; _HHH
RECK: test case allocated new simulation [2]: 0014e18e:00000000:0014e1ae:0014e1ea:0014e226
[1]New slave_stack at:14e226
RECK: 0000208c is _DDD
RECK: newly executing [2]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 0014E226
[2][0000208c][0015e21e][0015e222] 55 push ebp
[2][0000208d][0015e21e][0015e222] 8bec mov ebp,esp
[2][0000208f][0015e21a][0000208c] 688c200000 push 0000208c
[2][00002094][0015e216][00002099] e813fcffff call 00001cac ; _HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002119][0010375a][00000000] 83c404 add esp,+04
[0000211c][00103756][00000000] 50 push eax
[0000211d][00103752][000006c3] 68c3060000 push 000006c3
[00002122][00103752][000006c3] e845e6ffff call 0000076c ; VMI: _Output
Input_Halts = 0
[00002127][0010375a][00000000] 83c408 add esp,+08
[0000212a][0010375a][00000000] 33c0 xor eax,eax
[0000212c][0010375e][00000018] 5d pop ebp
[0000212d][00103762][00000000] c3 ret
Number of Instructions Executed(10578) == 158 Pages
RECK: ---------------
RECK: simulations for these function still exist:
RECK: [1]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 001037FE EIP == 00000b3d
RECK: [2]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 0014E226 EIP == 00001cac
RECK: ---------------
RECK: continuing simulation of [1]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 001037FE
RECK: test case allocated new simulation [3]: 0015e22e:00000000:0015e24e:0015e28a:0015e2c6
[2]New slave_stack at:15e2c6
[2]--Allocate (0003a980) --> 0016e2ce
[2]
Begin Local Halt Decider Simulation Execution Trace Stored at:16e2ce
RECK: 0000208c is _DDD
RECK: newly executing [3]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 0015E2C6
[3][0000208c][0016e2be][0016e2c2] 55 push ebp
[3][0000208d][0016e2be][0016e2c2] 8bec mov ebp,esp
[3][0000208f][0016e2ba][0000208c] 688c200000 push 0000208c
[3][00002094][0016e2b6][00002099] e813fcffff call 00001cac ; _HHH
RECK: test case allocated new simulation [4]: 001a8c56:00000000:001a8c76:001a8cb2:001a8cee
[3]New slave_stack at:1a8cee
RECK: 0000208c is _DDD
RECK: newly executing [4]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 001A8CEE
[4][0000208c][001b8ce6][001b8cea] 55 push ebp
[4][0000208d][001b8ce6][001b8cea] 8bec mov ebp,esp
[4][0000208f][001b8ce2][0000208c] 688c200000 push 0000208c
[4][00002094][001b8cde][00002099] e813fcffff call 00001cac ; _HHH
[2]Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[2][00002099][0015e21e][0015e222] 83c404 add esp,+04
[1]PushBack stdvector = 0x90909090 ! ### Ignoring erroneous call!
[2][0000209c][0015e222][00001d61] 5d pop ebp
[1]PushBack stdvector = 0x90909090 ! ### Ignoring erroneous call!
[2][0000209d][0015e226][00000018] c3 ret
[1]PushBack stdvector = 0x90909090 ! ### Ignoring erroneous call!
[1][00002099][001137f6][001137fa] 83c404 add esp,+04
[1][0000209c][001137fa][00001d61] 5d pop ebp
[1][0000209d][001137fe][0003a980] c3 ret
RECK: simulation of [1]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 001037FE reached
code_end!
RECK: ---------------
RECK: simulation of [2]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 0014E226 has
already ended!
RECK: while continuing the simulations listed above, further simulations
RECK: for these functions have been started:
RECK: [3]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 0015E2C6 EIP == 00000b3d
RECK: [4]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 001A8CEE EIP == 00001cac
RECK: ---------------
RECK: continuing simulation of [3]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 0015E2C6
RECK: test case allocated new simulation [5]: 001b8cf6:00000000:001b8d16:001b8d52:001b8d8e
[4]New slave_stack at:1b8d8e
[4]--Allocate (0003a980) --> 001c8d96
[4]
Begin Local Halt Decider Simulation Execution Trace Stored at:1c8d96
RECK: 0000208c is _DDD
RECK: newly executing [5]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 001B8D8E
[5][0000208c][001c8d86][001c8d8a] 55 push ebp
[5][0000208d][001c8d86][001c8d8a] 8bec mov ebp,esp
[5][0000208f][001c8d82][0000208c] 688c200000 push 0000208c
[5][00002094][001c8d7e][00002099] e813fcffff call 00001cac ; _HHH
RECK: test case allocated new simulation [6]: 0020371e:00000000:0020373e:0020377a:002037b6
[5]New slave_stack at:2037b6
RECK: 0000208c is _DDD
RECK: newly executing [6]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 002037B6
[6][0000208c][002137ae][002137b2] 55 push ebp
[6][0000208d][002137ae][002137b2] 8bec mov ebp,esp
[6][0000208f][002137aa][0000208c] 688c200000 push 0000208c
[6][00002094][002137a6][00002099] e813fcffff call 00001cac ; _HHH
[4]Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[4][00002099][001b8ce6][001b8cea] 83c404 add esp,+04
[3]PushBack stdvector = 0x90909090 ! ### Ignoring erroneous call!
[4][0000209c][001b8cea][00001d61] 5d pop ebp
[3]PushBack stdvector = 0x90909090 ! ### Ignoring erroneous call!
[4][0000209d][001b8cee][00000018] c3 ret
[3]PushBack stdvector = 0x90909090 ! ### Ignoring erroneous call!
[3][00002099][0016e2be][0016e2c2] 83c404 add esp,+04
[3][0000209c][0016e2c2][00001d61] 5d pop ebp
[3][0000209d][0016e2c6][0003a980] c3 ret
RECK: simulation of [3]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 0015E2C6 reached
code_end!
RECK: ---------------
RECK: simulation of [4]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 001A8CEE has
already ended!
RECK: while continuing the simulations listed above, further simulations
RECK: for these functions have been started:
RECK: [5]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 001B8D8E EIP == 00000b3d
RECK: [6]: entry == 0000208C (_DDD), code_end == 0000209D, stack == 002037B6 EIP == 00001cac
RECK: ---------------
... <INTERRUPTED>
==================================================================
Trace 2: [Latest HHH(DD)]
_DD()
[000020dc] 55 push ebp
[000020dd] 8bec mov ebp,esp
[000020df] 51 push ecx
[000020e0] 68dc200000 push 000020dc
[000020e5] e8c2fbffff call 00001cac
[000020ea] 83c404 add esp,+04
[000020ed] 8945fc mov [ebp-04],eax
[000020f0] 837dfc00 cmp dword [ebp-04],+00
[000020f4] 7402 jz 000020f8
[000020f6] ebfe jmp 000020f6
[000020f8] 8b45fc mov eax,[ebp-04]
[000020fb] 8be5 mov esp,ebp
[000020fd] 5d pop ebp
[000020fe] c3 ret
Size in bytes:(0035) [000020fe]
_main()
[0000210c] 55 push ebp
[0000210d] 8bec mov ebp,esp
[0000210f] 68dc200000 push 000020dc
[00002114] e893fbffff call 00001cac
[00002119] 83c404 add esp,+04
[0000211c] 50 push eax
[0000211d] 68c3060000 push 000006c3
[00002122] e845e6ffff call 0000076c
[00002127] 83c408 add esp,+08
[0000212a] 33c0 xor eax,eax
[0000212c] 5d pop ebp
[0000212d] c3 ret
Size in bytes:(0034) [0000212d]
S machine stack stack machine assembly
I address address data code language
M (before) (after) (after)
= ======== ======== ======== =============== =============
[0000210c][0010375a][00000000] 55 push ebp
[0000210d][0010375a][00000000] 8bec mov ebp,esp
[0000210f][00103756][000020dc] 68dc200000 push 000020dc
[00002114][00103752][00002119] e893fbffff call 00001cac ; _HHH
RECK: test case allocated new simulation [1]: 00103766:00000000:00103786:001037c2:001037fe
New slave_stack at:1037fe
Begin Local Halt Decider Simulation Execution Trace Stored at:113806
RECK: 000020dc is _DD
RECK: newly executing [1]: entry == 000020DC (_DD), code_end == 000020FE, stack == 001037FE
[1][000020dc][001137f6][001137fa] 55 push ebp
[1][000020dd][001137f6][001137fa] 8bec mov ebp,esp
[1][000020df][001137f2][001037fe] 51 push ecx
[1][000020e0][001137ee][000020dc] 68dc200000 push 000020dc
[1][000020e5][001137ea][000020ea] e8c2fbffff call 00001cac ; _HHH
RECK: test case allocated new simulation [2]: 0014e18e:00000000:0014e1ae:0014e1ea:0014e226
[1]New slave_stack at:14e226
RECK: 000020dc is _DD
RECK: newly executing [2]: entry == 000020DC (_DD), code_end == 000020FE, stack == 0014E226
[2][000020dc][0015e21e][0015e222] 55 push ebp
[2][000020dd][0015e21e][0015e222] 8bec mov ebp,esp
[2][000020df][0015e21a][0014e226] 51 push ecx
[2][000020e0][0015e216][000020dc] 68dc200000 push 000020dc
[2][000020e5][0015e212][000020ea] e8c2fbffff call 00001cac ; _HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002119][0010375a][00000000] 83c404 add esp,+04
[0000211c][00103756][00000000] 50 push eax
[0000211d][00103752][000006c3] 68c3060000 push 000006c3
[00002122][00103752][000006c3] e845e6ffff call 0000076c ; VMI: _Output
Input_Halts = 0
[00002127][0010375a][00000000] 83c408 add esp,+08
[0000212a][0010375a][00000000] 33c0 xor eax,eax
[0000212c][0010375e][00000018] 5d pop ebp
[0000212d][00103762][00000000] c3 ret
Number of Instructions Executed(12004) == 179 Pages
RECK: ---------------
RECK: simulations for these function still exist:
RECK: [1]: entry == 000020DC (_DD), code_end == 000020FE, stack == 001037FE EIP == 00000b3d
RECK: [2]: entry == 000020DC (_DD), code_end == 000020FE, stack == 0014E226 EIP == 00001cac
RECK: ---------------
RECK: continuing simulation of [1]: entry == 000020DC (_DD), code_end == 000020FE, stack == 001037FE
RECK: test case allocated new simulation [3]: 0015e22e:00000000:0015e24e:0015e28a:0015e2c6
[2]New slave_stack at:15e2c6
[2]
Begin Local Halt Decider Simulation Execution Trace Stored at:16e2ce
RECK: 000020dc is _DD
RECK: newly executing [3]: entry == 000020DC (_DD), code_end == 000020FE, stack == 0015E2C6
[3][000020dc][0016e2be][0016e2c2] 55 push ebp
[3][000020dd][0016e2be][0016e2c2] 8bec mov ebp,esp
[3][000020df][0016e2ba][0015e2c6] 51 push ecx
[3][000020e0][0016e2b6][000020dc] 68dc200000 push 000020dc
[3][000020e5][0016e2b2][000020ea] e8c2fbffff call 00001cac ; _HHH
RECK: test case allocated new simulation [4]: 001a8c56:00000000:001a8c76:001a8cb2:001a8cee
[3]New slave_stack at:1a8cee
RECK: 000020dc is _DD
RECK: newly executing [4]: entry == 000020DC (_DD), code_end == 000020FE, stack == 001A8CEE
[4][000020dc][001b8ce6][001b8cea] 55 push ebp
[4][000020dd][001b8ce6][001b8cea] 8bec mov ebp,esp
[4][000020df][001b8ce2][001a8cee] 51 push ecx
[4][000020e0][001b8cde][000020dc] 68dc200000 push 000020dc
[4][000020e5][001b8cda][000020ea] e8c2fbffff call 00001cac ; _HHH
[2]Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[2][000020ea][0015e21a][0014e226] 83c404 add esp,+04
[1]PushBack stdvector = 0x90909090 ! ### Ignoring erroneous call!
[2][000020ed][0015e21a][00000000] 8945fc mov [ebp-04],eax
[1]PushBack stdvector = 0x90909090 ! ### Ignoring erroneous call!
[2][000020f0][0015e21a][00000000] 837dfc00 cmp dword [ebp-04],+00
[1]PushBack stdvector = 0x90909090 ! ### Ignoring erroneous call!
[2][000020f4][0015e21a][00000000] 7402 jz 000020f8
[1]PushBack stdvector = 0x90909090 ! ### Ignoring erroneous call!
[2][000020f8][0015e21a][00000000] 8b45fc mov eax,[ebp-04]
[1]PushBack stdvector = 0x90909090 ! ### Ignoring erroneous call!
[2][000020fb][0015e21e][0015e222] 8be5 mov esp,ebp
[1]PushBack stdvector = 0x90909090 ! ### Ignoring erroneous call!
[2][000020fd][0015e222][00001d61] 5d pop ebp
[1]PushBack stdvector = 0x90909090 ! ### Ignoring erroneous call!
[2][000020fe][0015e226][00000018] c3 ret
[1]PushBack stdvector = 0x90909090 ! ### Ignoring erroneous call!
[1][000020ea][001137f2][001037fe] 83c404 add esp,+04
[1][000020ed][001137f2][00000001] 8945fc mov [ebp-04],eax
[1][000020f0][001137f2][00000001] 837dfc00 cmp dword [ebp-04],+00
[1][000020f4][001137f2][00000001] 7402 jz 000020f8
[1][000020f6][001137f2][00000001] ebfe jmp 000020f6
[1][000020f6][001137f2][00000001] ebfe jmp 000020f6
[1][000020f6][001137f2][00000001] ebfe jmp 000020f6
[1][000020f6][001137f2][00000001] ebfe jmp 000020f6
[1][000020f6][001137f2][00000001] ebfe jmp 000020f6
[1][000020f6][001137f2][00000001] ebfe jmp 000020f6
[1][000020f6][001137f2][00000001] ebfe jmp 000020f6
[1][000020f6][001137f2][00000001] ebfe jmp 000020f6
[1][000020f6][001137f2][00000001] ebfe jmp 000020f6
[1][000020f6][001137f2][00000001] ebfe jmp 000020f6
[1][000020f6][001137f2][00000001] ebfe jmp 000020f6
[1][000020f6][0011
... <INTERRUPTED>
==================================================================
Trace 3: [MJT_HHH(MJT_DD) pure code version of HHH(DD) ]
_MJT_DD()
[000021b2] 55 push ebp
[000021b3] 8bec mov ebp,esp
[000021b5] 51 push ecx
[000021b6] 68b2210000 push 000021b2
[000021bb] e832ffffff call 000020f2
[000021c0] 83c404 add esp,+04
[000021c3] 8945fc mov [ebp-04],eax
[000021c6] 837dfc00 cmp dword [ebp-04],+00
[000021ca] 7402 jz 000021ce
[000021cc] ebfe jmp 000021cc
[000021ce] 8b45fc mov eax,[ebp-04]
[000021d1] 8be5 mov esp,ebp
[000021d3] 5d pop ebp
[000021d4] c3 ret
Size in bytes:(0035) [000021d4]
_main()
[00002562] 55 push ebp
[00002563] 8bec mov ebp,esp
[00002565] 68b2210000 push 000021b2
[0000256a] e883fbffff call 000020f2
[0000256f] 83c404 add esp,+04
[00002572] 50 push eax
[00002573] 68a3070000 push 000007a3
[00002578] e845e2ffff call 000007c2
[0000257d] 83c408 add esp,+08
[00002580] 33c0 xor eax,eax
[00002582] 5d pop ebp
[00002583] c3 ret
Size in bytes:(0034) [00002583]
S machine stack stack machine assembly
I address address data code language
M (before) (after) (after)
= ======== ======== ======== =============== =============
[00002562][00103e94][00000000] 55 push ebp
[00002563][00103e94][00000000] 8bec mov ebp,esp
[00002565][00103e90][000021b2] 68b2210000 push 000021b2
[0000256a][00103e8c][0000256f] e883fbffff call 000020f2 ; _MJT_HHH
RECK: test case allocated new simulation [1]: 00103ea0:00000000:00103ec0:00103efc:00103f38
New slave_stack at:103f38
Begin Local Halt Decider Simulation Execution Trace Stored at:113f40
RECK: 000021b2 is _MJT_DD
RECK: newly executing [1]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00103F38
[1][000021b2][00113f30][00113f34] 55 push ebp
[1][000021b3][00113f30][00113f34] 8bec mov ebp,esp
[1][000021b5][00113f2c][00103f38] 51 push ecx
[1][000021b6][00113f28][000021b2] 68b2210000 push 000021b2
[1][000021bb][00113f24][000021c0] e832ffffff call 000020f2 ; _MJT_HHH
RECK: test case allocated new simulation [2]: 0014e8c8:00000000:0014e8e8:0014e924:0014e960
[1]New slave_stack at:14e960
[1]
Begin Local Halt Decider Simulation Execution Trace Stored at:15e968
RECK: 000021b2 is _MJT_DD
RECK: newly executing [2]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 0014E960
[2][000021b2][0015e958][0015e95c] 55 push ebp
[2][000021b3][0015e958][0015e95c] 8bec mov ebp,esp
[2][000021b5][0015e954][0014e960] 51 push ecx
[2][000021b6][0015e950][000021b2] 68b2210000 push 000021b2
[2][000021bb][0015e94c][000021c0] e832ffffff call 000020f2 ; _MJT_HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[0000256f][00103e94][00000000] 83c404 add esp,+04
[00002572][00103e90][00000000] 50 push eax
[00002573][00103e8c][000007a3] 68a3070000 push 000007a3
[00002578][00103e8c][000007a3] e845e2ffff call 000007c2 ; VMI: _Output
Input_Halts = 0
[0000257d][00103e94][00000000] 83c408 add esp,+08
[00002580][00103e94][00000000] 33c0 xor eax,eax
[00002582][00103e98][00000018] 5d pop ebp
[00002583][00103e9c][00000000] c3 ret
Number of Instructions Executed(12189) == 182 Pages
RECK: ---------------
RECK: simulations for these function still exist:
RECK: [1]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00103F38 EIP == 00001ecd
RECK: [2]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 0014E960 EIP == 000020f2
RECK: ---------------
RECK: continuing simulation of [1]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00103F38
RECK: test case allocated new simulation [3]: 001992f0:00000000:00199310:0019934c:00199388
[2]New slave_stack at:199388
[2]
Begin Local Halt Decider Simulation Execution Trace Stored at:1a9390
RECK: 000021b2 is _MJT_DD
RECK: newly executing [3]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00199388
[3][000021b2][001a9380][001a9384] 55 push ebp
[3][000021b3][001a9380][001a9384] 8bec mov ebp,esp
[3][000021b5][001a937c][00199388] 51 push ecx
[3][000021b6][001a9378][000021b2] 68b2210000 push 000021b2
[3][000021bb][001a9374][000021c0] e832ffffff call 000020f2 ; _MJT_HHH
[1]Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[1][000021c0][00113f2c][00103f38] 83c404 add esp,+04
[1][000021c3][00113f2c][00000000] 8945fc mov [ebp-04],eax
[1][000021c6][00113f2c][00000000] 837dfc00 cmp dword [ebp-04],+00
[1][000021ca][00113f2c][00000000] 7402 jz 000021ce
[1][000021ce][00113f2c][00000000] 8b45fc mov eax,[ebp-04]
[1][000021d1][00113f30][00113f34] 8be5 mov esp,ebp
[1][000021d3][00113f34][00002179] 5d pop ebp
[1][000021d4][00113f38][0003a980] c3 ret
RECK: simulation of [1]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00103F38
reached code_end!
RECK: ---------------
RECK: continuing simulation of [2]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 0014E960
RECK: test case allocated new simulation [4]: 001e3d18:00000000:001e3d38:001e3d74:001e3db0
[3]New slave_stack at:1e3db0
[3]
Begin Local Halt Decider Simulation Execution Trace Stored at:1f3db8
RECK: 000021b2 is _MJT_DD
RECK: newly executing [4]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 001E3DB0
[4][000021b2][001f3da8][001f3dac] 55 push ebp
[4][000021b3][001f3da8][001f3dac] 8bec mov ebp,esp
[4][000021b5][001f3da4][001e3db0] 51 push ecx
[4][000021b6][001f3da0][000021b2] 68b2210000 push 000021b2
[4][000021bb][001f3d9c][000021c0] e832ffffff call 000020f2 ; _MJT_HHH
[2]Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[2][000021c0][0015e954][0014e960] 83c404 add esp,+04
[2][000021c3][0015e954][00000000] 8945fc mov [ebp-04],eax
[2][000021c6][0015e954][00000000] 837dfc00 cmp dword [ebp-04],+00
[2][000021ca][0015e954][00000000] 7402 jz 000021ce
[2][000021ce][0015e954][00000000] 8b45fc mov eax,[ebp-04]
[2][000021d1][0015e958][0015e95c] 8be5 mov esp,ebp
[2][000021d3][0015e95c][00002179] 5d pop ebp
[2][000021d4][0015e960][0003a980] c3 ret
RECK: simulation of [2]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 0014E960
reached code_end!
RECK: while continuing the simulations listed above, further simulations
RECK: for these functions have been started:
RECK: [3]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00199388 EIP == 00001ecd
RECK: [4]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 001E3DB0 EIP == 000020f2
RECK: ---------------
RECK: continuing simulation of [3]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00199388
RECK: test case allocated new simulation [5]: 0022e740:00000000:0022e760:0022e79c:0022e7d8
[4]New slave_stack at:22e7d8
[4]
Begin Local Halt Decider Simulation Execution Trace Stored at:23e7e0
RECK: 000021b2 is _MJT_DD
RECK: newly executing [5]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 0022E7D8
[5][000021b2][0023e7d0][0023e7d4] 55 push ebp
[5][000021b3][0023e7d0][0023e7d4] 8bec mov ebp,esp
[5][000021b5][0023e7cc][0022e7d8] 51 push ecx
[5][000021b6][0023e7c8][000021b2] 68b2210000 push 000021b2
[5][000021bb][0023e7c4][000021c0] e832ffffff call 000020f2 ; _MJT_HHH
[3]Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[3][000021c0][001a937c][00199388] 83c404 add esp,+04
[3][000021c3][001a937c][00000000] 8945fc mov [ebp-04],eax
[3][000021c6][001a937c][00000000] 837dfc00 cmp dword [ebp-04],+00
[3][000021ca][001a937c][00000000] 7402 jz 000021ce
[3][000021ce][001a937c][00000000] 8b45fc mov eax,[ebp-04]
[3][000021d1][001a9380][001a9384] 8be5 mov esp,ebp
[3][000021d3][001a9384][00002179] 5d pop ebp
[3][000021d4][001a9388][0003a980] c3 ret
RECK: simulation of [3]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00199388
reached code_end!
RECK: ---------------
RECK: continuing simulation of [4]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 001E3DB0
RECK: test case allocated new simulation [6]: 00279168:00000000:00279188:002791c4:00279200
[5]New slave_stack at:279200
[5]
Begin Local Halt Decider Simulation Execution Trace Stored at:289208
RECK: 000021b2 is _MJT_DD
RECK: newly executing [6]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00279200
[6][000021b2][002891f8][002891fc] 55 push ebp
[6][000021b3][002891f8][002891fc] 8bec mov ebp,esp
[6][000021b5][002891f4][00279200] 51 push ecx
[6][000021b6][002891f0][000021b2] 68b2210000 push 000021b2
[6][000021bb][002891ec][000021c0] e832ffffff call 000020f2 ; _MJT_HHH
[4]Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[4][000021c0][001f3da4][001e3db0] 83c404 add esp,+04
[4][000021c3][001f3da4][00000000] 8945fc mov [ebp-04],eax
[4][000021c6][001f3da4][00000000] 837dfc00 cmp dword [ebp-04],+00
[4][000021ca][001f3da4][00000000] 7402 jz 000021ce
[4][000021ce][001f3da4][00000000] 8b45fc mov eax,[ebp-04]
[4][000021d1][001f3da8][001f3dac] 8be5 mov esp,ebp
[4][000021d3][001f3dac][00002179] 5d pop ebp
[4][000021d4][001f3db0][0003a980] c3 ret
RECK: simulation of [4]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 001E3DB0
reached code_end!
RECK: while continuing the simulations listed above, further simulations
RECK: for these functions have been started:
RECK: [5]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 0022E7D8 EIP == 00001ecd
RECK: [6]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00279200 EIP == 000020f2
RECK: ---------------
RECK: continuing simulation of [5]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 0022E7D8
RECK: test case allocated new simulation [7]: 002c3b90:00000000:002c3bb0:002c3bec:002c3c28
[6]New slave_stack at:2c3c28
[6]
Begin Local Halt Decider Simulation Execution Trace Stored at:2d3c30
RECK: 000021b2 is _MJT_DD
RECK: newly executing [7]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 002C3C28
[7][000021b2][002d3c20][002d3c24] 55 push ebp
[7][000021b3][002d3c20][002d3c24] 8bec mov ebp,esp
[7][000021b5][002d3c1c][002c3c28] 51 push ecx
[7][000021b6][002d3c18][000021b2] 68b2210000 push 000021b2
[7][000021bb][002d3c14][000021c0] e832ffffff call 000020f2 ; _MJT_HHH
[5]Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[5][000021c0][0023e7cc][0022e7d8] 83c404 add esp,+04
[5][000021c3][0023e7cc][00000000] 8945fc mov [ebp-04],eax
[5][000021c6][0023e7cc][00000000] 837dfc00 cmp dword [ebp-04],+00
[5][000021ca][0023e7cc][00000000] 7402 jz 000021ce
[5][000021ce][0023e7cc][00000000] 8b45fc mov eax,[ebp-04]
[5][000021d1][0023e7d0][0023e7d4] 8be5 mov esp,ebp
[5][000021d3][0023e7d4][00002179] 5d pop ebp
[5][000021d4][0023e7d8][0003a980] c3 ret
RECK: simulation of [5]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 0022E7D8
reached code_end!
RECK: ---------------
RECK: continuing simulation of [6]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00279200
RECK: test case allocated new simulation [8]: 0030e5b8:00000000:0030e5d8:0030e614:0030e650
[7]New slave_stack at:30e650
[7]
Begin Local Halt Decider Simulation Execution Trace Stored at:31e658
RECK: 000021b2 is _MJT_DD
RECK: newly executing [8]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 0030E650
[8][000021b2][0031e648][0031e64c] 55 push ebp
[8][000021b3][0031e648][0031e64c] 8bec mov ebp,esp
[8][000021b5][0031e644][0030e650] 51 push ecx
[8][000021b6][0031e640][000021b2] 68b2210000 push 000021b2
[8][000021bb][0031e63c][000021c0] e832ffffff call 000020f2 ; _MJT_HHH
[6]Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[6][000021c0][002891f4][00279200] 83c404 add esp,+04
[6][000021c3][002891f4][00000000] 8945fc mov [ebp-04],eax
[6][000021c6][002891f4][00000000] 837dfc00 cmp dword [ebp-04],+00
[6][000021ca][002891f4][00000000] 7402 jz 000021ce
[6][000021ce][002891f4][00000000] 8b45fc mov eax,[ebp-04]
[6][000021d1][002891f8][002891fc] 8be5 mov esp,ebp
[6][000021d3][002891fc][00002179] 5d pop ebp
[6][000021d4][00289200][0003a980] c3 ret
RECK: simulation of [6]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00279200
reached code_end!
... <INTERRUPTED>
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-04 18:36 +0000 |
| Message-ID | <20251104102813.682@kylheku.com> |
| In reply to | #135015 |
On 2025-11-04, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: > Below are 3 traces with different inputs. I'm sure you'll have run the first two yourself, but the > third will be new (but not surprising...) I modified your code somewhat to make it resume all the > outstanding simulations (until interrupted), and to integrate with my "simulation depth" reporting - > that's the SIM column on the left of the traces. Also my play code has "rationalised" log output so > your resumptions show the (filtered) trace instructions executed. [That came for free without > changing your code.] So I'd say the traces below are clearer than previously posted, if only > because you can see which simulation level is producing the various output messages! PO once added > code to add the simulation level to the instruction trace output, but then removed it, saying it > confused people! You clarified the situation with PushBack as being a case of the execution_trace pointer becoming invalidated to 0x90909090, and the memory at that address looking like a full buffer. The code could just check for that 0x90909090 value, and in that case drop the sample and return, to tie things over until a buffer reappears. > Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but > without the global variable misuse. HHH[0] decides non-halting. > Resumed simulations all halt with same behaviour as HHH[n] deciding > non-halting (like HHH[0]) then DDD[n] returning. > DDD[1] ends, after HHH[1] detects "infinite recursion" and returns 0. > DDD[2] ends, after HHH[2] detects "infinite recursion" and returns 0. > DDD[3] ends, after HHH[3] detects "infinite recursion" and returns 0. > DDD[4] ends, after HHH[4] detects "infinite recursion" and returns 0. Nice. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-04 18:59 +0000 |
| Message-ID | <10edidv$3s0lk$1@dont-email.me> |
| In reply to | #135018 |
On 04/11/2025 18:36, Kaz Kylheku wrote: > On 2025-11-04, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >> Below are 3 traces with different inputs. I'm sure you'll have run the first two yourself, but the >> third will be new (but not surprising...) I modified your code somewhat to make it resume all the >> outstanding simulations (until interrupted), and to integrate with my "simulation depth" reporting - >> that's the SIM column on the left of the traces. Also my play code has "rationalised" log output so >> your resumptions show the (filtered) trace instructions executed. [That came for free without >> changing your code.] So I'd say the traces below are clearer than previously posted, if only >> because you can see which simulation level is producing the various output messages! PO once added >> code to add the simulation level to the instruction trace output, but then removed it, saying it >> confused people! > > You clarified the situation with PushBack as being a case of the > execution_trace pointer becoming invalidated to 0x90909090, and the > memory at that address looking like a full buffer. The code could just > check for that 0x90909090 value, and in that case drop the sample and > return, to tie things over until a buffer reappears. That's more or less what my code for PushBack does - I changed it to check and ignore requests for that buffer address - it gives a message when it does this, and there are such messages appearing in the Trace 1 and Trace 2 output. It's not doing much harm to ignore them, as it seems they are only produced by the simulation that is currently being resumed. That simulation is trying to report a trace event to the "outer HHH", but of course that is well and truly gone by this point so there is nothing waiting to analyse those entries. [Bottom line I suppose is the resumptions are heading into undefined behaviour, as long as PO's code is misusing global variables. Once we have pure code the whole resumption idea makes good sense... Mike. > >> Trace 3: MJT_HHH(MJT_DD). These have the same abort logic as HHH, but >> without the global variable misuse. HHH[0] decides non-halting. >> Resumed simulations all halt with same behaviour as HHH[n] deciding >> non-halting (like HHH[0]) then DDD[n] returning. >> DDD[1] ends, after HHH[1] detects "infinite recursion" and returns 0. >> DDD[2] ends, after HHH[2] detects "infinite recursion" and returns 0. >> DDD[3] ends, after HHH[3] detects "infinite recursion" and returns 0. >> DDD[4] ends, after HHH[4] detects "infinite recursion" and returns 0. > > Nice. >
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-04 19:36 +0000 |
| Message-ID | <20251104113331.177@kylheku.com> |
| In reply to | #135015 |
On 2025-11-04, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: > DDD[1] ends, after HHH[1] detects "infinite recursion" and returns 0. > DDD[2] ends, after HHH[2] detects "infinite recursion" and returns 0. > DDD[3] ends, after HHH[3] detects "infinite recursion" and returns 0. > DDD[4] ends, after HHH[4] detects "infinite recursion" and returns 0. If every HHH deallocates the memory resources of the terminated DDD, this should be able to keep running indefinitely. There is no recursion chewing up a single linear stack that will overflow. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-04 21:03 +0000 |
| Message-ID | <10edpme$3ugoj$1@dont-email.me> |
| In reply to | #135020 |
On 04/11/2025 19:36, Kaz Kylheku wrote: > On 2025-11-04, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >> DDD[1] ends, after HHH[1] detects "infinite recursion" and returns 0. >> DDD[2] ends, after HHH[2] detects "infinite recursion" and returns 0. >> DDD[3] ends, after HHH[3] detects "infinite recursion" and returns 0. >> DDD[4] ends, after HHH[4] detects "infinite recursion" and returns 0. > > If every HHH deallocates the memory resources of the terminated DDD, > this should be able to keep running indefinitely. > > There is no recursion chewing up a single linear stack that will > overflow. > True. With the code as it is, it didn't last very long before out of memory: ..... RECK: --------------- RECK: continuing simulation of [50]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00F4D0E0 [51]--Allocate (00000018) --> 00fe2498 [51]--Allocate (00000034) --> 00fe24b8 [51]--Allocate (00000034) --> 00fe24f4 [51]--Allocate (00010000) --> 00fe2530 RECK: test case allocated new simulation [52]: 00fe2498:00000000:00fe24b8:00fe24f4:00fe2530 [51]New slave_stack at:fe2530 [51]--Allocate(240000) failed [51] Begin Local Halt Decider Simulation Execution Trace Stored at:0 RECK: 000021b2 is _MJT_DD RECK: newly executing [52]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00FE2530 [52][000021b2][00ff2528][00ff252c] 55 push ebp Ran out of memory@ Address[00000000] So it ran out while resuming MJT_DD[50]. Like you say, the progress was linear, because each new level resumed is like the original first level simulation, so there's no slowing down as we get deeper. The whole virtual address space is 32-bit, so 4GB. x86utm has no support for releasing Allocate()ed memory... Mike.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-04 21:58 +0000 |
| Message-ID | <20251104134343.652@kylheku.com> |
| In reply to | #135027 |
On 2025-11-04, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: > On 04/11/2025 19:36, Kaz Kylheku wrote: >> On 2025-11-04, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >>> DDD[1] ends, after HHH[1] detects "infinite recursion" and returns 0. >>> DDD[2] ends, after HHH[2] detects "infinite recursion" and returns 0. >>> DDD[3] ends, after HHH[3] detects "infinite recursion" and returns 0. >>> DDD[4] ends, after HHH[4] detects "infinite recursion" and returns 0. >> >> If every HHH deallocates the memory resources of the terminated DDD, >> this should be able to keep running indefinitely. >> >> There is no recursion chewing up a single linear stack that will >> overflow. >> > True. With the code as it is, it didn't last very long before out of memory: > > ..... > RECK: --------------- > RECK: continuing simulation of [50]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == > 00F4D0E0 > [51]--Allocate (00000018) --> 00fe2498 > [51]--Allocate (00000034) --> 00fe24b8 > [51]--Allocate (00000034) --> 00fe24f4 > [51]--Allocate (00010000) --> 00fe2530 > RECK: test case allocated new simulation [52]: 00fe2498:00000000:00fe24b8:00fe24f4:00fe2530 > [51]New slave_stack at:fe2530 > [51]--Allocate(240000) failed > [51] > Begin Local Halt Decider Simulation Execution Trace Stored at:0 > RECK: 000021b2 is _MJT_DD > RECK: newly executing [52]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00FE2530 > [52][000021b2][00ff2528][00ff252c] 55 push ebp > Ran out of memory@ Address[00000000] > > So it ran out while resuming MJT_DD[50]. Like you say, the progress was linear, because each new > level resumed is like the original first level simulation, so there's no slowing down as we get > deeper. Each new level is resumed using a DebugStep() loop inside a function in reckoning.cc, which runs on the host processor directly, and so it strips away the any extra layer of interpreter penalty under which that simulation had operated prior to being resumed. In principle, it could be compiled for a different machine; if you port and build x86utm for an ARM, our DebugStep loop in reckoning.cc will be ARM code, calling into an ARM-compiled DebugStep, calling into an ARM-compiled x86emu. DebugStep itself is always native, regardless of the simulation level from which it is invoked; the x86emu code comprising it is never simulated. When test cases like HHH call DebugStep (via a simplified API), that is recognized by the VM and treated as one giant "microcoded" instruction coded inside x86utm_exe. (The idea of the x86 emulator recognizing certain function calls and implementing them as "microcode" is a decent hack. I don't like that it performs string comparisons on function names to do the dispatch. I.e. when a CALL instruction is handled, the destination address is first mapped to a name using the COFF reader context and then string comparisons check that name against a vocabulary of function names handled directly by the VM. Regardless, Olcott did a good job in that regard; it's unclear why he's acting so dumb now. Maybe a decade of cognitive decline? If that's literally the ony thing he coded in ten years, and isn't working in any job, that's not enough to keep the brain from turning into mush.) > The whole virtual address space is 32-bit, so 4GB. x86utm has no support for releasing > Allocate()ed memory... Right, OK; So if a Free() function were were added and used, then the memory pressure should stabilize around a certain level of fragmentation and allow the thing to keep runnning. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-05 01:20 +0000 |
| Message-ID | <10ee8pf$2rds$1@dont-email.me> |
| In reply to | #135032 |
On 04/11/2025 21:58, Kaz Kylheku wrote: > On 2025-11-04, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >> On 04/11/2025 19:36, Kaz Kylheku wrote: >>> On 2025-11-04, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >>>> DDD[1] ends, after HHH[1] detects "infinite recursion" and returns 0. >>>> DDD[2] ends, after HHH[2] detects "infinite recursion" and returns 0. >>>> DDD[3] ends, after HHH[3] detects "infinite recursion" and returns 0. >>>> DDD[4] ends, after HHH[4] detects "infinite recursion" and returns 0. >>> >>> If every HHH deallocates the memory resources of the terminated DDD, >>> this should be able to keep running indefinitely. >>> >>> There is no recursion chewing up a single linear stack that will >>> overflow. >>> >> True. With the code as it is, it didn't last very long before out of memory: >> >> ..... >> RECK: --------------- >> RECK: continuing simulation of [50]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == >> 00F4D0E0 >> [51]--Allocate (00000018) --> 00fe2498 >> [51]--Allocate (00000034) --> 00fe24b8 >> [51]--Allocate (00000034) --> 00fe24f4 >> [51]--Allocate (00010000) --> 00fe2530 >> RECK: test case allocated new simulation [52]: 00fe2498:00000000:00fe24b8:00fe24f4:00fe2530 >> [51]New slave_stack at:fe2530 >> [51]--Allocate(240000) failed >> [51] >> Begin Local Halt Decider Simulation Execution Trace Stored at:0 >> RECK: 000021b2 is _MJT_DD >> RECK: newly executing [52]: entry == 000021B2 (_MJT_DD), code_end == 000021D4, stack == 00FE2530 >> [52][000021b2][00ff2528][00ff252c] 55 push ebp >> Ran out of memory@ Address[00000000] >> >> So it ran out while resuming MJT_DD[50]. Like you say, the progress was linear, because each new >> level resumed is like the original first level simulation, so there's no slowing down as we get >> deeper. > > Each new level is resumed using a DebugStep() loop inside a function in > reckoning.cc, which runs on the host processor directly, and so it > strips away the any extra layer of interpreter penalty under which that > simulation had operated prior to being resumed. That works fine. Another idea would be to call LoadState() once, and for your loop to call Execute_Instruction() rather than DebugStep(). (Execute_Instruction() is how the outer code is executed, i.e. HHH[0] etc.. It would come out much the same I think, but saving all the LoadState/SaveState per-instruction calls. OTOH using DebugStep() is probably more 'logical' - making fewer assumptions about how simulation is implemented...) > > In principle, it could be compiled for a different machine; if you port > and build x86utm for an ARM, our DebugStep loop in reckoning.cc will be > ARM code, calling into an ARM-compiled DebugStep, calling into an > ARM-compiled x86emu. > > DebugStep itself is always native, regardless of the simulation level > from which it is invoked; the x86emu code comprising it is never > simulated. When test cases like HHH call DebugStep (via a simplified > API), that is recognized by the VM and treated as one giant "microcoded" > instruction coded inside x86utm_exe. > > (The idea of the x86 emulator recognizing certain function calls and > implementing them as "microcode" is a decent hack. I don't like that > it performs string comparisons on function names to do the dispatch. > I.e. when a CALL instruction is handled, the destination address > is first mapped to a name using the COFF reader context and then > string comparisons check that name against a vocabulary of function > names handled directly by the VM. Regardless, Olcott did a good > job in that regard; it's unclear why he's acting so dumb now. Maybe a > decade of cognitive decline? If that's literally the ony thing he coded > in ten years, and isn't working in any job, that's not enough to keep > the brain from turning into mush.) Yeah, I think PO's implementation on that front is ok. On a real OS, some SVC-like processor instruction would be used, but that's not callable via C without ASM extensions. An OS would provide C-callable stubs you could link with, but PO's approach is light-weight and works, keeping everything in one obj file. [He could have declared DebugStep() et al. as extern in halt7.c rather than having to code empty dummy routines, but hey-ho!] I don't really see that PO has declined recently - It seems to me he's been the way he is for as long as I recall. I would say he's become markedly ruder of late, though! Maybe that's all related to his LLMs pandering to his delusions and giving him a renewed confidence. Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-04 20:14 -0600 |
| Subject | Kaz does not understand his own code. |
| Message-ID | <10eebun$3lq7$1@dont-email.me> |
| In reply to | #135039 |
On 11/4/2025 7:20 PM, Mike Terry wrote:
>
> I don't really see that PO has declined recently - It seems to me he's
> been the way he is for as long as I recall. I would say he's become
> markedly ruder of late, though! Maybe that's all related to his LLMs
> pandering to his delusions and giving him a renewed confidence.
>
>
> Mike.
>
>
news://news.eternal-september.org/20251103195844.661@kylheku.com
On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>
> How about this minimal viable H:
>
> #include <interpret.h> // C interpreter's own API
>
> bool H(fptr P)
> {
> interp *s = interp_init(P);
>
> for (int i = 0; i < 3; i++) {
> if (interp_step(s))
> return true;
> }
>
> return false;
> }
>
> H initializes an interpreter for its argument P.
> Then it applies a very simple abort logic: it
> steps the interpreter state three times. If
> during those three steps, P terminates, it returns
> true. Otherwise it assumes P is nonterminating and
> returns false.
>
> (Pretend that more complicated abort criteria are there.)
>
> The interpreter API consists of primitives built
> into the system, so it isn't traced.
>
> So then we have D:
>
> void D(void)
> {
> if (H(D)) { for (;;); }
> return;
> }
>
> Let's trace H(D). We indicate the simulation levels from 0,
> step numbers from 1 within each level, with a bit of indentation
> to tell apart the levels:
>
*This is the part that Kaz does not understand*
i == 0 reaches if (interp_step(s))
i == 1 reaches if (interp_step(s))
i == 2 reaches if (interp_step(s))
i == 3 NEVER reaches if (interp_step(s))
The whole point is that D simulated by H
cannot possbly reach its own simulated
"return" statement no matter what H does.
If we continue the simulation with the exact
same machine state then H simply returns false
because i == 3.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-05 02:43 +0000 |
| Subject | Re: Kaz does not understand his own code. |
| Message-ID | <20251104183329.967@kylheku.com> |
| In reply to | #135041 |
On 2025-11-05, olcott <polcott333@gmail.com> wrote:
> On 11/4/2025 7:20 PM, Mike Terry wrote:
>>
>> I don't really see that PO has declined recently - It seems to me he's
>> been the way he is for as long as I recall. I would say he's become
>> markedly ruder of late, though! Maybe that's all related to his LLMs
>> pandering to his delusions and giving him a renewed confidence.
>>
>>
>> Mike.
>>
>>
>
> news://news.eternal-september.org/20251103195844.661@kylheku.com
>
> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
> >
> > How about this minimal viable H:
> >
> > #include <interpret.h> // C interpreter's own API
> >
> > bool H(fptr P)
> > {
> > interp *s = interp_init(P);
> >
> > for (int i = 0; i < 3; i++) {
> > if (interp_step(s))
> > return true;
> > }
> >
> > return false;
> > }
> >
> > H initializes an interpreter for its argument P.
> > Then it applies a very simple abort logic: it
> > steps the interpreter state three times. If
> > during those three steps, P terminates, it returns
> > true. Otherwise it assumes P is nonterminating and
> > returns false.
> >
> > (Pretend that more complicated abort criteria are there.)
> >
> > The interpreter API consists of primitives built
> > into the system, so it isn't traced.
> >
> > So then we have D:
> >
> > void D(void)
> > {
> > if (H(D)) { for (;;); }
> > return;
> > }
> >
> > Let's trace H(D). We indicate the simulation levels from 0,
> > step numbers from 1 within each level, with a bit of indentation
> > to tell apart the levels:
> >
>
> *This is the part that Kaz does not understand*
>
> i == 0 reaches if (interp_step(s))
> i == 1 reaches if (interp_step(s))
> i == 2 reaches if (interp_step(s))
> i == 3 NEVER reaches if (interp_step(s))
>
> The whole point is that D simulated by H
> cannot possbly reach its own simulated
> "return" statement no matter what H does.
Yes; this doesn't happen while H is running.
So while H does /something/, no matter what H does, that D simulation
won't reach the return statement.
H has to return zero first and terminate, leaving the simulation
abandoned.
That's the one thing that H can "do" which then lets D
reach its return statement.
Then the simulation framework itself picks up that simuation
and does the stepping.
> If we continue the simulation with the exact
> same machine state then H simply returns false
> because i == 3.
Remember, we are not continuing the top level H,
which terminated and returned zero, but the simulated
D which is calling the simulated H.
That simulated H is just getting into the loop. Continued, it takes i
from 0 to i == 3, and returns false.
Where does it return? To the simulated D!
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-04 21:06 -0600 |
| Subject | Re: Kaz does not understand his own code. |
| Message-ID | <10eeevn$4anq$1@dont-email.me> |
| In reply to | #135043 |
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
> On 2025-11-05, olcott <polcott333@gmail.com> wrote:
>> On 11/4/2025 7:20 PM, Mike Terry wrote:
>>>
>>> I don't really see that PO has declined recently - It seems to me he's
>>> been the way he is for as long as I recall. I would say he's become
>>> markedly ruder of late, though! Maybe that's all related to his LLMs
>>> pandering to his delusions and giving him a renewed confidence.
>>>
>>>
>>> Mike.
>>>
>>>
>>
>> news://news.eternal-september.org/20251103195844.661@kylheku.com
>>
>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>
>>> How about this minimal viable H:
>>>
>>> #include <interpret.h> // C interpreter's own API
>>>
>>> bool H(fptr P)
>>> {
>>> interp *s = interp_init(P);
>>>
>>> for (int i = 0; i < 3; i++) {
>>> if (interp_step(s))
>>> return true;
>>> }
>>>
>>> return false;
>>> }
>>>
>>> H initializes an interpreter for its argument P.
>>> Then it applies a very simple abort logic: it
>>> steps the interpreter state three times. If
>>> during those three steps, P terminates, it returns
>>> true. Otherwise it assumes P is nonterminating and
>>> returns false.
>>>
>>> (Pretend that more complicated abort criteria are there.)
>>>
>>> The interpreter API consists of primitives built
>>> into the system, so it isn't traced.
>>>
>>> So then we have D:
>>>
>>> void D(void)
>>> {
>>> if (H(D)) { for (;;); }
>>> return;
>>> }
>>>
>>> Let's trace H(D). We indicate the simulation levels from 0,
>>> step numbers from 1 within each level, with a bit of indentation
>>> to tell apart the levels:
>>>
>>
>> *This is the part that Kaz does not understand*
>>
>> i == 0 reaches if (interp_step(s))
>> i == 1 reaches if (interp_step(s))
>> i == 2 reaches if (interp_step(s))
>> i == 3 NEVER reaches if (interp_step(s))
>>
>> The whole point is that D simulated by H
>> cannot possbly reach its own simulated
>> "return" statement no matter what H does.
>
> Yes; this doesn't happen while H is running.
>
> So while H does /something/, no matter what H does, that D simulation
> won't reach the return statement.
>
> H has to return zero first and terminate, leaving the simulation
> abandoned.
>
Just like leaving the Infinite_loop() abandoned.
> That's the one thing that H can "do" which then lets D
> reach its return statement.
>
When H has stopped simulating D then a resumption
of the exact same machine state of this simulation
would simply be the point where H rejected D.
> Then the simulation framework itself picks up that simuation
> and does the stepping.
>
If the simulation framework resumes the simulation
at the exact same machine state with H local i == 3
and H already returned to the simulation framework
then resuming the simulation cannot do anything more
than immediately return to the simulation framework.
>> If we continue the simulation with the exact
>> same machine state then H simply returns false
>> because i == 3.
>
> Remember, we are not continuing the top level H,
> which terminated and returned zero, but the simulated
> D which is calling the simulated H.
>
When we actually literally resume the simulation
then it must be the exact same machine state of
the whole system at the point just after H returned
false to the simulation framework.
If we don't do exactly this then we are not actually
resuming anything.
> That simulated H is just getting into the loop. Continued, it takes i
> from 0 to i == 3, and returns false.
>
> Where does it return? To the simulated D!
>
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-05 03:33 +0000 |
| Subject | Re: Kaz does not understand his own code. |
| Message-ID | <20251104192046.639@kylheku.com> |
| In reply to | #135044 |
On 2025-11-05, olcott <polcott333@gmail.com> wrote:
> On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
>> On 2025-11-05, olcott <polcott333@gmail.com> wrote:
>>> On 11/4/2025 7:20 PM, Mike Terry wrote:
>>>>
>>>> I don't really see that PO has declined recently - It seems to me he's
>>>> been the way he is for as long as I recall. I would say he's become
>>>> markedly ruder of late, though! Maybe that's all related to his LLMs
>>>> pandering to his delusions and giving him a renewed confidence.
>>>>
>>>>
>>>> Mike.
>>>>
>>>>
>>>
>>> news://news.eternal-september.org/20251103195844.661@kylheku.com
>>>
>>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>>
>>>> How about this minimal viable H:
>>>>
>>>> #include <interpret.h> // C interpreter's own API
>>>>
>>>> bool H(fptr P)
>>>> {
>>>> interp *s = interp_init(P);
>>>>
>>>> for (int i = 0; i < 3; i++) {
>>>> if (interp_step(s))
>>>> return true;
>>>> }
>>>>
>>>> return false;
>>>> }
>>>>
>>>> H initializes an interpreter for its argument P.
>>>> Then it applies a very simple abort logic: it
>>>> steps the interpreter state three times. If
>>>> during those three steps, P terminates, it returns
>>>> true. Otherwise it assumes P is nonterminating and
>>>> returns false.
>>>>
>>>> (Pretend that more complicated abort criteria are there.)
>>>>
>>>> The interpreter API consists of primitives built
>>>> into the system, so it isn't traced.
>>>>
>>>> So then we have D:
>>>>
>>>> void D(void)
>>>> {
>>>> if (H(D)) { for (;;); }
>>>> return;
>>>> }
>>>>
>>>> Let's trace H(D). We indicate the simulation levels from 0,
>>>> step numbers from 1 within each level, with a bit of indentation
>>>> to tell apart the levels:
>>>>
>>>
>>> *This is the part that Kaz does not understand*
>>>
>>> i == 0 reaches if (interp_step(s))
>>> i == 1 reaches if (interp_step(s))
>>> i == 2 reaches if (interp_step(s))
>>> i == 3 NEVER reaches if (interp_step(s))
>>>
>>> The whole point is that D simulated by H
>>> cannot possbly reach its own simulated
>>> "return" statement no matter what H does.
>>
>> Yes; this doesn't happen while H is running.
>>
>> So while H does /something/, no matter what H does, that D simulation
>> won't reach the return statement.
>>
>> H has to return zero first and terminate, leaving the simulation
>> abandoned.
>>
>
> Just like leaving the Infinite_loop() abandoned.
Indeed, with the above H, a simulation of /anything/ that does not
terminate within three inter_step steps is abandoned in order
to return false, whether that false is correct or not.
>> That's the one thing that H can "do" which then lets D
>> reach its return statement.
>>
>
> When H has stopped simulating D then a resumption
> of the exact same machine state of this simulation
> would simply be the point where H rejected D.
Yes, but that point is not special to D.
There is nothing in D's specification indicating that it should
stop at that point.
D doesn't even "experience" the stop since it has no real-time
clock or any other world reference.
In our case here, it turns out that three interp_step steps
of D just get D to the start of the for loop inside H.
So that is where it will be restarted.
If we used 4 instead of 3, then D would be stopped more
in the loop, where it has initialized i to 0.
>
>> Then the simulation framework itself picks up that simuation
>> and does the stepping.
>>
>
> If the simulation framework resumes the simulation
> at the exact same machine state with H local i == 3
The simulation state of D is just at the beginning of
the loop inside simualted H; i is about to be initialized
to zero (if I recall correcty; I don't have it quoted in
my edit buffer now).
The i == 3 happened in the "directly executed" H which
has now terminated.
We are not resuming that H!
We are only resuming (== taking over) the simulation
that it left behind.
The top level H is out of the picture. We remember
that it returned false for H(D) though.
> and H already returned to the simulation framework
> then resuming the simulation cannot do anything more
> than immediately return to the simulation framework.
>
>>> If we continue the simulation with the exact
>>> same machine state then H simply returns false
>>> because i == 3.
>>
>> Remember, we are not continuing the top level H,
>> which terminated and returned zero, but the simulated
>> D which is calling the simulated H.
>>
>
> When we actually literally resume the simulation
> then it must be the exact same machine state of
> the whole system at the point just after H returned
> false to the simulation framework.
No, it is not the machine state of the whole system; it is just the
object #<interp0> that was returned to the top-level H when it called
interp_init(P).
This is similar to the slave_state, and slave_stack and other simulation
parameters in the x86_utm.
The simulation carried out by H was never of the whole system, just a
simulation of D. Why would its continuation suddenly be the "the whole
system"?
Anyway, that is not the idea at all.
The framework obtains #<interp0> (because it keeps track of such
objects) and behaves as if it were calling interp_step() on it.
That is all.
> If we don't do exactly this then we are not actually
> resuming anything.
You are talking about capturing a continuation at the point
where H returned, and calling it. That's something else entirely,
and wouldn't make sense.
That would just be repeating the calculation consisting of H
returning to the main function, returning to the framework,
causing that to happen twice.
(I work with languages in which you can do exactly that sort
of thing, incidentally.)
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.org> |
|---|---|
| Date | 2025-11-05 07:47 +0000 |
| Subject | Re: Kaz does not understand his own code. |
| Message-ID | <10eevec$77ji$2@dont-email.me> |
| In reply to | #135044 |
Am Tue, 04 Nov 2025 21:06:30 -0600 schrieb olcott: > On 11/4/2025 8:43 PM, Kaz Kylheku wrote: >> That's the one thing that H can "do" which then lets D reach its return >> statement. > When H has stopped simulating D then a resumption of the exact same > machine state of this simulation would simply be the point where H > rejected D. We are not resuming H. H has halted. We are resuming the simulation of D. > If the simulation framework resumes the simulation at the exact same > machine state with H local i == 3 and H already returned to the > simulation framework then resuming the simulation cannot do anything > more than immediately return to the simulation framework. See above. > When we actually literally resume the simulation then it must be the > exact same machine state of the whole system at the point just after H > returned false to the simulation framework. > If we don't do exactly this then we are not actually resuming anything. The point where D was aborted. -- Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math: It is not guaranteed that n+1 exists for every n.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-04 21:51 -0600 |
| Subject | Re: Kaz does not understand his own code --- I AM PROVED EXACTLY CORRECT |
| Message-ID | <10eehjg$52du$1@dont-email.me> |
| In reply to | #135043 |
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
> On 2025-11-05, olcott <polcott333@gmail.com> wrote:
>> On 11/4/2025 7:20 PM, Mike Terry wrote:
>>>
>>> I don't really see that PO has declined recently - It seems to me he's
>>> been the way he is for as long as I recall. I would say he's become
>>> markedly ruder of late, though! Maybe that's all related to his LLMs
>>> pandering to his delusions and giving him a renewed confidence.
>>>
>>>
>>> Mike.
>>>
>>>
>>
>> news://news.eternal-september.org/20251103195844.661@kylheku.com
>>
>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>
>>> How about this minimal viable H:
>>>
>>> #include <interpret.h> // C interpreter's own API
>>>
>>> bool H(fptr P)
>>> {
>>> interp *s = interp_init(P);
>>>
>>> for (int i = 0; i < 3; i++) {
>>> if (interp_step(s))
>>> return true;
>>> }
>>>
>>> return false;
>>> }
>>>
>>> H initializes an interpreter for its argument P.
>>> Then it applies a very simple abort logic: it
>>> steps the interpreter state three times. If
>>> during those three steps, P terminates, it returns
>>> true. Otherwise it assumes P is nonterminating and
>>> returns false.
>>>
>>> (Pretend that more complicated abort criteria are there.)
>>>
>>> The interpreter API consists of primitives built
>>> into the system, so it isn't traced.
>>>
>>> So then we have D:
>>>
>>> void D(void)
>>> {
>>> if (H(D)) { for (;;); }
>>> return;
>>> }
>>>
>>> Let's trace H(D). We indicate the simulation levels from 0,
>>> step numbers from 1 within each level, with a bit of indentation
>>> to tell apart the levels:
>>>
>>
>> *This is the part that Kaz does not understand*
>>
>> i == 0 reaches if (interp_step(s))
>> i == 1 reaches if (interp_step(s))
>> i == 2 reaches if (interp_step(s))
>> i == 3 NEVER reaches if (interp_step(s))
>>
>> The whole point is that D simulated by H
>> cannot possbly reach its own simulated
>> "return" statement no matter what H does.
>
> Yes; this doesn't happen while H is running.
>
Then that all by itself conclusively proves that
the input to H(D) specifies non-halting behavior
when halting behavior is stipulated to mean behavior
that cannot possibly reach its own final halt state
as measured by D simulated by H.
Within the 100% perfectly exact meaning of those
words without the tiniest little change
I AM PROVED EXACTLY CORRECT.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-05 05:12 +0000 |
| Subject | Re: Kaz does not understand his own code --- I AM PROVED EXACTLY CORRECT |
| Message-ID | <20251104205857.675@kylheku.com> |
| In reply to | #135046 |
On 2025-11-05, olcott <polcott333@gmail.com> wrote: > On 11/4/2025 8:43 PM, Kaz Kylheku wrote: >> Yes; this doesn't happen while H is running. >> > > Then that all by itself conclusively proves that > the input to H(D) specifies non-halting behavior > when halting behavior is stipulated to mean behavior > that cannot possibly reach its own final halt state > as measured by D simulated by H. > > Within the 100% perfectly exact meaning of those > words without the tiniest little change > I AM PROVED EXACTLY CORRECT. But you can't conclude that D is infinite just because H's three-step tape measure runs out! D requires 11 steps to reach its halt state, right? H takes 9, to get to its return, then two more to evaluate the false return value and get to D's return. Since D has 11 steps, don't you see that 3 simply not enough to measure it; it is the wrong conclusion that D contains an infinite number of steps? You've lost sight of that H doesn't even try to be a decider; it's just assuming that anything with over three steps is non-terminating; I did it that way because it was easy to code up and trace for an example. If we want to do things like calling thes ame function twice without any conditional branches, we need much more logic, plus some primitives from <interp.h> for anayzing whether we are looking at a conditional jump, function call (and what is its target). You would never accepted a "three steps and you're out" criterion as correct when designing the x86utm! But the point is that /no/ amount of sophistication in the criteria can fix it. The manner by which H comes to the conlusion that it should stop and return false all lead to the same result: walking away from a termminating simulation of D. H returning false for any reason whatsoever makes D terminating. H cannot correctly decide D because D always requires a bunch more iter_steps than H performs. That's a consequence of D calling H and then adding more behavior based on the return value. So H can never have a "budget" of iter_step calls that can cover D; D is always a longer and slightly more complex calculation than H(D). The complexity of D cannot "fit" into H(D), because it's based on H(D) /and then some/. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-04 23:23 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10een03$671c$1@dont-email.me> |
| In reply to | #135043 |
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
> On 2025-11-05, olcott <polcott333@gmail.com> wrote:
>> On 11/4/2025 7:20 PM, Mike Terry wrote:
>>>
>>> I don't really see that PO has declined recently - It seems to me he's
>>> been the way he is for as long as I recall. I would say he's become
>>> markedly ruder of late, though! Maybe that's all related to his LLMs
>>> pandering to his delusions and giving him a renewed confidence.
>>>
>>>
>>> Mike.
>>>
>>>
>>
>> news://news.eternal-september.org/20251103195844.661@kylheku.com
>>
>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>
>>> How about this minimal viable H:
>>>
>>> #include <interpret.h> // C interpreter's own API
>>>
>>> bool H(fptr P)
>>> {
>>> interp *s = interp_init(P);
>>>
>>> for (int i = 0; i < 3; i++) {
>>> if (interp_step(s))
>>> return true;
>>> }
>>>
>>> return false;
>>> }
>>>
>>> H initializes an interpreter for its argument P.
>>> Then it applies a very simple abort logic: it
>>> steps the interpreter state three times. If
>>> during those three steps, P terminates, it returns
>>> true. Otherwise it assumes P is nonterminating and
>>> returns false.
>>>
>>> (Pretend that more complicated abort criteria are there.)
>>>
>>> The interpreter API consists of primitives built
>>> into the system, so it isn't traced.
>>>
>>> So then we have D:
>>>
>>> void D(void)
>>> {
>>> if (H(D)) { for (;;); }
>>> return;
>>> }
>>>
>>> Let's trace H(D). We indicate the simulation levels from 0,
>>> step numbers from 1 within each level, with a bit of indentation
>>> to tell apart the levels:
>>>
>>
>> *This is the part that Kaz does not understand*
>>
>> i == 0 reaches if (interp_step(s))
>> i == 1 reaches if (interp_step(s))
>> i == 2 reaches if (interp_step(s))
>> i == 3 NEVER reaches if (interp_step(s))
>>
>> The whole point is that D simulated by H
>> cannot possbly reach its own simulated
>> "return" statement no matter what H does.
>
> Yes; this doesn't happen while H is running.
>
*That is the definition of non-halting input*
Then that all by itself conclusively proves that
the input to H(D) specifies non-halting behavior
when halting behavior is stipulated to mean behavior
that cannot possibly reach its own final halt state
as measured by D simulated by H.
Within the 100% perfectly exact meaning of those
words without the tiniest little change
I AM PROVED EXACTLY CORRECT.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-05 07:01 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <20251104225410.579@kylheku.com> |
| In reply to | #135048 |
On 2025-11-05, olcott <polcott333@gmail.com> wrote:
> On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
>>> The whole point is that D simulated by H
>>> cannot possbly reach its own simulated
>>> "return" statement no matter what H does.
>>
>> Yes; this doesn't happen while H is running.
>>
>
> *That is the definition of non-halting input*
Well, anyway, there you go; that's how the "D simulated by H" is the
same halting D as the directly executed one.
You can keep working your same rhetoric on top of that
if you like; that in spite of that, there is some magically
different D that is non-halting.
If halting doesn't happen on H's watch, then the
input is nonhalting, and that is correct.
For instance this:
void Finite_Loop(void)
{
for (i = 0; i < 1000; i++) { }
}
This doesn't finish simulating in H's three interp_step(s) operations.
Therefore H(Finite_Loop) returns 0.
That must be correct, right? The 2000 step Finite_Loop, as measured by
H, is nonterminating: it does not reach termination while simulated by
H, exactly like the 11 step D.
Both of them obvious terminate, but ... wait for it .... that's not
the input!!!
Remember, halting deciders only operate on the finite string that is
their actual input, and not on a running process.
Yadda yadda, I've written it for you so you don't have to.
But anyway, I hope it is perfectly clear what is meant by
continuing an abandoned simulation and all that; it has been
shown in close to the simplest possible way possible subject
to C having to be used.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-05 08:55 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10efogm$fc5s$1@dont-email.me> |
| In reply to | #135049 |
On 11/5/2025 1:01 AM, Kaz Kylheku wrote:
> On 2025-11-05, olcott <polcott333@gmail.com> wrote:
>> On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
>>>> The whole point is that D simulated by H
>>>> cannot possibly reach its own simulated
>>>> "return" statement no matter what H does.
>>>
>>> Yes; this doesn't happen while H is running.
>>>
>>
>> *That is the definition of non-halting input*
>
> Well, anyway, there you go; that's how the "D simulated by H" is the
> same halting D as the directly executed one.
The whole point is that D simulated by H
cannot possibly reach its own simulated
"return" statement no matter what H does.
The semantic halting property of the input
to H(D) has been proven to be non-halting.
The function H is a simulating termination analyzer:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
(b) Simulated input reaches its simulated
"return" statement: return 1.
H1 is exactly the same as H except that D does
not call H1 at all and D calls H in recursive
simulation thus HD()==0 and H1(D)==1. >
> You can keep working your same rhetoric on top of that
> if you like; that in spite of that, there is some magically
> different D that is non-halting.
>
> If halting doesn't happen on H's watch, then the
> input is nonhalting, and that is correct.
>
I use the more sophisticated non-halting behavior
patterns.
> For instance this:
>
> void Finite_Loop(void)
> {
> for (i = 0; i < 1000; i++) { }
> }
>
HHH(Finite_Loop)==1
> This doesn't finish simulating in H's three interp_step(s) operations.
> Therefore H(Finite_Loop) returns 0.
>
> That must be correct, right? The 2000 step Finite_Loop, as measured by
> H, is nonterminating: it does not reach termination while simulated by
> H, exactly like the 11 step D.
>
> Both of them obvious terminate, but ... wait for it .... that's not
> the input!!!
>
> Remember, halting deciders only operate on the finite string that is
> their actual input, and not on a running process.
>
> Yadda yadda, I've written it for you so you don't have to.
>
> But anyway, I hope it is perfectly clear what is meant by
> continuing an abandoned simulation and all that; it has been
> shown in close to the simplest possible way possible subject
> to C having to be used.
>
It has never meant literally actually continuing the operation
from the exact same machine at the exact same machine state.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-05 17:35 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <20251105075542.874@kylheku.com> |
| In reply to | #135064 |
On 2025-11-05, olcott <polcott333@gmail.com> wrote: > On 11/5/2025 1:01 AM, Kaz Kylheku wrote: >> On 2025-11-05, olcott <polcott333@gmail.com> wrote: >>> On 11/4/2025 8:43 PM, Kaz Kylheku wrote: >>>>> The whole point is that D simulated by H >>>>> cannot possibly reach its own simulated >>>>> "return" statement no matter what H does. >>>> >>>> Yes; this doesn't happen while H is running. >>>> >>> >>> *That is the definition of non-halting input* >> >> Well, anyway, there you go; that's how the "D simulated by H" is the >> same halting D as the directly executed one. > > The whole point is that D simulated by H > cannot possibly reach its own simulated > "return" statement no matter what H does. > > The semantic halting property of the input > to H(D) has been proven to be non-halting. So you are saying that no simulating decider could ever be wrong about its D-like diagonal input case, if it conducts an incomplete (but otherwise correct) simulation of its input and then returns false for any reason whatsoever (such as "if the input is taking more than three steps, it must be nonterminating"). And you believe that this will get you written into the history books as the researcher who showed that the halting problem is all wrong. You think that math/CS academia will see it from your perspective and just agree that when H detaches from D, the question of whether the abandoned simulation is terminating becomes off-limits (like some sort "inadmissible evidence")? But at least hopefully you did see that the simulation of D started by H can be completed, resulting in the same total 11 wsteps as a directly executed D. (It just cannot all happen while H is running; H obviously cannot be the sole driver which pushes the simulation to completion, since it only pushes the first three steps.) I and others have not lied or been mistaken in any observations about what is going on. Everyone agrees that H returned false after certain steps that were correct up to that point, that the input didn't reach its return statement while simulated by H, and that there is an unfinished simulation that can be continued and has been correctly shown to reach its return statemnt. Your whole position is that if a simluation does not reach termination /while being simulated by the decider/ then it is correct to call it nonterminating. (If not absolutely then at least in situations when the input is the diagonal case). -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.theory
csiph-web