On 02/05/2012 17:03, Weddington, Eric wrote:
-----Original Message----- From:
avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org
[mailto:avr- gcc-list-bounces+eric.weddington=atmel....@nongnu.org]
On Behalf Of David Brown Sent: Wednesday, May 02, 2012 8:29 AM To:
Gabriel Dos Reis Cc: avr-gcc-list@nongnu.org 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
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
