Avoiding assembly code (NLR question)

[igorgatis]

I'm port micropy to a platform which "requires" Keil's ARM toolchain. I'd like to avoid assembly code if possible (let's say I have reasons for that).

Apparently, one can acoid assembly code by defining MICROPY_NLR_SETJMP (which will use setjmp/longjmp instead). However, PY_O_BASENAME still lists

nlrx86.o \
nlrx64.o \
nlrthumb.o \
nlrxtensa.o \

Which are all produced by assembly code. Does it make sense to remove these from PY_O_BASENAME when MICROPY_NLR_SETJMP is set?

A more general question: how to choose between Assembly based NLR or setjmp/longjmp NLR?

[pfalcon]

Which are all produced by assembly code. Does it make sense to remove these from PY_O_BASENAME when MICROPY_NLR_SETJMP is set?

You will find the answer as soon as you look inside those files.

A more general question: how to choose between Assembly based NLR or setjmp/longjmp NLR?

Wait, above you wrote that you do this by defining MICROPY_NLR_SETJMP, so what you're asking about?

[igorgatis]

They all became empty when MICROPY_NLR_SETJMP is defined.

My tool chain was not being able to properly preprocess .S files and thus defining MICROPY_NLR_SETJMP was not doing the trick. Do you think it make sense to modify py.mk to only compile nlr*.S if MICROPY_NLR_SETJMP is not defined?

What I meant was: why there are two ways of doing NLR? One uses setjmp/longjmp? The other uses assembly (which is harder to port).

I was guessing the answer would be performance. But it could also be because setjmp/longjmp is preferable but it might not be available so assembly option is provided.

[dhylands]

In order to properly do garbage collection, it needs to know the values of registers which may be pointing into the heap. It would be bad if the garbage collector freed an object which was still be referenced by a register.

So the NLR routines are optimized assembly functions which make those registers available to the garbage collector.

it turns out that setjmp also saves away all of the register values, so in the event that a customized assembly version is not available, then the more generic setjmp routine can be used instead. setjmp works, but isn't optimized for the purpose at hand.

[pfalcon]

My tool chain was not being able to properly preprocess .S files and thus defining MICROPY_NLR_SETJMP was not doing the trick. Do you think it make sense to modify py.mk to only compile nlr*.S if MICROPY_NLR_SETJMP is not defined?

Yes, so the answer to your question would be: there's no need to modify it from MicroPython point of view, which uses standard full-featured toolchain. Of course, if you can't use such toolchain, it's up to you to do any modifications to suit it (but they likely won't be mergeable back to mainline MicroPython if that's what you care about).

I was guessing the answer would be performance. But it could also be because setjmp/longjmp is preferable but it might not be available so assembly option is provided.

No, it's of course the opposite - selected platforms have optimized assembly implementation, any other platforms can just use standard ANSI C setjmp/longjmp.

[igorgatis]

No, it's of course the opposite - selected platforms have optimized assembly implementation...

That's (of course) what I meant.