Firefox 2 working on the A9Home

2 views
Skip to first unread message

Rob Kendrick

unread,
Dec 3, 2006, 12:27:55 PM12/3/06
to
Hi guys,

I've made The Chox's port of Firefox 2 work on the A9 Home, as can be seen
here:

http://www.rjek.com/ff2-a9home.png

I am asking for 1000 UKP to release this. Not really - I jest you. It's
still a bit grungy - and as you can see, the image rendering isn't all
that fantastic, but it works just fine otherwise.

To try it yourself, you will need to download a fudged copy of the
executable that doesn't check if you're running on an XScale machine:

http://www.rjek.com/ff2-a9home-bin.zip

You will also need my v5Emulator module, which provides emulation for the
XScale-specific instructions that Peter has chosen to use in his port:

http://www.rjek.com/v5emu-001.zip

I provide no guarantee what-so-ever for any of this. If it makes your
computer explode or claim the life if your first born, I am not to blame -
it's been some time since I last wrote the type of low-level ARM code this
hack required!

Have fun,

B.

Rob Kendrick

unread,
Dec 3, 2006, 6:00:36 PM12/3/06
to
On Sun, 03 Dec 2006 17:27:55 +0000, Rob Kendrick wrote:

> It's
> still a bit grungy - and as you can see, the image rendering isn't all
> that fantastic, but it works just fine otherwise.

I've fixed this. http://www.rjek.com/v5emu-002.zip for the updated
version of the emulator.

B.

Chris Evans

unread,
Dec 4, 2006, 7:41:25 AM12/4/06
to
In article <pan.2006.12.03....@rjek.com>, Rob Kendrick

Great work Rob!

We just tried it on the A9home and we do get some rendering corruption.
We downloaded it about three hours ago and it does report as 0.02!

Keep up the good work, it is appreciated.

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!

Rob Kendrick

unread,
Dec 4, 2006, 8:11:44 AM12/4/06
to
On Mon, 04 Dec 2006 12:41:25 +0000, Chris Evans wrote:

> In article <pan.2006.12.03....@rjek.com>, Rob Kendrick
> <URL:mailto:nn...@rjek.com> wrote:
>> On Sun, 03 Dec 2006 17:27:55 +0000, Rob Kendrick wrote:
>>
>> > It's
>> > still a bit grungy - and as you can see, the image rendering isn't all
>> > that fantastic, but it works just fine otherwise.
>>
>> I've fixed this. http://www.rjek.com/v5emu-002.zip for the updated
>> version of the emulator.
>
> Great work Rob!
>
> We just tried it on the A9home and we do get some rendering corruption.
> We downloaded it about three hours ago and it does report as 0.02!

My understanding is that Peter's port incorrectly uses the Tinct module
for plotting images, and as such there may be some image corruption.
Oddly, if you visit the images directly, they're not corrupted, and
they're only damaged if viewed within the context of a page.

An example of this is the "spam" article picture on
http://www.drobe.co.uk/ (on the R-Comp anti-spam article) - FF2 shows some
parts of the background to be black, instead of white. If you visit the
URL of the picture directly, it renders perfectly.

Also, it doesn't appear as if FF2's redrawing images correctly when a WIMP
redraw rectangle doesn't entirely cover the image - it appears to get its
offsets wrong. I do not know if this is my fault or not - somebody with
an Iyonix could confirm either way.

B.

Richard Wilson

unread,
Dec 4, 2006, 3:40:30 PM12/4/06
to
Rob Kendrick wrote:
> On Mon, 04 Dec 2006 12:41:25 +0000, Chris Evans wrote:
>
> > In article <pan.2006.12.03....@rjek.com>, Rob Kendrick
> > <URL:mailto:nn...@rjek.com> wrote:
> >> On Sun, 03 Dec 2006 17:27:55 +0000, Rob Kendrick wrote:
> >>
> >> > It's
> >> > still a bit grungy - and as you can see, the image rendering isn't all
> >> > that fantastic, but it works just fine otherwise.
> >>
> >> I've fixed this. http://www.rjek.com/v5emu-002.zip for the updated
> >> version of the emulator.
> >
> > Great work Rob!
> >
> > We just tried it on the A9home and we do get some rendering corruption.
> > We downloaded it about three hours ago and it does report as 0.02!
>
> My understanding is that Peter's port incorrectly uses the Tinct module
> for plotting images, and as such there may be some image corruption.
> Oddly, if you visit the images directly, they're not corrupted, and
> they're only damaged if viewed within the context of a page.

The image corruption won't be from Tinct calls. There was an issue with
the data being sent, but purely that it wasn't the correct sprite
format and thus the images aren't be plotted.

R.

Rob Kendrick

