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

ARM beds NEC for SMP

By Chris Williams. Published: 21st Oct 2003, 21:34:48 | Permalink | Printable

ARM11 goodness

ARM and NEC Electronics have teamed up to hopefully produce and market an SMP (Symmetric Multi-Processor) based ARM11 processor core. Additionally, NEC Electronics has licensed the ARM966E-S core and the VFP9 vector floating-point co-processor technology from ARM.

Usually a multi-processor system requires an operating system that can automatically balance applications across the individual CPUs, thus making a system far more efficient. RISC OS cannot at present deal with more than one ARM processor. However if the processor were to pretend to be a single processor while internally possessing multiple cores and performing load balancing itself, the OS and software will think only one processor core is present and run as normal, albeit faster, hopefully.

We predict that such a scenario involving RISC OS is a long way off, although the news is interesting in terms of how far ARM is willing to go in the high end embedded market. ARM also today posted news of their Q3 financial results.

Links


ARM website ARM beats expectations for third quarter from the Financial Times

Previous: Looking at an Elite history
Next: Software News

Discussion

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

The automatic load balancing a long way off? May I say impossible?

Both SMP (used in IBMs POWER4 high end processors) and SMT (Aka Hyper Threading in Intel's Xeon range) present the image of multiple processors to the OS, and it has to be the operating systems responsibility to load applications onto each processor, virtual or otherwise. The hardware is agnostic of high level terms such as processes and threads. The processor can not magically create contents for a second (or other) register file from thin air.

The operating system is where this would need to be supported, and with good reason anyway - the OS is the only entity with the overall picture of the system and is thus in the best position to make resource allocation decisions, such as what processes may execute.

On the other hand, having such a beast available means that if someone had the time, support might possibly be added to the operating system, but if an OS doesn't already provide multi-processor support, this is a lot of work, as the processor needs to be made secure for concurrent access, manage shared caches, and so on.

 is a RISC OS UserDougal on 21/10/03 9:56PM
[ Reply | Permalink | Report ]

Dougal, why do you have a picture of McCauly Kulkin (sp?) as your avatar? ;)

I agree the automatic load balancing idea is BS. If you think about it, it's the opposite of Hyperthreading.

You'd need something in between instructions from the OS to the processors to say "give this instruction to this processor" maybe an FPGA? Otherwise you'd be using processor cycles to actually decide which processor deals with which thread.

I can't see RISC OS ever being able to make use of this, athough I guess some work with PC Cards and Hydra has been done, as well as PMT.....

 is a RISC OS Usersimo on 21/10/03 10:10PM
[ Reply | Permalink | Report ]

There have been very few ARM machines with multiple processors, so I think the support in ARM Linux and NetBSD isn't that great (I think NetBSD's is best, because of Hydra work), although it would be easy to improve by copying from other architectures.

The stuff with the PC card really isn't comparable, except in a very limited way.

 is a RISC OS Usermrchocky on 21/10/03 10:58PM
[ Reply | Permalink | Report ]

Would it be quite easy to implement simple use of parallel processing? For example: RISC OS does always run on one core and each application is assigned to one of the other cores? This might not be very effective but should be faster than a single processor.

Michael

 is a RISC OS Usermaikl on 22/10/03 3:49AM
[ Reply | Permalink | Report ]

Hm, the co-operative way RISC OS works might make proper multithreading difficult?

 is a RISC OS Userpiemmm on 22/10/03 7:29AM
[ Reply | Permalink | Report ]

The Mac OS had no multi-processor support before Mac OS X, but certain applications like lightwave and Photoshop could use multiple processors. Although leaving the application to sort out how its going to use a second processor is not ideal, it suggests a dual (quad?) RISC OS machine is far from pointless.

 is a RISC OS UserJessFranco on 22/10/03 7:33AM
[ Reply | Permalink | Report ]

simo: Is that old McCauley or new Drag McCauly? ;)

It's not about instructions, it's about where a process's state is held. A process has to be explicity loaded into registers, in bigger OSs page tables for virtual memory have to be set up, and so on - giving that (virtual) CPU the task to run. The operating system is the only entity that knows where this active state is, so only it can decide.

JessFranco:

But the extra processor cards on old macs were largely unused, as they had to be explicity programmed for, and having the application manage the sharing is not teh best solution (it has to save off the processor incase other apps want it, or just hold exclusive use of it). Anyway, history shows that such cards were largely under utilised. It's only when multiprocessor support comes for free through OS thread management that multiprocessor macs became properly utilised.

All repeat after me: this requires OS support, this requires OS support, this... ;)

 is a RISC OS UserDougal on 22/10/03 9:56AM
[ Reply | Permalink | Report ]

... requires a miracle. For RISC OS at least. Still nice thought.

 is a RISC OS UserSpriteman on 22/10/03 10:18AM
[ Reply | Permalink | Report ]

According to the story the OS would be oblivious about the ectra processor cores. So it would be a question of replacing the single ARM processor with a SMP and it would work. How the SMP would work I don't know. It is easy for the SMP to follow the different threads but it would have to continue the threads in secret as the OS will think only one thread is running, it would also have to ignore the OS when it wants to continue a thread that has already run much further and when a thread calls the OS the thread has to stop untill the right time arives.

 is a RISC OS UserJaco on 22/10/03 7:15PM
[ Reply | Permalink | Report ]

Jaco: It is not so easy... Any assembler istruction can access the memory before an "atomic action" is completed, the CPUs cache can become invalid without the system knows that, the virtual memory pages can change their status and become spure etc... A process could be freezed by a processor when another processor is executing some of process istructions makeing the saved data in the processes table not valid and so on... Other than this there is RISC OS shared memory that is hard to protect when we use a only one processor... can you imagine with more then one???

I agree with Dougal, the system must support the SMP... a way could be working on the RISC OS 5 HAL, it is possible (but only on multi-threaded and reentrant kernels) to use an abstraction layer for let the rest of the system see a "one big processor" but at the moment the RISC OS kernel is still monolitic and so it is hard to do.

The good thing is that ARM based motherboard are growing and this can be a good help into ARM based computers.

The PC CARD structure is far from a SMP board also because, if i remember well, PC CARD use a feature of ARM processor that let it re-flush on another processor all not-arm-based istructions, (i hope i described it well in english) on an SMP board all processors are ARMs.

 is a RISC OS UserZFP on 22/10/03 10:45PM
[ Reply | Permalink | Report ]

At the ARM site I don't see anything about the SMP to pretent to be a single processor, so you you're probably right.

 is a RISC OS UserJaco on 23/10/03 12:23AM
[ Reply | Permalink | Report ]

The suggestion in the article that a SMP processor could pretend to be a single processor while using multiple cores internally is rubbish. The processor cannot distribute processes onto its cores because it has no idea of processes. Only the OS knows about them. Let us please not waste our time by discussing this nonsense.

 is a RISC OS Userwuerthne on 23/10/03 8:21AM
[ Reply | Permalink | Report ]

The fact riscos runs co-operatively probably isn't a barrier in itself to implementing a multy CPU system, the memory mapping and what not I also don't see as much of a problem, it's the fact that to the best of my knoledge many parts of RO rely on the asumption that there's only one program running at once.

The over-all system speed wouln't be much grater but you might notice improvements if you do a lot of work with CPU intensive programs, say youre applying a effect to a photo in a art package and want to continue typing up your report in another program it'd run a lot smoother, probably only people who build large C programs and what not would notice any great speed improvement.

 is a RISC OS UserNoMercy on 23/10/03 9:20AM
[ Reply | Permalink | Report ]

"However if the processor were to pretend to be a single processor..."

NEXT! :-)

"...while internally possessing multiple cores and performing load balancing itself, the OS and software will think only one processor core is present and run as normal, albeit faster, hopefully."

I'll assume that this is referring to some kind of Acornesque hardware on hardware solution because the software isn't up to the job, resulting in massive expenditure which could have been directed towards making the software cut the mustard whilst still leaving enough in the kitty for several rounds of pints afterwards.

 is a RISC OS Userguestx on 23/10/03 1:13PM
[ Reply | Permalink | Report ]

Not to damnpen any expectations of wonder hardware, but these cores are aimed at the java enabled mobile phones and PDA's out there, where threads are threads and having a 2nd core off working on the DSP/Encoding side of things while the other half plays java games is more likely, so I wouln't hold onto even a fraction of a hope that the'll be any fancy features to make the processor appear as a single core to the OS.

