Re: [avr-gcc-list] Telling inline asm that input register is clobbered?

[Paul Sokolovsky]

Hello,

On Mon, 10 Dec 2012 17:34:36 +0100
Georg-Johann Lay <address@hidden> wrote:

[]

> Besides that, using design-pattern "delay" for anything else than
> short delays to wait for, say, parasitical capacities /
> inductivities, can be considered as a design flaw.  But that's a
> different story...
> 
> Sorry, I cannot help you with dreaded [tm] languages like C++ ;-)
> 
> Maybe __builtin_avr_delay_cycles is too limited with the const
> delays.  Using variable delays is possible if the requirement of
> cycle-exactness is dropped.

What I'm trying to do is implement cross-MCU metaprogramming library
which would provide users inventory of basic primitives and patterns
and allow to freely combine them in any ways, while maintaining clean,
consistent, scalable syntax/API and achieving close to assembly
efficiency (all that again across number of CPUs/MCUs). So, there would
be all (and more) of:

StaticDelay::delay() for cycle-perfect constant delays
DynamicDelay::delay() for dynamic loop delays
TimerDelay::delay() for timer-based delays

Then user can superimpose physical-timedness on top of those primitives:

TimedDelay<FrequencyEncapsulator, StaticDelay>::delay_ms()

Where FrequencyEncapsulator is an entity which knows the current
frequency, and can be anything from static number to a routine to query
hardware for current frequency in effect.

Such magic are simply not doable in "classical" C at all. Now if we
assume that inlining is C (as in C99, how many people think of inlining
as C feature vs GCC extension?) thing after all, some subset of that
magic might be doable, but syntax would be more cumbersome and some
limit would be hit soon for sure (C++ does aggregate type
inference/management, which C doesn't). So yep, I reached for C++
after not touching it seriously for around 10 years...


> > So, I started another try on ldi-based approach, and just got lucky
> > that my test code had "good" value of literal integer constant.
> > Because it turned out that "M" asm constraint is very picky
> > regarding value it gets. One would think that casting to uint8_t
> > would be the best way to get a value suitable for it, but actually,
> > that will throw "error: impossible constraint in ‘asm’" for any
> > value >=0x80. Fortunately, I found that (& 0xff) does the trick, so
> > mission accomplished.
> 
> The question is why you use "M" in the first place and not "n"?

Googling led me to
http://www.nongnu.org/avr-libc/user-manual/inline_asm.html , and after
checking that this list is also hosted on nongnu.org, I thought it's
the authoritative manual. And it doesn't list "n". Is there more
up-to-date avr-gcc manual?


Thanks for all other suggestions! My current implementation is at
https://github.com/pfalcon/PeripheralTemplateLibrary/blob/master/include/delay_static_avr.hpp
(not yet cycle-perfect, but that's doable, I have that for MSP430).


-- 
Best regards,
 Paul                          mailto:address@hidden