Re: Richard seems to continue to blatantly lie -- I hope I am wrong about this

On 7/9/2024 1:09 AM, Barb Knox wrote:

On 04/07/2024 13:53, Richard Damon wrote:

On 7/3/24 9:30 PM, olcott wrote:

On 7/3/2024 8:12 PM, Richard Damon wrote:

On 7/3/24 8:36 PM, olcott wrote:

On 7/3/2024 6:18 PM, Richard Damon wrote:

On 7/3/24 2:20 PM, olcott wrote:

_DDD()
[00002172] 55               push ebp      ; housekeeping
[00002173] 8bec             mov ebp,esp   ; housekeeping
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call HHH(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret

 [...]
 Can someone please explain to me why a discussion of the Halting Problem is using Intel assembly laguage?
 

I haven't spoken to you in 12 years.
Examining the halting problem at the 100% concrete level of the
x86 programming language completely eliminates all gaps in
reasoning at the Turing machine level. This totally eliminates
all false assumptions.
Here is the most recent rewrite of my paper, it has been written
about 100 times. The latest revision of 14 rewrites is out on
researchgate.net. Each rewrite has at least ten revisions.
*Termination Analyzer H is Not Fooled by Pathological Input D*
https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
The above paper take the reader through several very simple
examples with the last one being an input that calls its
own termination analyzer. This has been the bulk of the recent
discussion. The next example is the conventional Halting Problem
input: DD and HH.
void DDD()
{
   HHH(DDD);
}
The last half of the paper shows the same reasoning applied
to the Peter Linz Halting problem proof. The key advantage
of a simulating termination analyzer is that when DD is
correctly simulated by HH is can never reach the self-contradictory
past of DD because it remains stuck in recursive simulation.
This is a world class termination analyzer that works on the
same basis as my x86utm termination analyzer by building a
directed graph of the control flow on the basis of the dynamic
behavior specified by a lower level form of the C input.
*AProVE: Non-Termination Witnesses for C Programs*
To prove (non-)termination of a C program, AProVE uses the Clang
compiler [7] to translate it to the intermediate representation
of the LLVM framework [15]. Then AProVE symbolically executes
the LLVM program and uses abstraction to obtain a finite symbolic
execution graph (SEG) containing all possible program runs.
https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf
I spent about 18 months creating the x86utm operating system
that uses a high quality x86 emulator that provides a way for
one C function to emulate the machine language of another C
function in DebugStep() mode.
This provides the way for to apply the modern notion of a
termination analyzer to some theory of computation problems.
The x86 language is a proxy for the Turing Machine description
language and the x86utm operating system is a proxy for a UTM.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer