Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1639 > unrolled thread

ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi)

Back to article view | Back to comp.sys.acorn.programmer

Contents

  ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Chris Evans <chris@cjemicros.co.uk> - 2012-04-19 13:05 +0100
    Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-04-19 14:15 +0100
      Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Chris Evans <chris@cjemicros.co.uk> - 2012-04-19 16:10 +0100
        Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-04-19 18:41 +0200
        Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Steve Fryatt <news@stevefryatt.org.uk> - 2012-04-19 19:46 +0100
          Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Martin Wuerthner <spamtrap@mw-software.com> - 2012-04-19 21:24 +0200
    Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-04-19 18:32 +0200
    Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) chrisbazley@bigfoot.com - 2012-04-29 06:37 -0700
      Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-04-29 15:47 +0100
      Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Gerph <gerph@gerph.org> - 2012-04-29 07:39 -0700
      Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) druck <news@druck.org.uk> - 2012-04-29 19:30 +0100
      Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-04-30 06:16 +0200
        Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) druck <news@druck.org.uk> - 2012-04-30 22:47 +0100
        Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Gerph <gerph@gerph.org> - 2012-04-30 15:30 -0700
          Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-05-02 19:26 +0200
            Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Gavin Wraith <gavin@wra1th.plus.com> - 2012-05-02 21:02 +0100
            Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) druck <news@druck.org.uk> - 2012-05-02 22:33 +0100
              Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) cferris@freeRemoveuk.com.invalid - 2012-05-02 23:37 +0100
                Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-05-03 06:25 +0200
                Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) trevj <trevj@cwazy.co.uk> - 2012-05-03 13:01 -0700
            Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-05-04 06:30 +0200
              Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Martin Wuerthner <spamtrap@mw-software.com> - 2012-05-04 11:55 +0200
                Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-05-04 22:39 +0100
              Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-05-05 17:58 +0200
                Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-05-05 17:22 +0100
          Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Simon <simon.willcocks@t-online.de> - 2012-05-04 04:24 -0700
        Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-05-01 21:33 +0100
          Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Gerph <gerph@gerph.org> - 2012-05-01 17:06 -0700
          Re: ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi) Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-05-02 19:02 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1689

On Wed, 02 May 2012 19:26:23 +0200, Rick Murray 
<heyrickmail-usenet@yahoo.co.uk> wrote:

> Indeed, my suggestion was to trap aborts

To follow up on my reply, having waded through both ARM ARMs and 
countless PDFs, is that there are two approaches to this problem.

1. The logical (Gerph) approach
This is to wait for the MMU to raise a Data Abort and then patch it 
up. I suspect reality is somewhat more complicated given that the 
current RISC OS has an option to control alignment exceptions - why 
would that be necessary if the OS could provide support for unaligned 
accesses?

2. The you-will-work-dammit approach (as I touted earlier)
Mark application memory as inaccessible, trap accesses, handle those 
that are unaligned. Sounds nastily complicated and faffy, but 
ironically is the only one guaranteed to work, given that handling of 
unaligned accesses varies depending on ARM family and memory 
controller. Some devices, to keep complexity/costs down may not only 
not support unaligned accesses, but may no even report this as an 
exception! An example is the LPC2148 (an older ARM7 based SoC). I've 
read my TMS320DM320 datasheets and the Broadcom sort-of-datasheet for 
the RPi, neither mention MMU handling in this case. As these are 
complex ARM+DSP things, I'd assume a complete MMU. Though, the fact 
remains that some cheaper and/or more basic devices may decide to 
omit this (and other) feature(s).
[note: I'm speaking as an ARM coder and not necessarily as a RISC OS 
one]


In essence, it would be most logical to avoid unaligned accesses 
altogether; certainly a little bit of wastage might be preferable to 
the problems that could be caused otherwise? If unaligned loads are 
required, this could be synthesized with LDRB, perhaps, unless aimed 
for a very specific device where its capabilities are known.



tl;dr: Just thinking aloud about the quirks of dealing with unaligned 
memory accesses.


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1690

In message <almarsoft.5638329217787058523@news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On Wed, 02 May 2012 19:26:23 +0200, Rick Murray
> <heyrickmail-usenet@yahoo.co.uk> wrote:

>> Indeed, my suggestion was to trap aborts

> To follow up on my reply, having waded through both ARM ARMs and
> countless PDFs, is that there are two approaches to this problem.

> 1. The logical (Gerph) approach
> This is to wait for the MMU to raise a Data Abort and then patch it
> up. I suspect reality is somewhat more complicated given that the
> current RISC OS has an option to control alignment exceptions - why
> would that be necessary if the OS could provide support for unaligned
> accesses?

This pragmatic approach is necessary because the OS *does not* provide 
support for unaligned accesses. It does not necessarily mean that the 
OS *could not* provide it. If anyone had done the work to add the 
required exception handling, there would be no need to allow users to 
turn the exception off.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1692

In message <4be2868a52.martin@bach.planiverse.com>
 on 4 May 2012 Martin Wuerthner  wrote:

> This pragmatic approach is necessary because the OS *does not* provide 
> support for unaligned accesses. It does not necessarily mean that the OS
> *could not* provide it. If anyone had done the work to add the required
> exception handling, there would be no need to allow users to turn the
> exception off.

Jeffrey Lee was working on this, but the last posting I can find talked about
how there was mixed success from this method.  Some programs were working
fine, but others were failing for other reasons, such as code unintentionally
entering Thumb mode:

http://www.riscosopen.org/forum/forums/3/topics/207?page=2

I might try asking whether anything further is likely to come of this work.

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#1694

On Fri, 04 May 2012 06:30:22 +0200, Rick Murray 
<heyrickmail-usenet@yahoo.co.uk> wrote:

> tl;dr: Just thinking aloud about the quirks of dealing with 
unaligned 
> memory accesses.

I've delved into this over the past few days and wrote up my findings 
at:
   http://www.heyrick.co.uk/armwiki/Unaligned_data_access

It isn't linked into anything yet, so feel free to register yourself 
and put in anything I may have missed, however my personal 
interpretation is, as much as humanly possible, stay the hell away 
from unaligned accesses.


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1696

Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:
> It isn't linked into anything yet, so feel free to register yourself 
> and put in anything I may have missed, however my personal 
> interpretation is, as much as humanly possible, stay the hell away 
> from unaligned accesses.

Nice summary.  But, assuming your memory dump is presented in the same way
as *Memory (ie byte ordering 3210 7654 BA98 FEDC), a word read from &8002,
being defined by:
?&8002 OR ?&8003<<8 OR ?&8004<<16 OR ?&8005<<24

isn't that &749302FE on the basis that ?&8002=&FE, ?&8003=&02, ?&8004=&93
and ?&8005=&74. In other words, I think you're writing in big-endian, not
little-endian, format.

Theo

[toc] | [prev] | [next] | [standalone]

#1691

On Apr 30, 6:30 pm, Gerph <ge...@gerph.org> wrote:
> I may be rusty in my low level ARM, but... you set the bit that
> indicates that you want unaligned loads to abort and you fix them up
> to behave in the manner that the currently active context expects them
> to operate. The bit in the system control register can be manipulated
> at any time, so could be changed based on the context quite easily,
> and instructions faulting erroneously can be restarted by toggling the
> state and reexecuting the instruction. Context switches would restore
> the state. The Fault Status Register contains an indication of why the
> fault occurred - in this case alignment problems - so this is a fast
> case to detect.

Exactly this.  It wouldn't hurt if the Linux kernel could do this
(probably as a personality), too, but it doesn't allow it, and I can't
see anywhere easy to add it.  You wouldn't know of anyone working on
it?

> No faffing with scanning code. No trapping of all memory accesses. No
> full scale emulation. You're only hooking into the abort handling code
> that already exists to fix up other cases, so a lot of your framework
> is already there. The only wrinkle might be that you're having to
> manipulate the context to understand which state you're in, but
> obviously you've moved on from the context model that was created 15
> years ago and the work that you've put in makes it trivial to do
> this... doesn't it ?

That wouldn't be a snark, would it?

[toc] | [prev] | [next] | [standalone]

#1680

Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:
> The answer is simple. Open Source. Those still in the RISC OS arena 
> will be able to modify. Those who have left, what have they got to 
> lose? It's no longer of commercial interest, so why not drop the code 
> someplace where it can be picked up if somebody is interested in 
> carrying on with it - thinking back to a short while ago the desired 
> updates to !Pluto, for instance. On the other hand, John's Pic_Index 
> was important to somebody, and a group effort got it patched up for 
> the new hardware.

