| Deutsch English Français Italiano |
|
<b0353d6a40aab27375c36cdf5f745e281a7bc25f@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Overcoming the proof of undecidability of the Halting Problem by
a simple example in C
Date: Fri, 16 May 2025 09:40:36 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <b0353d6a40aab27375c36cdf5f745e281a7bc25f@i2pn2.org>
References: <1005jsk$3akrk$1@dont-email.me>
<FAsVP.790302$BFJ.344089@fx13.ams4> <1005la7$3akrk$3@dont-email.me>
<tSsVP.790303$BFJ.255821@fx13.ams4> <1005mms$3akrk$4@dont-email.me>
<rBtVP.134541$0ia.111399@fx11.ams4> <1005t5g$3chps$1@dont-email.me>
<540244fc679b0c837eae09d6351d3c0571e2fce2@i2pn2.org>
<10067bl$3dmiv$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 16 May 2025 14:07:42 -0000 (UTC)
Injection-Info: i2pn2.org;
logging-data="604827"; mail-complaints-to="usenet@i2pn2.org";
posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <10067bl$3dmiv$4@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
On 5/15/25 10:19 PM, olcott wrote:
> 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.
>
>
Nope, just shows that you are stupid and don't know what you are talking
about.
The problem is your HHH just is not a emulator, as you HHH, as you have
defined it, is just your code in Halt7.c, which has no code in it to be
an emulator. And you can't consider the code of x86UTM as actually part
of HHH as then HHH, when it tries to emulate the full program of DD, and
the HHH that it calls needs to then also emulate the code of that x86utm
that is providing its functionality.
This FACT seems to be beyond your understanding, as you just can't seem
to handle things with any real complication.