Pan Sebastian Biały napisał:

>>> To wtedy nie liczyli na komputerach tylko kopiowali z lewa na prawą?
>> Z kopiowaniem musieli poczekać na Petera Nortona. Więc liczyli. Liczący
>> komputer nie nudzi się.
>
> Strasznie wąski zakres zastosowań, znaczy się ...

Ja bym szerokość tego zakresu oszacował tak gdzieś na Aleph_0. Można
wyliczyć jeszcze kilka innych zastosowań, ale to chyba niewiele zmienia.

>> IBM/PC nie był projektowany z myślą o zastosowaniach kowalskich.
>> Kowalski miał wtedy ZX-Spectrum i Commodore C64. I był szczęśliwy,
>> że ma kontakt z nowoczesną techniką.
>
> Nie, miał w tamtych czasach rownież Amigę. >85 rok.

A wcześniej ZX-81 albo ZX-80. Kontynuacja. Świat nie stoi w miejscu.

> A to nie byla zabawka jesli chodzi o OS.

Tak jak kolejka Piko. Tatusiowie też kupowali swoim synom, a później
samemu bawili się po nocach.

> OS był boski w porównaniu z resztą świata a tym bardziej blaszanym
> pudłem z procesorem ze średniowiecza i CP/M.

Boski. Jak mi kiedyś coś mówili o skecie, to nie wiedziałem o co chodzi.
Teraz już wiem.

>>> ... odkrywać na nowo zarządzanie heapem, borykać się z segmentacją,
>>> zastanawiać jaką pamięć dzisiaj użyć i tym podobne drobnostki
>>> pozwalające natychmiast zająć się nie cierpiącym zwłoki zadaniem.
>> ...przekształcając macierze w Fortranie, licząc korelacje w Basicu,
>> wyliszając wartości funkcji w C. Czasem pisząc jakiś artykuł.
>
> Czyli ręcznie zarządzając heapem, pieprząc się z segmentacją itp.

Jasne, bez "ręcznego zarządzania heapem" nie da się nawet pętli napisać.
Kilka razy mi się zdarzyła konieczność dopisania paru linijek kodu, bo
zmienna nie mogła być większa niż 64kB. Ale bardziej doskwierało mi to,
że wszystkie zmienne nie mogą zająć, dajmy na to, więcej niż 59237kB
(albo np. ok. 4MB -- problem z grubsza ten sam).

> Pozazdrościć architektury i OS. I tego że do końca obliczeni nie sposób
> było nawet napisać abstraktu artykulu ...

Jakoś nigdy mnie specjalnie nie interesowało, w którym rejestrze CPU
trzyma dane gdy mi liczy pętle. Ani w ogóle jaki tam jest procesor
i jaki OS. Dlatego nigdy nikomu takich rzeczy nie zazdrościłem.

Jarek

--
Zamienię pociąg do wódki na kolejkę elektryczną piko.

do góry

On 2011-05-11 22:20, Jarosław Sokołowski wrote:
>>> Kowalski miał wtedy ZX-Spectrum i Commodore C64. I był szczęśliwy,
>>> że ma kontakt z nowoczesną techniką.
>> Nie, miał w tamtych czasach rownież Amigę.>85 rok.
> A wcześniej ZX-81 albo ZX-80. Kontynuacja. Świat nie stoi w miejscu.

Za wyjątkiem MS-DOSa. Tylko cyferki się zmieniały. Choć oczywiście nie,
dodali przecież BASICa.

>> Czyli ręcznie zarządzając heapem, pieprząc się z segmentacją itp.
> Jasne, bez "ręcznego zarządzania heapem" nie da się nawet pętli napisać.

Zauważalna częśc programów nie składa się *wylacznie* z pętli.

> Kilka razy mi się zdarzyła konieczność dopisania paru linijek kodu, bo
> zmienna nie mogła być większa niż 64kB.

Zainteresuj się dodatkowo ile linijek kodu musiał dopisac kompilator
żeby niewidoczne problemy z segmentacją były rozwiązane w tle runtime.
Na ten przykład niech poleci normalizacja wskaźników. Rzecz nie
spotykana poza x86.

> Jakoś nigdy mnie specjalnie nie interesowało, w którym rejestrze CPU
> trzyma dane gdy mi liczy pętle.

Jesli liczysz to zapewne zalezy Ci na szybkości. Jeśli zalezy Ci na
szybkosci to poniżej pewnego progu optymalizacji zaczyna być
interesujące w jakim rejestrze co jest i dlaczego tych rejestrów jest
tak mało.

do góry

Pan Sebastian Biały napisał:

