At 08:57 PM 11/24/2000 +0000, Ben Harris wrote:
>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.

Heh.  There may be application on arm32 that may need more than 32MB
of address space (mozilla, ld making mozilla :), so will there be a way
to have 32bit code call shared 26/32 code? (aka libc)?

>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.

Given the above paragraph, this seem possible.  BTW, this mode will need
a special OSABI value in ELF.

>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.

Hmmm.  Not having looked closely at the arm32.{c,h,md} I don't know
how difficult this will be but it should be possible.

>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.

That's just linker script editing. :)

>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?

Yes it's a good idea.  You might ask Richard Earnshaw <rearnsha@arm.com>
since he's done most of the arm32 gcc work.
--
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message