CSIRT.CZ, český národní CERT provozovaný na základě veřejnoprávní správní smlouvy společností CZ.NIC, shrnuje patnáct let svého fungování pod tímto sdružením: CSIRT.CZ – 15 let ve sdružení CZ.NIC.
Commodore OS Vision (Wikipedie) byl vydán v nové verzi 3.0. Jedná se o linuxovou distribuci určenou pro fanoušky značky Commodore. Předinstalována je na počítačích Commodore 64x.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 208. brněnský sraz, který proběhne v pátek 25. dubna od 18:00 ve studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1.
Ve svém článku Getting Forked by Microsoft popisuje autor programu Spegel svoji nepříjemnou zkušenost s firmou Microsoft. Firma ho kontaktovala a zpočátku to vypadalo, že by mohlo jít o oboustranně prospěšnou spolupráci, autor tedy ochotně odpovídal na jejich otázky ohledně architektury programu a pomáhal jim ho zprovoznit. Následně komunikace ze strany Microsoftu utichla. Autor předpokládal, že zřejmě došlo ke změně priorit a firma
… více »Společnost Notion Labs stojící za softwarovou platformou pro spolupráci Notion (Wikipedia) oficiálně představila (YouTube) poštovního klienta Notion Mail. Aktuálně funguje pouze nad Gmailem.
Byla vydána nová verze 9.12 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Ubuntu 25.10 bude (𝕏) Questing Quokka (pátrající klokan quokka).
Ubisoft uvolnil zdrojové kódy softwaru Chroma pro simulaci barvosleposti pro vývojáře počítačových her. K dispozici jsou na GitHubu pod licencí Apache 2.0.
Defold (Wikipedie) je multiplatformní herní engine. Nejnovější verze je 1.10.0. Zdrojové kódy jsou k dispozici na GitHubu. Licence vychází z licence Apache 2.0.
Ahoj, chtel bych se zeptat jaky je rozdil mezi 32b a 64b OS. Prosim nepiste odpovedi jako vykonove temer zadny atd. Me to zajima ciste teoreticky... Co si mam predstavit pod tema 64 bitama? Vim ze 64b OS umi adresovat vic jak 4GB RAM. Ale to je vsechno co vim...ale prece tech 64 bit se netyka jen adresovaci sbernice ne? Ze skoly si pamatuju ze CPU aspon zjednodusene je povazovano za 32bit pokud ma 32b scitacku a secte tak naraz napr 2 32bit cisla... Dale me napada ze tech 64 bit jeste muze byt velikost typu promennych (napr integer atd) ale to uz fakt jen hadam...
Diky za rady
že binárky jsou větší a zabírají víc místa v paměti.Přičemž pro obojí platí, že zanedbatelně.
Je trojnásobek opravdu zanedbatelný?
Nejde vůbec o velikost samotných binárek. Instrukce na x86 (narozdíl například od MIPS64) nenarostou s přechodem na 64 bitů na dvojnásobek. (Dokonce bych tipoval, že nenarostou vůbec...) Nicméně faktem je, že Linux + KDE zabírá ihned po startu na 32-bitovém stroji cca 100 MB paměti, zatímco na 64-bitovém zabere (opět ihned po startu) přes 350 MB. Stejné distro, stejná paměť (2 GB), stejné balíčky, stejní démoni na pozadí.
Je trojnásobek opravdu zanedbatelný?
Tvrdit, že je to trojnásobek, je asi stejně nesmyslné, jako kdybych já prohlásil, že jsou 64-bitové programy asi dvaapůlkrát rychlejší, protože mi to tak v jednom konkrétním testu vyšlo.
Nicméně faktem je, že Linux + KDE zabírá ihned po startu na 32-bitovém stroji cca 100 MB paměti, zatímco na 64-bitovém zabere (opět ihned po startu) přes 350 MB.
Pak tam bude rozdíl i v něčem jiném.
Například v čem? Jde o jeden a ten samý stroj, na kterém byl 32-bitový a 64-bitový ArchLinux. Je to jednoduché: Kdo chce 64-bitový systém, potřebuje přinejmenším dvakrát víc paměti, než kolik používal u 32-bitového systému. To samozřejmě není žádný problém, protože paměť je dnes velmi levná. Nicméně je potřeba s tímto faktem počítat.
Je to jednoduché: Kdo chce 64-bitový systém, potřebuje přinejmenším dvakrát víc paměti, než kolik používal u 32-bitového systému.
Ne, tak jednoduché to opravdu není. Váš výsledek odporuje mým zkušenostem, takže si to zkusím sám. Před chvílí jsem rozběhl automatickou instalaci dvou systémů podle stejného profilu, až doběhne, napíšu sem, jak to vychází mně. Mělo by to trvat asi 20-30 minut.
znamená i šířku integeru
Jenom poznámečku - neznamená to ale, že Céčkový int
musí být na 64 bitové architektuře 8 bajtový.
No a kdyz je procesor 64bitovy tak to neznamena ze je rychlejsi? Ze proste zpracuje v jednom taktu 2x tolik dat nez 32bitovy?
V nekterych hodne specifickych pripadech tomu tak byt muze (pokud se kod vhodne naprogramuje), ale v tech samych pripadech se stejne spis pouzije MMX nebo SSE, kde to je jedno. Obecne tomu tak neni.
memcpy()
vám připadá jako "hodně specifický případ"? :-)
tak ti to zabere také stejně dlouho i když překopíruješ 2× tolik dat…Vzhledem k tomu, že int (C int) je na AMD64 32bitový - určitě?
No a kdyz je procesor 64bitovy tak to neznamena ze je rychlejsi?V některých případech ano. Například sečtení dvou 64-bitových čísel. V dnešní době se takových čísel vyskytuje hodně.
Striktně vzato, ve velmi specifickém případě (bitové operace na nějakém proudu dat (tj. například šifrování)) tomu tak může být. Ve skutečnosti ale rozdíl není moc velký.
Důvodem je fakt, že procesor nežije ve vzduchoprázdnu. Používá RAM a cache. Jejich propustnost je samozřejmě omezená. Z toho taky plyne, že v některých situacích (práce s obrovskými dynamickými strukturami se spoustou pointerů) bude 64-bitový systém naopak pomalejší. To není problém samotného procesoru, ale prostě vlastnost těch zařízení kolem něj.
Striktně vzato, ve velmi specifickém případě (bitové operace na nějakém proudu dat (tj. například šifrování)) tomu tak může být.
Už jsem se tu na to ptal jednou (jen někoho jiného): označil byste memcpy()
za "velmi specifický případ"?
Podle toho, co to znamená memcpy()
. Implementací takové funkce je spousta.
Například v nastavení Xine backendu je na výběr cca deset různých implementací dostupných pro x86. Tupá implementace bude nejspíš na 64 bitech rychlejší a možná tedy bude tím specifickým případem, nicméně vsadil bych se, že u chytřejší implementace už to bude záviset pouze na rychlostí paměti, nikoliv na délce slova procesoru.
memcpy()
v gcc
verze 4 to opravdu využívá.
To přece může 32-bitový procesor udělat taky, nebo snad ne? Pokud vím, některé implementace memcpy()
dělají různé triky s MMX registry, které jsou taky 128-bitové. (Možná si to pletu s něčím kolem SSE, ale faktem zůstává, že 32-bitové procesory něco takového umí.)
memcpy()
na nepříliš dlouhých blocích (tak, aby se vešly do cache) bylo na počítači s dual channel s -m64
přibližně dvakrát rychlejší než s -m32
. Ale přesný důvod neznám.
Na malý router bych spíš viděl něco se spotřebou pod 20W. (ARM? Nějaký malý MIPS?)
Tady nejde o házení uživatelů přes palubu. ArchLinux prostě nikdy ve své (krátké) historii staré Pentium nepodporoval. Zrovna u Debianu, který má balíčky pro spoustu architektur, by bylo řešení velice jednoduché. Stačilo by prostě přidat několik verzí x86 jako samostatné architektury. Mainstream by se měl dnes kompilovat s podporou alespoň SSE2 a výše. Netuším, proč to tak není.
Kdysi dávno existoval projekt, který vytvářel kompletní repository ArchLinuxu pro i586. (Normální balíčky se odjakživa kompilovaly pro Pentium Pro.) Nevím, jak to nakonec dopadlo a zda o to byl zájem. Nejspíš to ovšem zaniklo. Problém vidím hlavně v tom, že motherboardy pro Pentium měly (na desktopu) většinou podporu pro 64 MB nebo 256 MB paměti, víc ne. To už prostě na dnešní distro nestačí. Možná na ten router ano, ale pak není od věci zvolit jiné distro. Pokusy o portování ArchLinuxu na SPARC a MIPS taky nakonec nějak umřely. Jediný dnes funkční port na menšinovou architekturu je PowerPC.
Off-topic poznámka: Kdysi mě zajímalo, proč se ArchLinux kompiloval zrovna Pentium Pro, proč ne Pentium II. Pak jsem to zjistil. Zvolením Pentia II se ztratí podpora pro všechny procesory typu VIA 686, IBM 686 a jim podobné. Pentium II už mělo mnohem lepší FPU a například Ghostscript, který něco takového používá, pak například na 686 VIA okamžitě odletí kvůli kumulaci chyb ve výpočtu. (Podle hlášek se tam vypočte záporná velikost nějakého grafického objektu.)
Na malý router bych spíš viděl něco se spotřebou pod 20W. (ARM? Nějaký malý MIPS?)Že ty bys to tak viděl nemá žádnou spojitost s tím, co komu kde běží.
Stačilo by prostě přidat několik verzí x86 jako samostatné architektury.Jo, jako by už teď těch architektur neměli na starosti dost.
Pokusy o portování ArchLinuxu na SPARC a MIPS taky nakonec nějak umřely. Jediný dnes funkční port na menšinovou architekturu je PowerPC.Tak vidíš. ArchLinux umí dvě architektury (a dovedu si představit, jak ten port na PowerPC asi vypadá), ale přesto jiným radíš, aby jich podporovali víc.
Že ty bys to tak viděl nemá žádnou spojitost s tím, co komu kde běží.
A co jako? Takhle to vypadá, když někdo nepochopí pointu. Pointa je v tom, že omezovat podporu procesorů kvůli nějakému dřevnímu a zastaralému routeru je prostě holý nesmysl. Pokud někomu někde běží router na Pentiu, měl by si prostě zvolit jiné distro než desktopové. Prostě proto, že distro pro dnešní desktopy už není pro Pentium vhodné.
Jo, jako by už teď těch architektur neměli na starosti dost.
Další nesmysl. O jaké starosti je tady řeč? Podporou několika x86 architektur by ztratili pouze počítačový čas pro kompilaci s různými flagy, nic víc. A počítačový čas je dnes velmi levný.
Tak vidíš. ArchLinux umí dvě architektury (a dovedu si představit, jak ten port na PowerPC asi vypadá), ale přesto jiným radíš, aby jich podporovali víc.
Je snad na tom portu pro PowerPC něco špatně? Rád se dozvím o nějaké osobní zkušenosti, ať už pozitivní či negativní. ArchLinux je pořád ještě „malé“ distro, nemá tedy dost prostředků a dost vývojářů na nějaké rozsáhlé portování. Nikomu nic neradím, pouze nachápu, jak může Debian, který podporuje hned několik téměř vyhynulých architektur, dodávat balíčky jen pro jednu verzi x86. To je zkrátka absurdní.
Jak už jsem tu psal, ArchLinux si pro každý stroj kompiluju, binární balíčky používám pouze při první instalaci, k ničemu jinému. Právě proto bych ocenil, kdyby existovala distribuce, u které by člověk něco takového nemusel řešit. Balíčkovací manažer by prostě věděl, který je to procesor a v jaké repository pro něj hledat balíčky. Nicméně zdá se mi, že taková distribuce neexistuje.
Pokud někomu někde běží router na Pentiu, měl by si prostě zvolit jiné distro než desktopové.Odroluj si, prosím, o pár příspěvků výš a podívej se, o kterém distru se tu bavíme. Charakterizovat Debian jako desktopové distro, to je hodně velkej ústřel. A to nebudu zmiňovat různé tlusté klienty, kde je staré Pentium naprosto dostačující hardware.
O jaké starosti je tady řeč? Podporou několika x86 architektur by ztratili pouze počítačový čas pro kompilaci s různými flagy, nic víc.Za předpokladu dokonalých programátorů a tvůrců překladačů ano. Jinak samozřejmě ne, rozhodně se můžou objevit chyby, které postihnou jenom jednu variantu překladu. Navíc nevím jak v Archu, ale v Debianu nefunguje "tady jsme to přeložili a hurá, vydá se to" - když je zavedena nějaká architektura, tak se před vydáním musí otestovat, jestli všechno funguje. To prostě je práce navíc, kterou někdo musí udělat.
Nikomu nic neradím, pouze nachápu, jak může Debian, který podporuje hned několik téměř vyhynulých architektur, dodávat balíčky jen pro jednu verzi x86. To je zkrátka absurdní.Tak jim to běž říct. A že ty nějakou architekturu nepoužíváš a x86 je pro tebe začátek a konec světa, ještě neznamená, že ostatní jsou na tom stejně.
Balíčkovací manažer by prostě věděl, který je to procesor a v jaké repository pro něj hledat balíčky. Nicméně zdá se mi, že taková distribuce neexistuje.Ano, kombinaci Gentoo a Debianu bych uvítal taky, ale zrealizovat něco takového by bylo velice náročné - hlavně finančně.
Tak jim to běž říct. A že ty nějakou architekturu nepoužíváš a x86 je pro tebe začátek a konec světa, ještě neznamená, že ostatní jsou na tom stejně.
Vtipálku! Podle sebe soudíš ostatní?
Jedna otázka je, kolik lidí používá jako svůj hlavní desktop něco jiného než x86. Velmi málo. Jiná otázka ovšem je, s čím se kdo má možnost setkat. Někdo třeba kompiluje každý svůj program taktéž pro SPARC64, aby ho mohl vyzkoušet v big-endian prostředí. (Píšu si u sebe plus.) Někdo zase dělal ve škole kernel pro MIPS. (Píšu si u sebe další plus.) A někdo zase má přístup třeba k PowerPC a tu a tam vidí nějaký drobný strojek s ARM. Takže se začátkem a koncem světa jsi trochu přestřelil.
Rád věřím, že napsat --march=pentium-m
nebo --march=prescott
do nějakého konfiguračního souboru je fakt šíleně těžká práce... Hlavně když se pak v jednom ze 100 balíčků kvůli tomu vyskytne nějaká chyba, to je pak hotové neštěstí! Ale teď vážně. Kdyby ta podpora pro několik různých verzí 32-bitových a 64-bitových Intelů a AMD v nějaké distribuci existovala, a to v binární podobě, abych nemusel nic kompilovat, velmi rychle bych na takovou distribuci přešel. I kdyby se to jmenovalo třeba Debian ultra-hyper-experimental.
Jedna otázka je, kolik lidí používá jako svůj hlavní desktop něco jiného než x86. Velmi málo. Jiná otázka ovšem je, s čím se kdo má možnost setkat.Spousta otázek, žádná relevantní. Klíčová otázka zde je: odroloval sis o pár příspěvků výše, aby zjistil, že se nebavíme o desktopovém distru, ale o Debianu, u kterého se primárně předpokládá nasazení na servery (i když sám za sebe můžu říct, že na desktop se hodí taky, ale asi budu v menšině)
Kdyby ta podpora pro několik různých verzí 32-bitových a 64-bitových Intelů a AMD v nějaké distribuci existovala, a to v binární podobě, abych nemusel nic kompilovat, velmi rychle bych na takovou distribuci přešel.Můžeš takovou vytvořit. Jestli říkáš, že udělat několik větví pro varianty x86 a amd64 není nic těžké, určitě nebude udělat další fork Debianu - zdrojové balíčky pro vytváření těch binárních jsou k dispozici, stačí jenom udělat ten konfigurační soubor.
> Mainstream by se měl dnes kompilovat s podporou alespoň SSE2 a výše. Netuším, proč to tak není.
Ono tam, kde to je dulezite, je casto runtime detekce procesoru a dynamicka volba konkretniho kodu. Takze i v tom Debianu, obecne kompilovaneho pro 486, se pak pouzije konkretni implementace treba vyuzivajici SSE2.
Ono tam, kde to je dulezite, je casto runtime detekce procesoru a dynamicka volba konkretniho kodu.
Tohle je problém aplikací. Ne jádra.
> Na malý router bych spíš viděl něco se spotřebou pod 20W.
Jsou x86 kompatibilni routery se spotrebou okolo 2 W (platforma ALIX postavena na procesoru AMD Geode).
To je jeden z mnoha důvodů, proč si ArchLinux pro každý stroj kompiluju.
-march=k8
to nie je take jasne
pri 32 bit cislach je rychlost rovnaka
pri 64 bit cislach zaberie
A)scitanie a odcitanie
2x tolko casu na 32 bit
na naobeni a deleni je to 6x tolko casu, ale FPU ma uz davno viac nez 64 bit, takze tram sa rozdiel nepociti...
Nejvetsi rozdil je v mnozstvi pameti kterou lze adresovat. Samozrejme pokud na 64 bit stroji bezi 64 bit system.
Nechci delat flame, ale netyka se omezeni RAM na 3 GB jen 32bit windows ?
Na jednom PC jsem testoval Slax a dle vypisu free byly vyuzity skoro cely 4 GB, df vypsal rozvrzeni pameti na dve casti (zhruba napul) a to unionfs a tmpfs.
Rychlost behu 32 bit windows na 64bit CPU je takrka stejna jako 64bit windows na tom stejnem hw (win xp).
V Linuxu (Ubuntu 9.04) je to tez srovnatelne.
V extremnich vypocetnich pripadech to snad bude znatelne. Pro bezneho uzivatele patrne nikoliv
Nicmene RAM v radu desitek GB je uz hodne rozsahle pole kde se vyrazne projevuji kapacity mezi spoji na DPS, indukcnost a podobne zakladni fyzikalni jevy ktere omezuji prenosovou rychlost resp rychlost prebehu z log nuly do jednicky. Mozna jednou budou pametove moduly se seriovym rozhranim a tento problem se tak podari trochu potlacit. Tedy neco jako SATA u HDD - je tam pouzit seriovy prenos dat a presto je rychlost vyssi nez u PATA.
Zkratka zadny radikalni rozdil jako je mezi uvedenym prikladem SATA a PATA HDD necekejte.
3GB RAM je omezení jen pro Windows XP Home. Windows Servery některých řad umožňují pomocí PAE (umí to i Unixy/Linuxy) adresovat na 32bitech i více než 4GB paměti. Na rootu je o tom myslím článek.
Avsak stale ostava limit 4GB na proces ak sa nemylim, takze system dokaze spracovat viac ale jedna aplikacia nie.
pokud umi 32b linux dat na jeden proces max. 4 GB RAM, tak je na tom lip nez 32b windows, protoze ty daji na userspace normalne max. 2 GB a s prepinacem to jde zvednout na 3 GB
a jestli se nepletu, tak u 32b windows XP se MS na rozbehani PAE nakonec vykaslal...
nekdo linuxu znaly si muze projit toto: msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx a porovnavat, jak na tom byl a je linux ve vztahu k windows za poslednich deset let (ja na to znalosti nemam)
a jestli se nepletu, tak u 32b windows XP se MS na rozbehani PAE nakonec vykaslal...Jestli se nepletu, tak se pleteš.
hmm, oni rikaji "design change" (support.microsoft.com/) a ja uz jsem napsal, jak to vidim (kdyz jsem v praci dostal stroj s Win XP SP3 a 8GB RAM, tak at bylo PAE zapnute nebo ne, tak to videlo jen 3.2 GB RAM)
Rozšíření fyzické paměti (PAE) X86 umožňuje softwaru se sadou rozhraní API AWE (Address Windowing Extensions) v počítači s procesorem Intel Pentium Pro či vyšším a více než 4 gigabajty (GB) fyzické paměti mapovat více fyzické paměti na virtuální adresní prostor aplikací. Rozšíření fyzické paměti (PAE) X86 přináší výhody i aplikacím, které nevyužívají sadu rozhraní API AWE, protože operační systém využívá větší fyzickou paměť, která snižuje potřebu stránkování a tedy zvyšuje výkon. Rozšíření také přináší výhody konsolidačním serverům, které jsou hostiteli více aplikací.
Nicmene RAM v radu desitek GB je uz hodne rozsahle pole kde se vyrazne projevuji kapacity mezi spoji na DPSHezké, ale s režimem adresování to moc společného nemá
Na druhou stranu používání 64bitových registrů znamená větší nároky na paměť, což je také důvod, proč se 64bitové systémy nepoužívaly od počátku (paměť byla příliš drahá).
To není moc šťastně řečeno. Používání 64-bitových registrů neznamená větší nároky na paměť, větší nároky na paměť jsou způsobeny používáním 64-bitových datových typů místo 32-bitových, k čemuž vás ale nikdo nenutí, pokud je nepotřebujete. Co se týká historie, 64-bitové operační systémy se používaly už dávno, v podstatě jakmile se objevily 64-bitové procesory. Podobně to bylo i na PC - 64-bitové linuxové distribuce se začaly objevovat a používat velmi krátce poté, co se na trhu objevily první procesory s architekturou AMD64. Jenže holt platí, že co neposvětí Microsoft, to oficiálně neexistuje, takže spousta lidí (bohužel včetně "odborných" novinářů) se zcela nesmyslně tváří, jako by 64-bitové systémy byly nějaká horká novinka poslední doby.
Ten thread je označený jako vyřešený ale řekl bych, že tady je více údajů, které tazatele zmatou nebo dokonce přivedou na zcestí :)
n-bitovost nemá nic společného s šířkou adresové sběrnice. To by pak, pokud se podíváme do historie) osmibity adresovaly jen 256 bajtů paměti nebo v současnosti x86 nemohly adresovat 36bitů a naopak současné x64 procesory zase neumí adresovat plnými 64bity virtuálně natož fyzickou paměť
n-bitovost také né vždy souvisí s velikosti typu int v jazyku C. Závisí to na zvoleném datovém modelu viz http://en.wikipedia.org/wiki/64-bit#Specific_data_models na x64 se používá buďto LP64 nebo LLP64, ve skutečnosti je 64bit int na 64bit procesoru je opravdovou raritou.
velikost kódu - instrukce x64 jsou rozšířením x86, pokud se využívá 64bit registry nebo dodatečné registry tak instrukce narostou o jednobajtový prefix. V praxi je obvykle 64bit binárka o nejakých 10 % větší i když by mohl abýt za určitých okolností
velikost dat - narostou jen ukazatele na dvojnásobnou velikost. Násrust proměnných typu size_t se dá obvykle zanedbat.
SSE3 i SSE4 jsou použitelné i na x86.
Win XP (od SP2) nejen že PAE podporuje ale i implicitně zapíná u všech počítačů, které umí NX bit viz http://en.wikipedia.org/wiki/Physical_Address_Extension#Microsoft_Windows
Ten thread je označený jako vyřešený ale řekl bych, že tady je více údajů, které tazatele zmatou nebo dokonce přivedou na zcestíA proto sem nějaké přidáš a tam kde chyba nebyla, pro jistotu odpověď zopakuješ... (chtělo to přečíst celou diskuzi, nejenom první dva příspěvky)
n-bitovost také né vždy souvisí s velikosti typu int v jazyku C#9
velikost dat - narostou jen ukazatele na dvojnásobnou velikost. Násrust proměnných typu size_t se dá obvykle zanedbat.#29 a celé vlákno pod tím
SSE3 i SSE4 jsou použitelné i na x86.Univerzálně použitelné? Tzn. udělám jednu binárku používající SSE4 a ta půjde spustit na všech x86 procesorech? (omezím se na ty, na kterých běží Linux, tj. od 80386 výše) To asi ne, že ne...
n-bitovost ani neznamená, že general purpose registry mají n bitů páč třeba osmibitový Zilog Z80 měl registry 16bit HL a BC, které mají k pojmu general purpose hodně blízko.Jedna výjimka a ještě ne úplná, protože "hodně blízko" a "je to general purpose registr" jsou dvě různé věci. A jestli velikost univerzální registru není ukazatelem x-bitovosti procesoru, tak co teda je?
Takže jaká je vlastně odpověď na tazatelův dotaz? Taková, že odpověď rozhodně není triviální jak by se mohlo na první pohled dátZvlášť když každý čtvrtý příspěvek celou diskuzi zmate ještě víc, než byla.
Ten thread je označený jako vyřešený ale řekl bych, že tady je více údajů, které tazatele zmatou nebo dokonce přivedou na zcestí
Ono neškodí shrnout argumenty, a tohle vlastně popisuje, jak moc zamotané to je.
n-bitovost ani neznamená, že general purpose registry mají n bitů páč třeba osmibitový Zilog Z80 měl registry 16bit HL a BC, které mají k pojmu general purpose hodně blízko.
Jedna výjimka a ještě ne úplná, protože "hodně blízko" a "je to general purpose registr" jsou dvě různé věci. A jestli velikost univerzální registru není ukazatelem x-bitovosti procesoru, tak co teda je?
On ten tzv. 8bitový Z80 měl 16bitové registry skoro všechny, viz. en.wikipedia.org/wiki/Z80#Programming_model_and_register_set . 8bitový byl jen akumulátor a flags. Některé z těch 16bitových registrů fungovaly jako páry 8bitových (BC, DE, HL, ale např. instrukce pro cykly používaly všech 16 bitů, a podobně fungují registry v x86). Některé byly jen 16bitové - IX,IY,SP,PC. Takže to jediné, čím se pro programátora jevil Z80 8bitový, byl 8bitový akumulátor, a některé aritmeticko-logické operace tím pádem byly jen 8bitové (ale jiné ne, např. sčítání a odčítání fungovalo i na 16bitových registrech HL, IX a IY jedinou instrukcí). A například na zásobník se ukládaly jen 16bitové registry, 8bitový tam ani uložit nešlo.
> velikost dat - narostou jen ukazatele na dvojnásobnou velikost. Násrust proměnných typu size_t se dá obvykle zanedbat.
Struktury pak jeste narostou kvuli alignmentu. Tedy pokud mas treba ve strukture na stridacku integery a pointery, pak pointery se zvetsi na 8 B, ale musi byt alignovane a tak za kazdym 4B integerem bude jeste 4B mezera.
Takova hlavicka paketu obvykle nebude obsahovat pointery.
Obvykle to jde jednoduse preskladat. Ale musi se to udelat rovnou v kodu, protoze je zaruceno (akorat si ted nejsem jist, zda primo standardem C, nebo nejakou specifikaci binarniho rozhrani), ze se ukladaji v tom poradi, v kterem jsou v kodu.
A programatori maji radsi polozky ve strukture usporadane podle logickych souvislosti, nez podle velikosti typu.
Tiskni
Sdílej: