Re: a multicore XMOS CPU

[Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2528 bytes --]

On Thu, 11 Feb 2010, Ludovic Brenta wrote:

|------------------------------------------------------------------------|
|"darek <darek.maksim...@gmail.com> wrote on comp.lang.ada:              |
|>   1. How to distribute  tasks between cores ? It is responsibility of |
|> the Ada run-time or the programmer shall do it explicitly (each core  |
|> up to 8 real-time threads) via pragmas (I think, extending the        |
|> language definition is not a good idea)?"                             |
|------------------------------------------------------------------------|

If you can accomplish a compiler which will automatically take up all
of the cores, then congratulations. However, it is not unreasonable
for the end users to be required to determine this scheduling. For
example, I often need to run many programs and I have many cores for
them. It often does not matter whether I run them all at onece, one
per core, or one after the other, taking up many cores each time. It
is trivial to efficiently put each on one core each.

|------------------------------------------------------------------------|
|"I'd think the easiest, as a first step would be to mimic the extended  |
|C they provide and then, maybe, provide for dynamic thread allocation   |
|from within the kernel (see below).                                     |
|                                                                        |
|>  2. Is it possible to create from publicly available source GNAT code |
|> a system that does not require any OS support (a bare metal solution)?|
|                                                                        |
|Yes, it is possible. However I think tasking support requires a kernel  |
|such as the OpenRavenscar kernel[1].                                    |
|                                                                        |
|[1] http://polaris.dit.upm.es/~ork/                                     |
|                                                                        |
|[..]"                                                                   |
|------------------------------------------------------------------------|

Beware of ORK. It had a bug in it which had been fixed in GNAT seven
years earlier. Not to mention the excessive overhead of ORK (as
opposed to RAVENSCAR) for a virtually null program taking up nearly
half of the memory you have (per core or overall, it was not clear
from the product brief what the memory was being quoted for).