[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] using exceptions

From: David Brown
Subject: Re: [avr-gcc-list] using exceptions
Date: Wed, 02 May 2012 17:18:46 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0

On 02/05/2012 17:03, Weddington, Eric wrote:

-----Original Message----- From:
[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

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

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]