From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!IBM.COM!NCOHEN
From: NCOHEN@IBM.COM ("Norman H. Cohen")
Newsgroups: comp.lang.ada
Subject: Memory-mapped I/O
Message-ID: <9001181438.AA16438@ajpo.sei.cmu.edu>
Date: 18 Jan 90 14:19:37 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>

I agree with Harold Rabbie:  The best way to do memory-mapped I/O is
through LOW_LEVEL_IO.  If your compiler does not have an appropriate
SEND_CONTROL procedure, the best alternative is a code procedure.
This is one of the few circumstances in which a code procedure is both
appropriate and palatable.  It is appropriate because the intent is to
emit a specific short sequence of machine-code instructions.  It is
palatable because the sequence is only one instruction long.

A case study that SofTech did for CECOM (Ft. Monmouth) in 1982 pointed
out another problem, in addition to those mentioned by Rabbie, with the
use of assignment statements:  An assignment to a variable that is
located at an I/O address is typically not followed by a reference to
that variable.  Thus the variable looks "dead" to data-flow analysis and
the assignment is likely to be eliminated as useless by an optimizing
compiler.  (A strong case can be made that a compiler for a machine with
memory-mapped I/O must never treat an assignment as useless if the
target variable is subject to an address clause, but a case can also be
made to justify this behavior.)

Norman Cohen