Quote:
Originally Posted by meynaf
Moving data on the 68k works like TST'ing it, which is like CMP'ing it with zero. A side-effect of this, is that overflow and carry always get cleared (because CMP with 0 can't set them).
Check what MOVE+BLE (or BGT) combination could do if MOVE didn't clear V.
The MOVE SR instruction isn't for just saving the state of arithmetic flags - it touches the whole SR.
On 68010 was created MOVE CCR for the arithmetic flags.
68k code can be PIC if you write it to be so. Like x86 code can be not PIC if you write it to don't be so. I don't see why you insist on seeing an advantage where there is none.
You say some instructions can't be used there, but i don't see any. So, examples please.
In many cases i just don't have any C source.
|
Thank you. Your explanation gives some sense for the MOVE behaviors with flags. However they are unique and look really strange. IMHO it prevents compiler to mix instructions to get code executing faster on several ALUs simultaneously.
You have written
Now let's consider what happens if the hosted program saves SR for whatever reason, then restores it. We are speaking only about reading! Indeed the restoration of SR should be privileged and it was privileged.
PIC. Sorry I again should repeat the same thing.
When you write a COM-program you don't need to be aware of anything but size of the segments - you get PIC automatically. BTW I have some experience of work with experimental high-performance hardware based on Xilinx Microblaze variant without MMU. People wanted to run Minix with it so they just added two segment registers (for code and data) into hardware and using them they got PIC for every Minix program. Minix works with this system with this cheap and easy trick. It was possible to run even Linux this way but Linux uses MMU too often and this trick will often slow down performance too much. For 68k you should write your code in a special way.
Without C-sources it will be almost impossible to organize a contest.