Types defining h/w r/o or w/o registers

Types defining h/w r/o or w/o registers

[Don Gardner]

Is there some way to define a type such that all variables of that
type can be only read or only written?  For instance, I have a type that
defines the status register of some peripheral which can only be 
read.  It would be best if the compiler could flag any assignments 
to variables of such a type as errors.

Is there some other means for commonly handling this problem?  The 
compiler being used is VADSWorks, if an implementation-defined solution
is required.

Re: Types defining h/w r/o or w/o registers

[david.c.willett]

In article <3949@titan.tsd.arlut.utexas.edu>, gardner@titan.tsd.arlut.utexas.edu (Don Gardner) writes:
> Is there some way to define a type such that all variables of that
> type can be only read or only written?  For instance, I have a type that
> defines the status register of some peripheral which can only be 
> read.  It would be best if the compiler could flag any assignments 
> to variables of such a type as errors.
> 
> Is there some other means for commonly handling this problem?  The 
> compiler being used is VADSWorks, if an implementation-defined solution
> is required.

Don,
	The Ada LRM defines a "limited private" type as being one for which
the assignment operators are not valid outside the package in which the 
type is declared (see Booch, "Programming in Ada" pg. 125).  I think that
will take care of the read only case.  Only suggestion I have on write 
only is to hide the write operation in a package and provide no 
corresponding read function.

			Good Luck,
				Dave Willett

Re: Types defining h/w r/o or w/o registers

[david.c.willett]

In article <1991May31.170353.21919@cbnewsl.att.com>, willett@cbnewsl.att.com (david.c.willett) writes:
> In article <3949@titan.tsd.arlut.utexas.edu>, gardner@titan.tsd.arlut.utexas.edu (Don Gardner) writes:
> > Is there some way to define a type such that all variables of that
> > type can be only read or only written?  For instance, I have a type that
> > defines the status register of some peripheral which can only be 
> > read.  It would be best if the compiler could flag any assignments 
> > to variables of such a type as errors.
> > 
> > Is there some other means for commonly handling this problem?  The 
> > compiler being used is VADSWorks, if an implementation-defined solution
> > is required.
> 
> Don,
> 	The Ada LRM defines a "limited private" type as being one for which
> the assignment operators are not valid outside the package in which the 
> type is declared (see Booch, "Programming in Ada" pg. 125).  I think that
> will take care of the read only case.  Only suggestion I have on write 
> only is to hide the write operation in a package and provide no 
> corresponding read function.
> 
> 			Good Luck,
> 				Dave Willett
> 

Silly me, I listed the wrong author in the above post.  As we all know,
Grady Booch wrote "Software Engineering with Ada".  It was J.G.P. Barnes
who wrote "Programminng in Ada".  My appologies to all concerned.

				Dave

Re: Types defining h/w r/o or w/o registers

[J o s e D u a r t e]

> Is there some way to define a type such that all variables of that
> type can be only read or only written?  For instance, I have a type that
> defines the status register of some peripheral which can only be
> read.  It would be best if the compiler could flag any assignments
> to variables of such a type as errors.

> Is there some other means for commonly handling this problem?  The
> compiler being used is VADSWorks, if an implementation-defined solution
> is required.


Well...Ada is "the" language which explicitly allows you
to name variables which can ONLY be read/written/read-write using
the procedure syntax:


with REGISTERS; use REGISTERS;
procedure XYZ(Reg1: in REGISTER; Reg2: out REGISTER; Reg3: in out REGISTER) is
begin
  -- Reg1 can only be used effectively as a constant in this scope
  -- Reg2 can only be assigned to in this scope
  -- Reg3 can be assigned to or read from in this scope
  null;
end XYZ;

.
.
.

Alternatively, you can define a "type" and then define a constant variable
of that type for read only variables...

subtype XYZ is INTEGER;
NY_REG: constant XYZ := 0; -- define a  variable that can only be read

.
.
.

to define a type in a package that does not have ":="
implicitly defined...use a "limited private" syntax:
package REGS is

type XYZ is limited private;

-- insert your procedures/functions here

private
type XYZ is NEW WHATEVER;
end REGS;

--- This would not allow other programmers that use your package to assign
--- to a variable of type "XYZ" unless you also specified an "Assign" procedure.
--- Look up "limited private" types for more details. I believe that "limited
--- private" means that "=" (and thus "/=") and  ":=" are not implicitly
--- allowed for that type unless the  package also explicitly defines
--- "Assign" and "Read-From" procedures

Jose' D.

Re: Types defining h/w r/o or w/o registers

[Orville R. Weyrich]

