komentarze
slukaZobacz profil
Poziom ostrzeżenia: 0%
sluka2011.03.11, 14:33
@darkmartin

Wg dzisiejszych standardów nie, wg ówczesnych tak. Jak czytasz i dochodzisz do końca to nie zapominaj o początku, zwłaszcza o pierwszym zdaniu.
*Konto usunięte*2011.03.11, 14:36
Promilus1984 @ 2011.03.11 14:25  Post: 462186
@darkmartin - jednostka SIMD/MMX/FPU w Phenomie korzysta ze 128bitowych rejestrów ;) Jaki to jest zatem procesor? VMX w procesorach POWER/PPC także korzysta z 128bitowych rejestrów :] No, ale rejestry proca są 64bitowe w obu przypadkach. Tak samo ALU&AGU.

No jak to jaki? Wiesz w PS2 był 128bitowy CPU.
Administratormaly_szcz2011.03.11, 14:39
@SunTzu - 64-bitowy CPU, to nie tylko 64-bitowa szyna adresacji pamięci. Jak napisał mkopek, nawet 8-bitowe procesory potrafiły mieć szerszą szynę adresową - 16-, czy 24-bit. Podobnie rejestry.
Oczywiście były wytwory 12-, 31-, 36-bit (i inne, te to przykłady), ale czy o nich teraz słychać? :)


Pozdrawiam.
Promilus1984Zobacz profil
Poziom ostrzeżenia: 0%
Promilus19842011.03.11, 14:42
@sluka 6510 (6502) był 8 bitowy z 16 bitową magistralą adresową i 8 bitową magistralą danych. MCS-51 jest 8 bitowy (ma 8 bitowe rejestry za wyjątkiem... DPTR), ma zewnętrzną 16 bitową magistralę adresową i 8 bitową magistralę danych. Motorola 68k jest 32bitowa a w wersji 68000 ma 16 bitową magistralę danych i 23(4) bitową magistralę adresową. Ale jest to procesor 32bitowy (choć w tamtych czasach zwykło się nazywać zewnętrznie 16, wewnętrznie 32 albo 16/32bit). Pentium czy K7 to procesor 32bitowy z 64 bitową magistralą danych (szerokość modułu DIMM) i wg żadnej notacji nigdy nie był inny niż 32bitowy. K8 to procesor 64bitowy z 128bitową magistralą danych (s939, AM2, 940...) lub 64bitowy z 64bitową magistralą danych (754) i też nigdy nie był nazywany inaczej.
@SunTzu
w PS2 był 64bitowy MIPS z koprocesorami wektorowymi. Tak samo w Dreamcast (reklamowanej jako konsola 128bitowa) był 32bitowy SH-4 z 128bitowym SIMD. Ogółem trochę marketingu, ale nie przypudrujesz konkretów. W Cellu SPE to zmodyfikowana wycięta jednostka AltiVec z POWER4 i jest traktowane jako 128bit, niemniej procek z 128bit SIMD nadal jest tylko 32/64 bitowcem (np. Pentium 4+128bit SSE2/Core 2+128bit SSE3).
Administratormaly_szcz2011.03.11, 14:43
SunTzu @ 2011.03.11 14:36  Post: 462191
Promilus1984 @ 2011.03.11 14:25  Post: 462186
@darkmartin - jednostka SIMD/MMX/FPU w Phenomie korzysta ze 128bitowych rejestrów ;) Jaki to jest zatem procesor? VMX w procesorach POWER/PPC także korzysta z 128bitowych rejestrów :] No, ale rejestry proca są 64bitowe w obu przypadkach. Tak samo ALU&AGU.

No jak to jaki? Wiesz w PS2 był 128bitowy CPU.

Nie. Tam jest 64-bitowy CPU z 128-bitowymi rejestrami :) To procesor 46-bitowy i wynika to z definicji :)


Pozdrawiam.
slukaZobacz profil
Poziom ostrzeżenia: 0%
sluka2011.03.11, 14:46
Były nawet 20bitowe, rówieśnicy intela 4004. Np takim był F14 CADC.
darkmartinZobacz profil
Poziom ostrzeżenia: 0%
darkmartin2011.03.11, 14:50
Rejestry ogólnego przeznaczenia a wcześniej akumulator. VMX FPU to specjalizowane koprocesory które umieszczono z czasem wewnątrz mikroprocesora. Taka jest przyjęta klasyfikacja i możesz wymyślać co chcesz.
mkopekZobacz profil
Poziom ostrzeżenia: 0%
mkopek2011.03.11, 15:16
darkmartin @ 2011.03.11 14:50  Post: 462196
Rejestry ogólnego przeznaczenia a wcześniej akumulator. VMX FPU to specjalizowane koprocesory które umieszczono z czasem wewnątrz mikroprocesora. Taka jest przyjęta klasyfikacja i możesz wymyślać co chcesz.

