@sigma2pi, post #88

• Odpowiedz

@Radov, post #91

PS. Jest jeszcze jeden sposób na ocenę bitowości Motoroli 68000...

Świetny sposób, ale jest jeden problem.... Brakło mi tuszu w drukarce, a nie wiem ilu bitowy procesor ma ona zainstalowana... Poza tym nie mam kury...

• Odpowiedz

@Radov, post #91

• Odpowiedz

@Radov, post #91

PIV ma 128bitowej rejestry i udostepnia 128bitowy model programistyczny.

nie jest to prawda, bo 128bitowe rejestry dostepne sa tylko dla instrukcji SSE, a nie zbudujesz zadnego programu opierajac sie tylko na tych instrukcjach.

Albo przynajmniej 64bitowym jeśli weźmiemy pod uwagę rejestry ogólnego przeznaczenia./quote]

PIV to dosc dluga linia. Prescot ktorys jest juz 64bit.

[quote]instrukcje programu nie są tożsame z mikropoleceniami, oraz metodą ich obsługi przez układ

nie ma to wielkiego znaczenia, bo i tak nikt poza producentem nie ma do tego nikt wiecej wgladu.

Teoria którą głosisz jest więc bardzo prosta, ale potyka się już o najmniejsze kamyki.

raczej kolejna nieudana proba jej obalenia .

OK, Dowód jak powyżej: nie jest problemem, żeby układ o architekturze 8bitowej udostępniał 64 bitowy interfejs programistyczny oraz nie jest problemem, żeby układ o architekturze 64bitowej udostępniał interfejs 8bitowy. Założenie, że wykonywanie kodu X-bitowego determinuje X-bitową architekturę można rozbić o kant łysej, nieogolonej.

o ile w dol to dziala tj. 68000 pozwala korzystac z 16b, a nawet 8b, o tyle procesor 8 bitowy nie jest w stanie fizycznie wykonac kodu 64 bitowego. poza tym ja wyraznie napisalem kod, a nie interfejs, bo to sa dwa rozne pojecia.

Wiec jak ten dowod nie jest problemem to prosze bardzo go przedstawic, w koncu potyka sie o cytuje, "najmniejsze kamyczki", a nie Mount Everest

• Odpowiedz

@sigma2pi, post #94

@sanjyuubi

A patrząc przez pryzmat Twojej teorii, każdy procesor 8-bitowy mógł zaadresować maksymalnie 256 bajtów pamięci, bo taką musiał mieć szynę adresową, a tu patrz procesor w C64 ma 16-bitową szynę adresową, która pozwala mu adresować 64kB bez stronicowania, więc na pewno musi być 16-bitowy.
(...)
Biorąc pod uwagę Twoje stwierdzenie, że ile bit ma szyna adresowa, tylu bitowy jest procesor, pytam się ponownie jakim procesorem jest 68EC020, a jakim 68020, a jakim MOS6510?

A mógłbyś zacytować precyzyjnie - konkretnie jakiej mojej teorii i którego stwierdzenia?

Przecież od samego początku piszę, twierdzę i udowadniam, że ciężko sklasyfikować MC680000 do jakiejś rodziny X-bitowości, a już szczególnie tylko na podstawie 1 parametru (bez wykazania dlaczego właśnie on miałby być istotny, dlatego opcja z kurą jest najlepsza). Zaznaczyłem też, że dotychczasowa klasyfikacja pochodząca ze świata PC - KTÓRA ROZPOCZĘŁA TEN WĄTEK - jest niespójna, a to ona zaliczała MC68000 do klasy 16bit. Tylko jakbyśmy nie tupali nóżką, to jest ona obowiązująca, nikomu nie chce się zmieniać, a zastępowanie złej gorszą nie ma sensu...

BTW. Bodajże Intel 8030 ma szynę 8bitową, dorzucamy 1 latcha i mamy adresowanie 16kb - dlatego właśnie zaznaczyłem, że obowiązująca definicja jest niespójna....

Jakbyś zaczął katalogować procesory, które wszystkie komponenty w sobie mają tak samo bitowe, to by wyszło, że 90% z nich nie można zaliczyć do żadnej kategorii

A o czym ja (kurcze!!!) od samego piszę? Właśnie o tym!!! Z tą różnicą, że układ łączący w sobie architekturę 32bit, 24bit i 16bit klasyfikuję jedynie jako układ, uwaga, "łączący w sobie architekturę 32bit, 24bit i 16bit" - bez nacisku na konkretną z wartości i podkreślam, że klasyfikacja na podstawie szerokości danych widocznych z punktu widzenia programisty jest bez sensu.

Byłbym wdzięczny za uważne (i ze zrozumieniem) czytanie wiadomości.

Problem jest natomiast z tym przykładem 64-bitowy procesor będzie udostępniał zawsze 64-bitowy jak to nazywasz model programistyczny, chyba, że mu powyłączasz wszystkie 56-bitów, czyli tak jakbyś użył 12% krzemu, z którego jest zrobiony, no bo reszta będzie stała zawsze bezczynnie (a z większym balastem szybciej się tonie)

Bzdury piszesz: VLIW jest powszechnie stosowaną technologią i nie ma najmniejszego problemu, żeby architektura układu zakładała dużą szerokość bitową, udostępniając jednocześnie "wąski" model programistyczny. Z utylizacją tranzystorów zdecydowanie powyżej 12%. "Architektura układu" to nie tylko zbiór rejestrów, szyn i mikropoleceń - ale także forma przetwarzania danych.

64-bitowy procesor wykonany z 8-bitowych jednostek to nadal 64-bitowy procesor, tylko powolny.

A co konkretnie wynika z tego, że programistycznie widoczna 64bitowość jest pozorna, a układ w rzeczywistości ma architekturę 8bitową. Przez co nawet nie jesteś w stanie stwierdzić, czy układ to kilka równolegle pracujących jednostek 8bit, czy jedna odpowiednio szybko taktowana (co jest wyborem projektowym: prostota dla większego taktowania). Zrobiliśmy więc woltę i ponownie ponawiam kwestię, że pozorna (programistyczna) szerokość nic nie mówi o bitowości układu.

ale skoro każdy z nich wykonuje kod 32b lub 64b, to pozostają właśnie w takiej kategorii, przy czym jest to zawsze kategoria umowna.

Architektura ukłądu jest ustalona i niezależna od umowy. Jeśli twierdzisz, że układ jest Xbitowy, podczas gdy nie został zaprojektowany jako Xbitowy - na co przykładem jest wcześniej wspomniane FPU - to jest to ignorancja, a nie kwestia umowna.

Kod obliczeniowy dla jednostek wektorowych może opierać się i na obiektach 256 bitowych, działać na 64bitowych GPR'ach, ale świat i tak zaklasyfikuje program jako 32bitowy, jeśli pod takie adresowanie został napisany....

@sigma2pi

nie ma to wielkiego znaczenia, bo i tak nikt poza producentem nie ma do tego nikt wiecej wgladu.

OK. Konstrukcja układu nie ma znaczenia, za ty nam powiesz ile ma bitów. Fakt. Na ten 'argument' nie mam odpowiedzi.

Ignorancja nie jest argumentem. Producent zaprojektował układ przy określonych założeniach, a słowa mają swoje znaczenia. Nie możesz maznąć sobie kredką po opakowaniu i zadeklarować ileś-tam-prosto-z-głowy bitów.

- To ilu bitowy jest ten procesor co mi go pan sprzedał?
- To wspaniały układ 32 bitowy!
- to dlaczego adresuje 16MB
- aaaa... bo to takie niepełne 32... adresuje 24bity...
- a dlaczego wartość 32bit liczy w 2 operacjami?!!!
- ....mówiłem 24bity??? Miałem na myśli 16bitów.... ALU jest 16bitowe!!!
- chcę zwrotu pieniędzy!!!
- not anderstend.. ....rifands no posible...

o tyle procesor 8 bitowy nie jest w stanie fizycznie wykonac kodu 64 bitowego.

Chyba coś ci się przyśniło:) Ależ jak najbardziej jest, wszystko zależy od mikropoleceń na które tłumaczone są 'instrukcje procesora' - to te które nie mają dla ciebie wielkiego znaczenia. Nic nie szkodzi na przeszkodzie, by zaprojektować układ o architekturze 8 bitowej realizującej kod 64bitowy.
Może to być układ w pełni 8bitowy, przetwarzający dane bajt po bajcie z pamięci, albo wykorzystujący 64bitowe rejestry/bufory. Zaznaczam to, bo jeszcze napiszesz, że jak ma 1 bufor 64 bit, to jest to układ 64bitowy:)

poza tym ja wyraznie napisalem kod, a nie interfejs,

A w którym konkretnie miejscu widzisz istotną różnicę i dlaczego ona jest istotna? Interfejs (model programistyczny) to cegiełki kodu.

Wiec jak ten dowod nie jest problemem to prosze bardzo go przedstawic, w koncu potyka sie o cytuje, "najmniejsze kamyczki", a nie Mount Everest

Powtórzę jeszcze raz, nawiązując do FPU, które:
- realizazują kod 64 bitowy
- nie są układem 64 bitowym
- zaprojektowane jako układ 64 bitowy nie wykonują 'poprawnie' (zgodnie ze standardem IEEE 754) kodu 64bitowego
- teza, ze realizacja kodu X bitowego oznacza układ X bitowy jest więc fałszywa

Twoja teza nie działa na FPU - co więcej chcesz?

------------------------
BTW. A to nie było tak, że MC68000 w zasadzie nie ma podstawowych rejestrów w ogóle, tylko zrealizowano je jako ciągłą pamięć wybieraną przez nazwane adresy? Jak tak, to MC68000 jest procesorem 0 bitowym!!!

Ostatnia aktualizacja: 31.01.2014 14:36:20 przez Radov

• Odpowiedz

@Radov, post #95

• Odpowiedz

@flops, post #96

@ Ja Was pogodzę w tej wojnie Motorola vs Intel. I tak wszystkie te rozwiązania kasuje SH4, SH4 AL, SH5. Niestety najlepsze jest wypierane przez tańsze. Pierwszy kto rzuci we mnie kamieniem (rybą) jest genderdziewczyną.

• Odpowiedz

@sanjyuubi, post #93

• Odpowiedz

@Ender, post #97

jaki tam najlepszy skoro moja stara komórka ma lepszy procesor i bynajmniej nie jest to SHx

• Odpowiedz

@Ender, post #97

• Odpowiedz

@XoR, post #98

• Odpowiedz

@wali7, post #89

Pamiętam czasy ,, kiedy się "jarałem" parametrami Falcona, nawet że tak powiem marzyłem aby posiadać taki komputer który miażdży Amigę, a rzeczywistość okazała się inna. Amiga okazała się popularniejsza i powstało dosyć sporo fajnego softu...

Prześledziłem całą historię procesorów intela i przypomina ona kwadraturę koła.
Natomiast Motorola ze swoim 68k mogła zdobyć świat, niestety kombinatorstwo zawsze wygrywa i dlatego rozwiązania "mądrzejsze" tonęły a knoty zdobyły świat...

Bardzo mnie ciekawi jak by działały mc 68060 z zegarem powiedzmy 3 Ghz, z wiekszą pamiecią podręczną L2/L3 i powiedzmy choćby 2 rdzeniowo...

• Odpowiedz

@Voyox, post #102

• Odpowiedz

@abcdef, post #103

W zasadzie to AMD dobudowało do 32 pieter kolejne 32 i tak powstało x86-64, ładnie to oznaczaja dziś

wszystkiemu winne AMD bo powinni zaprezentować nową popularną, tanią, wydajną architekturę i przekonać do siebie ludzi zamiast podłączyć respirator do x86.

AMD powodowane było jednym,, STRACHEM,, a ponadto powstała już znów kombinatorska komitywa. Teraz podzielili rynek X86, AMD wzięłło konsole a intel laptopy i skrzynki Della czy HP (i inne składańce).

Wrócę jeszcze do PPC, ciąglę mam wrażenie że ten procek jest herlawy, miał być szokiem względem 68k, a tu oprócz suchych danych w których sie podaje jakie to cuda na kiju w nim drzemią, ja osobiście nie czuję tej mocy...Nawet mi cięzko porównać mojego PowerMaca 2x2,5 Ghz do powiedzmy posiadanego Core2Duo E6850 - 2x3 GHz ..
Jakim to jednakowym programem bym mógł sprawdzić moc Altiveca do intelowskich rozwiązań...

Tu ciekawą dyskujsję znalazłem PPC vs intel

Tu wspomniena O PPC

Ostatnia aktualizacja: 31.01.2014 19:36:40 przez Voyox

• Odpowiedz

@Voyox, post #104

• Odpowiedz

@Radov, post #95

• Odpowiedz

@Radov, post #95

• Odpowiedz

@sanjyuubi, post #107

@sanjyuubi

A proszę bardzo, post 81# i przecząca sobie definicja Twojego autorstwa: (...) No proszę, a przecież użyłeś tej niespójnej definicji do sklasyfikowania 68000 jako procesora 16-bitowego (...)

Echhh.. To ja się cofnę do postu 95# mojego autorstwa:
"Byłbym wdzięczny za uważne (i ze zrozumieniem) czytanie wiadomości."

1) Tematem wątku jest bitowość układu a nie modelu programistycznego układu.
2) Shredder w wiadomości #1 pyta się czy 68000 jest układem 32bit, a nie czy wykonuje on kod 32bit
3) Shredder ma sprzeczne informacje" - jestem pewien, że wynikają ze stosowania przez świat 'powszechnej' definicji X-bitowości". To, że jestem pewien, nie oznacza, że też tak klasyfikuję.
4) Po raz fafnasty powtarzam, że nie klasyfikuję MC68000 do którejkolwiek z architektur. Byłbym bardzo wdzięczny, byś wreszcie nie przypisywał mi rzeczy których nie napisałem.
5) Przywołałem tę mocno kulawę definicję żeby w ogóle wskazać miejsce powstania wątpliwości, bo wcześniejsze pomysły (np. dotyczące szerokości szyny danych) są w tym kontekście nieprawdziwe.
6) Cytując tą definicję wskazywałem miejsca gdzie nie jest spójna (co zacytowałeś), by podkreślić jej oderwanie od stanu faktycznego, a nie jako argument wobec bitowości MC68000.
7) Dodatkowo, interpretuję twoją wiadomość jakobyś zarzucał mi, że powołując się na świat sugeruję, że "skoro świat tak mówi, to tak trzeba tak robić". Nie jest to prawdą. Przytaczam definicję "ogólną" by przyciąć niepotrzebne dywagacje nie związane z pytaniem z wiadomości 1#

