Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Jiří Havel

Stran: [1] 2 3 ... 28
1
Vývoj / Re:Rozdíl mezi ASM a strojovým kódem
« kdy: 19. 03. 2026, 10:16:36 »
Váš kousek kódu může mít nedefinované chování kvůli aliasingu.
A to prosím kde/jak?
Tohle
Kód: [Vybrat]
uint32_t x = 1;
uint8_t *p = (uint8_t  *)&x;
je ok jen pokud je uint8_t typedef na unsigned char. C zaručuje jen to, že uint8_t je nějaký 8b int. Že je to character, který může aliasovat, zaručené není.

Dlouho byl unsigned char jediný standardní typ, na který ten typedef mohl rozumně vést. Ale C23 přišlo s _BitInt. To už zní dost lákavě na to, aby tou cestou někdo zkusil jít. Protože díky tomu aliasingu se uint8_t hůř optimalizuje.
Třeba tady kdysi probírali, jak by se dalo uint8_t oddělit od charu:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110

Jo, jsou to hypotetické obavy. Ale tak je to s UB v C vždycky. Lepší optimalizátor začne využívat další možnosti a najednou se to rozbije.

2
Vývoj / Re:Rozdíl mezi ASM a strojovým kódem
« kdy: 17. 03. 2026, 08:04:08 »
Tak jakto že The C Programming Language od Kernighana a Ritchieho z roku 1978 zmiňuje preprocesor?
Zmiňuje preprocesor jako separátní tool. Těsnější integraci udělal AFAIK až clang. Pořád si pamatuju ten kvalitativní skok v chybových hláškách, když překladač najednou mohl vypsat i jména maker.

Některé lovy bugů si pamatuju fakt dobře, protože byly fakt drsné. Překladač vidí úplně jiný kód než vy a preprocesor vás ubije k smrti kvanty textu.
Citace
To je prosím celá mrtě logika, která je potřeba pro detekci endianity buildtoolem - ten checkne návratový kód.
...
Nee, ta logika je celý ten autotools ansábl, který ošahává překladač aby tím mohla nakrmit preprocesor.

Je to takové Cčkovské. V C můžeš udělat cokoliv, stačí když to celé uděláš sám. C ti hlavně nastaví vidle.

Přeložit a spustit testovací kousky programu a výsledkama nakrmit preprocesor by šlo použít u jakéhokoliv jazyka. C v tom figuruje jen tím, že nikde jinde takovéhle divočiny nepotkáte. Protože to dává smysl jen když nic lepšího není k dispozici.

C je všude, protože je navržený tak, aby se pro něj jednoduše psaly překladače. Všechno ostatní je tomu podřízené.
Citace
Linux je nejpřenositelnější OS jaký existuje :D No a nemyslím si že používají GCC kvůli tomu že by C nebylo přenositelné.
 Inline assembler je spíše praktická věc pro OS kód. Různé builtin funkce jsou spíše optimalizační techniky. Makro typeof zase umožňuje generičtější kód, což jenom šetří psaní... dalo by se bez toho všeho obejít. Které věci z GCC dialektu jsou striktně kvůli přenositelnosti bez kterých by se nedalo obejít?
Dialekt není jen o rozšířeních. Je třeba i o zalepeném nedefinovaném chování. Váš kousek kódu může mít nedefinované chování kvůli aliasingu. Ve standardním C by se to muselo napsat jinak. Ale autotools samozřejmě řeší přenositelnost jen v rámci gnu světa.

3
Vývoj / Re:Rozdíl mezi ASM a strojovým kódem
« kdy: 13. 03. 2026, 11:13:36 »
to mi pripomelo kompilator, ktery generuje pouze move instrukce.

https://github.com/xoreaxeaxeax/movfuscator
Ten "single instruction" nadpis otvírá zajímavou teoretickou otázku, "Co je to vlastně ta 1 instrukce?"

Protože ten mov má hromadu variant, co dělají i docela odlišné věci. Už jenom "load" a "store" jsou tak odlišné věci, že pro to mají některé architektury různé instrukce.

