Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

Future ARM based processors for RISC OS?

By Chris Williams. Published: 25th Jul 2003, 21:13:26 | Permalink | Printable

From ARM7 to ARM11 and XScale, our stocking wishlist

Editorial OS owners Castle recently stated that their 32 bit, HAL abstracted RISC OS 5 can be used in devices powered by ARM9, ARM10, ARM11 and XScale processors. This fact was pretty much obvious when Castle first revealed details of its 32 bit OS however it's worth looking at what's on offer in terms of ARM based processors.

Strongarm processorRemember that these days ARM designs processor 'cores' which are the inner fundamental components inside processor chips. Usually, third party companies and manufacturers then license the rights to take these core designs and put them in custom designed chips to form a full processor. This means a company could take an ARM9 core and package it up in a chip that features LCD and wireless support circuitry to make a processor designed ideally for small portable devices.

So, it's therefore unusual to pick up a chip now with just an ARM processor core in it, like the processors in the ARM610, ARM710 and StrongARM daughter cards for RiscPCs. However, it does mean that ARM based processor chips contain built in useful functionality.

Processor cores suitable for RISC OS:

ARM 7 family [details]
We're all pretty much familiar with cores from this family, as seen in the ARM710 processor chip and the Cirrus PS7500FE. Cirrus offer other processors powered by the ARM 7 family including three chips aimed at portable products that use the ARM720T core. The ARM720T is a good modern core designed for embedded and low power products, like MP3 players and digital cameras. The core clock speed can run up to 100MHz.

ARM 9 family [details]
arm920T based processorWe're now entering the territory of intelligent consumer based eletronics where Symbian OS, Palm OS, Linux and Windows CE roam. The ARM920T core can be used in products such as next generation mobile phones, PDAs and set top boxes and ARM suggest clock frequencies of up to 200MHz. Earlier this week, Samsung boasted an ARM920T based processor, clocked at 533MHz. Their S3C2440 chip, which features the ARM 920T core, is touted as "the world's fastest mobile CPU" and includes built in support for LCD displays, interface for a touch screen and support for USB.

ARM 10 family [details]
The ARM 10 family is aimed at digital consumer projects and also industrial control systems. While the ARM1020E core is a 32 bit processor with 16 bit Thumb support, a 64 bit internal bus and digital signal processing (DSP) extensions. It also has a clock frequency of 325MHz. We're not aware of any high profile use of this core although last year, Samsung spoke of using an ARM 10 core in a 400-600MHz processor for PDAs. Samsung also said last year they had an ARM core capable of running at 1.2GHz. The 1GHz barrier breaking ARM1020E compatible core, nicknamed Halla, was said to be ready for sampling by Q3 of 2003.

ARM 11 family [details]
The ARM 11 family is really pushing into specialised areas. This family of cores focuses on applications where memory is a premium and there is a need for high performance, real time processing with low power consumption. This means wireless, sub-notebook computers and networking devices. ARM offer clock frequencies up to 400MHz for this family. We're not aware of any ARM 11 cores being widely available, however around this time last year, the EE Times reported that ARM wanted to control the release of their ARM11 based cores.

Intel XScale [details]
Iyonix XScale processorThe XScale core is currently overseen and packaged into integrated chips by Intel as a result of Intel buying DEC and thus the StrongARM design that ARM and DEC created. The XScale was once upon a time dubbed the 'StrongARM 2' and current cores are ARM architecture and code compliant. The XScale core can be found in numerous flavours of processor chips that are highly integrated with additional features to suit the markets Intel are aiming at. Firstly, there's the PXA26x family of chips designed for wireless products and mobile phones - by now you've probably started seeing a trend in the suggested applications of these ARM based chips. The PXA26x family offers clock frequencies of 200-400MHz and supports storage cards (such as CompactFlash), USB and the Bluetooth wireless standard. The PXA255 processor also runs between 200 and 400Mhz and also supports PCMCIA, other storage card media, USB and Bluetooth wireless.

Next, we move onto the familiar XScale I/O processor family. The IOP321, as used in the Castle Iyonix, runs at 600MHz and provides PCI interface and DDR SDRAM support. The 733Mhz IOP310 is a two chip chipset but is slower than the IOP321 in terms of PCI bus speed and DDR SDRAM access speed. The IOP200 is unlike the other ARM based processors we've seen here as it's a straight ARM compatible processor with no special integrated abilities. It can have a clock frequency as high as 733MHz. You can read a run down of what the XScale IOP321 brings to RISC OS here.

Will we see ARM processors breaking the golden 1GHz barrier? We have to consider that ARM processors are going into mobile gadgets where power usage is critical or into devices that don't need to go beyond 1GHz. However, this may one day all change.

