Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!uunet!mcsun!hp4nl!philapd!ssp11!dolf
From: dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer)
Newsgroups: comp.arch
Subject: Re: unexpected CPU behavior [was 486 bugs -- it's in there!]
Message-ID: <756@ssp11.idca.tds.philips.nl>
Date: 28 May 90 07:00:52 GMT
References: <1990May27.110726.17007@xavax.com> <AGLEW.90May27215556@dwarfs.csg.uiuc.edu>
Organization: Philips Information Systems, Apeldoorn, The Netherlands
Lines: 21

In article <AGLEW.90May27215556@dwarfs.csg.uiuc.edu> aglew@dwarfs.csg.uiuc.edu (Andy Glew) writes:
<..> Motorola's 68000 clr instruction quirk that read the addressed
<..> location before clearing it - causing problems for active
<..> memory mapped I/O locations.
<
<Comment: isn't this the sort of thing that comes with using the same
<instructions for I/O access as for memory?  For memory access all we
<care about is the data returned or written - for I/O you have to
<specify exactly what bus transactions are used.
<[..deleted..]
<case, for memory mapped I/O you might expect the memory controller to
<handle the active memory locations specially - but isn't it possible
<that a special I/O instruction might make the distinction more easily?

Obviously yes, but if you don't want to program in assembler how do you tell
the difference to your (pre-ANSI C) compiler ? 
-- 
Dolf Grunbauer      Tel: +31 55 433233 Internet dolf@idca.tds.philips.nl
Philips Information Systems            UUCP     ...!mcsun!philapd!dolf
Dept. BS Software,  P.O. Box 245, 7300 AE Apeldoorn, The Netherlands 
read: error in reading .signature