Help needed for small assembler script for the iraf package

[Ole Streicher]

Dear arm64 specialists,

I just got the "IRAF" package accepted into Debian [1]. Although the
code is claimed to be portable, it needs a piece of assembler
code for each platform that provides a (sort of) setjmp() to their
Fortran variant.

A "C" implementation for this looks like:

#include <setjmp.h>

int zsvjmp_( long *buf, long *status ) {
*status = 0;
((long **)buf)[0] = status;
return sigsetjmp ((void *)((long **)buf+1),0);
}

however this does not work, since the "sigsetjmp" call needs to be
replaced by a jump to sigsetjmp instead.

I already wrote that code for the arm 32 bit platforms, which looks like
this:

-------------------------------8<-----------------------------------
.file "zsvjmp.s"
.arch armv6
.text
.global zsvjmp_
.type zsvjmp_, %function
zsvjmp_:
mov r2, #0 @
str r2, [r1, #0] @ *status = 0
str r1, [r0, #0] @ buf[0] = status
add r0, r0, #4 @ &buf[1] --> 1st arg for sigsetjmp
mov r1, #0 @ 0 --> 2nd arg for sigsetjmp
b __sigsetjmp @ call sigsetjmp
-------------------------------8<-----------------------------------

The "zdojmp" counterpart is a portable C function.

I created a small repository [2] that contains the assembler I collected
so far as well as two test programs. The function of the Fortran test
program is still not so important since IRAF uses its own Fortran
calling interface.

However, I have no idea how to write the same for the 64-bit platform
arm64 (the code in the repo does not work). Maybe someone could help me
here? Preferably under the IRAF license [3], so that it can be included
upstream later.

The arm platforms are specifically important for IRAF, since the package
is also used by semiprofessional astronomers who use a Raspberry Pi (and
similar) as observation platform, and there is some request to have IRAF
available there.

Best regards

Ole

[1] https://tracker.debian.org/pkg/iraf
[2] https://github.com/olebole/zsvjmp
[3] https://github.com/iraf/iraf-v216/blob/master/local/COPYRIGHTS

[Ole Streicher]

Hi Ian,

thank you very much! I already got an off-list answer from Peter Green
which seems to work well (at least, it passes my tests), and I uploaded
a version that supports all arm platforms now. The code is:

.file "zsvjmp.s"
.arch armv8-a
.text
.global zsvjmp_
.type zsvjmp_, %function

zsvjmp_:
str xzr, [x1] // *status = 0;
str x1, [x0], 8 // ((long **)buf)[0] = status
// also post-increment x0 by 8: 1st arg for sigsetjmp
mov w1, 0 // 0 --> 2nd arg for sigsetjmp
b __sigsetjmp // call sigsetjmp

(Using @ as comment delimiter did not work, so I switched to //)

Best regards

Ole

Post by Ole Streicher
However, I have no idea how to write the same for the 64-bit platform
arm64 (the code in the repo does not work). Maybe someone could help
me here? Preferably under the IRAF license [3], so that it can be
included upstream later.

stp x29, x30, [sp, -32]!
cause sp to be updated (due to the "!")? That leaves the current stack
frame unbalanced since nothing undoes the push before the branch to
__sigsetjmp which cannot itself know to undo that change, so presumably
when __sigsetjmp (or whatever comes next) tries to return over this
stack frame explodes.
It looks like the intention is to preserve x29 in order to use it as a
scratch register, perhaps just use one of the caller saved registers
instead? (infocentre.arm.com seems to be down so I can't refresh my
memory which registers that would be).
Compared to the armhf version it seems to be making a lot of use of
spilling things to the stack slots created by moving sp, and seems to
do awful lot of pointless looking shuffling (although I've not fully
traced through to try and figure out what it thinks it is doing). Does
a more direct translation of the armhf code work, something like
Apart from changing the register names the main difference from armhf
is the use of xzr instead of loading 0 into r2 and the array step being
8 instead of 4. I also dropped the explicit 0 offsets on the stores,
not sure if that might be possible on the armhf side too -- perhaps the
eventual instruction encoding is the same either way.
I hardly feel like it deserves my copyright, but for formalities sake
please feel free to take the above snippet under an IRAF license.
Ian.