"Desktops today are (consuming power of) 75 to 100 watts and when you go to handheld devices you are typically operating at less than 1 watt," said Pat Gelsinger, Intel's chief technology officer speaking at the Intel Developer Forum in Japan last October. "Obviously, you are optimizing the design for different criteria. So today, if I was going to look at a StrongArm core or XScale core, could I create a 2GHz or 3GHz XScale today? Absolutely. Could I do so and deliver the best trade-off of power and performance inside a 1-watt envelope? No. You tend to design the chips differently to live inside different devices."

Summary
The bottom line is RISC OS can be employed on any available processor that features an ARM7 to ARM11 or XScale core and a suitable memory management unit (MMU). A processor's MMU provides flexible manipulation and control over the memory and memory mapped hardware in a device.

With these new processor cores unlocked, the leaping of RISC OS from the Iyonix to existing ARM based PDAs and similiar gadgets will rely on the availability of drivers for the proprietry PDA hardware. The HAL in RISC OS 5 enables the OS developers to adapt RISC OS to vital systems like hardware timers, clocks, interrupts and interfaces provided by new chipsets. With this and 32 bit compatibility out of the way, it's now largely down to the substantial work required to produce the necessary device drivers for newer hardware.

Links


RISC OS 5
ARM
ARM processor cores
Intel
Intel XScale processors With thanks to David Ruck, Martin Wuerthner, Steffen Huber and Ian Jeffray for their individual assistance.

Previous: State of play FAQ soon from Acorn User
Next: Imagining RISC OS and PMT

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

Nice article! Are there any plans for an FPU co-processor for these ARM processors? -- Simon Wilson, Boulder, Colorado

 is a RISC OS Userksattic on 26/7/03 12:08AM
[ Reply | Permalink | Report ]

ARM based, wtf does ARM based mean?

 is a RISC OS Usernex on 26/7/03 12:12AM
[ Reply | Permalink | Report ]

Don't worry nex I'm sure it's armless.

 is a RISC OS UserSnig on 26/7/03 12:21AM
[ Reply | Permalink | Report ]

nex: ARM don't make processors, they design processor cores. When manufacturers licence the cores, they integrate them into their own processor design. Hence, an ARM chip you buy is based on ARM technology. -- Simon Wilson, Boulder, Colorado

 is a RISC OS Userksattic on 26/7/03 1:26AM
[ Reply | Permalink | Report ]

ksattic: Gah, I left that FP issue out, accidentally. The ARM1020E core can have a VFP10 co-processor floating point unit that delivers up to 650 MFLOPS, according to ARM.

Chris, drobe.co.uk

 is a RISC OS Userdiomus on 26/7/03 3:03AM
[ Reply | Permalink | Report ]

Chris: NICE! Gimme one of those and a compatible ARM motherboard/chipset please! -- Simon Wilson, Boulder, Colorado

 is a RISC OS Userksattic on 26/7/03 3:11AM
[ Reply | Permalink | Report ]

Hi Chris!

650 MFLOPS at 325MHz. A 1.2GHz version would be a lot faster. :-)

Only problem with it is, that it is not compatible with the old FPU in the 7500FE. But I guess one could make a SuperFPEm that takes advantage of it.

-- Julian G. F. Zimmerle

 is a RISC OS UserJGZimmerle on 26/7/03 10:58AM
[ Reply | Permalink | Report ]

Or just pay one of the 53 companies that have the source code now :-)

Does compatibility matter? Is there enough old FP code to bother making a conversion module?

 is a RISC OS Usermavhc on 26/7/03 11:11AM
[ Reply | Permalink | Report ]

So, wearing my contraversial hat, doesn't it worry anyone that your platform is stuck on using embedded processors?

It worried me as an Apple user a little - I was concerned that I bought into a platform that couldn't keep up anymore. Motorola had no clear plans to speed up the G4 (which was essentially an embedded systems processor), it was only by going to IBM who championed PowerPC as a high-end platform that Apple managed to get back in line.

I know processor power isn't the be all and end all, but if you're doing lots of compile work or scientific work (like I do), or want to play modern games, multimedia editing software, etc., then it helps at times :)

-- Dougal

 is a RISC OS UserDougal on 26/7/03 11:41AM
[ Reply | Permalink | Report ]

Good article Chris !

Dougal> Yes it is of concern that ARM is being targetted at "embedded" only devices.

If I am correct Apple is still a major shareholder in ARM, if that is correct it follows that they would be less keen on seeing a "fast" ARM being used in computers that could compete against their boxes.

The problem for ARM though is that with PowerPC and MIPS processors beginning to encroach into their territory ARM simply sitting on their hands (if you pardon the pun) won't do.

