help - bit twiddling anomoly 
Author Message
 help - bit twiddling anomoly

Any ideas why the following code behaves strangely (other than the
fact that its SUN SPARCworks Ada 2.1.1 running on a SPARC5 with
Solaris 2.4)?  The only difference between the working version and the
broken version is 8 bits of storage (string(1..2) versus character) in
the unused object wdw.

TIA,
Dave

with unchecked_conversion;
with v_i_bits;
procedure testc is

type onebit is record
bit1: integer range 0..1;
end record;
for onebit'size use 1;
pragma bit_pack(onebit);

type four{*filter*}bit is record
value: integer range 0..16383;
end record;
for four{*filter*}bit'size use 14;
pragma bit_pack(four{*filter*}bit);

type br is record
bit0:   onebit;
bit1:   onebit;
bit2_15: four{*filter*}bit;
end record;
for br use
record at mod 1;
bit0   at 0 range 0..0;
bit1   at 0 range 1..1;
bit2_15 at 0 range 2..15;
end record;
for br'size use 16;
pragma bit_pack(br);

int:  integer;
brec: br;

-- with 2 bytes of data declared for wdw it works.
-- with 1 byte it doesn't.
wdw: string (1..2); -- with this declared it works :-)
--wdw: character; -- with this declared it doesn't work :-(
-- when it works brec.bit0 = 1
-- when it doesn't work brec.bit0  = 0.

function inttobit is new
unchecked_conversion (source=>integer, target=>onebit);
function intto14bit is new
unchecked_conversion (source=>integer, target=>four{*filter*}bit);
begin

int := 1;
brec.bit0 := inttobit(v_i_bits.bit_sll(int,(integer'size-onebit'size)));

int := 1;
brec.bit1 := inttobit(v_i_bits.bit_sll(int,(integer'size-onebit'size)));

int := 16383;
brec.bit2_15 :=
intto14bit(v_i_bits.bit_sll(int,(integer'size-four{*filter*}bit'size)));

end testc;

--

Systems Engineer                Hughes Technical Services Company



Tue, 27 Oct 1998 03:00:00 GMT  
 help - bit twiddling anomoly



Quote:
>Any ideas why the following code behaves strangely ...

Because it's not indented properly.

Quote:
>type onebit is record
>bit1: integer range 0..1;
>end record;
>for onebit'size use 1;
>pragma bit_pack(onebit);

>type four{*filter*}bit is record
>value: integer range 0..16383;
>end record;
>for four{*filter*}bit'size use 14;
>...

:-) / 2

- Bob



Wed, 28 Oct 1998 03:00:00 GMT  
 help - bit twiddling anomoly

Quote:

> Any ideas why the following code behaves strangely (other than the
> fact that its SUN SPARCworks Ada 2.1.1 running on a SPARC5 with
> Solaris 2.4)?  The only difference between the working version and the
> broken version is 8 bits of storage (string(1..2) versus character) in
> the unused object wdw.
...
> with unchecked_conversion;
> with v_i_bits;
...
> brec.bit1 := inttobit(v_i_bits.bit_sll(int,(integer'size-onebit'size)));

Since you are using a routine from the VADS internals (That's what
the "v_i" stands for), perhaps you should be asking this question to
the Rational technical support folks at

Now if you are just looking for ideas, I'm guessing that you are having
a byte-ordering problem. If the LSByte for your machine were to be
somewhere other than the lowest address in the integer, then the
unchecked conversion from integer to a one-byte type will put the
LSByte somewhere off in never-never land.

I'm also finding it curious that you are trying to declare a one bit
integer. Ada 83 Integers weren't really meant to do that. That's the
reason Boolean'size is 1. What I'd typically do is declare a packed
array type of booleans. "AND" and "OR" work in bitwise fashion
automaticly on such arrays. You still have endian issues to deal with,
though (plus now you have to worry about how your compiler chose to
order the bits).

I'm sure you had good reasons for doing this, but it seems quite
awkward in your little example.

--
T.E.D.          


                |  URL  - http://www.iag.net/~dennison         |



Wed, 28 Oct 1998 03:00:00 GMT  
 help - bit twiddling anomoly

Quote:

