[Greg McKaskle]

Perhaps it is useful to make a clearer distinction between the concepts and the implementations.

A SW library and a HW library for floating point are interchangeable provided they meet timing requirements and give the same answers. In fact, the PPC is RISC and does some float math in HW and some in SW. Even CISC processors will not do everything in HW. Both are implementations of the concept of numerical math operations on continuous number line approximating real numbers -- useful stuff.

A given computer can carry out at most N instructions in parallel. N is a hard limit imposed by the HW design. For a single-core, N is one. For a multicore, it is 2, 4, or maybe a higher number, but this is the upper limit. It is up to the SW to keep the cores busy but still produce the correct results. Threads, interrupts, and other concepts can act as SW work-arounds to the HW limits and even with these, multiple cores are often under-utilized.

So similarly, multi-tasking can be implemented in SW or HW, or more likely a combination. But in a time period, say 20ms, it can swap tasks numerous times and effectively get a number of things done. If the swapping is fast enough compared to the time period we are measuring, it is indistinguishable from HW parallelism -- gives the same results -- useful as well.

So my answers would be ...

I want easy access to mathematical operations that make robotics clear and accessible. This includes floating point math and IMO includes vector and matrix math.

I want to easily specify operations that are sequential and those that are parallel and the synchronization points. The FPGA already does many tasks in true parallel, so this lightens the need for this, but plenty need remains.

Editorial Comment:
Comparing implementations, threads are a gory and primitive way of specifying parallelism -- IMO. They are rather standard, but also very error prone. Even if you are going to implement in threads, it is nice to be able to think and specify operations in a higher level abstract language so that you can have a clearer design. And yes, I think this is one of the strengths of the data flow approach that LV adopted. I believe I am a better user of threads, semaphores, and the like because I know LV.

Greg McKaskle