Configure tests?

GNU Radio
1

I think I’ve got the issue with gr-audio-osx running on Intel
Macs … it’s about endianness in the float stream. Which means, if
I’m correct, that I need to add a #ifdef to select on whether the CPU
is big (PPC) or little (Intel) endian. Anyone know if this is
already available for configure, or will I need to add one? If the
latter, I’m sure it’s straight forward (e.g. uname -a | grep powerpc == “”), but why reinvent the wheel?

Also, it looks like Apple’s GCC implements the “.align X” in assembly
as a log2 based number (for either PPC or Intel) while others use
“.align Y” where X = log2 (Y) … a linear number. I really doubt
that this is available for configure, but it’s worth checking. I’ve
already started writing this one (“config/gr_asm_dot_align.m4”), but
again why reinvent the wheel?

Thanks! - MLD

2

On Fri, May 26, 2006 at 03:58:42PM -0400, Michael D. wrote:

I think I’ve got the issue with gr-audio-osx running on Intel
Macs … it’s about endianness in the float stream. Which means, if
I’m correct, that I need to add a #ifdef to select on whether the CPU
is big (PPC) or little (Intel) endian. Anyone know if this is
already available for configure, or will I need to add one? If the
latter, I’m sure it’s straight forward (e.g. uname -a | grep powerpc == “”), but why reinvent the wheel?

There’s already a test in the usrp and gr-usrp code for this.
See configure.ac, AC_C_BIGENDIAN.
See also usrp/host/lib/usrp_bytesex.h

I believe that the gr-usrp code already handles this properly.
See gr-usrp/usrp1_{sink,source}_{c,s}.cc.

Search for host_to_usrp_short and usrp_to_host_short

Also, it looks like Apple’s GCC implements the “.align X” in assembly
as a log2 based number (for either PPC or Intel) while others use
“.align Y” where X = log2 (Y) … a linear number. I really doubt
that this is available for configure, but it’s worth checking. I’ve
already started writing this one (“config/gr_asm_dot_align.m4”), but
again why reinvent the wheel?

I don’t know of a test for this.
How are you planning on implementing the test?
I’d suggest something like:

in test.asm (syntax could be wrong…)

.globl _start_test, _end_test

.align  16

_start_test:
.db 1
.align 4
_end_test:

Then use nm to extract the resulting symbol values, followed by some
python, etc to compute difference. Or I guess your test code could
just write the difference to stdout, then you could parse that.

Eric

3

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

4

On May 26, 2006, at 8:52 PM, Eric B. wrote:

There’s already a test in the usrp and gr-usrp code for this.
See configure.ac, AC_C_BIGENDIAN.

Yup, that works. I’ll send diff’s once I have confirmation that this
is the issue.

Then use nm to extract the resulting symbol values, followed by some
python, etc to compute difference.

Yes, something like that, but ‘.align 16’ is too big. sed could do
the trick too.

Even simpler would be:
+++++++++++++++++
.text
.globl _abc
.byte 1
.align 4
_abc:
+++++++++++++++++
Then:

gcc -c -o test.o test.S
nm test.o | grep abc | sed -e ‘s/.*([0-9a-fA-F][0-9a-fA-F]).abc./
\1/’

the output of the NM pipe should be ‘10’ or ‘16’ for ‘log’ based and
something else (I think ‘04’) for linear based. This works for me
(returns ‘10’, which is in hex but that doesn’t matter). Should be
pretty straight forward to stick in an m4 file. - MLD

5

Then use nm to extract the resulting symbol values, followed by some
python, etc to compute difference.

Yes, something like that, but ‘.align 16’ is too big. sed could do
the trick too.

By too big, do you mean that some tool complains?

gcc complains that “Alignment too large: 15. assumed.” I guess
alignment can be at most 2^15, but 2^16 is too big … not sure what
the page size on OSX is but they’re probably related. Anyway, testing
for “.align 4” is pretty safe. - MLD

6

On Fri, May 26, 2006 at 10:38:21PM -0400, Michael D. wrote:

On May 26, 2006, at 8:52 PM, Eric B. wrote:

There’s already a test in the usrp and gr-usrp code for this.
See configure.ac, AC_C_BIGENDIAN.

Yup, that works. I’ll send diff’s once I have confirmation that this
is the issue.

Great.

Then use nm to extract the resulting symbol values, followed by some
python, etc to compute difference.

Yes, something like that, but ‘.align 16’ is too big. sed could do
the trick too.

By too big, do you mean that some tool complains?

gcc -c -o test.o test.S
nm test.o | grep abc | sed -e ‘s/.*([0-9a-fA-F][0-9a-fA-F]).abc./
\1/’

the output of the NM pipe should be ‘10’ or ‘16’ for ‘log’ based and
something else (I think ‘04’) for linear based. This works for me
(returns ‘10’, which is in hex but that doesn’t matter). Should be
pretty straight forward to stick in an m4 file. - MLD

Sounds good!

Eric

7

On Sat, May 27, 2006 at 09:44:38PM -0400, Michael D. wrote:

Then use nm to extract the resulting symbol values, followed by some
for “.align 4” is pretty safe. - MLD
OK. Thanks for the info.

Eric