It would be monumental folly to restrict the ARM to such a degree that some of the bigger players could simply "cut" some bits out of a high end processor and then drop down into ARM's niche and compete or even outperform the ARM.

Perhaps ARM won't "officially" up their specs, but Samsung's HALLA (ARM10) may already represent a company off it's own bat upping the spec. Samsung have shown upping the ARM spec can be done (incidentally the HALLA puts out 1.5 Watts at 1.2GHz, so it's not that far outside Intel's 1 watt envelope, so perhaps Intel will be next - who knows).

Again a good article....

-- Annraoi McShane,

 is a RISC OS UserAMS on 26/7/03 12:39PM
[ Reply | Permalink | Report ]

I don't think that Apple will be *too* concerned about RISC OS competing with their boxes ;-)

Being restricted to embedded processors is not so bad, MIPS is primarily an embedded chip and gets very fast indeed. SGI use them in some of the fastest workstations and servers in the world, and even the embedded ones are fast, 2x1Ghz cores on one chip.

The only problem with an embedded processor, as stated above, is that speed is not the number one priority like it is with P4,G5 etc. But Intel,Samsung, and ARM themselves still want to see the ARM go faster, particularly if they want to go into markets like high end routers etc.

 is a RISC OS Userthegman on 26/7/03 1:15PM
[ Reply | Permalink | Report ]

AMS: I think you do ARM a disservice by saying they sit on their hands - they certainly do not. As one of the leading providers of embedded processor cores they are doing increadably well (and they're British - how confusing!) and having visited them I saw a very aggressive team determind to keep it like that.

The point is that ARM are world leading experts in embedded processors, and as such they're unlikely to start thinking about going into other markets like the desktop arena. For that to happen there would need to be a large market demand, and RISC OS certainly isn't that. One of the reasons Motorola never really got its act together for faster PowerPC devices is that Apple as a Motorola customer is a small customer compared to the embedded device consumers.

thegman is right - both SGI and Apple have made embedded processors do wonderful things, but again I'd argue that the ARMs target market is low power. I don't know the numbers, but I'm willing to bet that the G4 burns a lot more energy than an ARM device (and see the Intel quote in the article). Until someone produces an ARM design that's less concerned about power then it's still going to be a tardy thing in terms of raw performance.

There's nothing particularly wrong with this (it's environmentally friendly for a start ;) but the trade off is that some of the popular apps that people are starting to expect need more horse power., and without which I image Castle et al will have problems getting new people into the market rather than just selling machines to existing customers.

-- Dougal

 is a RISC OS UserDougal on 26/7/03 1:49PM
[ Reply | Permalink | Report ]

Just need to put 64 ARMs in 1 computer, problem solved.

 is a RISC OS Usermavhc on 26/7/03 1:58PM
[ Reply | Permalink | Report ]

Dougal> I think you misunderstood what I meant, I mean that ARM are not really "pushing" the performance of their platform (for example ARM v6 is scheduled to hit 650->1GHz by Q4 2004 -the end of NEXT year). But Intel's IOP321 already is more or less there (at 600MHz) and Samsungs (ARM v5) Halla is ahead (1.2GHz), so why hold back ?

By not "pushing" the envelope at all ARM are even falling behind what their licensee's are managing.

I do not see *any* technical reason why ARM cannot have designs that cover the full gamut from hand held up to server processors.

Unfortunately they don't, thing is Motorola/IBM or SGI (MIPS) are not as limited, they can hawk their wares to any company and assure them that their processor range covers *everything* from hand held battery powered devices up to high end servers.

Why limit your market - that limits your possibilities doesn't it ?

-- Annraoi McShane,

 is a RISC OS UserAMS on 26/7/03 2:04PM
[ Reply | Permalink | Report ]

"I do not see *any* technical reason why ARM cannot have designs that cover the full gamut from hand held up to server processors."

But are you a processor designer? I've done some work on processor design (my PhD thesis was about extending an ARM processor to do whizzy stuff) and I don't think even I'd make such a sweeping statement :)

The ARM ISA is a bit long in the tooth - it is lacking in registers compared to other RISC offerings like the Alpha and PowerPC architectures. Certain design decisions in the architecture that were fantastic at the time do not scale well these days (e.g., putting a barrel shifter on your critical path). Adding extra function units to an ARM processor requires the use of the coprocessor interface, which for load and store instructions requires the main integer unit to be tied up, so you can't superscale the ARM particularly well. My point is that there is no way that an ARM processor based on the current ISA will scale to compete in the server market.

ARM, like a lot of chip companies, are customer focused. They listen to what the customers want, and then they take the features that will shift the most chips and build them in. Look at the Java support for instance.

