From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,5eeb9329d556031f
X-Google-Attributes: gid103376,public
From: kadavi@most.fw.hac.com (Kirk Davis)
Subject: Re: help - bit twiddling anomoly
Date: 1996/05/13
Message-ID: <DrCrEs.L61@most.fw.hac.com>#1/1
X-Deja-AN: 154608844
sender: usenet@most.fw.hac.com
x-nntp-posting-host: kadavi
references: <3193C6C3.7FEC@ccgate.hac.com>
organization: Magnavox Electronics Systems Company
newsgroups: comp.lang.ada
Date: 1996-05-13T00:00:00+00:00
List-Id: <comp.lang.ada>


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