gnu@sun.uucp (John Gilmore) (05/14/85)
> Some of us have been considering allowing writes to PC space. The MOVE > instruction with the destination ea of any PC usage is now illegal. This . > means we could easily allow all of the PC modes here. I haven't checked on > the other instructions yet. Unfortunately the 68020 has blown a few instructions here. They use Scc pc@(d) and Scc pc@(d,x) as the TRAPcc instruction. From a quick scan of the 68020 manual, Appendix C, that's the only problem. > 1) MMU systems may have compatibility problems since they may be unprepared > to handle an error on a write to code space. PC-relative writes should generate write cycles to "data space" function codes, since MMU hardware is already set up to handle this properly. The Sun-2 MMU, for example, disallows ALL writes to "program" function codes since they could only happen via "move space" instructions and it was easiest to wire it that way. (It would be a simple change to make it work, but there are thousands of systems out there...) PC-relative reads should probably generate "data" function codes too; if you really want to read from program space, you should be the supervisor and use "move space". (This cleans up a minor security hole in 68000 systems; you can't put executable-but-not-readable code in the same address space as user-changeable code, since the user code could just reae your executable code with PC-relative reads.) In Suns, the only distinction between program and data mapping is in "boot state" where all program fetches come from PROM. There are one or two places during power-up where we use PC-relative reads to access the PROM; these could be changed to Move Spaces without trouble. > 3) Many, indeed most, 68K systems do not make a distinction between code > and data space function codes even if an MMU is utilized. (As an example > the following code will work on these systems: > LEA THIS,An Point to code space item > CLR (an) Clear word there > since the address map is not split between code and data.) Or better said > they doubly map the code space into both code and data space function > codes. This would indicate the additional modes would be allowing > functionality already allowed in most systems anyway. True, users are free to write into their instruction streams using data addressing modes. But they don't -- because the 68000 architecture can do 'most anything without using self-modifying code. I don't want to write to executable locations; the 68020 cache blows that anyway. Rather, I want to write to data locations located with reference to the program counter. At one point we enhanced our assembler to use the most efficient addressing mode to get to a symbolic address. But we had to detune it a little because it was generating PC-relative addresses for writeable operands. In general I like many of the "protections" in the 68000 family, e.g. trapping all invalid instructions. It makes the software more deterministic, and lets you do things like virtual machine emulation. In the case of PC-rel I think at this point that the protection is excessive. It may have been the right decision in the early days to strongly emphasize the difference between program and data spaces; certainly most code written for the 68000 is much cleaner than similar code written for the IBM 360, where the software supported mixing data and programs. This might not have been so without the restriction; then again, maybe the industry has learned something since the 360. Now that it is firmly in our minds, (and in the 68020 cache), I think we can let the microcode relax and let us write to PC-relative locations.