"Why limit your market - that limits your possibilities doesn't it ?"

It's also social issues. Do they have enough expertise in the higher end markets? How much would it cost to try and design a higher level calss ship in terms of man power and what is the likelyhood it'll make real money up against the existing competitors? Can they tackle it without taking their eye off the embedded market too much?

I disagree with you: I think ARM are probably doing the right thing by sticking with what they're good at.

-- Dougal

 is a RISC OS UserDougal on 26/7/03 2:15PM
[ Reply | Permalink | Report ]

Groovy article.

Erm - is it just me but isn't there an advantage for RISC OS with these embedded processors?

Here is the example:

Iyonix - once the 32 bit stuff & HAL done then a machine appears.

A lot of what that machine is (DDR & no AGP) is perhaps because it was already on the chip?

Omega - MD have to design RISC OS specific chips.

Omega uses a "pure" processor.

A massive[/i} task.

Result - machine is 3 years late.

All credit to MD for actually getting the thing to work.

RISC OS companies are tiny.

I doubt that anybody has the resource to quickly bring a new RISC OS machine to market even now without using these embedded jobbies to short circuit some design issues.

Last point....

Why is 1GHz so "magical" - does RISC OS really need it?

Or we do need it because of the FP problem?

 is a RISC OS Userepistaxsis_RISC OS on 26/7/03 2:52PM
[ Reply | Permalink | Report ]

Eh Dougal, I am allowed a sweeping statement now and again ;)

Yep I am not a processor designer, so I'll accept that the ARM as it *currently stands* would not do as a Server CPU. In addition to what you say above it lacks bus snooping so making it work effectively in a multiprocessor or shared memory environment would be difficult.

That having been said some of your assertions may still warrant a review, for example you say " it is lacking in registers compared to other RISC offerings like the Alpha and PowerPC architectures", true but many current server and desktop machines are usually x86 that have even fewer registers.

What I was really focussing on would be thinks like why is the cache so small (making it bigger should not be a problem 16+16KB seems a bit restrictive). Not endorsing higher clock rates seems a bit of a downer as well (especially when some licensees have shown that they can)

As to the market ARM are in ARM selected it *before* they had *any* customers.

And as to your last comment that ARM are "doing the right thing by sticking with what they're good at. " that's precisely what Acorn did by sticking to the education market - and we all know what ultimately happened to Acorn don't we ?

That having been said you've raised some interesting points, and although server may be aiming a bit high surely producing a compeditive desktop processor shouldn't be ?

Bear in mind as well although ARM may not have the manpower to do an upscale design - bear in mind Samsung, Intel et al may so ARM should encourage them to get on with that. ARM would simply ensure compliance with the ISA and wide availability of architectural improvements if and when they come on stream (all IMHO)

-- Annraoi McShane,

 is a RISC OS UserAMS on 26/7/03 3:46PM
[ Reply | Permalink | Report ]

I think that ARM does need to go to GHz levels, or make performance better at current levels. Clock for clock, ARM chips seem to be about the slowest you can buy in a desktop computer, for most tasks.

Also, if new RISC OS machines came out with a massive speed increase over existing models, people would be more liikely to upgrade.

I'm not qualified to talk about ISAs and whether the ARM needs more registers or whatever, but it certainly does need to go faster to be serious on the desktop.

 is a RISC OS Userthegman on 26/7/03 4:37PM
[ Reply | Permalink | Report ]

thegman>

running which OS?

For a full desktop environment RISC OS is still remarkably efficient.

unless this is to get around the software FP emulator issue?

 is a RISC OS Userepistaxsis_RISC OS on 26/7/03 5:52PM
[ Reply | Permalink | Report ]

epis: I should have clarified that statement: For stuff like C,Python,Java(Kaffe),web browsing, and graphics work, my RiscPC was very slow compared with my other machines.

RISC OS is extraordinarily fast on slow hardware, granted. I have read that Linux tends to benchmark faster though. However my experience with Linux and other UNIXes, is that you can't buy a PC fast enough to make it as 'snappy' as RISC OS.

I would like to see some benchmarks against other machines, I'm using a PA-RISC laptop right now, which feels sluggish, but would be interesting to see how it weighs up against RO boxes for comparable tasks.

I think most of us here are not that bothered about clock speeds, but we are bothered about real-world speeds, which IME ARM does not do so well.

 is a RISC OS Userthegman on 26/7/03 6:34PM
[ Reply | Permalink | Report ]

AMS: Some how I doubt ARM will pursuade Intel to make a version of the XScale that could eat into the Pentium market, their cash cow. :)

Note also that low end sever and high end desktops are using the same processors these days. You're not going to get that performance out of the ARM ISA as it is. And then if you design a new ISA you might as well go otherwhere.