Otoz to, dlugosc rejestrow ogolnego przeznaczenia procesora, oraz dugosc operandu na jakich sa wykonywane instrukcje procesora. I 6510/6502 byly procesorami 8 bitowymi, nie potrafily wykonywac operacji na danych 16 bitowych. 8088 byl procesorem 16 bitowym, takie mial rejestry, na takich danych byl w stanie operowac. Nawet mimo zewnetrznej fizycznej szyny danych 8 bitowej, dane z pamieci i tak pobieral po 16 bitow, tylko robil to na dwie raty.
ArlicZobacz profil
Poziom ostrzeżenia: 0%
Arlic2011.03.11, 16:10
sluka @ 2011.03.11 14:05  Post: 462182
Bitowość - to pierwsza ofiara marketingu w świecie IT. Trochę historii którą sam przeżyłem.
Komputery '8 bitowe', czyli takie jak ZX Spectrum, C64, Atari XL/XE, Amstrad/Schneider i im podobne chociaż mniej znane napędzały procesory o architekturze 16-to bitowej z 8-mio bitową magistralą danych. Dlatego też mogły one adresować 64KiB pamięci. W tych 'masowo' pionierskich czasach za wyznacznik bitowości uważało się szerokość magistrali danych. Czysty 8-bitowy procesor mógł się tylko nadawać do kalkulatorów i praktycznie niczego więcej. W epoce 16-bitowców obraz całości się trochę komplikuje, a to za sprawą Intela. Komputery oparte na procesorach Motoroli były w architekturze 32/16 (MC68000, MC68010), dla przypomnienia które - seria Atari ST, Amiga 1000, 500, 2000, 500+ i 600, oraz Macintosze, modeli nie będę wymiał, ponieważ ich nie znam, egzotyczny sprzęt, za egzotyczne kwoty pieniędzy. Na procesorach intela było już więcej zamieszania. Procesory 8086 i 8088, serca IBM PC XT i kompatybilnych były nieźle nakombinbowane, co długo się wszystkim odbijało czkawką. Procesory 16/16 i 16/8 ale z 20-to bitowym adresowaniem. XTeki na 8086 można było zgodnie z ówczesnymi standardami nazewnictwa nazywać 16-to bitowymi, ale na 8088 to były rasowe ośmiobitowce ;). Spuścizna po tych procesorach to słynne 640KiB RAM, dziesięć segmentów pamięci po 64KiB i piekło programistów. Dla tych co nie wiedzą, programy pisało się w wybranym modelu pamięci, Tiny, Small, Medium, Large, Hudge. W pierwszym całość program i dane musiały się zmieścić w 64KiB pamięci. Tylko w tym modelu pamięci mogły być programy .COM. Small to już dwa segmenty pamięci jeden na program, drugi na dane. Medium i Large różniły się ilością dostępnych segmentów na program, na dane był jeden. Dopiero w ostatnim modelu dało się użyć więcej danych, ale jedna tablica musiała się dalej mieścić w jednym segmencie. Takiego piekła jak na komputerach poganianych procesorami intela nie było tam gdzie sercem były procesor motoroli. Praktycznie liniowy model pamięci. Wczesne motorole miały 24bitowe adresowanie. Jedynym drobnym zgrzytem był fizyczny brak danych 8-mio bitowych.
Epoka '32' bitów, czyli pojawienie się i386. Motorolę sobie odpuszczę, powiem tylko tyle że były komputery na MC68020, 68030, 68040, no i na tych komputerach wszytko działało już w 32bitach. W komputerach pracujących na procesorach intela dalej był dos + rozpowszechniająca się graficzna nakładka czyli windows 3.1. Programy dalej były w głównej mierze 16-to bitowe. Wyznacznikiem 'bitowości' sprzętu była dalej szerokość magistrali pamięci. I tak i386SX był uważany za procesor 16-to bitowy, a zwykły 386 jak 32-bitowy.

64 bity po raz pierwszy, czyli pierwsze Pentium. Chyba nie muszę przypominać dlaczego ten procesor był za taki uważany.

64 bity po raz drugi to Athlon 64.

O jakie 64 bity chodzi nvidii?


