> >Jeżeli kompilator miałby wstawiać nopy, to jest to najgorsze
> >rozwiązanie,
> >ale za to bardzo proste.
>
> Ale ja postuluje zeby to robil procesor ... w miare potrzeby.
No to się nie da, bo jest taki jak go fabryka wyprodukowała.
Kompilator ma zawsze 6 etapów rozwoju:

1) zamienić HIGH Level na asm byle by jakoś działało.
i wtedy przynosi dla piszącego krocie:
a) na sprzedaży urządzenia
b) na serwisie oprogramowania

2) Wprowadzić optymalizację kodu poprzez wstawianie NOPów.
To się marketingowo sprzedaje, porównując do 3 innych z punktu 1)

3) Wprowadzić optymalizację kodu, który przestawia instrukcje.
Nazwać go jakimś słowem: ULTRA, LUX czy podobnie.
Cena x4 i dużo reklamy. Piszący ciągle nie zauważa różnicy

4) Wprowadzić 100 checkboxów, aby każdy mógł sobie sam zrobić kompilator
jaki potrzebuje.
Wtedy ludzie się wymieniają informacjami, jak najlepiej poustawiać silnik,
aby zapalił. Za niektóre złote checkboxy trzeba dopłacić.
Cena kompilatora x10. Programista ma już 1/4 głowy siwych włosów.

5)SUPER, CROSS, MULTI FUNCTIONAL, 5 GENERATION COMPILER
Ten już ma wszystko. Cena x20, kupują już go nieliczni, kod po kompilacji
jest tylko 5x dłuższy niż tego z pkt.1)

6) WEB Kompilator .
Aplikacja wysyła kod źródłowy na serwer. Tam 1000 programistów z całego
świata, ręcznie, kompilują fragmenty. Wygrywa najszybszy kod i taki wraca do
użytkownika.
Użytkownik oczywiście w niczym się nie orientuje, bo trwa to 5 minut i w tym
czasie na ekranie lecą mu różne losowo
wybrane komunikaty, których nikt na świecie jeszcze nie czytał on-line.
:-)

S.