Re: Komputer diy - prostszego nie widziałem - Grupy dyskusyjne w eGospodarka.pl

eGospodarka.pl › Grupy › pl.misc.elektronika › Komputer diy - prostszego nie widziałem › Re: Komputer diy - prostszego nie widziałem

X-Received: by 2002:a81:ae1d:0:b0:524:5bc5:a3d5 with SMTP id
m29-20020a81ae1d000000b005245bc5a3d5mr7452018ywh.4.1678139380556; Mon, 06
Mar 2023 13:49:40 -0800 (PST)
X-Received: by 2002:a81:ae1d:0:b0:524:5bc5:a3d5 with SMTP id
m29-20020a81ae1d000000b005245bc5a3d5mr7452018ywh.4.1678139380556; Mon, 06
Mar 2023 13:49:40 -0800 (PST)
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!3.eu.feeder.erj
e.net!2.eu.feeder.erje.net!feeder.erje.net!proxad.net!feeder1-2.proxad.net!209.
85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!goo
gle-groups.googlegroups.com!not-for-mail
Newsgroups: pl.misc.elektronika
Date: Mon, 6 Mar 2023 13:49:40 -0800 (PST)
In-Reply-To: <tu4n1q$lhm$1$cezar91@news.chmurka.net>
Injection-Info: google-groups.googlegroups.com; posting-host=24.77.110.106;
posting-account=jnRHMAoAAACB5EawItMhNTZMy_yOF2XE
NNTP-Posting-Host: 24.77.110.106
References: <64031dee$0$19623$65785112@news.neostrada.pl>
<ttvepf$vlti$1@dont-email.me>
<64035241$0$9612$65785112@news.neostrada.pl>
<6...@g...com>
<tu1oq7$suk$1$cezar91@news.chmurka.net>
<d...@g...com>
<tu4n1q$lhm$1$cezar91@news.chmurka.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c...@g...com>
Subject: Re: Komputer diy - prostszego nie widziałem
From: "ptoki (ptoki)" <s...@g...com>
Injection-Date: Mon, 06 Mar 2023 21:49:40 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: news-archive.icm.edu.pl pl.misc.elektronika:778945
[ ukryj nagłówki ]
poniedziałek, 6 marca 2023 o 06:41:32 UTC-6 Cezar napisał(a):
> 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.
>

Obejrz filmik jaki tu wrzucilem. Tam jest wiecej ciekawostek, np to ze 6502 wciaga
nowy rozkaz jak stary jeszcze sie nie skonczyl. To nieco komplikuje takie analizy.

>
> 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

Pisalem gdzies wyzej, mozna, ale w praktyce takich pamieci nie ma duzo albo sa
drogie.
DDR nieco temat adresuje ale to znowu jest nie do konca to co sie zazwyczaj uznaje za
"eleganckie" procesowanie takt w takt.
Nie zebym jakos specjalnie dbal o to jak sie realizuje dany aspekt komputera.