Towards the compiler

[schoeberl]

Not really an issue, but notes (from @Emoun) what needs to be done in the Patmos C source files and in the handbook:

Changes:

• Can no longer use clang as a linker using the below flags: "-fpatmos-nolibsyms", "-fpatmos-noruntimelibs", "-fpatmos_link_object" Instead, use "-c" to create object files and then call the linker directly.
• Removed flag "-fpatmos-skip-opt". Using "-O0" instead.
• Removed flag "-fpatmos-emit-asm". Using "-S" instead.
• Multiple "patmos-clang" patmos-specific flags have been removed. Instead, call the equivalent "patmos-ld" flags using "-mllvm" prefix: "-mpatmos-disable-stack-cache" -> "-mllvm --mpatmos-disable-stack-cache" "-mpatmos-disable-function-splitter" -> "-mllvm --mpatmos-disable-function-splitter" "-mpatmos-disable-vliw" -> "-mllvm --mpatmos-disable-vliw" Note how the flags need 2 "-" instead of the previous 1.
• Removed flag "-Xgold". Using "-Wl," instead.
• Removed flag "-Xllc". Using "-mllvm" instead.
• In inline assembly, input-, ouput-, and clobber registers should no longer have a "$" prefix. I.e. instead of "$r1" use "r1" as clobber register. In the inline assembly proper, registers need/allow 1 "$" only.
• Naked functions can only include inline assembly. No other code is allowed per the C standard. If you want to use C code in a naked function, you can manually call a non-naked function from the inline assembly.

Notes: Handbook says by default clang compiles to bitcode (section 8.2.1). This is wrong.

[schoeberl]

Naked functions are not allowed to have C code? That isn't good. What about the bootloader?

[Emoun]

Yes, see here for the definition in RISC-V and here for how microsoft treats them. We need to stick to convention and also disallow C code in naked functions.

This not an issue, as you can call another function that is implemented in C after you do any needed setup. The std _start function has already been fixed so it uses naked functions correctly. I did not consider that the bootloader also has a start function that is naked, so I'll get that fixed at some point too.

[schoeberl]

The Microsoft statement does not explicitly disallow C code. But I see the point. I guess this is not a C standard, but compiler-specific.

On bootloader: don't you need to start with a naked function anyway as long as no one has setup at least the stack pointer?

[Emoun]

Yes, you are right about microsoft, but GCC seems to me to treat C code in naked functions as undefined behavior. I presume clang by extension does the same, but did not find any documentation for this after a quick search.

Our bootloader does start with a naked function that sets up the stack using inline asm.

[schoeberl]

But it calls C functions with C code (the call is C, not inline assembly): https://github.com/t-crest/patmos/blob/f237b5ce18f5f853362541c4010ea4ffd8826e8f/c/include/bootable.h#L67 Is this considered OK, then?

[Emoun]

No, not in my opinion. That is what I was refering to earlier that I need to fix. Just like I fixed the newlib start function.

[schoeberl]

But there you the call itself in assembler, but the bootloader does not. Could this be the issue with the bootloader?

[Emoun]

It definitely needs fixing. I don't think it's the current issue, as I seem to remember the bootloader failing only when downloading a program and not before. But perhaps the issue only manifests at that point but is indeed caused by _start. We will see when I get to it.

[schoeberl]

I would propose to wrap those three functions into one, so you only need to call one function from assembler.