XPost: comp.theory   
   From: 643-408-1753@kylheku.com   
      
   On 2025-10-28, olcott  wrote:   
   > On 10/27/2025 10:54 PM, Kaz Kylheku wrote:   
   >> On 2025-10-28, olcott  wrote:   
   >>> On 10/27/2025 10:40 PM, Kaz Kylheku wrote:   
   >>>> On 2025-10-28, olcott  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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)