For Step 7, inspection of the code on my PC, the code on the memory card and the code in the work memory of the CPU shows it to be all the same (MC7) - my inference is that it is interpreted.
I don't think so. One can't interpret code and get the speeds Siemens claims. My impression is that there is a S7 CPU that runs the S7 STL instruction set. The S7 CPU can be easily implemented in a FPGA. However Siemens has silicon chip manufacturing facilities so it easy for them to just make their own CPU. The S7 CPU is rather crude compared to most other CPUs.
Also, there would be little point in compiling LAD or SCL code to STL unless STL was the native instructions set.
The big thing a PLC CPU must do is to be able to test and change individual bits efficiently. This is something that most modern day RISC type CPU don't do well because there are no instructions for directly accessing one bit in memory. It is clear the S7 CPU was designed to access bits in memory given that when the pointers are incremented by 1 the increment is only 1 bit.
Finally, if the S7 is a virtual CPU I would have designed it to be much different than the kludge that Siemens came up with. The S7 CPU design obviously to silicon constraints and complexity into account when designing it in the early 1990s. A virtual CPU can be very clean and simple. I would choose a stack based virtual machine and the stack would be mapped into any available registers the the real CPU has.
I am pretty sure the first Control Logix CPUs were ARM based. They were made by LSI. By now I am pretty sure Rockwell would have taken making the CPUs in house and augmented the basic ARM instruction set with some bit accessing instructions. Rockwell, doesn't have anything that looks like assembly language so I am very sure they compile down to native code.
Our motion controller has been using a virtual CPU so we can run the same code on two different micro controllers. We download compiled code for the virtual CPU but this code is executed by getting an instruction, using the instruction to index into a table of pointers, jump to the code that is pointed to, execute it and return for the next instruction. Our virtual CPU is stack based and the stack can have any kind of item on it like pointers, REALs, DINTs, and DWORDs. We do not have the two register limit that the S7 does nor must we shuffle pointers through an accumulator.
Our next generation of compiler will generate native machine code and it will use the stack much like any other modern compiler with a frame pointer to access local variables. Actually we have the frame pointer part now. What I hope to do is to make the stack as virtual as possible and map the stack into the registers so that the when accessing variables on the stack it can get one of the top 8 or 16 variable out of memory. Our CPU has 32 registers so I don't have to be stinggy with register allocation. Originally our CPU was much faster than the Control Logix or S7 so we could afford to use a virtual CPU and be faster but now the competition has caught up and they didn't do that by interpreting code.
If you really want to know more about this topic then look at this pdf
http://www.2shared.com/document/JSZCQJq6/A_Compact_Guide_To_Lex__Yacc_-.html
It has an example of a simple interpreter and compiler. This is one of the best texts and examples I have found on the internet. It is like the final project of a year long compiler writing course but it is easy to follow. One can see that both the interpreter and compiler parse down to tokens which are then used to go to the right place in a case or switch table. It is the code in the switch table that determines if the code is being interpreted or compiled. In the compiled example the compiler generates a simple assembly language but it could output machine code too so the assembler pass could be skipped.
