Clock not running (was Re: RTEMS4.7 and its tool chain (Re: powerpc mvme5500 clock off by factor of 150))

[Sergei Organov]

Till Straumann <strauman at slac.stanford.edu> writes:
> Sergei Organov wrote:
[...]
> not quite :-) -- the original statement modifies 'dec' (its value is used
> further down the line) so you would have to say
>
>   asm volatile("mtdec %0"::"r"(dec+=Clock_Decrementer_value));
>
> [just to make the point that cleaning up asms is in itself a tricky
> business].

That's my point as well, -- they shouldn't be there in the first place,
so that we don't need to even enter a tricky business ;)

> >
> >Better yet, should PowerPC port define:
> >
> >#define MFDEC(dec_) asm volatile ("mfdec %0": "=r" (dec_))
> >#define MTDEC(dec_) asm volatile ("mtdec %0": : "r" (dec_))
> >
> 
> You are right. However, in this particular case I wanted to make sure
> the update is as fast as possible since any lost cycles add up over
> time. If statements are split into multiple asm()s the compiler is
> free to reallocate registers and the generated code could (but
> probably will not) be suboptimal.

Yeah, I see the point. Poor PowerPC decrementer. Why didn't they
implement decrementer reload feature in the hardware is beyond my
understanding.

> 
> BTW: I should also have disabled interrupts around the update
>      to avoid the race condition [higher priority IRQ between mfdec
>      and mtdec].

Well, are interrupts enabled during exception processing by default?
That wasn't the case for the old_exception_processing. If it's so, I
find it rather strange decision.

-- 
Sergei.