Re: Overcoming the proof of undecidability of the Halting Problem by a simple example in C

On 5/15/2025 9:07 PM, Richard Damon wrote:

On 5/15/25 7:25 PM, olcott wrote:

On 5/15/2025 5:08 PM, Mr Flibble wrote:

On Thu, 15 May 2025 16:35:24 -0500, olcott wrote:
>

On 5/15/2025 4:18 PM, Mr Flibble wrote:

On Thu, 15 May 2025 16:11:35 -0500, olcott wrote:
>

On 5/15/2025 3:59 PM, Mr Flibble wrote:

On Thu, 15 May 2025 15:47:16 -0500, olcott wrote:
>

I overcome the proof of undecidability of the Halting Problem in
that the code that "does the opposite of whatever value that HHH
returns" becomes unreachable to DD correctly simulated by HHH.
>
int DD()
     {
      int Halt_Status = HHH(DD);
      if (Halt_Status)
        HERE: goto HERE;
      return Halt_Status;
     }
>
HHH simulates DD that calls HHH(DD) to simulate itself again over
and over until HHH sees this repeating pattern and aborts or both
HHH and DD crash due to OOM error.

It is not possible for HHH to simulate DD because we are already
inside DD when we call HHH:

>
Since HHH does correctly simulate itself simulating DD we have
complete proof that you are wrong.
>
I had to write the whole x86utm operating system to make this work.

>
It is not possible to make this work even by "writing an operating
system"
so whatever you think you are doing it isn't addressing my core point:
you are NOT *fully* simulating DD by HHH because you are already inside
DD when you are calling HHH.
>
/Flibble

>
Anyone that is intimately familiar with how multi-tasking operating
systems work will understand how HHH could emulate itself emulating its
input.

>
What has multi-tasking got to do with it?  You are talking out of your
arse, Peter. :)
>

>
Anyone that is intimately familiar with multi-tasking
operating systems will know the details of how HHH
emulates itself emulating DDD.
>
Whenever any HHH is about to begin emulating an input
it requests a separate process context with its own
virtual registers and stack from the x86utm operating
system. Then HHH calls the x86utm operating system
to execute
>
u32  DebugStep(Registers* master_state,
                Registers* slave_state, Decoded_Line_Of_Code* decoded)
>
each instruction one-at-a-time as cooperative multi-tasking.

 Which means your "simulator" isn't actually a Simulator. it just is directly running the program in a debug single step mode.
 

Yes and by the same reasoning an x86 emulator
IS NOT an x86 emulator it IS an actual x86 chip.
Quit acting like a freaking moron you are much
smarter than that.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer