🚀 go-pugleaf

On Sep 12, 10:32 am, Mateusz Grotek <unodue...@poczta.onet.pl> wrote:

> Tzn. jak rozumiem wirtualny FAS miałby dwa wyjścia,
> jedno carry/borrow a drugie sum.

Tak. (Pamiętajmy, że połączenia - "druty" :-) - zajmują
więcej miejsca na kości niż logika, więc należy je
ograniczać).

> Ale w takim razie jakbyśmy chcieli odczytać najpier carry a
> potem borrow (nie możemy tego zrobić równocześnie
> oczywiście) to FAS przeprowadzałby obliczenie dwukrotnie.

Tak - 3 cykle (instrukcje) wystarczą na pewno;
zastanowię się potem czy może nawet 2. Co prawda
takie oszacowania na ogół należy dokonywać w
sytuacji serialnej, więc trzeba zwracać uwagę na RAM.

Niech  //  oznacza koniec instrukcji gappowskiej, oraz
RAM niech oznacza w kodzie ustalony adres. W ramach
jednej instrukcji inputy podisntrukcji są te same dla tych
samych adresów i registrów (zawartość pamięci i registrów
zmienia się dopiero po //), a operacje podinstrukcji
dokonywane są równolegle. Popatrzmy na naturalny
GAPP-program (3 instrukcje):

    RAM := C  C := carry    //
    C := RAM  RAM := C    //
    C := borrow    //

W sytuacji ciągu takich operacji, gdy inputy
pochodzą z pamięci, należy to zegrać z
czytaniem pamięci, i dopiero policzyć liczbę
instrukcji per obliczenie, plus jednorazowy
dodatek.

> Raz z niezanegowanym NS a drugi raz z zanegowanym.
> Ale a priori nie wiemy czy będziemy potrzebować carry
> czy borrow.

Na ogół wiemy. Powiedzmy przy wielobitowym
dodawaniu potrzebujemy wciąż carry, a przy
odejmowaniu wciąż borrow. Czasem faktycznie
potrzebujemy carry lub borrow w zależności
od wyniku. Gdy w zależności od globalnego wyniku,
to GAPP to nieźle potrafi, bo ma globalne OR
czyli GLOR, które może wpływać na kontroler
(na ciąg instrukcji w czasie bieżącym). Proponowałem
też bardziej subtelne konstrukcje (chyba ich nawet
nie patentowałem, nie jestem pewny). Ponadto
wybór carry lub borrow może być lokalny, w zależności
od lokalnych wyników. To trochę koncepcyjnie jest
coś do obgadania (ma to sens i nie ma, że tak powiem).
Wtedy GAPP stosuje software'owe rozwidlenie
(fork). Tworzy się 1-bitową płaszczyznę, która decyduje
o operacjach dla każdej komórki (punktu). Na przykład
można dokonać każdego obliczenia na całym "array",
i zachować je w pamięci. Następnie z płaszczyzn
jednego wyniku można wykroić część odpowiadającą
zeru 0 wspomnianej płaszczyzny warunkowej, z drugiego
odpowiadającą części 1, oraz te wykrojone częśći
skleić. (Nic się nie kroi, ale tak to sobie można dla
ułatwienia wyobrażać).

> Czyli po wykonaniu rozkazu zawierającego C=CY on odczytuje
> po prostu carry z FAS. A gdy dostaje rozkaz C=BW to najpierw
> odwraca stan  NS, a potem odczytuje carry. Czy tak to działało?

Prawie tak. Liczenie borrow nie wpływa to na zawartość NS.

> A jeśli tak, to czy to nie powodowało opóźnień?

Czas GAPPu jest dyskretny. Więc zarówno carry
jak i borrow wykonuję się w czasie 1 cyklu, czyli
tak samo szybko. Jednak borrow z punkty widzenia
designera być może utrudnia w utrzymaniu obliczeń
instrukcji w ramach jednego pulsu. Gdyby akurat
borrow było krytyczne, to puls (one clock) trzeba by
wydłużyć. Chcę jednak podkreślić, że przy projektowaniu
na poziomie VLSI nie można z góry łatwo przewidzieć
czy i co jest szybsze, carry czy borrow. To akurat jest
zupełnie marginesowy problem (mam na myśli różnicę
czasu na carry i borrow).

Pozdrawiam,

    Włodek

PS. Myślałem w 1981 o wprowadzeniu mojej
konstrukcji oprogramowania "//" jako standardowej
do wszystkich klasycznych języków komputerowych.
Chodzi o "puls". Pamięć zmienia się dopiero
z końcem pulsu. To byłoby wspaniale wygodne.
O wiele łatwiej by się myślalo i pisało. Na przykład
zamiana zawartość lokacji (zmiennych) A oraz B
wyglądałaby tak (jak w mojej symulacji GAPPu):

    A=B  B=A  //

Myślałem też o konkretnym, bardzo symetrycznym
języku, który zamiast GAPP symulowałby SuperGAPP.
Taki język bardzo by mi odpowiadał, bo łatwo by
we mnie wsiąknął. Wyobrażalbym sobie supersilny
hardware, symetryczny, więc nauka takiego języka
byłaby pestką, umiałbym go momentalnie. Myślę,
że taki język odpowiadałby wielu ludziom. Przy tym
byłby to język algorytmów masowo-równoległych
(drobnicowo). Nawet na zwykłym komputerze (PeCecie)
takie algorytmy często są szybsze.

Oczywiście  APL  oraz  jego następca
są świetnymi językami arrayowymi, ale mój byłby
jednak naturalniejszy, można by go stale mieć
przed oczami. Zresztą można by w nim rozwinąć
bibliotekę "APL", by dał w efekcie także APL.

Byłby to też język wyższy dla wielu procesorów
równoległych, słabszych od SuperGAPPa. Łatwo
dopisałoby się bibliotekę, która pozwoliłaby
programować taki prawdziwy procesor, jakby to
był SuperGAPP, co byłoby bez porównania
łatwiejsze niż programowanie w asemblerze
danego procesora.  wh