unread,
Dec 4, 2006, 3:50:24 PM12/4/06
to

> Rob Kendrick wrote:

OK. Do Iyonix users see the same sort of artifacts as on
http://www.rjek.com/ff2-broken.png ?

(ie, the 'spam' drobe image - doesn't render correctly when in a page, but
renders fine when displayed alone.)

B.

Rob Kendrick

unread,
Dec 4, 2006, 4:06:15 PM12/4/06
to
On Mon, 04 Dec 2006 20:50:24 +0000, Rob Kendrick wrote:

> On Mon, 04 Dec 2006 12:40:30 -0800, Richard Wilson wrote:

>> The image corruption won't be from Tinct calls. There was an issue with
>> the data being sent, but purely that it wasn't the correct sprite
>> format and thus the images aren't be plotted.
>
> OK. Do Iyonix users see the same sort of artifacts as on
> http://www.rjek.com/ff2-broken.png ?

I've had this confirmed as a bug that also occurs on the Iyonix, so it's
not my fault. :)

B.

Rob Kendrick

unread,
Dec 4, 2006, 4:20:59 PM12/4/06
to
On Mon, 04 Dec 2006 21:06:15 +0000, Rob Kendrick wrote:

>> OK. Do Iyonix users see the same sort of artifacts as on
>> http://www.rjek.com/ff2-broken.png ?
>
> I've had this confirmed as a bug that also occurs on the Iyonix, so it's
> not my fault. :)

Further research shows that these "black" areas in images only occur in
areas that are transparent. For some reason, Chris decided to make parts
of that Spam image transparent rather than white. (The same effect can be
seen on the thumbnail of FF2 running on the A9 home on the article
mentioning such.)

This looks to be a bug of Peter's in his image plotting.

B.

druck

unread,
Dec 4, 2006, 4:24:46 PM12/4/06
to
On 4 Dec 2006 Rob Kendrick <nn...@rjek.com> wrote:
> On Mon, 04 Dec 2006 12:40:30 -0800, Richard Wilson wrote:
>> The image corruption won't be from Tinct calls. There was an issue with
>> the data being sent, but purely that it wasn't the correct sprite format
>> and thus the images aren't be plotted.
>
> OK. Do Iyonix users see the same sort of artifacts as on
> http://www.rjek.com/ff2-broken.png ?

Yes the corruption in that image is on the current Iyonix version when
rendered in the page but not on its own, exactlt as shown in the A9
screenshot. It also had difficulty with another drobe image in the pre-view
version I had last week, dragging another window over it repeatedly resulted
in a crash on that one.

Incidentally I much prefred the pre-view version I had first, it had an
iconbar icon and RISC OS menus. I wish I'd kepted it now, rather than
overwriting with the released version.

---druck

--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/

Rob Kendrick

unread,
Dec 6, 2006, 9:17:54 AM12/6/06
to
On Sun, 03 Dec 2006 17:27:55 +0000, Rob Kendrick wrote:


> You will also need my v5Emulator module, which provides emulation for the
> XScale-specific instructions that Peter has chosen to use in his port:
>
> http://www.rjek.com/v5emu-001.zip

New version available! http://www.rjek.com/v5emu-003.zip includes
optimisations and bug fixes - it's quite a bit faster now.

I did some maths to investigate why Peter might have chosen to use XScale
instructions in his Firefox 2 port. I instrumented my emulator such that
I could count the number of times FF2 used these instructions. My test
was loading FF2, and then navigating to http://news.bbc.co.uk/, scrolling
the page to the bottom, and then scrolling to the top again.

CLZ instructions used: 2500
SMULxx instructions used: 109396

Now, using CLZ saves you about 10 instructions. So he's saved 25000 there.
SMULxx saves you /at most/ around 4 instructions - often less. So he
saves another 437584 instructions there if every case was the worst case.
That's a total of 462584 cycles he's saved by making the binary
Iyonix-only.

It would take the Iyonix less than a thousandth of a second to execute
those 462584 instructions, and an A9 Home not noticeably longer. Hardly a
worth-while optimisation.

I've not spotted Peter saying anywhere why his port was Firefox 2 was
only going to be Iyonix-compatible either, so we're left guessing about
his reasons. It certainly isn't for performance issues, or API reasons,
as my emulator module shows.

As for RiscPC users - I've had many ask if this patch will work for them.
Alas, not. The StrongARM, for example, does implement the LDRH and STRH
instructions that Firefox 2 uses. But the RiscPC's IOMD does not support
them, and just return nonsense, unless the data it's trying to read is
already in the cache (or on the on-board RAM in the case of the Kinetic).
Unfortunately there is no way to intercept those instructions and emulate
them, so it would involve a recompile of Firefox 2.

