Re: [avr-libc-dev] Printing octal (brain dump)

[Georg-Johann Lay]

On 20.12.2016 00:51, George Spelvin wrote:
> > Is 8000 ticks too slow?
> >
> > Is 3000 ticks acceptable? And for what reason? Are 3000 acceptable just
> > because we have an algorithm that performs in 3000 ticks?
> >
> > My strong preference is still to have a one-fits-all algorithm that
> > might very well be slower than an optimal one.  But hey, an ordinary
> > division of a 64-bit value by 10 already costs 2300 cycles, so why
> > should we hunt cycles just for printf...?
>
> Well, I went and asked the customer.
>
> As I mentioned, the motivating application is the TAPR time interval
> counter (TICC).
> Info:   http://tapr.org/kits_ticc.html
> Source: https://github.com/TAPR/TICC            (Not up to date.)
> Manual: http://www.tapr.org/~n8ur/TICC_Manual.pdf
>
> Basically, it timestamps input events to sub-nanosecond resolution.
> It prints them with picosecond (12 decimal place) resolution.
>
> E.g. fed a 1 Hz input signal, it might print:
>
> 104.897999794440
> 105.897999794492
> 106.897999794549
> 107.897999794551
> 108.897999794553
> 109.897999794552
> 110.897999794667
>
> It would like to be able to run until 2^64 picoseconds wrap around in
> 213 days.

Just out of interest:  Isn't this overflow a problem? Hence isn't a
different representation warranted that doesn't overflow so soon?

> Anyway, although it only prints every input transition, the main
> processing loop has a 1 ms schedule to meet (it *can* print at up to
> 1 kHz, synchronized with the USB polling interval), and of the 16,000
> clock cycles available in that ms, 8000 are currently spoken for.
> 8000 are available for formatting and output device drivers.
>
> So yeah, they'd definitely prefer 4000 cycles to 8000.
>
> But they're going to use custom code *anyway*, since they don't want
> to wait for an avr-libc release, so that doesn't have to determine what
> avr-libc does.

IMO that's a sound approach -- not only because of avr-libc release
schedule but also because you actually have to guarantee some upper
bound for the execution time (of conversion etc.).

What consumes the other 8000 cycles? Arithmetic?

Johann