assembler instruction in endian.h not working

[skye-AL]

@mcharleb, @jywilson
using the inline functions defined in dspal/include/endian.h, e.g. __htonl(x), leads to errors

/tmp/i2c_test_imp-2ab05a.s:78:2: error: invalid operand for instruction
eor r2, r16, r16, ror #16
^
/tmp/i2c_test_imp-2ab05a.s:79:1: error: invalid operand for instruction
bic r2, r2, #0x00ff0000
^
/tmp/i2c_test_imp-2ab05a.s:80:1: error: invalid operand for instruction
mov r16, r16, ror #8
^
/tmp/i2c_test_imp-2ab05a.s:81:1: error: invalid operand for instruction
eor r16, r16, r2, lsr #8

unfortunately I don't know anything about assembler instructions, so I don't know really how to fix it, but a workaround is to use something like this instead:

static __inline __uint32_t
__bswap32_var(__uint32_t val)
{
    return ((((val) >> 24) & 0x000000FF) | (((val) >>  8) & 0x0000FF00) | \
            (((val) <<  8) & 0x00FF0000) | (((val) << 24) & 0xFF000000));
}

can you confirm this issue?

[mcharleb]

@skye-AL Make sure dspal/include is NOT in your path when building ARM binaries. It can ONLY be included when building HEXAGON binaries. Otherwise you will pick up the wrong version of endian.h

[skye-AL]

@mcharleb Thank you for the prompt answer. I was just testing it with the dspal tester and added the following lines at the beginning of int dspal_tester_i2c_test(void) in i2c_test_imp.c

uint32_t test = 200;
uint32_t temp = __htonl(test);
LOG_INFO("temp %lu ", temp);

and added #include <endian.h> and #include "dspal_log.h" thinking that i2c_test_imp.c is only built for HEXAGON binaries (as i2c_test_imp.c is under DSP_SOURCES in the CMakeLists.txt), but it didn't work. Also make build_dspal_tester_dsp leads to this error. But I don't understand the build system completely, so I need to recheck.

[mcharleb]

@skye-AL Did you resolve the issue you were having?

[skye-AL]

@mcharleb Hey Mark, thank you for coming back to me. Unfortunately I haven't yet solved this issue:
I get the following output when I compile the dspal tester using __htonl(x) in dspal_tester_i2c_test(void) as described above:

[ 8%] Building C object dspal_tester/CMakeFiles/dspal_tester.dir/adsp_proc/i2c_test_imp.c.o
cd /home/anton/dspal/test/build/dspal_tester && /home/anton/Qualcomm/HEXAGON_Tools/7.2.10/Tools/bin/hexagon-clang -Ddspal_tester_EXPORTS -I/home/anton/dspal/test/build -I/home/anton/dspal/test/../include -I/home/anton/dspal/test/include -I/home/anton/dspal/test/dspal_tester/include -I/home/anton/dspal/test/build/dspal_tester -I/home/anton/Qualcomm/Hexagon_SDK/2.0/inc -I/home/anton/Qualcomm/Hexagon_SDK/2.0/inc/stddef -I/home/anton/Qualcomm/Hexagon_SDK/2.0/lib/common/rpcmem -I/home/anton/Qualcomm/Hexagon_SDK/2.0/lib/common/remote/ship/hexagon_Debug -D__CUSTOM_FILE_IO__ -O0 -mv5 -G0 -O2 -g -fno-strict-aliasing -fdata-sections -fno-zero-initialized-in-bss -Wall -Wextra -Werror -Wno-unused-parameter -Wno-unused-function -Wno-unused-variable -Wno-gnu-array-member-paren-init -Wno-cast-align -Wno-missing-braces -Wno-strict-aliasing -fPIC -D QURT -D _PID_T -D _UID_T -D _TIMER_T -D _HAS_C9X -D restrict=__restrict -D noreturn_function= -o CMakeFiles/dspal_tester.dir/adsp_proc/i2c_test_imp.c.o -c /home/anton/dspal/test/dspal_tester/adsp_proc/i2c_test_imp.c
/tmp/i2c_test_imp-c4f2f6.s:48:2: error: invalid operand for instruction
eor r2, r4, r4, ror #16
^
/tmp/i2c_test_imp-c4f2f6.s:49:1: error: invalid operand for instruction
bic r2, r2, #0x00ff0000
^
/tmp/i2c_test_imp-c4f2f6.s:50:1: error: invalid operand for instruction
mov r4, r4, ror #8
^
/tmp/i2c_test_imp-c4f2f6.s:51:1: error: invalid operand for instruction
eor r4, r4, r2, lsr #8
^
clang-3.5: error: hexagon-llvm-mc command failed with exit code 1 (use -v to see invocation)

And as I understand this I only build hexagon binaries here, if I'm not wrong?

[mcharleb]

Somehow you are building ARM assembly (bic instruction) which means you are picking up the wrong header files somewhere that provide ARM versions of assembly macros.

[mcharleb]

@skye-AL Are you still having an issue or has this been resolved?

[skye-AL]

@mcharleb I appreciate that you ask again. Unfortunately, I couldn't solve this issue at the time and did not follow up as using the workaround described in the first comment would just be fine. Do you not experience this problem when using e.g. __htonl(x) on the dsp (e.g. as explained in the second comment)?

[mcharleb]

@skye-AL Closing the issue since it sounded like you found a workaround and this is not something that anyone else seems to be experiencing. Please feel free to re-open an issue if this is a continued problem.