| Deutsch English Français Italiano |
|
<0amdndFJSZSzYD77nZ2dnZfqnPednZ2d@brightview.co.uk> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!local-1.nntp.ord.giganews.com!local-2.nntp.ord.giganews.com!Xl.tags.giganews.com!local-3.nntp.ord.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 26 Jul 2024 19:46:54 +0000
Subject: Re: This function proves that only the outermost HHH examines the
execution trace
Newsgroups: comp.theory
References: <v80h07$2su8m$3@dont-email.me>
From: Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Date: Fri, 26 Jul 2024 20:46:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Firefox/91.0 SeaMonkey/2.53.17
MIME-Version: 1.0
In-Reply-To: <v80h07$2su8m$3@dont-email.me>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <0amdndFJSZSzYD77nZ2dnZfqnPednZ2d@brightview.co.uk>
Lines: 205
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-wIk5gKNwuZTB1tbTlOc6+QDs01oE/q5f1WDMKUuuudo2cmCu5e4OiVd09Kv5zBKm+zODICZYVMTTRk1!SlTU7MAiqxqReyTrGHN/zcuoitpTH60ChAdL3vMpfPNCP0cUO2nyI74uxuyEUxNMkxBY0COLmYGk!5G79E7cVZ6q0b2Hh3flnQC7wwtM=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Bytes: 12194
On 26/07/2024 16:56, olcott wrote:
> This is meant for Mike, Joes and Fred don't have the technical competence to understand it.
>
> Richard might be able to understand it yet the fact that he is
> stuck in rebuttal mode makes any understanding that he may have
> utterly useless.
>
> Mike: It seems that HHH has been a pure function of its inputs
> and never has provided data downward to its slaves that corrupts
> their halt status decision. They don't even make a halt status
> decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH effectively uses the static mutable data
to pass flags to the inner HHH that modify its behaviour. The Root flag below is derived from the
actual static data and causes inner HHH to totally skip its own abort logic!
You seem to acknowledge this, but claim it does not matter for various reasons, because whatever
mistakes you are making, what finally gets printed out is saying the right thing!
The problem with this attitude is that when you describe your ideas and present the printed output,
you say that HHH is "simulating" DDD, and people know what simulating means, and everyone has
expectations of what that implies. You are happy to use those expectations when it goes along with
what you want to claim, but try to conceal that those expectations are unjustified because what you
are doing is not "proper simulation" as everybody would understand it.
You can't have it both ways.
The way to avoid all such concerns is to implement simulation correctly, like you claim to have
done. Simulation is not /just/ the step by step simulation provided by libx86emu(sp?) - your entire
computation environment needs to correctly work together so that the end-to-end effect is that
simulated code exactly follows the behaviour of the original code, at least up to the point where
the simulator aborts. Put differently, you also need to simulate the /correct/ instructions and data.
The same applies to when you try to "copy" code, as in your H1 and HHH1: by definition of "copy"
[as understood by everybody here] the behaviour of the copied code must exactly match that of the
original code - otherwise it is simply not a proper "copy" by definition.
As a joke alternative you could stop claiming to simulate or copy anything, and say instead you are
misulating and pocying code! You could say "HHH misulates DDD and sees that DDD will never halt"
but obviously people will just say "What's misulating, and why should misulating (whatever it is)
allow HHH to see things about DDD?" You see - from your perspective that would be hopeless for your
wider scope argument which attempts to invalidate the Linz/Sipser proofs. Similarly if you claim
that you "pocyed" HHH to HHH1 and they have different results when given input DDD, people will just
look blank - what's "pocying" and why would anyone expect a pocyed routine to give the same result
as the original routine?
No, none of that flies. It was a joke, but with a sensible aim - to convince you that for your
wider scale arguments you need simulating (and copying) to have their correct meanings as everybody
here will understand them. No good saying "they mean something else, but it doesn't matter because
what my program finally writes out is TRUE".
Of course none of that will convince you of anything and you'll just continue.
>
> I could change the code so that the slave instances can and do
> try to form a halt status decision on the basis of the execution
> trace that they do have.
Your concept of master/slaves simulators is broken. There are outer/inner simulators but that is
just a relative term, and all simulated code (at whatever level) needs to have the same behaviour as
the unsimulated code.
If your simulation was correctly designed/implemented this would just work. (Of course, HHH has to
correctly use the DebugStep() (et al.) primitive ops to gather what it needs to make its decision,
no cheating with globals etc..)
I know you've said you don't have time to think about how to do this correctly. That's fair enough,
but in the meantime you should not claim that your incorrect implementation proves your conclusions!
To be fair, you shouldn't need x86utm.exe in your arguments - it is not the Appeal To Authority
that you imagine it to be! All of your arguments could just be phrased in pseudo-code and there
would not be any disagreement about how that would behave by posters here. Of course, your ideas
expressed that way would still be Wrong, and nobody would agree with them, but that's the case
anyway when you try to bring in x86utm!
>
> There is no sense in doing that because they can't possibly have
> enough data, they will always be one whole execution trace behind
> the next outer instance of HHH.
Well it's your code so correct it or don't correct it...
The sense in doing it would be:
1) Pride in having implemented something without botching it
2) Slight increase in the reliability of conclusions base on running x86utm simulations.
[But in any case you won't be able to claim x86utm "proves" any of your claims.
That's just not how proofs work...]
3) Surely there must be a (3). Um, third time lucky?
Regarding (2) I've found the answer to my recent question of what you had done wrong in the whole
"DDD simulated by HHH has different behaviour to DDD simulated by 'copy' HHH1". It turns out HHH1
wasn't a copy, it was a "pocy" [the word I coined above] :)
So what was the coding error? To remind us, here's a comparison of the different behaviour:
[VIEW WITH FIXED FONT!!]
HHH1 (DDD) HHH (DDD)
-----------------------------------------------------------------
1 main () main ()
2 HHH1 (DDD) HHH (DDD)
4 Simulate (DDD) Simulate (DDD)
5 | DDD() | DDD()
6 | HHH (DDD) | HHH (DDD)
7 | Simulate (DDD) | Simulate (DDD)
8 | | DDD() | DDD()
9 | | HHH (DDD) | HHH (DDD)
10 | | Simulate (DDD) Abort
11 | | DDD() ret 0
12 | | HHH (DDD) ret 0
13 | Abort
14 | ret 0
15 | ret
16 ret 1
17 ret 0
The question you never managed to answer was why on the right does HHH [line 2] spot that HHH is
called below [lines 6,9] in "infinite recursive simulation", while on the left HHH1 [line 2] does
not make the same decision, despite being a "copy" of HHH on the right?
The explantion is down to your misuse of mutable static variables in HHH/HHH1 to store their
execution traces covering all sub-simulations. HHH and HHH1 each have /their own/ static execution
trace table! So :
- HHH [line 2, RHS] has its own trace table which is explicitly updated
by (arbitrarily nested) sub-simulations, BUT ONLY BY SIMULATIONS OF
HHH1!!! So it "sees" the calls to HHH [lines 6,9] and matches
its [unsound] abort pattern.
- HHH1 [line 2, LHS] has its own trace table which is explicitly updated
by (arbitrarily nested) sub-simulations, BUT ONLY BY SIMULATIONS OF
HHH1!!! Simulations of HHH will update the execution trace in HHH's
static variable. So HHH1 completely fails to "see" the calls to HHH
[lines 6,9] and so never matches its [unsound] abort pattern. Instead
it continues simulating until DDD terminates, correctly deciding that
DDD terminates.
So... as suspected the reason HHH(DDD) and HHH1(DDD) see different behaviour is simply that HHH1 is
not a proper copy of HHH - it's a "pocy"! And the coding error is the misuse of mutable static
variables which you already know is wrong, although you are reluctant to correct.
It is of course nothing to do with "pathelogical self reference" or any such nonsense - it's just
WRONG CODING. Note that your HHH/HHH1 are trying to "push" data [inner simulation trace records] to
the outer simulators, which is Wrong Design. Right Design is for the outer simulators to dig into
the inner simulations to scrape what data they need. If HHH/HHH1 worked this way they would both
have the same behaviour as common sense requires, and you wouldn't be able to use this example to
back up your claims of different behaviour. In fact both HHH/HHH1 would then report DDD as
non-halting, which is wrong due to the unsound abort pattern they both use - but at least it would
be consistent, as required for a proper copy (rather than some kind of pocy).
Regards,
Mike.
>
> As they are the slaves perform their proper function of showing
> the actual behavior of DDD correctly emulated by HHH.
>
> u32 Decide_Halting_HH(u32** Aborted,
> u32** execution_trace,
> Decoded_Line_Of_Code** decoded,
> u32 code_end,
> u32 End_Of_Code,
> Registers** master_state,
> Registers** slave_state,
> u32** slave_stack,
> u32 Root)
> {
> u32 aborted_temp = 0; // 2024-06-05
> u32 Current_Length_Of_Execution_Trace = 0;
> while (aborted_temp == 0) // 2024-06-05
> {
> u32 EIP = (*slave_state)->EIP; // Save EIP of this instruction
> DebugStep(*master_state, *slave_state, *decoded); // Execute it
> if (EIP > Last_Address_Of_Operating_System()) // Ignore OS code
> {
> PushBack(**execution_trace, (u32)*decoded,
> sizeof(Decoded_Line_Of_Code));
> }
========== REMAINDER OF ARTICLE TRUNCATED ==========