<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Ten způsob s dělením 1e9, 1e8, ... 100, 10 jsem používal v minulém
století v assembleru na 486 a bylo tolepší. Ale na 8bitu mi přišlo
lepší nakonec odeslat byty v opačném pořadí, než generovat 32b
dělitele.<br>
Je samozřejmě možné, že to jde nějak optimalizovat, že to nakonec
bude stejně dlouhé, nebo kratší, zas tolik jsem to nezkoumal.<br>
<br>
Ale zrovna včera jsem dělal overloady na další datové typy a tam je
pak jasná výhoda dělení 10, že celý vnitřek funkce m;že být úplně
stejný pro 8, 16 i 32b.<br>
<br>
Mimochodem, vedlejší produkt včerejška je, že když je verze pro long
a unsigned long, je lepší v signed obrátit znamínko a zavolat
unsigned. Dokonce i když unsigned není jinak použitej.<br>
<br>
PH<br>
<br>
<div class="moz-cite-prefix">Dne 23.04.2024 v 8:53 Jan Waclawek
napsal(a):<br>
</div>
<blockquote type="cite"
cite="mid:PC1993202404230853590037cb0fdc60@wekovci">
<pre class="moz-quote-pre" wrap="">[preposielam]
Ahojte,
temu ste uz sice vycerpali ale predsa sa ku nej este v kratkosti vratim. Ja
som svojim sposobom trochu sahnuty a snazil som sa formatovany vystup
naprogramovat do malych PIC s 4kW a 256 bytov RAM-ky. Musim povedat, ze to
bolo pekne mentalne programatorske cvicenie. Musel som optimalizovat naozaj
vsetko, vratane pristupu do tabuliek vo Flash pamati kontrolera. Bolo to
sice len nejakych cca.10 instrukcii z kompilatora, ale aj to vo
finale urobilo svoje. Pokial sa dobre pamatam, tak mi to vyslo tesne nad
2kW, takze sa to uz do tych najmensich PIC nevmestilo. Tu by som sa chcel
spytat, preco vsetci robite konverziu od najmensej mocniny 10 a nie od
najvacsej mocniny? Myslim si, ze to ma zopar vyhod pri dalsom spracovani
retazca resp. pola tych znakov. A na formatovanie staci pouzit algoritmy,
ktore tu spomenul p.Labaj, teda prehladavanie hrubou silou na iste znaky a
jednoduche posuvanie retazca. Rozhodne ten kod nema 600 riadkov ako ta
nizsie spomenuta kniznica, ale zase je len na signed int a unsigned int, a
to este s osekanym rozsahom na -999...9999. Plus nastavenie
desatinej bodky. Ja to mam urobene takto, a bohato mi to staci na velku
cast vypisov na displej.
A.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Jeste stoji za zminku, ze resit usporne printf pro MCU uz napadlo
spoustu lidi a je ke stazeni mnoho projektu, ktere lze ruzne
parametrizovat atd. Namatkou napr. GitHub - mpaland/printf: Tiny, fast,
non-dependent and fully loaded printf implementation for embedded
systems. Extensive test suite passing. <a class="moz-txt-link-rfc2396E" href="https://github.com/mpaland/printf"><https://github.com/mpaland/printf></a>
Ja bych to printf s formatovanim uplne nezavrhoval, je to velmi
prakticke a flexibilni a s rozumnou implementaci a orezanim slozitejsich
formatu to neni nijak narocne na prostredky.
Cpat to do 4kB flash a 256B RAM je samozrejme blbost ale u attiny s
16/2kB uz jsem se nejak moc neomezoval.
Dne 20.04.2024 v 18:28 Petr Labaj napsal(a):
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">* Za sebe můžu říct, že se mi to Vaše pojetí s formátovacím řetězcem líbí.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">*>* Asi bych tam trochu šetřil s buffery, ale to je drobnost.
*>>* Já to skládám 3 voláními (text, číslo, text), ale takhle je to docela
*>* elegantní.
*>>* PL
</pre>
</blockquote>
</body>
</html>