Subject: Re: [linux-audio-dev] sfront 0.65 09/07/00
From: John Lazzaro (lazzaro_AT_CS.Berkeley.EDU)
Date: Sun Sep 10 2000 - 00:14:16 EEST
> Well, your hex strings are 5 bytes long each. IEEE float is 4 bytes long
> (any platform) so maybe there's an alignment problem.
Oops, this was my error during posting, sorry. Here's an example that
I think should make things clearer; since the sfront code was too
convoluted to post, I wrote a simple test program that should explain
what's up. This program below emulates sfront -- it prints out a C
program to stdout:
#define LEN 3
float farray[LEN] = {1.34F, -203.0F, 132.0F};
int main ()
{
unsigned char * c = (unsigned char *) farray;
int i;
printf("char carray[%i] = \"", LEN*sizeof(float) + 1);
for (i=0; i < LEN*sizeof(float); i++)
printf("\\x%02x",c[i]);
printf("\";\n");
printf("#define LEN %i\n", LEN);
printf("int main () {\n");
printf("float * f = (float *) carray;\n");
printf("int i;\n");
printf("for (i = 0; i < LEN; i++)\n");
printf("printf(\"%%f\\n\", f[i]);\n");
printf("}\n");
}
Running this on an x86 Linux machine yields this program as output:
char carray[13] = "\x1f\x85\xab\x3f\x00\x00\x4b\xc3\x00\x00\x04\x43";
#define LEN 3
int main () {
float * f = (float *) carray;
int i;
for (i = 0; i < LEN; i++)
printf("%f\n", f[i]);
}
Compiling and executing this program yields:
1.340000
-203.000000
132.000000
Showing that, for x86 byte-order, the basic technique gets the
correct answer (i.e. the three numbers printed are the same as
the three numbers used for initialization in farray.
Uploading the code onto our Solaris E450 box, and hoping I'm not
disturbing the 78 other users logged on (its primary role is for
DSL folks to read their mail these days ...), we compile the
original program using gcc and get:
char carray[13] = "\x3f\xab\x85\x1f\xc3\x4b\x00\x00\x43\x04\x00\x00";
#define LEN 3
int main () {
float * f = (float *) carray;
int i;
for (i = 0; i < LEN; i++)
printf("%f\n", f[i]);
}
and sure enough, byte order is reversed for each float! I stand
corrected ... but note that when you compile this program
on the Solaris box and run it, you get:
1.340000
-203.000000
132.000000
i.e. the implicit "reversal" is happening as hoped. So unless I'm
missing something here, if the goal is to run sfront and the C
program sfront creates on the same platform, this technique should
get the "correct" answer on little-endian and big-endian platforms.
> If hex initialisation is more efficient then why not (where your surrogate
> type is MyUint32_t )
From the benchmarks I did using gcc, it's not the hexadecimal format
that seems to be responsible for the speedup -- it's the string
data parsing code that seems to run much faster than the generic
array initialization parsing code.
> 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).
FYI, people have successfully compiled and used sfront on MacOS, as
a batch program for creating and processing data files -- so the
core engine seems OK on PPC, although the MacOS folks haven't written
real-time drivers yet ...
--jl
This archive was generated by hypermail 2b28 : Sun Sep 10 2000 - 01:14:13 EEST