>>>> Kowalski miał wtedy ZX-Spectrum i Commodore C64. I był szczęśliwy,
>>>> że ma kontakt z nowoczesną techniką.
>>> Nie, miał w tamtych czasach rownież Amigę.>85 rok.
>> A wcześniej ZX-81 albo ZX-80. Kontynuacja. Świat nie stoi w miejscu.
>
> Za wyjątkiem MS-DOSa. Tylko cyferki się zmieniały. Choć oczywiście nie,
> dodali przecież BASICa.

Chyba odjęli?

>>> Czyli ręcznie zarządzając heapem, pieprząc się z segmentacją itp.
>> Jasne, bez "ręcznego zarządzania heapem" nie da się nawet pętli napisać.
>
> Zauważalna częśc programów nie składa się *wylacznie* z pętli.

Jasne, bez "ręcznego zarządzania heapem" można napisać *wyłącznie* pętlę.
A bez Amigi można *wyłącznie* kopiować z lewej na prawą i z prawej na
lewą. (Statystycznie większość obliczńm to jednak pętle.)

>> Kilka razy mi się zdarzyła konieczność dopisania paru linijek kodu, bo
>> zmienna nie mogła być większa niż 64kB.
>
> Zainteresuj się dodatkowo ile linijek kodu musiał dopisac kompilator
> żeby niewidoczne problemy z segmentacją były rozwiązane w tle runtime.
> Na ten przykład niech poleci normalizacja wskaźników. Rzecz nie
> spotykana poza x86.

Dlaczego mam się tym interesować? Po to mam kompilator, bym nie musiał
grzebać w kodzie procesora. Skompilował, nie zużył więcej pamięci niż
trzeba, więc na miskę elektronów zasłużył.

>> Jakoś nigdy mnie specjalnie nie interesowało, w którym rejestrze
>> CPU trzyma dane gdy mi liczy pętle.
>
> Jesli liczysz to zapewne zalezy Ci na szybkości. Jeśli zalezy Ci
> na szybkosci to poniżej pewnego progu optymalizacji zaczyna być
> interesujące w jakim rejestrze co jest i dlaczego tych rejestrów
> jest tak mało.

W praktyce to ta szybkość zależy bardziej od piszącego program (żeby
użył odpowiedniego algorytmu) niż od optymalizacji kodu mikroprocesora.
A w teorii zwiększanie liczby rejestrów (liczby niewielkiej, skończonej,
rosnącej liniowo) nie może być receptą na złożoność algorytmów.

--
Jarek

do góry

On 2011-05-11 22:48, Jarosław Sokołowski wrote:
> Jasne, bez "ręcznego zarządzania heapem" można napisać *wyłącznie* pętlę.

Nie. Bez zarzadzania systemowego nalezy za kazdym razem wynajdywać koło
na nowo. Programy pracujące w CP/M robiły dokładnie to - wynajdywały na
nowo: heap, gui, multitasking, user input, itd.

> A bez Amigi można *wyłącznie* kopiować z lewej na prawą i z prawej na
> lewą.

Tak, w MS-DOS. Mówimy o OS.

>> Zainteresuj się dodatkowo ile linijek kodu musiał dopisac kompilator
>> żeby niewidoczne problemy z segmentacją były rozwiązane w tle runtime.
>> Na ten przykład niech poleci normalizacja wskaźników. Rzecz nie
>> spotykana poza x86.

> Dlaczego mam się tym interesować?

Bo profesjonaliści interesują się takimi rzeczami.

> Po to mam kompilator, bym nie musiał
> grzebać w kodzie procesora.

Jesli *liczysz* to musisz mieć świadomość wielu rzeczy. W tym jaki kod
jest generowany. Przykro mi, ale musisz wiedzieć czy lepiej użyć float
czy double i czy w ogóle są szybsze od fixed-point.

> Skompilował, nie zużył więcej pamięci niż
> trzeba, więc na miskę elektronów zasłużył.

Pomijasz dużo innych aspektów.

> W praktyce to ta szybkość zależy bardziej od piszącego program (żeby
> użył odpowiedniego algorytmu) niż od optymalizacji kodu mikroprocesora.

W praktyce kończą się optymalizacje wysokopoziomowe i pozostaje zejście
do kodu. Mozna ugrać sporo bo kompilatory nie sa perfekcyjne, a wtedy
tym bardziej nie były.

> A w teorii zwiększanie liczby rejestrów (liczby niewielkiej, skończonej,
> rosnącej liniowo) nie może być receptą na złożoność algorytmów.

Nadmiarowy kod obsługujący segmentację i swapowanie rejestrów jest
zbedny gdyby procesor nie był projektowany przez merketoidów.

do góry

Pan Sebastian Biały napisał:

>> Jasne, bez "ręcznego zarządzania heapem" można napisać *wyłącznie* pętlę.
> Nie. Bez zarzadzania systemowego nalezy za kazdym razem wynajdywać koło
> na nowo. Programy pracujące w CP/M robiły dokładnie to - wynajdywały na
> nowo: heap, gui, multitasking, user input, itd.

Jeśli tym kołowynajdującym programem jest kompilator, jeśli są tam równe
szprychy i obręcz gładka, to mnie ta sytuacja odpowiada. Gdy chcę liczyć.

>>> Zainteresuj się dodatkowo ile linijek kodu musiał dopisac kompilator
>>> żeby niewidoczne problemy z segmentacją były rozwiązane w tle runtime.
>>> Na ten przykład niech poleci normalizacja wskaźników. Rzecz nie
>>> spotykana poza x86.
>> Dlaczego mam się tym interesować?
>
> Bo profesjonaliści interesują się takimi rzeczami.

Profesjonaliści od kompilatorów i problemów z segmentacją. Nie każdy
nim jest.

>> Po to mam kompilator, bym nie musiał grzebać w kodzie procesora.
>
> Jesli *liczysz* to musisz mieć świadomość wielu rzeczy. W tym jaki kod
> jest generowany. Przykro mi, ale musisz wiedzieć czy lepiej użyć float
> czy double i czy w ogóle są szybsze od fixed-point.

Taką wiedzę miałem (chyba było o tym w podręczniku). I liczenie nie
sprawiało mi przykrości, fajne było.

>> Skompilował, nie zużył więcej pamięci niż trzeba, więc na miskę
>> elektronów zasłużył.
>
> Pomijasz dużo innych aspektów.

Do popicia nic mu nie dam. Niech sobie sam zorganizuje.

>> W praktyce to ta szybkość zależy bardziej od piszącego program (żeby
>> użył odpowiedniego algorytmu) niż od optymalizacji kodu mikroprocesora.
>
> W praktyce kończą się optymalizacje wysokopoziomowe i pozostaje zejście
> do kodu. Mozna ugrać sporo bo kompilatory nie sa perfekcyjne, a wtedy
> tym bardziej nie były.

Nie wiem jaka była praktyka liczenia na Amidze (w sumnie to był nowy
system, więc jeśli programista musiał schodzić do kodu, to też żaden
wstyd). Liczenie z dobrymi sprawdzonymi kompilatorami nie sprawiało
niespodzianek.

>> A w teorii zwiększanie liczby rejestrów (liczby niewielkiej, skończonej,
>> rosnącej liniowo) nie może być receptą na złożoność algorytmów.
>
> Nadmiarowy kod obsługujący segmentację i swapowanie rejestrów jest
> zbedny gdyby procesor nie był projektowany przez merketoidów.

A niech sobie maleństwo swapuje, co mi tam.

--
Jarek

do góry

On 2011-05-11 23:15, Jarosław Sokołowski wrote:
>> na nowo. Programy pracujące w CP/M robiły dokładnie to - wynajdywały na
>> nowo: heap, gui, multitasking, user input, itd.
> Jeśli tym kołowynajdującym programem jest kompilator

Nie jest.

>, jeśli są tam równe
> szprychy i obręcz gładka, to mnie ta sytuacja odpowiada. Gdy chcę liczyć.

Nie wszyscy chcą liczyć. Niektórzy chcą rysować, drukować, pisać.

>> Bo profesjonaliści interesują się takimi rzeczami.
> Profesjonaliści od kompilatorów i problemów z segmentacją. Nie każdy
> nim jest.

Więc nie każdy powinien programować. Nawet zwykłe liczenie.

>> W praktyce kończą się optymalizacje wysokopoziomowe i pozostaje zejście
>> do kodu. Mozna ugrać sporo bo kompilatory nie sa perfekcyjne, a wtedy
>> tym bardziej nie były.
> Nie wiem jaka była praktyka liczenia na Amidze

Optymalizacje sa wszędzie takie same w sensie ich istoty. Zawsze masz
taki etap że albo już olewasz albo musisz zejśc do kodu. W przypadku x86
musiałes się wtedy babrać w gównie.

>> Nadmiarowy kod obsługujący segmentację i swapowanie rejestrów jest
>> zbedny gdyby procesor nie był projektowany przez merketoidów.
> A niech sobie maleństwo swapuje, co mi tam.

