Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #133713 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2025-10-25 12:53 -0500 |
| Last post | 2025-10-27 18:50 -0700 |
| Articles | 20 on this page of 203 — 19 participants |
Back to article view | Back to comp.theory
No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-25 12:53 -0500
Re: No human has been able to understand this simple C in three years Bonita Montero <Bonita.Montero@gmail.com> - 2025-10-25 20:05 +0200
Re: No human has been able to understand this simple C in three years dbush <dbush.mobile@gmail.com> - 2025-10-25 14:20 -0400
Re: No human has been able to understand this simple C in three years Richard Heathfield <rjh@cpax.org.uk> - 2025-10-25 20:44 +0100
Re: No human has been able to understand this simple C in three years dart200 <user7160@newsgrouper.org.invalid> - 2025-10-25 11:44 -0700
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-25 13:58 -0500
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-26 17:17 -0500
Re: No human has been able to understand this simple C in three years Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 00:44 +0000
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-26 19:51 -0500
Re: No human has been able to understand this simple C in three years dbush <dbush.mobile@gmail.com> - 2025-10-26 21:06 -0400
Re: No human has been able to understand this simple C in three years "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 18:09 -0700
Re: No human has been able to understand this simple C in three years Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 01:16 +0000
A dishonest dodge is all that Kaz has olcott <polcott333@gmail.com> - 2025-10-26 20:20 -0500
Re: A dishonest dodge is all that Kaz has dbush <dbush.mobile@gmail.com> - 2025-10-26 21:28 -0400
Re: A dishonest dodge is all that Kaz has olcott <polcott333@gmail.com> - 2025-10-26 20:32 -0500
Re: A dishonest dodge is all that Kaz has dbush <dbush.mobile@gmail.com> - 2025-10-26 21:38 -0400
Re: A dishonest dodge is all that Kaz has Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 01:50 +0000
Kaz is now dishonored in his deceit olcott <polcott333@gmail.com> - 2025-10-26 20:58 -0500
Re: Kaz is now dishonored in his deceit Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 02:02 +0000
Re: Kaz is now dishonored in his deceit olcott <polcott333@gmail.com> - 2025-10-26 21:04 -0500
Re: Kaz is now dishonored in his deceit Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 03:46 +0000
Kaz proves his deceit by dodging this simple point --- Is Kaz just a Liar ??? olcott <polcott333@gmail.com> - 2025-10-26 23:10 -0500
Re: Kaz proves his deceit by dodging this simple point --- Is Kaz just a Liar ??? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 04:52 +0000
Re: Kaz proves his deceit by dodging this simple point --- Is Kaz just a Liar ??? Richard Damon <Richard@Damon-Family.org> - 2025-10-27 20:59 -0400
Re: Kaz is now dishonored in his deceit André G. Isaak <agisaak@gm.invalid> - 2025-10-26 20:15 -0600
Re: Kaz is now dishonored in his deceit olcott <polcott333@gmail.com> - 2025-10-26 21:20 -0500
Re: Kaz is now dishonored in his deceit "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 19:25 -0700
Re: Kaz is now dishonored in his deceit dbush <dbush.mobile@gmail.com> - 2025-10-26 22:35 -0400
Re: Kaz is now dishonored in his deceit olcott <polcott333@gmail.com> - 2025-10-26 21:38 -0500
Re: Kaz is now dishonored in his deceit dbush <dbush.mobile@gmail.com> - 2025-10-26 22:43 -0400
Re: Kaz is now dishonored in his deceit olcott <polcott333@gmail.com> - 2025-10-26 21:45 -0500
olcott tries to hide the evidence that he admitted the input to HHH(DD) is halting dbush <dbush.mobile@gmail.com> - 2025-10-26 22:47 -0400
dbush is now dishonored in his deceit olcott <polcott333@gmail.com> - 2025-10-26 21:52 -0500
olcott tries to hide the evidence that he admitted the input to HHH(DD) is halting dbush <dbush.mobile@gmail.com> - 2025-10-26 22:57 -0400
dbush proves his deceit by dodging this simple point olcott <polcott333@gmail.com> - 2025-10-26 22:11 -0500
Can someone from comp.lang.c or comp.lang.c++ help out here? olcott <polcott333@gmail.com> - 2025-10-26 22:02 -0500
olcott tries to hide the evidence that he admitted the input to HHH(DD) is halting dbush <dbush.mobile@gmail.com> - 2025-10-26 23:04 -0400
dbush proves is deceit by dodging this simple point olcott <polcott333@gmail.com> - 2025-10-26 22:09 -0500
olcott tries to hide the evidence that he admitted the input to HHH(DD) is halting dbush <dbush.mobile@gmail.com> - 2025-10-26 23:14 -0400
dbush proves his deceit by dodging this simple point --- dbush is a bot? olcott <polcott333@gmail.com> - 2025-10-26 22:42 -0500
olcott tries to hide the evidence that he admitted the input to HHH(DD) is halting dbush <dbush.mobile@gmail.com> - 2025-10-27 07:25 -0400
Re: Kaz is now dishonored in his deceit Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 04:47 +0000
Re: Kaz is now dishonored in his deceit olcott <polcott333@gmail.com> - 2025-10-26 23:54 -0500
Re: Kaz is now dishonored in his deceit dbush <dbush.mobile@gmail.com> - 2025-10-27 07:30 -0400
Re: Kaz is now dishonored in his deceit Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 18:36 +0000
Re: Kaz is now dishonored in his deceit "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 11:55 -0700
Re: Kaz is now dishonored in his deceit Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-27 05:59 +0000
Re: Kaz is now dishonored in his deceit olcott <polcott333@gmail.com> - 2025-10-27 08:18 -0500
Re: Kaz is now dishonored in his deceit Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-27 16:50 +0000
Re: Kaz is now dishonored in his deceit olcott <polcott333@gmail.com> - 2025-10-27 11:58 -0500
Re: Kaz is now dishonored in his deceit "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 11:48 -0700
Re: Kaz is now dishonored in his deceit Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 03:31 +0100
Re: Kaz is now dishonored in his deceit olcott <polcott333@gmail.com> - 2025-10-26 21:36 -0500
Re: Kaz is now dishonored in his deceit cross@spitfire.i.gajendra.net (Dan Cross) - 2025-10-27 14:08 +0000
I am only in these groups because I have been cheated out of a fair review. olcott <polcott333@gmail.com> - 2025-10-27 09:48 -0500
Re: A dishonest dodge is all that Kaz has Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 01:38 +0000
Re: A dishonest dodge is all that Kaz has --- Now dishonored in his deceit olcott <polcott333@gmail.com> - 2025-10-26 20:45 -0500
Re: A dishonest dodge is all that Kaz has --- Now dishonored in his deceit dbush <dbush.mobile@gmail.com> - 2025-10-26 21:49 -0400
dbush is now dishonored in his deceit olcott <polcott333@gmail.com> - 2025-10-26 20:56 -0500
Re: dbush is now dishonored in his deceit dbush <dbush.mobile@gmail.com> - 2025-10-26 22:05 -0400
Re: dbush is now dishonored in his deceit olcott <polcott333@gmail.com> - 2025-10-26 21:15 -0500
olcott tries to hide the evidence that he admitted the input to HHH(DD) is halting dbush <dbush.mobile@gmail.com> - 2025-10-26 22:33 -0400
Re: A dishonest dodge is all that Kaz has --- Now dishonored in his deceit Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 01:57 +0000
Kaz is now dishonored in his deceit olcott <polcott333@gmail.com> - 2025-10-26 20:59 -0500
Re: No human has been able to understand this simple C in three years Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-10-27 04:32 +0000
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-26 23:35 -0500
Re: No human has been able to understand this simple C in three years Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 16:45 +0000
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-27 11:53 -0500
Re: No human has been able to understand this simple C in three years Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 18:48 +0000
Re: No human has been able to understand this simple C in three years Richard Damon <Richard@Damon-Family.org> - 2025-10-25 21:20 -0400
Re: No human has been able to understand this simple C in three years Mikko Levanto <mikko.levanto@iki.fi> - 2025-10-26 11:06 +0200
Re: No human has been able to understand this simple C in three years Bonita Montero <Bonita.Montero@gmail.com> - 2025-10-27 09:11 +0100
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-27 08:15 -0500
Re: No human has been able to understand this simple C in three years Bonita Montero <Bonita.Montero@gmail.com> - 2025-10-27 16:04 +0100
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-27 10:19 -0500
Re: No human has been able to understand this simple C in three years Bonita Montero <Bonita.Montero@gmail.com> - 2025-10-27 17:41 +0100
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-27 11:52 -0500
Re: No human has been able to understand this simple C in three years Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 16:58 +0000
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-27 12:02 -0500
Re: No human has been able to understand this simple C in three years Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 18:42 +0000
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-27 13:53 -0500
Re: No human has been able to understand this simple C in three years dbush <dbush.mobile@gmail.com> - 2025-10-27 15:20 -0400
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-27 14:33 -0500
Re: No human has been able to understand this simple C in three years dbush <dbush.mobile@gmail.com> - 2025-10-27 15:40 -0400
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-27 14:53 -0500
Re: No human has been able to understand this simple C in three years dbush <dbush.mobile@gmail.com> - 2025-10-27 16:12 -0400
PO Meltdown? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 20:48 +0000
Re: PO Meltdown? dbush <dbush.mobile@gmail.com> - 2025-10-27 17:07 -0400
Re: PO Meltdown? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 21:14 +0000
Re: PO Meltdown? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 00:37 +0000
Kaz is a damned liar olcott <polcott333@gmail.com> - 2025-10-27 19:44 -0500
Re: Kaz is a damned liar Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 00:52 +0000
Re: Kaz is a damned liar "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 19:05 -0700
Kaz is a damned liar olcott <polcott333@gmail.com> - 2025-10-27 19:44 -0500
Re: PO Meltdown? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-10-28 02:24 +0000
D simulated by H cannot possibly reach past its own first line olcott <polcott333@gmail.com> - 2025-10-27 22:18 -0500
Re: D simulated by H cannot possibly reach past its own first line dbush <dbush.mobile@gmail.com> - 2025-10-27 23:27 -0400
Re: D simulated by H cannot possibly reach past its own first line Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 03:40 +0000
Re: D simulated by H cannot possibly reach past its own first line olcott <polcott333@gmail.com> - 2025-10-27 22:45 -0500
Re: D simulated by H cannot possibly reach past its own first line dbush <dbush.mobile@gmail.com> - 2025-10-27 23:47 -0400
Re: D simulated by H cannot possibly reach past its own first line Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 03:54 +0000
Re: D simulated by H cannot possibly reach past its own first line olcott <polcott333@gmail.com> - 2025-10-27 23:01 -0500
Re: D simulated by H cannot possibly reach past its own first line Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 06:02 +0000
Re: D simulated by H cannot possibly reach past its own first line Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-10-28 15:18 +0000
Re: D simulated by H cannot possibly reach past its own first line olcott <polcott333@gmail.com> - 2025-10-28 11:21 -0500
Re: D simulated by H cannot possibly reach past its own first line Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 16:44 +0000
Re: D simulated by H cannot possibly reach past its own first line Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-10-28 17:24 +0000
Re: D simulated by H cannot possibly reach past its own first line olcott <polcott333@gmail.com> - 2025-10-28 15:15 -0500
Re: D simulated by H cannot possibly reach past its own first line dbush <dbush.mobile@gmail.com> - 2025-10-28 16:18 -0400
Re: D simulated by H cannot possibly reach past its own first line Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 20:23 +0000
Re: D simulated by H cannot possibly reach past its own first line olcott <polcott333@gmail.com> - 2025-10-28 16:00 -0500
Re: D simulated by H cannot possibly reach past its own first line Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 21:23 +0000
Re: D simulated by H cannot possibly reach past its own first line olcott <polcott333@gmail.com> - 2025-10-28 16:33 -0500
Re: D simulated by H cannot possibly reach past its own first line dbush <dbush.mobile@gmail.com> - 2025-10-28 18:01 -0400
Re: D simulated by H cannot possibly reach past its own first line "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-28 12:03 -0700
Re: D simulated by H cannot possibly reach past its own first line Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 19:56 +0000
Re: D simulated by H cannot possibly reach past its own first line "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-28 13:27 -0700
Re: D simulated by H cannot possibly reach past its own first line joes <noreply@example.org> - 2025-10-28 08:40 +0000
Re: D simulated by H cannot possibly reach past its own first line olcott <polcott333@gmail.com> - 2025-10-28 09:43 -0500
Re: D simulated by H cannot possibly reach past its own first line "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-28 12:08 -0700
Re: D simulated by H cannot possibly reach past its own first line joes <noreply@example.org> - 2025-11-03 14:06 +0000
Re: D simulated by H cannot possibly reach past its own first line olcott <polcott333@gmail.com> - 2025-11-03 10:13 -0600
Re: D simulated by H cannot possibly reach past its own first line dbush <dbush.mobile@gmail.com> - 2025-10-28 00:04 -0400
Re: D simulated by H cannot possibly reach past its own first line olcott <polcott333@gmail.com> - 2025-10-27 23:29 -0500
Re: D simulated by H cannot possibly reach past its own first line Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 05:48 +0000
Re: D simulated by H cannot possibly reach past its own first line "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 22:51 -0700
Re: D simulated by H cannot possibly reach past its own first line dbush <dbush.mobile@gmail.com> - 2025-10-28 07:48 -0400
Re: PO Meltdown? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 03:31 +0000
Re: PO Meltdown? wij <wyniijj5@gmail.com> - 2025-10-28 13:25 +0800
Re: PO Meltdown? olcott <polcott333@gmail.com> - 2025-10-28 00:32 -0500
Re: PO Meltdown? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 05:53 +0000
D simulated by H cannot possibly reach past its own first line olcott <polcott333@gmail.com> - 2025-10-28 09:27 -0500
Re: D simulated by H cannot possibly reach past its own first line Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 16:48 +0000
Re: D simulated by H cannot possibly reach past its own first line olcott <polcott333@gmail.com> - 2025-10-28 15:23 -0500
Re: D simulated by H cannot possibly reach past its own first line Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 21:26 +0000
D simulated by H cannot possibly reach past its own first line olcott <polcott333@gmail.com> - 2025-10-28 00:27 -0500
Re: D simulated by H cannot possibly reach past its own first line "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 22:46 -0700
D simulated by H cannot possibly reach past its own first line olcott <polcott333@gmail.com> - 2025-10-27 21:58 -0500
Re: D simulated by H cannot possibly reach past its own first line "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 19:59 -0700
Re: D simulated by H cannot possibly reach past its own first line dbush <dbush.mobile@gmail.com> - 2025-10-27 23:10 -0400
Kaz insists on dodging this point only because he knows it is irrefutable olcott <polcott333@gmail.com> - 2025-10-27 17:40 -0500
Re: Kaz insists on dodging this point only because he knows it is irrefutable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 00:23 +0000
Re: Kaz insists on dodging this point only because he knows it is irrefutable olcott <polcott333@gmail.com> - 2025-10-27 19:29 -0500
Re: Kaz insists on dodging this point only because he knows it is irrefutable dbush <dbush.mobile@gmail.com> - 2025-10-27 20:32 -0400
Re: Kaz insists on dodging this point only because he knows it is irrefutable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 00:41 +0000
Re: Kaz insists on dodging this point only because he knows it is irrefutable +++ olcott <polcott333@gmail.com> - 2025-10-27 19:48 -0500
Re: Kaz insists on dodging this point only because he knows it is irrefutable +++ dbush <dbush.mobile@gmail.com> - 2025-10-27 20:52 -0400
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-27 18:01 -0500
Re: No human has been able to understand this simple C in three years dbush <dbush.mobile@gmail.com> - 2025-10-27 19:05 -0400
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-27 18:11 -0500
Re: No human has been able to understand this simple C in three years "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 18:38 -0700
Re: No human has been able to understand this simple C in three years Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 03:21 +0000
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-27 22:44 -0500
Re: No human has been able to understand this simple C in three years dbush <dbush.mobile@gmail.com> - 2025-10-27 23:46 -0400
Re: No human has been able to understand this simple C in three years "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 22:38 -0700
Re: No human has been able to understand this simple C in three years dbush <dbush.mobile@gmail.com> - 2025-10-28 07:55 -0400
Re: No human has been able to understand this simple C in three years tTh <tth@none.invalid> - 2025-10-27 18:57 +0100
Re: No human has been able to understand this simple C in three years Mikko <mikko.levanto@iki.fi> - 2025-10-27 12:10 +0200
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-27 08:45 -0500
Re: No human has been able to understand this simple C in three years Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 17:03 +0000
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-27 12:05 -0500
Re: No human has been able to understand this simple C in three years tTh <tth@none.invalid> - 2025-10-27 19:00 +0100
Re: No human has been able to understand this simple C in three years Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 19:59 +0000
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-27 17:38 -0500
Re: No human has been able to understand this simple C in three years Mikko <mikko.levanto@iki.fi> - 2025-10-28 11:09 +0200
Re: No human has been able to understand this simple C in three years Richard Heathfield <rjh@cpax.org.uk> - 2025-10-28 10:06 +0000
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-28 09:52 -0500
Re: No human has been able to understand this simple C in three years Mikko <mikko.levanto@iki.fi> - 2025-10-29 13:02 +0200
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-29 11:29 -0500
Re: No human has been able to understand this simple C in three years "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-29 12:48 -0700
Re: No human has been able to understand this simple C in three years Mikko <mikko.levanto@iki.fi> - 2025-10-30 12:24 +0200
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-30 08:15 -0500
Re: No human has been able to understand this simple C in three years Mikko <mikko.levanto@iki.fi> - 2025-10-31 13:53 +0200
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-31 08:42 -0500
Re: No human has been able to understand this simple C in three years dbush <dbush.mobile@gmail.com> - 2025-10-31 10:13 -0400
Re: No human has been able to understand this simple C in three years Mikko <mikko.levanto@iki.fi> - 2025-11-01 11:22 +0200
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-11-01 08:27 -0500
Re: No human has been able to understand this simple C in three years dbush <dbush.mobile@gmail.com> - 2025-11-01 09:53 -0400
understand this simple C ? --- counter-factual assumptions olcott <polcott333@gmail.com> - 2025-11-01 09:22 -0500
Re: understand this simple C ? --- counter-factual assumptions dbush <dbush.mobile@gmail.com> - 2025-11-01 10:37 -0400
Re: understand this simple C ? --- counter-factual assumptions olcott <polcott333@gmail.com> - 2025-11-01 09:41 -0500
Re: understand this simple C ? --- counter-factual assumptions dbush <dbush.mobile@gmail.com> - 2025-11-01 11:24 -0400
Re: understand this simple C ? --- counter-factual assumptions olcott <polcott333@gmail.com> - 2025-11-01 10:32 -0500
Re: understand this simple C ? --- counter-factual assumptions dbush <dbush.mobile@gmail.com> - 2025-11-01 11:44 -0400
Re: understand this simple C ? --- counter-factual assumptions olcott <polcott333@gmail.com> - 2025-11-01 12:04 -0500
Re: understand this simple C ? --- counter-factual assumptions dbush <dbush.mobile@gmail.com> - 2025-11-01 14:14 -0400
Re: No human has been able to understand this simple C in three years Mikko <mikko.levanto@iki.fi> - 2025-11-02 14:35 +0200
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-11-03 17:31 -0600
Re: No human has been able to understand this simple C in three years Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-11-03 23:48 +0000
Re: No human has been able to understand this simple C in three years Mikko <mikko.levanto@iki.fi> - 2025-11-04 12:00 +0200
Re: No human has been able to understand this simple C in three years Mikko <mikko.levanto@iki.fi> - 2025-10-29 13:01 +0200
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-28 09:55 -0500
Re: No human has been able to understand this simple C in three years Mikko <mikko.levanto@iki.fi> - 2025-10-29 13:03 +0200
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-29 11:29 -0500
Re: No human has been able to understand this simple C in three years "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-29 12:49 -0700
Re: No human has been able to understand this simple C in three years Mikko <mikko.levanto@iki.fi> - 2025-10-30 12:29 +0200
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-30 08:17 -0500
Re: No human has been able to understand this simple C in three years Mikko <mikko.levanto@iki.fi> - 2025-10-31 14:02 +0200
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-10-31 08:50 -0500
Re: No human has been able to understand this simple C in three years "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-31 12:58 -0700
Re: No human has been able to understand this simple C in three years Mikko <mikko.levanto@iki.fi> - 2025-11-01 11:32 +0200
Re: No human has been able to understand this simple C in three years olcott <polcott333@gmail.com> - 2025-11-01 08:32 -0500
Re: No human has been able to understand this simple C in three years "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 18:50 -0700
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-28 03:54 +0000 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <20251027204814.246@kylheku.com> |
| In reply to | #134004 |
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
> On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>> Once H has correctly determines that its simulated
>>> D cannot possibly reach its own simulated "return"
>>> instruction final halt state it is nutty to do
>>> anything else besides abort and reject the input.
>>
>> I have traces which prove otherwise.
>
> Then you can't be telling the truth.
LOL!
Have you forgotten? (Sigh, I'm afraid the answer is yes ...)
- You used to post execution traces claiming that they
proved you were right.
- You used to deride others for not following your
execution traces in detail (maybe they are not skilled
engineers)
>
> int D()
> {
> int Halt_Status = H(D);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> H simulates D
> that calls H(D) to simulate D
This is just empty claptrap about an ill-defined program
with a missing definition of H, not an execution trace.
Mere Rhetoric Bereft of Reasoning (MRBOR)
Only execution traces are real.
You are a less skilled coding technician than I estimated.
--
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-10-27 23:01 -0500 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <10dpf7i$1j14m$1@dont-email.me> |
| In reply to | #134007 |
On 10/27/2025 10:54 PM, Kaz Kylheku wrote:
> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>> On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
>>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>>> Once H has correctly determines that its simulated
>>>> D cannot possibly reach its own simulated "return"
>>>> instruction final halt state it is nutty to do
>>>> anything else besides abort and reject the input.
>>>
>>> I have traces which prove otherwise.
>>
>> Then you can't be telling the truth.
>
> LOL!
>
> Have you forgotten? (Sigh, I'm afraid the answer is yes ...)
>
> - You used to post execution traces claiming that they
> proved you were right.
>
> - You used to deride others for not following your
> execution traces in detail (maybe they are not skilled
> engineers)
>
>>
>> int D()
>> {
>> int Halt_Status = H(D);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> H simulates D
>> that calls H(D) to simulate D
>
> This is just empty claptrap about an ill-defined program
> with a missing definition of H, not an execution trace.
>
So you cannot begin to imagine WTF happens when D
is simulated by H?
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
That is as simple as arithmetic.
> Mere Rhetoric Bereft of Reasoning (MRBOR)
>
> Only execution traces are real.
>
> You are a less skilled coding technician than I estimated.
>
--
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-10-28 06:02 +0000 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <20251027225453.725@kylheku.com> |
| In reply to | #134008 |
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
> On 10/27/2025 10:54 PM, Kaz Kylheku wrote:
>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>> On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
>>>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>>>> Once H has correctly determines that its simulated
>>>>> D cannot possibly reach its own simulated "return"
>>>>> instruction final halt state it is nutty to do
>>>>> anything else besides abort and reject the input.
>>>>
>>>> I have traces which prove otherwise.
>>>
>>> Then you can't be telling the truth.
>>
>> LOL!
>>
>> Have you forgotten? (Sigh, I'm afraid the answer is yes ...)
>>
>> - You used to post execution traces claiming that they
>> proved you were right.
>>
>> - You used to deride others for not following your
>> execution traces in detail (maybe they are not skilled
>> engineers)
>>
>>>
>>> int D()
>>> {
>>> int Halt_Status = H(D);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> H simulates D
>>> that calls H(D) to simulate D
>>
>> This is just empty claptrap about an ill-defined program
>> with a missing definition of H, not an execution trace.
>>
>
> So you cannot begin to imagine WTF happens when D
> is simulated by H?
Of course I can. First H has to call Init_Halts_H to allocate resources
for the simulation and do certain initialiations not particuliar to D.
Then Init_Slave_State to point the simulation at D and prime its stack.
Then a function called Decide_Halting is called that contains the
main single stepping loop which checks for certain conditions with
a helper function called Needs_To_Be_Aborted.
Decide_Halting pushes each decoded instruction into the shared trace
buffer which is examined by Needs_To_Be_Aborted.
I've diescovered that this trace buffer can be virtually infinite; I
turned it into a sliding window due to needing more space, but not
wanting to modify the Halt7.obj whose compiled code establishes the
trace buffer size.
When the execution trace buffer fills up, we don't have to abort
the x86utm. We can just trim old information at the front of
the buffer and move it down. Unless I'm mistaken, The abort decisions
are made by looking backwards from the end of the buffer; they don't
need the full history.
--
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-10-28 15:18 +0000 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <10dqmrp$249fe$1@dont-email.me> |
| In reply to | #134022 |
On 28/10/2025 06:02, Kaz Kylheku wrote:
> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>> On 10/27/2025 10:54 PM, Kaz Kylheku wrote:
>>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>>> On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
>>>>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>>>>> Once H has correctly determines that its simulated
>>>>>> D cannot possibly reach its own simulated "return"
>>>>>> instruction final halt state it is nutty to do
>>>>>> anything else besides abort and reject the input.
>>>>>
>>>>> I have traces which prove otherwise.
>>>>
>>>> Then you can't be telling the truth.
>>>
>>> LOL!
>>>
>>> Have you forgotten? (Sigh, I'm afraid the answer is yes ...)
>>>
>>> - You used to post execution traces claiming that they
>>> proved you were right.
>>>
>>> - You used to deride others for not following your
>>> execution traces in detail (maybe they are not skilled
>>> engineers)
>>>
>>>>
>>>> int D()
>>>> {
>>>> int Halt_Status = H(D);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> H simulates D
>>>> that calls H(D) to simulate D
>>>
>>> This is just empty claptrap about an ill-defined program
>>> with a missing definition of H, not an execution trace.
>>>
>>
>> So you cannot begin to imagine WTF happens when D
>> is simulated by H?
>
> Of course I can. First H has to call Init_Halts_H to allocate resources
> for the simulation and do certain initialiations not particuliar to D.
>
> Then Init_Slave_State to point the simulation at D and prime its stack.
>
> Then a function called Decide_Halting is called that contains the
> main single stepping loop which checks for certain conditions with
> a helper function called Needs_To_Be_Aborted.
>
> Decide_Halting pushes each decoded instruction into the shared trace
> buffer which is examined by Needs_To_Be_Aborted.
>
> I've diescovered that this trace buffer can be virtually infinite; I
> turned it into a sliding window due to needing more space, but not
> wanting to modify the Halt7.obj whose compiled code establishes the
> trace buffer size.
>
> When the execution trace buffer fills up, we don't have to abort
> the x86utm. We can just trim old information at the front of
> the buffer and move it down. Unless I'm mistaken, The abort decisions
> are made by looking backwards from the end of the buffer; they don't
> need the full history.
>
Hmm. The trace buffer can certainly be compressed significantly:
a) Only the following are significant:
- call instructions
- unconditional branch instructions
- conditional branch instructions
b) I can't see any need to ever go back further than the last conditional branch instruction
c) For a given call or branch instruction, having a given (instruction address, target address)
combination, the backwards scan for a such a pair will never go back further than the latest call or
branch instruction that matches. So no harm in deleting earlier entries, provided every branch/call
instruction deleted has a subsequent matching entry.
Aside from the above (which are based on PO's pattern matching rules), I don't think it would be
safe to prune further. In principle, an earlier call might not be matched until 30GB of trace
later. (Of course, with further knowledge about /what/ is being decided we might know better, but
in general (a)(b)(c) seems the best that is guaranteed for arbitrary input.)
But most of all I'm surprised PO's trace buffer would fill up, unless there is an infinite loop in
the picture. (Your "infinite tower" would constitute such a loop, I guess, but then by the time you
need to compress, isn't it clear there's such an infinite loop, so no point going further?
Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-28 11:21 -0500 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <10dqqj9$267qo$1@dont-email.me> |
| In reply to | #134058 |
On 10/28/2025 10:18 AM, Mike Terry wrote:
> On 28/10/2025 06:02, Kaz Kylheku wrote:
>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>> On 10/27/2025 10:54 PM, Kaz Kylheku wrote:
>>>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>>>>>> Once H has correctly determines that its simulated
>>>>>>> D cannot possibly reach its own simulated "return"
>>>>>>> instruction final halt state it is nutty to do
>>>>>>> anything else besides abort and reject the input.
>>>>>>
>>>>>> I have traces which prove otherwise.
>>>>>
>>>>> Then you can't be telling the truth.
>>>>
>>>> LOL!
>>>>
>>>> Have you forgotten? (Sigh, I'm afraid the answer is yes ...)
>>>>
>>>> - You used to post execution traces claiming that they
>>>> proved you were right.
>>>>
>>>> - You used to deride others for not following your
>>>> execution traces in detail (maybe they are not skilled
>>>> engineers)
>>>>
>>>>>
>>>>> int D()
>>>>> {
>>>>> int Halt_Status = H(D);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>> H simulates D
>>>>> that calls H(D) to simulate D
>>>>
>>>> This is just empty claptrap about an ill-defined program
>>>> with a missing definition of H, not an execution trace.
>>>>
>>>
>>> So you cannot begin to imagine WTF happens when D
>>> is simulated by H?
>>
>> Of course I can. First H has to call Init_Halts_H to allocate resources
>> for the simulation and do certain initialiations not particuliar to D.
>>
>> Then Init_Slave_State to point the simulation at D and prime its stack.
>>
>> Then a function called Decide_Halting is called that contains the
>> main single stepping loop which checks for certain conditions with
>> a helper function called Needs_To_Be_Aborted.
>>
>> Decide_Halting pushes each decoded instruction into the shared trace
>> buffer which is examined by Needs_To_Be_Aborted.
>>
>> I've diescovered that this trace buffer can be virtually infinite; I
>> turned it into a sliding window due to needing more space, but not
>> wanting to modify the Halt7.obj whose compiled code establishes the
>> trace buffer size.
>>
>> When the execution trace buffer fills up, we don't have to abort
>> the x86utm. We can just trim old information at the front of
>> the buffer and move it down. Unless I'm mistaken, The abort decisions
>> are made by looking backwards from the end of the buffer; they don't
>> need the full history.
>>
>
> Hmm. The trace buffer can certainly be compressed significantly:
>
> a) Only the following are significant:
> - call instructions
> - unconditional branch instructions
> - conditional branch instructions
>
> b) I can't see any need to ever go back further than the last
> conditional branch instruction
>
> c) For a given call or branch instruction, having a given (instruction
> address, target address) combination, the backwards scan for a such a
> pair will never go back further than the latest call or branch
> instruction that matches. So no harm in deleting earlier entries,
> provided every branch/call instruction deleted has a subsequent matching
> entry.
>
> Aside from the above (which are based on PO's pattern matching rules), I
> don't think it would be safe to prune further. In principle, an earlier
> call might not be matched until 30GB of trace later. (Of course, with
> further knowledge about /what/ is being decided we might know better,
> but in general (a)(b)(c) seems the best that is guaranteed for arbitrary
> input.)
>
> But most of all I'm surprised PO's trace buffer would fill up, unless
> there is an infinite loop in the picture. (Your "infinite tower" would
> constitute such a loop, I guess, but then by the time you need to
> compress, isn't it clear there's such an infinite loop, so no point
> going further?
>
>
> Mike.
>
D simulated by H cannot possibly reach its own return statement
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
This can be imagined at the C interpreter level.
--
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-10-28 16:44 +0000 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <20251028093641.813@kylheku.com> |
| In reply to | #134058 |
On 2025-10-28, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: > But most of all I'm surprised PO's trace buffer would fill up, unless there is an infinite loop in > the picture. (Your "infinite tower" would constitute such a loop, I guess, but then by the time you > need to compress, isn't it clear there's such an infinite loop, so no point going further? The execution trace quickly fills up because when you have a doubly nested simulation, it takes many instructions of the first level to simulate each instruction of the second level. Each interpretation level in an interpretation tower is vastly less efficient than the one above. The x86emu is particularly inefficient because it performs a detailed simulation unconcerned with efficiency (executing as few host instructions as possible to complete a target instruction). Say that the interpretation ratio is 100: 100 instructions of host for one instruction of target. To simulate just 100 instructions of the second traced level, the first traced level has to execute 10,000 instructions. If we could actually use "reckoning" to simulate the infinite tower indefinitely, we could be counteracting this interpretation ratio, because when the "reckoning" module takes over an abandoned simulation, it effectively hoists it to its own level (the top level). -- 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-10-28 17:24 +0000 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <10dqu7k$2833d$1@dont-email.me> |
| In reply to | #134068 |
On 28/10/2025 16:44, Kaz Kylheku wrote:
> On 2025-10-28, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>> But most of all I'm surprised PO's trace buffer would fill up, unless there is an infinite loop in
>> the picture. (Your "infinite tower" would constitute such a loop, I guess, but then by the time you
>> need to compress, isn't it clear there's such an infinite loop, so no point going further?
>
> The execution trace quickly fills up because when you have a doubly
> nested simulation, it takes many instructions of the first level to
> simulate each instruction of the second level.
Right, I'd thought about that - I think it's around 80 instructions at level n to simulate one level
n+1 instruction. That grows considerably if the trace table grows, at least for outer HHH given
that inner HHHs do not traverse the table.
But I'd rejected this explanation, because PO's code does not capture trace entries that from
addresses lower than the Halts() function. E.g. from Decide_Halting_HH() :
if (EIP > Last_Address_Of_Operating_System()) // Don't examine any OS code
{
PushBack(**execution_trace, (u32)*decoded, sizeof(Decoded_Line_Of_Code));
}
The PushBack is adding to the trace table, but only if (EIP > Last_Address_Of_Operating_System()).
In practice that means the instruction only traced if it's inside DD*(). All 80-ish instructions of
HHH that are part of the exponential explosion are filtered out.
(Or should be - I suppose it depends on the exact version of halt7.obj you're using. All the
versions I've seen do the filtering! In fact, if PO /didn't/ do the filtering his code would not
work for him, because all the HHH conditional branches would be inspected.)
Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-28 15:15 -0500 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <10dr88a$2d30f$1@dont-email.me> |
| In reply to | #134068 |
On 10/28/2025 11:44 AM, Kaz Kylheku wrote:
> On 2025-10-28, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>> But most of all I'm surprised PO's trace buffer would fill up, unless there is an infinite loop in
>> the picture. (Your "infinite tower" would constitute such a loop, I guess, but then by the time you
>> need to compress, isn't it clear there's such an infinite loop, so no point going further?
>
> The execution trace quickly fills up because when you have a doubly
> nested simulation, it takes many instructions of the first level to
> simulate each instruction of the second level.
>
> Each interpretation level in an interpretation tower is vastly less
> efficient than the one above.
>
> The x86emu is particularly inefficient because it performs a detailed
> simulation unconcerned with efficiency (executing as few host
> instructions as possible to complete a target instruction).
>
> Say that the interpretation ratio is 100: 100 instructions of host
> for one instruction of target. To simulate just 100 instructions of the
> second traced level, the first traced level has to execute 10,000
> instructions.
>
> If we could actually use "reckoning" to simulate the infinite tower
> indefinitely, we could be counteracting this interpretation ratio,
> because when the "reckoning" module takes over an abandoned simulation,
> it effectively hoists it to its own level (the top level).
>
Yet that is just cheating.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
Once H correctly determines that its
simulated D cannot possibly reach its
own simulated "return" statement its
just nuts to pickup the simulation
again after this.
--
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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-10-28 16:18 -0400 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <10dr8fg$2cj81$2@dont-email.me> |
| In reply to | #134095 |
On 10/28/2025 4:15 PM, olcott wrote:
> On 10/28/2025 11:44 AM, Kaz Kylheku wrote:
>> On 2025-10-28, Mike Terry
>> <news.dead.person.stones@darjeeling.plus.com> wrote:
>>> But most of all I'm surprised PO's trace buffer would fill up, unless
>>> there is an infinite loop in
>>> the picture. (Your "infinite tower" would constitute such a loop, I
>>> guess, but then by the time you
>>> need to compress, isn't it clear there's such an infinite loop, so no
>>> point going further?
>>
>> The execution trace quickly fills up because when you have a doubly
>> nested simulation, it takes many instructions of the first level to
>> simulate each instruction of the second level.
>>
>> Each interpretation level in an interpretation tower is vastly less
>> efficient than the one above.
>>
>> The x86emu is particularly inefficient because it performs a detailed
>> simulation unconcerned with efficiency (executing as few host
>> instructions as possible to complete a target instruction).
>>
>> Say that the interpretation ratio is 100: 100 instructions of host
>> for one instruction of target. To simulate just 100 instructions of the
>> second traced level, the first traced level has to execute 10,000
>> instructions.
>>
>> If we could actually use "reckoning" to simulate the infinite tower
>> indefinitely, we could be counteracting this interpretation ratio,
>> because when the "reckoning" module takes over an abandoned simulation,
>> it effectively hoists it to its own level (the top level).
>>
>
> Yet that is just cheating.
>
> int D()
> {
> int Halt_Status = H(D);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> H simulates D
> that calls H(D) to simulate D
> that calls H(D) to simulate D
> that calls H(D) to simulate D
> that calls H(D) to simulate D
> that calls H(D) to simulate D
> until H sees this repeating pattern.
>
> Once H correctly determines that its
> simulated D cannot possibly reach its
> own simulated "return" statement
But it didn't correctly determine that, as proven by Kaz's code.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-28 20:23 +0000 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <20251028131838.405@kylheku.com> |
| In reply to | #134095 |
On 2025-10-28, olcott <polcott333@gmail.com> wrote:
> On 10/28/2025 11:44 AM, Kaz Kylheku wrote:
>> On 2025-10-28, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>>> But most of all I'm surprised PO's trace buffer would fill up, unless there is an infinite loop in
>>> the picture. (Your "infinite tower" would constitute such a loop, I guess, but then by the time you
>>> need to compress, isn't it clear there's such an infinite loop, so no point going further?
>>
>> The execution trace quickly fills up because when you have a doubly
>> nested simulation, it takes many instructions of the first level to
>> simulate each instruction of the second level.
>>
>> Each interpretation level in an interpretation tower is vastly less
>> efficient than the one above.
>>
>> The x86emu is particularly inefficient because it performs a detailed
>> simulation unconcerned with efficiency (executing as few host
>> instructions as possible to complete a target instruction).
>>
>> Say that the interpretation ratio is 100: 100 instructions of host
>> for one instruction of target. To simulate just 100 instructions of the
>> second traced level, the first traced level has to execute 10,000
>> instructions.
>>
>> If we could actually use "reckoning" to simulate the infinite tower
>> indefinitely, we could be counteracting this interpretation ratio,
>> because when the "reckoning" module takes over an abandoned simulation,
>> it effectively hoists it to its own level (the top level).
>
> Yet that is just cheating.
In sport, and other contests, if you say "cheating" you have to open the
rule or law book to the right page and point out the broken rule.
Otherwise all you are saying is that you don't like it and are having
a tantrum.
All the code is public; you can say, such and such line of code
in such and such a file is violating ... whatever, and should
instead be coded like this.
If I agree with the problem, I will merge it and post new test results.
I am completely transparent and honest.
> int D()
> {
This repeated narrative is impertinent to the thread between Mike and myself.
Scoot along now Petey, grown-ups are talking.
--
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-10-28 16:00 -0500 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <10drat7$2dv9l$5@dont-email.me> |
| In reply to | #134098 |
On 10/28/2025 3:23 PM, Kaz Kylheku wrote:
> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>> On 10/28/2025 11:44 AM, Kaz Kylheku wrote:
>>> On 2025-10-28, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>>>> But most of all I'm surprised PO's trace buffer would fill up, unless there is an infinite loop in
>>>> the picture. (Your "infinite tower" would constitute such a loop, I guess, but then by the time you
>>>> need to compress, isn't it clear there's such an infinite loop, so no point going further?
>>>
>>> The execution trace quickly fills up because when you have a doubly
>>> nested simulation, it takes many instructions of the first level to
>>> simulate each instruction of the second level.
>>>
>>> Each interpretation level in an interpretation tower is vastly less
>>> efficient than the one above.
>>>
>>> The x86emu is particularly inefficient because it performs a detailed
>>> simulation unconcerned with efficiency (executing as few host
>>> instructions as possible to complete a target instruction).
>>>
>>> Say that the interpretation ratio is 100: 100 instructions of host
>>> for one instruction of target. To simulate just 100 instructions of the
>>> second traced level, the first traced level has to execute 10,000
>>> instructions.
>>>
>>> If we could actually use "reckoning" to simulate the infinite tower
>>> indefinitely, we could be counteracting this interpretation ratio,
>>> because when the "reckoning" module takes over an abandoned simulation,
>>> it effectively hoists it to its own level (the top level).
>>
>> Yet that is just cheating.
>
It must be a pure simulation until the repeating pattern is matched
Once the repeating pattern is matched it is flat out nuts to do
anything besides abort and reject. Are you flat out nuts?
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.
--
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-10-28 21:23 +0000 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <20251028141434.406@kylheku.com> |
| In reply to | #134106 |
On 2025-10-28, olcott <polcott333@gmail.com> wrote: > On 10/28/2025 3:23 PM, Kaz Kylheku wrote: >> On 2025-10-28, olcott <polcott333@gmail.com> wrote: >>> On 10/28/2025 11:44 AM, Kaz Kylheku wrote: >>>> On 2025-10-28, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >>>>> But most of all I'm surprised PO's trace buffer would fill up, unless there is an infinite loop in >>>>> the picture. (Your "infinite tower" would constitute such a loop, I guess, but then by the time you >>>>> need to compress, isn't it clear there's such an infinite loop, so no point going further? >>>> >>>> The execution trace quickly fills up because when you have a doubly >>>> nested simulation, it takes many instructions of the first level to >>>> simulate each instruction of the second level. >>>> >>>> Each interpretation level in an interpretation tower is vastly less >>>> efficient than the one above. >>>> >>>> The x86emu is particularly inefficient because it performs a detailed >>>> simulation unconcerned with efficiency (executing as few host >>>> instructions as possible to complete a target instruction). >>>> >>>> Say that the interpretation ratio is 100: 100 instructions of host >>>> for one instruction of target. To simulate just 100 instructions of the >>>> second traced level, the first traced level has to execute 10,000 >>>> instructions. >>>> >>>> If we could actually use "reckoning" to simulate the infinite tower >>>> indefinitely, we could be counteracting this interpretation ratio, >>>> because when the "reckoning" module takes over an abandoned simulation, >>>> it effectively hoists it to its own level (the top level). >>> >>> Yet that is just cheating. >> > > It must be a pure simulation until the repeating pattern is matched > Once the repeating pattern is matched it is flat out nuts to do > anything besides abort and reject. Are you flat out nuts? That's like saying it is flat out nuts to watch the rest of the security camera video past the point in which the suspect is seen putting an item into their pocket. As of to say, the shoplifting pattern has been identified, and that's all that is needed for a conviction. Effectively, there is no more video after that; they are "totally busted". But what if they just thave a habit of sticking things into their pocket and subsequently they go to the front and present the item to the cashier? You have to watch the whole security video to keep the accusers honest and fair. Similarly, we have to watch the whole "footage" of what DD does, not just up to the point where it is "accused" by HHH of nontermination, but everything after that. In the case of "Infinite_Loop", we do confirm that HHH is right by doing exactly that: if we keep stepping the simulation of Infinite_Loop, we find that it loops. Is that flat out nuts? Or is it only flat out nuts when it catches you being wrong? The abandoned simulation contains evidence which is relevant to HHH being correct or not. You cannot withhold evidence; that's a crime-like situation known as academic misconduct. In any case, re-animating abandoned simulations works in the x86utm; if it is nuts, point to the line of code that is wrong. -- 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-10-28 16:33 -0500 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <10drcrh$2f24b$1@dont-email.me> |
| In reply to | #134112 |
On 10/28/2025 4:23 PM, Kaz Kylheku wrote: > On 2025-10-28, olcott <polcott333@gmail.com> wrote: >> On 10/28/2025 3:23 PM, Kaz Kylheku wrote: >>> On 2025-10-28, olcott <polcott333@gmail.com> wrote: >>>> On 10/28/2025 11:44 AM, Kaz Kylheku wrote: >>>>> On 2025-10-28, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >>>>>> But most of all I'm surprised PO's trace buffer would fill up, unless there is an infinite loop in >>>>>> the picture. (Your "infinite tower" would constitute such a loop, I guess, but then by the time you >>>>>> need to compress, isn't it clear there's such an infinite loop, so no point going further? >>>>> >>>>> The execution trace quickly fills up because when you have a doubly >>>>> nested simulation, it takes many instructions of the first level to >>>>> simulate each instruction of the second level. >>>>> >>>>> Each interpretation level in an interpretation tower is vastly less >>>>> efficient than the one above. >>>>> >>>>> The x86emu is particularly inefficient because it performs a detailed >>>>> simulation unconcerned with efficiency (executing as few host >>>>> instructions as possible to complete a target instruction). >>>>> >>>>> Say that the interpretation ratio is 100: 100 instructions of host >>>>> for one instruction of target. To simulate just 100 instructions of the >>>>> second traced level, the first traced level has to execute 10,000 >>>>> instructions. >>>>> >>>>> If we could actually use "reckoning" to simulate the infinite tower >>>>> indefinitely, we could be counteracting this interpretation ratio, >>>>> because when the "reckoning" module takes over an abandoned simulation, >>>>> it effectively hoists it to its own level (the top level). >>>> >>>> Yet that is just cheating. >>> >> >> It must be a pure simulation until the repeating pattern is matched >> Once the repeating pattern is matched it is flat out nuts to do >> anything besides abort and reject. Are you flat out nuts? > > That's like saying it is flat out nuts to watch the rest of the security > camera video past the point in which the suspect is seen putting an item > into their pocket. As of to say, the shoplifting pattern has been > identified, and that's all that is needed for a conviction. > Effectively, there is no more video after that; they are "totally > busted". > > But what if they just thave a habit of sticking things into their > pocket and subsequently they go to the front and present the > item to the cashier? > Its not like that at all. It is like proving there is a number greater than ten by counting to eleven and then restarting this again and again at the next higher number after you have conclusively proven that the original criteria has been fully satisfied. -- 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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-10-28 18:01 -0400 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <10drefc$2fije$3@dont-email.me> |
| In reply to | #134106 |
On 10/28/2025 5:00 PM, olcott wrote: > On 10/28/2025 3:23 PM, Kaz Kylheku wrote: >> On 2025-10-28, olcott <polcott333@gmail.com> wrote: >>> On 10/28/2025 11:44 AM, Kaz Kylheku wrote: >>>> On 2025-10-28, Mike Terry >>>> <news.dead.person.stones@darjeeling.plus.com> wrote: >>>>> But most of all I'm surprised PO's trace buffer would fill up, >>>>> unless there is an infinite loop in >>>>> the picture. (Your "infinite tower" would constitute such a loop, >>>>> I guess, but then by the time you >>>>> need to compress, isn't it clear there's such an infinite loop, so >>>>> no point going further? >>>> >>>> The execution trace quickly fills up because when you have a doubly >>>> nested simulation, it takes many instructions of the first level to >>>> simulate each instruction of the second level. >>>> >>>> Each interpretation level in an interpretation tower is vastly less >>>> efficient than the one above. >>>> >>>> The x86emu is particularly inefficient because it performs a detailed >>>> simulation unconcerned with efficiency (executing as few host >>>> instructions as possible to complete a target instruction). >>>> >>>> Say that the interpretation ratio is 100: 100 instructions of host >>>> for one instruction of target. To simulate just 100 instructions of the >>>> second traced level, the first traced level has to execute 10,000 >>>> instructions. >>>> >>>> If we could actually use "reckoning" to simulate the infinite tower >>>> indefinitely, we could be counteracting this interpretation ratio, >>>> because when the "reckoning" module takes over an abandoned simulation, >>>> it effectively hoists it to its own level (the top level). >>> >>> Yet that is just cheating. >> > > It must be a pure simulation until the repeating pattern is matched But it is proven that the pattern is incorrect by performing a pure simulation further until the halt state is reached as proven by Kaz's code.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-28 12:03 -0700 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <10dr41k$29u1f$1@dont-email.me> |
| In reply to | #134058 |
On 10/28/2025 8:18 AM, Mike Terry wrote:
> On 28/10/2025 06:02, Kaz Kylheku wrote:
>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>> On 10/27/2025 10:54 PM, Kaz Kylheku wrote:
>>>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>>>>>> Once H has correctly determines that its simulated
>>>>>>> D cannot possibly reach its own simulated "return"
>>>>>>> instruction final halt state it is nutty to do
>>>>>>> anything else besides abort and reject the input.
>>>>>>
>>>>>> I have traces which prove otherwise.
>>>>>
>>>>> Then you can't be telling the truth.
>>>>
>>>> LOL!
>>>>
>>>> Have you forgotten? (Sigh, I'm afraid the answer is yes ...)
>>>>
>>>> - You used to post execution traces claiming that they
>>>> proved you were right.
>>>>
>>>> - You used to deride others for not following your
>>>> execution traces in detail (maybe they are not skilled
>>>> engineers)
>>>>
>>>>>
>>>>> int D()
>>>>> {
>>>>> int Halt_Status = H(D);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>> H simulates D
>>>>> that calls H(D) to simulate D
>>>>
>>>> This is just empty claptrap about an ill-defined program
>>>> with a missing definition of H, not an execution trace.
>>>>
>>>
>>> So you cannot begin to imagine WTF happens when D
>>> is simulated by H?
>>
>> Of course I can. First H has to call Init_Halts_H to allocate resources
>> for the simulation and do certain initialiations not particuliar to D.
>>
>> Then Init_Slave_State to point the simulation at D and prime its stack.
>>
>> Then a function called Decide_Halting is called that contains the
>> main single stepping loop which checks for certain conditions with
>> a helper function called Needs_To_Be_Aborted.
>>
>> Decide_Halting pushes each decoded instruction into the shared trace
>> buffer which is examined by Needs_To_Be_Aborted.
>>
>> I've diescovered that this trace buffer can be virtually infinite; I
>> turned it into a sliding window due to needing more space, but not
>> wanting to modify the Halt7.obj whose compiled code establishes the
>> trace buffer size.
>>
>> When the execution trace buffer fills up, we don't have to abort
>> the x86utm. We can just trim old information at the front of
>> the buffer and move it down. Unless I'm mistaken, The abort decisions
>> are made by looking backwards from the end of the buffer; they don't
>> need the full history.
>>
>
> Hmm. The trace buffer can certainly be compressed significantly:
>
> a) Only the following are significant:
> - call instructions
> - unconditional branch instructions
> - conditional branch instructions
>
> b) I can't see any need to ever go back further than the last
> conditional branch instruction
>
> c) For a given call or branch instruction, having a given (instruction
> address, target address) combination, the backwards scan for a such a
> pair will never go back further than the latest call or branch
> instruction that matches. So no harm in deleting earlier entries,
> provided every branch/call instruction deleted has a subsequent matching
> entry.
>
> Aside from the above (which are based on PO's pattern matching rules), I
> don't think it would be safe to prune further. In principle, an earlier
> call might not be matched until 30GB of trace later. (Of course, with
> further knowledge about /what/ is being decided we might know better,
> but in general (a)(b)(c) seems the best that is guaranteed for arbitrary
> input.)
>
> But most of all I'm surprised PO's trace buffer would fill up, unless
> there is an infinite loop in the picture.
Humm... How many times does HHH(DD) return to dictate what DD should do,
halt or not... If it just sits there recursing, it might never return to
DD? If Olcott needs to artificially terminate the "internal" HHH(DD)
recursion? Try to avoid blowing the stack in a sense... If it does
return to DD, than BAM all of those return values are going to be
exposed to DD via Halt_Status, DD will halt or hit that GOTO loop. It
reminds me of a recursion with a limit. If that limit is breached, then
Olcott says DD is non-halting! Well, that is totally wrong... DD can
sometimes halt, other times, not-halt. Fair enough?
> (Your "infinite tower" would
> constitute such a loop, I guess, but then by the time you need to
> compress, isn't it clear there's such an infinite loop, so no point
> going further?
For some reason it makes me think of iteration vs. recursion. Humm...
The fuzzer just exposes the "instrumented" program to its values and
tries to see if all paths were hit. Its running in a loop, and not
allocating anything on each iteration, ect... It can run forever, and
not bring the system down with any out of memory conditions. Recursion,
that is a different story. We need to make sure it does not blow the
stack...? Humm...
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-28 19:56 +0000 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <20251028123744.602@kylheku.com> |
| In reply to | #134083 |
On 2025-10-28, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 10/28/2025 8:18 AM, Mike Terry wrote:
>> On 28/10/2025 06:02, Kaz Kylheku wrote:
>>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>>> On 10/27/2025 10:54 PM, Kaz Kylheku wrote:
>>>>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>>>>> On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>>>>>>> Once H has correctly determines that its simulated
>>>>>>>> D cannot possibly reach its own simulated "return"
>>>>>>>> instruction final halt state it is nutty to do
>>>>>>>> anything else besides abort and reject the input.
>>>>>>>
>>>>>>> I have traces which prove otherwise.
>>>>>>
>>>>>> Then you can't be telling the truth.
>>>>>
>>>>> LOL!
>>>>>
>>>>> Have you forgotten? (Sigh, I'm afraid the answer is yes ...)
>>>>>
>>>>> - You used to post execution traces claiming that they
>>>>> proved you were right.
>>>>>
>>>>> - You used to deride others for not following your
>>>>> execution traces in detail (maybe they are not skilled
>>>>> engineers)
>>>>>
>>>>>>
>>>>>> int D()
>>>>>> {
>>>>>> int Halt_Status = H(D);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> return Halt_Status;
>>>>>> }
>>>>>>
>>>>>> H simulates D
>>>>>> that calls H(D) to simulate D
>>>>>
>>>>> This is just empty claptrap about an ill-defined program
>>>>> with a missing definition of H, not an execution trace.
>>>>>
>>>>
>>>> So you cannot begin to imagine WTF happens when D
>>>> is simulated by H?
>>>
>>> Of course I can. First H has to call Init_Halts_H to allocate resources
>>> for the simulation and do certain initialiations not particuliar to D.
>>>
>>> Then Init_Slave_State to point the simulation at D and prime its stack.
>>>
>>> Then a function called Decide_Halting is called that contains the
>>> main single stepping loop which checks for certain conditions with
>>> a helper function called Needs_To_Be_Aborted.
>>>
>>> Decide_Halting pushes each decoded instruction into the shared trace
>>> buffer which is examined by Needs_To_Be_Aborted.
>>>
>>> I've diescovered that this trace buffer can be virtually infinite; I
>>> turned it into a sliding window due to needing more space, but not
>>> wanting to modify the Halt7.obj whose compiled code establishes the
>>> trace buffer size.
>>>
>>> When the execution trace buffer fills up, we don't have to abort
>>> the x86utm. We can just trim old information at the front of
>>> the buffer and move it down. Unless I'm mistaken, The abort decisions
>>> are made by looking backwards from the end of the buffer; they don't
>>> need the full history.
>>>
>>
>> Hmm. The trace buffer can certainly be compressed significantly:
>>
>> a) Only the following are significant:
>> - call instructions
>> - unconditional branch instructions
>> - conditional branch instructions
>>
>> b) I can't see any need to ever go back further than the last
>> conditional branch instruction
>>
>> c) For a given call or branch instruction, having a given (instruction
>> address, target address) combination, the backwards scan for a such a
>> pair will never go back further than the latest call or branch
>> instruction that matches. So no harm in deleting earlier entries,
>> provided every branch/call instruction deleted has a subsequent matching
>> entry.
>>
>> Aside from the above (which are based on PO's pattern matching rules), I
>> don't think it would be safe to prune further. In principle, an earlier
>> call might not be matched until 30GB of trace later. (Of course, with
>> further knowledge about /what/ is being decided we might know better,
>> but in general (a)(b)(c) seems the best that is guaranteed for arbitrary
>> input.)
>>
>> But most of all I'm surprised PO's trace buffer would fill up, unless
>> there is an infinite loop in the picture.
>
> Humm... How many times does HHH(DD) return to dictate what DD should do,
> halt or not... If it just sits there recursing, it might never return to
During the initial simulation, we do see two DDD simulations fire up.
So we have the first level whose instructions are traced. It calls
into HHH, which goes into into a complicated x86emu, all of whose
numerous instructions are traced just to simulate one instruction
of the second level DDD.
Then when I resume the original DDD with "reckoning", two more DDD
simulations fire up again.
So by then there is enough shit circling the toilet bowl by then that a
clog is imminent.
> DD? If Olcott needs to artificially terminate the "internal" HHH(DD)
> recursion? Try to avoid blowing the stack in a sense... If it does
> return to DD, than BAM all of those return values are going to be
> exposed to DD via Halt_Status, DD will halt or hit that GOTO loop. It
> reminds me of a recursion with a limit. If that limit is breached, then
> Olcott says DD is non-halting! Well, that is totally wrong... DD can
> sometimes halt, other times, not-halt. Fair enough?
Launching a simulation isn't a recursive call though; control does
not pass from the master to the slave. Control passes from the master
into a loop which simulates the slave. In Olcott's system, the slave
gets its own stack, so it is like a cooperative thread. (He knows it;
he has referred to the x86utm as a cooperatively tasked OS.)
If we liberate the memory occupied by simualtions which have terminated,
it's possible that the tower could be capable executing forever in a
fixed amount of RAM, if there is a master loop which pushes it forward:
the reckoning module or something like it has to keep monitoring the
list of simulations and carefully pick the right ones to push forward.
Not all the simulations in the list are abandoned. E.g. in our above
scenario when the top DDD is abandoned, its child DDD is not abandoned;
it is still referenced by DDD.
If we track the parentage between simulations (seems easily dable) then
we can sweep through the list and identify a simulation which has no
parent that is still in the list. We can step that one to completion and
then remove it from the list, and repeat.
With the right test case, this should just run forever, in spite
of the individual simulations terminating.
One thing that must be considered is that the reckoning module does
not record execution traces.
>
>
>> (Your "infinite tower" would
>> constitute such a loop, I guess, but then by the time you need to
>> compress, isn't it clear there's such an infinite loop, so no point
>> going further?
>
> For some reason it makes me think of iteration vs. recursion. Humm...
The launch of a simulation is a function call if it is done
to completion: the caller who launched the simulation is suspended
until the simulation ends.
This kind of function call powers most of or modern tech stacks,
which make use of languages which are interpreted directly or via
virtual machines.
When an interpreted function is called, the caller actually starts
a simulation; it has called into a loop in the virtual machine.
Because there is no execution monitoring and no abort, we have
a perfect illusion that control has passed into the VM domain
and then returned.
VMs can allocate their resources on the "native" stack, so that
runaway recursion among VM functions can blow the real stack.
--
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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-28 13:27 -0700 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <10dr8vm$291ll$2@dont-email.me> |
| In reply to | #134092 |
On 10/28/2025 12:56 PM, Kaz Kylheku wrote:
> On 2025-10-28, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 10/28/2025 8:18 AM, Mike Terry wrote:
>>> On 28/10/2025 06:02, Kaz Kylheku wrote:
>>>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/27/2025 10:54 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>>>>>> On 10/27/2025 10:40 PM, Kaz Kylheku wrote:
>>>>>>>> On 2025-10-28, olcott <polcott333@gmail.com> wrote:
>>>>>>>>> Once H has correctly determines that its simulated
>>>>>>>>> D cannot possibly reach its own simulated "return"
>>>>>>>>> instruction final halt state it is nutty to do
>>>>>>>>> anything else besides abort and reject the input.
>>>>>>>>
>>>>>>>> I have traces which prove otherwise.
>>>>>>>
>>>>>>> Then you can't be telling the truth.
>>>>>>
>>>>>> LOL!
>>>>>>
>>>>>> Have you forgotten? (Sigh, I'm afraid the answer is yes ...)
>>>>>>
>>>>>> - You used to post execution traces claiming that they
>>>>>> proved you were right.
>>>>>>
>>>>>> - You used to deride others for not following your
>>>>>> execution traces in detail (maybe they are not skilled
>>>>>> engineers)
>>>>>>
>>>>>>>
>>>>>>> int D()
>>>>>>> {
>>>>>>> int Halt_Status = H(D);
>>>>>>> if (Halt_Status)
>>>>>>> HERE: goto HERE;
>>>>>>> return Halt_Status;
>>>>>>> }
>>>>>>>
>>>>>>> H simulates D
>>>>>>> that calls H(D) to simulate D
>>>>>>
>>>>>> This is just empty claptrap about an ill-defined program
>>>>>> with a missing definition of H, not an execution trace.
>>>>>>
>>>>>
>>>>> So you cannot begin to imagine WTF happens when D
>>>>> is simulated by H?
>>>>
>>>> Of course I can. First H has to call Init_Halts_H to allocate resources
>>>> for the simulation and do certain initialiations not particuliar to D.
>>>>
>>>> Then Init_Slave_State to point the simulation at D and prime its stack.
>>>>
>>>> Then a function called Decide_Halting is called that contains the
>>>> main single stepping loop which checks for certain conditions with
>>>> a helper function called Needs_To_Be_Aborted.
>>>>
>>>> Decide_Halting pushes each decoded instruction into the shared trace
>>>> buffer which is examined by Needs_To_Be_Aborted.
>>>>
>>>> I've diescovered that this trace buffer can be virtually infinite; I
>>>> turned it into a sliding window due to needing more space, but not
>>>> wanting to modify the Halt7.obj whose compiled code establishes the
>>>> trace buffer size.
>>>>
>>>> When the execution trace buffer fills up, we don't have to abort
>>>> the x86utm. We can just trim old information at the front of
>>>> the buffer and move it down. Unless I'm mistaken, The abort decisions
>>>> are made by looking backwards from the end of the buffer; they don't
>>>> need the full history.
>>>>
>>>
>>> Hmm. The trace buffer can certainly be compressed significantly:
>>>
>>> a) Only the following are significant:
>>> - call instructions
>>> - unconditional branch instructions
>>> - conditional branch instructions
>>>
>>> b) I can't see any need to ever go back further than the last
>>> conditional branch instruction
>>>
>>> c) For a given call or branch instruction, having a given (instruction
>>> address, target address) combination, the backwards scan for a such a
>>> pair will never go back further than the latest call or branch
>>> instruction that matches. So no harm in deleting earlier entries,
>>> provided every branch/call instruction deleted has a subsequent matching
>>> entry.
>>>
>>> Aside from the above (which are based on PO's pattern matching rules), I
>>> don't think it would be safe to prune further. In principle, an earlier
>>> call might not be matched until 30GB of trace later. (Of course, with
>>> further knowledge about /what/ is being decided we might know better,
>>> but in general (a)(b)(c) seems the best that is guaranteed for arbitrary
>>> input.)
>>>
>>> But most of all I'm surprised PO's trace buffer would fill up, unless
>>> there is an infinite loop in the picture.
>>
>> Humm... How many times does HHH(DD) return to dictate what DD should do,
>> halt or not... If it just sits there recursing, it might never return to
>
> During the initial simulation, we do see two DDD simulations fire up.
> So we have the first level whose instructions are traced. It calls
> into HHH, which goes into into a complicated x86emu, all of whose
> numerous instructions are traced just to simulate one instruction
> of the second level DDD.
>
> Then when I resume the original DDD with "reckoning", two more DDD
> simulations fire up again.
>
> So by then there is enough shit circling the toilet bowl by then that a
> clog is imminent.
>
>> DD? If Olcott needs to artificially terminate the "internal" HHH(DD)
>> recursion? Try to avoid blowing the stack in a sense... If it does
>> return to DD, than BAM all of those return values are going to be
>> exposed to DD via Halt_Status, DD will halt or hit that GOTO loop. It
>> reminds me of a recursion with a limit. If that limit is breached, then
>> Olcott says DD is non-halting! Well, that is totally wrong... DD can
>> sometimes halt, other times, not-halt. Fair enough?
>
> Launching a simulation isn't a recursive call though; control does
> not pass from the master to the slave. Control passes from the master
> into a loop which simulates the slave. In Olcott's system, the slave
> gets its own stack, so it is like a cooperative thread. (He knows it;
> he has referred to the x86utm as a cooperatively tasked OS.)
Nice write up. I need more time for a proper read. Humm... DD can be
instrumented to use fibers for sure. If a fiber hits the GOTO loop, each
iteration of the loop can be run. Put in a yield at every path... Say,
the goto loop says:
10 REM GOTO PATH HIT!
20 YIELD
30 GOTO 10
lol. I bet that Olcott does not remember that basic trick of goto a REM
can be altered (POKE's) later. ;^)
>
> If we liberate the memory occupied by simualtions which have terminated,
> it's possible that the tower could be capable executing forever in a
> fixed amount of RAM, if there is a master loop which pushes it forward:
> the reckoning module or something like it has to keep monitoring the
> list of simulations and carefully pick the right ones to push forward.
>
> Not all the simulations in the list are abandoned. E.g. in our above
> scenario when the top DDD is abandoned, its child DDD is not abandoned;
> it is still referenced by DDD.
>
> If we track the parentage between simulations (seems easily dable) then
> we can sweep through the list and identify a simulation which has no
> parent that is still in the list. We can step that one to completion and
> then remove it from the list, and repeat.
>
> With the right test case, this should just run forever, in spite
> of the individual simulations terminating.
>
> One thing that must be considered is that the reckoning module does
> not record execution traces.
>
>>
>>
>>> (Your "infinite tower" would
>>> constitute such a loop, I guess, but then by the time you need to
>>> compress, isn't it clear there's such an infinite loop, so no point
>>> going further?
>>
>> For some reason it makes me think of iteration vs. recursion. Humm...
>
> The launch of a simulation is a function call if it is done
> to completion: the caller who launched the simulation is suspended
> until the simulation ends.
>
> This kind of function call powers most of or modern tech stacks,
> which make use of languages which are interpreted directly or via
> virtual machines.
>
> When an interpreted function is called, the caller actually starts
> a simulation; it has called into a loop in the virtual machine.
>
> Because there is no execution monitoring and no abort, we have
> a perfect illusion that control has passed into the VM domain
> and then returned.
>
> VMs can allocate their resources on the "native" stack, so that
> runaway recursion among VM functions can blow the real stack.
Does it allow for one to hook into events for every instruction? Say x86
XCHG, CMPXCHG, XADD, MOV, LEA, ect...
Say our listener gets XCHG with a line number and its parameters and the
current stack state? Say a prolog and epilog event for a single instruction:
XCHG.raise_prolog(...)
XCHG ... actually run the XCHG on the read machine
XCHG.raise_epilog(...)?
Every instruction has these callbacks. Is that just way off base? Sorry.
We say of course this is expensive. But, it makes for fun data!
;^)
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.org> |
|---|---|
| Date | 2025-10-28 08:40 +0000 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <10dpvhi$1op5o$4@dont-email.me> |
| In reply to | #134008 |
Am Mon, 27 Oct 2025 23:01:52 -0500 schrieb olcott: > H simulates D > that calls H(D) to simulate D > that calls H(D) here > to simulate D > that calls H(D) to simulate D > that calls H(D) to simulate D > that calls H(D) to simulate D > until H sees this repeating pattern. Nothing past the marked point happens. -- 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-10-28 09:43 -0500 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <10dqkq5$238f6$1@dont-email.me> |
| In reply to | #134027 |
On 10/28/2025 3:40 AM, joes wrote: > Am Mon, 27 Oct 2025 23:01:52 -0500 schrieb olcott: > >> H simulates D >> that calls H(D) to simulate D >> that calls H(D) > here > >> to simulate D >> that calls H(D) to simulate D >> that calls H(D) to simulate D >> that calls H(D) to simulate D >> until H sees this repeating pattern. > > Nothing past the marked point happens. > H is not in the repository it is a new hypothetical basis for my next paper. I have to repeat several times so that people brand new to the idea of simulating termination analyzer get the point. -- 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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-28 12:08 -0700 |
| Subject | Re: D simulated by H cannot possibly reach past its own first line |
| Message-ID | <10dr4b5$29u1f$2@dont-email.me> |
| In reply to | #134048 |
On 10/28/2025 7:43 AM, olcott wrote: > On 10/28/2025 3:40 AM, joes wrote: >> Am Mon, 27 Oct 2025 23:01:52 -0500 schrieb olcott: >> >>> H simulates D >>> that calls H(D) to simulate D >>> that calls H(D) >> here >> >>> to simulate D >>> that calls H(D) to simulate D >>> that calls H(D) to simulate D >>> that calls H(D) to simulate D >>> until H sees this repeating pattern. >> >> Nothing past the marked point happens. >> > > H is not in the repository it is a new hypothetical > basis for my next paper. Pure Genius! lol. > > I have to repeat several times so that people > brand new to the idea of simulating termination > analyzer get the point. >
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.theory
csiph-web