[Milkymist-devel] Single-Thread AEMB

Sébastien Bourdeauducq sebastien.bourdeauducq at lekernel.net
Mon Jun 1 08:41:32 PDT 2009


Hi,

On Monday 01 June 2009 17.00.48 Shawn Tan wrote:
> Sounds like the problems are mainly software portability issues. If an
> application is written as a single-threaded app, it will only benefit from
> the interrupt handling of the AEMB. Customising an app for the AEMB would
> make it less portable.

> I'm not quite sure if a single-threaded core may be better because of the
> wasted cycles encountered by data and control hazards.

The balance is between :

* having good performance with 2 threads and no hazards thanks to a good load-
sharing between the interrupt service routine and the main program (other 
optimizations should be avoided without a heavy framework like OpenMP to keep 
portability), and
* having good performance with only 1 thread subject to hazards, and a quite 
short pipeline plus a variety of well-known systematic techniques to reduce 
the occurrence or impact of such hazards (instruction reordering, loop 
unrolling, branch delay slots, etc.) that are already implemented in GCC (no 
extra software work required). A branch predictor could also be added to 
reduce the impact of control hazards (bimodal is quite simple and efficient 
and should fit well in FPGAs).

This is only my gut feeling, but it seems in favor of the single-thread 
version.

> There's only one real way to test this though - to design a single-threaded
> version and compare them side-by-side. (=

It could also be useful to have a high-level (not RTL) simulator to quickly 
test the impact of various architecture modifications (multiple way caches, 
branch predictor, multiple threads, etc.) without taking the time to go into 
the RTL design and coding.

Sébastien



More information about the Devel mailing list