Re: Flags in Ada?

Re: Flags in Ada?

[David Emery]

>I am trying to use UNIX system calls from Ada...
>BTW, I'm sure all of this has already been asked and discussed at
>length. Forgive me if this is just an FAQ.

Look at IEEE Std 1003.5-1992 (soon to be an ISO standard, too) for the
Ada interface to POSIX.  The rationale is very good on the design
decisions.  

I wrote a paper for Tri-Ada '90 on my implementation experience for
POSIX/Ada, and there'll be a similar presentation at the
POSIX/Real-Time conference in Bonn (FRG) November 14.

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Flags in Ada?

[Andre Spiegel]

I am trying to use UNIX system calls from Ada, which has been working
fine so far, i.e. the `translation' into Ada looks rather neat and
secure (enumeration types with representation clauses for C #define'd
constants, etc.), but how would I go about representing *flags* --
i.e. words, in which the individual bits have names, and can be set,
cleared, or'ed, xor'ed, and the like?

I seem to recall that all of this is realized very comfortably in Ada
9X, but how can I do it in Ada 83?

Another question: UNIX returns a pointer to some data structure, which
I want to read and possibly modify from within Ada. What would be the
adequate way to do this? Off the cuff, I can think of two
possibilities:

  (1) declare the operating system routine to be returning an access
      value, pointing to an Ada record, which resembles the C
      structure.

	type Data is record
                       ...
	             end record;

	type Data_Access is access Data;

        function OS_Routine (...) return Data_Access;

      Disadvantage: As far as I know, access types do not necessarily 
      have to be implemented as pointers. I have read (recently in
      this group), that GNAT, for example, doesn't always do that.
      Also, the Sparc Alsys compiler (which I'm using) seems to use
      the numeric address *one* to indicate a null access value...

  (2) declare the operating system routine to be returning
      System.Address, and use an address clause to interpret the
      memory area pointed to as the corresponding structure.

        function OS_Routine (...) return System.Address;

        Data_Pointer : System.Address;

	...

        Data_Pointer := OS_Routine (...);

        -- check for null address here, using Unchecked_Conversion
        -- to convert Data_Pointer to Integer?

	declare
          Result : Data;
	  for Result use at Data_Pointer;
        begin
          -- process Result...
        end;
 
      Questions: Is this acceptable? Why does RM83 13.5(8) forbid to
      use address clauses to achieve overlays, then? How do compilers 
      usually implement this -- does the declare statement force 
      data allocation on the stack, or is it optimized away, yielding
      simply a bypass of the type checking system, just like a `call'
      to Unchecked_Conversion should simply translate into _nothing_,
      if I'm not all wrong?

In either of these possibilities, what if `Data' is a record with
variants (forced to the right representation with a rep clause)? Might
Ada get into trouble when interpreting it, or even refuse to work with
a record value it has not assigned and checked itself?

Again, I'm primarily interested in the `83 solutions, but would also
like to learn how everything will be much simpler and more 
straightforward in `9X :-). 

BTW, I'm sure all of this has already been asked and discussed at
length. Forgive me if this is just an FAQ.

Regards,

--
Andre Spiegel                     |  This life is a test. It is only a test.
                                  |  Had this been an actual life, you would
University of Stuttgart, Germany  |  have received further instructions as to
Computer Science                  |  where to go and what to do.
                                                            -- Author unknown

	   email: spiegel@bruessel.informatik.uni-stuttgart.de

      
       
 
      

Re: Flags in Ada?

[Norman H. Cohen]

In article <SPIEGEL.94Oct25113657@berlin.bruessel.informatik.uni-stuttgart.de>, spiegel@bruessel.informatik.uni-stuttgart.de (Andre Spiegel) writes: 

|>                       how would I go about representing *flags* --
|> i.e. words, in which the individual bits have names, and can be set,
|> cleared, or'ed, xor'ed, and the like?
|>
|> I seem to recall that all of this is realized very comfortably in Ada
|> 9X, but how can I do it in Ada 83?

   type Permission_Type is
      (Owner_Read, Owner_Write, Owner_Execute,
       Group_Read, Group_Write, Group_Execute,
       World_Read, World_Write, World_Execute);

      -- These are the "bit names"

   type Permission_Set_Type is array (Permission) of Boolean;
   pragma Pack (Permission_Set_Type);

      -- This is the "word"

   Default_Permissions : constant Permission_Set_Type :=
                           Permission_Set_Type'
                              (Owner_Read .. Owner_Execute => True,
                               Group_Read | World_Read     => True,
                               others                      => False);

      -- This is the use of an array aggregate to specify a "word" value.

   Current_Permissions : Permission_Set_Type := (Permission_Type => False);

   Current_Permissions(World_Execute) := True;

   if Current_Permissions(World_Write) then
      Clobber_File;
   end if;

      -- These are uses of indexed components to set and examine
      --    individual "bits"

   Current_Positions := Current_Positions or Default_Positions;

      -- This is the application of logical operators to arrays of
      --    Boolean values.  and, or, xor, and not can be used in this
      --    way and they apply bit by bit.

|> Another question: UNIX returns a pointer to some data structure, which
|> I want to read and possibly modify from within Ada. What would be the
|> adequate way to do this? Off the cuff, I can think of two
|> possibilities: 
|>
|>   (1) declare the operating system routine to be returning an access
|>       value, pointing to an Ada record, which resembles the C
|>       structure.
...
|>       Disadvantage: As far as I know, access types do not necessarily
|>       have to be implemented as pointers. I have read (recently in
|>       this group), that GNAT, for example, doesn't always do that.
|>       Also, the Sparc Alsys compiler (which I'm using) seems to use
|>       the numeric address *one* to indicate a null access value...

Correct.  It's elegant when it works, but not very portable.

|>   (2) declare the operating system routine to be returning
|>       System.Address, and use an address clause to interpret the
|>       memory area pointed to as the corresponding structure.
|>
|>         function OS_Routine (...) return System.Address;
|>
|>         Data_Pointer : System.Address;
|>
|>      ...
|>
|>         Data_Pointer := OS_Routine (...);
|>
|>         -- check for null address here, using Unchecked_Conversion
|>         -- to convert Data_Pointer to Integer?
|>
|>      declare
|>           Result : Data;
|>        for Result use at Data_Pointer;
|>         begin
|>           -- process Result...
|>         end;
|>
|>       Questions: Is this acceptable?

Yes, this is the right way to do this.

|>                                      Why does RM83 13.5(8) forbid to
|>       use address clauses to achieve overlays, then?

13.5(8) must be understood as applying to the overlaying of Ada entities.
What other possible use could there be for an address clause except to
overlay an Ada entity with storage that has some special significance
outside the Ada program (significance either to hardware or software)?
Admittedly, address clauses give rise to a whole bunch of embarassing
questions that are best not asked.  (For example, what happens if you
locate a constant at an address that is changed by some agent outside the
Ada program?)

|>                                                      How do compilers
|>       usually implement this -- does the declare statement force
|>       data allocation on the stack, or is it optimized away, yielding
|>       simply a bypass of the type checking system, just like a `call'
|>       to Unchecked_Conversion should simply translate into _nothing_,
|>       if I'm not all wrong?

