Power Developer :: Suspected endianness problem

According to QT I am running a big endian system. (See documentation for QApplication::qSysInfo() to read it). I am no expert on PPC but I read it is endian selectable so I don't know if big endian is the correct answer.

I don't know how it would be possible that QT could read the wrong endianness from the OS yet all included software has no problems... is it possible SUSE reports the "wrong" endianness ?

Ah thanks, I wasn't sure how selectable endianness works.

One was some code to read a WAV file - I had copied an example *aimed* at developers for embedded systems so I had expected it to be portable but when I looked more closely it wasn't!

The other problem is with QT4.4 which seems to read some images with wrong colours - nothing to do with colourspaces.

Do you have example code here?

I can enjoy the luxury of C++ or C so I'm not going to use assembler to swap bytes; besides I want my code to be portable.

Just build something using a QFileDialog; the icons for navigating are red when they should be blue. I first noticed this when I loaded an XPM into a QIcon and then used the global setWindowIcon(). The icon in my about dialog was weird.

I can enjoy the luxury of C++ or C so I'm not going to use assembler to swap bytes; besides I want my code to be portable.

If you need to do realtime processing of audio data or so,

That's a more complicated issue than endianness, since XPM is an ASCII text format

You could just use swab()

Author:	koan [ Sat Sep 20, 2008 8:15 am ]
Post subject:	Suspected endianness problem
Hi I'm a little embarrassed to say that I'm running SUSE 10.3 still... I don't like to update while I'm in the middle of a project and I haven't had a chance to update yet. When I downloaded and installed QT4.4 I noticed some of the images had inverted colourmaps when I built my own software. Now I am trying to finish a program in QT3 and it seems that when reading certain data from a file I get some bizarre values that seem to correspond to an endianness problem. This would explain the earlier image colour problem. According to QT I am running a big endian system. (See documentation for QApplication::qSysInfo() to read it). I am no expert on PPC but I read it is endian selectable so I don't know if big endian is the correct answer. I don't know how it would be possible that QT could read the wrong endianness from the OS yet all included software has no problems... is it possible SUSE reports the "wrong" endianness ? thanks! koan

Author:	Neko [ Sat Sep 20, 2008 9:22 am ]
Post subject:	Re: Suspected endianness problem
Quote: According to QT I am running a big endian system. (See documentation for QApplication::qSysInfo() to read it). I am no expert on PPC but I read it is endian selectable so I don't know if big endian is the correct answer. Depending on the chip, it's endian-selectable. The architecture supports both ways but implementation of little-endian is sort of optional, and you need to build your kernel to support it anyway (at least, to let you select which way). If it doesn't support running in little-endian mode there are a few instructions which help in portability of data (load and automatically byteswap, and save and byteswap kind of things). Generally, you'll run it big-endian for a lot of reasons, and the Linux kernel defaults to this. Quote: I don't know how it would be possible that QT could read the wrong endianness from the OS yet all included software has no problems... is it possible SUSE reports the "wrong" endianness ? No. This is probably just a library problem - perhaps some data from a Windows BMP is just being read out verbatim (it will be swapped because it's an x86, little-endian format. It may also be in the wrong colour order anyway (ARGB or BGRA instead of RGBA). What exactly are you doing and what's the exact result?

Author:	koan [ Sat Sep 27, 2008 12:23 am ]
Post subject:
Ah thanks, I wasn't sure how selectable endianness works. I had problems with 2 different sets of sources so I thought that it could be an endianness issue. One was some code to read a WAV file - I had copied an example aimed at developers for embedded systems so I had expected it to be portable but when I looked more closely it wasn't! I never imagined example code to be so bad. The other problem is with QT4.4 which seems to read some images with wrong colours - nothing to do with colourspaces. So now it just seems to be the QT problem so it's less likely to be endianness.

Author:	Neko [ Sat Sep 27, 2008 10:51 am ]
Post subject:
Quote: Ah thanks, I wasn't sure how selectable endianness works. You needn't worry about it at all. Quote: One was some code to read a WAV file - I had copied an example aimed at developers for embedded systems so I had expected it to be portable but when I looked more closely it wasn't! Well, most WAV data is stored little-endian for obvious Windows-related reasons. All you need to do is read in the file, though, and if you want to read a 16-bit sample and convert it to big-endian data, use lhbrx (you may need a little inline assembler or a macro) to copy it into a register. It will automatically byteswap the data for you. lwbrx will do the same for a 32-bit word, and there are store instructions which will store it back with byte swap if you're modifying data. Quote: The other problem is with QT4.4 which seems to read some images with wrong colours - nothing to do with colourspaces. Do you have example code here? We run Qt4.4 in some demos and it seems to load images fine. What kind of images are you loading, and to what kind of class are you displaying them?

Author:	koan [ Sat Sep 27, 2008 7:28 pm ]
Post subject:
I didn't know anything about WAV until I had that problem. Now I know a lot more ;) I can enjoy the luxury of C++ or C so I'm not going to use assembler to swap bytes; besides I want my code to be portable. Quote: Do you have example code here? Just build something using a QFileDialog; the icons for navigating are red when they should be blue. I first noticed this when I loaded an XPM into a QIcon and then used the global setWindowIcon(). The icon in my about dialog was weird.

Power Developer https://www.powerdeveloper.org/forums/

Suspected endianness problem https://www.powerdeveloper.org/forums/viewtopic.php?f=12&t=1614	Page 1 of 1

Author:	Neko [ Tue Sep 30, 2008 7:44 am ]
Post subject:
Quote: I can enjoy the luxury of C++ or C so I'm not going to use assembler to swap bytes; besides I want my code to be portable. It can still be portable; just wrap it in a macro. The portability you crave needn't come at the expense of performance. If you need to do realtime processing of audio data or so, then you do not want to waste time byteswapping manually. It uses more registers and of course takes far more instructions (at least 2 logical ops and a couple of shifts) Quote: Just build something using a QFileDialog; the icons for navigating are red when they should be blue. I first noticed this when I loaded an XPM into a QIcon and then used the global setWindowIcon(). The icon in my about dialog was weird. That's a more complicated issue than endianness, since XPM is an ASCII text format and should be parsed the same way on x86 and PowerPC :)

Author:	markos [ Tue Sep 30, 2008 2:20 pm ]
Post subject:
Quote: I can enjoy the luxury of C++ or C so I'm not going to use assembler to swap bytes; besides I want my code to be portable. You could just use swab() from glibc or libfreevec, which exist just for this purpose :D

Author:	koan [ Mon Oct 06, 2008 2:23 am ]
Post subject:
Quote: If you need to do realtime processing of audio data or so, I"m only playing back a PCM WAV file so I think it's OK to use a high level programming language in order to write easy to understand code. Quote: That's a more complicated issue than endianness, since XPM is an ASCII text format Well it's not actually; as I said, when I build QT I can see the problem in the icons used by a QFileDialog. I don't know what format they are using, those icon files were not created by me. Quote: You could just use swab() I didn't know about that, thanks. I can see how you can do 16 bit BE/LE conversion but not 32 bit, have I missed something ?

Page 1 of 1	All times are UTC-06:00
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/