quentron.com

[sarkeizen]

An emulator or interpreter can not work because they only execute the code the same as the CPU would and is therefore prone to the same problems.

*sigh* Well this should be fun....

No idiot.  Remember you said that a CPU with a privilege ring could run a program which can monitor the code?  An interpreter, in this case a program that loads our object file and then processes each byte similar to the way the CPU would - could be programmed to do exactly the same thing!  Remember how you described your "control program" it could interrupt the CPU (or act at the behest of an interrupt) and check variables and things.  How you talked about a debugger stepping through and doing checks with each instruction.  This is exactly what a byte-code interpreter does/can do!

I swear you lower the mean IQ of the forum with each post.

Now I know that you know something about programming, but I feel you are lacking on low level assembly programming and hardware interfaces.

No, this is actually one of those cases where you're so stupid you only think the other person doesn't understand.  I'm pretty sure this isn't the first time it's happened to you although it may be the first time someone has pointed it out.

So again, given that your control program is acting like your debugger and stepping through each byte, word, instruction and making your checks that your debugger would have.   Then if a debugger + your checks can solve the halting problem by making checks then does it not stand to reason that a byte-code interpreter like the one described above solves the halting problem in effectively the same way as a Debugger, Ring 0, hypervisor, etc.. does?

So let me ask you a question.

I'll answer, on the condition you answer the question I just asked above in bold clearly and unambiguously.

If you run a segment of code through the CPU and it completes, then could you assume the same code will always complete every time it's run?

If by "complete" you mean the code halts then no way.

The CPU has a state, memory has a state - if we were talking about a CPU with privilege levels or other hardware then there are other factors).  Depending on the CPU even after a hard reset, or a complete power cycle the system state is not the same.

[lumen]

*sigh* Well this should be fun....

So again, given that your control program is acting like your debugger and stepping through each byte, word, instruction and making your checks that your debugger would have.   Then if a debugger can solve the halting problem by making checks then does it not stand to reason that a byte-code interpreter like the one described here solves the halting problem in effectively the same way as a Ring 0, Debugger, etc.. does?I

Wow, talk about getting up cranky.

Yes exactly the same except that the code and registers and stack are examined BEFORE it is executed, and it only executes this one instruction before returning control to the controller/interpreter.

Under these conditions any failure to solve the halting program theory is not due to the program that's running but to the control program.
This will allow ANY pile of garbage to run through the CPU doing whatever to memory or outputs along with jumps and calls or anything that happens, and still remain under control of the "control/interpreter"

Also because the program counter and memory writes can be recorded, near endless loops are possible as long as something is changing.

How does this work! It's not as hard as you think.
But do go on!


Or maybe tell us all how this is relevant to the quenco chip theory that you keep avoiding!

[sarkeizen]

Yes exactly the same except that the code and registers and stack are examined BEFORE it is executed, and it only executes this one instruction before returning control to the controller/interpreter.

This will allow ANY pile of garbage to run through the CPU doing whatever to memory or outputs along with jumps and calls or anything that happens, and still remain under control of the "control/interpreter"

Also because the program counter and memory writes can be recorded, near endless loops are possible as long as something is changing.

So you're agreeing that this byte-code interpreter solves the halting problem - that is when fed a program in byte-code it will always terminate and just before doing so it will always produce a correct output telling you if the byte-code submitted to it as input will terminate or not.  Also you believe that this is analogous to the way all your other solutions work.

Again a "yes" or "no, and here's why" here would be helpful...

Or maybe tell us all how this is relevant to the quenco chip theory that you keep avoiding!

Please use English that makes sense.  I'm not avoiding talking about quenco at all.  In fact the very last time you asked this question I gave you an answer.  That said my answer hasn't changed, go back and read my post...like you almost never do.

[lumen]

So you're agreeing that this byte-code interpreter solves the halting problem - that is when fed a program in byte-code it will always terminate and just before doing so it will always produce a correct output telling you if the byte-code submitted to it as input will terminate or not.  Also you believe that this is analogous to the way all your other solutions work.

Again a "yes" or "no, and here's why" here would be helpful...
Please use English that makes sense.  I'm not avoiding talking about quenco at all.  In fact the very last time you asked this question I gave you an answer.  That said my answer hasn't changed, go back and read my post...like you almost never do.

Ok, yes,  this will work. It will tell you if it terminated by itself or had to be terminated from endless loop.

[sarkeizen]

Ok, yes,  this will work. It will tell you if it terminated by itself or had to be terminated from endless loop.

Likewise, it makes no difference if we treat the interpreter like a function. Lets call it WillThisEnd() and say it takes as input two parameters.  A pointer to the byte-code and another pointer to the input the byte-coded program uses.  So you could run a piece of byte-code through your interpreter like this:

WillThisEnd(program,data)

Where program is a pointer to the bytecode and data is a pointer to the input data.  In terms of output let's say the function returns 'true' if the program terminates and 'false' if the program does not terminate.

This doesn't significantly change the situation right?