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