No new storage is allocated.  (How could the allocation be on the stack
if it has to be at the address specified in the address clause?) The
specified entity is simply taken to reside at the specified address.

|> In either of these possibilities, what if `Data' is a record with
|> variants (forced to the right representation with a rep clause)? Might
|> Ada get into trouble when interpreting it, or even refuse to work with
|> a record value it has not assigned and checked itself?

Record representation clauses can be used to control the location of
discriminants.  If a compiler cannot support this, it must reject the
record representation clause.  A compiler that accepts the record
representation clause must do the right thing with variants.
(This assumes that the C struct has a member acting in effect as a
discriminant to indicate the currently active variant.  A record
representation clause cannot specify overlapping components unless the
components are in different variants--see RM 13.4(7)-- and an Ada record
type with different variants necessarily has a discriminant.)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Flags in Ada?

[tmoran]

>Look at IEEE Std 1003.5-1992 (soon to be an ISO standard, too) for the
>Ada interface to POSIX.  The rationale is very good on the design
>...
>I wrote a paper for Tri-Ada '90 on my implementation experience for
Is either document ftp-able?

Re: Flags in Ada?

[Dale Stanbrough]

In article <SPIEGEL.94Oct25113657@berlin.bruessel.informatik.uni-stuttgart.de>
Andre Spiegel, spiegel@bruessel.informatik.uni-stuttgart.de writes:
>I am trying to use UNIX system calls from Ada, which has been working
>fine so far, i.e. the `translation' into Ada looks rather neat and
>secure (enumeration types with representation clauses for C #define'd
>constants, etc.), but how would I go about representing *flags* --
>i.e. words, in which the individual bits have names, and can be set,
>cleared, or'ed, xor'ed, and the like?
>
>I seem to recall that all of this is realized very comfortably in Ada
>9X, but how can I do it in Ada 83?

Devise a package to implement bit operations on your favourite Ada type
(here "word" is a subtype of your favourite integer type).

It would be appropriate, no doubt, to follow the facilities available in
package interfaces of Ada9x for the shift operations.

-------------------------------------------------------
package body bit_ops is

        type int_image is array(1..word'size) of boolean;
        pragma pack(int_image);

        function int_to_array is new unchecked_conversion
                        (source => word,
                        target => int_image);

        function array_to_int is new unchecked_conversion
                        (source => int_image,
                        target => word);

        function "xor"(w,w1:word) return word is
                a,a1:int_image;
        begin
                a:= int_to_array(w);
                a1 := int_to_array(w1);
                return(array_to_int(a xor a1));
        end;


        function "or"(w, w1 :word) return word is
                a, a1 : int_image;

        begin
                a:= int_to_array(w);
                a1 := int_to_array(w1);
                return(array_to_int(a or a1));
        end;

        function "and"(w, w1 : emtypes.word) return word is
                a, a1 : int_image;

        begin
                a := int_to_array(w);
                a1 := int_to_array(w1);
                return(array_to_int(a and a1));
        end;

        function "not"(w : word) return word is
                a : int_image;

        begin
                a := int_to_array(w);
                return(array_to_int(not a));

        end;
end bit_ops;

Dale
-------------------------------------------------------------
Dale Stanbrough, RMIT, Melbourne, Australia, dale@rmit.edu.au
GNU Ada 94 (GNAT) => the best $0 you'll ever spend.
Available for DOS, Linux, OS/2, Sun Sparc, Sun Solaris, ...
Coming to a GNU supported platform near you soon...

Re: Flags in Ada?

[tmoran]

>  type Permission_Type is
>     (Owner_Read, Owner_Write, Owner_Execute,
>      Group_Read, Group_Write, Group_Execute,
>      World_Read, World_Write, World_Execute);
>
>     -- These are the "bit names"
>
>  type Permission_Set_Type is array (Permission) of Boolean;
>  pragma Pack (Permission_Set_Type);
   -- and a rep clause to say just where these 9 bits fit? ;)

