Storage space question

Storage space question

[Craig Allen]

Hello!

the short version of my question is this:  If I'm using enumerations 
to
define names that will represent specific bit patterns that my program
may
wish to use, do *all* these bit patterns allocate space? e.g.  with 
this:

   type DCD_Mode_Type is
      (CARRIER_DETECT, SYNC_DETECT, LOW, HIGH);
   for DCD_Mode_Type'Size use 2;
   for DCD_Mode_Type use
      (CARRIER_DETECT => 2#00#,
       SYNC_DETECT    => 2#01#,
       LOW            => 2#10#,
       HIGH           => 2#11#
       );

is space allocated for each of these definitions?  I ask because I 
added
many of these types to a package I'm writing, and my memory map seems 
to
have grown even without using these types yet.  
I'd like to have these names available for use, but taking no more 
space
than what is necessary (like #define in C...) (I would only be using 1
definition per application, no need for space declared for all 
definitions...)

I'm using Ada 83, but I don't think that matters.

Thanks.
-Craig

Re: Storage space question

[Marin David Condic]

Craig Allen wrote:
> 
> Hello!
> 
> the short version of my question is this:  If I'm using enumerations
> to
> define names that will represent specific bit patterns that my program
> may
> wish to use, do *all* these bit patterns allocate space? e.g.  with
> this:
> 
>    type DCD_Mode_Type is
>       (CARRIER_DETECT, SYNC_DETECT, LOW, HIGH);
>    for DCD_Mode_Type'Size use 2;
>    for DCD_Mode_Type use
>       (CARRIER_DETECT => 2#00#,
>        SYNC_DETECT    => 2#01#,
>        LOW            => 2#10#,
>        HIGH           => 2#11#
>        );
> 
> is space allocated for each of these definitions?  I ask because I
> added
> many of these types to a package I'm writing, and my memory map seems
> to
> have grown even without using these types yet.
> I'd like to have these names available for use, but taking no more
> space
> than what is necessary (like #define in C...) (I would only be using 1
> definition per application, no need for space declared for all
> definitions...)
> 
> I'm using Ada 83, but I don't think that matters.
> 
> Thanks.
> -Craig

This is going to be a compiler dependent question, so maybe you need to
post which compiler you are using.

In general, a type does not require any space. Only when you declare
objects of the type is memory allocated. However, the rules of Ada
require that certain information be available at run time concerning a
type, which means the compiler has to keep that information somewhere -
hence memory utilization. Remember that for a given enumeration type T,
Ada has a function T'Image which has to return the character string
associated with the given value (id est, "CARRIER_DETECT",
"SYNC_DETECT", etc.) I don't think that the representation clauses would
have any impact on storage, but maybe one of the compiler-writers in the
crowd can fill us in.

If you've got a good avionics-quality, embedded target, Ada compiler,
I'd expect it to have switches/options to disable some of this storage
allocation. In most compilers of this sort, if you promise not to ask
certain kinds of questions the compiler will agree to make
smaller/faster code, so look into the implementation defined pragmas and
compiler options.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Transported to a surreal landscape, a young girl kills the first woman
she meets and then teams up with three complete strangers to kill
again."

        -- TV listing for the Wizard of Oz

Re: Storage space question

[Matthew Heaney]

Marin David Condic <condicma@bogon.pwfl.com> writes:

> If you've got a good avionics-quality, embedded target, Ada compiler,
> I'd expect it to have switches/options to disable some of this storage
> allocation. In most compilers of this sort, if you promise not to ask
> certain kinds of questions the compiler will agree to make
> smaller/faster code, so look into the implementation defined pragmas and
> compiler options.

Not implementation-defined, standard-defined: pragma Discard_Names
throws away the tables containing the images of enumeration literals.

Re: Storage space question

[dennison]

In article <m3vhjk53rs.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> Marin David Condic <condicma@bogon.pwfl.com> writes:
>
> > allocation. In most compilers of this sort, if you promise not to ask
> > certain kinds of questions the compiler will agree to make
> > smaller/faster code, so look into the implementation defined pragmas and
> > compiler options.
>
> Not implementation-defined, standard-defined: pragma Discard_Names
> throws away the tables containing the images of enumeration literals.

Craig said he is using an Ada *83* compiler. In my copy of the Ada 83
standard there is nothing in Appendix B between CONTROLLED and ELABORATE.
That would make any such pragma implementation defined, as Marin stated.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Storage space question

