27.01.2014 08:19
[#34]
Re: Motorola 68000
@cholok, post #32
przeciez napisalem post wczesniej, ze odbija sie to w tabeli cyklow, dla kodera procesor mimo to jest 32b, musi jedynie uwzglednic nieco dluzszy cykl wykonania niektorych instrukcji, jezeli bierze to pod uwage, bo wielu zrzuca to na barki kompilatorow i kompiluje kod 32b... Gdyby zadac pytanie czy 68000 jest procesorem 64bit, oczywiscie nie jest, a program wymagalby calkowitego przepisania. Czy jest procesorem 16bit, tez nie jest, bo mozna op. na 32b - model .L dla zdecydowanej wiekszosci instrukcji i rejestry adresowe sa 32b - niezaleznie od ilosci bitow branych pod uwage...
27.01.2014 08:32
[#35]
Re: Motorola 68000
@sanjyuubi, post #31
triki sa rozne, przesuniecia bitowe dla (* i / przez 2), tabele mnozen czy dzielen... w niektorych przypadkach w ogole uzywa sie wlasnych procedur itd.. wszystko zalezy od kontekstu. przypadek 2*2 to mozna zrobic dwojako, dodawaniem i przesunieciem bitowym :) i nie ma to nic wspolnego z 16bit ALU, bo tak samo zrobilby koder na jakims i7 czy 6502.
27.01.2014 08:39
[#36]
Re: Motorola 68000
@sigma2pi, post #34
No cóż w pentium masz 64 bitowe integery (MMX) i floaty (x87) obsługiwane, a nikt nie twierdzi, że to 64 bitowy procesor. Prawda, możliwości adresowe i tak 32/36b ale zauważ, że możliwości adresowe 6502 (czy 8051) to 16bit a nikt nie twierdzi, że to procesor 16bitowy. Pod 68000 pisze się program (dodam w asm, bo w C pod każdy tak można pisać nie licząc samego ograniczenia pamieci) jak pod 32bit, ale to nie oznacza, że jest 32bit. Trochę inną drogę obrał ARM bo masz w jednym procku 2 zestawy instrukcji, 32bitowe ARM (jeśli zależy na wydajności) i 16 bitowe Thumb (jeśli na gęstości kodu), ale procek jest 32bitowy. Pierwszym 32bitowym 68k jest w tej sytuacji 68020 i jego uboższa wersja EC020. Bo to, że motorola dodała do mikrokodu obsługę rozkazów na 32b wykorzystując 16bitowe jednostki arytmetyczno-logiczne nic nie zmienia, potrzeba więcej operacji na ALU by takie coś przetworzyć jak i na każdym innym 16 bitowym procesorze obrabiającym long (int).
27.01.2014 09:36
[#37]
Re: Motorola 68000
@abcdef, post #36
68000 jest akurat dosc przejrzystym procesorem, natomiast Pentium MMX to inna inszosc i jest procesorem wymieszanym, bedac 32bit procesorem x86, posiada rejestry specjalnego przeznaczenia SIMD i instrukcje SIMD - nie zmieniaja flag procesora..., bo tym jest MMX - jednostka SIMD, dzisiaj niektore procesory 64bit maja nawet 256/512bit jednostki SIMD.
27.01.2014 09:56
[#38]
Re: Motorola 68000
@sigma2pi, post #37
Ech, piszę o typie natywnie wspieranych danych. MMX działa przez rejestry FPU (x87) owszem, natomiast jest to właśnie od 486DX integralny układ samego procesora więc nie ma sensu traktować tego jak dwa oddzielne byty. MMX wspiera 64 bitowego integera i tryb packed 2x32bit oraz 4x16 jeśli mnie pamięć nie myli. Tak samo najnowsze AVX wspierają nadal jedynie 4x64 lub 8x32b, ale nie typ 128b czy 256bit per se. To jak dokładnie Pentium MMX wspierał 64bit long long int jest bez znaczenia, wspierał ten typ w mikrokodzie tak jak 32b wspierane jest przez 68000. Nie czyni to pierwszego procesorem 64b ani drugiego 32b.
27.01.2014 10:38
[#39]
Re: Motorola 68000
@Voyox, post #18
@Voyox & Ender
w momencie kiedy procesory zaczęły mieć pamięć cache i superskalarność ekonomiczne stało się zwiększenie szyny danych bo procesor i tak operował zawsze na danych z cache a te lepiej kopiować w trybie burst w większych blokach niż te których procesor aktualnie potrzebuje na zasadzie że jeśli procesor chce odczytać np. adres 0x3847 to najprawdopodobniej za chwilę odczyta 0x3848 i mając 64bit można te dwa adresy odczytać za jedną operacją odczytu. Zmiesza się tym ewentualny czas oczekiwania procesora na nowe dane. Dwa razy szybciej też można zapisywać dane z cache do pamięci. Miło to mniejsze znaczenie w pierwszych modelach taktowanych z prędkością szyny FSB ale już gdy powstawały modele np. 133MHz taktowane 2x prędkością szyny z mnożnikiem 2x miało to ogromne znaczenie. Bez 64bit procesor by się dusił dużo bardziej. Kolejne modele z mnożnikiem 2.5x czy nawet 3x skożystały jeszcze bardziej.
68060 miał 32bit szynę danych bo w zasadzie to taki wynalazek przeznaczony do specyficznych zastosowań i miał bezpośrednio zastępować w nich 68040 z którym był elektrycznie kompatybilny. W tamtym czasie główni odbiorcy tych procesorów albo padli (Atari i Commodore) albo przerzucili się na RISC więc miało byś oszczędnie i przez to chociażby 68060 nie miał pełnej kompatybilności programowej. Pentium dla odmiany był robiony jako procesor który miał zarabiać miliardy dolarów i nie liczyły się koszty aby uzyskać 100% kompatybilność czy aby nie odbiegać wydajnościowo od wyrastających jak grzyby po deszczu RISCów i właśnie dzięki 64bit szynie się to udało.
Zastanawiam się też czemu mało spotykamy takich idealnych procków np. 32bit rejestr na 32 bit szyna danych.. Taki chyba jest 68030 czy się mylę ?
A jak sądzicie pozostanie przy 32-bitach w przypadku 68060 zamiast (częściowa) przeprowadzka na 64-bity jak w przypadku Intela, czy to był dobry pomysł wtedy i czy z naszego klasycznego poziomu był/jest? Tylko łopatologicznie.
w momencie kiedy procesory zaczęły mieć pamięć cache i superskalarność ekonomiczne stało się zwiększenie szyny danych bo procesor i tak operował zawsze na danych z cache a te lepiej kopiować w trybie burst w większych blokach niż te których procesor aktualnie potrzebuje na zasadzie że jeśli procesor chce odczytać np. adres 0x3847 to najprawdopodobniej za chwilę odczyta 0x3848 i mając 64bit można te dwa adresy odczytać za jedną operacją odczytu. Zmiesza się tym ewentualny czas oczekiwania procesora na nowe dane. Dwa razy szybciej też można zapisywać dane z cache do pamięci. Miło to mniejsze znaczenie w pierwszych modelach taktowanych z prędkością szyny FSB ale już gdy powstawały modele np. 133MHz taktowane 2x prędkością szyny z mnożnikiem 2x miało to ogromne znaczenie. Bez 64bit procesor by się dusił dużo bardziej. Kolejne modele z mnożnikiem 2.5x czy nawet 3x skożystały jeszcze bardziej.
68060 miał 32bit szynę danych bo w zasadzie to taki wynalazek przeznaczony do specyficznych zastosowań i miał bezpośrednio zastępować w nich 68040 z którym był elektrycznie kompatybilny. W tamtym czasie główni odbiorcy tych procesorów albo padli (Atari i Commodore) albo przerzucili się na RISC więc miało byś oszczędnie i przez to chociażby 68060 nie miał pełnej kompatybilności programowej. Pentium dla odmiany był robiony jako procesor który miał zarabiać miliardy dolarów i nie liczyły się koszty aby uzyskać 100% kompatybilność czy aby nie odbiegać wydajnościowo od wyrastających jak grzyby po deszczu RISCów i właśnie dzięki 64bit szynie się to udało.
27.01.2014 10:56
[#40]
Re: Motorola 68000
@XoR, post #39
Owszem, ale 060 w CT60/63 ma przez FPGA dostęp do SDRAM, który tak czy siak trochę wpływa na wydajność, a dodatkowo przez PLX dostęp do PCI przez co karty mają znacznie szersze pasmo gfx<->cpu i gfx<-> ram; co za tym idzie jednak w pewien sposób wydajność procka była delikatnie dławiona przez DRAM
27.01.2014 11:17
[#41]
Re: Motorola 68000
@Voyox, post #18
Ściachanie szyny danych to zabieg typowo marketingowy, mniej pinów, mniejsza obudowa, mniejsza cena. Wkładanie dwóch banków, nie jest wymogiem, bo te procesory mają dynamiczną szynę (w MC68000 chyba jest zablokowana na 16-bitach), aż do 68030. 32bit rejestr i 32bit szyna danych jest już od 68EC020, czyli tak jak w A1200, pełna wersja 68020 ma za to jeszcze pełną szynę adresową. Sytuacja zmienia się w przypadku 68040, który obsługuje już tylko 32bitową szynę.
27.01.2014 14:50
[#42]
Re: Motorola 68000
@abcdef, post #38
Fpu i Simd to oddzielne bloki, pisanie o ich zintegrowaniu w jednym chipie tego nie zmienia!. To na jak szerokich rejestrach operuja nie ma znaczenia przy okreslaniu bitowosci procesora, bo oba bloki sa po to zeby efektywniej przetwarzac dane w toku wykynawania programu na 32bit/64bit procesorze. Podobnie instrukcja MOVEM nie zmienia bitowosci 68000, chociaz mozna zaliczyc taka instrukcje do SIMD :).... O tym ile bitow ma procesor decyduja instr. ktore bezposrednio oddzialuja na flagi operujac na maks. szerokosci rejestru - pomijajac juz nawet kwestie dt. Rej. PC czy szerokosci adresu. Tak sklada sie, ze w 68000 jest 32bit(w zasadzie przyczepic mozna sie tylko do mul i div), podobnie jak w Pentium, a nie podobnie jak w 6502 czy 8088.
68000 Od strony ISA jest 32b z malymi zastrzezeniami, a od strony logiki ukladu bardziej 16b. Pierwsze ma znaczenie projektantow softu, a drugie dla projektantow hardware. Wystarczy to oddzielic i robi sie jasniej :).
68000 Od strony ISA jest 32b z malymi zastrzezeniami, a od strony logiki ukladu bardziej 16b. Pierwsze ma znaczenie projektantow softu, a drugie dla projektantow hardware. Wystarczy to oddzielic i robi sie jasniej :).
27.01.2014 14:57
[#43]
Re: Motorola 68000
@sigma2pi, post #42
No to przecież nikt się nie czepia Instruction Set które przecież dziedziczy w pełni 32 bitowe 68020, kwestia jest właśnie mikroarchitektury gdzie nie można już nazwać tego 32bit. A jeśli chodzi o MMX to owszem, z reguły jest to SIMD (single instruction multiple data), ale dla wielkości 64bitowych to SISD czyli dokładnie to samo co zwykły proc. Jeśli chodzi o integer mul/div to oczywiście niektóre procki mają to sprzętowe, jak jest programowe zawsze zajmuje wiele, wiele cykli.
27.01.2014 17:58
[#44]
Re: Motorola 68000
@abcdef, post #21
do czasu wykonania rozkazu oprócz samej operacji arytmetycznej dolicza się kilka innych operacji w tym dekodowanie instrukcji. Dlatego też kod 32bit na 68000 nie wykonuje się 2x dłużej mimo że ALU musi wykonać każdą operację 32bit dwa razy. Gdyby ALU było 32 bitowe to nie było by żadnego powodu nazywać tego procesora 16 bitowym
dla mnie to ISA definiuje 'bitowość' procesora a nie szerokość samych jednostek wykonawczych czy szyn adresowych i danych. Zresztą 68000 i 68030 na szynie 16bit są z zewnątrz bardzo podobne, dlaczego więc tylko 030 ma być nazywany 32bit skoro oba mają 32bit zestaw instrukcji wraz z wygodną 32bitową płaską przestrzenią adresowania pamięci?
dla mnie 68000 jest 32bitowcem który lepiej działa z kodem 16bit bo ma 16bit ALU
dla mnie to ISA definiuje 'bitowość' procesora a nie szerokość samych jednostek wykonawczych czy szyn adresowych i danych. Zresztą 68000 i 68030 na szynie 16bit są z zewnątrz bardzo podobne, dlaczego więc tylko 030 ma być nazywany 32bit skoro oba mają 32bit zestaw instrukcji wraz z wygodną 32bitową płaską przestrzenią adresowania pamięci?
dla mnie 68000 jest 32bitowcem który lepiej działa z kodem 16bit bo ma 16bit ALU
27.01.2014 18:34
[#45]
Re: Motorola 68000
@abcdef, post #43
Intelowskie wynalazki takie jak MMX, (MultiMedia eXtensions lub Matrix Math eXtensions)
zestaw ten to strzał w kolano. Programiści omijali to szerokim łukiem, bo sprawniej i szybciej programowało się tradycyjne jednostki..
MMX
Motorola 68k
Ostatnia aktualizacja: 27.01.2014 18:39:51 przez Voyox
zestaw ten to strzał w kolano. Programiści omijali to szerokim łukiem, bo sprawniej i szybciej programowało się tradycyjne jednostki..
MMX
Motorola 68k
Ostatnia aktualizacja: 27.01.2014 18:39:51 przez Voyox
27.01.2014 19:35
[#46]
Re: Motorola 68000
@XoR, post #44
Niestety, ale nie mogę się z tym zgodzić. Zobacz sobie takie małe cudeczko jak Renesas H8. Masz 32 bitowe rejestry (fizycznie), które można rozdzielić na 16 bitowe, a dolne 16 bit nawet na dwa 8 bitowe. Procek jest 16 bitowy z 24 bitową przestrzenią adresową. ISA wspiera operacje na 32b danych. A jest 16 bitowy bo ma 16bit ALU. Nikt z niego na siłę 32b nie robi. EC020 nawet przy wyłączonym cache w operacjach na 32b będzie i tak odpowiednio szybszy od 68000 właśnie ze względu na to, że ten typ jest natywny dla ALU - ustawiasz rejestry, ustawiasz linie sterujące, mija cykl lub dwa i na wyjściu wynik. Żadnych hokus pokus "pobierz dolne 16bit liczby A, pobierz dolne 16bit liczby B, dodaj, zapamiętaj w C, przestaw na górne połówki... dodaj ..." Więc skoro nie można powiedzieć, że szerokość rejestrów decyduje, nie można powiedzieć, że obsługa danego typu danych w ISA decyduje to czemu tak trudno uwierzyć, że akurat szerokość ALU jest tu decydująca?
28.01.2014 01:17
[#48]
Re: Motorola 68000
@abcdef, post #46
Niestety, ale nie mogę się z tym zgodzić.
a ja zgadzam sie z tym co napisal XoR. Nic dodac, nic ujac. Gdyby zamknac 68000 w czarnym pudelku i pozostawic tylko model programowania procesora to 68000 jest procesorem 32b, podobnie jak kompatybilni z 68000 kolejno jego kuzyni 020/030/040 i 060.
Na tej samej zasadzie w rodzinie x86 taki 386SX jest rownie 32b co 486DX lub Pentium.
28.01.2014 01:27
[#49]
Re: Motorola 68000
@abcdef, post #43
ale dla wielkości 64bitowych to SISD
owszem, ale nie zbudujesz tylko na tej jednostce SIMD programu, bo potrzebujesz CPU, w tym przypadku Pentium (32b CPU), odwrotnie jest to juz wykonalne... dlatego jest to tylko kolejny koprocesor obok FPU, a wlasciwie wypierajacy FPU kolejny koprocesor.
ps. notabene, wiele kompilatorow x86 dokonuje tylko wlasnie takiej optymalizacji zamieniajac instrukcje FPU na identyczna SSE (SISD)...
28.01.2014 08:21
[#51]
Re: Motorola 68000
@abcdef, post #50
bo H8 jest 16 bitowym procesorem, a nawet z tego co jest napisane na wiki 8/16bit, a Tobie chodzi pewnie H8S i H8SX, ktore sa 32bit, choc ten pierwszy 16/32bit tzn. z trybem pracy 32bit.
http://en.wikipedia.org/wiki/H8_Family
Tych procesorow nie mozna jednak porownac do 68000, ktory od poczatku ma 32bit rejestry ogolnego przeznaczenia. Natomiast w H8 takie rejestry dokoptowano, czyli podobnie raczej jak w x86 niz 68k :).
http://en.wikipedia.org/wiki/H8_Family
Tych procesorow nie mozna jednak porownac do 68000, ktory od poczatku ma 32bit rejestry ogolnego przeznaczenia. Natomiast w H8 takie rejestry dokoptowano, czyli podobnie raczej jak w x86 niz 68k :).
28.01.2014 08:33
[#52]
Re: Motorola 68000
@abcdef, post #50
Po co właściwie ten spór?
68000 powszechnie określa się jako 16/32 bit. Jak wszyscy wiemy, tabela czasów wykonania instrukcji arytmetycznych wyraźnie pokazuje wydajność procesora na poziomie konstrukcji 16 bitowych, co jak najbardziej pozostaje w zgodzie z wiedzą o 16 bitowej ALU tego procesora. Zaś z uwagi na przyjęty w rodzinie 68k model programowy, podporządkowany nadrzędnej zasadzie forward compatibility, procesor posiada 32 bitowe rejestry danych, dzięki czemu tworzony kod można zakwalifikować (wg. przyjętych np. dla rodziny x86 kryteriów) jako 32-bitowy. Z tym, że w przypadku 68k takich podziałów i definicji nie ma, ponieważ innego modelu kodu tutaj nie ma :) . Co najwyżej można stworzyć kod zoptymalizowany pod konkretne listy rozkazowe, oraz czasy wykonania konkretnych procesorów z rodziny, czy ich specjalne mozliwości (np. superscalar dla 68060), ale z "bitowością" nie ma to nic wspólnego.
Powszechnie zresztą wiadomo, że 68020 jest "pierwszym w pełni 32 bitowym" procesorem w rodzinie, więc niższe zapewne nie są "pełne" ;) .
Na pewno nie ma co stosować tutaj definicji przyjętych dla innych rodzin procesorów, ponieważ każda rodzina rządzi się trochę własnymi prawami, oraz konkretne modele wnoszą różniące się między rodzinami ulepszenia.
Wracając do dyskusji z SIMD (albo MMX), dodam tylko, że te jednostki są w zasadzie osobnymi koprocesorami (jak FPU z 68040, czy Altivec w PPC). Bo wtedy... to już kosmos, czy będziemy się sprzeczać, że 68k z FPU jest prockiem 80 bitowym, skoro takie ma rejestry (w przypadku 68k traktowane na równi z własnymi rejestrami CPU) i w takiej precyzji dokonuje obliczeń?
Zostańmy przy definicji producenta, tym bardziej, że nie są to czarne skrzynki i dokładnie wiemy co jest w środku. I cieszmy się, że w Amigach jest taki fajny i ciekawy procek, oraz smućmy, że Motorola nie rozwijała tej bardzo udanej rodziny.
68000 powszechnie określa się jako 16/32 bit. Jak wszyscy wiemy, tabela czasów wykonania instrukcji arytmetycznych wyraźnie pokazuje wydajność procesora na poziomie konstrukcji 16 bitowych, co jak najbardziej pozostaje w zgodzie z wiedzą o 16 bitowej ALU tego procesora. Zaś z uwagi na przyjęty w rodzinie 68k model programowy, podporządkowany nadrzędnej zasadzie forward compatibility, procesor posiada 32 bitowe rejestry danych, dzięki czemu tworzony kod można zakwalifikować (wg. przyjętych np. dla rodziny x86 kryteriów) jako 32-bitowy. Z tym, że w przypadku 68k takich podziałów i definicji nie ma, ponieważ innego modelu kodu tutaj nie ma :) . Co najwyżej można stworzyć kod zoptymalizowany pod konkretne listy rozkazowe, oraz czasy wykonania konkretnych procesorów z rodziny, czy ich specjalne mozliwości (np. superscalar dla 68060), ale z "bitowością" nie ma to nic wspólnego.
Powszechnie zresztą wiadomo, że 68020 jest "pierwszym w pełni 32 bitowym" procesorem w rodzinie, więc niższe zapewne nie są "pełne" ;) .
Na pewno nie ma co stosować tutaj definicji przyjętych dla innych rodzin procesorów, ponieważ każda rodzina rządzi się trochę własnymi prawami, oraz konkretne modele wnoszą różniące się między rodzinami ulepszenia.
Wracając do dyskusji z SIMD (albo MMX), dodam tylko, że te jednostki są w zasadzie osobnymi koprocesorami (jak FPU z 68040, czy Altivec w PPC). Bo wtedy... to już kosmos, czy będziemy się sprzeczać, że 68k z FPU jest prockiem 80 bitowym, skoro takie ma rejestry (w przypadku 68k traktowane na równi z własnymi rejestrami CPU) i w takiej precyzji dokonuje obliczeń?
Zostańmy przy definicji producenta, tym bardziej, że nie są to czarne skrzynki i dokładnie wiemy co jest w środku. I cieszmy się, że w Amigach jest taki fajny i ciekawy procek, oraz smućmy, że Motorola nie rozwijała tej bardzo udanej rodziny.
28.01.2014 09:55
[#54]
Re: Motorola 68000
@wali7, post #52
Zaś z uwagi na przyjęty w rodzinie 68k model programowy, podporządkowany nadrzędnej zasadzie forward compatibility, procesor posiada 32 bitowe rejestry danych, dzięki czemu tworzony kod można zakwalifikować (wg. przyjętych np. dla rodziny x86 kryteriów) jako 32-bitowy.
Model programowania postawilby jako nadrzedny w tym sporze, bo to od oprogramowania zalezy w gruncie rzeczy czy procesor uznamy za 16b czy 32b. Na 68000 operuje sie w 32b modelu programowania tj. niemal identycznym z 68060. Reszta istotna jest dla sprzetowcow i ew. koderow asemblerowych ktorzy zawsze musza brac pod uwage nietypowosc swoich docelowych wyborow, jezeli chca uzskac jak najlepiej zoptymalizowany kod.
28.01.2014 10:03
[#55]
Re: Motorola 68000
@abcdef, post #46
68000 to procesor 32bit który powstał w czasach 16bitowych procesorów i nie był w ogóle optymalizowany dla kodu 32bit ze względów ekonomicznych. Do tego stopnia nie był optymalizowany że nie ma w nim oprócz ISA nic co by miało szerokość 32 bit
w ogóle to w przeciwieństwie do np. Amigi nie ma ścisłej definicji tego co jest 32bit a co nie jest więc cała ta dyskusja nie znajdzie żadnego finału innego niż to że każdy postawi za punkt honoru bronić swoich mojszych racji
dla mnie przykładowo Pentium 4 Prescott w wersji bez EM64T jest cepem 32bit a z nim już jest 64bit mimo że każdy wie że te 64bit to emulacja w microcode. I tak pierwsze Semprony na rdzeniu AMD K8 które miały sztucznie zablokowane 64bit są dla mnie procesorami 32bit mimo że tam nie ma fizycznie nic co by miało 32bit, tylko ISA jest zablokowane w microcode.
I tak jakby ktoś napisał w FPGA a potem zrobił z tego ASIC procesor zgodny z M68K mający ALU 8bit. Ba, najlepiej jakby zrobił go zgodnego pinami z 68000 i wrzucił do Amigi to dla mnie taki wynalazek dalej byłby 32bitowym procesorem bo miałby ISA 32bit i nie ważne że 16bit operacje wykona szybciej a 8bit jeszcze szybciej
Jeśli Twoja definicja jest inna to widocznie masz inne zapatrywanie na ten temat, niekoniecznie bardziej błędne od mojego ale to to już musiałby rozpatrzyć ktoś to wymyślił 'bity' a jak wiemy to tylko taki komputerowy żargon bez ścisłej definicji.... czyli temat bez rozwiązania
w ogóle to w przeciwieństwie do np. Amigi nie ma ścisłej definicji tego co jest 32bit a co nie jest więc cała ta dyskusja nie znajdzie żadnego finału innego niż to że każdy postawi za punkt honoru bronić swoich mojszych racji
dla mnie przykładowo Pentium 4 Prescott w wersji bez EM64T jest cepem 32bit a z nim już jest 64bit mimo że każdy wie że te 64bit to emulacja w microcode. I tak pierwsze Semprony na rdzeniu AMD K8 które miały sztucznie zablokowane 64bit są dla mnie procesorami 32bit mimo że tam nie ma fizycznie nic co by miało 32bit, tylko ISA jest zablokowane w microcode.
I tak jakby ktoś napisał w FPGA a potem zrobił z tego ASIC procesor zgodny z M68K mający ALU 8bit. Ba, najlepiej jakby zrobił go zgodnego pinami z 68000 i wrzucił do Amigi to dla mnie taki wynalazek dalej byłby 32bitowym procesorem bo miałby ISA 32bit i nie ważne że 16bit operacje wykona szybciej a 8bit jeszcze szybciej
Jeśli Twoja definicja jest inna to widocznie masz inne zapatrywanie na ten temat, niekoniecznie bardziej błędne od mojego ale to to już musiałby rozpatrzyć ktoś to wymyślił 'bity' a jak wiemy to tylko taki komputerowy żargon bez ścisłej definicji.... czyli temat bez rozwiązania
28.01.2014 10:19
[#56]
Re: Motorola 68000
@XoR, post #55
Dlaczego więc tak uparcie pomijasz przedstawione przeze mnie H8 z 32bitowymi rejestrami, 16 bitowym ALU, baa, sprzętową mnożarką 16x16 (której 68000 nie ma) będące przez producenta czyli obecnie renesas bezlitoście przedstawiane jako procesor (czy w niektórych przypadkach single chip computer) 16bit bez żadnych "łamane przez". Ktoś stwierdził, że o bitowości decyduje ISA - właśnie H8/300h/H8S zdaje się tej tezie przeczyć. Zresztą jak cortexy z listą rozkazów thumb (16bit) gdzie nie zmienia to faktu, że jest to cpu 32bit. Dalej - ktoś stwierdził, że to kwestia rejestrów - to podałem przykłady przeczące tej tezie. To co innego zostało?
Jeśli zaś chodzi o prescotty em64t itp. to mają po 2 ALU 32bit (zamiast REE taktowanego 2x wyższym zegarem) na potok (i oczywiście tyle samo AGU) więc jest i tak lepiej niż w 68000 gdzie alu jest jeden (i 2 agu). Natomiast z tego samego powodu nie nazwałbym tego procesorem 64 bitowym.
Jeśli zaś chodzi o prescotty em64t itp. to mają po 2 ALU 32bit (zamiast REE taktowanego 2x wyższym zegarem) na potok (i oczywiście tyle samo AGU) więc jest i tak lepiej niż w 68000 gdzie alu jest jeden (i 2 agu). Natomiast z tego samego powodu nie nazwałbym tego procesorem 64 bitowym.
28.01.2014 10:32
[#57]
Re: Motorola 68000
@abcdef, post #53
Nie wiem po co idziesz w zaparte skoro przyklad z rodzina H8 jest nietrafiony i rozwoj H8 przypomina duzo bardziej rozwoj x86 niz 68k tzn. dokoptowano rejestry do 32 bitow i zmieniono nazwe, nawet podobnie jak w przypadku x86 tj. dodano literke E, tylko tutaj przed R[numerek rejestru] zmieniajac przy tym takze kodowanie instrukcji, co wlasnie dowodzi nietrafnosci tego przykladu.
Gdyby H8 mogl rzeczywiscie operowac (H8/300 nie mogl) od poczatku na 32b to zabieg ten bylby bezsensowny. Sens ma tylko w przypadku zachowania kompatybilnosc z 16b ISA. Wyglada to zupelnie inaczej niz w przypadku 68k.
H8/300H jest okreslany jako 16/32 bitowy, co majac powyzsze na uwadze ma sens.
Gdyby H8 mogl rzeczywiscie operowac (H8/300 nie mogl) od poczatku na 32b to zabieg ten bylby bezsensowny. Sens ma tylko w przypadku zachowania kompatybilnosc z 16b ISA. Wyglada to zupelnie inaczej niz w przypadku 68k.
H8/300H jest okreslany jako 16/32 bitowy, co majac powyzsze na uwadze ma sens.
28.01.2014 10:40
[#58]
Re: Motorola 68000
@XoR, post #55
abcdef bardziej patrzy od strony sprzetowej, a ja czy Ty od strony ISA, tylko My przyznajemy, ze od strony sprzetowej 68000 jest w wiekszej czesci 16bit, ale od strony ISA to procek niemal w pelni 32b z 32b ISA.
Osobiscie uwazam ISA za wazniejsze w okresleniu bitowosci, wiec tak jak napisales, gdyby ALU byl 8bit to tak dalej jak napisales...
Osobiscie uwazam ISA za wazniejsze w okresleniu bitowosci, wiec tak jak napisales, gdyby ALU byl 8bit to tak dalej jak napisales...
28.01.2014 10:54
[#60]
Re: Motorola 68000
@sigma2pi, post #57
zmieniajac przy tym takze kodowanie instrukcji, co wlasnie dowodzi nietrafnosci tego przykladu
Eeee, czy Renesas nie pisze, że H8SX jest kompatybilny wstecz z H8( S/300h/300)? Aaa, pisze. Ergo 32bit w 16 bitowym H8S działa z pełną prędkością na 32 bitowym H8SX. Czyli jak między 68000 a 68020. Dodatkowo zupełnie nie trafiłeś z rejestrami bo jeśli w H8 zapiszesz bajt do R0L i bajt do R0H możesz nimi niezależnie operować. W przypadku x86-64 nie. Można operować albo calym 0:63, albo 0:31, albo 0:15, ale już nie 16:31, 32:63 etc. Prawda, H8/300 jest 8 bitowe, ale także ma 16 bitowe rejestry i instrukcje a nikt go nie nazywa 16bit! Jeszcze raz - ja się nie napinam, ale jak ktoś pisze, że to "ISA" decyduje gdy dałem wyraźne przykłady, że nie to mnie denerwuje. Skoro nie ISA, nie rejestry (po to właśnie dałem przykład z MMX!!!), nie szyny danych i adresów to co? Jakiś musi być składnik względem którego "bitowość" się określa.