Re: [avr-gcc-list] using exceptions

[David Brown]

On 02/05/2012 17:03, Weddington, Eric wrote:
> > -----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.

I understand that.  For students, it is the learning process that is 
important - not the usefulness of the work for the future or for other 
people.  But if it is possible to change direction slightly and do 
something that promotes learning /and/ is useful, then it's a win for 
everyone.  Of course, it's important that they don't focus too much on 
practicality and usefulness - as you say, the real discoveries come when 
messing around rather than being too focused.  (If we knew what we were 
doing, we wouldn't call it "research" :-)

> 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.

I agree with what you are saying.  I'm just trying to suggest that 
getting Haskell to work on the AVR is more akin to getting Linux to work 
on the AVR - while perhaps Lua, OCAML, more C++, or other options might 
be a better balance.  I also think they might be more likely to work - 
it would be a shame for the students to spend ages getting all the bits 
in place for Haskell on the AVR, only to find out that their quicksort 
example program runs out of memory with more than 4 elements.

> 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

Someone else got Linux running natively on a Cortex-M3 - that's cool and 
a least a bit practical.  Not as cool as running it on an AVR, and not 
as practical as porting eCOS, but perhaps an interesting compromise.

I don't disagree with you on any of your points - I just want to be sure 
that Gaby knows what he is getting into here, and that his time and 
effort is well spent.

mvh.,

David