Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!aplcen!uakari.primate.wisc.edu!ames!uhccux!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation (
Summary: another problem
Message-ID: <2128@munnari.oz.au>
Date: 18 Sep 89 12:43:50 GMT
References: <2353@oakhill.UUCP> <261500010@S34.Prime.COM> <34701@apple.Apple.COM> <31361@ucbvax.BERKELEY.EDU>
Sender: news@cs.mu.oz.au
Lines: 20

There is another problem with memory-mapped I/O instructions; I guess this
site must be losing some messages because I don't recall seeing it mentioned.
If I do
	movb	InputPort, r0
where InputPort is a memory-mapped device port, and then a few instructions
later to
	movb	InputPort, r0
again, I really don't want the second reference to look in the cache and
return whatever the first reference returned.  Presumably the VAX handles
this by ensuring that addresses in the "device" range are never cached.
A simpler approach could be to have I/O instructions.  Note that "memory
mapped I/O" has two faces:
    -- device registers appear as memory locations TO THE CPU
    -- device registers appear as memory locations TO THE BUS
It would be possible to have a machine with special
	input	DeviceAddress, Register
	output	DeviceAddress, Register
instructions which the CPU, cache, and so on "knew" about, but which
appeared ON THE BUS just like memory references that miss the cache.
Whether that would be a good thing is another question again.