Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.theory
Subject: Re: Simply defining =?utf-8?Q?G=C3=B6del?= Incompleteness and Tarski Undefinability away V47 (x86 really is Turing complete)
Date: Tue, 25 Aug 2020 17:07:18 -0700
Organization: None to speak of
Lines: 68
Message-ID: <87mu2i2rt5.fsf@nosuchdomain.example.com>
References: <fKqdnV-43axKybXCnZ2dnUU7-SPNnZ2d@giganews.com> <87d03h373i.fsf@bsb.me.uk> <nJ6dnQKhW7bh6d_CnZ2dnUU7-UXNnZ2d@giganews.com> <871rjx2wt3.fsf@bsb.me.uk> <qYadndgvRpvYB9_CnZ2dnUU7-evNnZ2d@giganews.com> <87k0xp12w4.fsf@bsb.me.uk> <ytSdnSIh9dV8ft_CnZ2dnUU7-NnNnZ2d@giganews.com> <87eenw27zx.fsf@bsb.me.uk> <vc2dnds0z8VU19nCnZ2dnUU7-THNnZ2d@giganews.com> <87364b1qxg.fsf@bsb.me.uk> <qvudnaHgEuEn-tnCnZ2dnUU7-bHNnZ2d@giganews.com> <87wo1nzc11.fsf@bsb.me.uk> <CJmdndC6gd8eu9jCnZ2dnUU7-cvNnZ2d@giganews.com> <87d03e4u4k.fsf@nosuchdomain.example.com> <OsednQWmsN2ZqtjCnZ2dnUU7-TnNnZ2d@giganews.com> <878se24ov3.fsf@nosuchdomain.example.com> <Z_SdnfTGPpIh0tjCnZ2dnUU7-dXNnZ2d@giganews.com> <874koq4j91.fsf@nosuchdomain.example.com> <I9CdnXEL7NLG9NjCnZ2dnUU7-VWdnZ2d@giganews.com> <877dtmz74a.fsf@bsb.me.uk> <IJ6dnf6_FvHUBdjCnZ2dnUU7-LfNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8c8d00f5ccd0214ff961c96eb77e80d3"; logging-data="13364"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+E5UGnYtWIt1ARfReYjuwQ"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
Cancel-Lock: sha1:bbhECCw8FS3udzLRB/X6pOW50ig= sha1:OyCW7/MlIa40SGO9K0mPUcGuwtA=
Xref: csiph.com comp.theory:22609

olcott <NoOne@NoWhere.com> writes:
> On 8/25/2020 5:35 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>> On 8/25/2020 2:29 PM, Keith Thompson wrote:
>> <cut>
>>>> A relative JMP is defined in terms of its effect on EIP, which is
>>>> specifed in that document as a 32-bit register.  This directly
>>>> contradicts your claim.
>> <cut>
>>> I have switched gears now.
>>> I have a much more effective approach.
>>>
>>> To make the abstract model of computation implied by RIP relative
>>> addressing code have Turing complete memory access for both code and
>>> data we merely fail to assume any specific size of the instruction
>>> pointer.
>>
>> Finally!  (Bravo Keith.)  You will never admit that this change of gears
>> means you were wrong, but at least there is now no need for you to keep
>> saying the same wrong thing over and over again.
>
> I was not wrong when I defined the line or demarcation between the
> abstract model and the physical implementation where I did.
>
> That you refuse to draw this line of demaracation where I specified
> does not make me wrong.

I never said that drawing the line where you did was wrong.  What you
were wrong about was your claim that your choice of where to draw the
line was forced by the "x86 language" that you never fully defined.

You defined (or tried to define) an abstract model based on the x86.
Nothing wrong with that.  You defined some aspects of the x86
definition as part of the abstraction and others as implementation
details.  Nothing wrong with that either.  But you insisted that the
specific line between abstraction and implementation details would
be obvious to anyone who read the references you cited -- when in
fact those references made it clear that the instruction pointer
has a fixed width of no more than 64 bits, and that jumping to an
address exceeding 2**64 could not make sense given the published
x86 specifications.

It's great that you're no longer making that claim, but I'm annoyed
that I spent so much time and effort arguing with you about it,
you've effectively changed your argument to be consistent with what
I've been saying, and you pretend that that never happened.

>> Now, what was it you had when falsely claimed to have Linz's H and H^?
>> That's the only interesting part of this whole sorry mess -- your claim
>> to have something impossible.  That unbounded register machines are
>> Turing complete, unlike the x86, is just computability 101, despite it
>> taking you weeks to get there.
>
> A lie requires an intentional falsehood. Human communication generally
> allows some subjective leeway of interpretation.  I have always
> construed everything computationally identical to a Turing machine as
> one-and-the-same thing as a Turing Machine. That you do not define it
> this way does not make me a liar.
>
> Now that I have provided a way to directly map the "C" programming
> language to an abstract model of computation that is Turing complete
> there is a direct bridge to show that programs specified in the "C"
> programming language specify Turing complete virtual machines.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */