Re: Liar detector: Fred, Richard, Joes and Alan --- Ben's agreement

On 2024-07-14 14:26:21 +0000, olcott said:

On 7/14/2024 2:56 AM, Mikko wrote:

On 2024-07-13 11:57:59 +0000, olcott said:
 

On 7/13/2024 2:46 AM, Mikko wrote:

On 2024-07-12 13:07:59 +0000, olcott said:
 

On 7/12/2024 2:55 AM, Mikko wrote:

On 2024-07-11 14:16:34 +0000, olcott said:
 

On 7/11/2024 1:50 AM, Mikko wrote:

On 2024-07-10 13:37:30 +0000, olcott said:
 

On 7/10/2024 2:18 AM, Mikko wrote:

On 2024-07-09 14:14:16 +0000, olcott said:
 

On 7/9/2024 1:14 AM, Mikko wrote:

On 2024-07-08 17:36:58 +0000, olcott said:
 

On 7/8/2024 11:16 AM, Fred. Zwarts wrote:

Op 08.jul.2024 om 18:07 schreef olcott:

 Try to show how infinity is one cycle too soon.
 

You believe that two equals infinity.

 void Infinite_Loop()
{
   HERE: goto HERE;
}
 void Infinite_Recursion()
{
   Infinite_Recursion();
}
 void DDD()
{
   HHH(DDD);
}
 Two cycles is enough to correctly determine that none
of the above functions correctly emulated by HHH can
possibly halt.
 That you don't see this is ignorance or deception.

 There is an important detail that determines whether an infinite
execution can be inferred. That is best illustrated by the following
examples:
 void Finite_Loop()
{
  int x = 10000;
HERE:
  if (x > 0) {
    x--;
    goto HERE;
  }
}
 void Finite_Recursion(int n)
{
  if (n > 0) {
    Finite_Recursion(n + 1);
  }
}
 void DDD()
{
  HHH(DDD); // HHH detects recursive simulation and then simulates no more
}
 The important difference is that in my examples there is a conditional
instruction that can (and does) prevent infinite exectuion.
 

 When we ask:
Does the call from DDD emulated by HHH to HHH(DDD) return?

 Why would anyone ask that? A question should make clear its topic.
Instead one could ask whether HHH can fully emulate DDD if that is
what one wants to know. Or one may think that HHH and DDD are so
unimteresting that there is no point to ask anyting about them.

 A correct emulator can correctly any correct x86 instructions.
When it emulates non-halting code then itself does not halt.

 Not quite right but should be easy to fix. There should be a verb before "any",
for example "execute". Of course there still is a probelm with the meaning
"any correct x86 instructions". Intel may publish a new x86 processor that has
instructios that the emulator cannot know but are nevertheless correct x86
instructions because Intel says so. In the second sentence "it" should be used
istead of "itself".
 

 Intel has already done this and they call this x64.
A 1907 Model-T Ford cannot have upgrades and still
be a 1907 model-T Ford. Likewise for the x86 language.

 A new version of a 1907 Model-T Ford is possible and can have the same name
except that the "1907" must be replaced as it refers to the year. That the
"Model-T" is also replaced is a free chioce of Ford.
 Likewise Intel is free to call a new processor whatever they want to call it.
 

 The x86 language is a fixed constant.

 Where has Intel promised so?
 

 Backward compatibility requires it.
https://en.wikipedia.org/wiki/X86_assembly_language#:~:text=x86%20assembly%20language%20is%20the,was%20launched%20in%20April%201972. 

 That is about the assembly language, not about the machine instruction set.
It does not say much about backwards compatibitlity and does not say that
Intel has promised anything about that.
 Policy of backwards compatibilty does not mean that every x86 proscessor
has exactly the same machine language as 8086. Later version have introduced
new instructions and new processor modes and Intel is not prohibited from
adding still more in future models. It only means that the meanings of the
existing instructions are not changed when executed in existing modes.
 

 When I refer to the x86 language I am referring to the minimal
subset that runs the same way on compatible Intel 32-bit processors.

Then you should specify a specific instruction set, preferably the one
that your compiler uses.
--
Mikko