Hi all,

Quick plug: avrpy version 0.0.3 released:
http://www.ecs.soton.ac.uk/~jb1403/projects/avrpy/
Now supports argument-less functions!

Thanks for all the feedback. Whilst I haven't invested a huge amount of
time in optimisation, it currently seems to generate fairly optimal
code (very few unnecessary movs, etc). I'm aware that there is another
league of optimisation entirely (cunning encoding of loops (swapping
increments for decrements), branch optimisation, removing various other
redundancies) which I have not considered, but one aim of the compiler
is to be as transparent and simple as possible.

I would like this project to remain simple and approachable by anyone,
and form a simple basis for education and also quick-hack-togethers.
Adding macros, for example, is currently incredibly easy, and I am
considering adding a fake-OO layer for doing things like ADC reading:

adc = AVR.ADC(0)
x = adc.read()

which would make x a pseudo-variable (it would enter the symbol tables,
but never reach the actual variable-register-allocator, and all the
method calls would be translated as macros).

I am also building a simple IDE which incorporates a syntax
highlighting editor, the python compiler (and hopefully some useful
error feedback), the 'avra' assembler, and 'avrdude' programmer,
allowing a very easy introduction to microcontrollers.

I would welcome your feedback, i.e. whether you see this as of any use,
and any other fun ideas.

Jonny Barker

Antti wrote:
> nono!
> 
> GCC is not very optimizing compiler, a very clever python to machine
> code translation would always produce better code then the path via C
> compiler. Sure it depends how optiming the python compiler is.
> 
> I was the first one to have a AVR compiler (was published 30 days after
> first AT90S1200 - at that time it was the only compiler for AVR) - my
> compiler with bad name "AVR basic compiler" is capable to produce more
> compact code than assembler - do to iterative multipass branch
> optimizing
> 
> Antti
> 

gcc is actually a pretty good optimizing compiler these days.  But the 
point is not that gcc is an ideal compiler, or that it would not be 
possible to write a better one, but that it is unlikely to be worth the 
effort for the OP to write a better one.  It would take a great deal of 
work to do better, and I'd be surprised if that's really how he wanted 
to spend his time on this project, rather than on the front-end python 
stuff.  Writing a code generator can be fun too, so it really depends on 
what he is interested in.

Another thing to remember is that part of what limits the effectiveness 
of a C compiler is that C code is generally written by humans, in a way 
that is legible and maintainable (or should be!) by humans.  When using 
C as an intermediary language, you are free to use dirty tricks like 
gotos and labels, huge functions spanning thousands of lines, a single 
source file so the compiler can optimise better, and so on.

mvh.,

David

nono!

GCC is not very optimizing compiler, a very clever python to machine
code translation would always produce better code then the path via C
compiler. Sure it depends how optiming the python compiler is.

I was the first one to have a AVR compiler (was published 30 days after
first AT90S1200 - at that time it was the only compiler for AVR) - my
compiler with bad name "AVR basic compiler" is capable to produce more
compact code than assembler - do to iterative multipass branch
optimizing

Antti

Jonny Barker wrote:
> Hi all,
> 
> I've been working on a simple python 'compiler' targetting the AVR
> (inspired by Pyastra, the equivalent PIC program).
> 
> The (rather bare) website is here:
> http://www.ecs.soton.ac.uk/~jb1403/projects/avrpy/
> 
> The code is fairly simple (though my tarballing skills leave much to be
> desired), and produces surprisingly clean assembly (optimal in many
> simple cases), though it only attempts a very bare subset of python, or
> rather some-simple-register-poking-programming-language with the same
> syntax as python.
> 
> I hope to implement functions and proper variable scope in the next few
> days, as well as a simple IDE to make it useful for teaching kids how
> to program microcontrollers. A high-level simulator should be possible
> in the python interpreter itself, by overriding a few __setitem__
> calls, which would then display the port state and allow interrogation
> with a simple GUI.
> 
> All of the interesting code resides in the 'avrpy' module, bundled are
> a load of half-finished python experiments, and some simple examples.
> 
> I'd appreciate feedback and suggestions, I hope to get this usable by
> the end of March for programming mini uC-controlled robots!
> 
> Jonny Barker
> 

As a fan of python for PC programming, and an embedded programmer by 
profession, I'm always interested in ports of python to embedded 
systems, or any other alternative to C.  However, I think the idea of 
generating AVR assembly from python code is not really a useful 
exercise.  What would, I think, make far more sense is to generate C 
code from python, and pass that through an avr C compiler (avrgcc would 
be an appropriate choice, but ideally any avr C compiler could be used). 
  The advantages with this approach are that you can concentrate on the 
interesting python-specific front-end, you will get far better code out 
of the system (unless you are willing to spend a great deal of time 
writing optimisers - the C compiler writers have already done that 
work), debugging will be easier, and it will be far easier to use the 
same system on other microcontrollers rather than just the AVR. 
Additionally, you might find that projects like Pyrex can be a head-start.

Good luck anyway,

David

"Jonny Barker" <jb1403@zepler.net> skrev i meddelandet 
news:1141170261.411341.124200@t39g2000cwt.googlegroups.com...
> Hi all,
>
> I've been working on a simple python 'compiler' targetting the AVR
> (inspired by Pyastra, the equivalent PIC program).
>
> The (rather bare) website is here:
> http://www.ecs.soton.ac.uk/~jb1403/projects/avrpy/
>
> The code is fairly simple (though my tarballing skills leave much to be
> desired), and produces surprisingly clean assembly (optimal in many
> simple cases), though it only attempts a very bare subset of python, or
> rather some-simple-register-poking-programming-language with the same
> syntax as python.
>
> I hope to implement functions and proper variable scope in the next few
> days, as well as a simple IDE to make it useful for teaching kids how
> to program microcontrollers. A high-level simulator should be possible
> in the python interpreter itself, by overriding a few __setitem__
> calls, which would then display the port state and allow interrogation
> with a simple GUI.
>
> All of the interesting code resides in the 'avrpy' module, bundled are
> a load of half-finished python experiments, and some simple examples.
>

Maybe you can get hold of the AVR Studio SDK (Software Development Kit)
This would allow you to extend AVR Studio with your tool, in a similar way
to the GCC plugin.

> I'd appreciate feedback and suggestions, I hope to get this usable by
> the end of March for programming mini uC-controlled robots!
>



-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB 

Hi all,

I've been working on a simple python 'compiler' targetting the AVR
(inspired by Pyastra, the equivalent PIC program).

The (rather bare) website is here:
http://www.ecs.soton.ac.uk/~jb1403/projects/avrpy/

The code is fairly simple (though my tarballing skills leave much to be
desired), and produces surprisingly clean assembly (optimal in many
simple cases), though it only attempts a very bare subset of python, or
rather some-simple-register-poking-programming-language with the same
syntax as python.

I hope to implement functions and proper variable scope in the next few
days, as well as a simple IDE to make it useful for teaching kids how
to program microcontrollers. A high-level simulator should be possible
in the python interpreter itself, by overriding a few __setitem__
calls, which would then display the port state and allow interrogation
with a simple GUI.

All of the interesting code resides in the 'avrpy' module, bundled are
a load of half-finished python experiments, and some simple examples.

I'd appreciate feedback and suggestions, I hope to get this usable by
the end of March for programming mini uC-controlled robots!

Jonny Barker