or

  type Line_Statuses is record
    Data_Ready   :boolean;
    Over_Run     :boolean;
    Parity_Error :boolean;
    Framing_Error:boolean;
    Break        :boolean;
    Transmitter_Holding_Register_Empty:boolean;
    Transmitter_Shift_Register_Empty  :boolean;
  end record;
  for Line_Statuses use record
    Data_Ready    at 0 range  0 .. 0;
    Over_Run      at 0 range  1 .. 1;
    Parity_Error  at 0 range  2 .. 2;
    Framing_Error at 0 range  3 .. 3;
    Break         at 0 range  4 .. 4;
    Transmitter_Holding_Register_Empty at 0 range 5 .. 5;
    Transmitter_Shift_Register_Empty   at 0 range 6 .. 6;
  end record;
  for Line_Statuses'size use 8;

In the Permissions example all the flags are homogenous - all 'OK or
DENIED' of some permission.  So
  Current_Permissions := (Permission_Type => False);
is a reasonable thing to say.  But in the UART example they have
quite different meanings (Data_Ready is a register status, Break
a line status, Parity_Error a data status) and normal values
(Parity_Error is much less often True than Data_Ready).
And though you might well wish to say
  Running_Status.Parity_Error
    :=Running_Status.Parity_Error or Latest_Status.Parity_Error;
it's unlikely you would want
  Running_Status.Data_Ready
    := Running_Status.Data_Ready or Latest_Status.Data_Ready;
so you would not say
  Running_Status:=Running_Status or Latest_Status;
You might of course mix the two styles - put Over_Run, Parity_Error,
and Framing_Error into a three component packed boolean vector a la
Permissions because they are similar to one another, and include
that bit vector along with Data_Ready, Break, and the Transmitter
statuses in a record a la Line_Statuses;

Re: Flags in Ada?

[David Emery]

Most of the techniques that have been proposed for this use packed
boolean and representation specs within the visibile part of the
package spec.  My experience is that this can be a dangerous approach,
particularly for portability.

The way we handle this in POSIX/Ada follows.  We tried to produce an
interface that could support a variety of implementation strategies,
but required no changes to using code.  

 package POSIX is 
  ...
    type Option_Set is private;
    function Empty_Set 
        return Option_Set;
    function "+" (L, R : Option_Set)
        return Option_Set;
    function "-" (L, R : Option_Set)
        return Option_Set;
  ...
 end POSIX;

 with POSIX,
      POSIX_Permissions;
 package POSIX_IO is
  ...
    type Open_Option_Set is new POSIX.Option_Set;
      -- Empty_Set, "+" and "-" are derived operations

    Non_Blocking 		: constant Open_Option_Set
				:= <implementation defined>;
    Append 			: constant Open_Option_Set
				:= <implementation defined>;
    Truncate 			: constant Open_Option_Set
				:= <implementation defined>;
    Exclusive 			: constant Open_Option_Set
				:= <implementation defined>;
    Not_Controlling_Terminal 	: constant Open_Option_Set
				:= <implementation defined>;
  ...
 end POSIX_IO;