4
Vývoj / Re:Rozdíl mezi ASM a strojovým kódem
« kdy: 13. 03. 2026, 09:10:11 »
Případně přenositelnost, kdy stejná instrukce na jiném procesoru má jiný kod.

Teoreticky ano, prakticky o tom silně pochybuju, nebo by muselo jít o dost omezený kousek kódu.

Nemá moc smysl dělat procesor se stejnou instrukční sadou, ale jinými opcodes. Když už stejná instrukční sada, tak lze docela čekat i stejné opcodes.
Čistě teoreticky by se tady dala vytáhnout rodina x86 procesorů. Kdy stejné instrukce assembleru můžou být zakódované pomocí mnoha různých opkódů. A staré procesory umí některé, které už nové neumí a naopak.
Ale prakticky se pořád mluví o x86 instrukční sadě. :)

5
Vývoj / Re:Rozdíl mezi ASM a strojovým kódem
« kdy: 13. 03. 2026, 08:53:17 »
A jak souvisí překladač, platforma, verze a nebo název makra s tím jestli je jazyk přenositelný? Toto makro má nakonfigurovat build systém a předat ho překladači.

V režii jazyka už pak je jenom podmíňěná kompilace na tu nebo onu variantu.
...
Tu podmíněnou kompilaci ale nedělá jazyk C ale C preprocesor. Je to separátní tool, který ani nerozumí kompletní syntaxi C a používá se i pro jiné jazyky. Integrace preprocesoru do překladače proběhla až relativně nedávno, protože to oddělení mělo nepříjemné důsledky na použitelnost.

Ve chvíli, kdy build systém chystá makra pro preprocesor, tak je přenositelný úplně každý jazyk. Abych dostal to makro ENDIANESS tak musím mít někde mrtě platformně závislé logiky. Protože sám jazyk C v tom pro mně neudělá ani ň.

Btw, drtivá většina C kódu není přenositelná, ale je psaná v nějakém platformně závislém dialektu. Je to proto, že v přenositelné podmnožině C chybí naprosto zásadní věci. Např linux není psaný v C ale v GCC dialektu a při portování do clangu se do něj ten GCC dialekt přidal.

6
Vývoj / Re:Rozdíl mezi ASM a strojovým kódem
« kdy: 12. 03. 2026, 12:54:01 »
Na to stačí jednoduchý #ifdef
případně runtime detekce se dá udělat taky, jak pro endianitu, tak pro dvojkový doplněk.
K ostatnímu se nebudu vracet, ale ten jednoduchý ifdef třeba na endiany bych chtěl vidět. Normálně potkávám několik obrazovek ifdefů, protože každý překladač, platforma a občas i verze mají ty makra nějak jinak.

7
Vývoj / Re:Rozdíl mezi ASM a strojovým kódem
« kdy: 11. 03. 2026, 10:58:53 »
Teprve jazyk C vyřešil přenositelnost.
V rámci možností. Pokud člověk například nepotřebuje vědět, jestli char je signed nebo unsigned. Nebo jak velký je int. Viz nedávné flame vlákno o bit shiftování signed intu.
To jsou zase plky :D
Pokud někdo potřebuje zajistit přesnou velikost typu přenositelným způsobem, tak na to je knihovna <stdint.h>, která je součást standardu.
Otázka do flamu. Pokud použiju separátní tool (který ani nezná kompletní syntaxi C) abych jím lepil platformně závislé kousky textu dohromady, můžu ještě mluvit o přenositelném jazyce? Protože s preprocesorem tak jde psát přenositelně i assembler.
A věci jako endiany nebo jestli mám vůbec dvojkový doplněk se zjišťují hůř. Ty jako makro naservírované nedostanu.
Citace
Jestli je něco signed nebo unsigned jazyk definuje taky - že to pak nějaký kompilátor overridne je druhá věc.
Tak zrovna u charu je to "implementation defined". Takže jazyk C definuje jen to, že to kompilátor "overridnout" prostě musí.
A proto jsou taky "char", "signed char" a "unsigned char" 3 různé typy (aby to nebylo nudné jako u intů). :)
Citace
A bit shift signed intu je prostě UB, tak shiftuj unsigned a taky máš přenositelný program.
Ano, v C se dá psát přenositelný kód. Ale protože je to jazyk z punkových časů, tak toho ta přenositelná podmnožina až tak moc neumí. A málo šedivé programátory to může překvapit, protože spousta těch věcí z dnešního pohledu už fakt nedává smysl.

