|
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: 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
[Prev in Thread] | Current Thread | [Next in Thread] |