OT Ceckarsky kviz

[František Burian]

Pane kolego,

   K odkazu na kizarm ...

   Od chvíle kdy existuje std::embed můžete odstranit tu část s pythonem a generovat C++ header kódem dynamicky přímo z toho kódu který se kompiluje
(tzn již od GCC 10 lze vytvořit tu tabulku DAC plně ve flash během jediného překladu souboru). Doporučuju k prostudování, je to velmi zajímavá knihovna.
Používají to zejména grafici kteří takto během kompilace generují řezy 3D animací z jednoho zdrojového datového souboru popisujícího model a volají
to pak jako inline funkce, které optimalizátor dále optimalizuje (data se díky linkeru "rozprostřou" do celého kódu a vpodstatě nemáte šanci je zpětně
rekonstruovat. Takže budu teď nadšeně sledovat jak přibyde další bloček textu s pokračováním, sám to použít neumím, má architektura zatím nemá
GCC10 :o)

   Ještě bych doplnil že rozdí mezi kompilátorem a syntezátorem je, že kompilátor jen slepuje knihovny k sobě a nemusí rozumět obsahu (tedy
platformovým nuancím), kdežto syntezátor musí rozumět všem okrajovým vlastnostem každého datového typu dané platformy. C i C++ jsou "jen"
kompilátory, ano toto překvapilo i mě. Syntezátor je např VHDL/Verilog a díky tomu algoritmus zapsaný ve VHDL bude vždy optimálnější z mnoha kritérií
než ten v C (a apriori proto instalace kompilátoru C zabere stovky MB, ale ten z VHDL i desítky GB (všechny corner case všech typů a všechna řešení...).

   C je kompilátor a double je realizováno knihovnou (je závislé na platformě, všiměte si vfp3, neon, x86 má taky svou repre, knihovnu volíte argumentem
kompilátoru.) takže ono tvrzení "musí emitovat warning když dochází ke konverzi typu" není platné protože pro C je to jen objekt u kterého apriori kompilátor
neví že se ten typ někde mění (to dělá knihovna runtime). Existují pravidla, která můžou kompilátoru napovědět že se _asi_ bude měnit typ, ale jsou corner
case pro danou platformu které to bude platit a pro které ne. To je také důvod proč je výstup kódu floatů velmi neoptimální i po optimalizaci (ta jen rozbaluje
funkce ale nijak nereorganizuje kód protože nerozumí funkcím které nad fp dělají operace. Optimalizace je prováděna masivně jen nad load/store a dependency
tree).

   C++ se s template přibližuje hodně k syntéze (tam potřebuje přesně znát typy i s nuancemi), ale díky platformové závislosti double je vše
realizováno stále knihovnami takže platí viz výše. Všiměte si důsledek, float nesmíte použít jako argument template právě z důvodu knihovnosti.
(Tam může být jen int, nebo název typu který je platformově nezávislý)

   Výše uvedené není z mé hlavy, zrovna včera jsem byl na obědě s kolegou který v C/C++ normě leží a má přímé osobní kontakty na tvůrce -
zrovna o tom embed jsme se bavili, nepřímo jsme se k tomu dostali od toho "P" exponentu (power), který jsem také neznal.

   Mimochodem padl letopočet 2026 kdy se má změnit ABI kompilátorů a to bude noční můra protože nepůjdou spustit staré programy na novém železe
(.so/.lib/.dll soubory budou binárně jiné/nekompatibilní ). Mělo to být 2024 ale covid to posunul. Od toho roku to znamená nutnost rekompilace úplně všeho
aby to fungovalo (a že v linuxu těch balíků je ...). Změna je ale nutná protože jsou nyní vazby velmi neoptimální. Realita bude taková že budou dva operační
systémy a dvě verze knihoven a OS si zvolí virtualizací zdali pojede "postaru" nebo "ponovu" My v embedded máme smůlu, pokud nemáme zdrojáky knihoven
a tvůrce mezitím zkrachuje (nevydá ty s novým ABI) tak knihovny umřou. To je imho důvod toho tlaku na GPLv3, dopředná kompatibilita ...

S pozdravem,

   František Burian



Dne 27. 01. 22 v 14:46 Miroslav Mraz napsal(a):
> Zřejmě to závisí na překladači. V C++ jdou dělat i větší zvěrstva např.
>
> #include <stdio.h>
> #include <cmath>
> // Compile: clang++ -std=c++14 -Oz
> static constexpr double operator"" _deg (const long double arg) {
>   return arg * M_PI / 180.0;
> }
> // Velká písmena v názvu operátoru jsou vyhrazena ...
> static constexpr unsigned long operator"" _h (const char * const str, size_t n) {
>   unsigned long result = 0ul;
>   for (unsigned i=0u; i<n; i++) {
>     const char c = str [i] | '\x20';  // to lowercase
>     if ((c >= '0') and (c <= '9')) {
>       result *= 0x10ul;
>       result += c - '0';
>     } else if ((c >= 'a') and (c <= 'f')) {
>       result *= 0x10ul;
>       result += c - 'a' + 10;
>     } // ostatni znaky jako je '_' ignoruj
>   }
>   return result;
> }
> int main () {
>   // Tohle by mohlo mit nejaky smysl.
>   constexpr double  args [] = { 30._deg, 45._deg, 60._deg, 0.5 * M_PI };
>   for (auto & arg : args) ::printf ("sin (%f) = %f\n", arg, std::sin(arg));
>   // Tohle uz je docela pitomost, gcc (a jine) s tim bude mit problem, clang OK.
>   constexpr unsigned long n = "DEAD_beef_CAFE_babe"_h;
>   constexpr unsigned long m = 0xdEaDbEeFcAfEbAbE;
>   static_assert (m == n, "not equal"); // opravdu je to spocteno pri prekladu
>   printf("0x%lX\n", "hello world"_h);  // prevede se i nesmysl, ale proc ne
>   printf("%f\n", 0x1C2D.3EP4F);        // projde i tahle hruza - 115411.875
>   return 0;
> }
>
> V řádce s poznámkou "to lowercase" je možná odpověď na otázku proč je to někde case insensitive. Trochu to zkrátí kód parseru. Takže v C++ si můžete napsat 
> vlastní parser konstanty. Možná se to hodí na obfuskaci kódu, ale prakticky bych se tomu vyhnul, čitelnost kódu je pak dost bídná, obzvlášť když ty operátory 
> definujete někde v hlavičce na 10. úrovni zanoření.
> Připadá mi, že je lépe psát deg_to_rad (30.) jako funkci (která může být též constexpr) než operátor 30._deg. Sice se může zdát, že to takhle můžete napsat i 
> v C-čku, ale není tomu tak. Constexpr výrazy se vyhodnotí při překladu, takže výsledný kód tím není zaplevelen. Dají se s tím dělat různá kouzla 
> https://kizarm.github.io/constexpr/index.html, ale je to takové ... no divné.
>
> Mrazík
>
> Dne 27. 01. 22 v 14:19 Jan Waclawek napsal(a):
>> ...
>> A tiez pise, ze v C++ tie hexadecimal float konstanty nie su, ale to uz nie
>> je pravda lebo to pribudlo v C++17.
>>
>> wek
>>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list