Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Unions vs endian ness

Reply
Thread Tools

Unions vs endian ness

 
 
root
Guest
Posts: n/a
 
      11-27-2009
Friends

I am bit twiddling on a 32 bit integer quantity. Often I need to look at
only the low 16 bits.

For this I currently AND with a mask.

It seems to me that it might simplify the code instead to have an union,
union u {
int32_t dw;
int16_t w;
};

But my question is: will this run in to port ability problems if I move
the code to a plat form with different endian ness?

/root


--
Learn more or lose your rights!
http://www.guncontrolkills.com/
http://www.gunbanobama.com/
Learn more or lose your rights!
 
Reply With Quote
 
 
 
 
Seebs
Guest
Posts: n/a
 
      11-28-2009
On 2009-11-27, root <(E-Mail Removed)> wrote:
> I am bit twiddling on a 32 bit integer quantity. Often I need to look at
> only the low 16 bits.
>
> For this I currently AND with a mask.
>
> It seems to me that it might simplify the code instead to have an union,
> union u {
> int32_t dw;
> int16_t w;
> };
>
> But my question is: will this run in to port ability problems if I move
> the code to a plat form with different endian ness?


Probably. Even ignoring the more general undefined behavior thing, there
is nothing about this to tell you whether you get the low-order or high-order
16 bits. Typically, that'd be low-order (little-endian) or high-order
(big-endian), but there have been weirder cases out there, etcetera.

Suggestion: Use a macro for the mask, use bit masking in it, and don't
sweat it -- I'd guess most modern compilers generate plenty-efficient code.

Another thing to consider is using an unsigned type, and then just doing
((uint16_t) x) to get the low-order bits.

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / http://www.velocityreviews.com/forums/(E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
 
Reply With Quote
 
 
 
 
James Dow Allen
Guest
Posts: n/a
 
      11-29-2009
On Nov 28, 6:06*am, root <(E-Mail Removed)> wrote:
> I am bit twiddling on a 32 bit integer quantity. Often I need to look at
> only the low 16 bits.
>
> It seems to me that it might simplify the code instead to have an union,
> union u {
> * * * * * * * * int32_t dw;
> * * * * * * * * int16_t w;
>
> };


My Jpeg compressor has a union something like
union u {
int32_t u_dw;
int16_t u_w[2];
#define u_hiword u_w[0]
#define u_loword u_w[1];
};
with config/ifdef set up to reverse hiword/loword on some
systems. I suppose that it is NOT guaranteed that EITHER
hiword/loword assignment will work. Just hold your
breath and remember to doublecheck when you port to a
new system.

An interesting thing about this union in my Jpeg compressor
is that the code worked fine, if you used the *wrong*
hiword/loword asignment, except for a *slight* loss of arithmetic
accuracy at the highest fidelity settings. Clever c.l.c'ers,
with this hint, may have little trouble deducing what I was
doing with this union.

James Dow Allen
 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      12-01-2009
James Dow Allen wrote:

> An interesting thing about this union in my Jpeg compressor [...]


Would you recommend your JPEG compressor over libjpeg, or are you
just writing it for your own personal use?

http://jpegclub.org/
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      12-01-2009
On 29 Nov, 14:16, "Malcolm McLean" <(E-Mail Removed)> wrote:
> "root" <(E-Mail Removed)> wrote in message


> > I am bit twiddling on a 32 bit integer quantity. Often I need to look at
> > only the low 16 bits.

>
> > For this I currently AND with a mask.

>
> > It seems to me that it might simplify the code instead to have an union,
> > union u {
> > int32_t dw;
> > int16_t w;
> > };

>
> Yes. In reality ypu will either get the high two bytes or the low two bytes
> of dw in w, depending on the endianness of the machine.


....unless you run it on a PDP-11


> However on a strict reading of the standard what you are doing evokes
> undefined behaviour, because you are writing to one member and reading from
> another.
>
> The AND masking scheme is a bit messy, but it the best solution.


must be me, but a mask always looks pretty clear to me, maybe a played
in the binary too much as a child. Unions just give me the willies

w = dw & 0xffff; /* what could be clearer? */

 
Reply With Quote
 
James Dow Allen
Guest
Posts: n/a
 
      12-01-2009
On Dec 1, 7:09*pm, Noob <r...@127.0.0.1> wrote:
> James Dow Allen wrote:
> > An interesting thing about this union in my Jpeg compressor [...]

>
> Would you recommend your JPEG compressor over libjpeg, or are you
> just writing it for your own personal use?


I'd guess mine's still faster; maybe I'll download the other
some day and check. You're welcome to apply for a license on
my method, but I won't see any of the revenue.

Did you solve the puzzle in the message to which you replied?

James
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      12-01-2009
James Dow Allen <(E-Mail Removed)> writes:
> My Jpeg compressor has a union something like
> union u {
> int32_t u_dw;
> int16_t u_w[2];
> #define u_hiword u_w[0]
> #define u_loword u_w[1];
> };
> with config/ifdef set up to reverse hiword/loword on some
> systems. I suppose that it is NOT guaranteed that EITHER
> hiword/loword assignment will work. Just hold your
> breath and remember to doublecheck when you port to a
> new system.
>
> An interesting thing about this union in my Jpeg compressor
> is that the code worked fine, if you used the *wrong*
> hiword/loword asignment, except for a *slight* loss of arithmetic
> accuracy at the highest fidelity settings. Clever c.l.c'ers,
> with this hint, may have little trouble deducing what I was
> doing with this union.


WSITD - U and V?

Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
 
Reply With Quote
 