Ignorancją to przepełniona jest osoba przedstawiona w tym dialogu, która przeprana marketingowym bełkotem ma zatępioną zdolność do logicznego myślenia.

Nie do końca jestem pewien, czy cię rozumiem, zwróć jednak uwagę na ciekawą kwestię związana z logicznym myśleniem: wiele osób koncentruje się procesie wnioskowania i zapomina, że podstawą są *aksjomaty* - prawdziwe założenia, nie będące przedmiotem wnioskowania. Czy nie jesteś przypadkiem jedną z nich? Analizowałeś swoje aksjomaty? Bo ja swoje tak. Wasze też...

Nie możesz w sensie logiki przeprowadzić prawidłowego procesu wnioskowania, jeśli nie jesteś w stanie udowodnić prawdziwości założeń. Pisząc inaczej: prawdziwość procesu logicznego wnioskowania jest zależna od prawdziwości przyjętych założeń. Niepewne założenia, to niepewne wnioskowanie. Błędne założenia, to błędne wnioski.

Z tego właśnie powodu nie stosuję do oceny X-bitowości kryterium (szyna danych, rejestr), jeśli nie mogę udowodnić poprawności jakiegokolwiek, bo musiałbym je potem przyjąć jako aksjomat przy analizie. Mogę za to szukać błędów i wykluczać. Weżmy na tapetę: "X-bitowość modelu programistycznego oznacza X-bitowość układu cyfrowego":
- Czy jestem w stanie udowodnić, że to założenie jest zawsze prawdziwe? Nie. Nawet nie wiem jak.
- Czy jestem w stanie znaleźć przynajmniej 1 przykład, gdy to założenie jest fałszywe? Tak. Wspomniane przeze mnie układy FPU.
- Wynik: założenie jest błędne, nie można go wykorzystać w procesie logicznego wnioskowania w kontekście układów cyfrowych.

A teraz na chlopski rozum: widzę układ o Xbitowym modelu programistycznym. Nie jest on X bitowy. Co tu więcej dowodzić? Założenie jest błędne... Oczywiście nie będę zabraniał drążyć dalej, ale byłbym wdzięczny o nie zasłanianie się słowem "logika"...

Wewnętrzna struktura procesora obchodzi jedynie dociekliwych, dlaczego jeden procesor robi coś szybciej od drugiego, ale skoro jeden i drugi ma takie same możliwości, to czemu mieliby być w innej kategorii?

Najwidoczniej, żeby merytorycznie udzielić się wątku "Ilu bitowy jest układ?", i zauważyć, że to inne pytanie od: "ilu bitowy model programistyczny układ realizuje."

Biorąc pod uwagę liczbę rozbieżności w budowie procesorów, zdolność wykonywania natywnie x-bitowgo kodu jest jedynym spójnym i logicznym uwarunkowaniem

Jest oparte na błędnym założeniu więc nie jest logiczne. Równie dobrze możesz przyjąć stwierdzenie: "Każdy procesor jest 32 bitowy" - też bardzo spójne, ale również też oparte na błędnym założeniu.
BTW. są procesory realizujące natywnie model 32bit i 64bit - klasyfikacja dałaby więc różne wyniki tego samego modelu zależnie od konfiguracji - wasze założenie jednak nawet nie jest spójne... chociaż aż się boję zapytać jak definiujecie 'spójność'
"Spójność - to taka cecha, że MC68000 jest 32 bit a Radov nie ma racji"

który pozwala na kwalifikację procesora do danego szeregu.

tak. do danego szeregu "układów natywnie realizujących x-bitowy kod". Może raczysz wreszcie zauważyć, że "- "układy natywnie realizujących x-bitowy kod" oraz "układy x-bitowe" to dwie różne klasyfikacje i co najwyżej mają część wspólna? Przy czym Shredder pytał się o to drugie i na ile przejrzałem wątek to nie zaktualizował się na twoją wersję?

Do ignorantów chyba zaliczasz Jay Minera, ponieważ przykładowy dialog poprowadził w swoim przypadku zupełnie inaczej.

Zbyt daleko idący wniosek, ciebie za to zaliczę do medium - bo nie wiem skąd inaczej mógłbyś nabyć wiedza o wyborach JM. JM miał zresztą w 1985r do dyspozycji w pełni 32 bitowe Motorole, więc potraktujmy tę całą historię jako nieudaną próbę dogryzienia mua:)

Tak więc:

przez co wychodzą ze sklepu z radeonem 9200 posiadającym 1GB pamięci, zamiast kilkunastokrotnie lepszym HD4850 z 512MB pamięci, ze świętym przekonaniem i oburzeniem, że sprzedawca się nie znał

...a sigma2pi wyjdzie ze sklepu z układem realizującym 32bitowy model programistyczny ze świętym przekonaniem, że oznacza to ze ma układ 32bitowy i oburzony, bo ludzie mu mówią że nie kupił układu 32bitowego....

• Odpowiedz

@sigma2pi, post #106

o czym Ty piszesz, zaden programista/program nie ma dostepu do mikropow, ten poziom jest domena konstruktorow i projektantow mikroprocesorow, wiec to jest takie gdybanie co bys mogl, bo naprawde nie moglbys nic.

Po czym siadasz do programowania, patrzysz na x-bitowy model programistyczny, grupujesz (optymalnie) instrukcje tak żeby CPU podjął je w jednym takcie zegara i ze zdziwieniem stwierdzasz, że kod jest wykonywany wielokrotnie wolniej niż powinien, a potok nie obsadzony. Co może być tego powodem? No przecież nie mikropolecenia, bo to "domena konstruktorow i projektantow mikroprocesorow" i nie zmienimy tego bo to tylko "takie gdybanie co bysmy mogli, a naprawde nie możemy nic". A już na pewno nie da się sprawdzić jakie mikropolecenia zostały niepotrzebnie wygenerowane, które blokują potok i czy są zamienniki pozbawione wad.

Dla osób zastanawiających się odnośnie czego drwię z sigma2pi, ogólnie i na chłopski rozum:
W zasadzie każda instrukcja to zbiór (czasem wprawdzie 1 elementowy) mikropoleceń dla wnętrzności układu wrzucanych w potok i jest na to prosta specyfikacja. W niektórych przypadkach generowana jest sekwencja 'zapychająca' potok. Instrukcje te mają uzasadnienie przy budowie czytelnego, testowego kodu, ale można je zastąpić bardziej efektywnymi odpowiednikami. Jeśli się o tym wie...

udostepnia 32b model programowania to pozostaje 32b procesorem dla programow i programistow i chocbys tupal ze zlosci i rwal wlosy to za nic tego nie zmienisz.

Ale ja nie tupię ze złości i włosów nie rwę. W zasadzie, a co mnie to obchodzi? Możesz wyjść z Radeonem 9200 z 2GB RAM z przeświadczeniem, że to szybka karta - a wyjdź sobie i z przeświadczeniem że skoro kupiłeś układ realizujący 32 bitowy model programistyczny, to na pewno układ jest 32 bitowy. Dietetyczna kola tez jest dietetyczna, bo tak piszą na opakowaniu. Kogo interesuje co jest w środku?

FPU itp. nie okresla bitowosci procesora, konkretnie CPU, tylko okresla bitowosc FPU, wiec cala ta dywagacja nie ma tutaj odniesienia, no chyba zeby odniesc do innego FPU...

sigma2pi - skoncentruj się. FPU może być takim samym autonomicznym układem jak CPU i nie ma najmniejszego powodu by ten przykład odrzucać. FPU ma swoją bitowść i ma model programistyczny. Nie kupuje teorii, którą glosisz, ale może się mylę?????? Zobaczmy więc:
- biorę implementację FPU z Pentiuma IV jako niezależny procesor
- Realizuje to dziwactwo 64bitowy model
- Zgodnie z teorią układ powinien być 64 bitowy
- patrzę do specyfikacji: 80 bitów
Dlaczego teoria jednak nie działa?
W mojej opinii: bo klasyfikacja na podstawie modelu programistycznego klasyfikuje jedynie względem... modelu programistycznego. A nie bitowości układu, o którą to było pytanie w wiadomości #1. No chyba, że autorowi wątku chodziło jednak o bitowość programistyczną. Albo, żeby ocenić MC68000 jako w pełni 32bitowe niezależnie do budowy i faktów. Jak tak to przepraszam, zamilknę i się więcej nie odezwę

Ostatnia aktualizacja: 01.02.2014 03:21:00 przez Radov

Ostatnia aktualizacja: 01.02.2014 03:26:43 przez Radov

• Odpowiedz

@sanjyuubi, post #107

• Odpowiedz

@Voyox, post #104

AMD zrobiło furorę swoimi K8 które były w swoim czasie jednymi z najlepszych mikroprocesorów 64bit a do tego umożliwiały uruchamianie ogromnej biblioteki oprogramowania X86-32 z prędkością większą niż jakikolwiek inny X86

one miażdżyły wydajnościowo Itanium oraz były wydajeniejsze i chłodniejsze od konkurencyjnych PowerPC G5 oraz zapoczątkowały przesiadanie się serwerów na X86. Dzisiaj większość serwerów jest na X86. Najszybsze procesory z największym IPC i zegarem to też X86

co do PowerPC to oprócz pierwszego modelu który był trochę lepszy od Pentiuma wielkiego szału nie było. Od 68060 te pierwsze PPC nie były lepsze w ALU co tylko obrazuje jak wielki był sens całej tej zmiany Gadki Jobsa o ogromnej przewadze wydajnościowej PPC nad X86 były wyssane z palca co potwierdzały testy oprogramowania OpenSource. To było miejwięcej jak z porównaniem dwóch procesorów X86, jeden był wydajniejszy w jednych rzeczach drugi w innych. Ogólnie X86 'normalne' programy wykonywał lepiej za to miał gorsze SIMD i mniejszą wydajność obliczeń podwójnej precyzji. Nijak się jednak lepsza wydajność FPU ma do ISA...

• Odpowiedz

@XoR, post #112

Miałem sen... A w nim najpierw pojawił się programista i powiedział:
"Napisałem dziś wspaniały kod na 32-bitowy procesor MC68000".
Później pojawił się projektant pewnego nowego komputera, o nazwie Amisia i powiedział:
"Zamontowałem 16-bitowy procesor MC68000 w moim komputerze".
Następnie pojawiła się kura z odrąbaną głową, która biegała po papierowej karcie, o wymiarach 3m x 3m z nadrukowaną strukturą wewnętrzną procesora MC68000. Na karcie tej były oznaczone obszary tranzystorów z poszczególnymi bitowościami, a kura miała paść na jeden z nich i tym samym odpowiedzieć ludzkości na pytanie: "ilu bitowy jest procesor MC68000?". Niestety kura, mimo braku głowy odleciała w krzaki i nikt nie był w stanie jej dogonić. To dowodzi, że nawet ona ma swoje zdanie na ten temat, mimo iż straciła głowę.
Pod koniec śniło mi się, że "Moda na sukces" skończyła się. Niestety, to był tylko sen (proszę nie pisać że był mokry, bo nic nie piłem), ponieważ ten i "nasz" serial trwa do dzisiaj

• Odpowiedz

@Radov, post #109

2) Shredder w wiadomości #1 pyta się czy 68000 jest układem 32bit, a nie czy wykonuje on kod 32bit

Shredder zadaje bardzo ogólnikowe pytanie w poście nr #1, po czym w poście
#3 ( Czyli jak, przepycham dane 16 bitami, żeby potem mógł policzyć sobie w 32 bitach i potem znowu podzieli na 16 i wypluje? ) i 6# ( To nie lepiej ,żeby wszystko szło w 16 bitach??(musi łączyć dzielić, bez sensu) ) wychodzi na jaw, że pyta się (choć pewnie nieświadomie) o bitowość od strony realizacji programu, a ta wynosi 32 bit.

7) Dodatkowo, interpretuję twoją wiadomość jakobyś zarzucał mi, że powołując się na świat sugeruję, że "skoro świat tak mówi, to tak trzeba tak robić". Nie jest to prawdą. Przytaczam definicję "ogólną" by przyciąć niepotrzebne dywagacje nie związane z pytaniem z wiadomości 1#

Na ogólne pytanie powinna być ogólna odpowiedź, której nie ma w przypadku 90% procesorów.

- Czy jestem w stanie znaleźć przynajmniej 1 przykład, gdy to założenie jest fałszywe? Tak. Wspomniane przeze mnie układy FPU.

FPU jest osobnym układem, nie wiem dlaczego wciągasz go w bitowość procesora.

Jest oparte na błędnym założeniu więc nie jest logiczne. Równie dobrze możesz przyjąć stwierdzenie: "Każdy procesor jest 32 bitowy" - też bardzo spójne, ale również też oparte na błędnym założeniu.

Proszę w takim razie, stosując się do swojego logicznego rozumowania i spójności, w jaki sposób realizuje sprzętowo operacje na 32-bitowych liczbach procesor MOS6510 i jak uruchomić na nim 32-bitowy kod. Moje stwierdzenie jest logiczne (mimo, ze może być pozorne, twoje na wstępie mija się z prawdą i nie widzę tu żadnej spójności.

Poza tym jak masz 32-bitowy system operacyjny, to na jakim procesorze chcesz go uruchomić? Idziesz do sklepu i prosisz o 32-bitowy i taki dostaniesz stosując się do normalizacji wg normy natywnie wykonywanego kodu.

W twoim świecie sytuacja wyglądała by tak, że wertowałbyś nieskończoną listę procesorów i zastanawiał się na którym ów 32-bitowy system będzie działał, a na którym nie. Ten procesor ma 32-bitowe ALU, ale 16-bitowe rejestry, a tamten ma 256-bit FPU i 64-bitowe rejestry ale ma 2 16-bitowe ALU, inny ma ma rejestry uniwersalne, inny to, następny tamto... Zamiast wymagań systemu operacyjnego w postaci: 32-bitowy procesor, miałbyś:

minimalne
- 32-bitowe rejestry
- 32-bitowy FPU
- 32-bitome SIMD
- 32-bitowe ALU lub 2 16-bitowe, lub 4 8-bitowe
itd....

Może dla komputerowych snobów byłoby to dogodne do dowartościowywania się w kółkach wzajemnej adoracji i gnębieniu lamerów, ale nie ma żadnego sensu użytkowego, ponieważ jak działa procesor w środku nikogo nie obchodzi, tylko co sobą reprezentuje na zewnątrz, a dla mnie 68000 na zewnątrz reprezentuje rodzinę 32-bitowców i dlatego do takiej dla mnie należy.


Zbyt daleko idący wniosek, ciebie za to zaliczę do medium - bo nie wiem skąd inaczej mógłbyś nabyć wiedza o wyborach JM. JM miał zresztą w 1985r do dyspozycji w pełni 32 bitowe Motorole,

Powiedzmy, że mam kryształową motorolę i w niej wszystko widzę ;) Poza tym, mimo, że JM miał do dyspozycji szybsze Motorole, to nie znaczy, że musiał ich użyć, zwłaszcza, że liczyły się każde pieniądze i jakimś dziwnym trafem A1000 z 7MHz procesorem w komputerze z 16-bitową szyną danych (ale adresy rejestrów są wyrównane do 32-bit) był uważany za komputer wyprzedzający epokę, a dla kasiastych były przecież karty turbo.