I'm told that LDRH/STRH work just fine on the Omega though, so there's a
slight possibility that this patch may work there. I have no idea, and
cannot test this myself.

B.

Steve Potts

unread,
Dec 7, 2006, 1:54:15 PM12/7/06
to
In message <pan.2006.12.06....@rjek.com>
Rob Kendrick <nn...@rjek.com> wrote:

> On Sun, 03 Dec 2006 17:27:55 +0000, Rob Kendrick wrote:
>
>
> > You will also need my v5Emulator module, which provides emulation for the
> > XScale-specific instructions that Peter has chosen to use in his port:
> >
> > http://www.rjek.com/v5emu-001.zip
>
> New version available! http://www.rjek.com/v5emu-003.zip includes
> optimisations and bug fixes - it's quite a bit faster now.

Excellent and much appreciated.

[snip]

> I've not spotted Peter saying anywhere why his port was Firefox 2 was
> only going to be Iyonix-compatible either, so we're left guessing about
> his reasons. It certainly isn't for performance issues, or API reasons,
> as my emulator module shows.

I guess it's money then.

[snip]


--
StevePotts at blastzone DOT demon STOP co DOT uk (www.blastzone.demon.co.uk/)
Written on RISC OS.
http://www.riscos.com/

--
Posted via a free Usenet account from http://www.teranews.com

John Williams (News)

unread,
Dec 7, 2006, 2:15:44 PM12/7/06
to
In article <1a38a091...@blastzone.demon.co.uk>,
Steve Potts <nos...@all.invaliid> wrote:

> > I've not spotted Peter saying anywhere why his port was Firefox 2 was
> > only going to be Iyonix-compatible either, so we're left guessing about
> > his reasons. It certainly isn't for performance issues, or API reasons,
> > as my emulator module shows.

> I guess it's money then.

I think that may be a little unfair - and possibly counter-productive!

Of course Peter needs some recompense, but sniping (as opposed to snipping)
isn't going to help, particularly at this stage!

If Peter takes his ball home because of your comments, I'll be upset!

John

--
John Williams, Wirral, Merseyside, UK - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject
for reliable contact! Who is John Williams? http://www.picindex.info/author/

Steve Potts

unread,
Dec 7, 2006, 2:24:14 PM12/7/06
to
In message <4e91a149...@tiscali.co.uk>

"John Williams (News)" <UCE...@tiscali.co.uk> wrote:

> In article <1a38a091...@blastzone.demon.co.uk>,
> Steve Potts <nos...@all.invaliid> wrote:
>
> > > I've not spotted Peter saying anywhere why his port was Firefox 2 was
> > > only going to be Iyonix-compatible either, so we're left guessing about
> > > his reasons. It certainly isn't for performance issues, or API
> > > reasons, as my emulator module shows.
>
> > I guess it's money then.
>
> I think that may be a little unfair - and possibly counter-productive!

How is that unfair, it was not intended to be anything other than
speculation? Surely others were thinking it.

> Of course Peter needs some recompense, but sniping (as opposed to snipping)
> isn't going to help, particularly at this stage!

Peter has made no statements as to why it is Iyonix only, despite
apparently being asked. Therefore others are speculating. It's no different
to any other speculation within the RISC OS market.

I don't dispute that Peter has done some excellent stuff and needs some
recompense. I'm not intending to start arguing about anything.

> If Peter takes his ball home because of your comments, I'll be upset!

I made a single statement - and purely speculation at that, not several
comments.

If Peter did that, it would be pretty childish - particularly given the abuse
he frequently dishes out. I'm sure he's better than that.

> John
>

Steve.

Dr Peter Young

unread,
Dec 8, 2006, 3:21:56 AM12/8/06
to
On 7 Dec 2006 Steve Potts <nos...@all.invaliid> wrote:

[snip]

> Peter has made no statements as to why it is Iyonix only, despite
> apparently being asked. Therefore others are speculating. It's no different
> to any other speculation within the RISC OS market.

Someone somewhere wrote that it's Iyo only because /in order to speed
it up to a reasonable speed/ (1) it uses code which only runs on the
Iyo. I'm sure someone with better technical than I have, and a better
memory, will be able to amplify this statement.

(1) It's certainly done that, with thanks to Mr Naulls.

With best wishes,

Peter.

--
Peter \ / \ Prestbury, Cheltenham, Glos. GL52
Anne \ / __ __ \ England.
and / / \ | | |\ | / _ \ http://pnyoung.orpheusweb.co.uk
family / \__/ \_/ | \| \__/ \______________ pny...@ormail.co.uk.

Alan Calder

unread,
Dec 8, 2006, 3:40:38 AM12/8/06
to
In article <432aea914...@pnyoung.ormail.co.uk>, Dr Peter Young

