Re: [avr-gcc-list] using exceptions

[David Brown]

On 01/05/2012 17:18, Gabriel Dos Reis wrote:
> My recent interests in AVR grew out of educational and research
> activities -- as I explained in a relatively recent post on libstdc++.  I am
> still learning AVR and its toolsets but I can definitely help with the C++ part.
>
> We are in the situation where we would like to compile a restricted
> subset of Haskell to AVR via C++ intermediate codes.
>
> I will have a look at PR50925.
>
> -- Gaby

I can't help wondering in all this - is it worth the effort?  Are people 
/really/ going to program in Haskell for the AVR?  Don't get me wrong 
here - I like functional programming, and would prefer to be able to do 
more of it.  It is a programming style which lends itself to provably 
correct programming, and can give you small and neat code for many types 
of tasks.  When programming on a PC in Python, I make heavy use of list 
comprehensions, lambda functions, decorators (which use functions as 
first-class objects), etc.

But on the AVR?

I can't help wondering what sort of tasks on the AVR are better coded in 
Haskell than C (or C++).  And I can't help thinking that any Haskell 
program with real functionality would be terribly inefficient on an AVR. 
 Functional programming languages have never been known for their 
efficiency, or their predictability in timing (lazy evaluation is 
wonderful - but it doesn't really fit in the real-time world).  And the 
AVR has an 8-bit cpu, very little ram, and slow and limited pointer 
registers.  Yes, you can use Haskell to make an LED blink - but can you 
do so without using most of the memory and processor capacity?


Maybe there are alternatives that could give a better compromise, such 
as OCAML (I haven't used it much, but the combination of functional and 
imperative programming support apparently gives very efficient compiled 
code, at least on 32-bit cpus) or Lua (it's an interpreted language, but 
good for embedding - although I've only used it on 32-bit cpus).

Another option may be to get C++ on the avr so advanced that lambda 
functions or functional programming libraries work with avr-gcc.


And while I hate to discourage someone helping to improving avr-gcc, I 
have to wonder if it would not make more sense to use a different 
platform, such as a Cortex-M4 with perhaps a hundred times the 
processing power for this sort of thing.

mvh.,

David