About udelay

[Programmingkid]

I see that you used a loop to simulate a wait time. I think there must be a better way of doing it. Doesn't the Sparc emulator have access to a hardware clock that we can use instead of a loop?

[Lennart Sorensen]

On Fri, May 03, 2013 at 05:50:39PM -0400, Programmingkid wrote:
> I see that you used a loop to simulate a wait time. I think there must be a better way of doing it. Doesn't the Sparc emulator have access to a hardware clock that we can use instead of a loop?

I would have thought the compiler was allowed to optimize away a loop
that incremented something that noone ever looks at.  It doesn't do
anything after all.

[Mark Cave-Ayland]

On 03/05/13 22:54, Lennart Sorensen wrote:
> > I see that you used a loop to simulate a wait time. I think there must be a better way of doing it. Doesn't the Sparc emulator have access to a hardware clock that we can use instead of a loop?
>
> I would have thought the compiler was allowed to optimize away a loop
> that incremented something that noone ever looks at.  It doesn't do
> anything after all.

Fortunately the use of the "volatile" quantifier in the patch makes sure 
that this doesn't happen. Both myself and Artyom have tested the patch 
and it works for both of us, so I'm reasonably confident.

The reason that the udelay() implementation is a trivial one is because 
we need something simple in order to get a working OpenBIOS (and 
hopefully 1.1 release) into QEMU git master in time for feature freeze 
on Monday. If anyone else would like to investigate using timers for 
udelay() on SPARC32/64, I'd be very happy to accept patches from next 
week onwards.

ATB,

Mark.

[Lennart Sorensen]

On Fri, May 03, 2013 at 11:07:24PM +0100, Mark Cave-Ayland wrote:
> Fortunately the use of the "volatile" quantifier in the patch makes
> sure that this doesn't happen. Both myself and Artyom have tested
> the patch and it works for both of us, so I'm reasonably confident.

Oh yes of course.  I missed that detail.  Oops.
> The reason that the udelay() implementation is a trivial one is
> because we need something simple in order to get a working OpenBIOS
> (and hopefully 1.1 release) into QEMU git master in time for feature
> freeze on Monday. If anyone else would like to investigate using
> timers for udelay() on SPARC32/64, I'd be very happy to accept
> patches from next week onwards.

Makes sense now.