Note the Ada9X-style use of derived types for 'inheritence'.  The type
Option_Set has no defined members (it's an 'abstract type').  

To define a particular set of options, such as the options used for
Open(), you derive a new type from POSIX.Option_Set, and then define
appropriate constants of that type.  

In Ada83, the definition of the option constants is a bit klugey, and
can involve unchecked_conversion.  Ada9X provides substantially better
features for this.  

In my prototype Ada83 implementation, I have the following:

 package POSIX is
  ...
 private
    type Option_Set is array (0..31) of boolean;
    pragma pack (Option_Set);
    for Option_Set'size use integer'size;
 end POSIX;

 with unchecked_conversion, POSIX;
 package option_munging is
   function to_option_set is new unchecked_conversion
		(integer, POSIX.option_set);
   function to_integer is new unchecked_conversion 
		(POSIX.option_set, integer);
 end option_munging;

 with POSIX,
      POSIX_Permissions;
 with option_munging;	-- implementation dependency
 package POSIX_IO is
  ...
    type Open_Option_Set is new POSIX.Option_Set;
      -- Empty_Set, "+" and "-" are derived operations

    Non_Blocking 		: constant Open_Option_Set
				:= Open_Option_Set
				    (option_munging.to_option_set (16#4000#));
    Append 			: constant Open_Option_Set
				:= Open_Option_Set
				    (option_munging.to_option_set (16#0008#));
    Truncate 			: constant Open_Option_Set
				:= Open_Option_Set
				    (option_munging.to_option_set (16#0400#));
    Exclusive 			: constant Open_Option_Set
				:= Open_Option_Set
				    (option_munging.to_option_set (16#0800#));
    Not_Controlling_Terminal 	: constant Open_Option_Set
				:= Open_Option_Set
				    (option_munging.to_option_set (16#8000#));
  ...
 end POSIX_IO;

In another implementation approach, I've completed the type Option_Set
as an integer, and changed the Option_Munging declaration to match.  

In Ada9X, I can eliminate the Option_Munging package altogether with a
'classic' use of child packages:

 package POSIX.Option_Values is
    Value_0 : constant Option_Set := (0 => true, others => false);
    Value_1 : constant Option_Set := (1 => true, others => false);
  ...
 end POSIX.Option_Values;

Then package POSIX_IO becomes

 with POSIX,
      POSIX_Permissions;
 with POSIX.Option_Values;
 package POSIX_IO is
  ...
    type Open_Option_Set is new POSIX.Option_Set;
      -- Empty_Set, "+" and "-" are derived operations

    Non_Blocking 		: constant Open_Option_Set
				:= Open_Option_Set
					(POSIX.Option_Values.Value_30);
    Append 			: constant Open_Option_Set
				:= Open_Option_Set
					(POSIX.Option_Values.value_8);
  ...
 end POSIX_IO;

Notice the type conversion from POSIX.Option_Set to
POSIX_IO.Open_Option_Set.  This is needed because the constants are
not 'inherited operations'.  

I've used this technique in other Ada bindings, and it works very
well.  

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: Flags in Ada?

[Robert Dewar]

The natural way of representing flags, i.e. words in which individual bits
have names and can be manipulated is to use pragma pack (some implementations
may require you to use a record representation clause, but this should not
be necessary, and is a weakness in the implementation).

   type Flag_Byte is record
      Flag1 : Boolean;
      ...
      Flag8 : Boolean;
   end record;

   for Flag_Byte'Size use 8;
   pragma Pack (Flag_Byte);

That should work fine (certainly works fine on GNAT, where it is equivalent
to the obviously corresponding C declaration with bit fields of length 1)

If sometimes you need to regard this as an integer, then you need to use
unchecked conversion -- quite an appropriate use of unchecked conversion,
since you are asking to view the same data as two totally different types.

Re: Flags in Ada?

[Robert Dewar]

As I noted in a previous message, pragma pack should work just fine on
records, it is NOT necessary to give record representation clauses unless
they are needed to match an external specification. In Ada 9X in particular,
one would assume that even in the latter case, the use of:

  pragma COnvention (C, rectype);

should be adequate to ensure a match up with the C type. In GNAT, convention
C is the default (i.e. for datatypes that match, convention Ada and
convention C are identical), so it works even in the absnece of this
pragma.

Re: Flags in Ada?

[Andre Spiegel]

[referring to Norman H. Cohen's article <38jb6s$tsr@watnews1.watson.ibm.com>]

Thanks for the flag example. I had missed the section in the RM which
says that boolean operators can also be applied to boolean arrays. 
I suppose that compilers also recognize that what I want is bit
arithmetic, and therefore won't generate loops to apply the operator
to the arrays elementwise, which would of course be ridiculously slow.

Thanks also for the explanations on address clauses. This is the way
in which I have been doing it in my program, too. I was just wondering
about efficiency, because those `declare' statements "look" somewhat
expensive. For example, if UNIX fills a buffer with data items of
varying length (talking about ethernet packets, actually), and I want
to scan that buffer in an Ada loop, there has to be a declare
statement *within* the loop, in order to, sort of, "move" the record
pattern over the buffer.  

This seems a little counter-intuitive, because it's so different from
what you would do in C, for example -- simply declare a pointer to a
struct, and increment that pointer accordingly. I have found,
meanwhile, that in Ada 9X the generic package Interfaces.C.Pointers
will provide precisely that. But from what you wrote, I conclude that
the declare statement solution does not translate into anything
different at the machine level. It probably even looks more Ada-like.

--
Andre Spiegel                     |  This life is a test. It is only a test.
                                  |  Had this been an actual life, you would
University of Stuttgart, Germany  |  have received further instructions as to
Computer Science                  |  where to go and what to do.
                                                            -- Author unknown

	   email: spiegel@bruessel.informatik.uni-stuttgart.de

Re: Flags in Ada?

[Norman H. Cohen]

In article <38jb6s$tsr@watnews1.watson.ibm.com>, ncohen@watson.ibm.com
(Norman H. Cohen) writes: 

|>    type Permission_Type is
|>       (Owner_Read, Owner_Write, Owner_Execute,
|>        Group_Read, Group_Write, Group_Execute,
|>        World_Read, World_Write, World_Execute);
|>
|>       -- These are the "bit names"
|>
|>    type Permission_Set_Type is array (Permission) of Boolean;
|>    pragma Pack (Permission_Set_Type);
|>
|>       -- This is the "word"

Oops.  That should have been

    type Permission_Set_Type is array (Permission_Type) of Boolean;
                                                 -----

Thanks to Peter Hermann for pointing this out.

In article <38khst$hn3@news.delphi.com>, tmoran@bix.com writes: 

|> >  pragma Pack (Permission_Set_Type);
|>    -- and a rep clause to say just where these 9 bits fit? ;)

The ";)" is a subtle hint that this doesn't really make sense, but for
those who might miss it, we ought to be explicit:  Permission_Set_Type is
an array type, not a record type, so one cannot write a record
representation clause for it.

It is not necessary to control where within the word the nine bits fit
unless you are passing Permission_Set_Type values across an interface to
or from hardware or some piece of software outside the program that
expects a specific bit placement.  If you do need to control the
placement of bits, and if you want to preserve the ability to apply
logical operations to the entire word (a requirement of the original
questioner), there are at least two alternatives: 

   1.  Expand Permission_Type to provide a name for every bit in the word
       and then check (by running a test or examining object code)
       whether the compiler implements packed arrays of booleans with the
       lowest index position in the least significant or most significant
       bit of the word.  You may have to reverse the order of the
       enumeration literals in Permission_Type.  This is obviously not
       portable.

   2.  Declare the types as

          type Permission_Type is range 0 .. Word_Size-1;
          type Permission_Set_Type is array (Permission_Type) of Boolean;
          pragma Pack(Permission_Set_Type);

       and determine at run time, perhaps by obtaining from across the
       interface a value Test_Value known to have only the least
       significant bit set, whether the least significant bit is
       component zero or component Word_Size-1 of the array, then define
       symbolic names for the Permission_Type values accordingly: 

           if Test_Value(0) then
              -- low order bits have low indices
              Owner_Read := 8;
              Owner_Write := 7;
              Owner_Execute := 6;
              Group_Read := 5;
              Group_Write := 4;
              Group_Execute := 3;
              World_Read := 2;
              World_Write := 1;
              World_Execute := 0;
           else
              -- low order bits have high indices
              Owner_Read := Permission_Type'Last - 8;
              Owner_Write := Permission_Type'Last - 7;
              Owner_Execute := Permission_Type'Last - 6;
              Group_Read := Permission_Type'Last - 5;
              Group_Write := Permission_Type'Last - 4;
              Group_Execute := Permission_Type'Last - 3;
              World_Read := Permission_Type'Last - 2;
              World_Write := Permission_Type'Last - 1;
              World_Execute := Permission_Type'Last;
           end if;

       Unfortunately, these nine variables are not static expressions, so
       they can't be used to name index positions in the kinds of array
       aggregates we would like to write.  Also, indexed components into
       packed arrays of Boolean values can be a lot slower on some
       architectures when the index value is not static, because of
       shifting instructions that have the number of bits to shift
       hard-wired into the instruction.

The pragma Packed tells the compiler that I want each Boolean value to
occupy only one bit, and that I want componentwise logical operations to
be implemented using the machine's underlying logical word instructions.
In the absence of such a hint, the compiler might choose to allocate a
byte for each array component, which speeds up the setting and extraction
of array components on some architectures, but slows down componentwise
logical operations.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Flags in Ada?

[Robert Dewar]

well to me Dave's approach seems overkill

I really don't see the objection to a packed record. OK, some implementations
are deficient and don't implement this feature properly, but that's not
Ada's fault -- insist on compilers that have this feature if you need it,
it's required by the language definition.

Re: Flags in Ada?

[tmoran]

>As I noted in a previous message, pragma pack should work just fine on
>records, it is NOT necessary to give record representation clauses unless
>they are needed to match an external specification. In Ada 9X in particular,
>one would assume that even in the latter case, the use of:
>
> pragma COnvention (C, rectype);

>should be adequate to ensure a match up with the C type. In GNAT, convention
>C is the default (i.e. for datatypes that match, convention Ada and
>convention C are identical), so it works even in the absnece of this
>pragma.

Does 'C' specify how the bit fields are arranged?
My copy of 'The ANSI C Programming Language' (by K&R) says 'Almost
everything about bit fields is implementation dependent.  ....  Fields
are assigned left to right on some machines and right to left on others.'
And in its appendix titled 'ANSI implementation-specific standards' my
Borland C++ 3.1 manual has an entry specifying 'The order of allocation
of bit fields within an int.'

Re: Flags in Ada?

[tmoran]

>Most of the techniques that have been proposed for this use packed
>boolean and representation specs within the visibile part of the
>package spec.  My experience is that this can be a dangerous approach,
>particularly for portability.
>
  ...
> package POSIX is
>  ...
>    type Option_Set is private;

Where is the conceptual focus?  If the important object is the set of
flags (Option_Set here), then certainly it should be dealt with as an
entity - either hiding the implementation details as per your example
or exposing it as an array of booleans (packed if interfacing or
other reasons so indicate).  But if the 'flags' are in fact logically
heterogenous data, that just happen to be tossed together to match
some external interface, then, like all heterogeneous data, they should
be in a record, not an array.  If it's just an interfacing requirement
that names and places the bits, it seems to me that like all system
dependencies their specification should be buried inside a package which
exports a clean, logical, and portable view of their relevant information.

Re: Flags in Ada?

[Henri Altarac]

Be careful with address clauses. If your type involves any implicit 
initialization, then the compiler may generate a call to a 
Type-support-subprogram.

-----
Henri Altarac 		haltarac@rain.org

Re: Flags in Ada?

[Norman H. Cohen]

In article <38mle1$e3m@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar)
writes: 
|> well to me Dave's approach seems overkill
|>
|> I really don't see the objection to a packed record.

The original question asked how to provide for logical operations among
corresponding flags in different flag sets.  Packed arrays of Booleans
provide this and packed records of Booleans do not, except with tedious
explicit programming: 

   generic
      with Op (Left, Right: Boolean) return Boolean;
   function Packed_Record_Op;

   function Packed_Record_Op
      (Left, Right: Packed_Record_Type) return Packed_Record_Type is
   begin
      return
         ( Op(Left.Component_1, Right.Component_1),
             ...,
           Op(Left.Component_N, Right.Component_N) );
   end Packed_Record_Op;

   function "and" is new Packed_Record_Op("and");
   function "or"  is new Packed_Record_Op("or");
   function "xor" is new Packed_Record_Op("xor");

   function "not" (Right: Packed_Record_Op) return Packed_Record_Op is
   begin
      return (not Right.Component_1, ..., not Right.Component_N);
   end "not";

Still, if you require explicit control over the mapping of Booleans in
such an array to specific bits in a word (for the sake of a low-level
external interface), only record representation clauses can provide them.

It is unfortunate that there is no portable way to indicate whether,as
index values increase, the positions of components in a packed array of
Booleans go from LSB to MSB or MSB to LSB.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Flags in Ada?

[Robert Dewar]

That's quite right, C does NOT specify how the bits are layed out. It lacks
anything equivalent to record rep clauses, and this can often be a real pain
when interfacing to external hardware. The bit fields of C correspond most
closely to Ada in which you have given the size of each component and then
you say pragma Pack for the record. There is no guarantee here either of
any specific ordering or layout, although simple cases, like 8 booleans in
a byte, should certainly work, but the ordering of the fields will still be
indeterminate.

What is true is that if you use pragma Convention (C,..) on such a type in
Ada 9X, then this packed record should be layed out the same way that C
would lay it out, whatever that is, and for some applications it is this
correspondence with the way some other language does things that is important,
not the specific layout. As I noted before, in GNAT, Ada and C by default
share the same convention for data layout, so pragma Converion (C, ...)
would do nothing.

Of course if you *do* need to specify the exact layout, then you are in
much better shape in Ada, because of the record representation clause.
The Bit_Order capability of Ada 9X further adds to the degree of control
that is the hands of an Ada programmer. This is one of the respects in 
which people who make the common assumption that C is somehow inherently
better than Ada for low level systems stuff are quite wrong, in this
particular area, Ada has much stronger tools than C. Of course you need
a decent Ada compiler that implements all these tools correctly, and
in the past, there have been some legitimate complaints in this area, but
the cure is to insist on better implementations, not to complain about
non-existent shortcomings in the language itself.

Re: Flags in Ada?

[Robert Dewar]

I certainly agree that normally a record is a better representation of a
set of heterogenous flags. The justifications for using an array are to
take advantage of the boolean array operators, if the flags are really
homogenous, or if indexing will be useful (again implying homogenous
flags).

Note that in Ada 9X, yet a third possibility is to use unsigned (modular)
numbers, which also have logical operations defined, with constant values
for the bits. This of course is even more low-level (and C-like, although
in C, bit specs are being more widely used these days), but may be
appropriate for algorithms where arithmetic and logical operations are
intermixed in wierd ways.

Re: Flags in Ada?

[John Volan]

The way I understand it, applying pragma Pack to a record type will
only guarantee that the record type will be optimized for space.  I
don't think there's anything in the language definition that requires
a compiler to preserve the order of the components.  In fact, RM9X
13.2(8);5.0 states that an implementation may reorder components to
improve the packing.

I grant you that the most straightforward implementation of Pack would
simply pack the components in the order they were originally declared,
and I expect that that's the way GNAT deals with it.  Nevertheless, I
can imagine some super-optimizing compiler that juggled the components
around to get a better fit.  

So if you have an external requirement that each component occupy
specific positions, such as when you're communicating with hardware or
operating-system services, then I think you'd need to use a
representation clause.  You can't just rely on the components being
stored in the order you declared them.

--------------------------------------------------------------------------------
--  Me : Person := (Name                => "John Volan",
--                  Company             => "Raytheon Missile Systems Division",
--                  E_Mail_Address      => "jgv@swl.msd.ray.com",
--                  Affiliation         => "Enthusiastic member of Team Ada!",
--                  Humorous_Disclaimer => "These opinions are undefined " &
--                                         "by my employer and therefore " &
--                                         "any use of them would be "     &
--                                         "totally erroneous.");
--------------------------------------------------------------------------------

Re: Flags in Ada?

[Norman H. Cohen]

In article <38nces$bdv@news.delphi.com>, tmoran@bix.com (quoting
Robert Dewar) writes: 

|> >As I noted in a previous message, pragma pack should work just fine on
|> >records, it is NOT necessary to give record representation clauses unless
|> >they are needed to match an external specification. In Ada 9X in particular,
|> >one would assume that even in the latter case, the use of: 
|> >
|> > pragma COnvention (C, rectype);
|>
|> >should be adequate to ensure a match up with the C type. In GNAT, convention
|> >C is the default (i.e. for datatypes that match, convention Ada and
|> >convention C are identical), so it works even in the absnece of this
|> >pragma.
|>
|> Does 'C' specify how the bit fields are arranged?

No.  ANSI C states that there is an implementation-defined "allocation
unit" (this is typically the size of a register that can be used in
shift/rotate and masking instructions) and that bit fields are to be
packed as tightly as possible into an allocation unit.  However, the size
of the allocation unit, the option of advancing to the start of the next
allocation unit if there is not enough room to fit the next bit field in
the current allocation unit, and the direction in which allocation units
are filled with bit fields (MSB->LSB or LSB->MSB) is explicitly
implementation-defined.  (Only the last issue, the direction in which
allocation units are filled, is relevant when all bit fields are one bit
long.)

The "language name" in the Convention pragma is really better understood
as a "language processor name".  When you ask a Gnu Ada compiler to use C
conventions, you are asking it to use the conventions of the Gnu C
compiler.  (A compiler can provide different convention names for
different C compilers, as long as the standard convention name "C"
applies to one of them.)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Flags in Ada?

[Henry G. Baker]

Don't flags in Ada have to be saluted?  (Sorry; I couldn't resist.)

      Henry Baker
      Read ftp.netcom.com:/pub/hbaker/README for info on ftp-able papers.

Re: Flags in Ada?

[Robert Dewar]

I think it is quite wrong for a compiler to initialize or otherwwise pester
values with address clauses as a result of calling type support subprorams.

Re: Flags in Ada?

[Tucker Taft]

In article <38ob12$7po@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
> ...
>Note that in Ada 9X, yet a third possibility is to use unsigned (modular)
>numbers, which also have logical operations defined, with constant values
>for the bits. This of course is even more low-level (and C-like, although
>in C, bit specs are being more widely used these days), but may be
>appropriate for algorithms where arithmetic and logical operations are
>intermixed in wierd ways.

One advantage of the modular types in Ada 9X is that they are "strong" 
types, just like all Ada numeric types.  This means that you can define
a "mask" for a particular modular type and be sure it is only
used to "and" with values of that type.  For example:

    type Control_Byte is mod 2**8;
    Start_Read_Bit  : constant Control_Byte := 2#1000_0000#;
    Start_Write_Bit : constant Control_Byte := 2#0100_0000#;
    Reset_All       : constant Control_Byte := 2#0000_0001#;

    type Status_Byte is mod 2**8;
    Char_Ready_Bit  : constant Status_Byte := 2#1000_0000#;
    Char_Mask       : constant Status_Byte := 2#0111_1111#;

    type Device_Type is record
        Status : Status_Byte;
        Control : Control_Byte;
    end record;
    pragma Convention(Assembler, Device_Type);

    Console : Device_Type;
    pragma Import(Assembler, Console);
    for Console'Address use 16#FFFF_F200#;
    pragma Volatile(Console);

 begin
   -- Reset console, then initiate read.
    Console.Control := Reset_All;
    Console.Control := Start_Read_Bit;

   -- busy wait until character ready, and then get character
    while (Console.Status and Char_Ready_Bit) = 0 loop
      -- busy wait (could keep a count to avoid an infinite loop)
        null;
    end loop;
    Next_Char := Console.Status and Char_Mask;

   ... -- etc.

Although record rep clauses would work just as well, the above
approach illustrates how modular types can be used, while still
getting a measure of safety.  The compiler will complain if you
use a Status_Byte mask on the Control register, or vice-versa.
Also, Ada's binary notation comes in quite handy for this kind
of bit twiddling.  In some ways using masks defined in binary
notation is more "graphic" than record rep clauses, making them
a little "bit" easier to read. ;-)

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.

Re: Flags in Ada?

[Robert Dewar]

"you are asking it [GNAT] to use the GNU C [conventions] .."

True, but an important part of the GCC design is that it tries to stay as
close as possible to system standards, and one of the requirements that is
aimed at is smooth interoperability with the manufacturers C compiler if
there is one, so that programs can be built in GNU C using libraries 
compiled with the manufacturers C compiler.

Now in some environments like the PC, there is more than one C compiler in
use, but there is less variation than you might think even here in data
layouts, because everyone is interested in interoperability.

Certainly on most targets you will find that the data layouts used by GNAT
correspond not only to GNU C, but also to other C compilers on the target.
This isn't guaranteed, just something that is aimed at, and nearly always
achieved.

Re: Flags in Ada?

[tmoran]

Some downsides of using 9X modular types:

 Console.Control := Start_Read_Bit;
may look correct, but perhaps what you really wanted was
 Console.Control := Console.Control or Start_Read_Bit;

Using records, those two are done with less ambiguity with
 Console.Control := Start_Read_OP_Code;
 Console.Control.Start_Read := True;

>...  a measure of safety.  The compiler will complain if you
>use a Status_Byte mask on the Control register, or vice-versa.

But    Console.Control := Console.Control*3;   is legal, though
perhaps not what you meant to code.  And there is a temptation
to do arithmetic (shift, for instance) to accomplish things.
In some circumstances that's fine, and even a good reason to use
modular types rather than records, but it clearly locks you
into a certain bit representation.  There are plenty of programmers
in the world who will do 'clever' arithmetic to juggle bits. :(

Re: Flags in Ada?

[Robert Dewar]

To follow up tmoran's comment [sorry I can't find the real name in the
message], I absolutely agree that the use of modular types for flag mucking
is usually inappropriate, this is also very much true in C.

Nevertheless there are cases where mixed integer and logical operations
are handy. Consider for instance the following

with text_io; use text_io;
procedure c is
   type m is mod 2**8;
   x : m := 2#10100000#;
   c : natural := 0;

begin
   -- count number of bits on in x

   while x /= 0 loop
      c := c + 1;
      x := x and (x - 1);
   end loop;

   put_line (c'img);
end c;

this is a very efficient algorithm for counting bits (the number of loops
is the number of one bits).

this sort of "trick" is why logical operations have been provided for
modular types. The trouble of course is that once they are available,
they are subject to tremendous abuse, especially from C programmers
used to committing the same kind of abuse in C. Coding standards should
stress that the use of logical operations on modular types should be
very much restricted to specialized cases of this type.

P.S. in case you are wondering, 'Img is a GNAT implementation defined
attribute that can be applied to objects as well as being used with a
subtype name like Image. The output differs only in that the darned blank
is omitted for positive values. Eventually we want to extend Img to handle
various types, e.g. arrays, but this is not done yet.

P.P.S. I am embarrassed to admit that the first time I compiled this program,
I received the following error diagnostic:

    12.       x := x & (x - 1);
                     |
        >>> invalid operand types for operator "&"

maybe we should special case this message to something like
"and" expected here :-)

Re: Flags in Ada?

[Robert Dewar]

It is true that it is a bit awkward to define bit strings for the record
representation case. Yes, I know that a nice named notation is often
better anyway, but if you are just copying down bit strings it is sometimes
useful to spell them that way.

Note that if you use a packed array, then you can (with appropriate
declarations), use constants that look like

  "01000101"

which is quite nice.

Re: Flags in Ada?

[David Emery]

>insist on compilers that have this feature if you need it, it's
>required by the language definition.

There has been a lot of disagreement within the Ada83 community on the
'enforcability' of Chapter 13 requirements...  My practical experience
is that a lot of work is needed to get the portability I want in
Ada83, given the current set of compilers.  

Maybe Ada9X will be different, but just because the LRM says something
is no particular guarantee that all compilers implement it correctly.

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: Flags in Ada?

[David Emery]

>I think it is quite wrong for a compiler to initialize or otherwwise pester
>values with address clauses as a result of calling type support subprorams.

Unfortunately, at least one widely-used compiler does this, despite
protests from users (like me!)

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: Flags in Ada?

[Norman H. Cohen]

In article <38qv61$ff4@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar)
writes: 

|> P.S. in case you are wondering, 'Img is a GNAT implementation defined
|> attribute that can be applied to objects as well as being used with a
|> subtype name like Image. The output differs only in that the darned blank
|> is omitted for positive values. Eventually we want to extend Img to handle
|> various types, e.g. arrays, but this is not done yet.

Yes, that blank is a real pain.  But since you're eliminating the
leftmost character of the Image string, you should have called the
attribute 'Mage.  That sounds much hipper. :-)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Flags in Ada?

[Mats Weber]

In article <392udo$jt4@watnews1.watson.ibm.com>, ncohen@watson.ibm.com wrote:
> |> P.S. in case you are wondering, 'Img is a GNAT implementation defined
> |> attribute that can be applied to objects as well as being used with a
> |> subtype name like Image. The output differs only in that the darned blank
> |> is omitted for positive values. Eventually we want to extend Img to handle
> |> various types, e.g. arrays, but this is not done yet.

I think that adding implementation-specific attributes is a VERY bad idea
even, as in this case, they are useful.

The problem is that they don't need to be imported using a with clause,
and it is impossible to assess the portability of code written for that
compiler.

Re: Flags in Ada?

[Robert Dewar]

Regarding the choice of our name (Img) [and norman's nice suggestion of mage]
the reason we chose Img was because we thought there was a rule in Ada
requiring attribute names to be abbrevaitions (Succ, Pred, Min, Max, ...)

:-) :-)

Re: Flags in Ada?

[Robert Dewar]

We have lots of implementation dependent attributes and pragmas, and yes
it is true that they compromise protability. We are planning to have
them controlled by the -pedantic GCC switch which would make them
unavailable, thus answering Mats (quite legitimate) concern.