As for Samsung, they had the Alpha and failed to do much with it, so I wouldn't count on them taking the ARM anywhere upwards.

BTW, one assumes the caches are small due to power concerns. The bigger they are the more power they consume. For an embedded device, which only does one thing very often, smaller caches are fine.

-- Dougal

 is a RISC OS UserDougal on 26/7/03 7:46PM
[ Reply | Permalink | Report ]

The slowest part of the computer is usually the human/computer interface, the conclusion is obvious.

 is a RISC OS Usermavhc on 27/7/03 12:12AM
[ Reply | Permalink | Report ]

Dougal: whats this ISA you keep mentioning?

 is a RISC OS Userdansguardian on 27/7/03 10:56AM
[ Reply | Permalink | Report ]

dansguardian: Sorry, ISA = Instruction Set Architecture. Basically it covers the semantics and syntax of a processor from a programming point of view (what registers are available, what instuctions can be performed, etc.). An ISA can have many different implementations, but all should be able to (more or less) run the same software.

mavhc: care to cite the scientific study that shows that? Persumably, for your sweeping statement, it shows that for all possible users for all possible applications, that the UI is the slowest thing. So when I set hardware simulations running that take days to complete, it was the UI I used that caused it to take that long?

-- Dougal

 is a RISC OS UserDougal on 27/7/03 11:08AM
[ Reply | Permalink | Report ]

There's a new device from PsionTeklogix that uses the XSCALE unfortunately it also runs on windows CE.NET! shame..

 is a RISC OS Usergoon on 27/7/03 11:20AM
[ Reply | Permalink | Report ]

No, just usually. As in for 75% of the peopletime

 is a RISC OS Usermavhc on 27/7/03 12:39PM
[ Reply | Permalink | Report ]

Dougal> But you say "As for Samsung, they had the Alpha and failed to do much with it, so I wouldn't count on them taking the ARM anywhere upwards."

Thing is Intel bought out DEC who sold their Alpha fab plant, Alpha was still second sourced by Samsung - but with Intel having "taken out" DEC where was Samsung to go.

I'd also point out that some of the techniques Samsung have used with their ARM10 (Halla) were taken directly from their experience of developing their variant of Alpha (and Halla is the fastest ARM10, ARM were only aiming for 350-400MHz (ballpark), Samsung managed 1.2GHz).

As for the ARM ISA it has some nice touches like conditional execution (and being able to avoid a branch is a useful way of keeping pipeline running efficiently I would have thought).

Yes more registers would be nice, but (again) as I said the x86 manages with fewer - where the ARM really does fall down is the relatively low clock rates and small caches - improve those two and in conjunction with the efficiency of RISC OS and we would wind up with a platform that could take on everything *but* the very fastest (read expensive) processors.

I'd also point out that later MS O/ses (such as 2003 Server with .NET, and Longhorn (whenever it finally appears)) will also sap performance improving our chances of catching up.

Kind Regards -- Annraoi McShane,

 is a RISC OS UserAMS on 27/7/03 1:47PM
[ Reply | Permalink | Report ]

goon> yeah I heard about that one.

crazy!

perhaps psion can't afford EPOC (sorry - symbian) anymore?

Anyone want to sell them galileo again?

Joking! ;-)

 is a RISC OS Userepistaxsis_RISC OS on 27/7/03 2:04PM
[ Reply | Permalink | Report ]

If I can just pick up a few points raised by AMS:

AMS: <Dougal says> " it is lacking in registers compared to other RISC offerings like the Alpha and PowerPC architectures", true but many current server and desktop machines are usually x86 that have even fewer registers.

This is as much a question as a comment but I was under the impression that part of the risc philoshophy was to have fewer instructions and more registers. I'd guess that somehow the disadvantage of not having a dedicated instruction for everything is made up for by having loads of registers. Perhaps Dougal can enlighten us.

AMS: What I was really focussing on would be thinks like why is the cache so small (making it bigger should not be a problem 16+16KB seems a bit restrictive). Not endorsing higher clock rates seems a bit of a downer as well (especially when some licensees have shown that they can)

Of course, both a bigger cache and a higher clock rate have detrimental effects on the power consumption. With the market that ARM are focused on, it would seem that they prefer the balance they have.

AMS: As to the market ARM are in ARM selected it *before* they had *any* customers.

I'm not sure how true that is. Obviously, before ARM was ARM, they concentrated on making processors for desktop computers. I don't know what came first. The customers interested in their low power processor or ARM themselves going out to attract the low power market.

AMS: And as to your last comment that ARM are "doing the right thing by sticking with what they're good at. " that's precisely what Acorn did by sticking to the education market - and we all know what ultimately happened to Acorn don't we ?