>Any ideas why the following code behaves strangely (other than the
>fact that its SUN SPARCworks Ada 2.1.1 running on a SPARC5 with
>Solaris 2.4)?  The only difference between the working version and the
>broken version is 8 bits of storage (string(1..2) versus character) in
>the unused object wdw.
>TIA,
>Dave
>with unchecked_conversion;
>with v_i_bits;
>procedure testc is
>type onebit is record
>bit1: integer range 0..1;
>end record;
>for onebit'size use 1;
>pragma bit_pack(onebit);
>type four{*filter*}bit is record
>value: integer range 0..16383;
>end record;
>for four{*filter*}bit'size use 14;
>pragma bit_pack(four{*filter*}bit);
>type br is record
>bit0:   onebit;
>bit1:   onebit;
>bit2_15: four{*filter*}bit;
>end record;
>for br use
>record at mod 1;
>bit0   at 0 range 0..0;
>bit1   at 0 range 1..1;
>bit2_15 at 0 range 2..15;
>end record;
>for br'size use 16;
>pragma bit_pack(br);
>int:  integer;
>brec: br;
>-- with 2 bytes of data declared for wdw it works.
>-- with 1 byte it doesn't.
>wdw: string (1..2); -- with this declared it works :-)
>--wdw: character; -- with this declared it doesn't work :-(
>-- when it works brec.bit0 = 1
>-- when it doesn't work brec.bit0  = 0.
>function inttobit is new
>unchecked_conversion (source=>integer, target=>onebit);
>function intto14bit is new
>unchecked_conversion (source=>integer, target=>four{*filter*}bit);

I'm suprised that the compiler does not complain that your source and
targets for these unchecked_conversions are not the same sizes. How
does the compiler know which of the integers bits are to be
converted(14 most significat bits, 14 least significant or some where
in-between)?

Quote:
>begin
>int := 1;
>brec.bit0 := inttobit(v_i_bits.bit_sll(int,(integer'size-onebit'size)));

Why do an unchecked converstion here? v_i_bits.bit_sll is returning an
integer and brec.bit0.bit1 is an integer just do an assignment.

Quote:
>int := 1;
>brec.bit1 := inttobit(v_i_bits.bit_sll(int,(integer'size-onebit'size)));
>int := 16383;
>brec.bit2_15 :=
>intto14bit(v_i_bits.bit_sll(int,(integer'size-four{*filter*}bit'size)));
>end testc;

It looks like the unchecked_conversion is dropping the unused bits
into the objects declared after the target objects (especially if
integers on a Sun are 32 bits).  


Fri, 30 Oct 1998 03:00:00 GMT  
 help - bit twiddling anomoly

David,

I'm a little concerned with the "at mod 1" you have specified to align the 16-bit
"br" record.  I would venture a guess that the compiler is aligning the record on an
odd byte boundary and then mixing in the "wdw" (character) variable with one-half of
the "br" record to form a 16 bit word.  Thus you may not be assigning the result of
the bit shift to where you think you are.

Consider the following example (for a Motorola 68K)

Address ----------------------------- Address
0x8000  |   Byte #1   |   Byte #2   | 0x8001
        -----------------------------
0x8002  |   Byte #3   |   Byte #4   | 0x8003
        -----------------------------

I would expect the alignment of the record to occupy Byte #1 and Byte #2.  However,
if your compiler has decided to align the record on Byte #2 and Byte #3 due to
the "at mod 1" then perhaps it has placed the "wdw" variable on Byte #4 when defined
as a single "character".

I'm not familiar with SPARC technology, but in 68K this would make sense as "bit0"
would be part of the high byte, potentially aligned on Byte #2.  If this is the case
then perhaps the value of bit0 in Byte #2 never actually changes and is always left
at 0 (presumably its initial value).

Give it a try!



Fri, 30 Oct 1998 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Bit Twiddling??

2. Bit twiddling on Parallel port

3. UUDECODE - Bit-twiddling in Arexx

4. SIMD-like bit-twiddling on odd-sized quantities

5. New Mathematical bit-twiddle - stage on of a isPerfectSquare()

6. Crazy bit-twiddle algorithms needed!

7. Bit twiddling functions

8. Bit twiddling functions

9. Byte/Bit Twiddling in Ada

10. Bit Twiddling in IBM (LE) COBOL

11. Twiddle binary bit in Cobol?

12. Bit Twiddling

 

 
Powered by phpBB® Forum Software