Path: utzoo!attcan!uunet!husc6!uwvax!oddjob!ncar!noao!mcdsun!nud!tom
From: tom@nud.UUCP (Tom Armistead)
Newsgroups: comp.arch
Subject: Re: architecture/implementation -- 88000
Message-ID: <798@nud.UUCP>
Date: 25 May 88 21:06:24 GMT
References: <2232@gumby.mips.COM>
Reply-To: tom@nud.UUCP (Tom Armistead)
Organization: Motorola Microcomputer Division, Tempe, Az.
Lines: 47

In article <2232@gumby.mips.COM> earl@mips.COM (Earl Killian) writes:
>
>Describe other unique or interesting features of the architecture or
>its implementation.
>E.g. describe the functional units, with emphasis on non-standard
>units.

    Some other features I think were missed in the original posting:

    It has bit field instructions.  (I'm not aware of other RISC processors
with this feature).

    Support for multiprocessing via cache coherency features of cache
chip.

    Support for fault tolerant applications.

    
>The instruction and data pipelines are exposed to software.  Exception
>handling involves a lot of overhead; the code has to deal with up to
>six outstanding user page faults and up to nine outstanding floating

    Actually only 5 page faults and handling just 4 of them is sufficient
and optimum for performance.

>point exceptions.  You can't just duck in and out of a device interrupt
>routine and then return with RTE.

    You can write the exception handlers to process the interrupt first
(if interrupt latency is important) before any page faults/FP exceptions
are handled.  The page faults/FP exception handling doesn't have to be done
on every interrupt either - only those faults that occur simultaneously with
the interrupt need to be handled simultaneously.  Simultaneous exceptions/
interrupts are relatively rare in comparison to interrupts that occur without
any other pending exceptions. 

    The FP exceptions can also be ignored until RTE if needed.  However, this
means your interrupt handler cannot use FP (including integer multiply and
divide).  If you can make this restriction (or guarantee no FP exceptions)
and if you can guarantee no page faults, you can indeed "duck in and out and
then RTE" with an 88K interrupt handler. 

    How about a comp.sys.m88k (or equivalent)?
-- 
Just a few more bits in the stream.

The Sneek