[Pat Rogers]

Marin David Condic wrote in message <366FE278.FAF73497@pwfl.com>...
>Craig Allen wrote:
>>
>> Hello!
>>
>> the short version of my question is this:  If I'm using
enumerations
>> to define names that will represent specific bit patterns that my
program
>> may wish to use, do *all* these bit patterns allocate space? e.g.
with
>> this:


<snip>

>In general, a type does not require any space. Only when you
declare
>objects of the type is memory allocated. However, the rules of Ada
>require that certain information be available at run time
concerning a
>type, which means the compiler has to keep that information
somewhere -
>hence memory utilization. Remember that for a given enumeration
type T,
>Ada has a function T'Image which has to return the character string
>associated with the given value (id est, "CARRIER_DETECT",
>"SYNC_DETECT", etc.) I don't think that the representation clauses
would
>have any impact on storage, but maybe one of the compiler-writers
in the
>crowd can fill us in.


See RM C.5(1) re: pragma Discard_Names

>"Transported to a surreal landscape, a young girl kills the first
woman
>she meets and then teams up with three complete strangers to kill
>again."
>
>        -- TV listing for the Wizard of Oz

:-)

Re: Storage space question

[dennison]

In article <74or0g$lgt$1@remarQ.com>,
  "Pat Rogers" <progers@NOclasswideSPAM.com> wrote:
