Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ARMv5, ARMv6 & ARMv7 (Programs for the Raspberry Pi)
3,643 views
Skip to first unread message
Chris Evans
Apr 19, 2012, 8:05:32 AM4/19/12
to
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
ch...@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!
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
ch...@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!
Martin Bazley
Apr 19, 2012, 9:15:28 AM4/19/12
to
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 ==========================
> 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?
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 ==========================
Chris Evans
Apr 19, 2012, 11:10:03 AM4/19/12
to
In article <d8a3df82...@blueyonder.co.uk>, Martin Bazley
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 ^
<URL:mailto:martin...@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
> 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!
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 ^
Rick Murray
Apr 19, 2012, 12:32:03 PM4/19/12
to
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.
> What are differences between ARMv5 and ARMv6?
> compared to the differences between ARMv5 and ARMv7
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.
Rick Murray
Apr 19, 2012, 12:41:27 PM4/19/12
to
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
> 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.
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.
Steve Fryatt
Apr 19, 2012, 2:46:08 PM4/19/12
to
On 19 Apr, Chris Evans wrote in message
<ant19150...@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/
<ant19150...@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.
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/
Martin Wuerthner
Apr 19, 2012, 3:24:28 PM4/19/12
to
In message <mpro.m2qpgu01...@stevefryatt.org.uk>
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
---------------------------------------------------------------------
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> On 19 Apr, Chris Evans wrote in message
> <ant19150...@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
> On 19 Apr, Chris Evans wrote in message
> <ant19150...@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.
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
---------------------------------------------------------------------
chris...@bigfoot.com
Apr 29, 2012, 9:37:53 AM4/29/12
to
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
> 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!
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
Martin Bazley
Apr 29, 2012, 10:47:02 AM4/29/12
to
The following bytes were arranged on 29 Apr 2012 by chris...@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
> 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).
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
Gerph
Apr 29, 2012, 10:39:12 AM4/29/12
to
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...
> 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.
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.
druck
Apr 29, 2012, 2:30:40 PM4/29/12
to
On 29/04/2012 14:37, chris...@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
> 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.
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.
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
Rick Murray
Apr 30, 2012, 12:16:50 AM4/30/12
to
On Sun, 29 Apr 2012 06:37:53 -0700 (PDT), chris...@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.
wrote:
> No, the ideal is that RISC OS gets off the treadmill of recompiling
> software for each new ARM architecture.
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'
> 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).
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.
druck
Apr 30, 2012, 5:47:20 PM4/30/12
to
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
> 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...
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
Gerph
Apr 30, 2012, 6:30:42 PM4/30/12
to
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
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.
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]
>
> > No, the ideal is that RISC OS gets off the treadmill of recompiling
> > software for each new ARM architecture.
>
> 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?
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.
you can't do.
> Okay, *technically* it will work, but think about it. How do you plan
> to spot an unaligned load?
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...
alignment issues, surely ?
--
Gerph, who now has colour in his DPU-16 video emulation. Woo.
Theo Markettos
May 1, 2012, 4:33:45 PM5/1/12
to
Rick Murray <heyrickma...@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
> 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.
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
Gerph
May 1, 2012, 8:06:39 PM5/1/12
to
On May 1, 9:33 pm, Theo Markettos <theom+n...@chiark.greenend.org.uk>
wrote:
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.
wrote:
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.
Rick Murray
May 2, 2012, 1:02:37 PM5/2/12
to
On 01 May 2012 21:33:45 +0100 (BST), Theo Markettos
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.
<theom...@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.
> 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.
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.
Rick Murray
May 2, 2012, 1:26:23 PM5/2/12
to
On Mon, 30 Apr 2012 15:30:42 -0700 (PDT), Gerph <ge...@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.
wrote:
> the new set state indicates that the application/API/whatever
> understands a newer state of affairs.
> I like the way you're telling a guy that works at ARM outright what
> you can't do.
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
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
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
> Uh... It's a question that has no relevance to the issue of handling
> alignment issues, surely ?
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.
Gavin Wraith
May 2, 2012, 4:02:55 PM5/2/12
to
In message <almarsoft.5791...@news.orange.fr>
found in many hearts.
--
Gavin Wraith (ga...@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/
Rick Murray <heyrickma...@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
> You know, I think it would be cool to run Zarch on newer hardware.
found in many hearts.
--
Gavin Wraith (ga...@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/
druck
May 2, 2012, 5:33:53 PM5/2/12
to
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
> 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...).
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!
to give it a go yourself using !ARMalyser which does half the work for you.
---druck
cfe...@freeremoveuk.com.invalid
May 2, 2012, 6:37:45 PM5/2/12
to
In message <jns97v$g5i$1...@dont-email.me>
[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
[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.
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
Rick Murray
May 3, 2012, 12:25:22 AM5/3/12
to
On Wed, 02 May 2012 23:37:45 +0100, cfe...@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.
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.
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.
trevj
May 3, 2012, 4:01:27 PM5/3/12
to
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
>
> !Lander seems to work ok with the Iyonix - needs slowing down a bit
> with a module.
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.
http://www.raspberrypi.org/forum/off-topic/port-of-david-braben-virus-on-rasberry-pi
Rick Murray
May 4, 2012, 12:30:22 AM5/4/12
to
On Wed, 02 May 2012 19:26:23 +0200, Rick Murray
<heyrickma...@yahoo.co.uk> wrote:
> Indeed, my suggestion was to trap aborts
To follow up on my reply, having waded through both ARM ARMs and
<heyrickma...@yahoo.co.uk> wrote:
> Indeed, my suggestion was to trap aborts
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.
Martin Wuerthner
May 4, 2012, 5:55:38 AM5/4/12
to
In message <almarsoft.5638...@news.orange.fr>
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.
Rick Murray <heyrickma...@yahoo.co.uk> wrote:
> On Wed, 02 May 2012 19:26:23 +0200, Rick Murray
> <heyrickma...@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
> On Wed, 02 May 2012 19:26:23 +0200, Rick Murray
> <heyrickma...@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?
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.
Simon
May 4, 2012, 7:24:18 AM5/4/12
to
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
> 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.
(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 ?
Matthew Phillips
May 4, 2012, 5:39:30 PM5/4/12
to
In message <4be2868a...@bach.planiverse.com>
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
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
> 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.
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
Rick Murray
May 5, 2012, 11:58:10 AM5/5/12
to
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.
Theo Markettos
May 5, 2012, 12:22:59 PM5/5/12
to
Rick Murray <heyrickma...@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
> 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.
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
0 new messages