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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ca7e14ee1b312f90 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-04-25 10:38:12 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!dfw-service2.ext.raytheon.com.POSTED!not-for-mail Message-ID: <3EA97222.35376FF7@raytheon.com> From: Mark Johnson X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Minimum Record Size? LONG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 25 Apr 2003 12:36:34 -0500 NNTP-Posting-Host: 192.27.48.39 X-Complaints-To: news@ext.ray.com X-Trace: dfw-service2.ext.raytheon.com 1051292291 192.27.48.39 (Fri, 25 Apr 2003 12:38:11 CDT) NNTP-Posting-Date: Fri, 25 Apr 2003 12:38:11 CDT Organization: Raytheon Company Xref: archiver1.google.com comp.lang.ada:36559 Date: 2003-04-25T12:36:34-05:00 List-Id: Dr Nancy's Sweetie wrote: > > I'm working on a program which has to take four six-bit hunks of data > and regroup them into three eight-bit hunks. [snip - long explanation] > If I put in C3zY, which map to 28, 55, 25, and 50, I see this: > > Put in: 28 55 25 50 > 011100 110111 011001 110010 aaaaaa bbbbbb cccccc dddddd > > Expect: 115 118 114 > 01110011 01110110 01110010 > > Actual: 220 157 201 > 11011100 10011101 11001001 bbaaaaaa ccccbbbb ddddddcc > > I can't see where the resulting bits that actually come out are from. > They don't seem to bear any relation to the bits that went in. > The bits look good to me - they just don't match what you expected. The packing I see is shown in line with your original message. You don't mention the machine you are using and you don't post the actual code you are using. Both would be a greater help in analyzing the specific problem and solution. This may also be a big / little endian problem. You have to read very carefully the ARM when it talks about placement of bits in fields and so on. You could also try using representation specifications (section 13) to place each field precisely where you want it. You may find that some of the combinations you are attempting to do are "not contiguous" and have to be handled in a special way. --Mark