Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.theory Subject: Re: Overcoming the proof of undecidability of the Halting Problem by a simple example in C Date: Sat, 17 May 2025 00:04:38 -0500 Organization: A noiseless patient Spider Lines: 70 Message-ID: <10095d6$73dt$3@dont-email.me> References: <1005jsk$3akrk$1@dont-email.me> <1005u6v$3cpt2$1@dont-email.me> <1005v0p$3b07v$1@dont-email.me> <10063u0$3dmiv$1@dont-email.me> <1006on8$3l9t7$1@dont-email.me> <1007kgq$3qb7l$9@dont-email.me> <1007mp8$3r37u$1@dont-email.me> <1008jgl$j63$3@dont-email.me> <1008o88$1bg1$1@dont-email.me> <1008s18$5uqc$1@dont-email.me> <1008t5g$1bg1$2@dont-email.me> <1008tr4$66kl$2@dont-email.me> <100901g$1bg1$3@dont-email.me> <10090vl$6mor$2@dont-email.me> <1009266$1bg1$4@dont-email.me> <10093pv$73dt$1@dont-email.me> <10094n4$1bg1$5@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 17 May 2025 07:04:38 +0200 (CEST) Injection-Info: dont-email.me; posting-host="6ea8251727358be87ec7627194d1f4d0"; logging-data="232893"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18znqOHXf/laH5qw3ROVnrl" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:mAwT5KrDBir7dleUAbsT3kOCdMU= X-Antivirus-Status: Clean Content-Language: en-US X-Antivirus: Norton (VPS 250516-6, 5/16/2025), Outbound message In-Reply-To: <10094n4$1bg1$5@dont-email.me> Bytes: 4100 On 5/16/2025 11:52 PM, Richard Heathfield wrote: > On 17/05/2025 05:37, olcott wrote: >> On 5/16/2025 11:09 PM, Richard Heathfield wrote: >>> On 17/05/2025 04:49, olcott wrote: >>> >>> >>> >>>> It is possible to create a C function that >>>> simulates the source-code of other C functions. >>>> The essential idea of this is a C interpreter. >>> >>> No. You clearly have no idea what an interpreter is. >>> >>> A C interpreter translates C, just as a C compiler translates C, the >>> difference being that the compiler writes down the translation (like >>> a book translator in a publishing house) while the interpreter says >>> it out loud, so to speak (like an interpreter at a United Nations >>> meeting). >>> >>> In each case, the input is C, not machine code. >>> >>>> The actual HHH uses x86 emulation that is way >>>> over most peoples heads. >>> >>> Clearly not a C interpreter, then. >>> >> >> Modern language are a hybrid between compiling >> and interpreting. Java compiles to byte code. > > Non sequitur. Your program is neither a compiler nor an interpreter. It > doesn't compile C to byte code or anything else because you don't give > it any C to compile. > >> Interpreters translate code line-by-line and immediately execute each >> one in real-time, without a separate compilation phase. The >> interpreter effectively runs and translates the program >> simultaneously. This means changes to the code can take effect >> instantly, without waiting for compilation. But this flexibility comes >> at a performance cost relative to compiled programs. > > All correct. Well read and accurately quoted. > >> https://thelinuxcode.com/interpreters-c-programming/ > > It's hard to fathom how you could have read the explanation on that Web > page and yet somehow continue to believe that you have written a C > interpreter. > Did I ever say anything like that? No! I didn't even write the x86 emulator. I integrated an x86 emulator into a multi-tasking operating system named x86utm. void DDD() { HHH(DDD); return; } We can easily imagine what the behavior of DDD correctly simulated by HHH is including HHH emulating itself emulating DDD. -- Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer