Georg-Johann Lay wrote:
> oh, I was just misreading this table and thought that it means yet
> another 200 bytes atop of ultoa_invert (just demonstrating that
> it isn't worse than ultoa_invert).
>
> But it appears you are intending to drop ultoa_invert which is great!
*Whew*! No, I'm comparing i
> What consumes the other 8000 cycles? Arithmetic?
I gave a link to the code (which I haven't read either, so I'm not
blaming you), but I expect it's a combination of dealing with the TDC7200
time-to-digital converter chip (it's an SPI peripheral) and arithmetic.
The chip is a combination of a 10
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
On 19.12.2016 23:05, George Spelvin wrote:
Georg-Johann Lay wrote:
George Spelvin schrieb:
It is unfortunately one instruction longer than ultoa_invert:
textdata bss dec hex filename
188 0 0 188 bc ultoa_invert.o
190 0 0 190
I implemented the idea I had, of using mem_itoa with base 100
and then printing two digits.
Omitting the strrev code to make everything equal, mem_toa is 64 bytes,
and the modified decimal-only version I call mem_tod is 80 bytes.
u64toa_nibbles is 90 bytes.
(That's assuming a ret of the reversed
> 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 o
Georg-Johann Lay wrote:
> George Spelvin schrieb:
>> It is unfortunately one instruction longer than ultoa_invert:
>>
>>text data bss dec hex filename
>> 1880 0 188 bc ultoa_invert.o
>> 1900 0 190 be itoa_engine.
Longer reply coming; I'm benchmarking.
But the tl;dr is that damn it, you may be right and I've wasted several
days of effort. :-(
I can even shave a few cycles (and one instruction) off of your code.
At less than half the size and slightly better than half the speed,
it's hard to argue with.
Wh
George Spelvin schrieb:
tl;dr: Beta code included below; it passes my initial testing. I named
it _itoa_engine, following "ftoa_engine", but suggestions are welcome.
It is unfortunately one instruction longer than ultoa_invert:
textdata bss dec hex filename
188 0
tl;dr: Beta code included below; it passes my initial testing. I named
it _itoa_engine, following "ftoa_engine", but suggestions are welcome.
It is unfortunately one instruction longer than ultoa_invert:
textdata bss dec hex filename
188 0 0 188 bc ulto
If anyone wants to flex their asm-hacking skills, there's some draft
code here. If not, don't panic; this is primarily notes to myself
that someone else might be interested in.
To finish long long support in printf, I need to print 64-bit numbers
(preferably, arbitrary-precision numbers) in octal
11 matches
Mail list logo
