rokicki@Neon.Stanford.EDU (Tomas G. Rokicki) (01/10/90)
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. > 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. > 2) A stock Amiga equiped with a 68010 is *not* object code compatible > at the user level. A patch is required (the famous DeciGel). A patch is only required to run certain brain-dead software that does not follow the Commodore-Amiga guidelines (ie, use the system call GetCC() to get the condition codes, rather than Move SR.) > 3) Commodore-Amiga does not sell the needed patch. There is no offical > support for the patch. Commodore Amiga has no responsibility to support software that breaks the rules. Any software that needs the patch has broken the rules. Very few packages are affected at all. > Therefore, "Amiga does not support the 68010". Sorry. Amiga supports the 68000, 68010, 68020, and 68030. > 5) I have taken programs written for the XT written before the > advent of '286 & '386 and run them on AT and 386-clones. They all > run with no problems (except for Video or other hardwares). In fact, > the earliest versions of MS-DOS runs on all machines. Furthure, any > combination of {program-version, DOS-version} that runs on any > machine should run on all machines. 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.) 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
schow@bcarh185.bnr.ca (Stanley T.H. Chow) (01/13/90)
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.
daveh@cbmvax.commodore.com (Dave Haynie) (01/16/90)
in article <1650@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) says: >>> 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? The only possible problem you can have with the 68010 is with the MOVE SR,<ea> instruction. The use of this instruction is not supported by Commodore, and an equivalent operating system call has been available since before the OS shipped. Any program the breaks with the 68010, just as any program that breaks under 1.3, or breaks with FAST memory, or just plain crashes, has a bug. If Commodore wrote that program, I'd suggest contacting them. If someone else wrote that program, you should contact them instead. You know this. You've been told this over and over again. Continuing to argue a point you're already lost is doing nothing more that showing everyone on the net your ignorance. >>-tom > Stanley Chow BitNet: schow@BNR.CA -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough