🚀 go-pugleaf

On Sun, 9 Aug 2009 03:17:37 -0700 (PDT) Wlodzimierz Holsztynski
<sennajawa@gmail.com> wrote:

> W kilka tygodni (dwa? cztery?) po przybyciu
> do Orlando, i zaaklimatyzowaniu się, miałem
> już GAPPa. Czyli w zasadzie już dojrzały
> "design" komórki i globalny. Ponadto konserwatywnie
> oszacowałem liczbę potrzebnych tranzystorów
> poprzez zaprojektowanie hardware nie tylko na
> poziomie logicznym,, ale i tranzystrowym. Na poziomie
> logicznym serio, a tranzystorowy tylko dla oceny
> wielkości design, bo to jest zajęcie dla fachowców,
> którzy poza tranzystorowym VLSI design niczego
> innego nie robią.

Jakie to były liczby - tzn. ile bramek, ile tranzystorów?
W jakiej technologii były wykonane pierwsze GAPP?
Jaki był czas otrzymania wyniku?
Istnieją kompilatory języków wyższego poziomu dla GAPP?

w.

-- 
Kupię: http://wm.ite.pl/kupie.html

"Wlodzimierz Holsztynski" <sennajawa@gmail.com> wrote in message 
news:0b4a1a5a-28bc-4a93-9391-df8b5f309e7e@o9g2000prg.googlegroups.com...

[...]

odleciales gosciu

-- 
usenet 

"Wlodzimierz Holsztynski" <sennajawa@gmail.com> wrote in message 
news:0b4a1a5a-28bc-4a93-9391-df8b5f309e7e@o9g2000prg.googlegroups.com...

[...]

jeszcze jedno, strasznie zmyslasz miszczu ale olewam to, najlepsze jest 
to ze ty nie potrafisz po angielsku wow

-- 
usenet 

On Aug 9, 4:41 am, Wojciech Muła
<wojciech_m...@poczta.null.onet.pl.invalid> wrote:

> Jakie to były liczby - tzn. ile bramek, ile tranzystorów?

Moje wstępne oszacowania liczby tranzistorów były
prowizoryczne. Celem był dowód konceptu.

Design prototypowego GAPP I był zrobiony przez NCR
(w ich arrayowej technologi PLA) i ludzi z MM, za moimi plecami,
choć to była implementacja mojej architektury, wcześniej
wykonanej w MM z części z pólki (of shelf parts). Ten GAPP I
byl straszny, idiotyczny. Potem musiałem się wstydzić za nich,
bo przy patencie prawo wymaga poinformowania o najlepszym
istniejącym wykonaniu. To było jedyne VLSI (PLA), więc
"najlepsze". NCR początkowo obiecało array 7x14. Potem,
po GAPP I wycofali się z obietnicy, wątpiąc, czy uda im
się uzyskać 6x6. Rozpatrywano możliwość skasowania projektu.
Szczęśkiwie o tym dowiedziałem się "na korytarzu" pod koniec
pewnego dnia, więc w nocy napisałem dwa memoranda.
W jednym pokazałem jak w ramach PLA zaprojektować kość
GAPPa wydajnie. W drugim podałem główne idee GAPP III.
W tym czasie umarł w NCR VLSI desgner, a z nowym
wspólpracowałem, zaprzyjaźniliśmy się. On z mojego
memorandum skorzystał przy swoim custom VLSI design
(zrezygnował z PLA). Wziął moje moduły i je upchał.

Architektura  GAPP II  jest podana w "Parallel Supercomputing..."
R. Michaela Horda, rozdział 6. Nigdy nie miałem z nim
żadnego kontaktu (lub nic o tym nie wiem, ale chyba po prostu
nie i kropka). Jestem mu wdzięczny, że starał się napisać
jak naprawdę było. Do końca nie był w stanie, bo musiał
opierać się na tym co jakoś usłyszał, przeczytał. Stąd wciąż
w jego monografii są mylące wytarte zwroty. Pisze na przykład:

  "Martin Marietta intentionally designed the GAPP cell
  as simple as possible. The simplicity was the driving
  principle resulting from Dr. Holsztynski's work. ..."

Drugie zdanie powyżej jest prawdziwe. Pierwsze zupełnie nie.
Martin  Marietta niczego nie design, a tylko WH. Gdy MM
przykładała do czegoś rękę poza moimi plecami, to kopała
niemiłosiernie, a ja to potem ratowałem. Wpadło mi do głowy,
że może nie zawsze to był przypadek, że dowiadywałem się
o tych rzeczach i mogłem naprawić. Po zastanowieniu się
jednak sądzę, że to był jakby brak zwykły dyscypliny wśród
managerów i kolegów. Bo jednak straty były drastyczne, i
materialne i czasowe. A oni jednak byli moimi kolegami.

Dodam uwagi, zakładając, że możesz Wojtku zajrzeć
do Horda.

Liczba tranzystorów w kości GAPP II chyba jest nieznana.
NCR dokładnie opisało typ kości, jej wymiar, specyfikacje.

Na kości było 6x12 = 72 komórki. Połowa real estate idzie
na połączenia. Moja architektura miała tylko 13 control
lines, czyli bardzo mało (elegancko, ekonomicznie).
Dochodziło 7 linii adresowych, bo każda komórka
miała 128 bitów własnej pamięci RAM. Poza tym miała
cztery 1-bitowe registry  CM NS EW C. Stąd już 13+7 pinów.
Ponadto geometryczne shifts wymagały  2*(12 + 6 + 6) = 48
pinów. To w zasadzie niemal wszystkie pins (dochodzą
"inżynieryjne": zasilanie i clock-zegar). Czyli pinów było
nieco ponad 20+48 = 68. Razem może 70-72, nie pamiętram.

Niska liczba linii kontrolnych jest ekstremalnie ważna,
bo większość miejsca na kości zajmują połączenia.

Logiki było relatywnie mało. Każdy register miał swój
input multypleksor (multiplexor):

  CM --  4x2
  NS --  7x3
  EW --  7x3
  C  --  7x3

oraz pamięć też miała swój multypleksor:

  RAM - 3x2

Może dziwić, że lewe wymiary nie są potęgą dwójki.
Zaokrąglenie 7 do 8 nie spowodowałoby zwiększenia
liczby linii kontrolnych. Jednak poza tym rozmiar
samego multypleksora wzrósłby z grubsza 2-krotnie.
Ponadto inputy 0 były przy każdym registrze, bo
były - jak przyuważyłem - za darmo. Gdyby nie to, to
dałbym tylko dla C.

Output procesora komórki był 1-bitową *pełną*
sumą/różnicą registrów NS EW C, oraz szedł
do RAM -suma/różnica (tutaj suma i różnica była
tym samym), i do C (carry/borrow), znowu wydajnie.
Figure 26 u Horda ciut myli (dla większości czytelników
to nie ma wielkiego znaczenia), bo sugeruje 3 outputy,
a to są naprawdę tylko dwa różne. (Zresztą Hord nie
mówi explicite, że opisuje akurat GAPP II). A tak było
mu prościej. Sztuka polega na tym  że 3  inputowe
linie kontrolne registra C mogą modyfikować output C,
ewentualnie go logicznie zaprzeczając w przypadku
kombinacji borrow, nim ten output dotrze do pełnego
sumatora/odejmowacza.

> W jakiej technologii były wykonane pierwsze GAPP?

Prototyp GAPP I używał NCR PLA, ale mniejsza.
GAPP II był custom made VLSI design. Chyba stosowano
w końcu więcej niż jedną technologię (rodzaj) kości,
oraz różnie je pakowano.

Opisy inżynieryjne kości GAPP II są dostępne
publicznie, bo NCR je sprzedawała komercjalnie -
ale MM miała monopol na "military grade". Te
"militarne" miały szybkość 9.8MHz. Hord i inni
zaokrąglali do 10MHz. NCR nawet nie mogło testować
takiej szybkości (dziś jest śmieszna :-), więc
wszystkie kości wysyłało do MM, która dla siebie
wybierała te, które przeszły testy, a reszta wracała
do NCR jako comercial. Lepsze opakowania, dla
mil-spec też były robione w MM. Początkowo
wkradły się jakieś elektryczne "bugs" i wydajność
NCR ("yield") była rozpaczliwie niska. Komercjalne
kości miały chyba około 5Mhz.

***

Pisałem o multypleksorach zamiast o bramkach
logicznych, gdyż multypleksory mają dobrą szansę
na bezpośredni design tranzystorowy, bez pośredniego
etapu bramek logicznych. Co więcej, gdybym dłużej
pracował w przemyśle elektronicznym, to spełniłbym
swoją ideę bogatych komórek, co dotąd chyba jest
ledwo w powijakach. Nawer mialem konkretne przykłady.
Zamiast logikę dawać na zewnątrz komórek, to warto dać
dla specjalnych zastosowań, jak sortowanie, do wewnątrz.
Wtedy hardware byłby znacznie szybszy.

Pełny adder jest klasyczną konstrukcją, więc znowu
się tu nad tym nie rozwodzę. Pełny adder/subtractor
był jednym z moich pomysłów. Czy sam w sobie byl
zauważony wcześniej (bez kontekstu Parallel
Processing)? Nie wiem.  Podejrzewam, że tak, ale
nie wiem.

***

Każdy kulturalny człowiek powinien znać
teorio-mnogościową kostrukcję zbioru
potęgowego  Y^X  (zbiór wykresów
wszystkich funkcji z X do Y), wraz
z towarzyszącą naturalną transformacją,
oraz powinien rozumieć, że w elektronice
to jest to samo co pełny multypleksor czyli
selektor (ciekawe jaki procent elektroników
rozumie, że multypleksor i selektor to w zasadzie
to samo: 99%? 5%?). Może gdzieś o tym
dla publiki ogólnej napiszę, może.

***
> Jaki był czas otrzymania wyniku?

Nie jestem pewny jak interpretować to pytanie
(znałem tylko angielską terminologię - a i to słabo :-).
Czy chodzi Ci o clock rate w MHz, czy też ile czasu
spędzono nad projektem, nim otrzymano kości?

> Istnieją kompilatory języków wyższego poziomu dla GAPP?

Najpierw mój system rozpowszechniony był
w oddziałach w Orlando, Denver i Waszyngton DC
(może to była Aleksandria, wszystko jedno).
Bīł tak napisany w STOIC (jakby Forth), że każdy
użytkownik z łatwością mógł tworzyć narzędzia, bo
dalem mu do ręki cały STOIC + mój system, t.zn.
mój GAPP assembler and simulator był przedłużeniem
STOICu, wzbogaceniem STOIC o GAPP.

Potem pracowałem dla małego start-up w Boca Raton,
i napisałem im jeszcze lepszy system w Forth.
Ale ta mała firma się rozwaliła, była zbyt zwariowana,
jak to małe firmy na Florydzie, więc ten system się
zmarnował. Doświadczenie wykorzystałem potem
w Lockheed, gdzie napisałem jeden, a dwa inne
napisano pod moim kierunkiem, w tym jeden
super szybki (idee miałem już w MM, ale je
ulepszyłem). Szybkie korzystają z równoległości
bitowej działn na słowach w PC, więc są mniej
elastyczne, gdy chodzi o wymiar symulowanego array
 - musi być wielokrotmością długości słowa procesora
PCetu. Dlatego dla eksperymentów algorytmicznych
warto mieć także wolniejszą wersję, ale która
dopuszcza dowlne wymiary EW x NS. Taka dowolność
jest także ważna dla teoretycznej matematyki i fizyki.
Przy małym wymiarze EWxNS szybkość nie ma tak
wielkiego znaczenia. Wszystkie systemy w Lockheed
projektowałem w języku C. Ale udało mi się zachować
dawną elastyczność systemu. Jeden z inżynierów-
programistów (z Wietnamu) był swietny, dorobił
fachowe konstrukcje w C, typu biblioteki... i w ogóle
doskonale nam się współpracowała (zawsze mi sie dobrze
pracowało z programistami - bo sam maczałem
palce w programowaniu, co wielce ułatwia współpracę;
moje opisy zadań dla programistów były software'owo
zaawansowane, odwalały kawał roboty).

Potem pisano systemy (nie od razu!!) w NCR.
Już mnie nie było w MM, ale oni i tak nie chcieli,
bym w czymkolwiek brał udział. Główny manager
napalał się na chama na sławę i władzę, stąd taka
bezsensowna polityka. Zatrudnili całą firmę software'ową.
Jak to bywa, nikt nie wiedział w umowie o czym
mówił, więc się pokłócili i rozeszli. W końcu NCR
miało dwa systemy. Jeden kiepski w C, drugi
w Forth, lepszy, bo programista Forth był ostrzejszy.
Ale konkurs na najkrotszy program Life wygrał
u nich w NCR mój przyjaciel, VLSI designer.
Parę lat wcześniej, bez konkursu, miałem jednak
w MM. Stworzyła swoje nowe systemy także MM,
łącząc je ze stacjami, ael wiem o tym tyle co nic.
Powstały nowe firmy, specjalizujące się wyłącznie w GAPP,
z blogosławieństwem MM. Jedna mnie kiedyś zaprosiła
na swoją konferencję (zwali się wtedy chyba Paralogic -
niby równoległa logika, ale brzmiało to jak jakiś
paraliż :-). Proponowałem zaadoptowanie APL,
ale nikt poważnie nie słuchał. Dziś istnieje nowa wersja APL,
język J chyba, ktora nie wymafa specjalnej klawiatury
(APL bez specjalnej klawiatury tracił swój urok).

Obawiam się, że nie istnieją kompilatory do Image
Processing, które  by działały i uniwersalnie i na wysokim
poziomie abstrakcji. (Czy Wolfram uzyskał już coś
takiego?) Można taki system napisać nie oglądając się na
żadne istniejące Im. Proc. hardware, po czym łatwo coś
takiego podłączyć (dodatkowym modułem oprogramowania)
do dowolnego sensownego hardware. Zaczęloby się od
fikcyjnej, bardzo mocnej i bardzo regularnej/super eleganckiej
architektury, co już daloby wysoki poziom. Więc inne architektury
w Image Processing, już prawdziwe, byłyby eleganckim
redukcjami tej hyper mocnej - prawdziwe zależałyby od zastosowań
i środowiska hardware'owego. Łatwo byłoby software'owo
połączyć to w jedną harmonijną rodzinę hardwere'owo-
softwarowo. Ba!

Po odejściu z MM stworzyłem architekturę HOPE, ale
nic z tej nadziei nie wyszło, nie namówiłem na to żadnych
inwestorów. Biznesmani i około- biznesowcy (różni executives
i hochsztaplerzy :-) ciągną jedni do drugich całkiem irracjonalnie,
może jakiś zapach wydzielają, nie wiem co za licho. Nawet
zabawnie patrzeć jak się nabierają, tracą grube $$, ale i tak
dobrze się czują wśród swoich. Żal tylko, że marnuje się potencjał
robienia efektywnie pożytecznych rzeczy. Nabrał się na przykład
na Steve Jobsa ten miliarder z Teksasu, gdy dał Jobsowi
miliony na NeXT. NeXt splajtowal, a Jobs wskoczył
z powrotem do Appla. Nieporozumienie polegało na tym,
że ten teksańczyk (Perrot?) sam był przecież jak Jobs,
więc potrzebował kogoś jak Woźniak, a nie jak Jobs=Perrot.
Jobs kiedyś miał Woźniaka, więc uzyskał sukces.
Ale Perrot+Jobs = Jobs+Jobs to disaster, to klęska.

Pozdrawiam,

    Włodek

> Output procesora komórki był 1-bitową *pełną*
> sumą/różnicą registrów NS EW C, oraz szedł
> do RAM -suma/różnica (tutaj suma i różnica była
> tym samym), i do C (carry/borrow), znowu wydajnie.
> Figure 26 u Horda ciut myli (dla większości czytelników
> to nie ma wielkiego znaczenia), bo sugeruje 3 outputy,
> a to są naprawdę tylko dwa różne. (Zresztą Hord nie
> mówi explicite, że opisuje akurat GAPP II). A tak było
> mu prościej. Sztuka polega na tym  że 3  inputowe
> linie kontrolne registra C mogą modyfikować output C,
> ewentualnie go logicznie zaprzeczając w przypadku
> kombinacji borrow, nim ten output dotrze do pełnego
> sumatora/odejmowacza.
> 

Mam dwa pytania.
1. Czy FAS robił NS-EW czy EW-NS ?
2. Nie zrozumiałem tego fragmentu z wypowiedzi powyżej o liniach
wyjściowych. O jakich liniach tutaj mowa. Niestety nie mam książki
Horda, więc mógłbyś może wyjaśnić coś więcej.
Z tego co wiem to wejścia/wyjścia całego układu to między innymi W, N,
S, E. Wejścia to CMS i 7 bitów adresu. Wyjście to CMN.
Natomiast jeśli chodzi o FAS to wejścia idą od rejestrów NS EW i C, a
wyjścia to SM, CY, BW. Więc o jakie 3 vs. 2 "outputy" chodzi?

On Sep 11, 6:35 pm, Mateusz Grotek <unodue...@poczta.onet.pl> wrote:

> > Output procesora komórki był 1-bitową *pełną*
> > sumą/różnicą registrów NS EW C, oraz szedł
> > do RAM -suma/różnica (tutaj suma i różnica była
> > tym samym), i do C (carry/borrow), znowu wydajnie.
> > Figure 26 u Horda ciut myli (dla większości czytelników
> > to nie ma wielkiego znaczenia), bo sugeruje 3 outputy,
> > a to są naprawdę tylko dwa różne. (Zresztą Hord nie
> > mówi explicite, że opisuje akurat GAPP II). A tak było
> > mu prościej.

Być może Hord miał ograniczony czas, więc zamiast
do końca sprawę przemyśleć, to ją sobie uprościł
(w GAPP było nieco lepiej).

> > Sztuka polega na tym  że 3  inputowe
> > linie kontrolne registra C mogą modyfikować output C,
> > ewentualnie go logicznie zaprzeczając w przypadku
> > kombinacji borrow, nim ten output dotrze do pełnego
> > sumatora/odejmowacza.

Mgliście to napisałem. Poniżej cierpliwie
pokaże o co chodzi. Będzie to ilustracją,
choćby drobną, o tym jak dobrze być
matematykiem w zastosowaniach.

> Mam dwa pytania.
>
> 1. Czy FAS robił NS-EW czy EW-NS ?

Chyba  NS - EW  (minęło ćwierć wieku, więc
na 100% nie mogę być pewny; gdyby mi nie
narzucono raczej zbędnego  CM,  to design
byłby w pełni elegancki i symetryczny, i wtedy
zupełnie n ie miałoby znaczenia czy to było
NS-EW czy też EW-NS, byłby automorfizm).

Napiszę poniżej jak wygląda 1-bitowa
suma wraz z bitem carry/borrow - użyję
notacji + na XOR, & na AND, v na OR,
oraz ~ na NOT:

    SUM(NS EW C)  :=  NS + EW + C
    carry(NS EW C)  :=  NS&EW v NS&C v EW&C

    borrow(NS EW C) := carry(~NS EW C)

Widzimy, że jedna z linii kontrolnych multipleksora C
po prostu neguje linię NS zanim wchodzi ona jako
input do carry/borrow.

> 2. Z tego co wiem to wejścia/wyjścia całego układu
> to między innymi W, N, S, E. Wejścia to CMS i 7 bitów
> adresu. Wyjście to CMN.

Lepiej mówić o wejściach/wyjściach RAM oraz
registrów  NS EW C  oraz nieszczęsnego  CM.

> Natomiast jeśli chodzi o FAS to wejścia idą od rejestrów NS EW i C, a
> wyjścia to SM, CY, BW. Więc o jakie 3 vs. 2 "outputy" chodzi?

FAS istnieje tylko koncepcyjnie. W zasadzie
istnieje w sensie bezpośrednim tylko RAM
i registry, których stan zmienia się z każdym
cyklem pod wpływem ich zawartości oraz
linii kontrolnych.

(Oczywiście hardwerowiec doda jako wejścia,
czy "pins", także zasilanie czyli "power" oraz
"clock", ale softwarowiec o to się nie martwi).

Pozdrawiam,

    Włodek

Wlodzimierz Holsztynski (Wlod) pisze:
> On Sep 11, 6:35 pm, Mateusz Grotek <unodue...@poczta.onet.pl> wrote:
> 
> Napiszę poniżej jak wygląda 1-bitowa
> suma wraz z bitem carry/borrow - użyję
> notacji + na XOR, & na AND, v na OR,
> oraz ~ na NOT:
> 
>     SUM(NS EW C)  :=  NS + EW + C
>     carry(NS EW C)  :=  NS&EW v NS&C v EW&C
> 
>     borrow(NS EW C) := carry(~NS EW C)
> 
> Widzimy, że jedna z linii kontrolnych multipleksora C
> po prostu neguje linię NS zanim wchodzi ona jako
> input do carry/borrow.

Tzn. jak rozumiem wirtualny FAS miałby dwa wyjścia, jedno carry/borrow a
drugie sum. 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. Raz z niezanegowanym NS a drugi
raz z zanegowanym. Ale a priori nie wiemy czy będziemy potrzebować carry
czy borrow. 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? A jeśli tak, to
czy to nie powodowało opóźnień? Czy dobrze to zrozumiałem?

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

On Sep 14, 4:08 am, "Wlodzimierz Holsztynski (Wlod)"
<sennaj...@gmail.com> wrote:

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

Pamięć (registry i RAM), która w danej instrukcji
nie występuje po lewej stronie znaku  :=  pozostaje
prze taką instrukcję niezmieniona. Powyżej
registry  NS  oraz  EW cały czas zachowują swoją
wartość - mamy mikro nop NS := NS oraz EW := EW
(nie warto ich pisać, są domyślne).

> W sytuacji ciągu takich operacji, gdy inputy
> pochodzą z pamięci, należy to zegrać z
> czytaniem pamięci,

i z wpisywaniem do pamięci.

> i dopiero policzyć liczbę instrukcji per obliczenie,
> plus jednorazowy dodatek.
>
> [...] 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).

Na poziomie tranzystorów na ogól mamy dostęp
zarówno do wartości registra, jak i do jego negacji,
i nie jest jasnym, który jest wygodniejszy.

Ponadto często i tak dodaje się podwójne przeczenia,
żeby sygnały zsynchronizować, co znowu stwarza
dodatkowe szanse sięgania po sygnał lub jego
zaprzeczenie.

Hardware w rękach specjalisty jest czymś
bardzo plastycznym, jak pozycja szachowa
dla arcymistrza lub język pod piórem świetnego
pisarza. Zapomina się o dyskretności, "wszystko"
wydaje się możliwe, wszystko można modyfikować,
itp.

Pozdrawiam,

    Włodek

Wlodzimierz Holsztynski (Wlod) pisze:
> 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ć).
> 
Dlatego użyłem słowa "wirtualny".
>> 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.
>
No tak. A jak rozumiem niewyprowadzenie dwóch wyjść było podyktowane
ówczesną technologią. Tzn. dzisiaj właściwie możnaby zrobić FAS który w
jednej instrukcji daje carry i borrow. Wtedy można by je wrzucać nie
tylko do C. Ale oczywiście wtedy będzie bardziej skomplikowana logika i
będzie można upakować to mniej gęsto. Ale do zastosowań to będzie
szybsze, bo obrazy i tak mają właściwie dość mało pikseli. Czyli możnaby
powiedzieć, że do tych samych zastosowań co wtedy możnaby zrobiś
używając dzisiejszej technologii jeszcze lepszego GAPPA.

>> 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ć).
> 
Jak rozumiem mówisz tu o optymalizacjach.
>> 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.
> 
No tak, przez odwracanie stanu nieprecyzyjnie wyraziłem fakt, że linia
idąca od NS do wirtualnego FAS przechodzi (tylko wirtualnie) przez
bramkę która odwraca lub nie odwraca sygnału zależnie od podanego
rozkazu. Nie chodziło mi o zmianę zawartości rejestru 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).
> 
No tak. Chodziło mi tylko, że musi tam być bramka która neguje lub nie
neguje linię od NS do FAS. Ale oczywiście na poziomie elektroniki można
to tak zoptymalizować, żeby dostać to za darmo niejako. Ale tak czy owak
chyba to rozwiązanie z uniemożliwieniem jednoczesnego odczytu carry i
borrow sporo upraszcza elektronikę. Czyli mówiąc inaczej, należałoby się
zastanowić na czym nam bardziej zależy i co jest bardziej korzystne do
danych zastosowań, a także do istniejącej technologii.
Najprawdopodobniej algorytmy przetwarzania obrazów rzadko potrzebują
jednocześnie jednego i drugiego, a dzięki temu ograniczeniu byćmoże
elektronika będzie szybsza, gdyż będzie prostsza. Ciekawy pomysł.
> 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

Hmm, w mojej opinii SIMD nie jest dobrym rozwiązaniem do ogólnego
przetwarzania danych. Jest świetny do grafiki, gdzie tą samą operację
chcemy wykonać na wielu danych. Ale w innych wypadkach może nie być taki
dobry. W mojej opinii MIMD sprawdzi się lepiej, gdyż oczywiście może
emulować SIMD, ale ma poza tym większe możliwości. Aczkolwiek jest
jescze drugi punkt widzenia, a mianowicie punkt widzenia elektroniki.
Jeżeli SIMD będzie DUŻO szybszy niż MIMD to preferowałbym SIMD. Ale
chyba nie ma aż tak wielkiej zależności. Poza tym mózg jeżeli możemy tak
powiedzieć, jest architekturą MIMD. Każdy neuron to jednostka
obliczeniowa, ale pomimo faktu, że ma początkowo zapisany ten sam
"program", wywołuje w zależności od warunków środowiska inne jego
"instrukcje", więc ścieżki się rozchodzą. Według mnie to przyszłość
komputerów. Już widać odchodzenie od SISD w kierunku MIMD nawet wśród
komputerów "domowych", a co dopiero powiedzieć o farmach serwerów, gdzie
każdy serwer jest sam w sobie kolekcją procesorów. Sądzę, że wreszcie
dojdą do wniosku, że jednostka obliczeniowa ma być jak najprostsza i
SISD w ogóle odejdzie do lamusa nawet w zastosowaniach domowych. Ale
żeby zaprogramować taki komputer będą potrzebne nowe języki
programowania, w których równoległość obliczeń jest oczywista, widoczna
na poziomie języka i łatwo dająca się pojąć. I co najciekawsze sądzę, że
takie języki nie powstaną. Już programowanie 5 równoległych procesów
jest trudne bez zatrzymywania żadnego z nich. A co gdy będziemy musieli
zaprogramować 1000000? Według mnie pójdzie to w stronę systemów uczących
się i sztucznej inteligencji. Bo bez tego nie wyobrażam sobie mówienie
1000000 nanoprocesorów co mają robić. Aczkolwiek możliwe jest także
skonstruowanie architektury która może zrobić 1000000 forków. Ale im
więcej forków tym prostsze instrukcje może interpretować. Takie coś
byłoby całkiem ciekawym pomysłem i działało by trochę jak ludzki mózg.
Przyszłość pokaże.

On Mon, 14 Sep 2009 17:55:06 +0200, Mateusz Grotek
<unoduetre@poczta.onet.pl> wrote:
 
>"instrukcje", więc ścieżki się rozchodzą. Według mnie to przyszłość
>komputerów. Już widać odchodzenie od SISD w kierunku MIMD nawet wśród
>komputerów "domowych", a co dopiero powiedzieć o farmach serwerów, gdzie
>każdy serwer jest sam w sobie kolekcją procesorów. 

Przyszlosc komputerow juz byla, ale sie rozmyla. Mam na mysli
transputer ktory zmarl smeircia tragiczna sporo lat temu i byl wlasnei
MIMD

>Sądzę, że wreszcie
>dojdą do wniosku, że jednostka obliczeniowa ma być jak najprostsza i
>SISD w ogóle odejdzie do lamusa nawet w zastosowaniach domowych. Ale
>żeby zaprogramować taki komputer będą potrzebne nowe języki
>programowania, w których równoległość obliczeń jest oczywista, widoczna
>na poziomie języka i łatwo dająca się pojąć. I co najciekawsze sądzę, że
>takie języki nie powstaną. 

A jezyk zwany Occam?...  Na przyklad, tylko. Implementacja mechanizmow
Occama w Javie zwana jest JCSP i programuje sie przy pomocy tego
doskonale

>Już programowanie 5 równoległych procesów
>jest trudne bez zatrzymywania żadnego z nich. 

Jak sie wie jak to robic, to nie. Poza tym, na ogol nei ejst mozliwe
"nei zatrzymywanie zadnego z nich" i nei wynika to z naszej
nieumiejetnosci a z powodu ograniczen zwiazanych z natura algorytmow.
Nei wszystko daje sie prosto zrownoleglic.

>A co gdy będziemy musieli
>zaprogramować 1000000?

A Thinking Machines?... Ile oni mieli procesorow?... 16 tysiecy, zdaje
sie, ale to bylo dawno. I jakos sie programowalo.

A BlueGene?... "The 1-PFLOPS Blue Gene/P configuration is a
294,912-processor, 72-rack system harnessed to a high-speed, optical
network. Blue Gene/P can be scaled to an 884,736-processor, 216-rack
cluster to achieve 3-PFLOPS performance. A standard Blue Gene/P
configuration will house 4,096 processors per rack"...

"new configuration has started at April 6, the system will go into
production end of June 2009. The new configuration will include 294
912 processor cores, 144 terabyte memory, 6 petabyte storage in 72
racks"

I tez sie jakos programuje.

A.L.

A.L. pisze:
> On Mon, 14 Sep 2009 17:55:06 +0200, Mateusz Grotek
> <unoduetre@poczta.onet.pl> wrote:
>  
>> "instrukcje", więc ścieżki się rozchodzą. Według mnie to przyszłość
>> komputerów. Już widać odchodzenie od SISD w kierunku MIMD nawet wśród
>> komputerów "domowych", a co dopiero powiedzieć o farmach serwerów, gdzie
>> każdy serwer jest sam w sobie kolekcją procesorów. 
> 
> Przyszlosc komputerow juz byla, ale sie rozmyla. Mam na mysli
> transputer ktory zmarl smeircia tragiczna sporo lat temu i byl wlasnei
> MIMD
> 
BlueGene o którym piszesz niżej to też MIMD.
>> Sądzę, że wreszcie
>> dojdą do wniosku, że jednostka obliczeniowa ma być jak najprostsza i
>> SISD w ogóle odejdzie do lamusa nawet w zastosowaniach domowych. Ale
>> żeby zaprogramować taki komputer będą potrzebne nowe języki
>> programowania, w których równoległość obliczeń jest oczywista, widoczna
>> na poziomie języka i łatwo dająca się pojąć. I co najciekawsze sądzę, że
>> takie języki nie powstaną. 
> 
> A jezyk zwany Occam?...  Na przyklad, tylko. Implementacja mechanizmow
> Occama w Javie zwana jest JCSP i programuje sie przy pomocy tego
> doskonale
> 
>> Już programowanie 5 równoległych procesów
>> jest trudne bez zatrzymywania żadnego z nich. 
> 
> Jak sie wie jak to robic, to nie. Poza tym, na ogol nei ejst mozliwe
> "nei zatrzymywanie zadnego z nich" i nei wynika to z naszej
> nieumiejetnosci a z powodu ograniczen zwiazanych z natura algorytmow.
> Nei wszystko daje sie prosto zrownoleglic.
> 
Cała zabawa polega właśnie na stworzeniu takich algorytmów które
zatrzymywanie ograniczają do minimum.
>> A co gdy będziemy musieli
>> zaprogramować 1000000?
> 
> A Thinking Machines?... Ile oni mieli procesorow?... 16 tysiecy, zdaje
> sie, ale to bylo dawno. I jakos sie programowalo.
>
Spojrzałem zarówno na manuala do occama jak i do C*. I nadal podtrzymuję
to co napisałem. Pewnie się nie zrozumieliśmy, (może trochę niejasno
napisałem). Wiem, że można programować równolegle. Wiem także że można
zaprogramować MIMD, żeby elementy wykonywały równolegle inne procesy.
Jednakże twierdzę, że nie można zaprogramować komputera z 1000000
elementów, żeby każdy z nich wykonywał KOMPLETNIE różny program w
rozsądnym czasie i od zera, gdyż równałoby się to programowaniu 1000000
komputerów równocześnie. Co innego jeśli każdy z tych programów będzie
umiał dopasowywać się do przychodzących danych. W takim wypadku możemy
mówić o sztucznej inteligencji, szczególnie programowaniu ewolucyjnym,
genetycznym itp. Inaczej mówiąc chodziło mi o to, że będzie odchodzić
się od programowania w stylu pisania dokładnych przepisów co kiedy
maszyna ma robić i jak reagować na polecenia użytkownika, a włączy się
także do tego czynniki ewolucyjne i inne rozwiązania sztucznej
inteligencji, które wcale nie muszą być przewidywalne. Już dzisiaj nie
można przewidzieć jak będzie przebiegało uczenie bardzo dużej sieci
neuronowej a priori, lub nawet prostej gry w życie, gdyż zabrałoby to
zbyt dużo czasu. Dlatego napisałem, że w tym kierunku pójdzie
programowanie, zamiast pisać elementom jak mają obrabiać dane które
chcemy przetworzyć, napiszemy im co mają zrobić by przetrwać, lub
wykorzystamy inne pomysły sztucznej inteligencji. Mówiąc jeszcze
inaczej, nie będziemy opisywać w programach dokładnie jak krok po kroku
przetwarzać dane które nas interesują, ale tylko jak procesy mają
przetrwać i pozwolimy im samym znaleźć rozwiązanie problemu. Mam
nadzieję, że teraz jest jasno i klarownie.

> A BlueGene?... "The 1-PFLOPS Blue Gene/P configuration is a
> 294,912-processor, 72-rack system harnessed to a high-speed, optical
> network. Blue Gene/P can be scaled to an 884,736-processor, 216-rack
> cluster to achieve 3-PFLOPS performance. A standard Blue Gene/P
> configuration will house 4,096 processors per rack"...
> 
> "new configuration has started at April 6, the system will go into
> production end of June 2009. The new configuration will include 294
> 912 processor cores, 144 terabyte memory, 6 petabyte storage in 72
> racks"
> 
> I tez sie jakos programuje.
> 
Jakoś na pewno ;-)
> A.L.

On Tue, 15 Sep 2009 02:56:22 +0200, Mateusz Grotek
<unoduetre@poczta.onet.pl> wrote:
 o.
>>
>Spojrzałem zarówno na manuala do occama jak i do C*. I nadal podtrzymuję
>to co napisałem. Pewnie się nie zrozumieliśmy, (może trochę niejasno
>napisałem). Wiem, że można programować równolegle. Wiem także że można
>zaprogramować MIMD, żeby elementy wykonywały równolegle inne procesy.
>Jednakże twierdzę, że nie można zaprogramować komputera z 1000000
>elementów, żeby każdy z nich wykonywał KOMPLETNIE różny program w
>rozsądnym czasie i od zera, gdyż równałoby się to programowaniu 1000000
>komputerów równocześnie.   

Programowales cos na komputerach rownoleglych i piszesz na podstawie
praktyki, czy tez tak ci sie zdaje?...

A.L.

A.L. pisze:
> On Tue, 15 Sep 2009 02:56:22 +0200, Mateusz Grotek
> <unoduetre@poczta.onet.pl> wrote:
>  o.
>> Spojrzałem zarówno na manuala do occama jak i do C*. I nadal podtrzymuję
>> to co napisałem. Pewnie się nie zrozumieliśmy, (może trochę niejasno
>> napisałem). Wiem, że można programować równolegle. Wiem także że można
>> zaprogramować MIMD, żeby elementy wykonywały równolegle inne procesy.
>> Jednakże twierdzę, że nie można zaprogramować komputera z 1000000
>> elementów, żeby każdy z nich wykonywał KOMPLETNIE różny program w
>> rozsądnym czasie i od zera, gdyż równałoby się to programowaniu 1000000
>> komputerów równocześnie.   
> 
> Programowales cos na komputerach rownoleglych i piszesz na podstawie
> praktyki, czy tez tak ci sie zdaje?...
> 
> A.L.
Nie muszę programować, żeby to ocenić. Chyba znowu się nie rozumiemy.
Użyłem słowa "kompletnie".