Error: Unknown instruction 'fcache #(ShiftOutDataEnd322 - ShiftOutDataStart322) '

DavidZemon

I get the following errors when compiling with PropGCC 2344 from a Raspberry Pi 2

pi@raspberrypi:~/software/PropWare/bin $ /opt/parallax/bin/propeller-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/opt/parallax/bin/propeller-elf-gcc
COLLECT_LTO_WRAPPER=/opt/parallax/libexec/gcc/propeller-elf/4.6.1/lto-wrapper
Target: propeller-elf
Configured with: ../../propgcc/gcc/configure --target=propeller-elf --prefix=/opt/parallax --disable-nls --disable-libssp --disable-lto --disable-shared --with-pkgversion=propellergcc_v1_0_0_2344 --with-bugurl=http://code.google.com/p/propgcc/issues
Thread model: single
gcc version 4.6.1 (propellergcc_v1_0_0_2344)

The assembled file is attached, and this is the command that is being invoked

/opt/parallax/bin/propeller-elf-gcc     -save-temps  -Os -m32bit-doubles -Wall     -std=gnu++0x -fno-exceptions -fno-rtti -fno-threadsafe-statics -mcog   -I/home/pi/software/PropWare  -o CMakeFiles/PropWare_cog.dir/__/__/printer/printer.cpp.obj -c /home/pi/software/PropWare/PropWare/printer/printer.cpp

ersmith

I notice "-mcog" on the command line. fcache isn't supported in COG mode, so the expansion of your inline assembly in abstractsimplexuart.h is failing. This wouldn't only be a Raspberry Pi issue, it should happen on any platform.

One solution would be to just skip -mcog for PropWare builds. Another would be to wrap any inline assembly using fcache with #ifndef __PROPELLER_COG__ (and perhaps provide an alternate implementation in the event that __PROPELLER_COG__ is defined, which means that -mcog is in effect).

ersmith

To clarify further: "fcache" isn't a real instruction, of course, it's a kind of built in macro in the GNU assembler that expands to a call to the fcache load routine in the LMM or CMM kernel. Since it does depend on a kernel, the macro is only defined when -mlmm (or some similar memory model that has a kernel, like CMM or XMM) is given to the assembler. PropGCC uses the fcache macro for simplicity and because it expands to a special compressed sequence in CMM mode.

DavidZemon

oh! of course. i didn't even notice that it was attempting to compile with -mcog.

Here's the file compiled from my Ubuntu 15.10 x64 machine with a recent version of GCC 4 from my build server.

/opt/parallax/bin/propeller-elf-gcc     -save-temps  -Os -m32bit-doubles -Wall     -std=gnu++0x -fno-exceptions -fno-rtti -fno-threadsafe-statics -mcog   -I....../PropWare  -o CMakeFiles/PropWare_cog.dir/__/__/printer/printer.cpp.obj -c ....../PropWare/PropWare/printer/printer.cpp

ersmith

Both files have the fcache, but only one caused an error? Sounds like the RPi and Ubuntu have different versions of the GNU assembler, and one of them is old and/or buggy. The fcache code certainly won't work in -mcog mode, so the assembler should flag it.

DavidZemon

ersmith wrote: »

Both files have the fcache, but only one caused an error? Sounds like the RPi and Ubuntu have different versions of the GNU assembler, and one of them is old and/or buggy. The fcache code certainly won't work in -mcog mode, so the assembler should flag it.

Definitely agreed. But yes, the one on Ubuntu assembles without error. I can provide the pre-processed C++ file tonight if that would help you debug this. Didn't think about that this morning or else I would have already.

DavidZemon

Here's the pre-processed file (in a zip since .ii files aren't allowed)

ersmith

Thanks. It looks like there were two problems:

(1) Your raspberry pi assembler was out of date, and didn't have the fcache macro
(2) The up to date assembler allowed fcache even in cog mode

I've added errors for use of LMM macros in non-lmm mode, so your Ubuntu builds should error now as they should.

I'm not sure why your raspberry pi assembler was old. Are cross-builds working OK?

DavidZemon

ersmith wrote: »

Thanks. It looks like there were two problems:

(1) Your raspberry pi assembler was out of date, and didn't have the fcache macro
(2) The up to date assembler allowed fcache even in cog mode

I've added errors for use of LMM macros in non-lmm mode, so your Ubuntu builds should error now as they should.

I'm not sure why your raspberry pi assembler was old. Are cross-builds working OK?

I just grabbed that from SimpleIDE. I think I tried the Pi build from my server a couple weeks ago and it didn't work. I'll give it another go tonight.

DavidZemon

Well you certainly fixed the bug. Now my PropWare builds are failing

DavidZemon

PropWare is now fixed. I think my solution is rather elegant. The following snippet now resides at the top of PropWare.h

#ifdef __PROPELLER_COG__
#define FC_START(start, end)
#define FC_END(end)
#define FC_ADDR(to, start) to
#else
#define FC_START(start, end) \
    "        fcache #(" end " - " start ")\n\t" \
    "        .compress off\n\t" \
    start ":\n\t"
#define FC_END(end) \
    "        jmp __LMM_RET\n\t" \
    end ":\n\t" \
    "        .compress default\n\t"
#define FC_ADDR(to, start) "__LMM_FCACHE_START+(" to " - " start ")"
#endif

And so an example fcache function looks something like this:

inline void shift_out_data (uint32_t data, uint32_t bits, const uint32_t bitCycles,
                            const uint32_t txMask) const {
    volatile uint32_t waitCycles = bitCycles;
    __asm__ volatile (
            FC_START("ShiftOutDataStart%=", "ShiftOutDataEnd%=")
            "        add %[_waitCycles], CNT                                           \n\t"

            "loop%=:                                                                   \n\t"
            "        waitcnt %[_waitCycles], %[_bitCycles]                             \n\t"
            "        shr %[_data],#1 wc                                                \n\t"
            "        muxc outa, %[_mask]                                               \n\t"
            "        djnz %[_bits], #" FC_ADDR("loop%=", "ShiftOutDataStart%=") "      \n\t"
            FC_END("ShiftOutDataEnd%=")
    : [_data] "+r"(data),
    [_waitCycles] "+r"(waitCycles),
    [_bits] "+r"(bits)
    : [_mask] "r"(txMask),
    [_bitCycles] "r"(bitCycles));
}

@ersmith,

Is this something that would be helpful to have in propeller.h?

ersmith

Those are neat macros. I don't think they're quite right for propeller.h (which is kind of more lower level) but definitely a propware/utilities.h file would be handy for a lot of people.