> Marin David Condic wrote in message <366FE278.FAF73497@pwfl.com>...
> >Ada has a function T'Image which has to return the character string
> >associated with the given value (id est, "CARRIER_DETECT",
>
> See RM C.5(1) re: pragma Discard_Names
>

This is an Ada *83* question. There is no C.5(1) in the Ada 83 LRM, and
neither is there a pragma Discard_Names.


--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Storage space question

[Pat Rogers]

dennison@telepath.com wrote in message
<74p6an$r6v$1@nnrp1.dejanews.com>...
>In article <74or0g$lgt$1@remarQ.com>,
>  "Pat Rogers" <progers@NOclasswideSPAM.com> wrote:
>> Marin David Condic wrote in message
<366FE278.FAF73497@pwfl.com>...
>> >Ada has a function T'Image which has to return the character
string
>> >associated with the given value (id est, "CARRIER_DETECT",
>>
>> See RM C.5(1) re: pragma Discard_Names
>>
>
>This is an Ada *83* question. There is no C.5(1) in the Ada 83 LRM,
and
>neither is there a pragma Discard_Names.


Mea culpa.  Or, perhaps more to your liking (from Blackadder's
Christmas Carol):

Edmund: ... and perhaps Lord Melchett would like to whip me naked
through the streets of Aberdeen...

Melchett: Oh, I don't think we need go that far, Blackadder...

Edmund: Oh, too kind...

Melchett: No -- Aylesbury's quite far enough.

Re: Storage space question

[Tucker Taft]

Marin David Condic (condicma@bogon.pwfl.com) wrote:
: Craig Allen wrote:
: > 
: > the short version of my question is this:  If I'm using enumerations
: > to
: > define names that will represent specific bit patterns that my program
: > may
: > wish to use, do *all* these bit patterns allocate space? e.g.  with
: > this:
: > 
: >    type DCD_Mode_Type is
: >       (CARRIER_DETECT, SYNC_DETECT, LOW, HIGH);
: >    for DCD_Mode_Type'Size use 2;
: >    for DCD_Mode_Type use
: >       (CARRIER_DETECT => 2#00#,
: >        SYNC_DETECT    => 2#01#,
: >        LOW            => 2#10#,
: >        HIGH           => 2#11#
: >        );
: > 
: > is space allocated for each of these definitions?  
: ...
: If you've got a good avionics-quality, embedded target, Ada compiler,
: I'd expect it to have switches/options to disable some of this storage
: allocation. 

In Ada 95, there is a language-defined pragma "Discard_Names"
designed to suppress the generation of the enumeration
"image" tables (and other similar run-time string names).
The pragma is described in RM95 C.5.  For the above example,

   pragma Discard_Names(On => DCD_Mode_Type);

would do the trick.

Note also that by specifying the representation of the
enumeration type, you run the danger of imposing additional
space and time overhead due to the internal conversions between 
enumeration position number and integer code.  In the above case,
all bit patterns are used consecutively, and hopefully 
your compiler is clever enough to recognize this special case.

However, there have been compilers which did not recognize
this special case, and in any case, if you have any "holes"
in the representation, the compiler will probably end up
creating a table (or tables) for converting between position
number and integer code.

The "Ravenscar" profile, which is supported by some Ada 95 compilers,
includes a restriction:

   pragma Restrictions(No_Enumeration_Maps);

which should suppress these tables, and flag any place
where a conversion between position number and integer code
would be required.

: Marin David Condic
: Real Time & Embedded Systems, Propulsion Systems Analysis
: United Technologies, Pratt & Whitney, Large Military Engines
: M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
: Ph: 561.796.8997         Fx: 561.796.4669

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: Storage space question

[callen]

2nd attempt at posting - sorry if posted twice...

In article <F3rBC7.JAr.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> Marin David Condic (condicma@bogon.pwfl.com) wrote:
> : Craig Allen wrote:
> : >
> : > the short version of my question is this:  If I'm using enumerations
> : > to
> : > define names that will represent specific bit patterns that my program
> : > may
> : > wish to use, do *all* these bit patterns allocate space? e.g.  with
> : > this:
> : >
> : >    type DCD_Mode_Type is
> : >       (CARRIER_DETECT, SYNC_DETECT, LOW, HIGH);
> : >    for DCD_Mode_Type'Size use 2;
> : >    for DCD_Mode_Type use
> : >       (CARRIER_DETECT => 2#00#,
> : >        SYNC_DETECT    => 2#01#,
> : >        LOW            => 2#10#,
> : >        HIGH           => 2#11#
> : >        );
> : >
> : > is space allocated for each of these definitions?
> : ...
> : If you've got a good avionics-quality, embedded target, Ada compiler,
> : I'd expect it to have switches/options to disable some of this storage
> : allocation.
>
> In Ada 95, there is a language-defined pragma "Discard_Names"
> designed to suppress the generation of the enumeration
> "image" tables (and other similar run-time string names).
> The pragma is described in RM95 C.5.  For the above example,
>
>    pragma Discard_Names(On => DCD_Mode_Type);
>
> would do the trick.
>

OK, well, I am using Ada83.

> Note also that by specifying the representation of the
> enumeration type, you run the danger of imposing additional
> space and time overhead due to the internal conversions between
> enumeration position number and integer code.  In the above case,
> all bit patterns are used consecutively, and hopefully
> your compiler is clever enough to recognize this special case.
>

I don't really mind this, as I don't intend on using the position number for
anything.  This was an unfortunate example, other instances of this that I am
doing have holes, and so must be specified in this way.

OK, well, maybe I'll elaborate a bit more on what it is I'm trying to
accomplish.  I have a hardware device that has registers I will access.  Lets
say one register looks like this (identifiers have been changed to protect the
innocent):


   type REGISTER_1_Type is
   record
      field_1_Ctrl:             t_3bit;
      field_2_Ctrl:             t_3bit;
      field_3_Ctrl:             t_2bit;
      field_4_Ctrl:             t_2bit;
      field_5_Ctrl:             t_2bit;
      DCD_Pin_Ctrl:             t_2bit;
      field_7_Ctrl:             t_2bit;
   end record;

Assume these imaginary t_ types are 3 and 2 bits worth of values respectively.
Now, in order to write to this register, I would write

   Reg.DCD_Pin_Ctrl := 2#01#;

OK, but I'd like to use more descriptive names for these.  Like so.

   Reg.DCD_Pin_Ctrl := SYNC_DETECT;

So, I define and represent the enum above (as 2 separate Ada books have
suggested...).	Now, the code looks nicer, but I have this baggage that came
with it that I don't need.  I really just want the ability to do as a #define
(or enum) would do in C - that is to do the substitution for me to make the
code look nicer, but not increase the memory footprint (over using constants
in the program). The reason is that I would like to make *many* of these. 
For the sake of argument, say there's 100 registers each with 8 bits worth of
possibilities.	I don't want tables with all that info in there, just the 100
values that I'm using to initialize the thing to be put in the right place in
the code. I liked the use of the enumerated types for these, as their
namespaces won't clash (Each register can have it's own DEFAULT for
instance).

Again, I'm using Ada83, and don't see a pragma that will help me.  I
understand and agree with the dislike of preprocessors, but is what I'm
trying to do (which textual subst would work for...) such a bad thing to ask
for?

Thanks again.

> --
> -Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
> Intermetrics, Inc.  Burlington, MA  USA
> An AverStar Company
>

Craig Allen

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Storage space question

[dennison]

In article <74pfg4$3s6$1@nnrp1.dejanews.com>,
  callen@space.honeywell.com wrote:

> accomplish.  I have a hardware device that has registers I will access.  Lets
> say one register looks like this (identifiers have been changed to protect the
> innocent):
>
>    type REGISTER_1_Type is
>    record
>       field_1_Ctrl:             t_3bit;
>       field_2_Ctrl:             t_3bit;

> in the program). The reason is that I would like to make *many* of these.
> For the sake of argument, say there's 100 registers each with 8 bits worth of
> possibilities.	I don't want tables with all that info in there, just
the 100
> values that I'm using to initialize the thing to be put in the right place in

