Re: [avr-gcc-list] using exceptions

[Weddington, Eric]

> -----Original Message-----
> From: address@hidden [mailto:avr-
> address@hidden On Behalf Of David
> Brown
> Sent: Wednesday, May 02, 2012 8:29 AM
> To: Gabriel Dos Reis
> Cc: address@hidden
> Subject: Re: [avr-gcc-list] using exceptions
> 
> 
> 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.
> 

Hi David,

I understand your sentiment, but I'll ask you to pull up and look at it from a 
higher point of view.

We're talking about university students and research projects. It does NOT have 
to be efficient. They're working on something new. It's the nature of research 
projects to try and find out what are the issues. Maybe they'll discover what 
needs to be done to make it efficient. Who knows? The important thing is 
letting this discovery process happen.

As engineers, working in industry, we are keenly aware of working with multiple 
constraints and an economic end goal. We know that there are multiple ways of 
doing things, but few correct ways of doing things, given the nature of our 
problems and our goals. University research projects are not beholden to that. 
But in that process, they may discover something new that will help later. At 
the very least, it will be a learning experience for them. :-)

But you bring up interesting points:

- Could C++ on AVR be improved to a point such that function programming 
libraries will work well in such an environment?

- Could Lua be made to work on an AVR?

- Could OCAML be made to work on an AVR?

All of these could be interesting projects. Part of the interest is in making 
it work on such a constrained environment like an 8-bit AVR processor.

Don't forget that someone recently got Linux running on AVR (via an ARM 
emulator on the AVR). That's pretty darn cool! Is it practical? Hell, no! But 
why else do we climb mountains? Because it's there!

Eric Weddington