That depends on which stage of Acorn's life you are referring. It's true that they may have been able to push the Archimedes into markets outside of education. They tried that with the beeb but one could argue that the machine was already a bit dated when they did that. Or perhaps the concepts were ahead of their time. Towards the end of Acorn/E14, education was hardly on the agenda. The company seemed to have lost focus. And that is one thing you can't say of ARM. They seem to know exactly what they are doing and they are having great success in doing so.

Lastly, do we really /have/ to have an ARM processor? If it weren't for the fact that RISC OS is so closely tied to the ARM wouldn't we be just as happy with another processor type? I hear that IBM are doing some nice things with PPC risc chips. :-)

-- Spriteman.

 is a RISC OS UserSpriteman on 27/7/03 3:26PM
[ Reply | Permalink | Report ]

AMS & Spriteman: I'd speculate (and I'm just guessing here) that the reason ix86 can get away with fewer registers is that as a CISC architecture it needs less intermediate results. The RISC idea is to only have basic instructions, no composite instructions (like string copy :) in order to make the processor design simpler and then clock higher. From this it seems that you need more explicit data storage for intermediate results on a RISC processor as you build up the larger operations from the basic ones provided to you. Like I say, look at the big RISC chips and they have lots of registers.

AMS: Yes, ARM have conditional instructions, and I won't disagree with you that it is very handy when writing ARM assembly (which I've done a fair amount of in my time), but then look at the designs for modern high speed processors - they all separate out the control flow instructions into a separate exection unit to try and increase instruction level parallelism (IPL). On the ARM you can't do this, as almost every instruction is potentially conditional. I think this feature is nice for software writers, but the moment you get to having the processor issue instructions out of order and in parallel groups then it's not so nice.

AMS: regarding just ramping up the clock speed, like I've pointed out, it's not that easy - that barrel shifter in there really does slow things down. And, as myself and Spriteman have pointed out ARM don't see this as a big seller right now. If ARM had a majority of customers demanding such highly clocked ARM chips they'd be going for it I'm sure. As it is ARMs biggest customers are not people that try and stuff ARMs into desktop machines, not even PDAs I'd wager. It's people like, mobile phone companies (from bumping into ARM people I know ARM have a strong relationship with Nokia at least), who shift vast number of units that absolutely have to have low power.

Finally: ARM originally was part of Acorn and designed their first ARM chip using just a handful of engineers who'd never made a chip before. It's still seen as a fantactic achievement in the industry that it worked so quickly. But the original ARM chip was aimed at a desktop device. ARM, since being spun off, have then over time drifted into the embedded market as they had such a low power chip in the ARM. Partly one imagines this drift will also have been in some small amount due to Apple's influence when it bought a large stake in ARM in order to get the Newton it's processor (note, I'm fairly sure this is no longer the case - I think Apple sold it's shares in ARM a while back).

Anyway, I'd best do some actual work ;)

-- Dougal

 is a RISC OS UserDougal on 27/7/03 3:56PM
[ Reply | Permalink | Report ]

Dougal: The barrel shifter is not as big an issue as you are claiming, provided it is in a separate pipeline stage like in the ARM11 or XScale microarchitectures. This does increase the number of interlocks, but not by a huge amount for average code.

AMS: ARM are not "falling behind what their licensee's are managing." Samsung are using the standard ARM1020E deliverables, then applying lots of funky low level circuit techniques to achieve a higher clock freqency. [link] has an interesting article which gives more details.

 is a RISC OS Useranon/217.155.73.149 on 27/07/03 6:17PM
[ Reply | Permalink | Report ]

AJW> ARM set targets that Intel and Samsung have both exceeded (ARM's roadmap document were mentioning 650-1GHz parts by "Q4 2004", that's over a year off and Samsung and Intel have hit that mark *now*).

I'd love to see someone subtantially up the cache and up the clock rate (even if the Power performance suffers). ARM's are no longer "just" used in handheld devices, firewalls and other comms gear do use them. Obviously in such circumstances power consumption should be/is of less concern (and hence why not have a large cache, why not clock the beastie a bit quicker). If as a bi-product we wind up with a processor that can substantially improve on what we have at the moment - fine.....

Regards

Annraoi

 is a RISC OS UserAMS on 28/07/03 6:18PM
[ Reply | Permalink | Report ]

Hi Dougal!

I am not very concerned about our OS's dependance on an embedded processor. It is fast enough for most things and most of the rest can be done in the FPGAs with application specific circuits. If the worst comes to the worst one could follow the Amiga's route and use two different CPUs, an ARM for compatability and an IBM-Power4-booster for new applications wich require this kind of power. :-)

 is a RISC OS UserJGZimmerle on 28/07/03 11:31PM
