Steven Johnson sjohnson at sakuraindustries.com
Wed Aug 29 16:44:38 CDT 2007

The IBM Research Hypervisor is not the same interface as the Sony one.  
They both utilise the System Call instruction to access functions of the 
Hypervisor from the Supervisor space, but beyond that the similarity 
ends. (at a programming level). 

Targeting different Hypervisors may be useful, but at the moment I only 
have access to the PS3 Hypervisor.

I am very much concerned by the dual hardware thread nature of the Cell 
PowerPC core.  It has 2 x 64 bit hardware threads operating (from a 
software perspective it can be considered dual core).  I have only seen 
RTEMS running on Single Processor - Multi Threaded systems or (seen, but 
not used) multi-processor systems where each processor runs a copy of 
rtems and each processor intercommunicates using rtems facilities.  What 
are the issues when the Hardware threads are tightly coupled like the 
Cell processor.  I would want RTEMS to schedule 2 simultaneously running 
threads to each processor thread.  Are there any issues with that?  has 
it been done before?  Are there any examples I can look at?  How will 
this effect things like critical regions when getting a critical region 
will not guarantee that the other hardware thread is not going to access 
the thing the critical region seeks to protect (The PowerPC targets I am 
aware of implement critical regions by turning of IRQ's, which is only 
"per thread" and not global.

Forget the SPU's, because I don't intend to run RTEMS on them, they will 
just be intelligent programmable peripherals.  Although it would be 
feasible to port RTEMS to an SPU and implement a classic RTEMS 
multi-processor implementation using them.  The limited ram in each 
(256K) may restrict the viability of that however.

Advice on the multi-threaded nature of this processor and best utilising 
that on RTEMS would be very helpful.


More information about the rtems-users mailing list