Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!bnrgate!bnr-fos!bigsur!bnr-rsc!bcarh185!schow From: schow@bcarh185.bnr.ca (Stanley T.H. Chow) Newsgroups: comp.sys.amiga Subject: Re: Stanley Chow Message-ID: <1650@bnr-rsc.UUCP> Date: 12 Jan 90 21:52:58 GMT References: <1990Jan10.071333.23967@Neon.Stanford.EDU> Sender: news@bnr-rsc.UUCP Reply-To: bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) Organization: BNR Ottawa, Canada Lines: 97 Summary: Followup-To: Keywords: In article <1990Jan10.071333.23967@Neon.Stanford.EDU> rokicki@Neon.Stanford.EDU (Tomas G. Rokicki) writes: Wow, I must be really (in)famous to occupy a whole Subject :-) >Nice try. You seem to have a massive misunderstanding of the >MOVE SR instruction. This instruction moves the status register >*to* a data register. It cannot be used to enter supervisor mode; >it can only be used to observe whether you are in supervisor mode >or not. Thus, the 68000 only `fails' as a virtual machine when >you are running code that must (and counts on) determining whether >or not it is running supervisor or not---such code as an operating >system. User programs should not (and do not, by and large) use >this instruction. Tom, I really like some of the stuff you have writen for the Amiga but you seem to be disagreeing with Motorola: "In order to fully support a virtual machine, the MC68010/MC68012 must protect the supervisor resources from access by user programs. The one supervisor resource that is not fully protected in the MC68000 is the sytem byte of the status register. In the MC68000 and MC68008, the MOVE from SR instruction allows user programs to test the S bit (in addition to the T bit and interrupt maks) and thus determine that they are running in the user mode. For full virtual machine support, a new operating system must not be aware of the fact that it is running in the user mode and thus should not be allowed to access the S bit. For this reason the MOVE from SR instruction has been added to allow user program unhindered access to the conditions. By making the MOVE from SR instruction priviledged, when the new operating system attempts to access the S bit, a trap to the governing system will have the S bit set." Pages 1-8 & 1-9 of "M68000 Programmer's Reference Manual" fifth editon. [Note that I am quoting nothing but Motorola manuals. This is my bid to avoid being called Motorola-bashing. I am sure many other people will be ready to supply other sources of information.] > >> 1) A machine base on the 68K family can be made to be Object Code >> Compatible at the User level. This means the operating system must >> be changed/patched to handle the MOVE SR case. > >True, except that 99% of the software (and certainly all productivity >software) does not use MOVE from SR, so there is no problem. At least 99% of time (and certinaly all working hours), I am not having sex, so I am still a virgin. Your argument may have merit if Motorola was claiming "99% Object Code Compatible". Please quote chapter and verse. >> Therefore, "Amiga does not support the 68010". > >Sorry. Amiga supports the 68000, 68010, 68020, and 68030. You mean I can drop a '010 into my Amiga (or have my dealer do it) and when I have a problem, I can call Commodore-Amiga for support? This is extremely good news. Can someone at Commodore confirm this please? >BFD. Most of the Amiga software written in '85 that followed the written >guidelines works like a charm, even despite radical changes in the >operating system. On the IBM, on the other hand, programs written for the >early PC fail badly on modern PCs (mostly due to the new hierarchical file >system.) There you go again, comparing software systems. I was talking about bugs in processors. > >Stanley, it really seems like you are picking a fight from a point of very >shallow knowledge. Yes, you did read the books, but did you understand >them? Relax a little, my man. > >-tom You are right, I was "winding people up" (an English expression that I just picked up recently). Watching people come up with incoherant flames to technically correct arguments is one way to spend the winter hours :-) Of course I mean the *other* flames, not you. I assure you that I understand the technical points. What is more, I seem to understand the *subtle* implications of the questions a whole lot more than many of the people on the net. [See, I just snuck in yet another atomic-powered flame generator. Gotta keep comp.sys.amiga usage up.] Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow (613) 763-2831 ..!utgpu!bnr-vpa!bnr-rsc!schow%bcarh185 Me? Represent other people? Don't make them laugh so hard.