[ Reply | Permalink | Report ]

Hey Zimmerle,

My actual PhD was on using reconfigurable logic to speed up applications at run time by letting them load circuits they lead. Trust me, there's a lot of issues about this (it's a hot active area of research) - FPGAs are slow to reprogram and thus fine grain sharing of the resource is quite hard. Most of the research is about combining the CPU core and reprogrammable logic on a single chip, otherwise your off chip communication costs can become excessive (I've seen reports of photoshop filters that ran slower that software on an FPGA co-processor because of the excessive communication overheads).

I think it's a cool technology (having spend 4 years of my life investigating it ;), and I really do hope to see it used in the future, but be aware that it's not just as simple as "ah, we'll just slap an FPGA in there and it'll work" - ensuring the reconfiguration and communication overheads don't out weigh the benefits whilst sharing it between a set of applications isn't easy. It'll be interesting to see if MD with the Omega allow 3rd party applications to access the FPGA and if so how they'll do it. I mailed them a couple of years ago when they announced the project enquiring as to what they were going to be doing but I got no reply.

On the other point (using a second processor) that's just a complete pain for developers. On of the reasons dual processor (DP) macs were never popular before Mac OS X was that programmers had to explicity write code to use the second processor rather than just threading their applications and letting the OS worry about it, so very few companies wrote applications to support it, and thus no one bought them, and thus DP macs were canned until the release of OS X. And note that that was two of the *same* processor!

Anyway, I hate to sound negative, I'm not trying to say "you're doomed! bwahahahaha" (this isn't an Amiga forum after all ;) ) - I was just trying to stir debate.

 is a RISC OS UserDougal on 29/07/03 08:49AM
[ Reply | Permalink | Report ]

My posts always end up as long rants - sorry :)

 is a RISC OS UserDougal on 29/07/03 08:49AM
[ Reply | Permalink | Report ]

I don't think the use of an embedded processor is a problem... There are many solutions to avoid the lack of performances : better software optimisation, assymetric multiprocessing support (check the 4 * ARM233 Simtec PCI card), good sales that mean that Castle could ask for a production line of ARM with "speed oriented transistors", etc.

Main problem is not to loose the focus : flexibility and optimisation. We see today that an R7500 has good performances, but we could make a better draw for it by using the FPU. In the PC world this idea cannot be applied but here people keep their computer a lot of years, so optimisation is really the way to get more performances.

a 20% speed up on Wimp is really better than to switch from a P4 2.0 GHz to a 2,4 GHz one... Other example : my PC card was really faster than my current (and as much pricey) VPC on Mac. thanks to the excellent PCPro driver. ARM computers has a strenght : best performances for the power. More power would be good, but never forget our performance/power advantage. If you do so, ARM computers will become a PC or a Mac and will - IMHO - die.

 is a RISC OS Userdfeugey on 29/07/03 10:19AM
[ Reply | Permalink | Report ]

My understanding of Simtec's multiple StrongARM PCI card is that they're completely seperate computers - not one with multiple CPUs. At this point, it's more of a cluster, than a multiprocessors.

I don't think many people would agree with you on the "R7500 has good performance" - if that were so, people wouldn't be so interested in getting Iyonixes. :)

 is a RISC OS Usernunfetishist on 29/07/03 2:07PM
[ Reply | Permalink | Report ]

I'm afraid I have to dispute the Mac VPC faster than PC Card claim. VPC on my mac runs at about the speed of a 600MHz x86 chip. However, that may be purely due to the fact I have 2 1.25GHz processors - 1 working on redraw, and another purely working on the emulation.

Also the G4 processor has an x86 emulation mode which VirtualPC takes full advantage of (minus the endian issue).

Earlier versions of VirtualPC supported the ill-fated 3DFX card for graphics acceleration. You could play quake full pace on it no problems at all.

Anyway, thats my 3p. Back to my PPC, ARM, MIPS, x86, etc boxes :)

 is a RISC OS Userg0tai on 29/07/03 9:04PM
[ Reply | Permalink | Report ]

Hi Julian/David: if you look at the major applications in RO which are still being developed/upgraded (Vantage, Artworks, Photodesk) there is a strong graphics bias IMHO. That can involve complex operations on big image files, for which even a 600Mhz X-scale may not be enough, if the alternative is a dual-processor Mac with over 2Ghz plus the described advantages of the PPC architecture. So why not port RO to the PPC? Didn't Acorn have a plan to do this once?

 is a RISC OS Userbucksboy on 30/07/03 1:36PM
[ Reply | Permalink | Report ]