If its the value of the bits themseves that are important rather that the
value of the whole word (iaw: each bit has its own meaning independent of any
other bits), then I'd prefer to use arrays of boolean, indexed by an
enumeration. Note that the boolean operations "and", "or", and "not" will
automaticly work on any array of boolean you create. Yes you still have that
enumeration overhead, but now its just one string per bit, instead of 2^X
strings for X bits.

> Again, I'm using Ada83, and don't see a pragma that will help me.  I
> understand and agree with the dislike of preprocessors, but is what I'm
> trying to do (which textual subst would work for...) such a bad thing to ask
> for?

What you can do to get a similar effect (no runtime storage) in Ada is to use
named-numbers. eg:

Begin_Twadling : constant := 2#10010011#;

Unfortunately, this only works for Integeral types in Ada 83, and Ada 83
Integers are not really suited for this kind of use.

Fortunately, most Ada 83 compilers will treat many normal constants the same
as named numbers (iaw: no runtime storage) when they see that they can. This
sounds like what you are asking for.

Several people have pointed out that all this is easier in Ada 95. Yes there
are the pragmas. Also there's a modular Integer type that you can use your
named numbers with. Its a shame you can't upgrade.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Storage space question

[Marin David Condic]

<snip>
> 
> Again, I'm using Ada83, and don't see a pragma that will help me.  I
> understand and agree with the dislike of preprocessors, but is what I'm
> trying to do (which textual subst would work for...) such a bad thing to ask
> for?
<snip>

I've done exactly this in any number of situations. Enumerations are
definitely "The Ada Way" of solving this problem, so naturally you want
to try to do this. However, if you're suffering a memory penalty - and
using Ada83 - there is no "conventional" way I know of to turn off
storage of all the stuff you don't want. But most embedded compilers
give you some means of doing this anyway - you need to tell us what
particular compiler you are using.

If you can't find an answer in the compiler-specific documentation, you
can always get there through the
less-desirable-but-no-worse-than-C-does-it method of declaring a bunch
of named numbers:

Some_Name : constant := 2#0101# ;

It does, as you observe, have name-space problems, but it will get you
there. I'd still urge you to check the compiler documentation (and let
us know the Manufacturer, Host, Target and Version - if possible because
someone else has probably been there already) because this is hardly a
new problem and is something most vendors accounted for in some way.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Transported to a surreal landscape, a young girl kills the first woman
she meets and then teams up with three complete strangers to kill
again."

        -- TV listing for the Wizard of Oz

Re: Storage space question

[Tucker Taft]

Marin David Condic (condicma@bogon.pwfl.com) wrote:

: ...
: If you can't find an answer in the compiler-specific documentation, you
: can always get there through the
: less-desirable-but-no-worse-than-C-does-it method of declaring a bunch
: of named numbers:

: Some_Name : constant := 2#0101# ;

: It does, as you observe, have name-space problems, but it will get you
: there. 

Actually, rather than using named numbers, I would recommend
using named constants of a derived integer type devoted to this
particular machine register.  This way, you would at least 
get some type checking when you have more than one such machine
register.

E.g.:
   type DMA_Register_Command is range 0..2#1111#;
   
   Start_DMA_Transfer : constant DMA_Register_Command := 2#0101#;
   ... 

Personally, I would only use enumerations for things which are
clearly enumerable.  Machine registers often use combinations of
bits, which are easily done with "+" for integers (or with "or"
in Ada 95 on modular types), but not easily done with enumeration types.

