Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-unix!hplabs!sdcrdcf!usc-oberon!castor.usc.edu!blarson
From: blarson@castor.usc.edu.UUCP
Newsgroups: comp.sys.m68k
Subject: Re: move sr/move ccr: crock
Message-ID: <517@castor.usc.edu>
Date: Fri, 23-Jan-87 20:43:24 EST
Article-I.D.: castor.517
Posted: Fri Jan 23 20:43:24 1987
Date-Received: Sat, 24-Jan-87 20:00:52 EST
References: <809@imagen.UUCP>
Reply-To: blarson@castor.usc.edu.UUCP (Bob Larson)
Organization: USC AIS, Los Angeles
Lines: 20
Keywords: logic?

In article <809@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes:
>In the 68000, the move from sr instruction is not a privileged
>instruction.  In the 68010 and 68020 a new instruction exists,
>move from ccr, which just moves the condition codes out of the
>SR, the other bits being zero.  In the 68010 and 68020 move from
>SR is a privileged instruction.
[...]
>My question is why the lords of 68000-land did this?

The 68k manuals say this was to allow virtual machine type operating
systems to be emplemented.  This by itself is not a bad idea, but I
think it should have been implemented by making the move ccr
instruction on the 68010 and 68020 have the same opcode as the 68000
move sr instruction.  This way only programs using the upper byte of
the sr would need to be changed.  (Mainly OS's.)
-- 
Bob Larson
Arpa: Blarson@Usc-Eclb.Arpa
Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson
			seismo!cit-vax!usc-oberon!castor.usc.edu!blarson