Jak pentium był pierwszym 64 bitowym procesorem, to ja jestem święty :/
Intel był ostatni w 64bit..
skoti48Zobacz profil
Poziom ostrzeżenia: 0%
skoti482011.03.11, 16:26
pawełpclab @ 2011.03.11 12:00  Post: 462157
Myślę że te 64bitwe rozszerzenia to jest właśnie sposób nvidii na stworzenie własnego standardu i zaistnienie na rynku CPU. Początkowe połączenie z 32bitowym ARM pozwoli na płynne wejście na rynek serwerów i desktopów, a gdy za jakiś czas rozwiązanie się upowszechni to nv będzie mogła albo zrezygnować z rdzenia ARM na rzecz własnego albo implementować 32bitowe instrukcje ARM na drodze emulacji kupując tylko licencję na listę instrukcji a nie na rdzeń.
Bardzo podobnie powinno wyglądać wprowadzenie 64bitowych rozszerzeń do x86. Niestety dzięki AMD mamy kolejną protezę a nie nową listę instrukcji

Najprawdopodobniej nie będzie to rozszerzenie nvidii, ale po prostu 64bit instrukcje ARM obsługiwane przez CPU Nvidii - ARM już od dłuższego czasu pracuje nad 64bit i wątpię, aby Nvidia chciała robić niekompatybilne rozszerzenia (jeśli już to ARM z Nvidią nawiążą współpracę, aby dokończyć specyfikację 64bit ARM).


GandalfG @ 2011.03.11 11:22  Post: 462147

Co do narzędzi których używa AMD to oni akurat mają jedne z lepszych i oprócz tego tworzą własne.
http://developer.amd.com/CPU/Pages/default.aspx
http://developer.amd.com/gpu/Pages/default.aspx

Nie mają jedne z lepszych. Tzn. dobry mają kompilator Open64, ale nie jest to ich twór, a po prostu wszystkim znany świetny kompilator GCC ze zmienioną nazwą (nie znam nikogo kto korzysta z Open64, bo kto używa GCC to używa po prostu GCC (gdzie poprawki są dodawane zarówno przez AMD jak i Intela, czy ARM)) - co nie zmienia jednak faktu, że najlepszy kompilator dla C/C++ to kompilator ICC Intela (ten jest komercyjny). Podobnie sprawa się ma w wypadku AMD CodeAnalyst - to jest zmieniona nazwa profillera OProfile (profiler napisany do profilowania jądra linuksa) - jednak tu też OProfile to jednak mimo, że jest świetny nie jest to co mamy w Intel Vtune (tylko tu też jest płatny) - Intel pomaga tworzyć otwarte rozwiązania i są one dobre... jednak ich zamknięte programy są po prostu lepsze.
Podobnie sytuacja się ma w kartach graficznych - AMD ma narzędzia, ale Nvidia ma zwyczajnie lepsze (tylko tu w przeciwieństwie do Intela dają wszystko za darmo).


SunTzu @ 2011.03.11 12:19  Post: 462163
dla mnie w pełni działający 64bitowy CPU w ARM to jakieś nieporozumienie.

64bit to słuszny kierunek - niektórzy już myślą o 128bit. Mylnie zakładasz, że 64bitowy procesor to tylko ilość adresowanej pamięci - to również możliwość szybszego liczenia większych lub bardziej dokładnych liczb - działania na liczbach 64 bitowych w 32bit po prostu na raz nie mogą iść jedno działanie zajmuje wiele cykli - co w wypadku wydajnych desktopów/serwerów ma zasadnicze znaczenie.
Dodatkowo robienie ilość bitów nie będącą potęgą dwójki robi tak wiele złego, że ciężko sobie aż wyobrazić konsekwencje - jeszcze w wypadku urządzeń jak konsole gdzie system i programy pisane jest od zera specjalnie pod sprzęt ma to sens, ale nie w wypadku gdy systemy i oprogramowanie jest gotowe - wybór innej liczby bitów niż potęga 2 to straszna głupota.

SunTzu @ 2011.03.11 12:19  Post: 462163

No i powtórzę swój argument. Konsole działają świetnie i tam 32bity w zupełności starczą i będą starczyć. Czemu tablety, komórki, które dysponują x-krotnie mniejszym wyświetlaczem miałyby potrzebować, nagle xGB pamięci?

