* problem with using bitfields
@ 1987-02-15 18:16 rrw
0 siblings, 0 replies; 2+ messages in thread
From: rrw @ 1987-02-15 18:16 UTC (permalink / raw)
I'm having a problem with getting bitfields to work. I think that
I'm doing what the LRM (13.4) says to do, but the compiler refuses
to accept it. Can anybody see what the problem is?
Here's the code:
package FOOBAR is
type DARK_VECTOR_TYPE is
record
vector: POSITIVE range 0 .. 2#1111111#;
parity: POSITIVE range 0 .. 1;
end record;
for DARK_VECTOR_TYPE use
record at mod 8;
vector at 0 range 0 .. 6;
----^A ###
--### A:error: LRM 13.4(7): not enough space allocated for field
parity at 0 range 7 .. 7;
----^A ###
--### A:error: LRM 13.4(7): not enough space allocated for field
end record;
for DARK_VECTOR_TYPE'SIZE use 8;
------------------------------^A ###
--### A:error: LRM 13.2(5): specified size is too small for type
end FOOBAR;
If I increase the space allotted for each field to 32, it works.
This will not do for my project, though.
Any help would be greatly appreciated.
Thanks,
Rick Wessman
..!seismo!rochester!cci632!rrw
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: problem with using bitfields
@ 1987-02-17 6:11 kinder
0 siblings, 0 replies; 2+ messages in thread
From: kinder @ 1987-02-17 6:11 UTC (permalink / raw)
In message 148, Rick writes that a compiler complained about a record field
of type "POSITIVE range 0..1" when a rep clause tries to pack this field
into one bit (and similarly when a field of type "POSITIVE range 0..2**6-1"
is packed into 6 bits).
Since the type POSITIVE is a subtype of INTEGER, the compiler is probably
complaining because you haven't left room for a "sign" bit. In many
architectures, there is a difference between integer (signed) and ordinal
(unsigned) operations (such as, whether arithmetic overflow is raised).
The compiler may have decided that since you used a subtype of an integer
type, you intend for integer-like behavior, and because of this, you need
to leave room for one more bit for the sign, (even though your subtype's
range can have no negative values).
The easiest way to determine this compiler behavior is to try a rep-clause
to pack the fields into 2 bits and 7 bits respectively. There may also be
a pre-defined numeric type available (perhaps in System) that is an
unsigned numeric type that you can use and would not require a sign bit.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1987-02-17 6:11 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1987-02-17 6:11 problem with using bitfields kinder
-- strict thread matches above, loose matches on Subject: below --
1987-02-15 18:16 rrw
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox