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 1 of 2  [1] 2  Next page →

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

AIUI
The Iyonix is ARMv5
The Raspberry Pi is ARMv6
The BeagleBoard/Panda board are ARMv7

Now I know most/all? Compiled programs and most? BASIC programs with Assembler
within, have needed to be updated to run on the BeagleBoard/Panda board (ARMv7)

What are differences between ARMv5 and ARMv6?
compared to the differences between ARMv5 and ARMv7

The basic question is will all(?) those programs that needed updating from
ARMv5 to ARMv7 also need to be updated for the Raspberry Pi?

and therefore may some Iyonix compatible programs that haven't been updated
work on the Raspberry without modification?

The ideal is that all programs will get updated to ARMv7 but we aren't in an
ideal world!

Chris Evans

-- 
CJE Micro's / 4D                'RISC OS Specialists'
Telephone: 01903 523222             Fax: 01903 523679
chris@cjemicros.co.uk     http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex,     BN11 2EN
The most beautiful thing anyone can wear, is a smile!

[toc] | [next] | [standalone]

#1640

The following bytes were arranged on 19 Apr 2012 by Chris Evans :

> The basic question is will all(?) those programs that needed updating from
> ARMv5 to ARMv7 also need to be updated for the Raspberry Pi?
>
> and therefore may some Iyonix compatible programs that haven't been updated
> work on the Raspberry without modification?

Sorry, but no.  The big change we usually talk about when we say "ARMv7
compatible" is the unaligned memory access problem, and that was
introduced in ARMv6 (but we had ARMv7 RISC OS computers before we had
ARMv6 ones, hence the ARMv7 name stuck).  As I understand it, the
differences between ARMv6 and ARMv7 are mainly to do with floating
point.

So if you were hoping for a free Raspberry Pi lunch - forget it!

-- 
  __<^>__
 / _   _ \           It is written that Geeks shall inherit the Earth.
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

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

#1641

In article <d8a3df8252.martin@blueyonder.co.uk>, Martin Bazley
<URL:mailto:martin.bazley@blueyonder.co.uk> wrote:
> The following bytes were arranged on 19 Apr 2012 by Chris Evans :
> 
> > The basic question is will all(?) those programs that needed updating from
> > ARMv5 to ARMv7 also need to be updated for the Raspberry Pi?
> >
> > and therefore may some Iyonix compatible programs that haven't been updated
> > work on the Raspberry without modification?
> 
> Sorry, but no.  The big change we usually talk about when we say "ARMv7
> compatible" is the unaligned memory access problem, and that was
> introduced in ARMv6 (but we had ARMv7 RISC OS computers before we had
> ARMv6 ones, hence the ARMv7 name stuck).  As I understand it, the
> differences between ARMv6 and ARMv7 are mainly to do with floating
> point.
> 
> So if you were hoping for a free Raspberry Pi lunch - forget it!

Thanks

Oh well. If you don't ask you don't learn!
At least I will now be able to explain correctly the situation to non
programers. 

p.s. I was told how to patch !Prophet for the BeagleBoard (Can't find the
details at present) IIRC it involved removing a ^ from towards the end of a
load or store assembler instruction. Is that to do with unaligned memory
access.

Pity you can't google ^

Chris Evans

-- 
CJE Micro's / 4D                'RISC OS Specialists'
Telephone: 01903 523222             Fax: 01903 523679
chris@cjemicros.co.uk     http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex,     BN11 2EN
The most beautiful thing anyone can wear, is a smile!

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

#1646

On 19/04/2012 17:10, Chris Evans wrote:

> p.s. I was told how to patch !Prophet for the BeagleBoard (Can't find the
> details at present) IIRC it involved removing a ^ from towards the end of a
> load or store assembler instruction. Is that to do with unaligned memory
> access.

No, the ^ *was* to instruct the processor to write back the program 
counter (current execution address) to R15, and ALSO write back the 
processor flags. You would be looking at something like:
   LDMFD R13!, {Rx-Ry, R14}^

This, however, has not worked in that way since the ARM went 32 bit and 
the processor flags moved into their own register (SPSR/CPSR). However, 
the exact behaviour is somewhat unpredictable and depends upon various 
factors, so it may be that the ^ instruction appears to work on one 32 
bit system, but goes horribly wrong on another.

What ^ means in 32 bit mode is to access the banked registers. In other 
words, if you are in FIQ mode you have a private R8 to R14 all to 
yourself. Now if for some reason you want to access the user mode R8, 
you would use ^ to tell the processor to pick up the user mode R8 and 
not the private FIQ R8.

Confused? You'll see now that the best way to explain the situation to 
non-programmers is the following phrase:
   technical-gobble-de-gook-mumble-mumble-mumble

:-)


Best wishes,

Rick.

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

#1648

On 19 Apr, Chris Evans wrote in message
    <ant19150372bpErr@client.cjemicros.co.uk>:

> p.s. I was told how to patch !Prophet for the BeagleBoard (Can't find the
> details at present) IIRC it involved removing a ^ from towards the end of
> a load or store assembler instruction. Is that to do with unaligned memory
> access.

Either you or your informant is confused, as the ^ was used to preserve
flags on multiple loads and stores.  It stopped working on the Iyonix, so
what you're describing above would have been done to make Prophet 32-bit
friendly.  Beagleboard compatibility involves removing unaligned loads and
stores, which is something completely different.

However, 32-bitting wasn't just "removing a ^ from towards the end of a load
or store assembler instruction".  It required reading all of the code
through carefully to ensure that the ^ wasn't required, and then removing
it.  Often this was the case (it being easier to always add a ^ when using
the stack, even if not required), but on the occasions when it *was* being
used then 32-bitting involved the rather more complex rewriting of the code
to make it work correctly without the ^.

-- 
Steve Fryatt - Leeds, England             Wakefield Acorn & RISC OS Show
                                             Saturday 28 April 2012
http://www.stevefryatt.org.uk/           http://www.wakefieldshow.org.uk/

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

#1649

In message <mpro.m2qpgu015g74w01k8.news@stevefryatt.org.uk>
          Steve Fryatt <news@stevefryatt.org.uk> wrote:

> On 19 Apr, Chris Evans wrote in message
>     <ant19150372bpErr@client.cjemicros.co.uk>:

>> p.s. I was told how to patch !Prophet for the BeagleBoard (Can't find the
>> details at present) IIRC it involved removing a ^ from towards the end of
>> a load or store assembler instruction. Is that to do with unaligned memory
>> access.

> Either you or your informant is confused, as the ^ was used to preserve
> flags on multiple loads and stores.  It stopped working on the Iyonix, so
> what you're describing above would have been done to make Prophet 32-bit
> friendly.  Beagleboard compatibility involves removing unaligned loads and
> stores, which is something completely different.

Correct in principle, but I have seen cases similar to the one 
described by Chris in practice. This happens because some of the 
supposedly 32-bit-unsafe instructions continued to work happily on the 
Iyonix, so programmers could get away with missing some of them.

The switch to the BeagleBoard finally uncovers 32-bit conversion 
glitches that went unnoticed before, and therefore, it can happen that 
"^" or "S" modifiers have to be removed from instructions to make a 
program that works fine on the Iyonix work on the BeagleBoard as well.

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

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

#1645

On 19/04/2012 14:05, Chris Evans wrote:

> What are differences between ARMv5 and ARMv6?
> compared to the differences between ARMv5 and ARMv7

In most cases, none.

I believe it is low-level stuff such as caching/MMU, etc.
Also support for things like load/save from unaligned addresses and how 
it is handled, plus family-specific things such as saturated maths, what 
DSPish instructions are available, etc. [though with the absolute 
plethora of ARM core variations, this is nothing new]

In terms of the OS, this stuff matters.

In terms of application programs, this may affect games and software 
like MP3/video decoders, but a program that uses the base ARM intruction 
set to get its job done should run without problems. It might, however, 
be necessary to recompile older code if the compiler made use of 
unaligned LDR/STR (though it has always been a rather unwise tactic 
since unaligned word access seems to change behaviour with each ARM 
family, but there you go...).


Best wishes,

Rick.

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

#1673

On Apr 19, 1:05 pm, Chris Evans <ch...@cjemicros.co.uk> wrote:
> AIUI
> The Iyonix is ARMv5
> The Raspberry Pi is ARMv6
> The BeagleBoard/Panda board are ARMv7
>
> Now I know most/all? Compiled programs and most? BASIC programs with Assembler
> within, have needed to be updated to run on the BeagleBoard/Panda board (ARMv7)
>
> What are differences between ARMv5 and ARMv6?
> compared to the differences between ARMv5 and ARMv7
>
> The basic question is will all(?) those programs that needed updating from
> ARMv5 to ARMv7 also need to be updated for the Raspberry Pi?
>
> and therefore may some Iyonix compatible programs that haven't been updated
> work on the Raspberry without modification?
>
> The ideal is that all programs will get updated to ARMv7 but we aren't in an
> ideal world!

No, the ideal is that RISC OS gets off the treadmill of recompiling
software for each new ARM architecture. Acorn recognized this was
unsustainable when they launched the StrongARM and there was still a
semblance of a viable commercial software market, which is why we have
the AppPatcher and UnsqueezeAIF mechanism.

A flag should have been allocated in all of the executable file
formats to mean 'unaligned data accesses have ARMv6 behaviour' and the
operating system should be responsible for emulating the pre-ARMv6
behaviour of unaligned data accesses for executables which do not have
this flag set (or rejecting such executables). Unfortunately, people
are still digging in their heels over the requirement since 16.5 years
ago for all Absolute files to have valid AIF headers, so that isn't
likely to happen.

Chris Bazley

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

#1674

The following bytes were arranged on 29 Apr 2012 by chrisbazley@bigfoot.com:

> the operating system should be responsible for emulating the pre-ARMv6
> behaviour of unaligned data accesses for executables which do not have
> this flag set (or rejecting such executables).

Are you volunteering to write such an emulator?  It's been on the cards
for some years but nobody's found the time yet.  You know where the
source is...

-- 
  __<^>__   "Start off every day with a smile and get it over with."
 / _   _ \  - W.C. Fields
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

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

#1675

On Apr 29, 2:37 pm, chrisbaz...@bigfoot.com wrote:
> On Apr 19, 1:05 pm, Chris Evans <ch...@cjemicros.co.uk> wrote:
>
>
>
>
>
>
>
>
>
> > AIUI
> > The Iyonix is ARMv5
> > The Raspberry Pi is ARMv6
> > The BeagleBoard/Panda board are ARMv7
>
> > Now I know most/all? Compiled programs and most? BASIC programs with Assembler
> > within, have needed to be updated to run on the BeagleBoard/Panda board (ARMv7)
>
> > What are differences between ARMv5 and ARMv6?
> > compared to the differences between ARMv5 and ARMv7
>
> > The basic question is will all(?) those programs that needed updating from
> > ARMv5 to ARMv7 also need to be updated for the Raspberry Pi?
>
> > and therefore may some Iyonix compatible programs that haven't been updated
> > work on the Raspberry without modification?
>
> > The ideal is that all programs will get updated to ARMv7 but we aren't in an
> > ideal world!
>
> No, the ideal is that RISC OS gets off the treadmill of recompiling
> software for each new ARM architecture. Acorn recognized this was
> unsustainable when they launched the StrongARM and there was still a
> semblance of a viable commercial software market, which is why we have
> the AppPatcher and UnsqueezeAIF mechanism.

Tra-la-la... not listening... nothing listening...

> A flag should have been allocated in all of the executable file
> formats to mean 'unaligned data accesses have ARMv6 behaviour' and the
> operating system should be responsible for emulating the pre-ARMv6
> behaviour of unaligned data accesses for executables which do not have
> this flag set (or rejecting such executables). Unfortunately, people
> are still digging in their heels over the requirement since 16.5 years
> ago for all Absolute files to have valid AIF headers, so that isn't
> likely to happen.

"Indeed"

There's only so many times you can try to say the same thing that was
said years ago, and which was clearly the intention of the original
Acorn developers as shown by the precedent of Service_UKCompression,
the patching APIs, the app notes and the like, before you get bored of
even your own voice. Well I don't get bored of my voice, but that's
just 'cos I'm bitter...

AIF has the ability to flag features, and could be set updated to
handle such things (abort handlers fix-up, UKCompression services,
emulation and even outright rejection as you suggest - there's a bunch
of ways that these things /can/ be dealt with).

Modules have the ability to flag features, and could be updated to
handle such things (similar methods, albeit slightly more complex
because you're having to deal with different modes).

Utilities are the same, although equally fun because they have less
constrained execution.

--
Gerph, bitter and frustrated of Cambridge.

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

#1676

On 29/04/2012 14:37, chrisbazley@bigfoot.com wrote:
> On Apr 19, 1:05 pm, Chris Evans<ch...@cjemicros.co.uk>  wrote:
>> The ideal is that all programs will get updated to ARMv7 but we aren't in an
>> ideal world!
>
> No, the ideal is that RISC OS gets off the treadmill of recompiling
> software for each new ARM architecture. Acorn recognized this was
> unsustainable when they launched the StrongARM and there was still a
> semblance of a viable commercial software market, which is why we have
> the AppPatcher and UnsqueezeAIF mechanism.

It isn't always possible to foresee such developments. Changes to the 
ARM architecture generally require more extensive modification than 
patching a few instructions, or using a new squeeze mechanism; i.e. a 
full recompilation.

> A flag should have been allocated in all of the executable file
> formats to mean 'unaligned data accesses have ARMv6 behaviour' and the
> operating system should be responsible for emulating the pre-ARMv6
> behaviour of unaligned data accesses for executables which do not have
> this flag set (or rejecting such executables). Unfortunately, people
> are still digging in their heels over the requirement since 16.5 years
> ago for all Absolute files to have valid AIF headers, so that isn't
> likely to happen.

The consequence of such an emulator would be that each new generation of 
RISC OS hardware would existing software slower than than the last, 
despite any increase in performance of the new machine. You might as 
well not bother with new ARM hardware and emulate the entire machine on 
Windows or Mac for close to 100% legacy software compatibility.

At least if software doesn't work at all on the new machines, there is 
some impetus for authors to dig out the source and recompile. If it just 
works, but slower, it will probably be left that way.

---druck

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

#1677

On Sun, 29 Apr 2012 06:37:53 -0700 (PDT), chrisbazley@bigfoot.com 
wrote:

> No, the ideal is that RISC OS gets off the treadmill of recompiling
> software for each new ARM architecture.

Really? You know there's a bunch of stuff on my PC that requires 
fairly modern stuff and just won't work on a 486, or a 386, or a 286 
for that matter. As things improve, your product either stays frozen 
in time (with the advantages and disadvantages that entails) or is 
recompiled to take benefit of newer features provided by the system 
and/or the operating system.

Or another way to look at it is to ask how you predict the future? It 
was my personal belief that unaligned word accesses were always going 
to be risky, but there's some changes that would have been harder to 
predict. How can you hope to set a flag for something that hasn't 
happened yet? You can't go and retcon an entire API fifteen years 
down the line because *now* you've run into problems!


> A flag should have been allocated in all of the executable file
> formats to mean 'unaligned data accesses have ARMv6 behaviour'

ARMv5? ARMv7? ARMv8? Etc etc etc.


> and the operating system should be responsible for emulating the
> pre-ARMv6 behaviour of unaligned data accesses for executables
> which do not have this flag set (or rejecting such executables).

Won't work.


Okay, *technically* it will work, but think about it. How do you plan 
to spot an unaligned load? You can't scan the code because a simple 
LDR Rx, [Ry] may be okay, or it may not be. The only way this stands 
a hope of working is to intercept and interrogate *all* memory 
accesses. So on the chance that a program might have a tricky access, 
you're going to pile on the instructions, screw up the caches 
(without altering the executable, you have to find a way to do this 
in-line, like perhaps mark off all memory as inaccessible and pick it 
up on a fault?) and generally perform some awesome magic to make a 
1GHz Beagleboard put in a pretty good impression of my old A3000...


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.


Of course, mentions of stuff like "giving away source code" tends to 
get wailings and gnashings of teeth, so let me put it another way. 
Three questions:
1. How much software is on your machine?
2. How much is important to you?
3. How much is actually still being developed?

Don't bother to reply, it's a rhetorical question...


Best wishes,

Rick.

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

#1678

On 30/04/2012 05:16, Rick Murray wrote:

> Okay, *technically* it will work, but think about it. How do you plan to
> spot an unaligned load? You can't scan the code because a simple LDR Rx,
> [Ry] may be okay, or it may not be. The only way this stands a hope of
> working is to intercept and interrogate *all* memory accesses. So on the
> chance that a program might have a tricky access, you're going to pile
> on the instructions, screw up the caches (without altering the
> executable, you have to find a way to do this in-line, like perhaps mark
> off all memory as inaccessible and pick it up on a fault?) and generally
> perform some awesome magic to make a 1GHz Beagleboard put in a pretty
> good impression of my old A3000...

Exactly. The technique StrongGuard used to make old games work on a 
StrongARM could be used to fix up unaligned data accesses, but with a 
massive speed penalty. It wasn't a problem for StrongGuard as that was 
primarily designed to run ARM2/3 games on a processor which was up to 
20x faster, and had to use other techniques to slow them down to a 
playable speed.

For normal desktop applications, that would cause applications to run 
far slower than an Iyonix, maybe even slower than a Risc PC, so pretty 
pointless, particularly compared to the performance you can get on an 
emulator.

---druck

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

#1679

On Apr 30, 5:16 am, Rick Murray <heyrickmail-use...@yahoo.co.uk>
wrote:
> On Sun, 29 Apr 2012 06:37:53 -0700 (PDT), chrisbaz...@bigfoot.com
> wrote:
>
> > No, the ideal is that RISC OS gets off the treadmill of recompiling
> > software for each new ARM architecture.
>
[snip]
> Or another way to look at it is to ask how you predict the future?

There is no need to predict the future here. A flags word, previously
reserved, would be set. This would
indicate the new feature. Its being unset indicates the old state, and
the new set state indicates that the application/API/whatever
understands a newer state of affairs.

> It
> was my personal belief that unaligned word accesses were always going
> to be risky, but there's some changes that would have been harder to
> predict. How can you hope to set a flag for something that hasn't
> happened yet?

You don't. You set a flag for the change awareness of the new
behaviour.

[snip]

> > and the operating system should be responsible for emulating the
> > pre-ARMv6 behaviour of unaligned data accesses for executables
> > which do not have this flag set (or rejecting such executables).
>
> Won't work.

I like the way you're telling a guy that works at ARM outright what
you can't do.

> Okay, *technically* it will work, but think about it. How do you plan
> to spot an unaligned load?

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.

The use of unaligned operations will be the exception, not the norm,
and so you can trust that the speed won't be too cripplingly hit by
it. Hardware accesses (memory mapped registers and the like) might
take a hit if you're emulating the operations, but really they
shouldn't be doing that kind of thing at all in the first place - and
if you're doing your emulation correctly it won't really matter that
you're a little slower, unless you're bit-banging an API in which
case... find something else to do because that's really wrong on
modern systems.

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 ?

My memory may be faulty, and I might not know the details of the
particular processor, but that's what I think about the issue.

[snip]

> Of course, mentions of stuff like "giving away source code" tends to
> get wailings and gnashings of teeth, so let me put it another way.
> Three questions:
> 1. How much software is on your machine?
> 2. How much is important to you?
> 3. How much is actually still being developed?
>
> Don't bother to reply, it's a rhetorical question...

Uh... It's a question that has no relevance to the issue of handling
alignment issues, surely ?

--
Gerph, who now has colour in his DPU-16 video emulation. Woo.

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

#1683

On Mon, 30 Apr 2012 15:30:42 -0700 (PDT), Gerph <gerph@gerph.org> 
wrote:

> the new set state indicates that the application/API/whatever
> understands a newer state of affairs.

Workable, yes. ;-)


> I like the way you're telling a guy that works at ARM outright what
> you can't do.

It's called being audacious. Or maybe being a prick. Your choice. The 
thing that worries me is that it seems that behaviour of unaligned 
loads seems to change not only depending upon processor family, but 
also upon implementation (if I read the ARM ARM correctly, the memory 
system is as much of an influence as the processor itself?). I fear 
this could lead to a heck of a lot of baggage in sorting out what 
went wrong, what sort of ARM device it is, and then what to do about 
it.


> indicates that you want unaligned loads to abort and you fix them up
> to behave in the manner that the currently active context expects

Indeed, my suggestion was to trap aborts - it is pretty much 
impossible to modify the program (it isn't safe to poke in a branch 
to a special handler on top of LDRs as it may screw up R14, etc), and 
a full blown emulation is silly when it's an ARM pretending to be an 
ARM, why? Why!? So waiting for an abort is the only logical option. 
Though, it is worth asking if different ARMs/MMUs handle things the 
same way if they *don't* abort? It seems we're straying into the 
realms of "implementation defined" here.


> The use of unaligned operations will be the exception, not the norm,
> and so you can trust that the speed won't be too cripplingly hit by

I'm not sure - I recall reading that one of ROOL's compiler mods was 
to provide a command line option to specify if unaligned accesses 
were to be used, or not, and to make not the default.
This implies at one stage the compiler may well have used unaligned. 
For what, to pack structs to remove padding wastage? This is 
speculation, compiled code doesn't read well. ;-) But something must 
have done it at some point to lead to that alteration.


> 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

That's the most logical approach, certainly.


> Uh... It's a question that has no relevance to the issue of handling
> alignment issues, surely ?

Could you have patched up RISC OS to work in a 32 bit world with only 
the binary to work with? It's a lot more involved than simply getting 
rid of the 'S' and '^' (I'll leave you to reply with your favourite 
horror story...). If the sources are available (and, with due 
consideration to getting them to actually build a working product), 
updating a program will become a lot more viable. It might be a 
compiler flag, it might be a newer library, it might be stepping 
through a lot of badly commented assembler. Each case is different.

You know, I think it would be cool to run Zarch on newer hardware. My 
first memory of RISC OS was plugging in my A3000 and firing up 
!Lander. I would be willing to have a crack at making it compatible 
with modern kit. I can imagine it'd be painful, it's from the days 
when it was normal to nuke the caches and RMKill everything in sight. 
But I think it'd be a nice introduction to something like the 
RaspberryPi. It is simple yet rather addictive. But from a binary? No 
thanks!


Best wishes,

Rick.

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

#1684

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

> You know, I think it would be cool to run Zarch on newer hardware. 

That is an inspired suggestion. I am sure nostalgia for Zarch can be
found in many hearts.

-- 
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

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

#1685

On 02/05/2012 18:26, Rick Murray wrote:
> Could you have patched up RISC OS to work in a 32 bit world with only
> the binary to work with? It's a lot more involved than simply getting
> rid of the 'S' and '^' (I'll leave you to reply with your favourite
> horror story...).

I've ported binaries which must be a good fraction of the size of RISC 
OS itself. But 26 bit only code can be found from static analysis, 
unaligned loads can usually only be spotted at run time.

> You know, I think it would be cool to run Zarch on newer hardware. My
> first memory of RISC OS was plugging in my A3000 and firing up !Lander.
> I would be willing to have a crack at making it compatible with modern
> kit. I can imagine it'd be painful, it's from the days when it was
> normal to nuke the caches and RMKill everything in sight. But I think
> it'd be a nice introduction to something like the RaspberryPi. It is
> simple yet rather addictive. But from a binary? No thanks!

Could be done if I wasn't too busy putting the word to rights. Feel free 
to give it a go yourself using !ARMalyser which does half the work for you.

---druck

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

#1686

In message <jns97v$g5i$1@dont-email.me>
          druck <news@druck.org.uk> wrote:

> On 02/05/2012 18:26, Rick Murray wrote:
[snip]

> 
> > You know, I think it would be cool to run Zarch on newer hardware.
> > My first memory of RISC OS was plugging in my A3000 and firing up
> > !Lander. I would be willing to have a crack at making it compatible
> > with modern kit. I can imagine it'd be painful, it's from the days
> > when it was normal to nuke the caches and RMKill everything in
> > sight. But I think it'd be a nice introduction to something like
> > the RaspberryPi. It is simple yet rather addictive. But from a
> > binary? No thanks!
> 
> Could be done if I wasn't too busy putting the word to rights.  Feel
> free  to give it a go yourself using !ARMalyser which does half the
> work for you.

!Lander seems to work ok with the Iyonix - needs slowing down a bit
with a module.

But !Zarch needs to be StrongARMed first - it runs for some time and
then crashes - SA RPC- with or without running in a window.

Presumably uses self modifying code. 

-- 
Colin Ferris Cornwall UK

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

#1687

On Wed, 02 May 2012 23:37:45 +0100, cferris@freeRemoveuk.com.invalid 
wrote:

> But !Zarch needs to be StrongARMed first - it runs for some time and
> then crashes - SA RPC- with or without running in a window.

There must have been a newer one around at some stage. Mine threw 
address exceptions on my A5000 and wasn't any better on the ARM710 
RiscPC. Zarch is a no go for me as not only do I have no idea where 
the disc is, most of them have suffered from dampness (it took 11 
discs before I found one that my Mavica was capable of formatting) so 
I wouldn't hold out hope for it working if I did find it...

<sigh>


Best wishes,

Rick.

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

#1688

On May 2, 11:37 pm, cfer...@freeRemoveuk.com.invalid wrote:
>
> !Lander seems to work ok with the Iyonix - needs slowing down a bit
> with a module.

I didn't know that. How about ARMv6+? If so, then maybe the source
isn't needed:
http://www.raspberrypi.org/forum/general-discussion/demo-scene#p13389

> But !Zarch needs to be StrongARMed first - it runs for some time and
> then crashes - SA RPC- with or without running in a window.
>
> Presumably uses self modifying code.

No takers on that one, either:
http://www.raspberrypi.org/forum/off-topic/port-of-david-braben-virus-on-rasberry-pi

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web