XPost: comp.theory, sci.logic, sci.math
On 6/7/22 9:04 PM, olcott wrote:
On 6/7/2022 7:05 PM, Mike Terry wrote:
On 07/06/2022 21:51, Mr Flibble wrote:
On Tue, 7 Jun 2022 15:34:13 -0500
olcott <NoOne@NoWhere.com> wrote:
<..snip..>
How many times do I have to say this before you notice that I said it
at least once? H (in the current process) always creates a new
process context to emulate its its input with an x86 emulator.
I will have to take your word for it as you refuse to publish source
code. Why not just stick your project on GitHub? Open source is de
rigueur these days. What are you trying to hide?
If a new process context is made then how is nested simulation
detected?
The code in x86utm.exe (his emulator) that emulates individual
instructions also updates a global trace table, making it accessible
to the emulated code. So every instruction and any (nested,
nested(nested) etc.) simulated instructions ALL get merged together in
this one global trace.
I imagine the global trace table to be much like the printed traces
that PO posts over and over. If YOU can recognise some pattern in
those printed traces, then logically H can spot that same pattern in
the global trace, as the info in both cases is more or less the same.
When a UTM simulates TM description
that invokes a UTM that simulates a TM description
Nope, it invoke a copy of H that simulates its input and then abort is.
that invokes a UTM that simulates a TM description
that invokes a UTM that simulates a TM description
that invokes a UTM that simulates a TM description
This appears to be a flaw in your whole system design, you P changes to
call as H whatever you try to use to simulate it.
P needs to call the H that this P is designed to refute, and no others.
Remember, You need to pick *A* H that you are going to claim is a
correct decider, then you make *A* P based on that one, and run the
descion and test on THOSE SPECIIFIC machines.
All of this whole process is data belongs to the first UTM, thus global
data is not needed and the whole process is a computable function of the original inputs to the outermost UTM.
????
The input to the UTM is a description of a P that calls the H that you
claim is correct in aborting its simulation of the P built on it.
That UTM will simulate that input and generate the exact same results as running that P.
That emulation will show the first 7 instructions of P, then the call to
H, and then H doing its emulations and eventually aborting its emulaton
and returning the 0 to P and P halting.
If the H doesn't do this, then your H never answered H(P,P) as 0, and
your whole premise is false, and shown to be a LIE.
[Above is my best guess, based on previous PO answers before you were
interested.]
I assume the data segment of each process is private...
PO said "new process context.." and that would imply each has its own
address space, and that is obviously how simulation is SUPPOSED to
work (like a TM would perform) - so your assumption is totally
reasonable!
My unlimited nested simulations could not function properly if I did not
know all of the details of how to do this.
Then why do you think the UTM sees another UTM when it should see an H.
Remember, your LIE that the test was to REPLACE H with a UTM has been discredited, or are you still claiming that is what needs to be done,
even though it doesn't match the test you define?
Or, do you not understand that the representation of P includes
EVERYTHING needed to run it, and thus does include the copy of H that it
calls, so it doesn't change when we give that input to the UTM?
But you've made the basic mistake of assuming PO knows what a
"process" is - PO is not a software engineer or computer scientist,
although he does his utmost to give that impression!
Anyhow, each PO-simulation is like a single-stepped thread within a
SINGLE shared address space, so any globals in his H are shared by all
his "independent" simulations.
[Above is based on previous PO answers before you were interested.]
Mike.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)