In article <9105311025.aa04299@PARIS.ICS.UCI.EDU> Jose Aleman Duarte <jduarte@liege.ICS.UCI.EDU> writes:
>> Is there some way to define a type such that all variables of that
>> type can be only read or only written?  For instance, I have a type that
>> defines the status register of some peripheral which can only be
>> read.  It would be best if the compiler could flag any assignments
>> to variables of such a type as errors.
>
>> Is there some other means for commonly handling this problem?  The
>> compiler being used is VADSWorks, if an implementation-defined solution
>> is required.
>
>Alternatively, you can define a "type" and then define a constant variable
>of that type for read only variables...
>
>subtype XYZ is INTEGER;
>NY_REG: constant XYZ := 0; -- define a  variable that can only be read
>

NO NO NO!

The original poster wants to describe a memory location that can be modified
by an entity outside the control of the program. In C (and many DEC language
extensions) this would be a VOLATILE memory location. If you tell the compiler
that it is constant, the optimizer may copy the value into a register and use
the copy, or do constant folding and substitute the value 0 for the memory
reference.

Can you say BUG?  :-)



--------------------------------------           ******************************
Orville R. Weyrich, Jr., Ph.D.                   Certified Systems Professional
Internet: orville%weyrich@uunet.uu.net             Weyrich Computer Consulting
Voice:    (602) 391-0821                         POB 5782, Scottsdale, AZ 85261
Fax:      (602) 391-0023                              (Yes! I'm available)
--------------------------------------           ******************************

Re: Types defining h/w r/o or w/o regis

[stt]

Re: Read-only types

Rather than associating the Read-only-ness with the
type, I would associate it with the object.
The simplest implementation is to declare the object
in a package body, with an appropriate address clause,
and then define a parameterless function to return
the value of the object.  This function could be inlined.

S. Tucker Taft    stt@inmet.inmet.com
Intermetrics, Inc.
Cambridge, MA  02138

Re: Types defining h/w r/o or w/o registers

[rharwood]

In article <3949@titan.tsd.arlut.utexas.edu>,
gardner@titan.tsd.arlut.utexas.edu (Don Gardner) writes:

> Is there some way to define a type such that all variables of that
> type can be only read or only written?  For instance, I have a type that
> defines the status register of some peripheral which can only be 
> read.  It would be best if the compiler could flag any assignments 
> to variables of such a type as errors.
> 
> Is there some other means for commonly handling this problem?  The 
> compiler being used is VADSWorks, if an implementation-defined solution
> is required.

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.

Naturally, you'd have to change/define types as appropriate, but here's a
sample of how I've done it (from memory... don't expect perfect recall!).

