Probably the most common question I get asked about NetBSD/arm26 is "can
it run arm32 programs?".  So far, my answer has been "no".  I'd like to
change this.  This will require some co-operation from the arm32 side, but
if it could be achieved at the same time as the ELF transition (and before
arm26 gets shared libraries), I think it would be fairly painless.

What we need to do is to arrange for GCC to produce code that'll run
correctly both in USR32 mode on new ARMs and in USR26 mode on old
ones.  Conveniently, this is more-or-less the same problem the RISC OS
world is facing, since they're finally having to abandon 26-bit modes.  We
may be able to make use of their efforts.

Clearly, the calling convention used by portable binaries will have to be
a 32-bit APCS variant (RISCOS Ltd call it APCS-32).  Unfortunately, GCC
uses "-mapcs-32" to mean that the code will be running in a 32-bit mode,
and not just that a 32-bit APCS should be used.  Either this needs to be
corrected, or a new flag to specify mode-independent code will be
needed.  In either case, the APCS variant and the target mode need to be
distingushed.

In GCC 2.95.2, -mapcs-32 affects the following:

 - Whether thumb interworking is possible (arm.c:362)
 - What kind of CPUs can be selected. (arm.c:376)
 + Function return conventions (arm.c:5372)
 + Preservation of PSR over calls (arm.c:6440)
 * Setting of MASK_RETURN_ADDR

Now, the first two should probably be made fairly relaxed for the new
mode.  The next two should follow -mapcs-32, and the last one is
interesting.  MASK_RETURN_ADDR needs to be an rtx that is used to mask off
the PSR bits from return addresses, and hence needs to generate code to
check the processor mode at runtime.  The recommeded way to do this is:

        TEQ     R0, R0          ; sets Z (can be omitted if not in User mode)
        TEQ     PC, PC          ; EQ if in a 32-bit mode, NE if 26-bit

Working out how to put this into GCC needs someone who understands its
depths better than I.

A final thing that needs to be considered is that arm26 requires sections
to be aligned on 32k boundaries, so the linker will have to be set up to
arrange this.

So, do people think all this is a good idea?  Does anyone understand GCC
well enough to help implement that side of it?  What have I forgotten?

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