How to move AROS forward

[A6000]

When the CPU reads a memory location or a block of memory, it fetches something like this:-
1011001 11001100 11101010 00110110 01101111 00001110

the only way to interpret this "data" is to know what the CPU is expecting.

HenryCase wrote:
I would like to pick up on one point which has been stated by you both in the past, which is that there isn't a way to distinguish between instructions and data.

Every program has a start point and the CPU knows this start address WILL be an instruction (opcode) but the second byte maybe another opcode or it could be data.

According to Wikipedia, the following four steps are used in classical CPU architecture: fetch, decode, execute, writeback. The second step 'decode' is of interest to us here. Again, according to Wikipedia:
.....
So for even the most basic program to function the CPU must know the difference between the opcode part of the instruction and the operand part of the instruction. Can we agree on that at least?

So the only way for the operating system to know if a byte contains an opcode or data is to emulate the cpu in software and follow the execution of the program from the start, which will be very slow, it cannot simply read a byte and know whether it has fetched an opcode or data.

[A6000]

Variable length instructions are no problem, they are fully documented, if the CPU expects the next byte to be an opcode, that opcode will be decoded and reveal if the following byte is also an opcode.
I think 68k instructions range from 1 to 16 bytes including operands where applicable.

[A6000]

HenryCase wrote:
@pkillo
Thanks for your examples, I enjoyed following them. In your imaginary computer how does the CPU know when to increase the Program Counter?

The program counter is automatically incremented after every instruction execution.

One fly in the ointment for your idea of tracing program execution is that data may not be static, it might be input in real time to change program flow, or data might come from another part of the program which only executes if certain conditions are met, dependant on real world input, or data may come from another program entirely.
You may need to log all input data just in case the program you are tracing needs the data that came in during the trace time. it's all getting quite complicated.
You may not know the data found at the memory location is invalid.

[A6000]

Just checked, 68k instructions range from 2 to 10 bytes, though I vaguely recall that instructions relating to co-processors such as the FPU may use up to 16 bytes.

[A6000]

HenryCase wrote:
I won't ask for 'any ideas' on this matter as I know I'll just get the usual 'it can't be done' stuff, and I'd much rather have a better explanation than that.

I don't know enough about programming to say it is impossible, but I can see it won't be easy.

Sandboxes have been mentioned several times, maybe this would be easier.
And just how important is memory protection anyway? we managed without it for a quarter of a century.

[A6000]

HenryCase wrote:
@A6000 and @SamuraiCrow

If 68k opcodes are 2-10 bytes in length, and one opcode can be directly followed by another opcode (i.e. no data in between) how does the instruction code tell the CPU to expect an opcode rather than operand data? Is there an opcode 'flag' instruction, or is it purely determined by the current opcode in use (and its operand needs)?

When the processor completes an instruction it increments the program counter and fetches the next instruction, the word (2 bytes) returned will specify the instruction, if the instruction requires operands the next 2,4 or 8 bytes will tell the CPU where to get it's operands from. these additional bytes will be immediate data, registers or memory locations, source and destination.