Denver i 64bitowe ARM nie będą w tabletach/telefonach przez lata - ARM 64bitowe instrukcje i Nvidia z Denver atakują rynek wysokowydajnych komputerów stacjonarnych i serwerów - te procki nie będą oszczędnymi prockami do zastosowań mobilnych, a wydajnymi potworami o częstotliwościach procesorów równych x86, a ilości rdzeni zapewne kilkukrotnie więcej niż odpowiedniki x86 - ARM chce zdobyć rynek Desktopów, Serwerów, a pewnie i nawet superkomputerów (tu bez 64bit to raczej marnie).

SunTzu @ 2011.03.11 11:51  Post: 462155
@up
Mają świetne, ale np. kompilator OpenCL nie jest już taki wpsaniały intel, który ma 'tyle' tu wspólnego robi lepszy

Akurat tu ostatnio też się zmieniło - AMD teraz zoptymalizowała implementację, wykorzystuje SSE i działa nawet szybciej niż implementacja Intela (obie testowane na procku intela).
cyrix133Zobacz profil
Poziom ostrzeżenia: 0%
cyrix1332011.03.11, 16:57
-7#31
nvidia jak zwykle wyprzedza konkurencje.....innowacyjność zawsze była u nvidii na wysokim poziomie...
losiuZobacz profil
Poziom ostrzeżenia: 0%
losiu2011.03.11, 17:28
SunTzu @ 2011.03.11 11:51  Post: 462155
@up
Mają świetne, ale np. kompilator OpenCL nie jest już taki wpsaniały intel, który ma 'tyle' tu wspólnego robi lepszy


Promilus1984 @ 2011.03.11 11:06  Post: 462145
@SunTzu - GPU i CPU pracują nad wspólnym problemem. GPU jedzie na 64bit float i potrzebuje 64bitowych danych z dajmy na to 36bitowego CPU. Z 36 bitowymi ALU, rejestrami i liniami danych. Bezsens. Taki CPU albo prześle 36bit młodsze, a potem 28bit starsze z 8 zerami, albo 2x32bit z 4 zerami. Jak pisałem dziwolągi są dobre w specyficznych przypadkach - to nie jest jeden z tych przypadków. Takim przypadkiem może być np. współpraca z 18 bitowymi A/D lub innymi urządzeniami (oraz softem) przystosowanym do takich właśnie liczb.


Ale po jakiego grzyba GPU? Po co 64bitowy CPU do gier? Ja myślałem, że to raczej do rozwiązań serwerowych. Patrz na konsole i zobacz ile one mają w sumie pamięci.

Ok... zróbmy CPU 256bitowy. Po co? NV będzie się chwaliło, mamy CPU 256bitowy pierwsi na świecie i co z tego? Dla 99,999% użytkowników 64bity są i będą bezużyteczne. Tylko do serwerów.


Niedawno był lament, że ARM to tylko 32 bity i że wielka z tego kupa. Teraz, że będą 64bity i po co to komu - paranoja to mało powiedziane:) A po co GPU? Słyszałeś o głośno promowanym przez NVidie przez ostatnie kilka lat GPGPU? Myślisz, że project Denver to będzie sam rdzeń ARM? Stawiam rękę i nogę, że to będzie 64bit ARM + jakiś wariant rdzeni graficznych od nomen omen NV.
slukaZobacz profil
Poziom ostrzeżenia: 0%
sluka2011.03.11, 17:57
Bitowość - to pierwsza ofiara marketingu w świecie IT.


Cała afera jest o to, że określenie 'bitowości' jest płynne, a w zasadzie było płynne. W zależności jak w marketingu to uznali. Niedopowiedzenia to niestety tych panów i pań specjalność.

Najlepiej by było, jeśli 'iloczyn logiczny' wszytkich bitowości dawał 1 przy 64 bitach, rejestry i licznik i rozkazy i magistrala i adresowanie były 64bitowe. Ale czy przy takim podejściu wszytkie obecne procesory 64 bitowe były by 64 bitowe. Czy może czeka nas 64 bit po raz trzeci?

Intel był ostatni w 64bit..


Jeśli masz na myśli x86-64 to tak, jeśli chodzi o same instrucje 64 bit to nie. Miał IA-64.

8088 operował na liczbach 16 bitowych, ale było to okupione dodatkowym czasem oczekiwania. Gdyby w tym czasie procesory były już wyposażane w pamięć cache to nie zasługiwał by na typowanie go jako najbardziej dziadowski procesor. W porównaniu do niego 8086 był piękny i wspaniały oraz wyraźnie szybszy przy tych samych zegarach.