Hi George, Yes, there is a strong bias towards graphics, simply because that's what people are buying for their machines more than most things, it's also probably the only area in which RISC OS can really stand up for itself on the desktop, especially OPro vs. Quark. I think for Iyonix money the best new Mac you can get is a dual 1.25Ghz G4, which is clearly going to open a huge can of whoopass on the Iyonix in terms of raw speed. But still, I'd have the Iyonix myself. I think back in the Xemplar days, Acorn got an idea into their heads about CHRP Macs with ARM cards or something, but I don't think they really seriously considered porting RISC OS to PowerPC, maybe Galileo though.

RISC OS is very tied to ARM, porting to PowerPC is certainly *possible*, but I think ARM is a good place to be. It's the most popular processor core in the world, and although the computers we have right now are terribly slow by comparison to Macs and PCs, with Castle owning RISC OS now, there is no real reason why it cannot be made to work on much faster ARMs, when they appear.

I think Castle have the right idea wanting to go into the embedded arena, rather than just desktops.

 is a RISC OS Userthegman on 30/07/03 3:24PM
[ Reply | Permalink | Report ]

agreed.

better "new" market than set top boxes ;-)

btw how much of the ARM3 is left in the modern PPC?

1 other thing if graphics stuff is the biggy - wouldn't enabling all the capabilities of the iyonix's graphics card help?

 is a RISC OS Userepistaxsis_RISC OS on 30/07/03 11:34PM
[ Reply | Permalink | Report ]

I did not know PowerPC had any relation to ARM3!

STBs may be a bad idea, but the NCs were a great one, the only way RISC OS can possibly compete with PCs on price in schools and stuff, if they had RISC OS 5 on those simtec/EQ StrongARM machines in a little case, make a lovely NC.

For me personally, graphics is not the biggie, it's programming tools, but having full use of the GeForce2 would be good for OpenGL and stuff.

 is a RISC OS Userthegman on 30/07/03 11:52PM
[ Reply | Permalink | Report ]

"btw how much of the ARM3 is left in the modern PPC?"

Pardon? They're totally unrelated.

 is a RISC OS UserDougal on 31/07/03 00:31AM
[ Reply | Permalink | Report ]

really?

I was told that parts of the ARM3 were in the PPC...

praps an old acorn rumour from the 90s then :-)

 is a RISC OS Userepistaxsis_RISC OS on 31/07/03 6:17PM
[ Reply | Permalink | Report ]

Trust me, they are unrelated, both in the fact that they were designed and made independantly, and in that they program differently at the assembly level (I've written a considerable amount of code for both).

 is a RISC OS UserDougal on 31/07/03 6:46PM
[ Reply | Permalink | Report ]

The one thing they do have in common is that they were both used in the first RISC Desktop PC. :-)

 is a RISC OS UserSpriteman on 01/08/03 10:56AM
[ Reply | Permalink | Report ]

And an R in the name

 is a RISC OS UserDougal on 01/08/03 1:29PM
[ Reply | Permalink | Report ]

Dougal, I read with interest your comments about the ARM architecture. With regard to your comments on the barrel shifter, I wonder, would it not be possible to special-case one or a few (probaby LSL#1 and LSL#2) so that they didn't slow it down? As I understood it this was already the case for the X-Scale with LDR instructions.

(Oh, and this is my first post on this forum. Hi folks.)

 is a RISC OS UserLoris on 01/08/03 4:02PM
[ Reply | Permalink | Report ]

"The one thing they do have in common is that they were both used in the first RISC Desktop PC."

So it was said!

Martyn

 is a RISC OS UserMartyn Fox on 01/08/03 6:56PM
[ Reply | Permalink | Report ]

The ARM is the most sold processor, it's cheap, it doesn't use much power. Why not putting 10 ARM processors in one computer instead of one. You can even put 10 processors on one chip.

 is a RISC OS UserJaco on 19/08/03 7:08PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • RISC OS filename translation
    Being understood in the outside world
     31 comments, latest by mrchocky on 09/01/04 11:06PM. Published: 2 Jan 2004

  • Random article

  • Publicise RISC OS and win a prize
    Spread the word, deadline Thursday
     Discuss this. Published: 18 Jun 2006

  • Useful links

    News and media:
    IconbarMyRISCOSArcSiteRISCOScodeANSC.S.A.AnnounceArchiveQercusRiscWorldDrag'n'DropGAG-News

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    Dealers:
    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster

    Usergroups:
    WROCCRONENKACCIRUGSASAUGROUGOLRONWUGMUGWAUGGAGRISCOS.be

    Useful:
    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign


    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "I've been attributed with things I didn't say on drobe in an attempt to stir the pot with this situation"
    Page generated in 0.5275 seconds.