Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

The value of a program is proportional to the weight of its output.


programming / comp.lang.asm.x86 / Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)

SubjectAuthor
* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinolcott
`* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinwolfgang kern
 `* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinolcott
  +* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinFrank Kotler
  |+* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinTerje Mathisen
  ||`* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinFrank Kotler
  || `- Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinolcott
  |+- Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinolcott
  |`* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinJames Harris
  | `* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinKerr-Mudd,John
  |  +* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)olcott
  |  |`* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)Terje Mathisen
  |  | `* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)olcott
  |  |  `* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)wolfgang kern
  |  |   `- Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)Frank Kotler
  |  `* Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen} HPFrank Kotler
  |   +- Re: Moderation issues - was Re: Refuting the {Linz, Sipser andRod Pemberton
  |   +- Re: Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen}James Harris
  |   `* Re: Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen}Robert Prins
  |    `* Re: Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen}Terje Mathisen
  |     `- Re: Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen}Frank Kotler
  `* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinBernhard Schornak
   `* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinolcott
    `* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinRobert
     `* Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinolcott
      `- Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders withinBernhard Schornak

Pages:12
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.lang.asm.x86
Organization: A noiseless patient Spider
Date: Mon, 14 Dec 2020 21:56 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: NoO...@nospicedham.NoWhere.com (olcott)
Newsgroups: comp.theory,comp.ai.philosophy,comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Date: Mon, 14 Dec 2020 15:56:55 -0600
Organization: A noiseless patient Spider
Lines: 347
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr2j08$4ur$1@dont-email.me> <0KadnafWuKP6f0nCnZ2dnUU7-IPNnZ2d@giganews.com>
<rr2oq2$ao3$1@dont-email.me> <35OdnezHsPxac0nCnZ2dnUU7-YvNnZ2d@giganews.com>
<rr2tlk$c32$1@dont-email.me> <zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com>
<rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="7f19e0d1116082fd360d82ac1fedadb4";
logging-data="28288"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+G1G05Vd9k4rkQ5B6nAWyjY8bp83+m4qg="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
Cancel-Lock: sha1:TaFvV8RB28V3YgqOz97nFSADf6E=
View all headers
On 12/14/2020 2:02 PM, Kaz Kylheku wrote:
On 2020-12-14, olcott <NoOne@NoWhere.com> wrote:
On 12/14/2020 9:32 AM, Malcolm McLean wrote:
On Monday, 14 December 2020 at 15:16:13 UTC, olcott wrote:
On 12/14/2020 8:48 AM, André G. Isaak wrote:
On 2020-12-14 07:25, olcott wrote:
On 12/12/2020 2:37 PM, André G. Isaak wrote:
On 2020-12-12 13:01, olcott wrote:
On 12/12/2020 1:40 PM, André G. Isaak wrote:
On 2020-12-12 12:25, olcott wrote:
On 12/12/2020 1:13 PM, André G. Isaak wrote:
On 2020-12-12 12:08, olcott wrote:
On 12/12/2020 1:00 PM, André G. Isaak wrote:
On 2020-12-12 11:26, olcott wrote:
On 12/12/2020 12:08 PM, André G. Isaak wrote:
On 2020-12-12 10:45, olcott wrote:
On 12/12/2020 11:40 AM, André G. Isaak wrote:
On 2020-12-12 10:38, olcott wrote:
On 12/12/2020 11:12 AM, André G. Isaak wrote:
On 2020-12-12 09:24, olcott wrote:

<snip>

The outermost Halts() always returns a value to its
caller even though it must sometimes abort the
simulations of inner infinite invocations of itself.

And since it claims to be simulating those inner
instances and to abort those instances only in cases
where they would not otherwise halt, it is asserting that
there *are* inputs to Halts() which will not halt. Ergo,
it is asserting that Halts() is *not* a decider.

...in those cases where it does not halt and return a
value to its caller Halts() is not a decider. On those
invocations of Halts() where it does halt and return a
value to its caller it is a decider.

A program is either a decider or it isn't. There's no such
thing as a program which is sometimes a decider and
sometimes isn't.

André


You already know that is pure bullshit or the term "partial
decider" would not exist. What motive do you have for saying
things that you know are pure bullshit?

A partial decider is not a decider. More importantly, it is
not a "sometimes decider".

A partial decider makes a correct decision for a particular
class of inputs but may fail to halt for other inputs.


Your program sometimes halts and sometimes doesn't for the
*same* inputs. So you cannot even claim your program is a
partial decider, let alone an actual decider.

André


So in other words you "believe" against logic that some
infinitely recursive invocations <do> return a result to their
caller. That sounds nutty to me.

How you can possibly get that idea from what I wrote is utterly
beyond me.

I am saying that anything which has the possibility of getting
caught in infinite recursion cannot return a result and
therefore cannot constitute a decider.

André



Except in those cases that it has not been caught in infinite
recursion and does return a result to its caller.

Alternatively a function that can and does correctly detect
infinite recursion on itself and return its decision to its
caller does not count.

Basically you are saying that it is wrong all of the time even
though it is right some of the time.

No. I am saying that it is not a decider. A decider *must* return
a result for *all* inputs. That's the definition of 'decider'.
Something that only returns results in some instances is not a
decider. I don't know how I can make this any clearer...

André


The way that you are defining it when a function does correctly
decide that it has been infinitely invoked that even though this
decision is correct it does not count.

Since a partial decider <is> a decider for some inputs and not for
other inputs, then this same idea can be extended to some
invocations and not all invocations, otherwise correctly deciding
infinite recursion does not count even when the decision is correct.

A partial decider is not a decider any more than a half-dollar is a
dollar. A partial decider is something that correctly decides some
cases, not something which is a decider in some cases. Things are
either deciders or they aren't.

A partial decider that decides the {Linz, Sipser, Kozen}
counter-examples refutes these three proofs.

That a program correctly decides some cases does not make it a
decider in those cases. You could call it a partial decider, but
not a decider.

However, in the case of your program, you can't even call it that
because it sometimes returns and other times does not return *on
the same input*. A partial decider is something which decides some
set of inputs and fails to decide another, *disjoint* set of
inputs. Something which gets different results for the same input
isn't even a function, let alone a decider or partial decider.

André


So in other words when a partial decider correctly determines that
it has been invoked in infinite recursion it must fix the bug in
this infinitely recursive invocation so that it can report its
infinitely recursive invocation to its infinitely recursive caller,
that is no longer infinitely recursive because it fixed this bug.

<sarcasm>
That makes perfect sense to me.
</sarcasm>

No, I did not say that. You need to make at least some effort to read
for comprehension. I said that something which can be caught in
infinite recursion is *not* a decider. This is getting rather
tedious. Something that correctly decides some cases but not others
could be a partial decider, but not if it decides the *same* input in
some cases but not others.


01 void H_Hat(u32 P)
02 {
03 u32 Input_Halts = DebugTrace(P, P);
04 if (Input_Halts)
05 HERE: goto HERE;
06 else
07 HALT
08 }

Halts((u32)H_Hat,(u32)H_Hat) is correctly decided** as not halting
because it aborts the invocation of itself on line 03.

You've switched back from using Halts() to using DebugTrace(). Are these
intended to be distinct functions?

** Halts returns the correct halting determination.

According to your way of defining a decider:
(a) Halts is not a decider even though it correctly decides.
(b) Halts would be a decider if it aborted the infinite recursion of
any other function besides itself.

That is ridiculous!
Look, a decider is a type of *function*. To be a function, something
must consistently map the same input to the same result, but that isn't
what you get above. Assuming that your DebugTrace() and Halts() are
intended to be the same, you are claiming that

Halts(H_Hat, H_Hat)

returns false. This means Halts(H_Hat, H_Hat) is a finite computation.

But by returning false is is also claiming that the instance of
Halts(H_Hat, H_Hat) invoked from within H_Hat must be aborted as a
non-halting function.

This is a contradiction.
As I have said very many times (no one notices because they only glance
at a few of my words to contrive some lame basis for a rebuttal that
would fool the gullible):

Halts(H_Hat, H_Hat) is only a finite computation because it aborts the
otherwise infinite recursion of its input according to this criteria:

On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
A computation that would not halt if its simulation were not
halted is indeed a non-halting computation.

If Halts aborts itself, is it halted or aborted? That's the question.


Halts() simulates H_Hat() that invokes Halts() in infinite recursion.
Halts() stops simulating H_Hat() including its infinite recursive
invocation of Halts(), returning its non-halting decision to main()
where it is output.

If we say "halted" then H_Hat inverts whatever result it returns,

It is not possible for an aborted function to invert any damn thing.

and :Halts" is wrong. If we say "aborted" then "Halts" isn't a function,
which is a slightly more subtle requirement of H_Hat.

Certainly an at least partial halt decider that bases its halting
decision by looking for patterns of behavior of its inputs can stop
simulating this input as soon as it detects any non-halting pattern.

It does not make any damn difference if it detects an infinite loop, or
infinite recursion. It also does not make any damn difference which
function is involved in infinite recursion. As long as Halts() detects
the non-halting behavior of its input then it can stop simulating this
input and report non-halting.

void H_Hat(u32 P)
{
    u32 Input_Halts = Halts(P, P);
    if (Input_Halts)
      HERE: goto HERE;
    else
      HALT
}


int main()
{
    u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
    Output("[Input_Would_Halt] =", Input_Would_Halt);
    HALT;
}

I finally renamed my internal DebugTrace() to Halts() now that it
finally does return its correct halting decision to main().

Your techique is suspicious, because you're transcribing the pseudo-code
from the usual halting proofs into the higher level C language, but then
are messing with the execution at a lower level. The mapping between the
C language and abstract concepts like "pure function of certain
arguments" only depends on certain conventions being upheld in the
machine language translation, and the expected execution model for which
the translation is made.


At the TM level is is merely the execution of a TM on a finite string, in this case the TM a a halt decider based on a UTM.

It is not the details of the C/x86 implementation that are important it is whether or not the architecture of the C/x86 implementation maps to a TM solution.

Click here to read the complete article
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: wolfgang kern
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Tue, 15 Dec 2020 09:05 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: nowh...@nospicedham.never.at (wolfgang kern)
Newsgroups: comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Date: Tue, 15 Dec 2020 10:05:21 +0100
Organization: Aioe.org NNTP Server
Lines: 9
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rr9uag$1j0n$1@gioia.aioe.org>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<0KadnafWuKP6f0nCnZ2dnUU7-IPNnZ2d@giganews.com> <rr2oq2$ao3$1@dont-email.me>
<35OdnezHsPxac0nCnZ2dnUU7-YvNnZ2d@giganews.com> <rr2tlk$c32$1@dont-email.me>
<zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com> <rr2vb1$mhs$1@dont-email.me>
<SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com> <rr30u4$2ba$1@dont-email.me>
<BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com> <rr340r$l9i$1@dont-email.me>
<bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com> <rr34ok$rof$1@dont-email.me>
<oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com> <rr36c2$7dk$1@dont-email.me>
<-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com> <rr39me$tev$1@dont-email.me>
<IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com> <rr7tvl$h7a$1@dont-email.me>
<DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="76487f5ea975e63f3b6b677cdab64cef";
logging-data="13785"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/R1FkoZmpzfeyMGc4iQOU9ufjzqJM4b3M="
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
Thunderbird/68.0
Cancel-Lock: sha1:WiCBBp/xiyRv0mtGAR8efDPGByg=
View all headers
removed theory etc.

On 14.12.2020 22:56, olcott wrote and cyted:

A LOT of useless HLL lines.
please don't bother us here with this, it's an assembler group.
__
wolfgang



Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: olcott
Newsgroups: comp.lang.asm.x86
Organization: A noiseless patient Spider
Date: Thu, 17 Dec 2020 01:40 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: NoO...@nospicedham.NoWhere.com (olcott)
Newsgroups: comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Date: Wed, 16 Dec 2020 19:40:50 -0600
Organization: A noiseless patient Spider
Lines: 198
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr2oq2$ao3$1@dont-email.me> <35OdnezHsPxac0nCnZ2dnUU7-YvNnZ2d@giganews.com>
<rr2tlk$c32$1@dont-email.me> <zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com>
<rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="4a23faa1200c6b29da9d0c80fbd9723f";
logging-data="6814"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+yBajPmD3YWPzl1odPtC+EoO1zLbNkh+s="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
Cancel-Lock: sha1:irpPWYWAJvJ5LRFkpHtBTgw9His=
View all headers
On 12/15/2020 3:05 AM, wolfgang kern wrote:
removed theory etc.

On 14.12.2020 22:56, olcott wrote and cyted:

A LOT of useless HLL lines.
please don't bother us here with this, it's an assembler group.
__
wolfgang


That last message was sent by mistake.

This is the only one that might be relevant to this group:
I refuted the halting problem proofs by building a universal Turing machine that has the x86 language as its machine description language.
The key aspect of this proof is the x86 execution trace at the bottom of this message.

If you have a good understanding of:
(a) software engineering,
(b) The C programming language
(c) The x86 programming language

You will be able to easily verify that Halts() does correctly decide the halt status of H_Hat().

The x86utm operating system provides the operating environment to execute virtual machines computationally equivalent to universal Turing machines having the x86 language as their machine description language. x86utm executes the COFF object file output of the Microsoft C compiler. The x86utm operating system is based on a world class x86 emulator that has been developed and tested for decades.

x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
It is common knowledge that all x86 based programs are computationally equivalent to UTMs for every computation that does not require more memory than they have.

This is the generic halt deciding criteria:
On Saturday, November 28, 2020 at 2:00:28 PM UTC-8, olcott wrote:
 > Every computation that would not halt if its simulation
 > were not halted is by logical necessity a non-halting computation.

We can verify that the following execution trace of the computational equivalent of:
(a) {Peter Linz: H, Michael Sipser: H, Dexter Kozen: K}
       Correctly decides halting on the the computational equivalent of:
(b) {Peter Linz: Ĥ, Michael Sipser: D, Dexter Kozen: N}

The following execution trace can be verified as correctly deciding the halting status of its input with only these three prerequisites and nothing more:

(a) An elementary understanding of software engineering, such things as: (a) infinite loops do not have a fixed number of iterations and (b) infinitely recursive invocations never return any value to their caller.

(b) A basic understanding of how the C programming language maps to x86 instructions. This is used to verify that the translations of the "C" functions into their x86 equivalents are correct. It is also used to verifiy that the execution trace of these x86 functions is correct.

(c) An understanding of one very elementary infinite recursion detection algorithm: Whenever an execution trace shows a second call to the same function from the same machine address with no control flow instructions in-between this second invocation is always an instance of infinite recursion. From this it is very easy to see that the halt decider did apply this simple criteria in its halt deciding decision, thus meeting he generic criteria shown above.

Actual debug trace of Halts() deciding halting on H_Hat()

#define HALT __asm hlt

void H_Hat(u32 P)
{
   u32 Input_Halts = Halts(P, P);
   if (Input_Halts)
     HERE: goto HERE;
   else
     HALT
}

int main()
{
   u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
   Output_Debug_Trace();
   Output("Input_Would_Halt =", Input_Would_Halt);
   HALT;
}

_H_Hat()
[000005e6](01)  55                  push ebp
[000005e7](02)  8bec                mov ebp,esp
[000005e9](01)  51                  push ecx
[000005ea](03)  8b4508              mov eax,[ebp+08]
[000005ed](01)  50                  push eax
[000005ee](03)  8b4d08              mov ecx,[ebp+08]
[000005f1](01)  51                  push ecx
[000005f2](05)  e8effdffff          call 000003e6
[000005f7](03)  83c408              add esp,+08
[000005fa](03)  8945fc              mov [ebp-04],eax
[000005fd](04)  837dfc00            cmp dword [ebp-04],+00
[00000601](02)  7404                jz 00000607
[00000603](02)  ebfe                jmp 00000603
[00000605](02)  eb01                jmp 00000608
[00000607](01)  f4                  hlt
[00000608](02)  8be5                mov esp,ebp
[0000060a](01)  5d                  pop ebp
[0000060b](01)  c3                  ret

_main()
[00000616](01)  55                  push ebp
[00000617](02)  8bec                mov ebp,esp
[00000619](01)  51                  push ecx
[0000061a](05)  68e6050000          push 000005e6
[0000061f](05)  68e6050000          push 000005e6
[00000624](05)  e8bdfdffff          call 000003e6
[00000629](03)  83c408              add esp,+08
[0000062c](03)  8945fc              mov [ebp-04],eax
[0000062f](05)  e8f2fcffff          call 00000326
[00000634](03)  8b45fc              mov eax,[ebp-04]
[00000637](01)  50                  push eax
[00000638](05)  68a3020000          push 000002a3
[0000063d](05)  e894fcffff          call 000002d6
[00000642](03)  83c408              add esp,+08
[00000645](01)  f4                  hlt
[00000646](02)  8be5                mov esp,ebp
[00000648](01)  5d                  pop ebp
[00000649](01)  c3                  ret

Output_Debug_Trace() Trace_List.size(24)
---[00000616](01)  55                  push ebp
---[00000617](02)  8bec                mov ebp,esp
---[00000619](01)  51                  push ecx
---[0000061a](05)  68e6050000          push 000005e6
---[0000061f](05)  68e6050000          push 000005e6
---[00000624](05)  e8bdfdffff          call 000003e6       --CALL [000003e6]
---[000005e6](01)  55                  push ebp
---[000005e7](02)  8bec                mov ebp,esp
---[000005e9](01)  51                  push ecx
---[000005ea](03)  8b4508              mov eax,[ebp+08]
---[000005ed](01)  50                  push eax
---[000005ee](03)  8b4d08              mov ecx,[ebp+08]
---[000005f1](01)  51                  push ecx
---[000005f2](05)  e8effdffff          call 000003e6       --CALL [000003e6]
---[000005e6](01)  55                  push ebp
---[000005e7](02)  8bec                mov ebp,esp
---[000005e9](01)  51                  push ecx
---[000005ea](03)  8b4508              mov eax,[ebp+08]
---[000005ed](01)  50                  push eax
---[000005ee](03)  8b4d08              mov ecx,[ebp+08]
---[000005f1](01)  51                  push ecx
---[000005f2](05)  e8effdffff          call 000003e6       --CALL [000003e6]
Input Aborted because of INFINITE RECURSION from [000005f2] to [000003e6]
---[00000629](03)  83c408              add esp,+08
---[0000062c](03)  8945fc              mov [ebp-04],eax
===[0000062f](05)  e8f2fcffff          call 00000326
.....[00000634](03)  8b45fc              mov eax,[ebp-04]
.....[00000637](01)  50                  push eax
.....[00000638](05)  68a3020000          push 000002a3

Click here to read the complete article
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: Frank Kotler
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Thu, 17 Dec 2020 06:41 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: fbkot...@nospicedham.myfairpoint.net (Frank Kotler)
Newsgroups: comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Date: Thu, 17 Dec 2020 01:41:50 -0500
Organization: Aioe.org NNTP Server
Lines: 40
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rreusc$2jp$1@gioia.aioe.org>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<35OdnezHsPxac0nCnZ2dnUU7-YvNnZ2d@giganews.com> <rr2tlk$c32$1@dont-email.me>
<zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com> <rr2vb1$mhs$1@dont-email.me>
<SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com> <rr30u4$2ba$1@dont-email.me>
<BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com> <rr340r$l9i$1@dont-email.me>
<bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com> <rr34ok$rof$1@dont-email.me>
<oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com> <rr36c2$7dk$1@dont-email.me>
<-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com> <rr39me$tev$1@dont-email.me>
<IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com> <rr7tvl$h7a$1@dont-email.me>
<DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="4a23faa1200c6b29da9d0c80fbd9723f";
logging-data="11668"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ev9/1Oy5vnFsPnEZsaqGhqYynUnWBS6k="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.5.2
Cancel-Lock: sha1:w5dBAc4IPa0eCXbaDuujpdkDDKw=
View all headers
On 12/16/2020 08:40 PM, olcott wrote:
On 12/15/2020 3:05 AM, wolfgang kern wrote:
removed theory etc.

On 14.12.2020 22:56, olcott wrote and cyted:

A LOT of useless HLL lines.
please don't bother us here with this, it's an assembler group.
__
wolfgang


That last message was sent by mistake.

This is the only one that might be relevant to this group:

Hi Pete,

As moderator of this newsgroup, I am very reluctant to reject your messages just because I'm not interested (but I'm not). Woifgang's message makes me think I'm not the only one...

Could I ask you to not post on this topic here?

Could I ask Wolfgang (and others) to simply ignore messages you don't like? It only takes you a second to click "next".

There's an "issue" here. If clax86 is on the lost of newsgroups, it comes to my attention. If I reject it - NONE of the messages get posted! If it were up to me, it wouldn't work this way, but it isn't.

So I think we'll all be happier if clax86 is off your list

I'm sorry this is a problem.

Best,
Frank
moderator
fbkkotler@myfairpoint.net



Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: Terje Mathisen
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Thu, 17 Dec 2020 11:48 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: terje.ma...@nospicedham.tmsw.no (Terje Mathisen)
Newsgroups: comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Date: Thu, 17 Dec 2020 12:48:36 +0100
Organization: Aioe.org NNTP Server
Lines: 47
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <0382c4cb-991d-9dfe-08ab-0c2d5ec5134a@tmsw.no>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr2tlk$c32$1@dont-email.me> <zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com>
<rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="4a23faa1200c6b29da9d0c80fbd9723f";
logging-data="22114"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/piJiKlFfUUmYWwzZgsnfLtlvOiOSbiOE="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.5.1
Cancel-Lock: sha1:6u9NEaEHuSB0K4oMtgLS6HFk0gg=
View all headers
Frank Kotler wrote:
On 12/16/2020 08:40 PM, olcott wrote:
On 12/15/2020 3:05 AM, wolfgang kern wrote:
removed theory etc.

On 14.12.2020 22:56, olcott wrote and cyted:

A LOT of useless HLL lines.
please don't bother us here with this, it's an assembler group.
__
wolfgang


That last message was sent by mistake.

This is the only one that might be relevant to this group:

Hi Pete,

As moderator of this newsgroup, I am very reluctant to reject your messages just because I'm not interested (but I'm not). Woifgang's message makes me think I'm not the only one...

Could I ask you to not post on this topic here?

Could I ask Wolfgang (and others) to simply ignore messages you don't like? It only takes you a second to click "next".

There's an "issue" here. If clax86 is on the lost of newsgroups, it comes to my attention. If I reject it - NONE of the messages get posted! If it were up to me, it wouldn't work this way, but it isn't.

So I think we'll all be happier if clax86 is off your list

I'm sorry this is a problem.

This is a _big_ problem imho, you Frank have been a lot more patient that I would have been, I would have at a minimum grey-listed olcott, i.e. only manually forwarded any messages that were clearly relevant to clax.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: olcott
Newsgroups: comp.lang.asm.x86
Organization: A noiseless patient Spider
Date: Thu, 17 Dec 2020 14:07 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: NoO...@nospicedham.NoWhere.com (olcott)
Newsgroups: comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Date: Thu, 17 Dec 2020 08:07:59 -0600
Organization: A noiseless patient Spider
Lines: 54
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <z5mdncsMZ66i-0bCnZ2dnUU7-IXNnZ2d@giganews.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr2tlk$c32$1@dont-email.me> <zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com>
<rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="4a23faa1200c6b29da9d0c80fbd9723f";
logging-data="4323"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/LDcZVisGO5GosdZlJBq6oakCIusW+vv8="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
Cancel-Lock: sha1:lgltyHJg+p7R+dniFqbZGqlB9os=
View all headers
On 12/17/2020 12:41 AM, Frank Kotler wrote:
On 12/16/2020 08:40 PM, olcott wrote:
On 12/15/2020 3:05 AM, wolfgang kern wrote:
removed theory etc.

On 14.12.2020 22:56, olcott wrote and cyted:

A LOT of useless HLL lines.
please don't bother us here with this, it's an assembler group.
__
wolfgang


That last message was sent by mistake.

This is the only one that might be relevant to this group:

Hi Pete,

As moderator of this newsgroup, I am very reluctant to reject your messages just because I'm not interested (but I'm not). Woifgang's message makes me think I'm not the only one...

Could I ask you to not post on this topic here?

Could I ask Wolfgang (and others) to simply ignore messages you don't like? It only takes you a second to click "next".

There's an "issue" here. If clax86 is on the lost of newsgroups, it comes to my attention. If I reject it - NONE of the messages get posted! If it were up to me, it wouldn't work this way, but it isn't.

So I think we'll all be happier if clax86 is off your list

I'm sorry this is a problem.

Best,
Frank
moderator
fbkkotler@myfairpoint.net

One of my messages accidentally got cross-posted to this group.
Everytime that I reply to this message it gets cross-posted again.
I will try and find it and remove the cross-post link.

The people on comp.theory don't understand the x86 language well enough to understand that my infinite recursion detection algorithm is correct.

--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein



Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: Frank Kotler
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Thu, 17 Dec 2020 22:17 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: fbkot...@nospicedham.myfairpoint.net (Frank Kotler)
Newsgroups: comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Date: Thu, 17 Dec 2020 17:17:17 -0500
Organization: Aioe.org NNTP Server
Lines: 16
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rrglm3$1rb8$1@gioia.aioe.org>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com> <rr2vb1$mhs$1@dont-email.me>
<SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com> <rr30u4$2ba$1@dont-email.me>
<BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com> <rr340r$l9i$1@dont-email.me>
<bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com> <rr34ok$rof$1@dont-email.me>
<oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com> <rr36c2$7dk$1@dont-email.me>
<-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com> <rr39me$tev$1@dont-email.me>
<IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com> <rr7tvl$h7a$1@dont-email.me>
<DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
<0382c4cb-991d-9dfe-08ab-0c2d5ec5134a@tmsw.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="9cbbec290d64abf99a35b871ef40dc10";
logging-data="2034"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/kLVV98AbXk1mZOjLRYKfBe0xtX7KA4t8="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.5.2
Cancel-Lock: sha1:0dtZZ/8TAOdbv89pWyCVGr1qrwA=
View all headers
On 12/17/2020 06:48 AM, Terje Mathisen wrote:

This is a _big_ problem imho, you Frank have been a lot more patient that I would have been, I would have at a minimum grey-listed olcott, i.e. only manually forwarded any messages that were clearly relevant to clax.

Terje


Sorry. I hope it is solved.

Best,
Frank




Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: olcott
Newsgroups: comp.lang.asm.x86
Organization: A noiseless patient Spider
Date: Thu, 17 Dec 2020 23:19 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: NoO...@nospicedham.NoWhere.com (olcott)
Newsgroups: comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Date: Thu, 17 Dec 2020 17:19:59 -0600
Organization: A noiseless patient Spider
Lines: 28
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <XbSdnQxd2N8CekbCnZ2dnUU7-c2dnZ2d@giganews.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
<0382c4cb-991d-9dfe-08ab-0c2d5ec5134a@tmsw.no> <rrglm3$1rb8$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="fca2fdec84556fd965ff78ab8704ac53";
logging-data="26280"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+NCcluHMXMAouxXBymeZHIdxBc3p9ngV8="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.1
Cancel-Lock: sha1:HbuhoSr8eLANZE3aOaG3XPzc3nQ=
View all headers
On 12/17/2020 4:17 PM, Frank Kotler wrote:
On 12/17/2020 06:48 AM, Terje Mathisen wrote:

This is a _big_ problem imho, you Frank have been a lot more patient that I would have been, I would have at a minimum grey-listed olcott, i.e. only manually forwarded any messages that were clearly relevant to clax.

Terje


Sorry. I hope it is solved.

Best,
Frank



I initially accidentally added this group to the cross-post list because I am unable to wear my glasses for a few weeks. I try to always post to comp.theory and two other groups.

--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein



Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: James Harris
Newsgroups: comp.lang.asm.x86
Organization: A noiseless patient Spider
Date: Sat, 19 Dec 2020 11:57 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: james.ha...@nospicedham.gmail.com (James Harris)
Newsgroups: comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Date: Sat, 19 Dec 2020 11:57:28 +0000
Organization: A noiseless patient Spider
Lines: 31
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rrkpr9$svo$1@dont-email.me>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr2tlk$c32$1@dont-email.me> <zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com>
<rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="30e571bc39cd694ee7d2153651e3699f";
logging-data="391"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ZbyTjBluYiJRXySylyam7fSg/KE00YwY="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:7dtisD7m0Y66E1v2x3QGBf4olTM=
View all headers
On 17/12/2020 06:41, Frank Kotler wrote:

....

Hi Pete,

As moderator of this newsgroup, I am very reluctant to reject your messages just because I'm not interested (but I'm not). Woifgang's message makes me think I'm not the only one...

Could I ask you to not post on this topic here?

Could I ask Wolfgang (and others) to simply ignore messages you don't like? It only takes you a second to click "next".

There's an "issue" here. If clax86 is on the lost of newsgroups, it comes to my attention. If I reject it - NONE of the messages get posted! If it were up to me, it wouldn't work this way, but it isn't.

Thanks for what you are doing, Frank. IIRC you are the only one who took up the challenge of moderating this group and what you do for us is appreciated.

At the risk of continuing a thread that is already off the topic of x86 asm I wonder if there's not some way the rest of us could make the job of the moderator easier. Maybe that's something we should discuss.


--
James Harris



Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: Kerr-Mudd,John
Newsgroups: comp.lang.asm.x86
Organization: dis
Date: Sat, 19 Dec 2020 12:22 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: notsay...@nospicedham.127.0.0.1 (Kerr-Mudd,John)
Newsgroups: comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Date: Sat, 19 Dec 2020 12:22:24 -0000 (UTC)
Organization: dis
Lines: 37
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <XnsAC987DDE86887admin127001@144.76.35.252>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com> <zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com> <rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com> <rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com> <rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com> <rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com> <rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com> <rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com> <rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com> <7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com> <NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com> <20201214113311.509@kylheku.com> <kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com> <rr9uag$1j0n$1@gioia.aioe.org> <U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org> <rrkpr9$svo$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="30e571bc39cd694ee7d2153651e3699f";
logging-data="12458"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19b0N9jmFSXwG2ccisPO9IEH6Tu0zoXLOs="
User-Agent: Xnews/2009.05.01
Cancel-Lock: sha1:tjE9xPPU7PJP7+gilcZmAqdbsVU=
View all headers
On Sat, 19 Dec 2020 11:57:28 GMT, James Harris
<james.harris.1@nospicedham.gmail.com> wrote:

On 17/12/2020 06:41, Frank Kotler wrote:

...

Hi Pete,

As moderator of this newsgroup, I am very reluctant to reject your
messages just because I'm not interested (but I'm not). Woifgang's
message makes me think I'm not the only one...

Could I ask you to not post on this topic here?

Could I ask Wolfgang (and others) to simply ignore messages you don't
like? It only takes you a second to click "next".

Sounds a sensible approach.

There's an "issue" here. If clax86 is on the lost of newsgroups, it
comes to my attention. If I reject it - NONE of the messages get
posted! If it were up to me, it wouldn't work this way, but it isn't.

Thanks for what you are doing, Frank. IIRC you are the only one who
took up the challenge of moderating this group and what you do for us
is appreciated.

At the risk of continuing a thread that is already off the topic of
x86 asm I wonder if there's not some way the rest of us could make the
job of the moderator easier. Maybe that's something we should discuss.

Is there any need for moderating? Just ignore any religious posts.

--
Bah, and indeed, Humbug.



Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)
From: olcott
Newsgroups: comp.lang.asm.x86, comp.theory
Organization: A noiseless patient Spider
Date: Sat, 19 Dec 2020 19:46 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: NoO...@nospicedham.NoWhere.com (olcott)
Newsgroups: comp.lang.asm.x86,comp.theory
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)
Date: Sat, 19 Dec 2020 13:46:23 -0600
Organization: A noiseless patient Spider
Lines: 72
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <avudnSgIa8QSxUPCnZ2dnUU7-TvNnZ2d@giganews.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
<rrkpr9$svo$1@dont-email.me> <XnsAC987DDE86887admin127001@144.76.35.252>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="30e571bc39cd694ee7d2153651e3699f";
logging-data="2632"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+tXLe2Ji/cEgpuGyjl79hxMMTCuEASJds="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
Cancel-Lock: sha1:53E27cImI1RuvMdBwYFmulBkXE0=
View all headers
On 12/19/2020 6:22 AM, Kerr-Mudd,John wrote:
On Sat, 19 Dec 2020 11:57:28 GMT, James Harris
<james.harris.1@nospicedham.gmail.com> wrote:

On 17/12/2020 06:41, Frank Kotler wrote:

...

Hi Pete,

As moderator of this newsgroup, I am very reluctant to reject your
messages just because I'm not interested (but I'm not). Woifgang's
message makes me think I'm not the only one...

Could I ask you to not post on this topic here?

Could I ask Wolfgang (and others) to simply ignore messages you don't
like? It only takes you a second to click "next".

Sounds a sensible approach.

There's an "issue" here. If clax86 is on the lost of newsgroups, it
comes to my attention. If I reject it - NONE of the messages get
posted! If it were up to me, it wouldn't work this way, but it isn't.

Thanks for what you are doing, Frank. IIRC you are the only one who
took up the challenge of moderating this group and what you do for us
is appreciated.

At the risk of continuing a thread that is already off the topic of
x86 asm I wonder if there's not some way the rest of us could make the
job of the moderator easier. Maybe that's something we should discuss.

Is there any need for moderating? Just ignore any religious posts.


My post was not totally off-topic because the most important part of this post is examining the semantic meaning of the execution trace of this sequence of x86 instructions:

---[000005e6](01)  55                  push ebp
---[000005e7](02)  8bec                mov ebp,esp
---[000005e9](01)  51                  push ecx
---[000005ea](03)  8b4508              mov eax,[ebp+08]
---[000005ed](01)  50                  push eax
---[000005ee](03)  8b4d08              mov ecx,[ebp+08]
---[000005f1](01)  51                  push ecx
---[000005f2](05)  e8effdffff          call 000003e6   --CALL [000003e6]
---[000005e6](01)  55                  push ebp
---[000005e7](02)  8bec                mov ebp,esp
---[000005e9](01)  51                  push ecx
---[000005ea](03)  8b4508              mov eax,[ebp+08]
---[000005ed](01)  50                  push eax
---[000005ee](03)  8b4d08              mov ecx,[ebp+08]
---[000005f1](01)  51                  push ecx
---[000005f2](05)  e8effdffff          call 000003e6   --CALL [000003e6]
Input Aborted because of INFINITE RECURSION from [000005f2] to [000003e6]

Every time that the same function is called from the same machine address a second time without any control flow instructions in-between (within an execution trace) is a case of infinite recursion. This is shown at execution trace lines 1-16 above.

People on other groups do not know the x86 language well enough to understand that this execution trace does specify infinite recursion.

--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein



Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)
From: Terje Mathisen
Newsgroups: comp.lang.asm.x86, comp.theory
Organization: Aioe.org NNTP Server
Date: Sat, 19 Dec 2020 21:18 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: terje.ma...@nospicedham.tmsw.no (Terje Mathisen)
Newsgroups: comp.lang.asm.x86,comp.theory
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)
Date: Sat, 19 Dec 2020 22:18:11 +0100
Organization: Aioe.org NNTP Server
Lines: 96
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rrlqmc$1pus$1@gioia.aioe.org>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com> <rr30u4$2ba$1@dont-email.me>
<BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com> <rr340r$l9i$1@dont-email.me>
<bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com> <rr34ok$rof$1@dont-email.me>
<oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com> <rr36c2$7dk$1@dont-email.me>
<-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com> <rr39me$tev$1@dont-email.me>
<IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com> <rr7tvl$h7a$1@dont-email.me>
<DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
<rrkpr9$svo$1@dont-email.me> <XnsAC987DDE86887admin127001@144.76.35.252>
<avudnSgIa8QSxUPCnZ2dnUU7-TvNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="30e571bc39cd694ee7d2153651e3699f";
logging-data="23404"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18yGMaAB74i5ZPQ0+nf02Axq3uBmITUh+Q="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.5.1
Cancel-Lock: sha1:1m99g0dF8V5MKwYNCr1f9ekTW2g=
View all headers
olcott wrote:
On 12/19/2020 6:22 AM, Kerr-Mudd,John wrote:
On Sat, 19 Dec 2020 11:57:28 GMT, James Harris
<james.harris.1@nospicedham.gmail.com> wrote:

On 17/12/2020 06:41, Frank Kotler wrote:

...

Hi Pete,

As moderator of this newsgroup, I am very reluctant to reject your
messages just because I'm not interested (but I'm not). Woifgang's
message makes me think I'm not the only one...

Could I ask you to not post on this topic here?

Could I ask Wolfgang (and others) to simply ignore messages you don't
like? It only takes you a second to click "next".

Sounds a sensible approach.

There's an "issue" here. If clax86 is on the lost of newsgroups, it
comes to my attention. If I reject it - NONE of the messages get
posted! If it were up to me, it wouldn't work this way, but it isn't.

Thanks for what you are doing, Frank. IIRC you are the only one who
took up the challenge of moderating this group and what you do for us
is appreciated.

At the risk of continuing a thread that is already off the topic of
x86 asm I wonder if there's not some way the rest of us could make the
job of the moderator easier. Maybe that's something we should discuss.

Is there any need for moderating? Just ignore any religious posts.


My post was not totally off-topic because the most important part of this post is examining the semantic meaning of the execution trace of this sequence of x86 instructions:

---[000005e6](01)  55                  push ebp
---[000005e7](02)  8bec                mov ebp,esp
---[000005e9](01)  51                  push ecx
---[000005ea](03)  8b4508              mov eax,[ebp+08]
---[000005ed](01)  50                  push eax
---[000005ee](03)  8b4d08              mov ecx,[ebp+08]
---[000005f1](01)  51                  push ecx
---[000005f2](05)  e8effdffff          call 000003e6       --CALL [000003e6]
---[000005e6](01)  55                  push ebp
---[000005e7](02)  8bec                mov ebp,esp
---[000005e9](01)  51                  push ecx
---[000005ea](03)  8b4508              mov eax,[ebp+08]
---[000005ed](01)  50                  push eax
---[000005ee](03)  8b4d08              mov ecx,[ebp+08]
---[000005f1](01)  51                  push ecx
---[000005f2](05)  e8effdffff          call 000003e6       --CALL [000003e6]
Input Aborted because of INFINITE RECURSION from [000005f2] to [000003e6]

Every time that the same function is called from the same machine address a second time without any control flow instructions in-between (within an execution trace) is a case of infinite recursion. This is shown at execution trace lines 1-16 above.

People on other groups do not know the x86 language well enough to understand that this execution trace does specify infinite recursion.

(To any comp.theory readers: I am getting this as scatter noise in the moderated clax86 newsgroup where it is totally offtopic. :-( )

And you _really_ have no idea whatsoever about mathematical proofs if you think that dressing your "proof" up as x86 asm makes _any_ difference at all. You could just as well have been trying to refute the second law of thermodynamics. :-(

A few days ago you even provoked a math guy to explain why your idea is totally bonkers.

"Extraordinary claims require extraordinary proof", what you have is similar to my math teacher in secondary school who thought he had invented a construction which could trisect an arbitrary angle. Even at that time (i.e. when I was about 14/15 years old I found it quite easy to prove that what he had was a method which quickly brought the error down to well less than his pencil line thickness, but that's like claiming that a specific rational number is equal to sqrt(2).

Again, this has nothing to do with x86 asm.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)
From: olcott
Newsgroups: comp.lang.asm.x86
Organization: A noiseless patient Spider
Date: Sat, 19 Dec 2020 21:25 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: NoO...@nospicedham.NoWhere.com (olcott)
Newsgroups: comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)
Date: Sat, 19 Dec 2020 15:25:18 -0600
Organization: A noiseless patient Spider
Lines: 106
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <IZydnWyHFf4i8kPCnZ2dnUU7-IHNnZ2d@giganews.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
<rrkpr9$svo$1@dont-email.me> <XnsAC987DDE86887admin127001@144.76.35.252>
<avudnSgIa8QSxUPCnZ2dnUU7-TvNnZ2d@giganews.com>
<rrlqmc$1pus$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="30e571bc39cd694ee7d2153651e3699f";
logging-data="8716"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/7uOhcvyq6Wa2vR2H7TDbas0xFuf+cv2I="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
Cancel-Lock: sha1:89vLw8aCfXGRVB2BHA7DaIb/Adw=
View all headers
On 12/19/2020 3:18 PM, Terje Mathisen wrote:
olcott wrote:
On 12/19/2020 6:22 AM, Kerr-Mudd,John wrote:
On Sat, 19 Dec 2020 11:57:28 GMT, James Harris
<james.harris.1@nospicedham.gmail.com> wrote:

On 17/12/2020 06:41, Frank Kotler wrote:

...

Hi Pete,

As moderator of this newsgroup, I am very reluctant to reject your
messages just because I'm not interested (but I'm not). Woifgang's
message makes me think I'm not the only one...

Could I ask you to not post on this topic here?

Could I ask Wolfgang (and others) to simply ignore messages you don't
like? It only takes you a second to click "next".

Sounds a sensible approach.

There's an "issue" here. If clax86 is on the lost of newsgroups, it
comes to my attention. If I reject it - NONE of the messages get
posted! If it were up to me, it wouldn't work this way, but it isn't.

Thanks for what you are doing, Frank. IIRC you are the only one who
took up the challenge of moderating this group and what you do for us
is appreciated.

At the risk of continuing a thread that is already off the topic of
x86 asm I wonder if there's not some way the rest of us could make the
job of the moderator easier. Maybe that's something we should discuss.

Is there any need for moderating? Just ignore any religious posts.


My post was not totally off-topic because the most important part of this post is examining the semantic meaning of the execution trace of this sequence of x86 instructions:

---[000005e6](01)  55                  push ebp
---[000005e7](02)  8bec                mov ebp,esp
---[000005e9](01)  51                  push ecx
---[000005ea](03)  8b4508              mov eax,[ebp+08]
---[000005ed](01)  50                  push eax
---[000005ee](03)  8b4d08              mov ecx,[ebp+08]
---[000005f1](01)  51                  push ecx
---[000005f2](05)  e8effdffff          call 000003e6       --CALL [000003e6]
---[000005e6](01)  55                  push ebp
---[000005e7](02)  8bec                mov ebp,esp
---[000005e9](01)  51                  push ecx
---[000005ea](03)  8b4508              mov eax,[ebp+08]
---[000005ed](01)  50                  push eax
---[000005ee](03)  8b4d08              mov ecx,[ebp+08]
---[000005f1](01)  51                  push ecx
---[000005f2](05)  e8effdffff          call 000003e6       --CALL [000003e6]
Input Aborted because of INFINITE RECURSION from [000005f2] to [000003e6]

Every time that the same function is called from the same machine address a second time without any control flow instructions in-between (within an execution trace) is a case of infinite recursion. This is shown at execution trace lines 1-16 above.

People on other groups do not know the x86 language well enough to understand that this execution trace does specify infinite recursion.

(To any comp.theory readers: I am getting this as scatter noise in the moderated clax86 newsgroup where it is totally offtopic. :-( )

And you _really_ have no idea whatsoever about mathematical proofs if you think that dressing your "proof" up as x86 asm makes _any_ difference at all. You could just as well have been trying to refute the second law of thermodynamics. :-(

A few days ago you even provoked a math guy to explain why your idea is totally bonkers.

"Extraordinary claims require extraordinary proof", what you have is similar to my math teacher in secondary school who thought he had invented a construction which could trisect an arbitrary angle. Even at that time (i.e. when I was about 14/15 years old I found it quite easy to prove that what he had was a method which quickly brought the error down to well less than his pencil line thickness, but that's like claiming that a specific rational number is equal to sqrt(2).

Again, this has nothing to do with x86 asm.

Terje


All that I am asking members of the comp.lang.asm.x86 group to do is explain that the above execution trace does specify infinite recursion.

If you don't know the x86 language or software engineering well enough to answer this then you can simply refrain from responding.

--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein



Subject: Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen} HP
From: Frank Kotler
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Sun, 20 Dec 2020 00:13 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: fbkot...@nospicedham.myfairpoint.net (Frank Kotler)
Newsgroups: comp.lang.asm.x86
Subject: Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen} HP
Date: Sat, 19 Dec 2020 19:13:31 -0500
Organization: Aioe.org NNTP Server
Lines: 36
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rrm58a$1uab$1@gioia.aioe.org>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
<rrkpr9$svo$1@dont-email.me> <XnsAC987DDE86887admin127001@144.76.35.252>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="549dc2f47cfcb0ea24851a1c2fc730d7";
logging-data="18793"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18zHIuYCz5PPbXuGKc9HgCi2mWGi5eSjC4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.5.2
Cancel-Lock: sha1:UzARow3BtPDhEusCBH/bkTk6w6Y=
View all headers
On 12/19/2020 07:22 AM, Kerr-Mudd,John wrote:
On Sat, 19 Dec 2020 11:57:28 GMT, James Harris

....
At the risk of continuing a thread that is already off the topic of
x86 asm I wonder if there's not some way the rest of us could make the
job of the moderator easier. Maybe that's something we should discuss.

Is there any need for moderating? Just ignore any religious posts.


Thank you,,,

Unfortunately, without approval from a moderator, nothing will get posted at all. I am advised that removing the group from moderation will make matters worse. Perhaps we should try it?

comp.lang.asm - the unmoderated group - may still exist. We could try that. Last I tried it, it worked. Your server may not carry it.

I would like to have an "assistant" - if I can  even remember that address - just to have a moderator in line when I kick off. The mailbox is the real moderator. Terje is providing the mailbox and may be stuck with it. Any "approved:" header works... you may need special permission to post with such a header. Depends om the server, I think.

Meanwhile, I'll try to approve the on-topic stuff - just ohnore the off-topic stuff that slips by me...

Best,
Frank







Subject: Re: Moderation issues - was Re: Refuting the {Linz, Sipser and
From: Rod Pemberton
Newsgroups: comp.lang.asm.x86, alt.lang.asm
Organization: Aioe.org NNTP Server
Date: Sun, 20 Dec 2020 05:19 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: nomaili...@nospicedham.trgzxcqvbe.cpm (Rod Pemberton)
Newsgroups: comp.lang.asm.x86,alt.lang.asm
Subject: Re: Moderation issues - was Re: Refuting the {Linz, Sipser and
Date: Sun, 20 Dec 2020 00:19:32 -0500
Organization: Aioe.org NNTP Server
Lines: 51
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rrmmre$3mt$1@gioia.aioe.org>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me>
<BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me>
<bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me>
<oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me>
<-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me>
<IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me>
<DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com>
<rreusc$2jp$1@gioia.aioe.org>
<rrkpr9$svo$1@dont-email.me>
<XnsAC987DDE86887admin127001@144.76.35.252>
<rrm58a$1uab$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="549dc2f47cfcb0ea24851a1c2fc730d7";
logging-data="7124"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19I2VxFKYiIIPbK0Ep4ZUxFT+8XSvSovzY="
Cancel-Lock: sha1:ZgIexAj3w+HjPSDYu1rvGbDOm1k=
View all headers
On Sat, 19 Dec 2020 19:13:31 -0500
Frank Kotler <fbkotler@nospicedham.myfairpoint.net> wrote:

On 12/19/2020 07:22 AM, Kerr-Mudd,John wrote:

Is there any need for moderating? Just ignore any religious posts.


Thank you,,,

Unfortunately, without approval from a moderator, nothing will get
posted at all. I am advised that removing the group from moderation
will make matters worse. Perhaps we should try it?

Well, I seem to recall asking for a casual "vote" on this a few times,
but no one ever really did state their preferences ...  Is everyone just
indifferent about CLAX's future?


Option A: keep comp.lang.asm.x86 (CLAX) alive
1) auto-approve all messages to CLAX
2) alternately, find a backup moderator

Option B: kill the group
1) halt approval of all messages to CLAX

Option C: move the group
1) auto-approve everyone posting to CLAX
2) but, post all messages to a different newsgroup
3) optionally, set message follow-ups to the new newsgroup

comp.lang.asm - the unmoderated group - may still exist. We could try
that. Last I tried it, it worked. Your server may not carry it.

I don't see comp.lang.asm (CLA) on either of two free-to-read Usenet
servers. Google Groups now requires an account to read or search Usenet
groups there. The CLA group is also not listed for Eternal-September's
webpage Usenet hierarchy search. Personally, I would prefer to have CLAX
traffic re-routed to alt.lang.asm (ALA). ALA has seemed to be widely
available over the past fifteen years or so, and has less traffic than
CLAX. IIRC, you sent rejected messages there in the past. The only
disadvantage - besides nuisance posts - is that ALA is on alt.*
hierarchy instead of comp.* hierarchy. I.e., some servers might not
have the alt.* hierarchy because of binaries, and I don't recall ever
seeing Terje post there.  IIRC, Herbert is the only one to get a
non-moderator Approved header through, or was that Wolfgang? ...

--
The EU mocked the US response to Covid in the spring of 2020.  With a
massive resurgence of Covid in the EU, they aren't laughing now.



Subject: Re: Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen}
From: James Harris
Newsgroups: comp.lang.asm.x86
Organization: A noiseless patient Spider
Date: Sun, 20 Dec 2020 11:43 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: james.ha...@nospicedham.gmail.com (James Harris)
Newsgroups: comp.lang.asm.x86
Subject: Re: Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen}
Date: Sun, 20 Dec 2020 11:43:54 +0000
Organization: A noiseless patient Spider
Lines: 68
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rrnddq$sd1$1@dont-email.me>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
<rrkpr9$svo$1@dont-email.me> <XnsAC987DDE86887admin127001@144.76.35.252>
<rrm58a$1uab$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="549dc2f47cfcb0ea24851a1c2fc730d7";
logging-data="31817"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19MgatU8j/N1GTL2Jnvdwhie7yW6gxPm3g="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:tCJgjjmNBLt2avysKTSduRCLpGc=
View all headers
On 20/12/2020 00:13, Frank Kotler wrote:
On 12/19/2020 07:22 AM, Kerr-Mudd,John wrote:
On Sat, 19 Dec 2020 11:57:28 GMT, James Harris

...
At the risk of continuing a thread that is already off the topic of
x86 asm I wonder if there's not some way the rest of us could make the
job of the moderator easier. Maybe that's something we should discuss.

Is there any need for moderating? Just ignore any religious posts.

I think there is. I appreciate the moderation. It stops this group being flooded with posts which are completely off topic as is happening to other groups.

That said, I wonder if those of us who post here could make the job of the moderator a bit easier. Specifically:

For me, the best thing about moderation is that it filters out the garbage which is unquestionably spam. I mean things such as adverts for manuals or for medicines etc. Personally, I don't mind topics like olcott's which are only vaguely related to asm programming: such things could be a problem if the group was very busy with them but it's not. And it's no problem at all for the rest of us to delete or ignore any messages we personally feel are too far away from x86 asm.

Don't get me wrong. It would be nice to have only the 'right' messages here but IMO that's an unnecessary ask of a moderator. For one thing, each person will have his own idea as to which messages are 'right'. For another, each of us can decide for himself which messages to read. It's no great trouble to do so.

So ISTM (and this is just my view) the best balance is to whitelist those who write about anything vaguely connected with x86 assembly, causing all spam (adverts etc) to be filtered out, and to leave it to the members of the group to deal with questions of what they consider to be strictly on topic or not.

Further, if a whitelisted poster goes rogue and starts to try to use the group to proselytise or publish other clearly off-topic writings that he knows it's wrong to post I would be happy to see him removed from the whitelist without mercy! And to be kept off for a long, long time. There is at least one unmoderated asm group for such people to use.

AISI that lot would ask the least of the moderator while also keeping the group clear of spam.

But that's just my view.

....

comp.lang.asm - the unmoderated group - may still exist. We could try that. Last I tried it, it worked. Your server may not carry it.

I don't think there's a comp.lang.asm but there is an alt.lang.asm which is unmoderated.

....

Meanwhile, I'll try to approve the on-topic stuff - just ohnore the off-topic stuff that slips by me...

Thanks for what you've been doing for us, Frank.


--
James Harris



Subject: Re: Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen}
From: Robert Prins
Newsgroups: comp.lang.asm.x86
Organization: A noiseless patient Spider
Date: Sun, 20 Dec 2020 14:33 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Path: i2pn2.org!i2pn.org!news.swapon.de!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: rob...@nospicedham.prino.org (Robert Prins)
Newsgroups: comp.lang.asm.x86
Subject: Re: Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen}
Date: Sun, 20 Dec 2020 14:33:36 +0000
Organization: A noiseless patient Spider
Lines: 53
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rrngb3$f9q$1@dont-email.me>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
<rrkpr9$svo$1@dont-email.me> <XnsAC987DDE86887admin127001@144.76.35.252>
<rrm58a$1uab$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="549dc2f47cfcb0ea24851a1c2fc730d7";
logging-data="16953"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19M8rkmWwMj0j82L2+hSFaqq+7d4GYjTw8="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
Cancel-Lock: sha1:h//J3gq9LbOcuKb/1MpK7kZ7DeQ=
View all headers
On 2020-12-20 00:13, Frank Kotler wrote:
On 12/19/2020 07:22 AM, Kerr-Mudd,John wrote:
On Sat, 19 Dec 2020 11:57:28 GMT, James Harris

...
At the risk of continuing a thread that is already off the topic of
x86 asm I wonder if there's not some way the rest of us could make the
job of the moderator easier. Maybe that's something we should discuss.

Is there any need for moderating? Just ignore any religious posts.


Thank you,,,

Unfortunately, without approval from a moderator, nothing will get posted at all. I am advised that removing the group from moderation will make matters worse. Perhaps we should try it?

Probably not before someone's figured out what would happen... I'm pretty sure I once read that making a group moderated is easier than undoing it!

comp.lang.asm - the unmoderated group - may still exist. We could try that. Last I tried it, it worked. Your server may not carry it.

That's a big show-stopper, Eternal September doesn't carry it, just as is doesn't carry comp.lang.pascal, whereas is does carry all its "comp.lang.pascal.*" descendants!

I would like to have an "assistant" - if I can  even remember that address - just to have a moderator in line when I kick off. The mailbox is the real moderator. Terje is providing the mailbox and may be stuck with it. Any "approved:" header works... you may need special permission to post with such a header. Depends om the server, I think.

Just explain what's involved being a moderator. If it's merely a matter of ticking some boxes, more than a few of us would probably be willing to give a hand!

I'm an admin on http://zos.efglobe.com/index.php and weeding out the spam would just take a few minutes of my time. (Would, because we've closed to forum (for now/ever?) as the z/OS system is no longer available)

Meanwhile, I'll try to approve the on-topic stuff - just ohnore the off-topic stuff that slips by me...

I like the earlier posted suggestion of an approved-poster list.

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html



Subject: Re: Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen}
From: Terje Mathisen
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Sun, 20 Dec 2020 21:40 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: terje.ma...@nospicedham.tmsw.no (Terje Mathisen)
Newsgroups: comp.lang.asm.x86
Subject: Re: Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen}
Date: Sun, 20 Dec 2020 22:40:06 +0100
Organization: Aioe.org NNTP Server
Lines: 71
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rrogbf$1ip3$1@gioia.aioe.org>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com> <rr30u4$2ba$1@dont-email.me>
<BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com> <rr340r$l9i$1@dont-email.me>
<bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com> <rr34ok$rof$1@dont-email.me>
<oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com> <rr36c2$7dk$1@dont-email.me>
<-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com> <rr39me$tev$1@dont-email.me>
<IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com> <rr7tvl$h7a$1@dont-email.me>
<DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
<rrkpr9$svo$1@dont-email.me> <XnsAC987DDE86887admin127001@144.76.35.252>
<rrm58a$1uab$1@gioia.aioe.org> <rrngb3$f9q$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="549dc2f47cfcb0ea24851a1c2fc730d7";
logging-data="24480"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19X00aZRapr1So6bmxqygPPHozYgZ8PX6E="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.5.1
Cancel-Lock: sha1:2D4MqQM5Vd7YJM7rQKxkmBwEZHk=
View all headers
Robert Prins wrote:
On 2020-12-20 00:13, Frank Kotler wrote:
On 12/19/2020 07:22 AM, Kerr-Mudd,John wrote:
On Sat, 19 Dec 2020 11:57:28 GMT, James Harris

...
At the risk of continuing a thread that is already off the topic of
x86 asm I wonder if there's not some way the rest of us could make the
job of the moderator easier. Maybe that's something we should discuss.

Is there any need for moderating? Just ignore any religious posts.


Thank you,,,

Unfortunately, without approval from a moderator, nothing will get posted at all. I am advised that removing the group from moderation will make matters worse. Perhaps we should try it?

Probably not before someone's figured out what would happen... I'm pretty sure I once read that making a group moderated is easier than undoing it!

comp.lang.asm - the unmoderated group - may still exist. We could try that. Last I tried it, it worked. Your server may not carry it.

That's a big show-stopper, Eternal September doesn't carry it, just as is doesn't carry comp.lang.pascal, whereas is does carry all its "comp.lang.pascal.*" descendants!

I would like to have an "assistant" - if I can  even remember that address - just to have a moderator in line when I kick off. The mailbox is the real moderator. Terje is providing the mailbox and may be stuck with it. Any "approved:" header works... you may need special permission to post with such a header. Depends om the server, I think.

Just explain what's involved being a moderator. If it's merely a matter of ticking some boxes, more than a few of us would probably be willing to give a hand!

I'm an admin on http://zos.efglobe.com/index.php and weeding out the spam would just take a few minutes of my time. (Would, because we've closed to forum (for now/ever?) as the z/OS system is no longer available)

Meanwhile, I'll try to approve the on-topic stuff - just ohnore the off-topic stuff that slips by me...

I like the earlier posted suggestion of an approved-poster list.

This seems like a no-brainer:

Three lists:

White - pass through automatically.
Grey - require manual approval, increment good/bad counters until N messages. Here I would guess that N = 3 is sufficient as long as they are all of the same type. Maybe require something like

   (good >= 3) && ((good-bad)/all > 0.8)

Black - remove automatically

A former good poster who starts spamming would then be given an email warning and moved to the grey list with initial good/bad counts of 0/0.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



Subject: Re: Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen}
From: Frank Kotler
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Mon, 21 Dec 2020 04:07 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: fbkot...@nospicedham.myfairpoint.net (Frank Kotler)
Newsgroups: comp.lang.asm.x86
Subject: Re: Moderation issues - was Re: Refuting the {Linz, Sipser and Kozen}
Date: Sun, 20 Dec 2020 23:07:46 -0500
Organization: Aioe.org NNTP Server
Lines: 57
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rrp7bl$17vm$1@gioia.aioe.org>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
<rrkpr9$svo$1@dont-email.me> <XnsAC987DDE86887admin127001@144.76.35.252>
<rrm58a$1uab$1@gioia.aioe.org> <rrngb3$f9q$1@dont-email.me>
<rrogbf$1ip3$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="183dca59b4e91da553707bf4991b910f";
logging-data="23394"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19eQbHUr9ch23QS1FpTVYChWflcAzdByUw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.5.2
Cancel-Lock: sha1:Hx7S/WHvPfP/CKJsR9+l/T/n+wU=
View all headers
On 12/20/2020 04:40 PM, Terje Mathisen wrote:

....
This seems like a no-brainer:

Three lists:

White - pass through automatically.

This is what I've got. I'm thinking of changing the name to
karenlist" so it won't be so racist (joke).

Grey - require manual approval,

This is everything else.

increment good/bad counters until N
messages. Here I would guess that N = 3 is sufficient as long as they are all of the same type. Maybe require something like

   (good >= 3) && ((good-bad)/all > 0.8)


???

Black - remove automatically

With one exception, I do not automatically reject anything. When I first got into this, there were many messages - several per day - with the word "Viagra" in the subject line. Those I rejected. Doesn't happen any more - there are very few "bad" messages. I don't know why. Once in a while, a long (50k or more) "binary" (no regular linefeeds) message named "Confirmation of your order" or so. Malware, I assume. Only a few that want to sell us a fake watch or a fake diploma. An occasional gal who has seen our profile and wants to be our girlfriend... Used to be much more... I can't predict the names. so can't have a "blacklist". I just delete 'em by hand,

A former good poster who starts spamming would then be given an email warning and moved to the grey list with initial good/bad counts of 0/0.

I think there is only one individual who has been permanently removed from the whitelist. (not Rick - he is very cooperative!). He was insulting to a member (Rod). If he'd posted something on-topic_he would have been back on, but he just wanted to argue with me. There is no point in arguing with a moderator... you might be right, but you won't win. :)

Then there are certain messages from Pete, which are - at least sometimes - "sorta" on-topic or "almost" on-topic. but which we don't seem to want to see here. I'm hoping I can leave Pete on the whitelist and ask him not to post them here and ask the rest of us to be tolerant.   One way or another I hope it'll work out...

Best,
Frank



Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)
From: wolfgang kern
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Tue, 22 Dec 2020 07:05 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: nowh...@nospicedham.never.at (wolfgang kern)
Newsgroups: comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)
Date: Tue, 22 Dec 2020 08:05:54 +0100
Organization: Aioe.org NNTP Server
Lines: 16
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rrs5ul$kgu$1@gioia.aioe.org>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com> <rr340r$l9i$1@dont-email.me>
<bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com> <rr34ok$rof$1@dont-email.me>
<oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com> <rr36c2$7dk$1@dont-email.me>
<-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com> <rr39me$tev$1@dont-email.me>
<IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com> <rr7tvl$h7a$1@dont-email.me>
<DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
<rrkpr9$svo$1@dont-email.me> <XnsAC987DDE86887admin127001@144.76.35.252>
<avudnSgIa8QSxUPCnZ2dnUU7-TvNnZ2d@giganews.com>
<rrlqmc$1pus$1@gioia.aioe.org>
<IZydnWyHFf4i8kPCnZ2dnUU7-IHNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="9ee2b87db71f5f6a9268ef24f0dd92e8";
logging-data="10941"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+l0E+rUiMyS6R7n8tj30i6y5jjuK3j3UE="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:84.0) Gecko/20100101
Thunderbird/84.0
Cancel-Lock: sha1:CWj2Zu5nGoLltjFVAXfcfMNa5ME=
View all headers
On 19.12.2020 22:25, olcott wrote:

All that I am asking members of the comp.lang.asm.x86 group to do is explain that the above execution trace does specify infinite recursion.

If you don't know the x86 language or software engineering well enough to answer this then you can simply refrain from responding.

you wont see any answer to this because of "unknown call target".
it's only recursive (error stack overflow) if 05e6 is part of 03e6.
there are much easier ways to produce such errors.
__
wolfgang
sorry Frank, I cannot stay quiet on illogical assumptions.




Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: Bernhard Schornak
Newsgroups: comp.lang.asm.x86
Organization: A noiseless patient Spider
Date: Tue, 22 Dec 2020 10:07 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: schor...@nospicedham.web.de (Bernhard Schornak)
Newsgroups: comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Date: Tue, 22 Dec 2020 11:07:44 +0100
Organization: A noiseless patient Spider
Lines: 53
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rrsgi0$4gt$1@dont-email.me>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<35OdnezHsPxac0nCnZ2dnUU7-YvNnZ2d@giganews.com> <rr2tlk$c32$1@dont-email.me>
<zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com> <rr2vb1$mhs$1@dont-email.me>
<SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com> <rr30u4$2ba$1@dont-email.me>
<BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com> <rr340r$l9i$1@dont-email.me>
<bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com> <rr34ok$rof$1@dont-email.me>
<oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com> <rr36c2$7dk$1@dont-email.me>
<-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com> <rr39me$tev$1@dont-email.me>
<IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com> <rr7tvl$h7a$1@dont-email.me>
<DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="9ee2b87db71f5f6a9268ef24f0dd92e8";
logging-data="10031"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19QCEbdVsQb1XwwXKi6aYDQb3QLMGQg+V8="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.4
Cancel-Lock: sha1:TZ+2Aw5RB8nHHaAhROySUHSvb2k=
View all headers
olcott wrote:

_H_Hat:
[000005e6](01)  55                  push ebp
[000005e7](02)  8bec                mov ebp,esp
[000005e9](01)  51                  push ecx
[000005ea](03)  8b4508              mov eax,[ebp+08]
[000005ed](01)  50                  push eax
[000005ee](03)  8b4d08              mov ecx,[ebp+08]
[000005f1](01)  51                  push ecx
[000005f2](05)  e8effdffff          call 000003e6
[000005f7](03)  83c408              add esp,+08
[000005fa](03)  8945fc              mov [ebp-04],eax
[000005fd](04)  837dfc00            cmp dword [ebp-04],+00
[00000601](02)  7404                jz 00000607
[00000603](02)  ebfe                jmp 00000603
[00000605](02)  eb01                jmp 00000608
[00000607](01)  f4                  hlt
[00000608](02)  8be5                mov esp,ebp
[0000060a](01)  5d                  pop ebp
[0000060b](01)  c3                  ret


0603 jumps to itself. Reduce to

_H-Hat:movl  0x0C(%esp), %eax
        subl  $0x08,      %esp
        movl  %eax,       0x00(%esp)
        movl  %eax,       0x04(%esp)
        call  _WHATEVER_THAT_IS
        testl %eax,       %eax
        je    0f
    L00:jmp   L00                      # loop forever
      0:hlt                            # CLI/STI?
        addl $0x08,       %esp
        ret



As long as the code at 0x03E6 is unknown, it is impossible to tell
anything. _H_Hat itself does nothing ... except wasting clocks and
electrical power when the returned value is not zero.

The only thing I can see in your debug trace is that you would run
out of stack, if the debugger did not stop your attempts with this
error message before ESP reached your stack's bottom. Maybe a good
proof the debugger works well, but nothing else... ;)


Merry Winter Solstice!

Bernhard Schornak



Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: olcott
Newsgroups: comp.lang.asm.x86, comp.theory
Followup: comp.theory
Organization: A noiseless patient Spider
Date: Tue, 22 Dec 2020 15:55 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: NoO...@nospicedham.NoWhere.com (olcott)
Newsgroups: comp.lang.asm.x86,comp.theory
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Followup-To: comp.theory
Date: Tue, 22 Dec 2020 09:55:19 -0600
Organization: A noiseless patient Spider
Lines: 82
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <Ed6dnahm5sd6i3_CnZ2dnUU7-amdnZ2d@giganews.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr2tlk$c32$1@dont-email.me> <zp6dnf8CEZuHnUjCnZ2dnUU7-SfNnZ2d@giganews.com>
<rr2vb1$mhs$1@dont-email.me> <SrSdnbIYprUrnEjCnZ2dnUU7-U2dnZ2d@giganews.com>
<rr30u4$2ba$1@dont-email.me> <BcSdnZTygJfElkjCnZ2dnUU7-UednZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rrsgi0$4gt$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="9ee2b87db71f5f6a9268ef24f0dd92e8";
logging-data="30585"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18NLK1lpbgvf3m0in+/1m0pUj1Pi3wn2Zk="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
Cancel-Lock: sha1:0R9aVo9sRvwDpXC914SbRuid0s8=
View all headers
On 12/22/2020 4:07 AM, Bernhard Schornak wrote:
olcott wrote:

_H_Hat:
[000005e6](01)  55                  push ebp
[000005e7](02)  8bec                mov ebp,esp
[000005e9](01)  51                  push ecx
[000005ea](03)  8b4508              mov eax,[ebp+08]
[000005ed](01)  50                  push eax
[000005ee](03)  8b4d08              mov ecx,[ebp+08]
[000005f1](01)  51                  push ecx
[000005f2](05)  e8effdffff          call 000003e6
[000005f7](03)  83c408              add esp,+08
[000005fa](03)  8945fc              mov [ebp-04],eax
[000005fd](04)  837dfc00            cmp dword [ebp-04],+00
[00000601](02)  7404                jz 00000607
[00000603](02)  ebfe                jmp 00000603
[00000605](02)  eb01                jmp 00000608
[00000607](01)  f4                  hlt
[00000608](02)  8be5                mov esp,ebp
[0000060a](01)  5d                  pop ebp
[0000060b](01)  c3                  ret


0603 jumps to itself. Reduce to

_H-Hat:movl  0x0C(%esp), %eax
        subl  $0x08,      %esp
        movl  %eax,       0x00(%esp)
        movl  %eax,       0x04(%esp)
        call  _WHATEVER_THAT_IS
        testl %eax,       %eax
        je    0f
    L00:jmp   L00                      # loop forever
      0:hlt                            # CLI/STI?
        addl $0x08,       %esp
        ret



As long as the code at 0x03E6 is unknown, it is impossible to tell
anything. _H_Hat itself does nothing ... except wasting clocks and
electrical power when the returned value is not zero.

The only thing I can see in your debug trace is that you would run
out of stack,

That is the answer that I expected and confirms that I am correct.

I am using the x86 code that was translated from C as the machine description language of a Universal Turing Machine equivalent. I wrote a whole x86utm operating system for this purpose. This means that the assumption is infinite memory and thus infinite stack.

if the debugger did not stop your attempts with this
error message before ESP reached your stack's bottom. Maybe a good
proof the debugger works well, but nothing else... ;)


In my actual test case the debugger is a halt decider that recognizes the pattern, (in my prior post) stops simulating this code and reports not halting.

It turns out that all the halting problem proofs depend on the assumption that such a halt decider is impossible.

Thanks for your help. The people in the other forums don't seem to have a clue about the x86 language.


Merry Winter Solstice!

Bernhard Schornak



--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein



Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: Robert
Newsgroups: comp.lang.asm.x86, comp.theory
Organization: Aioe.org NNTP Server
Date: Tue, 22 Dec 2020 17:40 UTC
References: 1 2 3 4 5 6 7 8 9 10
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: red...@nospicedham.ev1.net.invalid (Robert)
Newsgroups: comp.lang.asm.x86,comp.theory
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Date: Tue, 22 Dec 2020 17:40:39 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 66
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rrtb2n$jpl$1@gioia.aioe.org>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com> <rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com> <7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com> <NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com> <20201214113311.509@kylheku.com> <kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com> <rr9uag$1j0n$1@gioia.aioe.org> <U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rrsgi0$4gt$1@dont-email.me> <Ed6dnahm5sd6i3_CnZ2dnUU7-amdnZ2d@giganews.com>
Injection-Info: reader02.eternal-september.org; posting-host="9ee2b87db71f5f6a9268ef24f0dd92e8";
logging-data="30202"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/onjiJMO4gNYSc9Vwwf64pc5WBYK3sphw="
Cancel-Lock: sha1:xvzod+8zauYgXEv/Jdcv1Xtxe9Q=
View all headers
In comp.lang.asm.x86 olcott <NoOne@nospicedham.nowhere.com> wrote in part:
On 12/22/2020 4:07 AM, Bernhard Schornak wrote:
olcott wrote:

_H_Hat:
[000005e6](01)? 55????????????????? push ebp
[000005e7](02)? 8bec??????????????? mov ebp,esp
[000005e9](01)? 51????????????????? push ecx
[000005ea](03)? 8b4508????????????? mov eax,[ebp+08]
[000005ed](01)? 50????????????????? push eax
[000005ee](03)? 8b4d08????????????? mov ecx,[ebp+08]
[000005f1](01)? 51????????????????? push ecx
[000005f2](05)? e8effdffff????????? call 000003e6
[000005f7](03)? 83c408????????????? add esp,+08
[000005fa](03)? 8945fc????????????? mov [ebp-04],eax
[000005fd](04)? 837dfc00??????????? cmp dword [ebp-04],+00
[00000601](02)? 7404??????????????? jz 00000607
[00000603](02)? ebfe??????????????? jmp 00000603
[00000605](02)? eb01??????????????? jmp 00000608
[00000607](01)? f4????????????????? hlt
[00000608](02)? 8be5??????????????? mov esp,ebp
[0000060a](01)? 5d????????????????? pop ebp
[0000060b](01)? c3????????????????? ret


0603 jumps to itself. Reduce to

_H-Hat:movl? 0x0C(%esp), %eax
 ?????? subl? $0x08,????? %esp
 ?????? movl? %eax,?????? 0x00(%esp)
 ?????? movl? %eax,?????? 0x04(%esp)
 ?????? call? _WHATEVER_THAT_IS
 ?????? testl %eax,?????? %eax
 ?????? je??? 0f
 ?? L00:jmp?? L00????????????????????? # loop forever
 ???? 0:hlt??????????????????????????? # CLI/STI?
 ?????? addl $0x08,?????? %esp
 ?????? ret



As long as the code at 0x03E6 is unknown, it is impossible to tell
anything. _H_Hat itself does nothing ... except wasting clocks and
electrical power when the returned value is not zero.

The only thing I can see in your debug trace is that you would run
out of stack,

If it doesn't get caught in the infinite loop at 603, likely less
than one million before you hit the stack guard page.


That is the answer that I expected and confirms that I am correct.

I am using the x86 code that was translated from C as the
machine description language of a Universal Turing Machine
equivalent. I wrote a whole x86utm operating system for
this purpose. This means that the assumption is infinite
memory and thus infinite stack.

??? I don't think any general-use compiler will emit a HLT
instruction.  No need, this is a priviliged ring0 instruction
on modern x86 p-mode OSes.

-- Robert



Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)
From: Frank Kotler
Newsgroups: comp.lang.asm.x86
Organization: Aioe.org NNTP Server
Date: Tue, 22 Dec 2020 22:07 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: fbkot...@nospicedham.myfairpoint.net (Frank Kotler)
Newsgroups: comp.lang.asm.x86
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (x86 portion)
Date: Tue, 22 Dec 2020 17:07:45 -0500
Organization: Aioe.org NNTP Server
Lines: 24
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <rrtr0h$abn$1@gioia.aioe.org>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr340r$l9i$1@dont-email.me> <bo2dnRdK_KDeiEjCnZ2dnUU7-UnNnZ2d@giganews.com>
<rr34ok$rof$1@dont-email.me> <oaedncLQ-96MhEjCnZ2dnUU7-WnNnZ2d@giganews.com>
<rr36c2$7dk$1@dont-email.me> <-LCdnQjCJqk1vEjCnZ2dnUU7-eXNnZ2d@giganews.com>
<rr39me$tev$1@dont-email.me> <IdGdnS9EruNl6ErCnZ2dnUU7-QvNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rreusc$2jp$1@gioia.aioe.org>
<rrkpr9$svo$1@dont-email.me> <XnsAC987DDE86887admin127001@144.76.35.252>
<avudnSgIa8QSxUPCnZ2dnUU7-TvNnZ2d@giganews.com>
<rrlqmc$1pus$1@gioia.aioe.org>
<IZydnWyHFf4i8kPCnZ2dnUU7-IHNnZ2d@giganews.com> <rrs5ul$kgu$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="9ee2b87db71f5f6a9268ef24f0dd92e8";
logging-data="4503"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19cxtxuhM6gua8fnNXU5wvqj5fLifFtcGM="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.5.2
Cancel-Lock: sha1:4eV1doq5Hk9sI3TORXJHh0M8Hhg=
View all headers
On 12/22/2020 02:05 AM, wolfgang kern wrote:
On 19.12.2020 22:25, olcott wrote:

All that I am asking members of the comp.lang.asm.x86 group to do is explain that the above execution trace does specify infinite recursion.

If you don't know the x86 language or software engineering well enough to answer this then you can simply refrain from responding.

you wont see any answer to this because of "unknown call target".
it's only recursive (error stack overflow) if 05e6 is part of 03e6.
there are much easier ways to produce such errors.
__
wolfgang
sorry Frank, I cannot stay quiet on illogical assumptions.

Okay Wolfgang - I w0n't remove ya from the whitelist. :)

This seems "on-topic" to me. Weren't you one of the ones who was complaining? Apologize to Terje! (seriously - hope this isn't a problem)

Best,
Frank



Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
From: olcott
Newsgroups: comp.lang.asm.x86, comp.theory
Organization: A noiseless patient Spider
Date: Tue, 22 Dec 2020 22:19 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: NoO...@nospicedham.NoWhere.com (olcott)
Newsgroups: comp.lang.asm.x86,comp.theory
Subject: Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within
Date: Tue, 22 Dec 2020 16:19:10 -0600
Organization: A noiseless patient Spider
Lines: 103
Approved: fbkotler@myfairpoint.net - comp.lang.asm.x86 moderation team.
Message-ID: <zOqdnWa0npJD7X_CnZ2dnUU7-V_NnZ2d@giganews.com>
References: <3JSdnRrpiNHInV3CnZ2dnUU7-YHNnZ2d@giganews.com>
<rr7tvl$h7a$1@dont-email.me> <DLCdnTdFDrYoHErCnZ2dnUU7-e3NnZ2d@giganews.com>
<7fbe5f35-e17b-4964-888d-ef038a6a2126n@googlegroups.com>
<NuydnecrJuqQL0rCnZ2dnUU7-RHNnZ2d@giganews.com>
<20201214113311.509@kylheku.com>
<kcqdnSuH7702QkrCnZ2dnUU7-VvNnZ2d@giganews.com>
<rr9uag$1j0n$1@gioia.aioe.org>
<U9GdnYVTzZu-KkfCnZ2dnUU7-TPNnZ2d@giganews.com> <rrsgi0$4gt$1@dont-email.me>
<Ed6dnahm5sd6i3_CnZ2dnUU7-amdnZ2d@giganews.com> <rrtb2n$jpl$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="9ee2b87db71f5f6a9268ef24f0dd92e8";
logging-data="10899"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/0ISQBKavlRmXb2j8zjl+ZjHrSGMxeTxk="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
Cancel-Lock: sha1:86ndf1mB56OLjfIrJjPhqf5VVN8=
View all headers
On 12/22/2020 11:40 AM, Robert wrote:
In comp.lang.asm.x86 olcott <NoOne@nospicedham.nowhere.com> wrote in part:
On 12/22/2020 4:07 AM, Bernhard Schornak wrote:
olcott wrote:

_H_Hat:
[000005e6](01)? 55????????????????? push ebp
[000005e7](02)? 8bec??????????????? mov ebp,esp
[000005e9](01)? 51????????????????? push ecx
[000005ea](03)? 8b4508????????????? mov eax,[ebp+08]
[000005ed](01)? 50????????????????? push eax
[000005ee](03)? 8b4d08????????????? mov ecx,[ebp+08]
[000005f1](01)? 51????????????????? push ecx
[000005f2](05)? e8effdffff????????? call 000003e6
[000005f7](03)? 83c408????????????? add esp,+08
[000005fa](03)? 8945fc????????????? mov [ebp-04],eax
[000005fd](04)? 837dfc00??????????? cmp dword [ebp-04],+00
[00000601](02)? 7404??????????????? jz 00000607
[00000603](02)? ebfe??????????????? jmp 00000603
[00000605](02)? eb01??????????????? jmp 00000608
[00000607](01)? f4????????????????? hlt
[00000608](02)? 8be5??????????????? mov esp,ebp
[0000060a](01)? 5d????????????????? pop ebp
[0000060b](01)? c3????????????????? ret


0603 jumps to itself. Reduce to

_H-Hat:movl? 0x0C(%esp), %eax
  ?????? subl? $0x08,????? %esp
  ?????? movl? %eax,?????? 0x00(%esp)
  ?????? movl? %eax,?????? 0x04(%esp)
  ?????? call? _WHATEVER_THAT_IS
  ?????? testl %eax,?????? %eax
  ?????? je??? 0f
  ?? L00:jmp?? L00????????????????????? # loop forever
  ???? 0:hlt??????????????????????????? # CLI/STI?
  ?????? addl $0x08,?????? %esp
  ?????? ret



As long as the code at 0x03E6 is unknown, it is impossible to tell
anything. _H_Hat itself does nothing ... except wasting clocks and
electrical power when the returned value is not zero.

The only thing I can see in your debug trace is that you would run
out of stack,

If it doesn't get caught in the infinite loop at 603, likely less
than one million before you hit the stack guard page.


It is only this portion of the excution trace of H_Hat that I am referring to. The second call 000003e6 from the same machine address [000005f2] without any control flow instructions inbetween indicates infinite recursion. Many of the comp.theory people could not understand this.

---[000005e6](01)  55                  push ebp
---[000005e7](02)  8bec                mov ebp,esp
---[000005e9](01)  51                  push ecx
---[000005ea](03)  8b4508              mov eax,[ebp+08]
---[000005ed](01)  50                  push eax
---[000005ee](03)  8b4d08              mov ecx,[ebp+08]
---[000005f1](01)  51                  push ecx
---[000005f2](05)  e8effdffff          call 000003e6       --CALL [000003e6]
---[000005e6](01)  55                  push ebp
---[000005e7](02)  8bec                mov ebp,esp
---[000005e9](01)  51                  push ecx
---[000005ea](03)  8b4508              mov eax,[ebp+08]
---[000005ed](01)  50                  push eax
---[000005ee](03)  8b4d08              mov ecx,[ebp+08]
---[000005f1](01)  51                  push ecx
---[000005f2](05)  e8effdffff          call 000003e6       --CALL [000003e6]

That is the answer that I expected and confirms that I am correct.

I am using the x86 code that was translated from C as the
machine description language of a Universal Turing Machine
equivalent. I wrote a whole x86utm operating system for
this purpose. This means that the assumption is infinite
memory and thus infinite stack.

??? I don't think any general-use compiler will emit a HLT
instruction.  No need, this is a priviliged ring0 instruction
on modern x86 p-mode OSes.

-- Robert


I use it in the x86 emulator to indicate the that system definitely stopped executing at this point. Before I used this instruction the emulator tended to try to execute garbage. When it popped the return from main() it had no where to go.

--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre minds." Einstein



Pages:12
rocksolid light 0.7.2
clearneti2ptor