W dniu 05.03.2023 o 21:45, Dawid Rutkowski pisze:
> niedziela, 5 marca 2023 o 17:55:06 UTC+1 Dariusz Dorochowicz napisał(a):
>> W dniu 2023-03-05 o 17:31, Dawid Rutkowski pisze:
>>> sobota, 4 marca 2023 o 22:04:05 UTC+1 Dariusz Dorochowicz napisał(a):
>>>> W dniu 2023-03-04 o 15:14, Mirek pisze:
>>>>> On 4.03.2023 13:49, heby wrote:
>>>>>
>>>>>> Jeśli dobrze zrozumiałem opis - to raczej magnetofon ze skakaniem
>>>>>> między kawałkami taśmy.
>>>>>>
>>>>> No tak - bardzo trafne porównanie.
>>>>> Tam nie ma procesora - jest tylko zegar, pamięć i coś na kształt
>>>>> licznika rozkazów sterowanego zwrotnie z tejże pamięci.
>>>>> Brakuje przede wszystkim skoku warunkowego... ale żeby sprawdzić warunek
>>>>> trzeba jakiś rejestr, instrukcję ładującą ten rejestr...
>>>>> Raczej bitów nie starczy i w ten sposób się nie da.
>>>>> Trzeba by robić normalny dekoder rozkazów, rejestry itp.
>>>> Kiedyś, bardzo dawno temu, coś podobnego zrobiłem. Sterownik składał się
>>>> z eproma, rejestru i "zegara". Linie danych przez rejestr "wracały" na
>>>> część linii adresowych eproma, inne linie adresowe były sterowane z
>>>> wejść. Potem znalazłem że to się nawet nazywa, ale już nie pamiętam.
>>>> Zapewne zresztą jest na to kilka różnych określeń.
>>>> Trochę zabawy było z rysowaniem grafu przejść.
>>>> W zależności od zawartości eproma realizował różne funkcje.
>>>
>>> Typowy automat.
>>> Czyli procesor i pamięć (w tym pamięć programu) w jednym.
>> Procesorem to tego bym nie nazwał.
>
> Jak przetwarza dane to procesor.
> Nawet jeśli jest to "komputer sterowany przepływem danych".
> Zapewne nie jest to CPU, bo jednak "wszystko w jednym".

Czy ja wiem... Bardziej symulacja układu. Dokładnie to samo można by
było zrobić na bramkach i rejestrze. Sterownik to tak. Komputer to mi
się jakoś nie widzi.

>>> Jeszcze pytanie, czy synchroniczny czy asynchroniczny.
>> Skoro miał zegar i zmiany stanu były możliwe tylko w czasie zbocza tego
>> zegara no to synchroniczny.
>
> No ten tak, łatwiej się projektuje ale więcej krzemu trzeba.
> Coś za coś.

Przede wszystkim można było łatwo zmienić funkcjonalność. Wystarczył
programator epromów. A do rozpisania zawartości parę kartek papieru.

>>> Mnie do dziś zadziwia, że odczyt z pamięci jest asynchroniczny...
>>>
>>> A taki sterownik na PROMie zrobił zrobił Steve Wozniak do odczytu dyskietek -
procesor 6502 był za wolny, by samplować każdą zmianę pola, więc samplował całe bajty
odczytane przez automat - na tyle szybki był.
>> No bo to może całkiem szybko pracować w porównaniu do starych
>> procesorów. Tylko to mało uniwersalne rozwiązanie.
>
> Nikt nie mówi, że jest to "komputer", a tym bardziej "komputer uniwersalny".

Hmmm... Jedyne elementy pamięciowe to eprom i rejestr. Trochę mało jak
na procesor.

> Tak też określił PC-ty jeden wykładowca - procesor od kalkulatora, OS marny i to ma
udawać komputer uniwersalny.
> Jedyne dobre to magistrala PCI.
> To było tak 1999-2000 - hmm, dziwne, że o Linuxie nie wspomniał, a był to akurat
wykład z "systemów operacyjnych" - choć właściwe jedyne co zapamiętałem to SOM-3 i
CROOK - i 4096 "sekcji" w CROOKu.
> Trzeba chyba zajrzeć do notatek.
> Z czego mógł być egzamin???
>
> Ale ale, czemu znów tak o wiele szybciej?
> Procesory zwykle były wolne bo pamięci i tak nie nadążały.
> Ale były tak szybkie jak pamięć pozwalała - pierwsza sprawa to oczywiście odczyt
rozkazów, bo to jest potrzebne na każdy rozkaz (stąd idea RISC miała sens dopiero
przy cache instrukcji), drugorzędna to dane.
> A tu przecież centralnym elementem jest taka sama pamięć.

Tak, ale gdybym dał zegar maksymalnie szybki dla pamięci i rejestru
zmiana stanu mogłaby następować po każdym takcie zegara. Procesor musi
sprawdzić co się zmieniło, obliczyć co ma sie zmienić i wysłać ten stan
na wyjście. Nie ma szans na to żeby to zrobił w jednym takcie.
Oczywiście wszystko sie zmienia kiedy mówimy o rozbudowanej
architekturze z pamiecią cache itd, ale tu nie o taką alternatywę
chodzi. Tu alternatywą był co najwyżej jakiś klon 8085.

Pozdrawiam

DD

do góry

On 06/03/2023 03:26, ptoki (ptoki) wrote:
> Innymi slowy, to co uwazasz ze nie jest procesorem tak naprawde nim jest.

Tak naprawdę, od bardzo dawna używamy stosownego kryterium:

https://pl.wikipedia.org/wiki/Kompletno%C5%9B%C4%87_
Turinga

To, że coś potafi przemieszczać kwadraty na ekranie i liczyć cyferki,
nie czyni z tego jeszcze *komputera*.

> Bo definicja jest na tyle szeroka ze jakby sie uprzec to mozna zrobic bardzo prosty
procesor w ktorym nie bedzie wydzielonych rejestrow, alu, pamieci - tak jak w tej
atarynkowej konsolce.

Jest wątpliwe, czy ten "procesor" jest turing-complete. Tym bradziej, że
zestaw danych i polecań na których pracuje jest nieelastyczny. A tym, co
odróznia CPU od garści TTLi, jest mozliwośc realizacji *dowolnego*
algorytmu.

do góry

On 4.03.2023 13:49, heby wrote:

> Jeśli dobrze zrozumiałem opis - to raczej magnetofon ze skakaniem między
> kawałkami taśmy.

W sumie to włáśnie opisałeś maszynę Turinga. ;)

do góry

Atlantis pisze:

>> Jeśli dobrze zrozumiałem opis - to raczej magnetofon
>> ze skakaniem między kawałkami taśmy.
>
> W sumie to włáśnie opisałeś maszynę Turinga. ;)

E tam, maszyna Turing ma przecież taśmę filmową:

https://youtu.be/E3keLeMwfHY

--
Jarek

do góry

On Mon, 6 Mar 2023 09:08:59 +0100, heby <h...@p...onet.pl> wrote:
> Tak naprawdę, od bardzo dawna używamy stosownego kryterium:
> https://pl.wikipedia.org/wiki/Kompletno%C5%9B%C4%87_
Turinga
> nie czyni z tego jeszcze *komputera*.

Przedpiśca argumentował procesor a nie komputer. Kompletność Turinga
nie definiuje ani procesor ani de facto komputer.

--
Marek

do góry

On 06/03/2023 09:28, Atlantis wrote:
>> Jeśli dobrze zrozumiałem opis - to raczej magnetofon ze skakaniem
>> między kawałkami taśmy.
> W sumie to włáśnie opisałeś maszynę Turinga. ;)

Magnetofon ze skakaniem po taśmie nie jest maszyną Turinga. Nie ma
elementu decyzji zmiany stanu, nie ma elementu pamięci (zapisu). Jest
tylko mechaniczne odtwarzanie sekwencji, zawsze stałej, choć czasami
zależnej od stanu wejścia, przez co graf wydaje sie być w jakims stopniu
interaktywny. Wykorzystywano to nawet w praktyce.

To coś w ten deseń:
https://youtu.be/LaBq9GyuaPA?t=300

Aby była jasność: w latach 70, jak opowiadał nauczyciel zawodowy,
sterowanie obrabiarkami za pomocą sekwencji z epromu było praktykowane,
bez cpu. Nigdy potem o tym nie słyszałem, jednak nie wydaje się to być
jakieś nieprawdopodobne, zaś wiele lat później dowiedziałem się od
jednego automatyka, że znalazł jakąs linię produkcyjną (a może rolniczą,
nie pamiętam) z tego okresu gdzie za "sterownik" odpowiadał właśnie
eprom, nadajacy prawidłowe sekwencje na pneumatykę. Ponoć jakieś
rękodzieło zdolnego hobbysty wydziargane na pająka.

Trudno jednak te przykłady nazywać 'komputerem". To tylko magnetofon.

do góry

