[ACCEPTED]-How instructions are differentiated from data?-cpu-architecture

Simple answer - it doesn't. Machine code 9 instructions are just binary numbers, as 8 are data. More complicated answer - your 7 processor may (or may not) provide segmentation 6 of memory, meaning that attempting to execute 5 what has been specified as data causes a 4 trap of some sort. This is one of the the 3 meaning of a "segmentation fault" - the 2 processor tried to execute something that 1 was not labelled as being executable code.

Each opcode will consist of an instruction 21 of N bytes, which then expects the subsequent 20 M bytes to be data (memory pointers etc.). So 19 the CPU uses each opcode to determine how 18 manyof the following bytes are data.

Certainly 17 for old processors (e.g. old 8-bit types 16 such as 6502 and the like) there was no 15 differentiation. You would normally point 14 the program counter to the beginning of 13 the program in memory and that would reference 12 data from somewhere else in memory, but 11 program/data were stored as simple 8-bit 10 values. The processor itself couldn't differentiate 9 between the two.

It was perfectly possible 8 to point the program counter at what had 7 deemed as data, and in fact I remember an 6 old college tutorial where my professor 5 did exactly that, and we had to point the mistake 4 out to him. His response was "but that's 3 data! It can't execute that! Can it?", at 2 which point I populated our data with valid 1 opcodes to prove that, indeed, it could.

The original ARM design had a three-stage 10 pipeline for executing instructions:

1. FETCH the instruction into the CPU
2. DECODE the instruction to configure the CPU for execution
3. EXECUTE the instruction.

The 9 CPU's internal logic ensures that it knows 8 whether it is fetching data in stage 1 (i.e. an 7 instruction fetch), or in stage 3 (i.e. a 6 data fetch due to a "load" instruction).

Modern 5 ARM processors have a separate bus for fetching 4 instructions (so the pipeline doesn't stall 3 while fetching data), and a longer pipeline 2 (to allow faster clock speeds), but the 1 general idea is still the same.

Each read by the processor is known to be 21 a data fetch or an instruction fetch. All 20 processors old and new know their instruction 19 fetches from data fetches. From the outside 18 you may or may not be able to tell, usually 17 not except for harvard architecture processors 16 of course, which the ARM is not. I have 15 been working with the mpcore (ARM11) lately 14 and there are bits on the external interface 13 that tell you a little about what kind of 12 read it is, mostly to hook up an external 11 cache, combine that with knowledge of if 10 you have the mmu and L1 cache on and you 9 can tell data from instruction, but that 8 is the exception to the rule. From a memory 7 bus perspective it is just data bits you 6 dont know data from instruction, but the 5 logic that initiated that memory cycle and 4 is waiting for the result knew before it 3 started the cycle what kind of fetch it 2 was and what it is going to do with that 1 data when it gets it.

I think its down to where the data is stored 22 in the program and OS support for informing 21 the CPU whether it is code or data.

All code 20 is placed in different segment of the image 19 (along with static data like constant character 18 strings) compared to storage for variables. The 17 OS (and memory management unit) need to 16 know this because they can swap code out 15 of memory by simply discarding it and reloading 14 it from the original disk file (at least 13 that's how Windows does it).

So, I think 12 the CPU 'knows' whether memory is data or 11 code. No doubt the modern pipeling CPUs 10 we have now also have instructions to read 9 this memory differently to assist the CPU 8 is processing it as fast as possible (eg 7 code may not be cached, data will always 6 be accessed randomly rather than in a stream)

Its 5 still possible to point your program counter 4 at data, but the OS can tell the CPU to 3 prevent this - see NX bit and Windows' "Data 2 Execution Protection" settings (system control 1 panel)