Should Representation Clauses be complete for each bit?
Stephen Leake
Lowe Anthony A wrote:
>
> Some of our new Ada folks have written Rep Clauses which do not
> explicitly map every bit in the range of data to a member of the
> record. (i.e.
> type x is record
> one : boolean;
> two : boolean;
> three : boolean;
> end record;
> for x use record
> one at 0 range 0..0;
> two at 0 range 3..3;
> three at 0 range 15..15;
> end record;
>
> In the past I have always used a package Rep_Clause_Types which
> defines spare bits types for anywhere from 1 to 31 bits of spare and
> subprograms to set each of the choices to all zeros or ones. I have
> not found any information in the LRM or Q&S to guide which way is more
> appropriate.
> On one hand, it is helpful to explicitly state that these bits are
> spare and will not be used for any specific purpose. If you fill in
> the spare bits with elements, they can be explicitly set to a value
> (ones or zeros). This is nice for cleanliness, but costs some
> execution time for initialization. I also am a bit concerned about
> people using the 'spare bit' types instead of creating new types when
> the spare bits mean something.
> On the other hand, if the compilers do not require you to fill it
> in and the Q&S is quiet on the subject, it must not be that bad to
> do. It is definitely easier and less crowded to not fill them in.
> If my description is not too biased I think you can see that I am
> leaning towards requiring each rep clause to be complete. I am
> interested on other takes on this issue for screaming benifits/costs
> of either approach.
I've had problems leaving bits undefined and then passing them to
Windows API functions. The Windows API has many "flag" arguments that
are easily defined by Ada records. However, the C definition is via
constants with 1 in the appropriate bits. Apparently, the actual API
functions do not always mask out the unused bits.
I've also had problems with comparing test outputs. If you leave bits
undefined, then you get whatever was left in the register from the
previous operation. If you then print this value as hex (for debugging
stream output, say), you may see different values from run to run. I
usually only see different values when changing compilers (GNAT to
ObjectAda), but it could happen when you change optimization levels. The
problem is not that the behavior is undefined, just that the test output
changes, which makes comparing the test results more difficult.
So I've adopted the general policy that all bits must be defined.
--
- Stephe
Marin David Condic, 561.796.8997, M/S 731-96
Stephen Leake <Stephe...@GSFC.NASA.GOV> writes:
>Lowe Anthony A wrote:
>>
<snip>
>> If my description is not too biased I think you can see that I am
>> leaning towards requiring each rep clause to be complete. I am
>> interested on other takes on this issue for screaming benifits/costs
>> of either approach.
>
>
>So I've adopted the general policy that all bits must be defined.
>
"Spare_xx" or something similar to make it clear which bits were
undefined by hardware, etc. It had the advantage of making a
change rather direct & simple if one of the spare bits suddenly
comes into use.
However, I've shifted my thinking on this. It is certainly less
"cluttered" to avoid declaring unused bits. Also, it is less
misleading. I have encountered code where the programmer declared
all unused bits as "Spare" (or similar) only to discover later
that there really were definitions for the bits in question - just
that they were unused by this particular piece of code. One might
have been tempted to appropriate the bits for something else. So
if they are left completely undefined, someone else comming along
later is not likely to make assumptions about the bits other than
that they are not used by this application.
One thing I do favor is this: Where you are using the rep clause
to model something coming out of hardware or some external source,
I find it a good idea to define all of the fields that are
documented and do so with names as close to what appears in the
document as is possible. This way it is explicit what bits the
hardware is supposed to be setting/using, what bits the hardware
does not care about (if its labeled "reserved" you probably want
to declare it to make clear that the hardware *might* use those
bits) and there is a clear mapping between what someone reads in
the document and what they read in the code. The code may not use
all the bits that are defined - and that's O.K. - but it is clear
when reading the definition, why those bits exist.
It would be nice to have a convention on this one way or the
other.
MDC
Marin David Condic, Senior Computer Engineer Voice: 561.796.8997
Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600 Fax: 561.796.4669
West Palm Beach, FL, 33410-9600 Internet: COND...@PWFL.COM
=============================================================================
"Because that's where they keep the money."
-- Willie Sutton when asked why he robbed banks.
=============================================================================