Easiest parallel transistion

[BitWise]

In my short time programming I have only used C++ and Verilog for some hardware applications. What would be the easiest parallel language to transition into when my board arrives? I know the documentation said the board is C/C++ programmable but does that mean that I have to use the C++ AMP library? Any advice will be greatly appreciated!

[Dade]

[notzed]

C++ AMP wont be any use since there isn't any free implementation afaik, let alone one for the board. It just seems to be another microsoft version of existing technology with a few sweeteners to wedge the competition.

Programming in C looks relatively straightforward (and perhaps the most fun) - at least if one is comfortable with DMA, the fixed/limited memory space, and so on. And C of course.

OpenCL has a flexible 'platform' model, which should map quite nicely to the epiphany architecture, so i'll be interested to see how that works in practice. It has a fairly low level api which at least doesn't get in the way of the parallel code too much, and isn't too hard to get to grips with if you understand concepts behind malloc/free. I guess the biggest plus about OpenCL is that there's already an implementation for the machine, it's widely available on other hardware, and if you spend time learning it you can use the knowledge elsewhere. And because the API is quite small you (are) also (forced to) learn about parallel processing hardware along the way.

There was mention of other parallel programming systems systems like MPI and so on, but I don't know much about those myself.

[hewsmike]

As far as I can tell, the given compiler with the SDK is going to emit code for either C or C++. Depends on one's preference for procedural and/or OO operation. One paradigm well worth a thought ( due to small memory per node ) is to acquire resources with a constructor and release with a destructor, to minimise such footprints at runtime.

Cheers, Mike.

[fmotta]

As far as I am familiar, the use of high overhead libraries like AMP and OpenML is generally a loss of important and limited resources. Those libraries are intended for extremely high-end (read wasteful) systems like Windows and Linux.

For quality application development on most embedded multi-core systems use standard C99 or older coding style. That with a custom runtime library (RTL) that replaces newlib/glibc/... or supplements it with APIs that provide additional hardware features is the solution that many embedded multi-core CPU/MPU suggest. This methodology allows the programmer to learn from the design and use tight/small code and not bloatware libraries intended to prevent the developer from elevating their skills.

[mrob]

[charles]

@mrob You can do a lot with 32KB.

http://en.wikipedia.org/wiki/Apple_II_series

http://apple2.org.za/gswv/a2zine/faqs/csa2pfaq.html#001

"001- What programming languages are available for the Apple II?

Quite a few. Apple Integer BASIC (in-ROM on the first Apple II's), can be loaded into II+ and later models. Applesoft, a floating point BASIC, is in-ROM on all models starting with the II+. Older Apple II's can load-in Applesoft or, via a plug-in board, access it from ROM.

Then, there is MD BASIC, the BASIC-like MacroSoft from MicroSparc, a beta version of Apple's GS BASIC, and the new (1998) Byte Works GS BASIC! Users who want to speed up their AppleSoft programs can use a BASIC compiler such as TASC or Einstein.

Other Apple II languages are Apple Fortran, UCSD Pascal, Orca (ByteWorks) Pascal, Kyan Pascal, Terrapin Logo, Apple Logo, two Logos from ByteWorks, Isys Forth, Master Forth, (and many other Forths), Modula2, Aztec C, Orca/C, ... . Hyperstudio and HyperCard let you create stacks.

To the above you can add several assemblers including Merlin, Orca/M, an assembler from Ninja Force, and the MicroSparc Assembler.

For Orca manuals and to order the Orca languages see Byte Works products at Syndicomm ( http://www.syndicomm.com/products/ ).

--Rubywand, Jeffrey Iverson, Andrew Roughan, Willi Kusche"

[fmotta]

[XYMANDIAS]

This may just be my very basic knowledge not understanding key differences, but would the CUDA language be a viable programming option? It is based in C, and was designed to utilize both a serial and parallel processor, which is what we have here with the ARM/Epiphany Parallella.

Thoughts?

[fmotta]