Za čtyřicetpět let by snad již mohlo být jasno (diskuse)

[Pida]

Rozhodujici je externi bus. 386sx byly taky oznacovany za 16bit.

[PetebLazar]

Takže můžeme díky tomu napsat. Při vhodné konstelaci je možný nativní běh 32-bitového OS i na 16-bitovém CPU.

[Radovan]

Souhlas, proto se první IBM PC s i8088 řadí mezi osmibitové počítače, přestože reklama tvrdila něco jiného.

[z_sk]

Prečo 16 bitová?:

Interne používa 16-bitovú dátovú aritmetickú logickú jednotku (ALU) … (Motorola 68000 [Wikipedia])

Takže sizeof(int) by mal byť rovný hodnote 2.

[z_sk]

Áno, sizeof(int) je rovný 2 (viď. 9.3.2 The size of an operation).

[PetebLazar]

Zní to relevantněji než argument šíři externí sběrnice. Například i8088 vrací údajně na sizeof(int) 2 a tipnul bych si, že 386SX bude vracet 4.

[z_sk]

386SX je 32-bitovy systém, lebo ALU je 32-bitové, ale sizeof(int) vracia 2 (2.5 Data Types, strana č. 15).

[PetebLazar]

Takže asi není jediný rozhodný atribut. Pocitově si myslím, že si 68000 zařazení do stejné rodiny jako SEGMENT:OFFSET hrůza 8086 nezaslouží.

Možná je pro označování 16-bit Home Computers jestě jeden historický důvod. Snaha výrobců vyhnout se exportním omezením COCOM. Plnokrevné 32-bitové CPU podléhaly exportním povolením jehož součástí byl souhlas soudruhů s nahodilými kontrolami ze strany vojenských přidělenců NATO v příslušných zemích, kteří ověřovali zda tyto nejsou v rozporu s vydaným exportním povolením využívány k vojenským účelům.

[PetebLazar]

Například na x86_64 Linuxu mi gcc v defaultu pro int vrací delku 4, pro long 8. Ve Windows-64 gcc pro int 4, pro long 4, pro int64_t 8. Což nakonec asi odpovídá tabulce níže.

https://www.ibm.com/docs/en/ibm-mq/9.0?topic=platforms-standard-data-types-unix-linux-windows

[Radovan]

To je věc implementace kompilátoru, nikoliv procesoru. Totéž můžeš mít na Crayi stejně jako na i4004

[Gilhad]

Nevím jak vy, ale já "všude" vidím označení 16/32 bitový procesor. (Teda ne pouze 16, nebo pouze 32, ale právě kombinaci obou současně.)

Jak na wiki, tak v dokumentaci od Motoroly, tak i porůznu na webu. A jelikož to Motorola jak vymyslela, tak vyráběla, tak bych docela řekl, že ví, o čem mluví

A dává to dobrý smysl, protože datovou sběrnici má 16 bit a instrukce 32 bit.

[PetebLazar]

Jde o to, že šířka datové sběrnice (případně šírka výkonných jednotek) jsou kvantitativním faktorem, kdežto 32-bitové registry, 24-bitová sběrnice s přímou adresací jsou změnou paradigmatu. Nakonec výše taktovaný procesor s užší ext. sběrnicí a užšími výkonnými jednotkami může být ve výsledku výkonnějším.

[PetebLazar]

Ta Motorola co byla dokonce schopna vyrobit i 32-bitové CPU s ext. 8-bitovou sběrnicí? A teď babo raď.

https://en.wikipedia.org/wiki/Motorola_68008

[z_sk]

Architektúra sa určuje podla toho, aký rozsah zvláda natívne hardvérovo vypočítať CPU. Tak natívne ako prvá zvláda 16 bítový údaj, lebo takú ma takú ALU. Ale ALU je iba časť procesora. Ale zvláda hardvero aj 32 bítove údaje. Keďže ALU nie je 32-bitové (ale 16-bitové), tak zrejme to robí menej efektívne, ako by to robilo CPU s 32-bitovým ALU.

Keďže nie to nie je čisté 16 bítové CPU, lebo má "obvody" pre 32-bitové údate; a zároveň ani riadne 32-bitové, lebo efektivita voči riadnemu 32-bitovému ALU by mala byť menšia; je vo výsledku taký mačko/pec, ani jedno, ani druhe, čiže je vo výsledku 16/32-tová architektúrach. Ak by sme povedali, že je iba 16 alebo 32-bitové, tak by sme "klamali" zákazníka.

A nemá to nič spoločné zbernicou, viď súčasne moje CPU (vid Address sizes):

$ lscpu |head -n 4
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   40 bits physical, 48 bits virtual

[PetebLazar]

To možná jako pravidlo akceptujeme my, ale marketingová oddělení často takové restrikce nemají. https://en.wikipedia.org/wiki/Atari_Jaguar#Bit_count_controversy

[kvr]

To, že si to marketing dezinterpretoval ve svůj prospěch v jiných případech, neznamená, že je to validní..

Souhlasím s debian+, že je to otázkou toho, co zvládá CPU za výpočty a v tomto případě je ALU 16-bitová. I přesto, že CPU instruction set architecture byla 32-bitová a bez její změny bylo možné vytvořit 32-bitový CPU (což nebyl případ 8086 vs 80386). Ono to dává smysl - jako zákazníka mě nezajímá, co nové podobné CPU někdy dokáží, ale co v dané chvíli ten konkrétní kus umí.

... jakkoli tedy souhlasím, že bylo nefér porovnávat jednoduchost Motorola 68000 se zpraseným segment:offset na 8086 . Ale prostě to není relevantní.

[Radovan]

Námitka: Z80 má čtyřbitovou ALU a šestnáctibitové aritmetické instrukce!

[PetebLazar]

Patrně zúročení jimi nabytých zkušeností v rámci jejich předchozího díla Intelu 4004.

[Radovan]

O tom nepochybuj, když je na obou podpis FF

Ale vzal bych v úvahu také instrukci DAA a "tajný" příznak Half Carry.

[Radovan]

Z80 byl 8/16 bitový procesor a používal se v osmibitových počítačích.

[Zelena je trava]

Je i nejaky rusky procesor (co neni kradezi ci klonem)?

[Radovan]

Jistě, je jich celá řada. A nejen to:

https://www.root.cz/clanky/pocitac-setun-1057-1077-1090-1091-1085-1100-a-benderova-nocni-mura/

Mimochodem, Pentium a Pentkovskij

[z_sk]

Z80 sa uvádza, že bol 8-bitový. Čo je ok, lebo dátový aritmetický číselný typ zvláda 8-bitový údaj. Keďže má adresovanie 16-bitové, tak ma obvody na prácu s touto adresou. Ale (si myslím) pri priamom adresovaní (aké ma Z80) nepotrebuješ na tej adrese trebars robiť iné operácie ako sčítanie/odčítanie (napr. ALU zvláda aj bitové operácie).

Možno sa ani nevedelo, že ALU malo Z80 interné 4-bitové. Zas na druhej strane, vtedy, ta réžia asi nebola až tak výrazná, ako trebars dnes, keby si 64-bitový údaj rátal na hardvérovej 4-bitovej ALU-i.

Ako tragédiu by som to nevidel. Treba brať, že technológie sa vyvíjali. A bolo trebars nejaká éra pred vznikom štandardu.

[PetebLazar]

Takže užší 4-bit ALU u Z80 nerozhoduje (zůstává osmibitem), u 68000 její 16-bit ALU rozhoduje (není 32-bitem).

A exotický 680008, který je deklarovaný jako 8bit/32bit (externí šíře/logická šíře) označíme za 16-bit díky šířce jeho ALU.

[z_sk]

Výrobca ho prezentoval zrejme ako 8-bit. Ale zakladný pracovný aritmetický rozsah je 8-bit.

M68000 je 8-/16-/32-Bit Microprocessors (Zdroj).

Prepáč, ja svoju "definíciu" definujem z pohľadu najmä bežnej prítomnosti, takže ber to v úvahu.

Ináč, treba rozlišovať aj, čo je procesor a mikrokontróler.

[Radovan]

Vědělo se třeba tohle:

add hl,bc
add hl,de
add hl,hl
add hl,sp
add ix,bc
add ix,de
add ix,ix
add ix,sp
add iy,bc
add iy,de
add iy,iy
add iy,sp

Celé to opisovat nebudu

[z_sk]

To je fronend. A poznáš backend? Čo ak sa len prepínajú interne hardvérové vývody, kde sa číta a kam zapisuje?

[Radovan]

Myslíš něco jako když třeba ex de,hl místo poctivého přesouvání dat ty registry ve skutečnosti jenom přejmenuje? Tak jako když eex udělá totéž se všemi registry naráz?

Ale jo, něco málo o backendu Z80 vím

[z_sk]

Asi som zle pochopil, co si napísal. Myslel som, že Tvoj príspevok je ako protiargument.

No, 1-bajtovy register môže byť klopný obvod D, co vo vnútri sú nejako zapojené tranzistory (a tranzistory su ako prepínače), takže vlastné vstup výstup/výstup je vecou interného "prepínania".

Ale, radšej ignoruj(te) môj komentár.

[Radovan]

Vlastně je i není. A registry Z80, poskládané ze dvou invertorů, jsou fakt kulervoucí!

[PetebLazar]

Tohoto sběratele patrně podobné otázky netrápí.

[PetebLazar]

Pro ty co neměli tu čest, srovnání velikosti Motorola 68000 s NVMe 2280.

[Jendа]

Uvnitř bude menší čip, IMHO to mohlo být menší a limitem je, že by tehdy návrháři a výrobci plošňáků neuměli použít menší packages.

[Gilhad]

Tak on ten chip bylo jen to v tom zlatém a zbytek byly jenom nožičky, aby se to dalo používat způsobem obvyklým Pre-release XC68000 chip made in 1979

[PetebLazar]

Přesto mne velikost pouzdra při vyjímání docela překvapila. Začínal jsem na C=16 osazeného MOS 7501 (odvozenina 6510 vycházejícího z 6502) a kromě 8080 jsem za těch uplynulých čtyřicet let v osobních počítačích potkal prakticky pouze CPU Intelu a AMD.

[vlk]

kazdy si to oznacoval po svojom, niekto podla sirky datovej zbernice, iny podla sirky vnutornej zbernice ci hlavnych registrov, preto 8088 je sice vnutorne 16bitovy (odlahceny 8086) ale oznacovali ho aj ako 8bitovy, lebo von mal vyvedenych bitov iba 8. a nevsimol som si ze by niekto pocital kolko je bitovy procesor podla sirky adresnej zbernice

[plostenka]

N-bitovy procesor se pozna podle velikosti "general purpose" registru. Sirka rozhrani k I/O nebo ALU je implementacni detail...

[PetebLazar]

Tak jsme asi dva. https://www.cs.mcgill.ca/~cs573/fall2002/notes/lec273/lecture9/#81

[kvr]

Dovolím si upravit: N-bitová architektura se pozná podle velikosti "general purpose" registru. Šířka rozhraní k I/O nebo ALU určuje N-bitovost dané implementace.

Nechcu startovat flame, ale holt ALU je to, co určuje skutečný výkon (v tehdejší době, dnes jsme samozřejmě jinde se superscalar a SIMD).

[PetebLazar]

Šířka ext. sběrnice a výkonných jednotek určitě ovlivňuje výkon, ale nemění architekturu (ve smyslu instrukční sady vlastní 8-bit CPU, 16-bit CPU, 32-bit CPU, ...). Jde o to zda jsou rozhodující kvantitativní či kvalitativní hlediska.

[ptakopisk]

To je jen dalsi priklad toho, ze je nesmysl oznacovat architekturu pouze jednim parametrem. Je to jak 16bit tak 32bit, takze asi nejlepsi je oznaceni 16/32bit. Vicemene je kravina...

[Gréta]

tak těch 16 a 32 jakoby zpruměruj na 24bitů a všichni budou muset bejt spokojený :D ;D

[disorder]

o motorole nic neviem, ale x86 som mozno mylne vzdy povazoval za 16/32/64 podla virtualneho adresneho priestoru... teda 386 vedela real mode (16 bit) alebo protected, pripadne unreal mode, k tomu potom patrili aj rozsirene registry (uz to nebolo ax ale eax).

[PetebLazar]

Nevím jestli je vhodný přístup. Například i386, kterou by asi vetsina povazovala za 32bitovy procesor zvládal v rámci PAE přístup k více fyzické paměti než 4GB. Ten přístup byl snad vlastnostmi limitovaný tak se to myslím především využívalo pro blokový přístup buffery/ramdisky. https://en.m.wikipedia.org/wiki/Physical_Address_Extension

[kvr]

Oprava: PAE vzniknul mnohem později, až s Pentium Pro. A naštěstí byl docela rychle zapomenut, co vím, tak ta podpora v Linuxu byla docela peklo z hlediska kódu. Kromě Linuxu to snad ani nikdo nepodporoval...?

Na buffery se to právě využít nedalo, bo buffer je adresovaný z kernelu - a kernel měl pro sebe jenom 1 GB address space (u Linux x86 bylo dělení 3GB-1GB, Windows NT měly myslím 2GB-2GB). Takže to jenom umožňovalo běžet několika velkým aplikacím paralelně, což není úplně běžné využití, takže to asi i z toho důvodu chcíplo. I když možná v době před virtualizací a s velkými J2EE servery, možná to krátce smysl mělo.

[Jendа]

Podporovalo se to normálně, třeba i ve widlích.

[PetebLazar]

Pentium Pro byl stale IA32, označení i386 jsem použil nevhodně.

Využívaly to především vyšší edice Windows Serveru. https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/how-pae-awe-work-together

[kvr]

Jo, díky, taky jsem to potom našel... Docela by mě zajímala statistika, nakolik to bylo skutečně využíváno.

[PetebLazar]

Tady popisují uživatelé WinXP některé případy užití. Typicky persistentní Ramdisk, který byl naplněn aplikacemi/daty s požadavkem na rychlý přístup. Šlo o dobu předSSDčkovou, takže ramdisk se nabízel.

https://msfn.org/board/topic/181447-what-to-do-with-8gb-of-ram-on-xp/

Tipoval bych, že v server segmentu šlo o %, v desktopu o méně než °/oo. Je si třeba uvědomit, že v době vzniku PAE(1995) se hranice 4GB či reálně 2GB kvapně blížila a x86_64(1999) byla zatim v nedohlednu, stejne tak IA64(2001). Do Windows Vista 64-bit(2006) to se s tim asi vydrzelo. Windows XP 64 (stejny zaklad jako Windows 2003 Server 64bit) trpěly pri desktop vyuziti driverovou nouzí.