: MDC
: -- 
: Marin David Condic
: Real Time & Embedded Systems, Propulsion Systems Analysis
: United Technologies, Pratt & Whitney, Large Military Engines
: M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
: Ph: 561.796.8997         Fx: 561.796.4669
: ***To reply, remove "bogon" from the domain name.***

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: Storage space question

[dennison]

In article <F3ruDu.Cr1.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> Marin David Condic (condicma@bogon.pwfl.com) wrote:
>
> : ...
> : If you can't find an answer in the compiler-specific documentation, you
> : can always get there through the
> : less-desirable-but-no-worse-than-C-does-it method of declaring a bunch
> : of named numbers:
>
> : Some_Name : constant := 2#0101# ;
>
> Actually, rather than using named numbers, I would recommend
> using named constants of a derived integer type devoted to this

Technicly, such constants are considered objects. Thus 'address is valid on
them, which means the compiler allocates runtime storage (which was his
problem with enumerations). In practice, the embedded compilers I have used
would treat such constants the same as named numbers, as long as you are
willing to declare them in a certian way, and not try a 'address on them. But
if he doesn't want *any* allocations for these things, it would be best to
check the compiler docs before using anthing other than named-numbers.

BTW: In order to get around the "namespace problems", you could declare each
register in its own package spec (and not use "use" clauses on them, of
course).

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Storage space question

[Matthew Heaney]

Marin David Condic <condicma@bogon.pwfl.com> writes:

> I've done exactly this in any number of situations. Enumerations are
> definitely "The Ada Way" of solving this problem, so naturally you want
> to try to do this. 

I don't necessarily agree.  Giving enumeration types a representation
clause seems to be of dubious value.

> If you can't find an answer in the compiler-specific documentation, you
> can always get there through the
> less-desirable-but-no-worse-than-C-does-it method of declaring a bunch
> of named numbers:
> 
> Some_Name : constant := 2#0101# ;

But that's going too far, because you've turned off all the type
checks.  

A middle position between named numbers and enumeration types is
constants of a integer type:

  type Robot_Control is range 0 .. 3;

  Run_Robot : constant Robot_Control := 0;

  Stop_Robot : constant Robot_Control := 1;

  Turn_Robot : constant Robot_Control := 3;


  type Control_Register is
    record
      ...
      Control : Robot_Control;
      ...
   end record;


As long as you only use the constants (not the literals), you get all
the type safety that an enumeration type buys you.

Which is why rep clauses for enumeration types is overkill, that adds
unnecessary complexity to the language.

Re: Storage space question

[Marin David Condic]

Matthew Heaney wrote:
> 
> Marin David Condic <condicma@bogon.pwfl.com> writes:
> 
> > I've done exactly this in any number of situations. Enumerations are
> > definitely "The Ada Way" of solving this problem, so naturally you want
> > to try to do this.
> 
> I don't necessarily agree.  Giving enumeration types a representation
> clause seems to be of dubious value.

I was referring to using enumerations in general to represent values for
fields in a register - not necessarily with a representation clause.
Fields in special registers are quite often naturally reflected by an
enumeration. (Off, Standby, On) or even op-codes in machine instructions
are examples. Other times, fields represent some sort of count -
Watchdog_Timer_Resets => 0..7 might be an example. If the bit-patterns
are labeled with some mnemonic in the hardware documentation, then
enumerations are a very natural way of representing that. If they are
contiguous starting at zero - save your rep clause work. If not
contiguous, then the rep clause suits it well. As long as your compiler
implementation is reasonably efficient about it, I see no reason to
resort to named numbers or constants since they are going to be less
type-safe. 

> 
> > If you can't find an answer in the compiler-specific documentation, you
> > can always get there through the
> > less-desirable-but-no-worse-than-C-does-it method of declaring a bunch
> > of named numbers:
> >
> > Some_Name : constant := 2#0101# ;
> 
> But that's going too far, because you've turned off all the type
> checks.

Sure. I wouldn't normally adopt this method at all because all of the
embedded compilers I've got for my real time hardware do a reasonable
job of implementing enumerations. My point was that if compiler A does a
lousy job with enumerations or you can't find out how to tell compiler A
to do a better job _you_are_no_worse_off_than_you_are_with_C_. You can
always resort to a C sort of implementation, so there should be no
reason to claim "I can't do this as efficiently as I can with C". Of
course, there will be issues of constant folding with named numbers
which may be undesirable and you'll want to go with a constant
declaration and some flavor of pragma Volatile (Ada83 doesn't have it
but lots of vendors found a way to give it to us.)