OK. Na szczęście jednak niektórym zależy dzięki czemu mamy jakiś postęp.

UWAGA!

Ponieważ wątek zaczyna mi wychodzić poza kolumnę w thunderbiridzie
niniejszym dokonuje EOT z mojej strony. Gadajcie sobie dalej :)

do góry

Pan Sebastian Biały napisał:

>>> Programy pracujące w CP/M robiły dokładnie to - wynajdywały na
>>> nowo: heap, gui, multitasking, user input, itd.
>> Jeśli tym kołowynajdującym programem jest kompilator
>
> Nie jest.

No faktycznie, GUI ani multitaskingu nie musi wynajdować, by sobie
trochę pokompilować. Ale to chyba lepiej, nie?

>> jeśli są tam równe szprychy i obręcz gładka, to mnie ta sytuacja
>> odpowiada. Gdy chcę liczyć.
>
> Nie wszyscy chcą liczyć. Niektórzy chcą rysować, drukować, pisać.

No to biorą program, który wynalazł rysowanie, drukowanie, pisanie.

>>> Bo profesjonaliści interesują się takimi rzeczami.
>> Profesjonaliści od kompilatorów i problemów z segmentacją.
>> Nie każdy nim jest.
>
> Więc nie każdy powinien programować. Nawet zwykłe liczenie.

Oczywiście. Na przykład profesjonalisci od kompilatorów z reguły nie
programują (w sensie liczenia).

>> Nie wiem jaka była praktyka liczenia na Amidze
>
> Optymalizacje sa wszędzie takie same w sensie ich istoty. Zawsze masz
> taki etap że albo już olewasz albo musisz zejśc do kodu. W przypadku x86
> musiałes się wtedy babrać w gównie.

A czym się różniło amigowe gówno od gówna x86 (w sensie ich istoty)?

> UWAGA!
>
> Ponieważ wątek zaczyna mi wychodzić poza kolumnę w thunderbiridzie
> niniejszym dokonuje EOT z mojej strony. Gadajcie sobie dalej :)

Przerażające! Thread error overflow. To musi być wina peceta i braku
rejestrów. Na Amidze to by było nie do pomyślenia.

--
Jarek

do góry

On 11-05-2011 17:23, Jarosław Sokołowski wrote:
> Pan Marcin Wasilewski napisał:
>
>>> Ile on właściwie potrafił pokazać pikseli? (Macintosh miał
>>> 512x324 na 9 calach, brr...).
>>
>> W zasadzie 640x512 z interlacem, bo tak był przecież kreślony
>> sygnał PAL.
>
> Jaką rolę w tym zdaniu pełni słowo "przecież"? Przecież mówimy
> o komputerze, a nie o magnetowidzie czy innym sprzęcie telewizyjnym.
> I to o tak zdefiniowanym komputerze, że ZX-Spectrum się nie łapie.
>
> Jak już zadałem pytanie, to coś mnie podkusiło i spróbowałem samemu
> się dowiedzieć jak jest z tą grafiką Amigi. Wszędzie w opisach pomija
> się podanie liczby pikseli, jest zwykle tylko coś o "full-scren geaphics"
> i o liczbie kolorów (jakby to miało znaczenie, czy będę próbował
> zmusić telewizor do pokazania tysiąca kolorów, czy miliona). To jest
> wstydliwy temat, od razu widać. Dlaczego nikt mi tu wcześniej nie
> powiedział, że ten sprzęt w ogóle nie miał ambicji wyświetlania czegoś
> na normalnych monitorach?
>
> Wygląda to tak, jakby producent nastawił się na odbiorców związanych
> z rynkiem wideo. Ten rynek się naonczas szybko rozwijał, jak ktoś miał
> pomysł i parę groszy oszczędności, mógł na nim zaistnieć. Dla takich
> ten komputer mógł być skarbem.
>
>> W czasach Amigi 1200 wszystko się trochę skomplikowało, bo
>> i rozdzielczości były wyższe i monitor SVGA dało się podłączyć.
>
> Doczytałem też o jakichś hackerskich sztuczkach przy podłączaniu
> monitora VGA -- programowa zmiana czegoś w komputerze, by wytworzyć
> sygnał zbliżony do VGA (czyli o wyższej częstotliwości odświeżania
> i większej rozdzielczości). Najbadziej zdumiało mnie uzasadnienie
> tej sztuczki -- żeby mieć możliwość skorzystania z *tańszych*
> monitorów (VGA) w miejsce oryginalnego sprzętu (PAL), który miał
> już cenę rzadkiego zabytku techniki.
>
>> A jeśli chodzi o edytory tekstu, to zaufaj, że potrafił.
>
> Niestety, w tym momencie moje zaufanie sie skończyło. Edytowanie tekstów
> na ekranie telewizora z odświeżaniem 50 Hz w przeplocie, w dodatku
> w okienkach -- nie, nie, nie... Sam bym tego nie wymyślił. Brr...
>
No popatrz topowa wtedy VGA miala odswierzanie 60 Hz. Czyli tyle samo co
Amiga w NTSC.