A abych přispěl i k původní otázce, tak rozdíl mezi assemblerem a strojákem nemusí být jen ty symbolické adresy. U DSPček (myslím že to bylo nějaké TMS320) jsem potkal i to, že pipeline nebyla maskovaná. Instrukce ve strojáku byly v pořadí v jakém se cpaly do pipeliny, ne v jakém se nakonec vykonaly. Takže assembler i přerovnával instrukce (podle latence + přidával potřebné nopy) z lidsky čitelného pořadí do toho jejich hnusnopekla.

8
Studium a uplatnění / Re:Ako ste sa stali seniorom?
« kdy: 10. 03. 2026, 13:10:53 »
Vždycky jsem si myslel, že senior je někdo, kdo zná tři tech stacky od základu a umí navrhout architekturu projektu během půlhodinky mezi meetingama, ale jak mi Vás tak poslouchám, tak stačí bejt medior se znalostí projektu.
Nee, senior je někdo, kdo ví jak takové rychlokvašené návrhy obvykle dopadají. ;)

9
/dev/null / Re:Nechali byste si do mozku implantovat čip?
« kdy: 09. 03. 2026, 12:33:14 »
Možná tě překvapím tvrzením, že již v roce 2000 měla jedna renomovaná firma hotový čip do hlavy a byla připravena ho masově vyrábět. Od té doby uplynulo již 25 let. Takže předpokládám, že technologie hodně pokročila.
Pokud už uplynulo 25 let a stále nic, tak to asi tak úplně připravené nebylo ::) BTW "jedna renomovaná firma" zní, jako byste opravdu nechtěl, aby to někdo googlil ;)

Na Googlu to asi nenajdete. Takže to řeknu přímo. Šlo o firmu Intel. Čip měl sloužit k ovládnutí člověka a nikoliv ke komunikaci atd. Čip měl být do lidí implantován nařízením s odůvodněním, že jde o identifikační čip a ještě něco, co si již nepamatuji. Zjistilo se však, že by to lidi nepřijali. Krom toho testovací lidi s tím čipem měli zdravotní problémy - časté a intenzivní bolesti hlavy atd.

Dnes se čipuje všechno možné: identifikační průkazy, zvířata, zboží v obchodech a dobrovolně lidi, co to chtěj.

Ovšem čipovat lidi se slibem, že z nich budou nadlidi s lepšími schopnostmi, je zvěrstvo.
Jo takhle, už začínám chápat odkud vítr fouká  ;D

10
/dev/null / Re:Nechali byste si do mozku implantovat čip?
« kdy: 09. 03. 2026, 11:47:41 »
Možná tě překvapím tvrzením, že již v roce 2000 měla jedna renomovaná firma hotový čip do hlavy a byla připravena ho masově vyrábět. Od té doby uplynulo již 25 let. Takže předpokládám, že technologie hodně pokročila.
Pokud už uplynulo 25 let a stále nic, tak to asi tak úplně připravené nebylo ::) BTW "jedna renomovaná firma" zní, jako byste opravdu nechtěl, aby to někdo googlil ;)

11
/dev/null / Re:Nechali byste si do mozku implantovat čip?
« kdy: 09. 03. 2026, 07:40:48 »
Vypadá to, že mozkové implantáty jsou již připraveny k masovému použití. Budou umožňovat čtení myšlenek, ovládání hardwaru myšlenkami, komunikaci mezi čipy a též komunikaci s centrální umělou inteligencí.

Přes všechny takovéto "výhody" bude mít čip i schopnost ovládat myšlení lidí, což se však nepropaguje. Když si ale spojíte oba dva zmíněné odstavce, bude vaše představa úplná.
Spíš to vypadá jako leštěné marketinkové pšouky, ale skutek zatím těžce utek.

12
Sítě / Re:Funguje někomu u O2 reverzní záznam?
« kdy: 26. 02. 2026, 07:38:25 »
Jinak to zdražování o 50 Kč by se u O2 mělo týkat jen pomalejších tarifů, takže řešením by mělo být zrychlit si připojení na 1000 Mbps (což je samozřejmě je dražší než pomalejší tarify, ale ne o moc - např. oproti zdraženému 500 Mbps je 1000 Mbps dražší jenom o 50 Kč).
Řešit zdražení o 50 tím, že misto toho dostanou navíc 100? To mi něco připomíná :)

13
Sítě / Re:Funguje někomu u O2 reverzní záznam?
« kdy: 25. 02. 2026, 10:12:01 »
IPv6 stále nefunguje a teď přišlo, že zdražují o 50Kč. >:( Aby je čert vzal.
Taky mi přišlo že zdražují o 50. Akorát až po tom, co jsem vypověděl smlouvu, protože předtím už jednou zpomalili a zdražili potichu.
A když jsem jim řekl cenu od konkurence, tak se mě snažili přesvěčit abych zůstal a platil jim dvojnásobek. ::) Ta firma je prostě úžasná...

14
Vývoj / Re:Vhodna AI na programovanie (pre neprogramatora)
« kdy: 19. 02. 2026, 11:53:36 »
Já i manželka oceňujeme věci, co vydrží sto let. Tak těžký ten stůl zase fakt není :D
Tak já myslím masivní stůl co opravdu masiv a hlavně jde na něm vidět řemeslo a ne masiv co se kupuje v marketu.
Takový na který jsou potřeba dva chlapi.
Nevím, normální masivní olejovaný stůl na zakázku od truhláře. Ano, nezvednu ho a neodnesu (ale to ani žádný kupovaný). Ale odsunu ho v pohodě jak já, tak manželka. Prostě normální stůl. Měl bych čekat něco jiného?
No odtlačím i auto ale přenést na zahradu se v jednom člověku dělá blbě. Známý měl rád tyhle stoly a nechal k tomu udělat i židle ale jeho manželka je ráda když je zasune pod stůl. Prostě dubový sůl a židle. Mají to venku (pod terasou) ale hýbat s tím nejde. Nemyslím takové ty jednoduché byť na zakázku dělané stoly které na první pohled není jasné zda je to. Blbě se to hledá ale něco jako tohle plus ve stejném stylu židle a nohy taky byly dřevěné.
Tak takový stůl jsem si fakt nepředstavil. Protože tenhle stůl je IMO záměrně udělaný tak, aby na něm bylo vidět řemeslo co možná nejmíň. Cílem je aby bylo vidět dílo přírody, ne člověka.
A to, že ta extra tlustá deska vypadá líp je taky důvod, proč je ten stůl tak těžký. Masiv může být naopak lehčí než dřevotříska.

15
Vývoj / Re:Vhodna AI na programovanie (pre neprogramatora)
« kdy: 13. 02. 2026, 10:02:28 »
... (kromě toho, že AI z tohohle oboru dost odstraňuje to, co na něm bylo zábavné) ...
Souhlas, ale nejen v tomhle oboru. Ono to vypadá, že AI bude psát básně, skládat hudbu a my lidi budeme umývat podlahu.

Psaní kódu je zábavné a přiznejme si že i jednoduché. Těžké jsou ty věci okolo. Najít a doplnit díry ve vágním zadání. Code review nebo třeba louskání nějakého starého kódu. Ladění chyby, která nastává zásadně jen když je měsíc v úplňku. atd...

AI je jako nespolehlivý podřízený, na kterého nemám žádnou páku. Někdy dělá, co chci. Někdy to podělá. Někdy se na to vykašle. Nikdy sám nepřizná, že něco pokazil. Ještě jsem nezažil, aby mi řekl, že něco nezvládne. A nikdy za nic neponese zodpovědnost.

Pro darebacika :
Buď sakra opatrný, když používáš AI na něco, co neumíš. Protože ty to musíš zkontrolovat a ty za to poneseš zodpovědnost.

Stran: [1] 2 3 ... 28