quentron.com

[lumen]

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?

This does change the situation, and though the arbitrary program will be executed (one instruction at a time) on the actual CPU, the outcome of each instruction was already predetermined.

This changes the situation because the arbitrary program is not considered a program, but data to the preservation program, even though the data will run on the CPU and produce the same results, the outcome has changed in that once a determination is made (the program completes or not) the preservation program is still in control.

This is almost like a modern CPU where the programs run at a secondary level and could be considered merely data, though they do run and produce data and output, if they run out of bounds or become an infinite loop, they are simply terminated. (was that a program or data?)

In the end one can only argue that the theory holds true because the arbitrary program never ran at an equal level, but then it did run and did produce the same outcome, only now the results would be known. One might say, "now the results of actually running it", are known. (though it actually already ran)

Is this possible, YES. Does it prevent the program from halting and produce data, YES.
Does it violate the halting program theory?, depends on how you view it.

[sarkeizen]

This does change the situation, and though the arbitrary program will be executed (one instruction at a time) on the actual CPU, the outcome of each instruction was already predetermined.

This changes the situation because the arbitrary program is not considered a program, but data to the preservation program

Well first I'd like to offer my condolences for the recent and severe head trauma you suffered yesterday..as that's probably the most likely reason for your posting.

A few notes: Please only use one term to refer to the thing being described.  The byte-code interpreter is the thing being discussed.  Don't call it five different names.  Second don't anthropomorphize, "considered" is not a instruction on this processor.  There is no language construct which "considers" anything.

All I've suggested and you somehow, through a huge amount of effort got confused over....is that the byte-code interpreter - is a program and for the purposes of clarity - can be called with parameters.  If it couldn't then one wonders how you expected it to ininterpret with any byte-coded program.  The byte-code interpreter must somehow FIND the byte-code of the program we wish for it to interpret.  So at some point it must, somewhere, at some time have an address of the byte-code being executed.  Even if it simply has this stored on the stack.  Remember you said this runs on ANY CPU AT ALL and the one were discussing has no interrupts.  So in order for your byte-code interpreter to actually do anything.  It at least has to know where the byte-code it's interpreting is.

Now think again, does adding four or five instructions (the call overhead) to your program radically alter it?

[lumen]

Well first I'd like to offer my condolences for the recent and severe head trauma you suffered yesterday..as that's probably the most likely reason for your posting.

A few notes: Please only use one term to refer to the thing being described.  The byte-code interpreter is the thing being discussed.  Don't call it five different names.  Second don't anthropomorphize, "considered" is not a instruction on this processor.  There is no language construct which "considers" anything.

All I've suggested and you somehow, through a huge amount of effort got confused over....is that the byte-code interpreter - is a program and for the purposes of clarity - can be called with parameters.  If it couldn't then one wonders how you expected it to ininterpret with any byte-coded program.  The byte-code interpreter must somehow FIND the byte-code of the program we wish for it to interpret.  So at some point it must, somewhere, at some time have an address of the byte-code being executed.  Even if it simply has this stored on the stack.  Remember you said this runs on ANY CPU AT ALL and the one were discussing has no interrupts.  So in order for your byte-code interpreter to actually do anything.  It at least has to know where the byte-code it's interpreting is.

Now think again, does adding four or five instructions (the call overhead) to your program radically alter it?

It can indeed be setup exactly as you stated.

It can be called as a sub function by passing parameters ( a pointer to the data) and the interpreter can read the data and operate on it.

The view you are taking is a view of another sub process running under control of yet another process, but it would make no difference.

I was viewing it as a much smaller CPU with the code interpreter in bank switched shadowed ROM, to give the arbitrary program code all the resources of the CPU, but either way the safety of the interpreter can still be maintained.
Usually in these smaller CPUs, the execution start point is simply a predetermined point in memory where the program is loaded.

I changed the term of the interpreter because you seem to want to consider this interpreter program just as any normal interpreter, and that cannot do the task because a simple interpreter does nothing more than run a program. (offers no control over the programs action or inaction)

[sarkeizen]

It can indeed be setup exactly as you stated.

It can be called as a sub function by passing parameters ( a pointer to the data) and the interpreter can read the data and operate on it.
The view you are taking is a view of another sub process running under control of yet another process, but it would make no difference.

No not really - again I stress that reading is important and you should try taking the job more seriously at some point in your life.  I'm not really talking about multiple processes.  Just that the code for the byte-code interpreter can be called as a function.

I was viewing it as a much smaller CPU with the code interpreter in bank switched shadowed ROM, to give the arbitrary program code all the resources of the CPU, but either way the safety of the interpreter can still be maintained.

Needless detail.   From the start we have been talking about a program which can determine if an arbitrary program will terminate.  Clearly the program which determines of an arbitrary program will terminate will consume memory.

Usually in these smaller CPUs, the execution start point is simply a predetermined point in memory where the program is loaded.

Depends Again you're being vague, do you mean the power on execution point?  In some CPU's that might be a fixed point or a semi-static point stored in an eeprom, on general purpose CPUS it's more frequently a fixed vector i.e. 6502 ($FFFE-$FFFF), 8086 ($FFFF:0000), 68000 ($0) on more modern x86 PCs the BIOS takes care of the boot into real-mode at $FFFF:0000 and then sets up protected mode for the OS.

I changed the term of the interpreter because you seem to want to consider this interpreter program just as any normal interpreter, and that cannot do the task because a simple interpreter does nothing more than run a program. (offers no control over the programs action or inaction)

Spoken like someone who's never written an interpreter.  Kind of sad if you ask me; 30 years of programming and you've never implemented an entire language.  Most interpreters do not simply run a program.  Interpreters have to interface with the operating system, allocate memory, perform bounds checking, type checking and sometimes task switching.  Before you go nuts again, I'll just point out that I'm not saying your interpreter must do these things but rather I'm illustrating that interpreters, as a rule offer control over the program's action.

So now you agree that I can call:

WillThisEnd(program,data)

Since the data, is a pointer to a series of bytes and as you said your byte-code interpreter will "allow ANY pile of garbage to run through the CPU doing whatever to memory" we can pass the same pointer to both parameters without changing how well your program predicts termination.

e.g.:

{
data = program;
WillThisEnd(program,data)
}

Will tell you if "program" will end when it is fed with it's own binary image as "data".

[lumen]

No not really - again I stress that reading is important and you should try taking the job more seriously at some point in your life.  I'm not really talking about multiple processes.  Just that the code for the byte-code interpreter can be called as a function.

As I said:

"It can be called as a sub function by passing parameters ( a pointer to the data) and the interpreter can read the data and operate on it."

So now you agree that I can call:

WillThisEnd(program,data)

Since the data, is a pointer to a series of bytes and as you said your byte-code interpreter will "allow ANY pile of garbage to run through the CPU doing whatever to memory" we can pass the same pointer to both parameters without changing how well your program predicts termination.

e.g.:

{
data = program;
WillThisEnd(program,data)
}

Will tell you if "program" will end when it is fed with it's own binary image as "data".

Yes you can, and it will report that it will not end because it will not end without something ending it.

Of course if you need this to be detected, then it's possible also.
With your knowledge of programming, you should already be thinking of how to do it, not how can I show it cannot be done.

You should already know that to the programmer, if something cannot be done, then the program needs to be changed so it can.

It stands to reason that anything that anyone does on a CPU can also be undone on the CPU.