This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: m68k problem and libstdc++


Richard Henderson <rth@redhat.com> writes:

> On Thu, Jan 03, 2002 at 07:55:03PM -0500, Craig Rodrigues wrote:
> > I'm not a 68000 asm expert.  Does anyone have an idea as
> > to what the fix could be?
> 
> Some preprocessor hackery and or configure hackery.
> 
> Virtually all real operating systems don't support anything less
> than 68020, because that's the first one that had a built-in mmu.
> There are some very antiquated exceptions which are notable only
> in the amazing jumped through to bolt an mmu on the side.

Actually it was the 68030 that was first to have a built-in MMU.  The
68020 was designed to make use of an optional external MMU which used
the coprocessor interface; Motorola made one called the 68851.
However, you didn't have to use that one; 68020-based Sun 3s used a
Sun-designed MMU, and the Macintosh II was sold with a dumbed-down MMU
whose name escapes me.

The 68000 could not even restart an instruction that triggered an bus
error exception, which was the real reason for those weird dual 68000
arrangements for supporting paging, like on the earliest Sun 1s.
However, the 68010 could restart such instructions, so it was easier
to support real OS's on it.  Most Sun 1s and all Sun 2s used the
68010, again with a Sun-designed MMU.  The 68010 still didn't have the
coprocessor interface provided on the 68020.  I suppose the MMU was
memory-mapped and controlled like an I/O device, by writing to special
memory addresses.

By the way, the 68000 and 68010 do have an instruction for atomic
memory operations which can be used for multiprocessor
synchronization: TAS (test-and-set).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]