[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Help needed for small assembler script for the iraf package



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

On 02.01.2018 11:06, Ian Campbell wrote:
> On Mon, 2018-01-01 at 15:20 +0100, Ole Streicher wrote:
>> 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.
> 
> My arm ASM is a bit rusty but doesn't this first instruction:
> 	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
> (uncompiled/untested):
> 
> 	str	xzr, [x1]      @ *status = 0
> 	str	x1, [x0]       @ buf[0] = status
> 	add	x0, x0, #8     @ &buf[1] --> 1st arg for sigsetjmp
> 	mov	x1, xzr        @ 0       --> 2nd arg for sigsetjmp
> 	b	__sigsetjmp    @ call sigsetjmp
> 
> 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.
> 


Reply to: