Subject: Re: [linux-audio-dev] sfront 0.65 09/07/00
From: Iain Sandoe (iain_AT_sandoe.co.uk)
Date: Sat Sep 09 2000 - 17:17:59 EEST
Hi John,
[...]
>> - that is I think it's a byte ordering problem - not an embedded 0 problem
>> (but maybe I'm not awake yet :-)
>>
>> [or maybe you re-reverse it at run-time]
>
> I think it re-reverses,
quite a run-time task if there's a lot of data (or is it only at init time)?
>and that it's not byte-order related --
OK
> primary evidence is that gcc running under Solaris handles the
> hexadecimal string encoding just fine, while cc under Solaris
> produces a binary that crashes on takeoff. Another reason I
> think its the "embedded \x00" issue is that I'm only using the
> trick on float arrays,
Well, your hex strings are 5 bytes long each. IEEE float is 4 bytes long
(any platform) so maybe there's an alignment problem. The compiler doesn't
have to pack arrays of bytes on anything other than a byte boundary.
IIRC it *must* pack floats on 4 bytes on Sparc or there will be an access
error when trying to read/write them (it's been a while since I've used
Sparc - so my memory might be slightly faulty). This certainly would be the
case on PPC.
Also, there seems to be a potential waste of space - because, to avoid the
alignment issue, the compiler would have to place the five byte arrays 8
bytes apart - say if there was a union specified that said:
typedef union {
unsigned char foo[5] ;
float bar ;
} equi_t ;
equi_t fred[1000] ; /* this, I think, would end up 8000 bytes long */
There can (also) be issues between compiler implementations of structure
population...
It's that old "don't use portable code, use a portable compiler" thing again
- no?
=====
If hex initialisation is more efficient then why not (where your surrogate
type is MyUint32_t )
MyUint32_t foo = 0x41a00000 ;
which is both alignment transparent and only occupies 4 bytes...
> and I had thought IEEE floating-point
> didn't have machine-specific byte-order issues (maybe I'm wrong
> on that).
Sorry, float & double are just as byte-ordering sensitive as anything else.
They need byte-swapping between x86/Alpha & PPC/Sparc.
> In any event, by default sfront produces the slow
>
> float foo[1] = { 0.39485};
>
> initialization, and only uses embedded strings if the -hexdata
> flag is selected ...
OK.
I have an (eventual) interest in making things work on PPC (somewhat in the
future right now - because drivers are still needed in places).
Iain.
This archive was generated by hypermail 2b28 : Sat Sep 09 2000 - 18:22:52 EEST