<pny...@ormail.co.uk> wrote:
> On 7 Dec 2006 Steve Potts <nos...@all.invaliid> wrote:

> [snip]

> > Peter has made no statements as to why it is Iyonix only, despite
> > apparently being asked. Therefore others are speculating. It's no
> > different to any other speculation within the RISC OS market.

> Someone somewhere wrote that it's Iyo only because /in order to speed
> it up to a reasonable speed/ (1) it uses code which only runs on the
> Iyo. I'm sure someone with better technical than I have, and a better
> memory, will be able to amplify this statement.

No better technically, probably much less so, but maybe a better memory!

Drobe has something http://www.drobe.co.uk/riscos/artifact1747.html which
throws some light possibly. Relevant bits are:

> However, following discussions on the GCCSDK list, we believe Peter has
> configured GCC to produce code that uses ARMv5 instructions when
> building the Firefox 2 port. This machine code can be executed by the
> Iyonix's Intel XScale IOP321 processor, but not the RiscPC's StrongARM
> and the A9home's Samsung ARM9 chips. The ARMv5 instructions could
> squeeze extra performance out of the mammoth web browser

> Well FireFox2 does contain a number of ARMv5 instructions which rules
> out it running on a RiscPC. Incdicentally ARMalayser required a 200MB
> wimpslot to analyse the 20MB firefox2 binary, and produced 340MB of
> dissassembly. (Druck)

Cheers

Alan

[Snip]

--
Alan Calder, Milton Keynes, UK.

charles

unread,
Dec 8, 2006, 3:52:47 AM12/8/06
to
In article <4e91ebe0ab...@orpheusmail.co.uk>,
Alan Calder <alan_...@orpheusmail.co.uk> wrote:

[Snip]

> > Well FireFox2 does contain a number of ARMv5 instructions which rules
> > out it running on a RiscPC. Incdicentally ARMalayser required a 200MB
> > wimpslot to analyse the 20MB firefox2 binary, and produced 340MB of
> > dissassembly. (Druck)

So perhaps the 512MB I have in my Iyonix isn't really enough :-(

--
From KT24 - in "Leafy Surrey"

Using a RISC OS computer running v5.11

Paul C Robinson

unread,
Dec 8, 2006, 4:31:48 AM12/8/06
to
In article <fcf6a291...@blastzone.demon.co.uk>, Steve Potts

<URL:mailto:nos...@all.invaliid> wrote:
> In message <4e91a149...@tiscali.co.uk>
> "John Williams (News)" <UCE...@tiscali.co.uk> wrote:
>
> > In article <1a38a091...@blastzone.demon.co.uk>,
> > Steve Potts <nos...@all.invaliid> wrote:
> >
> > > > I've not spotted Peter saying anywhere why his port was Firefox 2 was
> > > > only going to be Iyonix-compatible either, so we're left guessing about
> > > > his reasons. It certainly isn't for performance issues, or API
> > > > reasons, as my emulator module shows.
> >
> > > I guess it's money then.
> >
> > I think that may be a little unfair - and possibly counter-productive!
>
> How is that unfair, it was not intended to be anything other than
> speculation? Surely others were thinking it.
Snip to end.

I have, but I have been looking at it from another angle.
I now have 6 RISC OS Browsers loaded on my system.
!Fresco !Oregano !Origano2 !WebsterXL !NetSurf and !Firefox
Yet I still end up using wintel browsers.

