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.7 required=5.0 tests=BAYES_00,GAPPY_SUBJECT,
	INVALID_DATE autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!spool.mu.edu!cs.umn.edu!uc!shamash!case
From: case@shamash.cdc.com (Steven V. Case)
Newsgroups: comp.lang.ada
Subject: Re: Types defining h/w r/o or w/o registers
Message-ID: <33884@shamash.cdc.com>
Date: 6 Jun 91 03:02:04 GMT
Organization: Control Data, Arden Hills, MN
List-Id: <comp.lang.ada>


> Well, it's been 2.5 years since I did this, but IMHO "the right way" to do 
> what you are trying is to encapsulate the READ operation in a FUNCTION and the
> WRITE operation in a one-parameter procedure.  Several replies to your message
> correctly stated that you should "hide the operations in a package," but 
> didn't show how to implement the desired functionality.

I was wondering when someone would mention this.  I too agree that this is the
prefered approach.  It is the method that I have used on all of the projects
I have worked on which have had a similar requirement.

I have read several papers addressing the use of LOW_LEVEL_IO to also serve
this purpose.  Unfortunately, I have not had the pleasure to use a compiler
which provides LOW_LEVEL_IO support.  I would be interested in hearing from
anyone who has some "real life" experience with LOW_LEVEL_IO, especially if
it was used in an embedded, real-time system.

Using the READ function and WRITE procedure approach that you mention, the
biggest problem that I have run into is not that of inefficient code generated
due to the procedure calls.  As you pointed out, using PRAGMA INLINE has always
been able to take care of it.  The problem I have had is with compilers that
have been too aggressive in their optimizations.  Specifically, most of the
systems I have developed for have memory-mapped I/O.  On these systems (that
I am familiar with) the I/O will only work if a read or write operation is
performed at the proper address with the properly "sized" access.  

In such systems, problems appear when the hardware expects a 32-bit access
and one attempts to perform the I/O with something other than a 32-bit access.
This is a problem that I have had to work around frequently.  Typically I 
will define a record which describes the content of the I/O register to be
accessed.  Then if the compiler detects that I am only accessing a portion of
the record, it might attempt to "optimize" the access by using an 8-bit or
a 16-bit access rather than a 32-bit access as required by the hardware.

Since I have been able to deliver these systems, there are obvious ways to
work around the "optimizations" if the compiler demonstrates such behavior.
They just require me to write code that is not quite what I would have 
preferred.  I would also like to hear of others experience with memory 
mapped I/O when LOW_LEVEL_IO support is not present.

Regards,
Steve

-- 
  ____  ____        Steve Case - HQG526           email: case@shamash.cdc.com
 / ___||___ \       Control Data Corporation      AT&T : (612) 853-3345
| |___  ___| |      3101 East 80th Street                 
 \____||____/       Bloomington, MN 55425