> 
> A middle position between named numbers and enumeration types is
> constants of a integer type:
> 
>   type Robot_Control is range 0 .. 3;
> 
>   Run_Robot : constant Robot_Control := 0;
> 
>   Stop_Robot : constant Robot_Control := 1;
> 
>   Turn_Robot : constant Robot_Control := 3;
> 
>   type Control_Register is
>     record
>       ...
>       Control : Robot_Control;
>       ...
>    end record;
> 
> As long as you only use the constants (not the literals), you get all
> the type safety that an enumeration type buys you.
> 
> Which is why rep clauses for enumeration types is overkill, that adds
> unnecessary complexity to the language.

Well, not quite all the type safety. Suppose that the field occupies 3
bits but only the values 0, 1 and 2 are currently valid. Or worse, only
the values 2#001#, 2#010# and 2#100# are valid. With an integer type,
there is no way of eliminating the invalid values. With enumerations,
you can't accidentally get an invalid bit pattern assigned to the
register field.

Granted, an integer type restricted to the field size & range is better
than nothing. But I still think enumerations are more often the natural
expression of this unless the field represents a count of something.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Transported to a surreal landscape, a young girl kills the first woman
she meets and then teams up with three complete strangers to kill
again."

        -- TV listing for the Wizard of Oz

Re: Storage space question

[Matthew Heaney]

Marin David Condic <condicma@bogon.pwfl.com> writes:

> > As long as you only use the constants (not the literals), you get all
> > the type safety that an enumeration type buys you.
> > 
> > Which is why rep clauses for enumeration types is overkill, that adds
> > unnecessary complexity to the language.
> 
> Well, not quite all the type safety. Suppose that the field occupies 3
> bits but only the values 0, 1 and 2 are currently valid. Or worse, only
> the values 2#001#, 2#010# and 2#100# are valid. With an integer type,
> there is no way of eliminating the invalid values. With enumerations,
> you can't accidentally get an invalid bit pattern assigned to the
> register field.

"As long as you only use the constants (not the literals), you get all
the type safety that an enumeration type buys you."

The object will never get assigned the values 3 .. 7, because those
values aren't named by constants.

If you stick to the constants, then there is no loss of type safety.

Re: Storage space question

[David C. Hoos, Sr.]

Matthew Heaney wrote in message ...
>Marin David Condic <condicma@bogon.pwfl.com> writes:
>
>> > As long as you only use the constants (not the literals), you get all
>> > the type safety that an enumeration type buys you.
>> >
>> > Which is why rep clauses for enumeration types is overkill, that adds
>> > unnecessary complexity to the language.
>>
>> Well, not quite all the type safety. Suppose that the field occupies 3
>> bits but only the values 0, 1 and 2 are currently valid. Or worse, only
>> the values 2#001#, 2#010# and 2#100# are valid. With an integer type,
>> there is no way of eliminating the invalid values. With enumerations,
>> you can't accidentally get an invalid bit pattern assigned to the
>> register field.
>
>"As long as you only use the constants (not the literals), you get all
>the type safety that an enumeration type buys you."
>
>The object will never get assigned the values 3 .. 7, because those
>values aren't named by constants.
>
>If you stick to the constants, then there is no loss of type safety.
>
Well, what if the data structure was filled by, say, a read from a network.
Use of the enumeration allows you to apply the 'valid test.

Re: Storage space question

[Matthew Heaney]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

> Matthew Heaney wrote in message ...
> >"As long as you only use the constants (not the literals), you get all
> >the type safety that an enumeration type buys you."
> >
> >The object will never get assigned the values 3 .. 7, because those
> >values aren't named by constants.
> >
> >If you stick to the constants, then there is no loss of type safety.
> >
> Well, what if the data structure was filled by, say, a read from a network.
> Use of the enumeration allows you to apply the 'valid test.

Yes, but you can validate input data by using a case statement, just
like we did in Ada83:

X : <unconstrained integer subtype>;

Read (fd, X);

case X is
   when Run | Stop | Turn =>
     <data OK>

   when others =>
     <handle bad data somehow>

end case;

Like representation clauses for enumeration types, the Valid attribute
just adds unnecessary complexity to the language.  

Re: Storage space question

[dennison]