James Dow Allen
Guest
Posts: n/a
 
      12-02-2009
On Dec 2, 4:45*am, Phil Carmody <(E-Mail Removed)>
wrote:
> James Dow Allen <(E-Mail Removed)> writes:
> > My Jpeg compressor has a union something like
> > * *union u {
> > * * * * *int32_t *u_dw;
> > * * * * *int16_t *u_w[2];
> > * *#define *u_hiword u_w[0]
> > * *#define *u_loword u_w[1];
> > * *};
> > with config/ifdef set up to reverse hiword/loword on some
> > systems....

> ..
> > An interesting thing about this union in my Jpeg compressor
> > is that the code worked fine, if you used the *wrong*
> > hiword/loword asignment, except for a *slight* loss of arithmetic
> > accuracy at the highest fidelity settings. *Clever c.l.c'ers,
> > with this hint, may have little trouble deducing what I was
> > doing with this union.

>
> WSITD - U and V?


Translating this for the acronym-impaired, I think Phil means:
> Wanton Smack in the Derriere - Cr Cb ?
> where Cr, Cb are the chromaticity values
> in a method like JFIF.


Well, simply swapping U and V will be much worse than a
"slight loss of arithmetic accuracy" on any but *extremely*
drab color images.

The explanation is actually rather simple,
but it involves a special (probably little-known)
technique, and may be *very* difficult to guess
without more clues. (If I thought there was an
interest for such puzzles, I might rephrase
it and post in comp.graphics or somewhere.)

Here's a big hint, though you'll still
need to put your thinking cap on for the
complete explanation:

Fvkgrra ovgf bs cerpvfvba ner whfg rabhtu
sbe onfryvar Wcrt vs vg'f cebcreyl pbqrq.
Jvgu gur snhygl uvjbeq/ybjbeq fjnc, *fbzr*
bs gur qngn raqrq hc, va rssrpg, jvgu bayl
svsgrra ovgf bs cerpvfvba.

Wnzrf Qbj Nyyra

 
Reply With Quote
 
David Thompson
Guest
Posts: n/a
 
      12-17-2009
On Tue, 1 Dec 2009 04:53:34 -0800 (PST), Nick Keighley
<(E-Mail Removed)> wrote:

> On 29 Nov, 14:16, "Malcolm McLean" <(E-Mail Removed)> wrote:
> > "root" <(E-Mail Removed)> wrote in message


> > > union u {
> > > int32_t dw;
> > > int16_t w;
> > > };

> >
> > Yes. In reality ypu will either get the high two bytes or the low two bytes
> > of dw in w, depending on the endianness of the machine.

>
> ...unless you run it on a PDP-11
>

Even on -11; you get the high 2 bytes. It's just not *consistent* with
the otherwise little-endian behavior where e.g. int16 punned as int8
(or u-char) gives you the low byte.

 
Reply With Quote
 
James Dow Allen
Guest
Posts: n/a
 
      12-18-2009
On Dec 2, 5:34*pm, James Dow Allen <(E-Mail Removed)> wrote:
> > > My Jpeg compressor has a union something like
> > > * *union u {
> > > * * * * *int32_t *u_dw;
> > > * * * * *int16_t *u_w[2];
> > > * *#define *u_hiword u_w[0]
> > > * *#define *u_loword u_w[1];
> > > * *};
> > > with config/ifdef set up to reverse hiword/loword on some
> > > systems....

> > ..
> > > An interesting thing about this union in my Jpeg compressor
> > > is that the code worked fine, if you used the *wrong*
> > > hiword/loword asignment, except for a *slight* loss of arithmetic
> > > accuracy at the highest fidelity settings. *Clever c.l.c'ers,
> > > with this hint, may have little trouble deducing what I was
> > > doing with this union.

>
> The explanation is actually rather simple,
> but it involves a special (probably little-known)
> technique, and may be *very* difficult to guess
> without more clues. *(If I thought there was an
> interest for such puzzles, I might rephrase
> it and post in comp.graphics or somewhere.)
>
> Here's a big hint, though you'll still
> need to put your thinking cap on for the
> complete explanation:
>
> Fvkgrra ovgf bs cerpvfvba ner whfg rabhtu
> sbe onfryvar Wcrt vs vg'f cebcreyl pbqrq.
> Jvgu gur snhygl uvjbeq/ybjbeq fjnc, *fbzr*
> bs gur qngn raqrq hc, va rssrpg, jvgu bayl
> svsgrra ovgf bs cerpvfvba.
>
> Wnzrf Qbj Nyyra


There was a reply in this thread 2 weeks later,
and I thought someone might have solved the puzzle!
No....

I created this "programming puzzle"
spontaneously when I noticed the exact
union definition I used in this thread.
No one in c.l.c has solved the puzzle.

I believe the puzzle to be a difficult
challenge about low-level programming, but fair,
and could even be phrased as a good interview question.
I will probably post it to alt.math.rec in a
few days, expecting someone there may solve it quickly.

Thus it becomes a challenge for c.l.c!
Are you going to let a.m.r show you up?


James Dow Allen
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Little Endian to Big Endian invincible C++ 9 06-14-2005 10:21 PM
Little Endian to Big Endian for 32 bit invincible C++ 1 06-14-2005 04:20 PM
Q about endian-ness/portability Joe C C++ 3 01-15-2004 03:04 AM
float: IEEE, big endian, little endian Ernst Murnleitner C++ 0 01-13-2004 01:48 PM
convert from BIG-ENDIAN to LITTLE-ENDIAN hicham C++ 2 07-02-2003 04:55 PM



Advertisments