From: rsrodger@wam.umd.edu (Yamanari)
Subject: Re: If things had been different... (was: FCC etc)
Organization: University of Maryland, College Park
Date: Tue, 5 Jan 1993 21:04:24 GMT

In article <1icr5gINNgh2@shelley.u.washington.edu> tzs@carson.u.washington.edu (Tim Smith) writes:
>rsrodger@wam.umd.edu (Yamanari) writes, on why there will be a 68060 but
>no 68050:
>>			Exactly. Marketroids.
>
>Actually, 68060 is the logical next number.  If the number/10 is off, the
>new CPU is a major new version.  If it is even, it is not.  The 010, 008,
>and 012 were not that different from the 000.  The 020 was a big step up.
>The 030 basically just puts the MMU on chip.  The 040 is very different
>inside.  If the next one is also totally different inside, it should be
>the 060, not the 050.


	Do you actually believe this?  This is the same glop Motorola
	has been spewing in Byte magazine and elsewhere.  It's clever, but
	it doesn't match the numbering system for their other processing
	lines (and it only matches the 68k line because it was crafted
	to do so).  

	Marketing.  Motorola is a little ashamed (rightfully) at the 
	delay in getting out even just a faster '040, let alone the 
	*huge* delay for the '050.  


>[About code that used the upper 8 bits of an address, because 68000 had
> 24 bit addressing]
>>
>>	All code that practiced this broke under the 68010.
>
>The 010 still only had 24 bit addressing, so I don't think that broke code
>that did this.  The 68012 has 30 bits of address, so code would have broke
>on it.  Maybe that's what you were thinking of?


	Perhaps I'm remembering incorrectly.  I used to write for the
	Amiga and I practiced this little diddy myself.  I remember my programs
	breaking when I pulled out the 68000 and dropped in a '010, so
	I'm almost certain that they broke for some reason.  Although,
	soon after I went with an '020--maybe I'm just befuddled on this one.


>>	2.  Many SW programs used an incompatible means of accessing
>>	the SR (might be wrong--I haven't thought about this in 
>>	years) registers through supervisor mode.  These programs broke
>>	in the transition from 68000 to 68010.
>
>If I recall correctly, the problem was that the condition codes were in
>half of the status register.  Code that wanted to set condition codes
>directly did so via a move to SR.  This became priveledge on the 68010,
>and a new move to CCR instruction was added for user-mode access to the
>condition code half of the status register.  Thus user-mode code that
>tried to directly set the condition codes would trap.


	Right.  Thanks for a better description.


>However, I seem to recall that the OS could catch this and simulate it
>for the user code.  Thus, this change only broke user code if the OS didn't
>want to do this.


	Not quite.  We had something on the Amiga called Decigel and
	SuperDecigel.  They worked (for the most part) for programs that
	ran under Amigados (they also slowed them down by about 12%).  
	Didn't work with most games, though.

	I think Macs actually had more troubles with this, but most
	Mac users took it all at once--you didn't see them opening up
	their machines to drop in a 68010 for the measily (what, 5-15%?) 
	performance increase that it got them (besides, were the socketed
	on the Mac?).  But at 7.14mhz, the Amiga was already the slow kid on
	the block.

	(Still multitasked better than my '486 under OS/2, though.)

-- 
      Blaming "society" for your problems is like blaming clouds for rain.
 ---  boycott == coercion == censorship == closed mindedness == cowardice  ---
	      "Psalms 23:1  The LORD is my shepherd; I shall not want."  
		Shepherds are for sheep.   -----      Pain teaches.
Newsgroups: comp.os.os2.advocacy,comp.os.ms-windows.advocacy