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!attcan!uunet!peregrine!elroy!ames!pasteur!ucbvax!cl.uh.EDU!ROGERS
From: ROGERS@cl.uh.EDU ("Pat Rogers, Software Engineering Research Center")
Newsgroups: comp.lang.ada
Subject: read-only objects
Message-ID: <8807300158.AA05816@ajpo.sei.cmu.edu>
Date: 29 Jul 88 17:58:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>

Recently, Mark Adolph asked the following:

>Subject: Read-Only Variables
>
>We've come across an interesting problem here.  We're trying to build a
>model of a processor that we can use in simulation.  In at least one
>case, we have a register with bits that, in the hardware, can be read by
>software but only modified by hardware.  How does one declare a record
>component that is only visible for reading but can be updated
>internally?  Making it private and declaring a function to allow reading
>isn't appropriate as it would not be a correct model of the situation.
>
>-- 
>
>					-- Mark A.
>					...uw-beaver!ssc-vax!adolph

My mailer won't accept his address for some unknown reason, so here goes
to the general public:

We have defined a class of objects called "Opaque Data Types" (not related
to the Modula or C uses of the name) in which parts of an object of the
type are read-only. This appears to be what Mark is looking for. The type
can be declared as follows:

  package Foo is
  
    type Opaque( A, B, C : Integer := 0 ) is private;
    
    -- subprograms to alter the state of objects of type Opaque
    
  private
  
    type Opaque( A, B, C : Integer := 0 ) is
      record
        -- any internal, hidden components here...
      end record;
      
  end Foo;
  
  
Since the discriminants are visible to users, they may be read. They may
not be updated, of course, since the only way to alter discriminants is
by complete record assignment, which is not possible outside the package
since the type is private. The exported subprograms can alter
the state of such objects, since the discriminants have default values
assigned in the type declaration...

For your application, it sounds like the bits need to be discriminants of a
type called Register, with subprograms that are logically called by the
hardware and not by the software. Is that close enough? It might be nice to
just declare an object of that type in a package to act as a state machine, and
not export any operations, since the user (the "software" in the model)
should not be able to update the register via the exported operations, but such
use of a private type is illegal. Placing such an object in another package
and hiding the implementation package Foo might do what you want, as long
as the "user" doesn't import Foo via a context clause...

For example,

                                             
package Hardware is

  type Bit is range 0 .. 1;
      
  type Register( Bit0, Bit1, Bit2, Bit3, 
                 Bit4, Bit5, Bit6, Bit7 : Bit := 0 ) is private;
    
  -- subprograms to alter the state of objects of type Register
    
private
  
  type Register( Bit0, Bit1, Bit2, Bit3, 
                 Bit4, Bit5, Bit6, Bit7 : Bit := 0 ) is
    record
      Internal : Integer; -- optional
    end record;
      
end Hardware;
                                         

with Hardware;
package Software_Visible is
  
  PC : Hardware.Register;
    
end Software_Visible;
  


Hope that helps...

Regards,

Pat Rogers
Software Engineering Research Center
progers@ajpo.sei.cmu.edu