On Mon, 8 Jan 2001, Chris Gilbert wrote:

> On Friday 29 December 2000  8:25 pm, Ben Harris wrote:
> > As people may have noticed, I've created a directory for shared NetBSD/arm
> > libc sources, and made the arm26 port use it.  Now, does anyone want to
> > make arm32 use it as well?
> 
> I'll probably take a look at some point (next weekend).  Do we have any 
> guidelines on doing generic asm code for both arm26 and arm32.  I believe 
> that it's mostly the MOV PC, LR kinda thing?

Indeed.  Here, have some guidelines:

When returning from a function, APCS-26 code must restore the flags in the
PC to those recorded in R14 on function entry.  APCS-32 code must not
attempt this.  Thus, return from a function which doesn't create a stack
frame will look like this:

#ifdef __APCS_26__
	movs	pc, lr
#else
	mov	pc, lr
#endif

Functions which create a stack frame return something like this:

#ifdef __APCS_26__
	ldmdb   fp, {r4, fp, sp, pc}^
#else
	ldmdb   fp, {r4, fp, sp, pc}
#endif

Note that because NetBSD/arm26 is likely to eventually move to APCS-32,
arm26-specific code should still follow these guidelines.


Any code that might run in SVC mode and cause a data abort must be able to
cope with such data aborts corrupting R14.  Prefetch aborts, undefined
instructions, SWIs and address exceptions will also corrupt R14, but
should never occur in the kernel anyway. [Aside:  This might mean that
memcpy needs work, since it uses R14 as a scratch register.]

> Perhaps we should think of some 
> defs for future proofing stuff, eg making the code #ifdef based on the target 
> architecture?

At present, I'm using GCC's __APCS_26__ predefine, which it turns on when
you specify -mapcs-26.  There's some evil in libc because the system call
stubs are made with cpp, which doesn't throw in the usual mix of
predefines, so I manually predefine __APCS_26__ in the arm26 case.

Linux has a bunch of macros (LOADREGS, RETINSTR etc) that are
conditionally defined per architecture to do the right thing.  I think
that's unnecessary in this case, since we shouldn't be using APCS-26 much
longer.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>