(Before anyone attacks the "obvious inefficiencies" here, try inserting 
"PRAGMA INLINE"s for the subprograms and COMPILE it on YOUR compiler, then look
at generated assembler code when you CALL them.  I believe the compiler we had
did almost exactly what the assembler programmer would have done: a direct read
from the IO location.)  Obviously, you should check the performance issues for
YOUR compiler!  This is a bit long... but I hope it's helpful.
============================ package spec
Package My_Device_Controller is

  --
  --  Your "read-only" register interface:
  --

  -- Define the possible status returned as enumerated:
  Type Status is (Device_Busy, Device_Idle, Device_Error);  -- etc....

  -- And attach the appropriate "real" values:
  For Status use (Device_Busy  => 16#01#,   -- Define as appropriate
                  Device_Idle  => 16#08#,   -- for YOUR controller
                  Device_Error => 16#F0#);  --

  -- Here's the function which provides a "read-only" status value...
  -- See implementation in package body below.
  Function device_status return status;

  --
  -- Now, the "write-only" register interface:
  --

  -- Define the possible control values, also enumerated:
  -- (I'm assuming "read" and "write" commands are concerned with reading/
  -- writing device DATA, not CONTROL information.)
  Type controls is (Write_Command, Read_Command,     -- Etc.... add others
                    Status_Command, Reset_Command);  -- if needed

  -- Define the "real values":
  For Controls use (Write_Command  => 16#01#,  -- Again, use whatever
                    Read_Command   => 16#04#,  -- your hardware dudes
                    Status_Command => 16#14#,  -- give you (normally
                    Reset_Command  => 16#F9#); -- in HEX!)

  Procedure Device_Command ( command : in controls );
end My_Device_Controller;
============================ package body
With Low_Level_IO;  
    -- or maybe you use Memory-Mapped... that's a bit trickier,
    -- but I've done that too. (Not here, for brevity!)
Package Body My_Device_Controller is

  -- The LRM 14.6 defines Low_Level_IO, but does not explicitly
  -- define type "device_type"; an exercise for the interested...
  Status_Register  : constant Low_level_IO.Device_type := 16#F001#;
  Control_Register : constant Low_level_IO.Device_type := 16#F003#;

  Function device_status return status is
    results : Low_Level_IO.data_type;
  begin
    Low_Level_IO.Receive_Control(Device=> Status_Register, Data => results);
    Return Results;  -- You may need some UNCHECKED_CONVERSION here...
  end device_status;

  Procedure Device_Command ( command : in controls ) is
  begin
    -- Again, you may need a little CONVERSION...
    Low_Level_IO.Send_Control(Device=> Control_Register, Data => Command);
  end Device_Command;
end My_Device_Controller;
============================ code usage fragment
With My_Device_Controller; Use My_Device_Controller;
..
..
  Device_Command (Status_command);  -- tell the device to report!
  Case device_Status is
    When Device_idle  => process_whatever_you_want;
    When Device_busy  => dont_do_anything_now;
    When Device_error => Device_Command(reset_command); -- or whatever!
  end case;
..
..
  Device_Command(Write_command);
  Device_Command(Read_command);
..

Re: Types defining h/w r/o or w/o registers

[Orville R. Weyrich]

In article <1991Jun2.095459.1@east.pima.edu> rharwood@east.pima.edu writes:
>In article <3949@titan.tsd.arlut.utexas.edu>,
>gardner@titan.tsd.arlut.utexas.edu (Don Gardner) writes:
>
>> Is there some way to define a type such that all variables of that
>> type can be only read or only written?  For instance, I have a type that
>> defines the status register of some peripheral which can only be 
>> read.  It would be best if the compiler could flag any assignments 
>> to variables of such a type as errors.
>> 
>> Is there some other means for commonly handling this problem?  The 
>> compiler being used is VADSWorks, if an implementation-defined solution
>> is required.
>
>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


I have one concern about this approach: What happens if the compiler optimizer
is SO CLEVER that it notices a write to a location that is never referenced,
and optimizes away the write? 

Does anyone know of a compiler that is this clever?

In any event, you had best check the machine language generated each time
your compiler is upgraded ...

Is there any issue pending before the 9x committee to address the issue of
declaring certain memory locations as VOLATILE?

--------------------------------------           ******************************
Orville R. Weyrich, Jr., Ph.D.                   Certified Systems Professional
Internet: orville%weyrich@uunet.uu.net             Weyrich Computer Consulting
Voice:    (602) 391-0821                         POB 5782, Scottsdale, AZ 85261
Fax:      (602) 391-0023                              (Yes! I'm available)
--------------------------------------           ******************************

Re: Types defining h/w r/o or w/o registers

[John Goodenough]

In article Re: Types defining h/w r/o or w/o registers of 3 Jun 91 07:57:41
GMT orville@weyrich.UUCP (Orville R. Weyrich) writes: 

>Is there any issue pending before the 9x committee to address the issue of
>declaring certain memory locations as VOLATILE?

The following user need and requirement address this issue

    USER NEED U7.1-A: CONTROL OF SHARED MEMORY

    Requirement R7.1-A(1) -- Control of Shared Memory

If you get access to the Requirements Rationale document and look up
"VOLATILE" in the KWIC index, you will be referred directly to this
requirement.  This document is available electronically on the AJPO host and
on the Ada 9X Bulletin Board -- 1-800-Ada9X25 or 301/459-8939.  Or contact the
Ada 9X Project Office at the address below to receive a hard copy.

	Chris Anderson
	Ada 9X Project Manager
	WL/MNAG
	Eglin AFB, FL 32542-5434
	904/882-8264
	e-mail: anderson@uv4.eglin.af.mil
	FAX: 904/882-2095

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391

Re: Types defining h/w r/o or w/o registers

[Anthony Shipman]

In article <1991Jun3.075741.1945@weyrich.UUCP>, orville@weyrich.UUCP (Orville R. Weyrich) writes:
................
> 
> Is there any issue pending before the 9x committee to address the issue of
> declaring certain memory locations as VOLATILE?


Wasn't there something in the tasking part of the language for this?  Ada's
multi-tasking model is shared memory between tasks.  I vaguely recall there was
a pragma, or something in the machine-dependant chapter, to declare certain
memory locations as volatile.  Certainly what you have is logically equivalent
to multi-tasking except that one of the tasks is implemented in hardware.

-- 
Anthony Shipman                 "You've got to be taught before it's too late,
Computer Power Group             Before you are six or seven or eight,
19 Cato St., East Hawthorn,      To hate all the people your relatives hate,
Melbourne, Australia             You've got to be carefully taught."  R&H

Re: Types defining h/w r/o or w/o registers

[John Goodenough]

In article Re: Types defining h/w r/o or w/o registers of 4 Jun 91 14:48:21 GMT als@bohra.cpg.oz.au (Anthony Shipman) writes:

>Wasn't there something in the tasking part of the language for this?  Ada's
>multi-tasking model is shared memory between tasks.  I vaguely recall there was
>a pragma, or something in the machine-dependant chapter, to declare certain
>memory locations as volatile.  Certainly what you have is logically equivalent
>to multi-tasking except that one of the tasks is implemented in hardware.

You are talking here about pragma SHARED, which is not suitable for use with
volatile data.  The Ada 9X study report on shared variables (available from
the usual sources) discusses why pragma SHARED doesn't fit the bill.

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391