Using setjmp/longjmp seems to crash chip

[technoblogy]

A program implementing setjmp/longjmp for error recovery seems to have problems opening a serial port. Demonstration:

#include <setjmp.h>

jmp_buf exception;

void error () { Serial.println("Error"); longjmp(exception, 1); }

void setup () {
  Serial.begin(9600);
  Serial.println("Starting");
}

void loop () {
  if (!setjmp(exception)) {}
  Serial.println("Waiting");
  delay(10000);
  error();
}

Hangs up with no port available on arduino-pico core 1.9.15. Works OK on Arduino Mbed OS RP2040 Boards core version 2.6.1.

Test setup:
Raspberry Pi RP2040 board
MacBook Pro with macOS High Sierra 10.13.6
Arduino IDE 1.8.13

[earlephilhower]

I'm far from an ARM asm guru, but it looks like the toolchain is including setjmp which expects there to be non-Thumb mode support. Cortex-M0+ only support Thumb mode AIUI so this will cause an invalid instruction processor exception on the bx pc and a nice hang of the chip:

100086dc <setjmp>:
100086dc:       4778            bx      pc
100086de:       46c0            nop                     ; (mov r8, r8)

100086e0 <.arm_start_of.setjmp>:
100086e0:       e8a07ff0        stmia   r0!, {r4, r5, r6, r7, r8, r9, sl, fp, ip, sp, lr}
100086e4:       e3a00000        mov     r0, #0
100086e8:       e31e0001        tst     lr, #1
100086ec:       01a0f00e        moveq   pc, lr
100086f0:       e12fff1e        .word   0xe12fff1e

100086f4 <longjmp>:
100086f4:       4778            bx      pc
100086f6:       46c0            nop                     ; (mov r8, r8)

100086f8 <.arm_start_of.longjmp>:
100086f8:       e8b07ff0        ldm     r0!, {r4, r5, r6, r7, r8, r9, sl, fp, ip, sp, lr}
100086fc:       e1b00001        movs    r0, r1
10008700:       03a00001        moveq   r0, #1
10008704:       e31e0001        tst     lr, #1
10008708:       01a0f00e        moveq   pc, lr
1000870c:       e12fff1e        .word   0xe12fff1e

[technoblogy]

I don't really understand. How does it work on the Arduino Mbed OS RP2040 Boards core then?

[earlephilhower]

They have a different and older toolchain than this one. It's a trivial fix, but to do it properly needs a rebuild of the tools tarball. Basically have to make sure that Newlib's setjmp.S doesn't emit non-Thumb and it works fine (I just copied the file and manually hacked the change and your uLisp runs fine). See earlephilhower/pico-quick-toolchain#7

[technoblogy]

This is all way over my head, but if it can be fixed that would be great!

[earlephilhower]

Latest release should get your app running. If you use the IDE, the update will take care of everything. If you use git, then you'll need to run tools/get.py to download and install the new fixed toolchain. Thx for the concise MCVE!

[technoblogy]

Works perfectly - thanks!

Also it seems to run my benchmarks substantially faster than the Arduino Mbed OS RP2040 Boards core:

Arduino Mbed OS RP2040 Boards core: (tak 18 12 6) takes 8.9 seconds.
arduino-pico core 1.10.0: (tak 18 12 6) takes 5.5 seconds.

[earlephilhower]

Also it seems to run my benchmarks substantially faster than the Arduino Mbed OS RP2040 Boards core:
Arduino Mbed OS RP2040 Boards core: (tak 18 12 6) takes 8.9 seconds.
arduino-pico core 1.10.0: (tak 18 12 6) takes 5.5 seconds.

I'm not sure how it could be almost 2x slower on MBED. They do have extra levels of indirection because they're driver-based vs. pure native, but I wouldn't think it would be that harsh of a speed penalty.

If you want real apples-to-apples, use the Tools->CPU Speed->133MHz and re-run. Should give ~6% boost assuming it's CPU limited. Or, bump it up to 250MHz and see it really burn. 🔥

[technoblogy]

If you want real apples-to-apples, use the Tools->CPU Speed->133MHz and re-run. Should give ~6% boost assuming it's CPU limited. Or, bump it up to 250MHz and see it really burn. 🔥

I’ll let you know when I’ve run all the benchmarks, and updated this page: http://www.ulisp.com/show?36M3 Regards, David