Subject: ARM3/ARM6 compatibility

From: Matthew Wilcox <[email-masked]>
Date: Thu, 15 May 1997 10:19:55 +0100 (BST)

Since the two architectures /are/ different, it would make sense to have
two different magic numbers - one for 26 bit code and one for 32 bit code.
It would then be possible to have a binfmt_aout26 module that would do
the necessary magic to run the app in 26 bit code space if you weren't
going to run 26 bit code often.  As far as I can see, this should be
a matter of setting the appropriate bit in the CPSW to set the flag.
32 bit data should still be okay, I think.

An alternative measure would be to compile all code for 32 bit - it
will run on all machines; the only problem will be that it's slightly
less efficient.

Obviously, that's not terribly good for the kernel; I think we should
always have a specific architecture set up for the kernel - since that's
the least of the worries.

---

From: Philip Blundell <[email-masked]>
Date: Thu, 15 May 1997 15:58:27 +0100 (BST)

> 32 bit data should still be okay, I think.

That's basically what I was thinking.

> the least of the worries.

Of course.  Given that the drivers and so on need to be different,
compiling for a specific CPU is a trivial matter.  But people ought to be
able to take a user binary of unknown provenance, and either run it in the
knowledge that it will work correctly, or (at worst) get an error message.
Random lossage is not an acceptable option. ;-)

p.

---

From: [email-masked]
Date: Thu, 15 May 1997 22:14:34 +0100 (BST)

> Random lossage is not an acceptable option. ;-)

ARM3 code will run on ARM6, ARM7, ARM8, SA110 with no problems under linux.
There is no need to complicate the issue with different magic numbers!

If you do go to 32-bit aout binaries, then you WILL have problems on ARM3
machines.  The problem is not obvious, but basically if you use shared C
libraries on 32-bit, they will be located at 0x60000000, which is, obviously,
an invalid address on ARM3.

The solution is to set a flag in the a.out header to indicate 32-bit.  That
way, there is absolutely no need to change the binutils (apart from setting
said flag if you're using 32-bit).  *Nothing else changes*.

Simple solution isn't it?  And it involves the least work!
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |       Russell King      [email-masked]         --- ---
  | | | | http://whirligig.ecs.soton.ac.uk/~rmk92/home.html  /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |      *  who wishes that he was in Hong Kong  *      ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Philip Blundell <[email-masked]>
Date: Fri, 16 May 1997 10:56:49 +0100 (BST)

> machines.  The problem is not obvious, but basically if you use shared C

Or if you go to newer processors (Thumb etc) you will have problems with
26-bit binaries.

> said flag if you're using 32-bit).  *Nothing else changes*.

Yeah - that's basically the same solution that Matthew proposed. 

p.