help - bit twiddling anomoly

help - bit twiddling anomoly

[Dave Wright]

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 fourteenbit is record
value: integer range 0..16383;
end record;
for fourteenbit'size use 14;
pragma bit_pack(fourteenbit);

type br is record
bit0:   onebit;
bit1:   onebit;
bit2_15: fourteenbit;
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=>fourteenbit);
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-fourteenbit'size)));

end testc;

-- 
Wm. David Wright		wdwright@ccgate.hac.com
Systems Engineer		Hughes Technical Services Company

Re: help - bit twiddling anomoly

[Theodore E. Dennison]

Dave Wright wrote:
> 
> 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
   mailto:support@rational.com

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.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: help - bit twiddling anomoly

[Robert A Duff]

In article <3193C6C3.7FEC@ccgate.hac.com>,
Dave Wright  <wdwright@ccgate.hac.com> wrote:
>Any ideas why the following code behaves strangely ...

Because it's not indented properly.

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

:-) / 2

- Bob

Re: help - bit twiddling anomoly

[Marc Bouvette]

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!

Re: help - bit twiddling anomoly

[Kirk Davis]

Dave Wright <wdwright@ccgate.hac.com> wrote:

>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 fourteenbit is record
>value: integer range 0..16383;
>end record;
>for fourteenbit'size use 14;
>pragma bit_pack(fourteenbit);

>type br is record
>bit0:   onebit;
>bit1:   onebit;
>bit2_15: fourteenbit;
>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=>fourteenbit);
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)?

>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.

>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-fourteenbit'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).