Inne karty z tego okresu tez wygladaja blado:

Hercules 720x350 50 Hz
CGA 640x200 60 Hz
EGA 640x350 60 Hz
VGA 640x480 60 Hz

O ilosci kolorow w stosunku do Amigi przez grzecznosc nie wspomne.

Taki byl wtedy standart i gotow jestem sie zgodzic iz tryb tekstowy byl
bywal wygodniejszy. Ale jesli chodzi o mulitasking - to bez przesady.


Pozdr

Marek

do góry

Pan Marek Borowski napisał:

>>> A jeśli chodzi o edytory tekstu, to zaufaj, że potrafił.
>>
>> Niestety, w tym momencie moje zaufanie sie skończyło. Edytowanie tekstów
>> na ekranie telewizora z odświeżaniem 50 Hz w przeplocie, w dodatku
>> w okienkach -- nie, nie, nie... Sam bym tego nie wymyślił. Brr...
>
> No popatrz topowa wtedy VGA miala odswierzanie 60 Hz. Czyli tyle samo co
> Amiga w NTSC.

...a w PAL -- 50 Hz. Za to w NTSC rozdzielczość musiała być jeszcze mniejsza.
Tak źle i tak niedobrze.

> Inne karty z tego okresu tez wygladaja blado:
>
> Hercules 720x350 50 Hz
> CGA 640x200 60 Hz
> EGA 640x350 60 Hz
> VGA 640x480 60 Hz

W opisie blado, w praktyce blado było tylko z monitorami CGA. Czyli mniej
więcej tymi, co się je po odejściu ze służby sprzedawało jako "lepszy
telewizor do Amigi". Te pozostałe karty miały jednak inne monitory (na
starym monitorze VGA obraz wygląda lepiej niż na (prawie) współczesnym CRT
w trybie 640x480). Zresztą "ten okres" też wymaga doprecyzowania -- jak
się spojrzy w kalendarz, to widać, że w jakiś rok po epokowym wynalazku
firmy Commodore pojawiły się na świecie kolejne standardy. Warto podkreślić
ostatnie słowo -- *standardy*. Bo w tych nielicznych zastosowaniah gdzie
było trzeba, to już dużo wcześniej podłączało się takie monitory, że ho ho ho.

> O ilosci kolorow w stosunku do Amigi przez grzecznosc nie wspomne.

Dlaczego? Nie widzę we wspominaniu niczego niegrzecznego.

> Taki byl wtedy standart i gotow jestem sie zgodzic iz tryb tekstowy byl
> bywal wygodniejszy. Ale jesli chodzi o mulitasking - to bez przesady.

No właśnie, nikt rozsądny nie traktował poważnie możliwości pracy z tymi
rozdzielczościami w środowisku graficznym z okienkami. A w przypadku
Amigi było to (zdaje się) koniecznością.

--
Jarek

do góry

Użytkownik "Jarosław Sokołowski" <j...@l...waw.pl> napisał w wiadomości
news:slrnisohrl.h0a.jaros@falcon.lasek.waw.pl...

> No właśnie, nikt rozsądny nie traktował poważnie możliwości pracy z tymi
> rozdzielczościami w środowisku graficznym z okienkami. A w przypadku
> Amigi było to (zdaje się) koniecznością.

Typowa rozdzielczość pracy na Amidze na monitorach PAL wynosiła 640x256 i
pracowało się w niej naprawdę spoko. Większość programów (a edytory tekstu
to chyba wszystkie) pozwalały przejść w tryb pełnoekranowy. 640x512 mało
kto używał poza zastosowaniami dot. obróbki grafiki, gdyż z powodu
interlace-u trzeba było mieć albo dobry monitor, albo flicker-fixer, który
był montowany seryjnie bodajże w Amidze 3000. Tylko zapominasz, że w czasach
Amigi 1200/4000 (być może nawet w A500+) bez problemu można było pracować na
monitorach VGA i jedyne co było do tego potrzebne to przejściówka na wtyk
VGA (być może były tam jakieś bramki, czy rezystory) ale pamiętam, że
zrobienie tego zajmowało 15 minut i nie był to jakiś high-tech.

do góry