don@gp.govt.nz (Don Stokes) (05/25/90)
In article <1990May24.113025.7041@xavax.com>, alvitar@xavax.com (Phillip Harbison) writes: > In article <20058@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: >> So I finally figured it out: one of the supervisor's new >> responsibilities as of the 68010 was to trap and emulate the MOVE >> SR,<dest> instruction, and then the user model would be complete. >> ... >> If only Motorola had TOLD us this, way back when the 68010 was >> introduced... :-) > > If you had bothered to read their application notes, you would know > that they did make the MOVE SR change and solution known. Under > duress, I'll dig up the documentation and cite chapter and verse. > I recall seeing Motorola documentation justifying the design change > (to support their virtual machine concept) and explaining how the > supervisor code could make the user code happy, and this was just > after the 68010 was introduced. MC68020 32-Bit Microprocessor User's Manual, Second Edition (ISBN 0-13-655860-3 01 {Prentice-Hall edition}), chapter 1, section 1.3.2 "Virtual Machine", para 2 (page 1-8): In order to fully support a virtual machine, the MC68020 must protect the supervisor resources from access by user programs. The only supervisor resource that is not protected on the MC68000 and MC68008 is the system byte of the status register. On the MC68000 and MC68008, the MOVE from SR instruction allows user programs to test the S bit in the status register (in addition to the T bits and interrupt mask) and thus determine that they are running in the user mode. For full virtual machine support, an operating system must not be aware of the fact that it is running in the less privileged user mode, and thus should not be allowed direct access to the S bit. For this reason, the MOVE from SR instruction on the MC68010, MC68012 and MC68020 is a privileged instruction and the MOVE from CCR (condition code register) instruction is available to allow user programs direct access to the condition codes. By making the MOVE from SR instruction privileged, when the new operating system attempts to access the system byte of the status register, a trap to the governing operating system will occur, where the operation can be emulated. So there we have it; the last word on the "why did Motorola break the 68000" question. Quoted without permission. Don Stokes, ZL2TNM / / PSI%(5301)47000028::DON Systems Programmer /GP/ Government Printing Office Postmaster@gp.govt.nz ____________________/ /__Wellington__New_Zealand________________don@gp.govt.nz Badness comes in waves.
jgk@demo.COM (Joe Keane) (05/26/90)
In article <20073@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: >Of course, Commodore always says "we always told you not to use MOVE SR! >If you used it, it's your fault you broke!" Well, I might suggest to >Commodore and any other computer maker (and I must include chip makers >too I suppose) that's listening: programmers will never ever universally >"follow the rules", unless by not doing so their programs don't work. >You can blame us all you want, and I won't say you're not justified. >But if you really want programmers to follow rules, those rules had >better be enforced *now*. I think this is a ridiculous argument. How is Commodore supposed to enforce a restriction on using a _user instruction_? They said clearly you should not use it; there's nothing more they can do. If a programmer uses it, he's an idiot. He can't use the excuse that it's a special case, or his compiler put it out. He _specifically_ wrote MOVE SR when he knew he shouldn't have. When it breaks in the 68010 i have _zero_ sympathy for him; he got exactly what he deserves.