I have paid my money supporting RISC OS but to no end. So it is time for me
to be realistic.
So unless Firefox2 is working as I expect a browser to work then I am
sorry to say my hands will stay in my pocket. If this ultimatly means no
full on browser on a RISC OS system then sooner or later all my
RISC OS systems will be recycled and BG wins again 8-(

Personally if the next version of RISC OS released included every thing
we have come to expect from a wintel system I would buy a new complete
RISC OS system even though a have a loft full of Risc PC's

PS I do have RISC OS Adjust.


--
Paul C.Robinson. Born to be a rebel.
Loves Ice Hockey, my Yamaha XJR1300 and RISC OS computer systems.
Speaking for me myself and I when you see this sig. #8-)
Alternative communication Tel:- (+44) 1708 852225 Fax:- (+44) 8700568378

Message has been deleted

charles

unread,
Dec 8, 2006, 5:02:24 AM12/8/06
to
In article <ant08082...@pr006f6094.blueyonder.co.uk>,
Paul C Robinson <Pa...@havaccnt.demon.co.uk> wrote:
>

[Snip]

> So unless Firefox2 is working as I expect a browser to work then I am
> sorry to say my hands will stay in my pocket. If this ultimatly means no
> full on browser on a RISC OS system then sooner or later all my
> RISC OS systems will be recycled and BG wins again 8-(

> Personally if the next version of RISC OS released included every thing
> we have come to expect from a wintel system I would buy a new complete
> RISC OS system even though a have a loft full of Risc PC's

> PS I do have RISC OS Adjust.

You've said it all. Using a 10 yo computer - albeit with more modern
operating system - will not give you what you want/need. FF2 on the
Iyonix, OTH, now provides a viable alternative to O2 altough I suspect I
may need to upgrade to !GB memeory - something that would not be possibleon
the RISC PC.

Martin Hodgson

unread,
Dec 8, 2006, 5:47:38 AM12/8/06
to
In article <fcf6a291...@blastzone.demon.co.uk>,

Steve Potts <nos...@all.invaliid> wrote:
> In message <4e91a149...@tiscali.co.uk>
> "John Williams (News)" <UCE...@tiscali.co.uk> wrote:

> > In article <1a38a091...@blastzone.demon.co.uk>,
> > Steve Potts <nos...@all.invaliid> wrote:
> >
> > > > I've not spotted Peter saying anywhere why his port was Firefox 2 was
> > > > only going to be Iyonix-compatible either, so we're left guessing about
> > > > his reasons. It certainly isn't for performance issues, or API
> > > > reasons, as my emulator module shows.
> >
> > > I guess it's money then.
> >
> > I think that may be a little unfair - and possibly counter-productive!

> How is that unfair, it was not intended to be anything other than
> speculation? Surely others were thinking it.

Words are slippery things. We hear or read them, then we /all/
interpretate them according to our situation, mood at the time,
background, etc.

The written word is especially difficult since we lack visual indications
from the writer.

Hence the negative response to your innocent speculation.

And a lot of the nonsense that goes on around here.

My first rule of communications: if a piece is written so there is only
one way to read it, then if two people read it they will have two
different understandings of your words.
Second rule: if either interpretation corresponds to what you meant, that's
a bonus.

Martin Hodgson

Rob Kendrick

unread,
Dec 8, 2006, 7:08:14 AM12/8/06
to
On Fri, 08 Dec 2006 08:21:56 +0000, Dr Peter Young wrote:

> On 7 Dec 2006 Steve Potts <nos...@all.invaliid> wrote:
>
> [snip]
>
>> Peter has made no statements as to why it is Iyonix only, despite
>> apparently being asked. Therefore others are speculating. It's no different
>> to any other speculation within the RISC OS market.
>
> Someone somewhere wrote that it's Iyo only because /in order to speed
> it up to a reasonable speed/ (1) it uses code which only runs on the
> Iyo. I'm sure someone with better technical than I have, and a better
> memory, will be able to amplify this statement.

Alas, this argumenet is nonsense, as I said in my earlier post. The use
of XScale-only instructions saves about a thousandth of second. Not
something you're going notice.

B.

Alan Calder

unread,
Dec 8, 2006, 7:17:56 AM12/8/06
to
In article <pan.2006.12.08....@rjek.com>, Rob Kendrick

I'm sure you are correct but all the same your earlier post
<pan.2006.12.06....@rjek.com>
does seem to indicate that FF2 uses instructions that don't work on the
RPC. I know that you have sorted things for the A9Home but that still
leaves RPC owners out in the cold - though the memory needs might rule it
out anyway.

Cheers

Alan

> B.

Rob Kendrick

unread,
Dec 8, 2006, 7:29:13 AM12/8/06
to
On Fri, 08 Dec 2006 12:17:56 +0000, Alan Calder wrote:

>> Alas, this argumenet is nonsense, as I said in my earlier post. The use
>> of XScale-only instructions saves about a thousandth of second. Not
>> something you're going notice.
>
> I'm sure you are correct but all the same your earlier post
> <pan.2006.12.06....@rjek.com>
> does seem to indicate that FF2 uses instructions that don't work on the
> RPC. I know that you have sorted things for the A9Home but that still
> leaves RPC owners out in the cold - though the memory needs might rule it
> out anyway.

I suspect dodgy snipping and attribution here - I don't believe I said the
above. But either way, it may be true. Certainly, there's no tangible
advantage at all for end-users to have FF2 use XScale-only instructions,
which is what I said. Memory may be an issue. On the A9 I have here, I
can have six tabs open in FF2 (my home page, news.bbc, slashdot, the
register, freshmeat, drobe) and I still had over 60MB of free memory.

The RISC OS on the A9 Home has very sophisticated DA support, including
sparse DAs, and features that make it much easier to implement swap.
Firefox and Mozilla are notorious for allocating memory they then never
use or touch - sparse DAs may be the answer here to free up more memory.
(Linux and Windows do this by not actually allocating memory until
a process tries to write to it - malloc() always succeeds.)
Firefox often also allocates memory that it rarely uses, so swap might be
useful here.

B.

charles

unread,
Dec 8, 2006, 7:57:57 AM12/8/06
to
In article <4e91ffc592...@orpheusmail.co.uk>,

Alan Calder <alan_...@orpheusmail.co.uk> wrote:
>
> I'm sure you are correct but all the same your earlier post
> <pan.2006.12.06....@rjek.com>
> does seem to indicate that FF2 uses instructions that don't work on the
> RPC. I know that you have sorted things for the A9Home but that still
> leaves RPC owners out in the cold - though the memory needs might rule it
> out anyway.

Might? I would have thought that 340 MB of memory for the application alone does rule it out ;-(

Theo Markettos

unread,
Dec 8, 2006, 8:38:16 AM12/8/06
to
Rob Kendrick <nn...@rjek.com> wrote:
> I suspect dodgy snipping and attribution here - I don't believe I said the
> above. But either way, it may be true. Certainly, there's no tangible
> advantage at all for end-users to have FF2 use XScale-only instructions,

Do you know how many LDRH/STRH instructions there are and their impact on
performance? I suspect that might be a more significant speedup than CLZ
and SMULL.

It may be that Peter hasn't done the profiling work you have (having an
emulation module makes it much easier) and building Iyonix compatible was
simply because he doesn't have an A9 to test with. But given this knowledge
it's possible to release an ARM v4 (or whatever) version and saying 'not
supported on A9'.

Theo

Message has been deleted

Rob Kendrick

unread,
Dec 8, 2006, 9:00:04 AM12/8/06
to
On Fri, 08 Dec 2006 13:38:16 +0000, Theo Markettos wrote:

> Rob Kendrick <nn...@rjek.com> wrote:
>> I suspect dodgy snipping and attribution here - I don't believe I said the
>> above. But either way, it may be true. Certainly, there's no tangible
>> advantage at all for end-users to have FF2 use XScale-only instructions,
>
> Do you know how many LDRH/STRH instructions there are and their impact on
> performance? I suspect that might be a more significant speedup than CLZ
> and SMULL.

Perhaps so, but they're not XScale-only instructions. The A9, Omega and
Kinetic RiscPCs (most of the time) can execute LDRH/STRH just fine.

> It may be that Peter hasn't done the profiling work you have (having an
> emulation module makes it much easier) and building Iyonix compatible was
> simply because he doesn't have an A9 to test with. But given this knowledge
> it's possible to release an ARM v4 (or whatever) version and saying 'not
> supported on A9'.

StrongARM and ARM9 are both ARMv4. ARM11 and XScale are ARMv5. But
otherwise, perhaps. Although I'm sure Peter could have seen that there
was no noticeable improvement using -march=armv5 over -march=armv4. He's
not a Gentoo user, after all :) (At least, he wasn't the last I knew.)

B.

Rob Kendrick

unread,
Dec 8, 2006, 9:02:17 AM12/8/06
to
On Fri, 08 Dec 2006 12:57:57 +0000, charles wrote:

> In article <4e91ffc592...@orpheusmail.co.uk>,
> Alan Calder <alan_...@orpheusmail.co.uk> wrote:
>>
>> I'm sure you are correct but all the same your earlier post
>> <pan.2006.12.06....@rjek.com>
>> does seem to indicate that FF2 uses instructions that don't work on the
>> RPC. I know that you have sorted things for the A9Home but that still
>> leaves RPC owners out in the cold - though the memory needs might rule it
>> out anyway.
>
> Might? I would have thought that 340 MB of memory for the application
> alone does rule it out ;-(

Firefox doesn't use anywhere near this much unless you have dozens of
pages open. Its WIMP slot is 20MB, and it allocates memory in dynamic
areas, but hardly ever this much.

You may be confused by the amount of memory reported as in use by Firefox
under UNIX and Windows - these numbers are misleading, as they can be
anything from the "VM" size to including all the the libraries it links
to, and as such can't be used to compare against how much the same app
would consume under RISC OS.

B.

charles

unread,
Dec 8, 2006, 9:01:53 AM12/8/06
to
In article <4e920753d1inval...@invalid-domain.co.uk>,
Paul Vigay <invalid-em...@invalid-domain.co.uk> wrote:
> In article <4e92036f...@charleshope.demon.co.uk>,
> charles <cha...@charleshope.demon.co.uk> wrote:

> > Might? I would have thought that 340 MB of memory for the application
> > alone does rule it out ;-(

> Eh? Who said it needs 340MB of memory? It only requires 20MB on the
> Iyonix, so there should be oodles of memory left,

A post earlier today, which I deleted from my Bin said the 20MB unpacked to
340MB. Did I misundrstand what was written?

John Williams (News)

unread,
Dec 8, 2006, 9:22:53 AM12/8/06
to
In article <4e920949...@charleshope.demon.co.uk>, charles
<cha...@charleshope.demon.co.uk> wrote:

> A post earlier today, which I deleted from my Bin said the 20MB unpacked
> to 340MB. Did I misundrstand what was written?

That was a post referring to the Armalyser output quoting a Drobe article,
so you did misunderstand it.

The original article is at:

http://www.drobe.co.uk/riscos/artifact1747.html

Message has been deleted

charles

unread,
Dec 8, 2006, 9:34:19 AM12/8/06
to
In article <4e920b44ccinval...@invalid-domain.co.uk>,

> > A post earlier today, which I deleted from my Bin said the 20MB unpacked
> > to 340MB. Did I misundrstand what was written?

> Yes. I think that was druck's comment about how much space it would
> require to disassemble the code and examine the source code.

Tyhank you.

Chris Joseph

unread,
Dec 8, 2006, 10:17:18 AM12/8/06
to
charles <cha...@charleshope.demon.co.uk> wrote:

> Paul Vigay <invalid-em...@invalid-domain.co.uk> wrote:
>> charles <cha...@charleshope.demon.co.uk> wrote:
>
>> > Might? I would have thought that 340 MB of memory for the application
>> > alone does rule it out ;-(
>
>> Eh? Who said it needs 340MB of memory? It only requires 20MB on the
>> Iyonix, so there should be oodles of memory left,
>
>A post earlier today, which I deleted from my Bin said the 20MB unpacked to
>340MB. Did I misundrstand what was written?

Yes :) That was the space required to take the binary apart for analysis
by ARMalyser, rather than the space required to run it....

Chris.

george

unread,
Dec 8, 2006, 10:50:42 AM12/8/06
to
In message <4e91ffc592...@orpheusmail.co.uk>
Alan Calder <alan_...@orpheusmail.co.uk> wrote:

> In article <pan.2006.12.08....@rjek.com>, Rob Kendrick
> <nn...@rjek.com> wrote:
>> On Fri, 08 Dec 2006 08:21:56 +0000, Dr Peter Young wrote:
>
>> > On 7 Dec 2006 Steve Potts <nos...@all.invaliid> wrote:

[snip]

>

> I'm sure you are correct but all the same your earlier post
> <pan.2006.12.06....@rjek.com>
> does seem to indicate that FF2 uses instructions that don't work on the
> RPC. I know that you have sorted things for the A9Home but that still
> leaves RPC owners out in the cold - though the memory needs might rule it
> out anyway.
>

I should think the main problem with the RPC would be processing
power: I used FFbeta3 on a Kinetic RPC and the Iyonix which replaced
it was twice as fast using the same version. Bearing in mind the
Kinetic is between 50-100% faster than a vanilla S/ARM RPC, using FF
on a RPC, even given the latest speed ups, would be a pretty
pedestrian experience.

George

--

Steven Pampling

unread,
Dec 8, 2006, 1:45:26 PM12/8/06
to
In article <432aea914...@pnyoung.ormail.co.uk>,
Dr Peter Young <pny...@ormail.co.uk> wrote:
> On 7 Dec 2006 Steve Potts <nos...@all.invaliid> wrote:

> [snip]

> > Peter has made no statements as to why it is Iyonix only, despite
> > apparently being asked. Therefore others are speculating. It's no different
> > to any other speculation within the RISC OS market.

> Someone somewhere wrote that it's Iyo only because /in order to speed
> it up to a reasonable speed/ (1) it uses code which only runs on the
> Iyo.

I think that was me, and it wasn't a statement, just speculation based on
Peter having chosen to use certain XScale only instructions.

People ought to treat it as a hint to upgrade their machine to something
newer...

--

Steve Pampling

Rob Kendrick

unread,
Dec 8, 2006, 1:55:07 PM12/8/06
to
On Fri, 08 Dec 2006 18:45:26 +0000, Steven Pampling wrote:

>> Someone somewhere wrote that it's Iyo only because /in order to speed
>> it up to a reasonable speed/ (1) it uses code which only runs on the
>> Iyo.
>
> I think that was me, and it wasn't a statement, just speculation based on
> Peter having chosen to use certain XScale only instructions.
>
> People ought to treat it as a hint to upgrade their machine to something
> newer...

Like, say, an A9 Home? :)

B.

Steven Pampling

unread,
Dec 8, 2006, 7:12:47 PM12/8/06
to
In article <pan.2006.12.08....@rjek.com>, Rob Kendrick
<nn...@rjek.com> wrote:

Preferably an Iyonix if they want to run FF2...

(Or technically speaking anything anyone wants to run on a non-beta OS.)

--

Steve Pampling

Rob Kendrick

unread,
Dec 8, 2006, 8:47:09 PM12/8/06
to
On Sat, 09 Dec 2006 00:12:47 +0000, Steven Pampling wrote:

> In article <pan.2006.12.08....@rjek.com>, Rob Kendrick
> <nn...@rjek.com> wrote:
>> On Fri, 08 Dec 2006 18:45:26 +0000, Steven Pampling wrote:
>
>> >> Someone somewhere wrote that it's Iyo only because /in order to speed
>> >> it up to a reasonable speed/ (1) it uses code which only runs on the
>> >> Iyo.
>
>> > I think that was me, and it wasn't a statement, just speculation based
>> > on Peter having chosen to use certain XScale only instructions.
>
>> > People ought to treat it as a hint to upgrade their machine to
>> > something newer...
>
>> Like, say, an A9 Home? :)
>
> Preferably an Iyonix if they want to run FF2...

I'm still not convinced that Firefox 2 is significantly faster on the
Iyonix than it is on the A9 Home.

> (Or technically speaking anything anyone wants to run on a non-beta OS.)

Most users wouldn't notice, IMO.

B.

druck

unread,
Dec 9, 2006, 6:41:47 AM12/9/06
to
On 8 Dec 2006 Paul Vigay <invalid-em...@invalid-domain.co.uk> wrote:
> In article <4e920949...@charleshope.demon.co.uk>,
> charles <cha...@charleshope.demon.co.uk> wrote:
>
> > A post earlier today, which I deleted from my Bin said the 20MB unpacked
> > to 340MB. Did I misundrstand what was written?
>
> Yes. I think that was druck's comment about how much space it would require
> to disassemble the code and examine the source code.

Yes, each 4 byte instruction can produce up to 100 characters of output in
dissassembly mode with comments.

---druck

--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/

druck

unread,
Dec 9, 2006, 6:36:59 AM12/9/06
to
On 8 Dec 2006 charles <cha...@charleshope.demon.co.uk> wrote:
> In article <4e91ebe0ab...@orpheusmail.co.uk>,
> Alan Calder <alan_...@orpheusmail.co.uk> wrote:
>
> [Snip]
>
> > > Well FireFox2 does contain a number of ARMv5 instructions which rules
> > > out it running on a RiscPC. Incdicentally ARMalayser required a 200MB
> > > wimpslot to analyse the 20MB firefox2 binary, and produced 340MB of
> > > dissassembly. (Druck)
>
> So perhaps the 512MB I have in my Iyonix isn't really enough :-(

Its enough for mine.

BTW: if anyone else wants to run ARMalyser on Firefox 2, then select
dissassembly output as its much quicker. A bit of inefficent code in
assembly output means multi megabyte executables take a very long time.
I've just fixed this, and the next release is almost ready to go out.

druck

unread,
Dec 9, 2006, 6:39:58 AM12/9/06
to
On 8 Dec 2006 Rob Kendrick <nn...@rjek.com> wrote:
> On Fri, 08 Dec 2006 13:38:16 +0000, Theo Markettos wrote:
>> Rob Kendrick <nn...@rjek.com> wrote:
>>> I suspect dodgy snipping and attribution here - I don't believe I said
>>> the above. But either way, it may be true. Certainly, there's no
>>> tangible advantage at all for end-users to have FF2 use XScale-only
>>> instructions,
>>
>> Do you know how many LDRH/STRH instructions there are and their impact on
>> performance? I suspect that might be a more significant speedup than CLZ
>> and SMULL.
>
> Perhaps so, but they're not XScale-only instructions. The A9, Omega and
> Kinetic RiscPCs (most of the time) can execute LDRH/STRH just fine.

You can't use LDRH/STRH on any Risc PC, there is no guarentee even on a
Kinetic that a page will be from the local memory. I don't have any
information in whether an Omega's memory control ASIC works with the 16
bit instructions, has anyone tested it?

Rob Kendrick

unread,
Dec 9, 2006, 8:03:36 AM12/9/06
to
On Sat, 09 Dec 2006 11:39:58 +0000, druck wrote:

>> Perhaps so, but they're not XScale-only instructions. The A9, Omega and
>> Kinetic RiscPCs (most of the time) can execute LDRH/STRH just fine.
>
> You can't use LDRH/STRH on any Risc PC, there is no guarentee even on a
> Kinetic that a page will be from the local memory. I don't have any
> information in whether an Omega's memory control ASIC works with the 16
> bit instructions, has anyone tested it?

I havn't, but at least two people have independently confirmed that you
can use them safely.

B.

Reply all
Reply to author
Forward
0 new messages