Open source is half of the solution, but the other half is automated build
environments.  Putting a .zip on a random webserver is only useful if
someone picks it up and recompiles it, as long as they get together the
relevant compiler, libraries, etc.  This is quite a bit of manual work.  But
if the code is in an automated build environment (the ones we have being
GCCSDK and NetSurf's own) you just do 'make all'...  all the libraries are
built for you, and an executable comes out.  Even if the program is
abandoned, anyone can run 'make all' and produce a new executable.  Want to
recompile everything to use ARM v7 NEON for floating point?  Change a few
compiler flags and rebuild all your programs with one command - no need to
mess about with each one individually.

Theo

[toc] | [prev] | [next] | [standalone]

#1681

On May 1, 9:33 pm, Theo Markettos <theom+n...@chiark.greenend.org.uk>
wrote:
> Rick Murray <heyrickmail-use...@yahoo.co.uk> wrote:
> > The answer is simple. Open Source. Those still in the RISC OS arena
> > will be able to modify. Those who have left, what have they got to
> > lose? It's no longer of commercial interest, so why not drop the code
> > someplace where it can be picked up if somebody is interested in
> > carrying on with it - thinking back to a short while ago the desired
> > updates to !Pluto, for instance. On the other hand, John's Pic_Index
> > was important to somebody, and a group effort got it patched up for
> > the new hardware.
>
> Open source is half of the solution, but the other half is automated build
> environments.  Putting a .zip on a random webserver is only useful if
> someone picks it up and recompiles it, as long as they get together the
> relevant compiler, libraries, etc.  This is quite a bit of manual work.  But
> if the code is in an automated build environment (the ones we have being
> GCCSDK and NetSurf's own) you just do 'make all'...  all the libraries are
> built for you, and an executable comes out.  Even if the program is
> abandoned, anyone can run 'make all' and produce a new executable.  Want to
> recompile everything to use ARM v7 NEON for floating point?  Change a few
> compiler flags and rebuild all your programs with one command - no need to
> mess about with each one individually.

I might be missing the point, but suggesting that the solution to
things not working on hardware is 50% making things open source and
50% making things automated is ... just wrong.

Things being open source only changes the availability of the code,
not whether it works on systems.
Things being automatically built only ensures that the code builds,
not whether it works on systems.

Anyone who has any reasonable amount of software written will have a
form of automatable build, whether it is purely a makefile which
produces a binary, or a fully fledged release system, There is a huge
degree of difference between building your code and actually making it
work. If it was purely a matter of recompiling with a different set of
options for a new platform then the difficulty in updating to new
platforms would be negligible.

Automated builds of idle projects ensure that code-rot through other
changes do not cause failures which you are unaware of. Automated
builds of maintained projects ensure that changes to the code does not
break code, and can check for issues in configurations that you might
not be aware of, through the use of compilation directives and the
like. But automated builds will never tell you whether the code will
actually work.

Assuming that automated builds of abandoned code will ensure that the
code is updating requires the assumption that the 'abandoned' code has
people watching it that a) care that the abandoned code if broken, b)
have the inclination to address the issues that the build shows, and
c) have the ability to fix the issues that the build shows. And
that's, obviously, just for the build, before you get into actually
running the code. It is also important that 'having the ability to fix
the issues' is not confused with 'believing they have the ability to
fix the issues' - there's a great many ways to 'fix' things that
aren't the right solution, and fixing an automated build can be vastly
different from addressing a core problem.

Sorry... longer ramble than I meant to have this late at night, but I
don't believe that the problem of applications failing to work on
differing hardware is solved by making things open source and
automating their build.

--
Gerph, so very, very tired.

[toc] | [prev] | [next] | [standalone]

#1682

On 01 May 2012 21:33:45 +0100 (BST), Theo Markettos 
<theom+news@chiark.greenend.org.uk> wrote:

> Open source is half of the solution, but the other half is 
automated build
> environments.  Putting a .zip on a random webserver is only useful 
if
> someone picks it up and recompiles it, as long as they get together 
the
> relevant compiler, libraries, etc.  This is quite a bit of manual 
work. 

Indeed it is.

Problem is, it is only viable for projects using open source 
components. Most of my code is assembled with the Castle dev suite 
(and prior was with Acorn/Norcroft). I plan to update to ROOL's one. 
It is a drop-in replacement, but is a prerequisite. Converting across 
compilers is painful. I have the code for the Windows version of 
OakDraw that I'd love to fix a few bugs, update, etc. It was written 
for a Microsoft compiler, mine is OpenWatcom, and can you believe the 
latter has no GDIPlus library?!? It's a brick wall, I suspect. :-(

Anyway, nobody said it would be simple, but having code available 
(even if a random zip) is a massive step forward compared to hacking 
a binary.

I'm not sure the build environment is the solution. Sure, it helps 
massively, but - as I said - commercial compilers, if used, may well 
be a prerequisite...


Best wishes,

Rick.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web