quentron.com

[sarkeizen]

Vague, vague, vague, vague.  Did you major in vagueness?   Is that some subspecialty of engineering these days?

then run each instruction

How is that different from an emulator?

Do you or do you not concede that an emulator which runs a program would not terminate by virtue of the instructions it is emulating if it was running a program that does not terminate?  If so then do you also concede that an emulator can not solve your problem for an arbitrary program?  If not why - please give considerable detail.

If it is not an emulator then does your program identify loops and then execute code to determine if the loops terminate or not.

Seriously I've asked you a number of simple and straight-forward questions and you do anything but answer them.  Are you so terrified of being wrong? (which is understandable considering the incredible amount of emotion you put into your groundless assertion).

You got to be kidding me, I can think of at least 3 ways and they would all work

So far you haven't shown even ONE solution to the halting problem...now that doesn't seem to stop you from bragging that it is easy and obvious to solve but bragging does seem easier than actually doing anything.

Oh gee I didn't answer the kindergarten math question, that must mean I admit to something

Yawn, perhaps you need to be less emotional about this.  Either you could tell that the machine I described would not work or you could not.  You seemed to be able to tell that it could not work.  It seems easy to prove that it could not work.   Yet, I did not detail it's internal mechanism to you.

So from there you have two choices....live in a world where you can't know that there is no integer X which satisfies X * 3 = 2 unless you know the mechanism of the machine being employed to solve it OR you believe that you do not need to know the mechanism of a machine to determine that it can not work.  QED MoFo.

You have convinced yourself you live in a world of can't do,

What I said about being less emotional applies here too. I simply acknowledge that there exists a set of tasks which can not be done.  These are exceptionally valuable because they can tell you when one approach to something is futile and thus steer you into more productive ways of accomplishing a task.

I know for sure you must be divorced

Because that's not a personal attack. ROFL.

[lumen]

Vague, vague, vague, vague.  Did you major in vagueness?   Is that some subspecialty of engineering these days?How is that different from an emulator?

Do you or do you not concede that an emulator which runs a program would not terminate by virtue of the instructions it is emulating if it was running a program that does not terminate?  If so then do you also concede that an emulator can not solve your problem for an arbitrary program?  If not why - please give considerable detail.

Seriously I've asked you a number of simple and straight-forward questions and you do anything but answer them.  Are you so terrified of being wrong? (which is understandable considering the incredible amount of emotion you put into your groundless assertion).So far you haven't shown even ONE solution to the halting problem...now that doesn't seem to stop you from bragging that it is easy and obvious to solve but bragging does seem easier than actually doing anything.Yawn, perhaps you need to be less emotional about this.  Either you could tell that the machine I described would not work or you could not.  You seemed to be able to tell that it could not work.  It seems easy to prove that it could not work.   Yet, I did not detail it's internal mechanism to you.

So from there you have two choices....live in a world where you can't know that there is no integer X which satisfies X * 3 = 2 unless you know the mechanism of the machine being employed to solve it OR you believe that you do not need to know the mechanism of a machine to determine that it can not work.  QED MoFo.
What I said about being less emotional applies here too. I simply acknowledge that there exists a very valuable set of tasks which can not be done.  These are exceptionally valuable because they can tell you when one approach to something is futile and thus steer you into more productive ways of accomplishing a task.
Because that's not a personal attack. ROFL.

Method 1:

Again, yes like an emulator EXCEPT that the outcome can be predetermined. Meaning that it will not succumb to the hangup or loops or other procedures that you claim will halt the program. The fact is the program will not halt and if it did it's only the program and not the emulator because it read ahead and understood it would halt.

Ok method 2:

You read the next instruction and calculate the clock cycles the instruction will take, then you push the current location to the stack and read them back and save the current address, then set the interrupt controller to interrupt the CPU after these clock cycles. Now no matter what the next instruction does, the CPU will return the control back to the supervisor program that is running. No lockups, no lost loops no divide by zero errors , NO PROBLEM, at this time you can check to see if the program counter is advancing and continue if it is.

Ok Method 3:

You run the code through a decompiler and save the instructions, now the program can run under an interpreter that can test for endless loops or errors and never actually run the code.

Oh, yes you have been a programmer since 14.

Wake up, your dreaming! The fact is someone told you it cannot be done and you just blindly believe them because it's what you want to believe!

Get over it and move on!

[sarkeizen]

Meaning that it will not succumb to the hangup or loops or other procedures that you claim will halt the program. The fact is the program will not halt and if it did it's only the program and not the emulator because it read ahead and understood it would halt.

So it detects that a loop exists and calls code to determine if the loop will halt?  I have asked you this question many, many, many times.

You read the next instruction and calculate the clock cycles the instruction will take, then you push the current location to the stack and read them back and save the current address, then set the interrupt controller to interrupt the CPU after these clock cycles. Now no matter what the next instruction does, the CPU will return the control back to the supervisor program that is running. No lockups, no lost loops no divide by zero errors , NO PROBLEM, at this time you can check to see if the program counter is advancing and continue if it is.

Cart before the horse.  So you have some hardware to initiate a timed non-maskable interrupt. However all that lets you do is alter the path of execution.  You still haven't detected if the program will run infinitely or not.  So this would be valuable only if you had already solved the problem...which you haven't.

You run the code through a decompiler and save the instructions, now the program can run under an interpreter that can test for endless loops or errors and never actually run the code.

Interpreter, decompiler, hypervisor - it doesn't matter.  That still doesn't solve the problem since you still have to - in your words no less - test for endless loops.  Testing for endless loops *IS* the problem.  You can't embed the same problem in your solution and call it solved.  You might as well say that you can create a machine that turn a penny into infinite energy by simply placing infinite energy inside a penny vending machine.

Oh, yes you have been a programmer since 14.

I've written assembly code since I was 14.  I've written code for computers since I was 12. Initially on an HP 9830A on optical cards.

[lumen]

So it detects that a loop exists and calls code to determine if the loop will halt.  I have asked you this question many, many, many times.
Cart before the horse.  So you have some hardware to initiate a non-maskable interrupt. However all that lets you do is alter the path of execution.  You still haven't detected if the program will run infinitely or not.  So this would be valuable only if you had already solved the problem...which you haven't.
Interpreter, decompiler, hypervisor - it doesn't matter.  That still doesn't solve the problem since you still have to - in your words no less - test for endless loops.  Testing for endless loops *IS* the problem.  You can't embed the same problem in your solution and call it solved.  You might as well say that you can create a machine that turn a penny into infinite energy by simply placing infinite energy inside a penny vending machine.
I've written assembly code since I was 14.  I've written code for computers since I was 12.

So if you have done any recent programming, you would know about the priority levels in the current CPU's and even a program under windows cannot halt the CPU. It would be a very easy task for the supervisory program to simply monitor all variables and program counter progress.
It would even be easy to detect infinite loops of any length because it could monitor the progress with shorter and shorter interrupt times until it found no change in any variable or jump conditions. Or even return after every instruction like debug mode.

That's why I say it can be done today. I understand that the point in doing so is not actually the point in indicating why it cannot be done but change is inevitable.

[sarkeizen]

That's why I say it can be done today.

Are you saying that it couldn't be done on a CPU lacking a privileged mode? (e.g. Rings 0,1,2 on the x86)