25.01.2014 19:21
[#5]
Re: Motorola 68000
@Shredder, post #3
Żeby uściślić nieco...
- szyna danych jest 16-bitowa (czyli można przesłać do/z peryferiów na raz w jednym cyklu 16-bit)
- szyna adresowa jest 24-bitowa (czyli można zaadresować 2^24 bajtów pamięci, przy czym peryferia więc np. chipset, karty rozszerzeń też traktowane są jak pamięć)
- wewnętrzne rejestry są 32-bitowe
To takie laickie wytłumaczenie, ale w skrócie tak :P.
Warto zauważyć, że już w 68020 wszystkie szyny zewnętrzne są 32-bitowe (za wyjątkiem 68EC020, który zachował szynę adresową 24-bit).
Poza tym wystarczyłoby spojrzeć do dokumentacji procesora i wszystko byłoby jasne...
- szyna danych jest 16-bitowa (czyli można przesłać do/z peryferiów na raz w jednym cyklu 16-bit)
- szyna adresowa jest 24-bitowa (czyli można zaadresować 2^24 bajtów pamięci, przy czym peryferia więc np. chipset, karty rozszerzeń też traktowane są jak pamięć)
- wewnętrzne rejestry są 32-bitowe
Czyli jak, przepycham dane 16 bitami, żeby potem mógł policzyć sobie w 32 bitach i potem znowu podzieli na 16 i wypluje?
To takie laickie wytłumaczenie, ale w skrócie tak :P.
Warto zauważyć, że już w 68020 wszystkie szyny zewnętrzne są 32-bitowe (za wyjątkiem 68EC020, który zachował szynę adresową 24-bit).
Poza tym wystarczyłoby spojrzeć do dokumentacji procesora i wszystko byłoby jasne...
25.01.2014 19:37
[#7]
Re: Motorola 68000
@Shredder, post #1
Procesor ma 32-bitowe rejestry adresu i danych, tylko na zewnątrz wyprowadzone są 24-bity adresu i 16-bitów danych. Rozmiar rejestru kwalifikuje procesor jako 32-bitowy, jednak Freescale samo w swojej dokumentacji nie wie czy nazywać to procesorem 16- czy 32-bitowym, na przykład:
http://www.freescale.com/files/32bit/doc/ref_manual/MC68000UM.pdf
Tu piszą, że 68010 to procesor 16-bitowy:
The MC68010 utilizes VLSI technology and is a fully implemented 16-bit microprocessor
with 32-bit registers, a rich basic instruction set, and versatile addressing modes.
A tu, że 68EC000 jest 32-bitowy (HC to wersja ekonomiczna o niskim poborze mocy):
MC68EC000 has an internal 32-bit architecture that is supported by a statically selectable
8- or 16-bit data bus.
Dla mnie to masło maślane, skoro procesor ma 32-bitowe rejestry danych, to jest 32-bitowy jeśli potrafi operować na liczbach 32-bitowych bezpośrednio. Poza tym, przecież 68020 jest już uznawany za 32-bitowy, a programy na nim działają tak samo jak na 68000 od kopa (z małymi wyjątkami). 68020 potrafi także pracować w trybie 16-bitowej szyny jak i 8-bitowej, co nie znaczy, że staje się wtedy procesorem 16 i 8-bitowym.
68000 ma 16-bitową szynę danych, a to znaczy, że jak zaczniesz operować na liczbach przekraczających zakres 16 bitów, to trzeba wczytanie/zapis takiej danej rozbić na dwa cykle.
http://www.freescale.com/files/32bit/doc/ref_manual/MC68000UM.pdf
Tu piszą, że 68010 to procesor 16-bitowy:
The MC68010 utilizes VLSI technology and is a fully implemented 16-bit microprocessor
with 32-bit registers, a rich basic instruction set, and versatile addressing modes.
A tu, że 68EC000 jest 32-bitowy (HC to wersja ekonomiczna o niskim poborze mocy):
MC68EC000 has an internal 32-bit architecture that is supported by a statically selectable
8- or 16-bit data bus.
Dla mnie to masło maślane, skoro procesor ma 32-bitowe rejestry danych, to jest 32-bitowy jeśli potrafi operować na liczbach 32-bitowych bezpośrednio. Poza tym, przecież 68020 jest już uznawany za 32-bitowy, a programy na nim działają tak samo jak na 68000 od kopa (z małymi wyjątkami). 68020 potrafi także pracować w trybie 16-bitowej szyny jak i 8-bitowej, co nie znaczy, że staje się wtedy procesorem 16 i 8-bitowym.
68000 ma 16-bitową szynę danych, a to znaczy, że jak zaczniesz operować na liczbach przekraczających zakres 16 bitów, to trzeba wczytanie/zapis takiej danej rozbić na dwa cykle.
25.01.2014 19:46
[#9]
Re: Motorola 68000
@MaaG^dA, post #8
Tak, ale 8086 ani 286 nigdy nie były przeznaczone do bezpośredniej pracy z 32bitowymi wartościami by 4(!!) krotne zwężenie szyny danych w stosunku do rejestrów miało aż takie znaczenie. 68008 z kolei już na starcie był o połowę gorszy od 68000, a ile byłby od tak samo taktowanego 68020 nawet nie śmiem zgadywać.
25.01.2014 20:30
[#10]
Re: Motorola 68000
@Shredder, post #6
Oj błądzisz, kolego, błądzisz...
Patrz, liczba 16-bitowa to 65535 (w skrócie 64k), w procesorze 16-bitowym rejestry mają po 16 bitów, więc każda wartość przekraczająca 64k, będzie rozbita na dwa rejestry i nie będziesz miał do niej dostępu jako całości, czyli jesli masz liczbę $AABBCCDD ( 2864434397) , to w jednym rejestrze będzie $AABB (43707), a w drugim $CCDD (52445) , więc dla procesora, są to dwie różne wartości, dopiero to Ty jako programista, jesteś odpowiedzialny za to, aby traktować w wybrany przez siebie sposób te dwie wartości jako jedną i wykonywać odpowiednie operacje, tak aby w tych dwóch rejestrach wartości zmieniały się tak jak oczekujesz. Musisz też pilnować rejestrów, bo co się stanie jeśli dodasz do siebie dwie liczby, a ich wynik będzie większy niż 64k? Liczba będzie zajmować dwa rejestry, co jeśli wszystkie są zajęte? Musisz to przewidzieć i kombinować mając do dyspozycji największa liczbę, jaką jest 64k, by to ładnie rozbić na dwa rejestry. Teraz wyobraź sobie jakich trików będziesz musiał używać, aby np dodać do siebie dwie wartości. W procesorze 32-bitowym wystarczy polecenie typu R3=R1+R2 (zapisz w rejestrze R3 sumę rejestru R1 i R2), a w 16-bitowym? Oczywiście, myślę tutaj o assemblerze, bo jak napiszesz program w C to kompilator Ci zastosuje odpowiednie algorytmy automatycznie, będzie kombinował i przerzucał rejestry z pamięci do procesora i odwrotnie, jednym słowem Meksyk. Taki program skompilowany pod procesor 16-bitowy będzie wykonywał się dłużej niż na procesorze 32-bitowym, nawet jeśli obydwa mają 16-bitową szynę danych. A musisz wiedzieć, że procesor, to nie tylko operacje na szynie danych i adresu, ale także na wewnętrznych rejestrach. Różnicy w prędkości natomiast nie będzie, gdy liczby i wyniki ich operacji nie będą przekraczać 64k.
Druga sprawa to szyna adresowa, gdyby miała 16-bitów, to mógłbyś zaadresować, bagatela 64kB, a jeżeli, procesor 16-bitowy posiadałby szerszą niż 16-bit szynę danych, to zapis adresu do rejestru zajmowałby dwa polecenia, w procesorze 32-bitowym jedno. I tym się właśnie będzie różniła praca procesora 16-bitowego i 32-bitowego. W 32-bitowym robisz odczyt 32-bitowej wartości, a procesor, lub właściwie jego część odpowiedzialna za obsługę szyny wykona dwa cykle i załaduje wartość do rejestru, wszystko automatycznie i zupełnie przeźroczyście dla użytkownika (chyba, że bawi się w tkzw. liczenie cykli). Z poziomu procesora 16-bitowego musiałbyś wydać ręcznie polecenie przepisania wartości z pamięci do rejestru, a potem drugi raz do drugiego rejestru, no i dalej musisz traktować te dwie liczby jako jedną, w procesorze 32-bitowym masz wartość 32-bitową w jednym rejestrze, i jest to wartość na której operujesz, a nie dwie liczby, z którymi musisz kombinować. Także określenie "(musi łączyć dzielić, bez sensu) ", zastosowałeś nie do tego procesora co trzeba. MC68000 będzie się zachowywała dokładnie jak procesor 16-bitowy, póki nie będzie operować na wielokrotnie wspominanych przeze mnie liczbach większych niż 64k, jednak tu masz przywilej używania większych niż 16-bitowe wartości bez zbędnego wysiłku, a w 16-bitowcu już nie.
Opis oczywiście dość ogólnikowy, reszta w otchłaniach datasheetów :)
Ostatnia aktualizacja: 25.01.2014 20:32:04 przez sanjyuubi
Patrz, liczba 16-bitowa to 65535 (w skrócie 64k), w procesorze 16-bitowym rejestry mają po 16 bitów, więc każda wartość przekraczająca 64k, będzie rozbita na dwa rejestry i nie będziesz miał do niej dostępu jako całości, czyli jesli masz liczbę $AABBCCDD ( 2864434397) , to w jednym rejestrze będzie $AABB (43707), a w drugim $CCDD (52445) , więc dla procesora, są to dwie różne wartości, dopiero to Ty jako programista, jesteś odpowiedzialny za to, aby traktować w wybrany przez siebie sposób te dwie wartości jako jedną i wykonywać odpowiednie operacje, tak aby w tych dwóch rejestrach wartości zmieniały się tak jak oczekujesz. Musisz też pilnować rejestrów, bo co się stanie jeśli dodasz do siebie dwie liczby, a ich wynik będzie większy niż 64k? Liczba będzie zajmować dwa rejestry, co jeśli wszystkie są zajęte? Musisz to przewidzieć i kombinować mając do dyspozycji największa liczbę, jaką jest 64k, by to ładnie rozbić na dwa rejestry. Teraz wyobraź sobie jakich trików będziesz musiał używać, aby np dodać do siebie dwie wartości. W procesorze 32-bitowym wystarczy polecenie typu R3=R1+R2 (zapisz w rejestrze R3 sumę rejestru R1 i R2), a w 16-bitowym? Oczywiście, myślę tutaj o assemblerze, bo jak napiszesz program w C to kompilator Ci zastosuje odpowiednie algorytmy automatycznie, będzie kombinował i przerzucał rejestry z pamięci do procesora i odwrotnie, jednym słowem Meksyk. Taki program skompilowany pod procesor 16-bitowy będzie wykonywał się dłużej niż na procesorze 32-bitowym, nawet jeśli obydwa mają 16-bitową szynę danych. A musisz wiedzieć, że procesor, to nie tylko operacje na szynie danych i adresu, ale także na wewnętrznych rejestrach. Różnicy w prędkości natomiast nie będzie, gdy liczby i wyniki ich operacji nie będą przekraczać 64k.
Druga sprawa to szyna adresowa, gdyby miała 16-bitów, to mógłbyś zaadresować, bagatela 64kB, a jeżeli, procesor 16-bitowy posiadałby szerszą niż 16-bit szynę danych, to zapis adresu do rejestru zajmowałby dwa polecenia, w procesorze 32-bitowym jedno. I tym się właśnie będzie różniła praca procesora 16-bitowego i 32-bitowego. W 32-bitowym robisz odczyt 32-bitowej wartości, a procesor, lub właściwie jego część odpowiedzialna za obsługę szyny wykona dwa cykle i załaduje wartość do rejestru, wszystko automatycznie i zupełnie przeźroczyście dla użytkownika (chyba, że bawi się w tkzw. liczenie cykli). Z poziomu procesora 16-bitowego musiałbyś wydać ręcznie polecenie przepisania wartości z pamięci do rejestru, a potem drugi raz do drugiego rejestru, no i dalej musisz traktować te dwie liczby jako jedną, w procesorze 32-bitowym masz wartość 32-bitową w jednym rejestrze, i jest to wartość na której operujesz, a nie dwie liczby, z którymi musisz kombinować. Także określenie "(musi łączyć dzielić, bez sensu) ", zastosowałeś nie do tego procesora co trzeba. MC68000 będzie się zachowywała dokładnie jak procesor 16-bitowy, póki nie będzie operować na wielokrotnie wspominanych przeze mnie liczbach większych niż 64k, jednak tu masz przywilej używania większych niż 16-bitowe wartości bez zbędnego wysiłku, a w 16-bitowcu już nie.
Opis oczywiście dość ogólnikowy, reszta w otchłaniach datasheetów :)
Ostatnia aktualizacja: 25.01.2014 20:32:04 przez sanjyuubi
25.01.2014 21:53
[#12]
Re: Motorola 68000
@tygrys, post #11
Nie za bardzo, wg tej interpretacji Pentium I jest procesorem 64 bitowym, bo tyle liczy szerokość jego szyny danych.
Liczenie po szerokościach rejestrów jak najbardziej ma sens, ale nie po szerokościach rejestrów adresowych, bo te muszą mieć taką szerokość, jaką ma szyna adresowa, tylko po szerokościach rejestrów na których dokonuje się obliczeń. W przypadku Z80 i większości innych procesorów 8 bitowych jest to rejestr akumulatora, w przypadku 8086 rejestr ten jest 16 bitowy. 68000 operandy i wyniki obliczeń ładuje do 32 bitowych rejestrów danych. Często mówi się, że o "bitowości" procesora świadczy to jak długą liczbę jest w stanie w jednym cyklu przetworzyć jednostka arytmetyczno-logiczna (ALU). Jak już wcześniej wyjaśniono, 32 bitowe rejestry są olbrzymią wygodą dla programisty w assemblerze, gdzie można jednym rozkazem przetworzyć 32 bitowe liczby, zamiast dzielić je na 16 bitowe kawałki, przetwarzać po kawałku i przy okazji pilnować rozmaitych flag (overflow, negative... ), co dodaje sporo instrukcji.
Do tego taki 68000 wykonuje kod dokładnie taki sam jak w pełni 32 bitowy 68020 (zarówno rejestry, szyna danych, jak i ALU są 32 bitowe), bo 16bitowy 68000 ma te same rozkazy używające 32 bitowych rejestrów. Nie ma tak jak w przypadku x86 osobnego kodu 16, oraz 32bitowego, różniących się użytymi instrukcjami assemblera i szerokością przetwarzanych w rejestrach danych. Oczywiście 32 bitowa ALU w 68020 wykona ten sam kod znacznie szybciej niż 16 bitowa ALU w 68000 (przy tym samym taktowaniu), ale będzie to ten sam kod. Takie cuda w przypadku 286 i 386 są niemożliwe.
Ostatnia aktualizacja: 25.01.2014 22:12:30 przez wali7
Liczenie po szerokościach rejestrów jak najbardziej ma sens, ale nie po szerokościach rejestrów adresowych, bo te muszą mieć taką szerokość, jaką ma szyna adresowa, tylko po szerokościach rejestrów na których dokonuje się obliczeń. W przypadku Z80 i większości innych procesorów 8 bitowych jest to rejestr akumulatora, w przypadku 8086 rejestr ten jest 16 bitowy. 68000 operandy i wyniki obliczeń ładuje do 32 bitowych rejestrów danych. Często mówi się, że o "bitowości" procesora świadczy to jak długą liczbę jest w stanie w jednym cyklu przetworzyć jednostka arytmetyczno-logiczna (ALU). Jak już wcześniej wyjaśniono, 32 bitowe rejestry są olbrzymią wygodą dla programisty w assemblerze, gdzie można jednym rozkazem przetworzyć 32 bitowe liczby, zamiast dzielić je na 16 bitowe kawałki, przetwarzać po kawałku i przy okazji pilnować rozmaitych flag (overflow, negative... ), co dodaje sporo instrukcji.
Do tego taki 68000 wykonuje kod dokładnie taki sam jak w pełni 32 bitowy 68020 (zarówno rejestry, szyna danych, jak i ALU są 32 bitowe), bo 16bitowy 68000 ma te same rozkazy używające 32 bitowych rejestrów. Nie ma tak jak w przypadku x86 osobnego kodu 16, oraz 32bitowego, różniących się użytymi instrukcjami assemblera i szerokością przetwarzanych w rejestrach danych. Oczywiście 32 bitowa ALU w 68020 wykona ten sam kod znacznie szybciej niż 16 bitowa ALU w 68000 (przy tym samym taktowaniu), ale będzie to ten sam kod. Takie cuda w przypadku 286 i 386 są niemożliwe.
Ostatnia aktualizacja: 25.01.2014 22:12:30 przez wali7
25.01.2014 22:03
[#13]
Re: Motorola 68000
@tygrys, post #11
Chyba nie odróżniasz pojęcia "ilości" od "rozmiaru" kolego, no i jesteś w błędzie.
http://pl.wikipedia.org/wiki/Architektura_32-bitowa
http://pl.wikipedia.org/wiki/MC68000
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC68000 - The industry's lowest cost 32-bit microprocessor, the MC68000......
http://www.cpu-world.com/CPUs/68000/
Ostatnia aktualizacja: 25.01.2014 22:18:20 przez sanjyuubi
http://pl.wikipedia.org/wiki/Architektura_32-bitowa
http://pl.wikipedia.org/wiki/MC68000
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC68000 - The industry's lowest cost 32-bit microprocessor, the MC68000......
http://www.cpu-world.com/CPUs/68000/
Ostatnia aktualizacja: 25.01.2014 22:18:20 przez sanjyuubi
25.01.2014 22:27
[#14]
Re: Motorola 68000
@wali7, post #12
Dokładnie, 68010 nie był zbyt mocno ulepszoną wersją 68000, ale 68020 już tak, wyprowadzili tam pełną 32-bitową szynę danych, skrócili cykl pamięci, kilka rozkazów zostało zoptymalizowanych, kilka dołożonych, jednak jest to właściwie ten sam rdzeń tylko ulepszony, wszystko jest ze sobą kompatybilne z wyjątkiem kilku instrukcji, które maja inne przywileje. Z biegiem czasu Motorola ulepszała swój rdzeń, dodawała różne bajery, zmieniała niektóre instrukcje itd, i tak doszła do 68060, procesora skalarnego, który dalej jest kompatybilny na poziomie kodu z 68000 (kickstart z A600 uruchomi się na 68060 normalnie), z wyjątkiem kilku instrukcji, które wycięto i trzeba je emulować.
Rejestry adresowe, to oczywiste, że muszą mieć taką samą szerokość, ale nie wpiszesz 32-bitowego adresu procesorem 16-bitowym w jednym cyklu do rejestru adresowego 32-bitowego, chyba, że jest jakaś specjalna instrukcja.
Ostatnia aktualizacja: 25.01.2014 22:31:47 przez sanjyuubi
Rejestry adresowe, to oczywiste, że muszą mieć taką samą szerokość, ale nie wpiszesz 32-bitowego adresu procesorem 16-bitowym w jednym cyklu do rejestru adresowego 32-bitowego, chyba, że jest jakaś specjalna instrukcja.
Ostatnia aktualizacja: 25.01.2014 22:31:47 przez sanjyuubi
25.01.2014 22:40
[#15]
Re: Motorola 68000
@wali7, post #12
Ja tylko sprostuję, co sam trochę namieszałem, oczywiście ALU nie musi (i raczej rzadko to robi) przetwarzać tego co wczyta w jednym cyklu. Chodzi bardziej o zdolność do bezpośredniego przetwarzania liczb o danej szerokości, bez dzielenia ich na kawałki.
Powiem szczerze, nie pamiętam ilu bitowy ALU ma 68000. Pisząc poprzedni post byłem pewien, że 16 bit, teraz nie jestem taki pewien. Muszę jeszcze poszperać w sieci. Inna sprawa, że szerokość ALU nie ma większego znaczenia - jeżeli jest wąska, to procesor musi się sporo "naobracać" zanim przerobi np. liczbę 16 bit, ale może to zrobić (o ile ma taką instrukcję w liście rozkazów). Jednak na zewnątrz CPU efekt może być dokładnie ten sam, poza oczywiście ilością cykli CPU niezbędnych do wykonania danej instrukcji.
Z punktu widzenia implikacji dla całej rodziny CPU, struktura rejestrów i podobieństwo list rozkazów (co wpływa na kompatybilność) jest zdecydowanie ważniejsza niż szerokość ALU. Nie mówiac już o szerokości szyny danych, bo to interesować może jedynie inżyniera projektującego komputer, względnie programistę który chce wiedzieć jak wiele danych w określonym czasie jest w stanie wymieniać między CPU a pamięcią.
Powiem szczerze, nie pamiętam ilu bitowy ALU ma 68000. Pisząc poprzedni post byłem pewien, że 16 bit, teraz nie jestem taki pewien. Muszę jeszcze poszperać w sieci. Inna sprawa, że szerokość ALU nie ma większego znaczenia - jeżeli jest wąska, to procesor musi się sporo "naobracać" zanim przerobi np. liczbę 16 bit, ale może to zrobić (o ile ma taką instrukcję w liście rozkazów). Jednak na zewnątrz CPU efekt może być dokładnie ten sam, poza oczywiście ilością cykli CPU niezbędnych do wykonania danej instrukcji.
Z punktu widzenia implikacji dla całej rodziny CPU, struktura rejestrów i podobieństwo list rozkazów (co wpływa na kompatybilność) jest zdecydowanie ważniejsza niż szerokość ALU. Nie mówiac już o szerokości szyny danych, bo to interesować może jedynie inżyniera projektującego komputer, względnie programistę który chce wiedzieć jak wiele danych w określonym czasie jest w stanie wymieniać między CPU a pamięcią.
25.01.2014 22:52
[#16]
Re: Motorola 68000
@sanjyuubi, post #14
W przypadku 8bitowców 16 bitowe rejestry adresowe (PC) były bardzo częste, tak było w przypadku 8080, Z80, czy 6502.
Oczywiście operowanie na nich wymagało więcej czasu niż w przypadku 8 bitowych rejestrów. Gdyby te CPU miały rejestry PC mniejsze, to nie mogłyby adresować pełnych 64 kB.
A 68000 akurat ma odwrotnie - jego rejestry adresowe są szersze niż szerokość magistrali adresowej, co więcej można operować w tych rejestrach na pełnych 32 bitach, które zostaną obcięte do 24 bitów (taka jest magistrala adresowa).
Oczywiście operowanie na nich wymagało więcej czasu niż w przypadku 8 bitowych rejestrów. Gdyby te CPU miały rejestry PC mniejsze, to nie mogłyby adresować pełnych 64 kB.
A 68000 akurat ma odwrotnie - jego rejestry adresowe są szersze niż szerokość magistrali adresowej, co więcej można operować w tych rejestrach na pełnych 32 bitach, które zostaną obcięte do 24 bitów (taka jest magistrala adresowa).
25.01.2014 23:10
[#17]
Re: Motorola 68000
@Shredder, post #1
oczywiście że 32bit bo ma rejestry 32bit w których trzyma wskaźniki do pamięci które też są 32bitowe a to jest wyznacznikiem ile CPU ma 'bitów' a nie szyny danych czy szerokość ALU
całe te tzw 16bit wynikało tylko i wyłącznie ze słabiutkiej wydajności tego procesora w wykonywaniu kodu 32bit. Z tym że i tak była lepsza niż kombinacje cuda wianki jakie trzeba było wyczyniać na prawdziwych procesorach 16bit aby wykonywać operacje na większych liczbach tudzież obsłużyć więcej pamięci od 64KB
czyli 68000 to CPU 32bit z 24bit szyną adresową, 16bit szyną danych i 16bit ALU
BTW. podobnym wynalazkiem był Pentium 4 który w n-tej rewizji uzyskał magicznie 64bit. Każdy wie że to były rdzenie 32bit i widać to było po takiej sobie wydajności w 64bit ale z praktycznego punktu widzenia był to CPU 64bit. Wewnętrzna realizacja nie wpływa na ilość bitów tylko eksponowane ISA
całe te tzw 16bit wynikało tylko i wyłącznie ze słabiutkiej wydajności tego procesora w wykonywaniu kodu 32bit. Z tym że i tak była lepsza niż kombinacje cuda wianki jakie trzeba było wyczyniać na prawdziwych procesorach 16bit aby wykonywać operacje na większych liczbach tudzież obsłużyć więcej pamięci od 64KB
czyli 68000 to CPU 32bit z 24bit szyną adresową, 16bit szyną danych i 16bit ALU
BTW. podobnym wynalazkiem był Pentium 4 który w n-tej rewizji uzyskał magicznie 64bit. Każdy wie że to były rdzenie 32bit i widać to było po takiej sobie wydajności w 64bit ale z praktycznego punktu widzenia był to CPU 64bit. Wewnętrzna realizacja nie wpływa na ilość bitów tylko eksponowane ISA
25.01.2014 23:28
[#18]
Re: Motorola 68000
@XoR, post #17
Nie wiem czy dobrze kombinuję, ale "sciachanie' szyny danych było jakby wymogiem rynku, aby nie stosować par pamięci które były bardzo drogie. I wymóg obłożenia 2 banków byłby w tamtych czasach "nierynkowy".
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ę ?
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ę ? 
26.01.2014 08:12
[#21]
Re: Motorola 68000
@XoR, post #17
oczywiście że 32bit bo ma rejestry 32bit w których trzyma wskaźniki do pamięci które też są 32bitowe a to jest wyznacznikiem ile CPU ma 'bitów' a nie szyny danych czy szerokość ALU
Pudło. 8051 i wiele innych procków ma wyspecjalizowany rejestr przeznaczony do poruszania się po pamięci, w tym konkretnym przypadku DPTR jest 16 bitowy, może być nawet 24 bitowy, a procesor nadal jest tylko 8.
całe te tzw 16bit wynikało tylko i wyłącznie ze słabiutkiej wydajności tego procesora w wykonywaniu kodu 32bit
Nieprawda. Całe te 16 bit wynikało ze względów ekonomicznych.
czyli 68000 to CPU 32bit z 24bit szyną adresową, 16bit szyną danych i 16bit ALU
A skąd wzięło ci się to 16bit ALU? rozumiesz, że w takiej sytuacji 32bitowe rejestry nic nie znaczą i procesor jest tak szybki jak inne 16bit? Bo np. żeby zrobić addc z 2 32 bitowych wartości musi wykonać tak czy siak kilka operacji? Właśnie. A 68000 tego nie robi.
http://www.freescale.com/files/32bit/doc/ref_manual/MC68000UM.pdf
Zapoznaj się z sekcją 8. Czy to jest kilka razy więcej cykli? Nie. Ergo ALU jest 32b
26.01.2014 09:20
[#22]
Re: Motorola 68000
@Ender, post #19
pozostanie przy 32-bitach w przypadku 68060 zamiast (częściowa) przeprowadzka na 64-bity jak w przypadku Intela, czy to był dobry pomysł
W praktyce 64 bitowa architektura procesora ma niewielki wpływ na wzrost wydajności (w stosunku do 32 bitowej), adresowanie powyżej 4GB dla klasycznej Amigi jest bez znaczenia. Poza tym sam procesor to nie wszystko, aby go rozsądnie wykorzystać potrzebna jest odpowiednia szyna danych i adresowa oraz układy, pamięci, a to koszty, koszty, koszty.
No i oczywiście 64 bitowy system i oprogramowanie.
.
26.01.2014 11:26
[#24]
Re: Motorola 68000
@Pinto, post #20
Nie można powiedzieć, że procesor 68000 jest w pełni 32-bitowy, bo jest to hybryda z 32-bitową architekturą wewnętrzną, 24-bitową szyną adresową (w rzeczywistości 23-bitową - brakuje najmłodszego bitu) oraz 16-bitową szyną danych. Powszechnie zalicza się go do procesorów 16-bitowych ze względu na "najwęższe gardło", jakim jest właśnie szyna danych.
26.01.2014 11:52
[#25]
Re: Motorola 68000
@cholok, post #23
At one time, then, one 32-bit address and one 16-bit data calculation can take place within the MC68000. This speeds instruction execution time considerably by processing addresses and data in parallel. The MC68000 also operates on 32-bit data. This is usually done by taking two passes of 16-bit data, one for the lower word and one for the upper word. This is reflected in the execution time of many 16- and 32-bit instructions
W takim wypadku jest to 16 bitowy procesor, tyle że dość inteligentnie zbudowany - w zasadzie w takiej formie by przyszłe procesory z pełnymi 32b miały odpowiednio bogatą i powiedzmy 100% kompatybilną platformę programową. Dziwne są tylko te czasy wykonywania instrukcji bo nie licząc trybu bezpośredniego nieraz w long jest nawet szybciej niż word/byte. Swoją drogą bardzo sprytny zabieg - stworzyć instrukcje operujące na 32b operandach, zrobić 32b rejestry i bazować na 32b przetrzeni adresowej mając tylko 16bitowe ALU. Czyli tanie podwaliny pod coś szybszego z możliwością pisania od razu pod docelowy sprzęt. x86 tego nie miało. Program napisany na 8086 czy 286 posiadał wszystkie jego ograniczenia na 386. Program napisany na 68000 mógł rozwijać skrzydła na 020/030.
26.01.2014 13:46
[#26]
Re: Motorola 68000
@abcdef, post #25
Tak, projektanci 68k kierowali się czymś o czym rzadko się mówi (chociaż nierzadko się stosuje): forward compatibility. Chodzi o zastosowanie w obrębie całej rodziny produktu pewnych ustandaryzowanych rozwiązań. Często w początkowych etapach mogą one stanowić pewną trudność techniczną, bądź zwyczajnie są rozwiązaniem wydającym się być na wyrost (np. 32 bit rejestry w 68000). Jednak na dalszych etapach rozwoju rodziny produktów nie trzeba kombinować jak koń pod górę aby można było wprowadzać nowe rozwiązania techniczne, patrz mnogość trybów pracy w rodzinie x86, dzięki czemu kolejne procesory mogły adresować więcej RAM niż poprzednik (np. 8086>>80286), albo mogły pracować na kodzie 32 bit (80286>>80386), i wiele innych. Intel stosował tu nadrzędną zasadę backward compatibility, czyli robimy pod dzisiejsze potrzeby, a rozwojem i zmianami będziemy się martwić w przyszłości, zachowując zgodność z poprzednikami.
Ostatnia aktualizacja: 26.01.2014 13:47:38 przez wali7
Ostatnia aktualizacja: 26.01.2014 13:47:38 przez wali7
26.01.2014 21:10
[#27]
Re: Motorola 68000
@abcdef, post #25
Czyli innymi słowy MC68000 to taki niedorobiony procesor 32-bitowy lub 16-bitowy wykraczający poważnie poza swoją specyfikację. Pytanie brzmi, czy pisząc program w assemblerze pod MC68000, pisze się jak pod 16 czy 32 bitowy procesor? Nawet jeśli ALU jest 16-bitowe, to czy z punktu widzenia kodu, nie jest to całkowicie przeźroczyste?
26.01.2014 23:36
[#28]
Re: Motorola 68000
@sanjyuubi, post #14
nie jest tak do konca kompatybilne jak piszesz, zapominasz od dodaniu cache do 020, a to eliminuje b.czesto programy dokonujace samomodyfikacji kodu. trik stosowany na 68000 w celu odzyskania kilku cykli...
68000 dla programisty/kodera jest procesorem 32bit, a to czy wew. bedzie operowal na 8/16/32/64/128 bitach jest sprawa tutaj wtorna widoczna wlasciwie tylko w tabeli cyklow...
68000 dla programisty/kodera jest procesorem 32bit, a to czy wew. bedzie operowal na 8/16/32/64/128 bitach jest sprawa tutaj wtorna widoczna wlasciwie tylko w tabeli cyklow...
26.01.2014 23:53
[#29]
Re: Motorola 68000
@cholok, post #23
Akurat ALU jest 16-bitowe, tylko jest ich 3 jednostki.
tak, tylko odbija sie to tylko wlasciwie na 2 instrukcjach, mnozenia i dzielenia (mul. 16b x16b wynik 32b, div. 32b /16b wynik 16b), dodawanie, odejmowanie, rotacje, przesuniecia, logiczne sa w pelni 32b... instrukcje mnozenia i dzielenia sa b.powolne na 68000, gdyby mialy operowac szerzej pewnie bylby prawie nieuzywalne
. 27.01.2014 02:07
[#30]
Re: Motorola 68000
@sigma2pi, post #28
Dodanie cache nie wpływa na kompatybilność kodu z punktu widzenia rdzenia, a jedynie ujawnia mizerne jego wykonanie. Cache nie wchodzi w skład architektury procesora, a jest jego peryferią/dodatkiem, który można wyłączyć i pracować bez niego. Powodem owych niekompatybilności, jest pewne cecha tegoż dodatku, a mianowicie, gdy procesor zapisze jakąś wartość do pamięci pod adres X, a adres ten jest już w cache, to nie zostanie on uaktualniony. Dlatego, gdy procesor będzie chciał odczytać ponownie wartość z adresu X to cache podsunie mu nieaktualną wartość tej komórki pamięci. Programiści, którzy piszą samo-modyfikujące się programy vel wirusy, powinni czyścić cache po modyfikacji kodu, a że 68000 nie miała w ogóle cache, to lenistwo dało o sobie znać jak wprowadzono lepsze procesory.