więc potraktujmy tę całą historię jako nieudaną próbę dogryzienia mua:)



Ostatnia aktualizacja: 01.02.2014 17:15:03 przez sanjyuubi

• Odpowiedz

@abcdef, post #111

• Odpowiedz

@Radov, post #110

Po czym siadasz do programowania, patrzysz na x-bitowy model programistyczny, grupujesz (optymalnie) instrukcje tak żeby CPU podjął je w jednym takcie zegara i ze zdziwieniem stwierdzasz, że kod jest wykonywany wielokrotnie wolniej niż powinien, a potok nie obsadzony.

Na pewno piszesz o 68000 , bo wydaje mi sie, ze mieszasz cos w kotle nie w ten desen. Nie za bardzo widze w tym zwiazku z bitowoscia procesora. 68000 wykona zazwyczaj szybciej op. na 16b niz 32b i chyba to chcesz mi powiedziec, tak, tylko co to zmienia ?.

skoncentruj się. FPU może być takim samym autonomicznym układem jak CPU i nie ma najmniejszego powodu by ten przykład odrzucać.

moze byc, ale nie jest, osiol tez moze robic za konia i vice versa, tylko kazdy widzi roznice . 68881 ma rejestry 80bit (do pamieci odczyt/zapisuje 96bit) dla op. zmiennoprzecinkowych - wymog IEEE754, operacje na int. wykonuje maks. do 32bit, adres wykonywanej instrukcji przechowuje 32bit rejestr - przestrzen adresow.

Pytanie, ilu bitowy jest 68881 w porownaniu do 68000. To ja zadam pytanie Tobie, a jaki model programistyczny obsluguje 68881, a jaki 68000, golym okiem kazdy widzi, ze osiol to nie kon, poza chyba Toba

Nie mozesz prowadzic takiego porownaniu w oderwaniu od tego faktu

zamilknę i się więcej nie odezwę

z takim rozumowaniem to dobra mysl

Ostatnia aktualizacja: 02.02.2014 02:15:37 przez sigma2pi

• Odpowiedz

@Radov, post #109

sigma2pi wyjdzie ze sklepu z układem realizującym 32bitowy model programistyczny ze świętym przekonaniem, że oznacza to ze ma układ 32bitowy i oburzony, bo ludzie mu mówią że nie kupił układu 32bitowego....

tylko pewnie zatkalby nie jednego z tych ludzi widok dzialajacego natywnie 32 bitowego oprogramowania. A Radov na to, niemozliwe, liczyl na tranzystorach i wyszlo 16bit, a swistak siedzi i zawija w sreberka 32bitowe paczki

--
Zajmowac sie informatyka i nie rozumiec natury informacji

• Odpowiedz

@Radov, post #110

FPU samo w sobie bez instrukcji procesora nic nie byłoby w stanie zrobić dokładnie nic

poza tym dlaczego akurat FPU z P4? nie masz jakiegoś Core i7 aby z niego lepsze FPU wziąć?

P4 to było popularne ponad 10 lat temu

• Odpowiedz

@Radov, post #110

Ale ja nie tupię ze złości i włosów nie rwę. W zasadzie, a co mnie to obchodzi? Możesz wyjść z Radeonem 9200 z 2GB RAM z przeświadczeniem, że to szybka karta - a wyjdź sobie i z przeświadczeniem że skoro kupiłeś układ realizujący 32 bitowy model programistyczny, to na pewno układ jest 32 bitowy. Dietetyczna kola tez jest dietetyczna, bo tak piszą na opakowaniu. Kogo interesuje co jest w środku?

A ty właśnie piszesz jak klient kupujący redeona 9200 z 2GB RAMu i nie jestem pewien, czy byś sam go nie kupił, skoro cały czas patrzysz na to że im większe na niej cyferki, tym produkt jest lepszy. Sama liczba 32-bit nie mówi nic o wydajności procesora, poza tym, że 32-bitowe liczbami operuje się szybciej i wygodniej niż miałoby to miejsce w przypadku8/16bit i to wszystko, to samo
mówi pojemność pamięci na karcie graficznej, załadujesz do nie więcej tekstur i tyle.

Po czym siadasz do programowania, patrzysz na x-bitowy model programistyczny, grupujesz (optymalnie) instrukcje tak żeby CPU podjął je w jednym takcie zegara i ze zdziwieniem stwierdzasz, że kod jest wykonywany wielokrotnie wolniej niż powinien

To jest dopiero świetny przykład kogoś, kto z programowaniem nie ma nic wspólnego, koder planujący wykorzystać taki procesor najpierw czyta jego dokumentację i patrzy na tabele cyklów, zwłaszcza jeśli liczy cykle i ramy czasowe (mówiłem już, ze nie wszystko jest wykonywane w jednym cyklu?). Natomiast sposób w jaki to napisałeś sugeruje, że chodzisz do sklepu i kupujesz 32-bitowe procesory, a potem w domu tupiesz nogami, bo się okazało, że kupiłeś i386, no ale tak to jest jak się sugeruje tylko jednym parametrem, że jest on gwarancją udanego zakupu. A przeciez procesor ma jeszcze coś takiego jak częstotliwość taktowania, podstawkę, szerokość szyny, ilość cache, a każdy z nich jest równie ważny przy doborze pod kątem wydajności. Ocenianie wydajności procesora po samej jego bitowości, a tym bardziej zakładanie z góry jego właściwości, które są w każdym modelu inne jest przykładem wspomnianego radeona9200+2GBRAM jak i zwykłej amatorszczyzny. Prostym przykładem takiej amatorszczyzny jest też kierowanie się wydajnością procesora pod kątem MHz, przy czym większość ludzie wie, że procesor AMD o taktowaniu 1.8GHz potrafił dorównać intelowskiemu 2.4GHz, a także intel pentium M o taktowaniu 2,4GHz bił na głowę pentiumIV 3,2GHz (nie pamiętam, czy też ten mało udany dwurdzeniowy), jak to wytłumaczyć programiście, że na jednym 32-bitowym procesorze coś działa szybciej a na drugim wolniej? Wg Twojej teorii i na jednym i na drugim instrucja powinna być wykonanana w ciągu jednego cyklu, bo procesory są 32-bitowe (lub tak też je nazywają producenci i reszta świata), więc skąd te rozbieżności?


Dla osób zastanawiających się odnośnie czego drwię z sigma2pi, ogólnie i na chłopski rozum:
W zasadzie każda instrukcja to zbiór (czasem wprawdzie 1 elementowy) mikropoleceń dla wnętrzności układu wrzucanych w potok i jest na to prosta specyfikacja. W niektórych przypadkach generowana jest sekwencja 'zapychająca' potok. Instrukcje te mają uzasadnienie przy budowie czytelnego, testowego kodu, ale można je zastąpić bardziej efektywnymi odpowiednikami. Jeśli się o tym wie...

I oczywiście trzeba wstąpić do zakonu na 10 letnią służbę, żeby się o nich dowiedzieć Jest coś takiego co się nazywa doświadczeniem i jest coś takiego jak ignorancja, którą jest zakładanie, że każdy kolejny "prawdziwy" procesor, będzie działała tak samo wydajnie na tym samym kodzie nie studiując jego charkterystyki. Jeśli weźmiesz program zoptymalizowany pod kątem 68030, to nie będzie on zasuwał tak samo na 68060, może nawet zamulać lub nie działać wcale i tak samo na odwrót, a przecież oba są procesorami 32-bit więc w czym problem? W przypadku X86 także można spotkać programy skompilowane pod kątem kompatybilności z i386 lub pod kątem wydajności oznaczone jako i486, i586 i i686.


Na koniec jeszcze ciekawostka, ktorą przez przypadek natrafiłem na wikipedii: http://pl.wikipedia.org/wiki/RISC

cyt:"Obecnie popularne procesory Intel, AMD i VIA z punktu widzenia programisty są widziane jako CISC, ale ich rdzeń jest RISC-owy. Rozkazy CISC są rozbijane na mikrorozkazy (ang. microops), które są następnie wykonywane przez RISC-owy blok wykonawczy. W praktyce okazuje się, że rozwiązanie takie (pomimo wielu znaczących wad) jest podejściem znacznie bardziej wydajnym (szczególnie, że RISC-owy blok wykonawczy jest znacznie bardziej nowoczesny od architektury CISC widocznej dla programisty)."

To jakie są te procesory RISC czy CISC?



Ostatnia aktualizacja: 02.02.2014 13:03:59 przez sanjyuubi

• Odpowiedz

@sanjyuubi, post #119

• Odpowiedz