64bit to słuszny kierunek - niektórzy już myślą o 128bit. Mylnie zakładasz, że 64bitowy procesor to tylko ilość adresowanej pamięci - to również możliwość szybszego liczenia większych lub bardziej dokładnych liczb - działania na liczbach 64 bitowych w 32bit po prostu na raz nie mogą iść jedno działanie zajmuje wiele cykli - co w wypadku wydajnych desktopów/serwerów ma zasadnicze znaczenie.


Cieszył bym się bardzo nawet 256 bitów, rejestrów i instrukcji. Reszta mogła by pozostać na poziomie współczesnych 64 bitowców. Z liczbami 1024 bitowymi było by tyle samo zabawy co obecnie z 256 bitowymi.
*Konto usunięte*2011.03.11, 17:59
-4#34
@up
Tylko tam gdzie trzeba wydajności mamy od dawna PPC, które jest znacznie wydajniejsze.
----------------------
ARM miał się znaleźć w zastosowaniach mobilnych/serwerach gdzie priorytetem nie jest moc, a energooszczędność.... O ile w serwerach super 64bity.....

Większa wydajność, więcej pamięci, wprost perfekcja.

--> Po jakiego grzyba jednak stosować takie rozwiązanie w sektorze mobilnym i tego dotyczyła moja wypowiedź. Jeżeli NV zrezygnuje z 64bitów dla sektora mobilnego tak jak to zrobili z Neon to super... Jednak tego dowiedziałem się z dalszej części dyskusji.


-> Oczywiście znamy możliwości GPGPU... Po co ładować jednak GPU do serwera, który z założenia ma być najbardziej energooszczędnym. W moim serwerze Intela jest GPU AMD? ATI Rage. Sprawdza się idealnie. Strata! Jednak jeżeli chcemy wydajności to jest PPC x krotnie lepszy, Itanium, x86-classic+GPU, które będzie x-krotnie wydajniejsze od takiego ARMowego.
slukaZobacz profil
Poziom ostrzeżenia: 0%
sluka2011.03.11, 18:02
@up

Dodanie 64bitowych rozkazów w ARM to ucieczka do przodu, na razie mało kto z tego skorzysta. Ale jak przyjdzie czas na 64 bitowe oprogramowanie, to nie będzie problemów, że nie ma na czym tego uruchomić.
*Konto usunięte*2011.03.11, 18:09
-3#36
@up
No dobra, czyli kiedy będziemy potrzebowali 64bitów? Armowe konstrukcje osiągną wydajność dzisiejszych konsol przy 28nm.
-> dzisiejsze konsole potrzebują zaledwie 512mb pamięci

Ostatni proces technologiczny w dzisiejszej technologii to zdaję się 10nm. Czyli zakładając, że SoC będzie wydajniejszy wtedy od tego 28nm 8-10krotnie powinno mu wystarczyć 4GB pamięci+PAE.
sevaeZobacz profil
Poziom ostrzeżenia: 0%
sevae2011.03.11, 18:15
SunTzu @ 2011.03.11 17:59  Post: 462242
@up
Tylko tam gdzie trzeba wydajności mamy od dawna PPC, które jest znacznie wydajniejsze.
----------------------
ARM miał się znaleźć w zastosowaniach mobilnych/serwerach gdzie priorytetem nie jest moc, a energooszczędność.... O ile w serwerach super 64bity.....

Fujitsu SPARC64 VII+ ich wszystkich zakasuje i pogodzi. Do boju Fujitsu! :D

EDIT: ew. Oracle
Promilus1984Zobacz profil
Poziom ostrzeżenia: 0%
Promilus19842011.03.11, 18:18
@sevae - no co ty. Albo Tilera, albo godson ^^
sevaeZobacz profil
Poziom ostrzeżenia: 0%
sevae2011.03.11, 18:24
Promilus1984 @ 2011.03.11 18:18  Post: 462250
albo godson ^^

Nieeeeee....

EDIT: Teraz chwila przerwy w dyskusji bo połowa googluje -> sparc, tilera, godson :P :D


*Konto usunięte*2011.03.11, 18:43
@up
wiadomo coś co oracle skrobie przy sparc? To były świetne procki, biły w pewnych zadaniach wszystko się rusza po ziemi. No, ale dawno nie widziałem testu, który na tle dzisiejszych rozwiązań AMD, Intel by mnie utwierdził w tym przekonaniu.

-> Ma wyjśc nowy CPU. 128 wątkowym. Z tego co wiem pojawia się problem ze skalowaniem i to znaczny już powyżej 64 wątków.
Zaloguj się, by móc komentować