Supporting the "multicore" (multi-FPPA in Padauk terminology, in reality they are not full cores, as the µC is a barrel processor - its more like hyperthreading) Padauk µC is hard: They lack good support for parallelism in the instruction set.
What would work now:
Compile code as usual, run it on FPPA0, use hand-written assembler for
all other FPPA.
We will need a synchronization primitive for the user. In many cases,
using volatile will work, but it would be good to have atomics. They
will have to be implemented using a lock. The standard requires
atomic_flag to be lock-free (which by C standardese means they can be
used from signal handlers - I'd assume we'd consider our interrupt
handlers to be signal handlers), and I've found a (complicated,
inefficient) workaround that uses two locks, but hides them from the
user in a way that makes it conform to the standard.
Of course, the pseudo-register p is a big problem, since it would be
shared by all FPPA. So we'd need a lock around any use of it, making it
inefficient.
Where it is known at compile-time that a certain function will be
executed on a particular FPPA only, we could use a core-specific p0…p7
and avoid the lock.
E.g. if main is not called rom any FPPA other than FPPA0, one could use:
[[sdcc::fppa(0)]] void main(void)
{
…
}
Or if function f is only ever used on FPPA4, one would use:
[[sdcc::fppa(4)]] int f(int)
{
…
}
Any further ideas or comments on supporting Padauk multicore µC in SDCC?
Philipp
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
