Re: Storage space question

[callen@space.honeywell.com]

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