In article <74tr9g$ei4$1@tsunami.traveller.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
>
> Well, what if the data structure was filled by, say, a read from a network.
> Use of the enumeration allows you to apply the 'valid test.

Not for the origonal poster. He's using Ada 83.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Storage space question

[Matthew Heaney]

callen@space.honeywell.com writes:

> OK, well, maybe I'll elaborate a bit more on what it is I'm trying to
> accomplish.  I have a hardware device that has registers I will
> access.  Lets say one register looks like this (identifiers have been
> changed to protect the innocent):
> 
> 
>    type REGISTER_1_Type is
>    record
>       field_1_Ctrl:             t_3bit;
>       field_2_Ctrl:             t_3bit;
>       field_3_Ctrl:             t_2bit;
>       field_4_Ctrl:             t_2bit;
>       field_5_Ctrl:             t_2bit;
>       DCD_Pin_Ctrl:             t_2bit;
>       field_7_Ctrl:             t_2bit;
>    end record;
> 
> Assume these imaginary t_ types are 3 and 2 bits worth of values
> respectively.  Now, in order to write to this register, I would write
> 
>    Reg.DCD_Pin_Ctrl := 2#01#;
> 
> OK, but I'd like to use more descriptive names for these.  Like so.
> 
>    Reg.DCD_Pin_Ctrl := SYNC_DETECT;
> 
> So, I define and represent the enum above (as 2 separate Ada books
> have suggested...). Now, the code looks nicer, but I have this baggage
> that came with it that I don't need.  I really just want the ability
> to do as a #define (or enum) would do in C - that is to do the
> substitution for me to make the code look nicer, but not increase the
> memory footprint (over using constants in the program). The reason is
> that I would like to make *many* of these.  For the sake of argument,
> say there's 100 registers each with 8 bits worth of possibilities. I
> don't want tables with all that info in there, just the 100 values
> that I'm using to initialize the thing to be put in the right place in
> the code. I liked the use of the enumerated types for these, as their
> namespaces won't clash (Each register can have it's own DEFAULT for
> instance).
> 
> Again, I'm using Ada83, and don't see a pragma that will help me.  I
> understand and agree with the dislike of preprocessors, but is what
> I'm trying to do (which textual subst would work for...) such a bad
> thing to ask for?


Then just ditch the enumeration type, and use named constants of an
integer type:

  type CDC_Control is range 0 .. 3;

  Sync_Control : constant CDC_Control := 2#01#;
 
  ...


You don't really need enumeration types that have rep clauses; most of
the time an integer type will do.

Re: Storage space question

[dennison]

In article <9v6hGdgMLuwN-pn2-v5sq1RxFJ1z1@dt182n2f.tampabay.rr.com>,
  cpallen@nospam.com (Craig Allen) wrote:
> Hello!
>
> the short version of my question is this:  If I'm using enumerations
> to
> define names that will represent specific bit patterns that my program
> may
> wish to use, do *all* these bit patterns allocate space? e.g.  with
...
> is space allocated for each of these definitions?  I ask because I
> added
> many of these types to a package I'm writing, and my memory map seems
> to
> have grown even without using these types yet.

There is an attribute available for every enumeration type, "'image", which
returns the string reprenentation of a given enumeration value. If you think
about it, the only way to implement this is to build a mapping between the
enumeration values and the strings which is consulted whenever "'image" is
called. This mapping *has* to contain the strings, and *has* to be stored in
your program somewhere.

If you don't want that to happen, and can live without 'image and 'value,
many Ada compilers provide a pragma to prevent generation of the mapping.
Check your vendor docs for more information.

There is also an attribute, "'pos", which will return the position number of
an enumeration value. Since a record representation clause makes the value
represeted by an enumeration different from its position number, a mapping
between those must be created as well.

Enumerations can't be handled like "#defines" in C because they are actual
values, which may be stored in variables. A compiler may be able to tell you
what "Boolean'image(TRUE)" is at compile time, but in order to tell you what
"Boolean'image(My_Boolean_Flag_Variables)" is, a table will have to be
consulted at runtime.

If you truly need the low overhead untyped C approach (yuk), integers and
named numbers are the way to go (in Ada 83). But I'd try turning on compiler
size optimizations first. If your executable is *still* too big for the
target after that, then worry about mangling your code. (I assume you aren't
looking to micro-optimize your souce code as you design it, which is almost
always a bad idea).

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own