On 06/03/2023 02:21, ptoki (ptoki) wrote:
> niedziela, 5 marca 2023 o 03:53:13 UTC-6 Cezar napisał(a):
>> On 05/03/2023 03:48, ptoki (ptoki) wrote:
>>
>>> Troche tak ale i troche nie.
>>>
>>> Jak definiujemy procesor?
>>> Filozoficznie to jest uklad ktory moze wykonywac program skladajacy sie z
instrukcji.
>>> Ile tych instrukcji? Jedna? Dwie? 300? Gdzie jest granica gdzie procesor sie
zaczyna?
>>> Jakie te instrukcje? Starczy dodawanie i skok? Czy jednak musi byc rowniez
transfer? A moze transfer bedzie domniemany?
>>> Ile opcji per instrukcja? Dodawanie miedzy rejestrami? Ile ich? A moze tylko
miedzy pamiecia i rejestrem? A moze rejestru nie trzeba is ie doda miedzy pamiecia a
pamiecia?
>>>
>> Tak sobie myśle czy obecnie nie było by wydajniej aby CPU mógł
>> bezpośrednio wykonywać działania na pamięci a nie na rejestrach.
>> Ja wiem- odwołania do działań byby dłuższe ale zaoszczędzilibysmy duzo
>> czasu na kopiowaniu RAMu do rejestrów.
>> Oczywiście część rejestrów musiała by zostać - jak np program counter.
>>
>>
>
> Raczej nie.
> Z paru powodow.
>
> 1. Szybki ram jest wolniejszy od taktowania cpu. W rezultacie cpu by patrzylo w
sufit wiekszosc czasu. Aktualnie chyba nawet transfery cache-rejestr zabieraja czasem
wiecej niz cykl lub dwa (nie jestem na bierzaco).
OK ale wezmy takiego 6502 czy nawet AVR, który ma dostęp do pamięci w
czasie rzeczywistym
Takie LDX zajmuje 2-4 cykle, CPX następne 2-4, INX dwa cykle. Jakby CPX
i wykonywał się bezpośrednio na ramie to można by zaoszczędzić kilka cykli.


Nie to że sam na to wpadłem - jakiś rok temu oglądałem tego gościa co
zrobił własny CPU z peryferiami i wspomniał w podsumowaniu ze te
rejestry są niepotrzebne
https://youtu.be/vaGZapAGvwM?t=670

do góry

heby napisał:

> Aby była jasność: w latach 70, jak opowiadał nauczyciel zawodowy,
> sterowanie obrabiarkami za pomocą sekwencji z epromu było praktykowane,
> bez cpu. Nigdy potem o tym nie słyszałem

Ale przedtem było to podejście dość powszechne.

https://pl.wikipedia.org/wiki/Maszyna_%C5%BCakardowa

--
Jarek

do góry

On Mon, 6 Mar 2023 14:11:42 +0100, Jarosław Sokołowski wrote:
> heby napisał:
>> Aby była jasność: w latach 70, jak opowiadał nauczyciel zawodowy,
>> sterowanie obrabiarkami za pomocą sekwencji z epromu było praktykowane,
>> bez cpu. Nigdy potem o tym nie słyszałem
>
> Ale przedtem było to podejście dość powszechne.
>
> https://pl.wikipedia.org/wiki/Maszyna_%C5%BCakardowa

Epromy to juz jednak technika jakby komputerowa.
Niemal bym rzekl, ze mikroprocesorowa, ale nie - pierwszy Eprom byl w
roku 1971.

Kiedys przyszli do mnie ludzie, z dwiema plytkami, sterownik od
jakiejs maszyny ... i tak na oko zawieral procesor zrobiony z TTL.
I Epromy.
Jakis strasznie uproszczony musial byc ... cos w rodzaju PLC ?

Uzycie eproma do prostego sterowania wydaje sie naturalne gdzies w
latach 70/80-tych, bo jednak trzeba miec jakis komputer do jego
zaprogramowania (eee tam - mozna recznie, programator z klawiaturą)
a uP jeszcze drogie - w PRL dluzej.

J.

do góry

On Sun, 5 Mar 2023 09:53:10 +0000, Cezar wrote:
> On 05/03/2023 03:48, ptoki (ptoki) wrote:
>> Troche tak ale i troche nie.
>>
>> Jak definiujemy procesor?
>> Filozoficznie to jest uklad ktory moze wykonywac program skladajacy sie z
instrukcji.
>> Ile tych instrukcji? Jedna? Dwie? 300? Gdzie jest granica gdzie procesor sie
zaczyna?
>> Jakie te instrukcje? Starczy dodawanie i skok? Czy jednak musi byc rowniez
transfer? A moze transfer bedzie domniemany?
>> Ile opcji per instrukcja? Dodawanie miedzy rejestrami? Ile ich? A moze tylko
miedzy pamiecia i rejestrem? A moze rejestru nie trzeba is ie doda miedzy pamiecia a
pamiecia?
>>
>
> Tak sobie myśle czy obecnie nie było by wydajniej aby CPU mógł
> bezpośrednio wykonywać działania na pamięci a nie na rejestrach.
> Ja wiem- odwołania do działań byby dłuższe ale zaoszczędzilibysmy duzo
> czasu na kopiowaniu RAMu do rejestrów.
> Oczywiście część rejestrów musiała by zostać - jak np program counter.

a) koncepcja RISC, chyba ciagle w miare żywa - chcemy w miare prosty
i szybki procesor, nie trzeba komplikowac rozkazow,

b) obecnie to pamiec wolna jest,

c) i mnóstwo cache po drodze ...

J.

do góry