Subject: Re: Arm Linux

From: [email-masked] (John Tytgat)
Date: Mon, 20 Jan 1997 13:40:17 +0000 (GMT)

From:	ADMVAX::SMTP%"[email-masked]" 20-JAN-1997 13:36:37.10
To:	OCTAAF::_JOTY
CC:	
Subj:	Re: Arm Linux

Date: 	Mon, 20 Jan 1997 12:25:15 +0000 (GMT)
From: Philip Blundell <[email-masked]>
X-Sender: [email-masked]
To: Joseph Heenan <[email-masked]>
Cc: [email-masked]
Subject: Re: Arm Linux
In-Reply-To: <[email-masked]>
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk

On Mon, 20 Jan 1997, Joseph Heenan wrote:

> Perhaps I've got the wrong end of the stick here - I'd assumed
> debian would be a lot of C sources that just need perhaps the odd
> bit of inline assembler rewriting. Surely the C compiler should handle
> all the platform specific things, apart from inline assembler?

No.  To take a contrived example, imagine you have this:

unsigned char foo[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
unsigned int *bar;

bar = (unsigned int *)(foo+1);
printf("bar = %08x\n", *bar);

On Intel, this gives:

kings-cross:~$ ./align
bar = 05040302
kings-cross:~$

On Alpha, this gives:

paddington:~$ ./align 
align(1964): unaligned trap at 0000000120000a74: 000000011ffff711 28 2
bar = 05040302
paddington:~$

But on an old ARM, you will get `bar = 0x04030201'.  The reason is that
the dereference of `bar' compiles to an LDR instruction.  In general, the
compiler can't know the alignment at compile-time, so there's not a lot
else it *can* do.  Old ARM machines silently discard the low two address
bits when you ask them to do a word access.  This differs, as I said
before, from the Intel (where you get the correct access performed, albeit
more slowly) and the Alpha/SPARC/etc (where you get a fault, and your OS
has to patch up in software).

This sort of thing doesn't crop up *that* often, but it does happen, and
code will go wrong when it does.  There is *very* little inline assembler
in most things, and I doubt much porting work will be needed in general.
A lot of autoconf scripts will probably need to be taught about Linux/ARM,
but other than that...

> Basic sounds like quite a good idea. Shame it's copyright, really -
> a basic interpretter running under general unix has some sort of appeal
> to it :-)

Yes.  OTOH, although it's copyright, if it's in ROM it can be used fairly
freely.  Someone sufficiently sick could probably write a snippet of code
to be run as root that rummages around the RISC OS ROMs and pulls out the
BASIC module. 

P.

---

From: Matthew Wilcox <[email-masked]>
Date: Wed, 22 Jan 1997 09:25:02 +0000 (GMT)

> has to patch up in software).

To be pedantic.. you will get 'bar = 0x01040302'.  It's the MEMC's fault
rather than the ARM's fault - it could pull the ABRT line high and allow
the OS to patch up in software.  Or it could do two memory accesses and
give the word that you wanted.  But it does neither of these things.  And
it's a bit late to demand a new version of the MEMC from ARMltd!

---

From: Philip Blundell <[email-masked]>
Date: Wed, 22 Jan 1997 23:27:10 +0000 (GMT)

> To be pedantic.. you will get 'bar = 0x01040302'.  It's the MEMC's fault

Uh, yeah, brain out of gear there.  But the point is valid -- you won't
get what you'd naively expect (and what you get on other architectures),
and - worse - you have no way of knowing that the result you've just
picked up is duff.

P.

---

From: Philip Blundell <[email-masked]>
Date: Wed, 22 Jan 1997 23:27:10 +0000 (GMT)

P.

---

From: [email-masked]
Date: Thu, 23 Jan 1997 22:28:29 +0000 (GMT)

> and - worse - you have no way of knowing that the result you've just

If this talk about unaligned accesses is about the X server, then it is
entirely irrelevent.  The generic code will use aligned accesses whenever
possible anyway, since one of the pieces of information that the Colour
Frame Buffer requires is the number of pixels per word.

The only improvement that can be made is to replace the low-level routines
with assembly versions.

Below, I have included the assembly code for the vertical/horizontal line
drawing routines (cfbhrzvert.c).  It has other areas that can provide a
significant improvement:

   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |       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: Thu, 23 Jan 1997 23:55:16 +0000 (GMT)

> Frame Buffer requires is the number of pixels per word.

It's not.  There is much user-space software out there, some of it quite
fundamental (eg fdisk) that does unaligned accesses.  This is quite a
problem for us -- Alpha people and the like can fix the ones that happen
often and ignore the rest, because they just take a tiny performance hit.
But on the ARM there is the possibility to actually get wrong data from an
unaligned access, and this is something that people who are going to port
packages need to watch out for. 

It's not likely to apply to anything that was developed with the ARM in
mind, like your X server. 

P.