There's virtually no way 2 cores could operate faster than one modern optimised core on a single instruction chain.

 is a RISC OS UserNoMercy on 23/10/03 4:26PM
[ Reply | Permalink | Report ]

The very first thing RISC OS needs before we can even think about SMP support is pre-emptive multi-tasking. From that, the processes (and threads?) could be seperated to run on different CPUs. Any other way would involve the nasty business of hand-coding each application specifically to take advantage of multiple CPUs.

 is a RISC OS Userrpozz on 23/10/03 9:13PM
[ Reply | Permalink | Report ]

Been there [link] done that [link] twice! Seriously though, multi threading and multi CPU support is possible and indeed as show has been done. ARM have however it seems made a commitment to taking such technology forwards, perhaps they will even address the issues of cache coherancy in the new architecture.

 is a RISC OS Userkyllikki on 23/10/03 10:24PM
[ Reply | Permalink | Report ]

I don't know much about multi CPU but it should be possible to run interrupts on an other processor without the OS knowing it. But, knowing this, wouldn't it be possible to do the same with SWI's?

 is a RISC OS UserPeter on 24/10/03 8:48AM
[ Reply | Permalink | Report ]

Peter:

Yes Peter it is possible cause when you call a SWI you make a call to the kernel that have to undestand wich swi you called so it can manage your call inside the current thread and create another thread for execute your swi, this could have also another benefit that is the asincronus system calls more usefull when the system have to serve a lot of requests.

 is a RISC OS UserZFP on 24/10/03 2:33PM
[ Reply | Permalink | Report ]

It may be possible to handle IRQs/FIRQs on a seperate CPU, however virtually all SWI calls take over the machine while they are running anyway. So making SWIs run on a different CPU would be pretty pointless.

 is a RISC OS Userrpozz on 25/10/03 2:48AM
[ Reply | Permalink | Report ]

Peter: you cannot use the other processor without the OS knowing about it. Who's going to set the thing up? That's the job of the OS.

Now, if the OS dedicated one processor to handling interrupts, then the operating system would need to be rewritten anyway to provide the appropriate locking mechanisms to prevent errors introduced due to concurrent accesses conflicting.

I think this news article is basically a red herring for now - the work required to take advantage of it would be substantial, and I doubt it's a priority for either castle or ROL at the moment.

 is a RISC OS UserDougal on 25/10/03 1:03PM
[ Reply | Permalink | Report ]

in reply to rpozz: We are used to the fact that we wait for a SWI to end before continuing the program but I don't know if you ever worked with the APEX card from Millipede. It has an ARM processor on board and when calling a SWI from the RiscPC, you can decide if you wait for the SWI to end or not (or was it the SWI deciding it?) On the other hand, calling a SWI would be a good time to swap tasks.

In reply to Douglas: In interrupts you allways have to provide appropriated locking mechanisms so no difference here.

 is a RISC OS UserPeter on 25/10/03 7:15PM
[ Reply | Permalink | Report ]

Peter:

1) It's Dougal, not Douglas

2) Supporting an OS on a multiple processors is more complicated and requires more locking structures than that designed to run on a uniprocessor system. I recommend you get a book on operating system design and read up on such matters.

Interrupts do have to have protection from other interrupts happening, but there's a danger on a multiprocessor system from when the interrupt actual puts the data somewhere it might modify internal data structures being used by the other processor. The only other way around this is to prevent the other processor making any system calls whilst the interrupt dedicated one is doing its stuff.

 is a RISC OS UserDougal on 25/10/03 9:24PM
[ Reply | Permalink | Report ]

Dougal: > 1> It's Dougal Sorry about that.

As I wrote, I know nothing about multiple processors, only about interrupts. In the Commsdesign article about the ARM-NEC they wrote the OS should take care of the loading, not the processor itself.

 is a RISC OS UserPeter on 27/10/03 9:12AM
[ 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

  • Internationalising RISC OS
    Unicode, i18n and more explained
     30 comments, latest by caliston2 on 16/7/03 8:57PM. Published: 10 Jul 2003

  • Random article

  • Running RISC OS Programs on Linux
    Peter Naulls contemplates the possibilities
     17 comments, latest by drjones69 on 6/6/05 11:17AM. Published: 31 Mar 2005

  • 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
    "Every once in a while I get the impression that sometimes the things published on Drobe are not 100% accurate"
    Page generated in 0.2162 seconds.