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: Marc Bouvette Subject: Re: help - bit twiddling anomoly Date: 1996/05/13 Message-ID: <4n7vvo$7m4@magpie.cdev.com>#1/1 X-Deja-AN: 154627603 references: <3193C6C3.7FEC@ccgate.hac.com> to: wdwright@ccgate.hac.com content-type: text/plain; charset=us-ascii organization: Computing Devices International mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 1.22 (Windows; I; 16bit) Date: 1996-05-13T00:00:00+00:00 List-Id: 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!