* Storage space question @ 1998-12-10 0:00 Craig Allen 1998-12-10 0:00 ` dennison 1998-12-10 0:00 ` Marin David Condic 0 siblings, 2 replies; 21+ messages in thread From: Craig Allen @ 1998-12-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 Storage space question Craig Allen @ 1998-12-10 0:00 ` dennison 1998-12-10 0:00 ` Marin David Condic 1 sibling, 0 replies; 21+ messages in thread From: dennison @ 1998-12-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 Storage space question Craig Allen 1998-12-10 0:00 ` dennison @ 1998-12-10 0:00 ` Marin David Condic 1998-12-10 0:00 ` Matthew Heaney ` (2 more replies) 1 sibling, 3 replies; 21+ messages in thread From: Marin David Condic @ 1998-12-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 ` Marin David Condic @ 1998-12-10 0:00 ` Matthew Heaney 1998-12-10 0:00 ` dennison 1998-12-10 0:00 ` Tucker Taft 1998-12-10 0:00 ` Pat Rogers 2 siblings, 1 reply; 21+ messages in thread From: Matthew Heaney @ 1998-12-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 ` Matthew Heaney @ 1998-12-10 0:00 ` dennison 0 siblings, 0 replies; 21+ messages in thread From: dennison @ 1998-12-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 ` Marin David Condic 1998-12-10 0:00 ` Matthew Heaney @ 1998-12-10 0:00 ` Tucker Taft 1998-12-10 0:00 ` callen 1998-12-10 0:00 ` Pat Rogers 2 siblings, 1 reply; 21+ messages in thread From: Tucker Taft @ 1998-12-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 ` Tucker Taft @ 1998-12-10 0:00 ` callen 1998-12-10 0:00 ` dennison ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: callen @ 1998-12-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 ` callen @ 1998-12-10 0:00 ` dennison 1998-12-10 0:00 ` Marin David Condic 1998-12-11 0:00 ` Matthew Heaney 2 siblings, 0 replies; 21+ messages in thread From: dennison @ 1998-12-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 ` callen 1998-12-10 0:00 ` dennison @ 1998-12-10 0:00 ` Marin David Condic 1998-12-10 0:00 ` Tucker Taft 1998-12-11 0:00 ` Matthew Heaney 1998-12-11 0:00 ` Matthew Heaney 2 siblings, 2 replies; 21+ messages in thread From: Marin David Condic @ 1998-12-10 0:00 UTC (permalink / raw) <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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 ` Marin David Condic @ 1998-12-10 0:00 ` Tucker Taft 1998-12-11 0:00 ` dennison 1998-12-11 0:00 ` Matthew Heaney 1 sibling, 1 reply; 21+ messages in thread From: Tucker Taft @ 1998-12-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 ` Tucker Taft @ 1998-12-11 0:00 ` dennison 0 siblings, 0 replies; 21+ messages in thread From: dennison @ 1998-12-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 ` Marin David Condic 1998-12-10 0:00 ` Tucker Taft @ 1998-12-11 0:00 ` Matthew Heaney 1998-12-11 0:00 ` Marin David Condic 1 sibling, 1 reply; 21+ messages in thread From: Matthew Heaney @ 1998-12-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-11 0:00 ` Matthew Heaney @ 1998-12-11 0:00 ` Marin David Condic 1998-12-12 0:00 ` Matthew Heaney 0 siblings, 1 reply; 21+ messages in thread From: Marin David Condic @ 1998-12-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-11 0:00 ` Marin David Condic @ 1998-12-12 0:00 ` Matthew Heaney 1998-12-12 0:00 ` David C. Hoos, Sr. 0 siblings, 1 reply; 21+ messages in thread From: Matthew Heaney @ 1998-12-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-12 0:00 ` Matthew Heaney @ 1998-12-12 0:00 ` David C. Hoos, Sr. 1998-12-12 0:00 ` Matthew Heaney 1998-12-14 0:00 ` dennison 0 siblings, 2 replies; 21+ messages in thread From: David C. Hoos, Sr. @ 1998-12-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-12 0:00 ` David C. Hoos, Sr. @ 1998-12-12 0:00 ` Matthew Heaney 1998-12-14 0:00 ` dennison 1 sibling, 0 replies; 21+ messages in thread From: Matthew Heaney @ 1998-12-12 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-12 0:00 ` David C. Hoos, Sr. 1998-12-12 0:00 ` Matthew Heaney @ 1998-12-14 0:00 ` dennison 1 sibling, 0 replies; 21+ messages in thread From: dennison @ 1998-12-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 ` callen 1998-12-10 0:00 ` dennison 1998-12-10 0:00 ` Marin David Condic @ 1998-12-11 0:00 ` Matthew Heaney 2 siblings, 0 replies; 21+ messages in thread From: Matthew Heaney @ 1998-12-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 ` Marin David Condic 1998-12-10 0:00 ` Matthew Heaney 1998-12-10 0:00 ` Tucker Taft @ 1998-12-10 0:00 ` Pat Rogers 1998-12-10 0:00 ` dennison 2 siblings, 1 reply; 21+ messages in thread From: Pat Rogers @ 1998-12-10 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 ` Pat Rogers @ 1998-12-10 0:00 ` dennison 1998-12-10 0:00 ` Pat Rogers 0 siblings, 1 reply; 21+ messages in thread From: dennison @ 1998-12-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Storage space question 1998-12-10 0:00 ` dennison @ 1998-12-10 0:00 ` Pat Rogers 0 siblings, 0 replies; 21+ messages in thread From: Pat Rogers @ 1998-12-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~1998-12-14 0:00 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-12-10 0:00 Storage space question Craig Allen 1998-12-10 0:00 ` dennison 1998-12-10 0:00 ` Marin David Condic 1998-12-10 0:00 ` Matthew Heaney 1998-12-10 0:00 ` dennison 1998-12-10 0:00 ` Tucker Taft 1998-12-10 0:00 ` callen 1998-12-10 0:00 ` dennison 1998-12-10 0:00 ` Marin David Condic 1998-12-10 0:00 ` Tucker Taft 1998-12-11 0:00 ` dennison 1998-12-11 0:00 ` Matthew Heaney 1998-12-11 0:00 ` Marin David Condic 1998-12-12 0:00 ` Matthew Heaney 1998-12-12 0:00 ` David C. Hoos, Sr. 1998-12-12 0:00 ` Matthew Heaney 1998-12-14 0:00 ` dennison 1998-12-11 0:00 ` Matthew Heaney 1998-12-10 0:00 ` Pat Rogers 1998-12-10 0:00 ` dennison 1998-12-10 0:00 ` Pat Rogers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox