Xref: utzoo comp.arch:17157 comp.sys.intel:1293
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!uakari.primate.wisc.edu!uflorida!mephisto!mcnc!thorin!rudolph.cs.unc.edu!leech
From: leech@rudolph.cs.unc.edu
Newsgroups: comp.arch,comp.sys.intel
Subject: i860 flush instruction obscurities - HELP!
Message-ID: <15194@thorin.cs.unc.edu>
Date: 16 Jul 90 19:13:38 GMT
Sender: news@thorin.cs.unc.edu
Reply-To: leech@rudolph.cs.unc.edu ()
Organization: University Of North Carolina, Chapel Hill
Lines: 44
Expires:
References:
Sender:
Followup-To:
Keywords:


    The i860 based custom graphics multicomputer we're developing,
Pixel-Planes, has a memory-mapped message transmit interface between
860 nodes: the transmit hardware snoops on the 860 address bus, and
sends words read from specific areas of memory.  The mechanism for
sending a message, then, is to toggle the address bit reserved to the
transmit hardware and read the message one word at a time.  To send
the right data, we must ensure that the message is in main memory, not
the cache.  We are trying to accomplish this by flushing the cache
lines which might contain the message buffer before sending it.  This
is where the problem lies: the i860 programmer's reference manual
says,

   "The addresses used by the flush instruction refer to a reserved
    4Kbyte memory area that is not used to store data.	This ensures
    that, when flushing the cache before a task switch, cached data
    items from the old task are not transferred to the new task.
    These addresses must be valid and writable in both the old and the
    new task's space.  Any other usage of flush has undefined
    results."

    Since we are running a single process in supervisor mode, the
caution about task switches should not apply.  What we do is use the
address of the data buffer to be sent in the flush instruction, and
only flush a number of cache blocks corresponding to the message
length.  This approach seems to contain a fatal error, but we've been
unable to characterize the problem, since our diagnostics rely on
being able to successfully send messages back to the host machine -
and the problem is in the message sending code.  Attempts to use the
i860 simulator supplied by Intel cause the simulator to get a
segmentation violation, perhaps indicating that whomever wrote the
simulator did not understand the flush instruction, either :-)

    I'd appreciate commentary from anyone in the know about what the
flush instruction really does, why we might be having problems, and
why the documentation claims that a cache flush area "not used to
store data" is needed.

    Thanks,
--
    Jon Leech (leech@cs.unc.edu)    __@/
    ``Nuclear fusion, the promise of limitless energy from sea water
    or something, has been just around the corner ever since World War
    II and is still just around the corner.'' - David Goodstein