Użytkownik "Jarosław Sokołowski" <j...@l...waw.pl> napisał w wiadomości
news:slrnpq83ol.73a.jaros@falcon.lasek.waw.pl...
>> Mnie akurat chodzi o kompilację.
>
> No to trzeba wziąć coś innego niż basic. Ten do kompilacji się nie
> nadaje. Chyba, że ja czegoś nie wiem.

Jarku, na C64 się dawało, to na PC się nie da? Pecet, już w QBASICu,
zachowuje się, jakby robił coś w stylu kompilacji, a tym bardziej (wbrew
pozorom 32-bitowym) w windowsowym odpowiedniku QBASICa (niemal zgodnym z
QBASIC, są drobne różnice, dla poczatkującego mało zauważalne), kompilujemy
program, mając z niego plik EXE. Sam kompilator też można ponownie
skompilować.

>> Jarku, drobna różnica - "w kompilatach" vs "w kompilatORach"...
>
> W kompilatorach tak nie jest, żeby osadzały [one] nadmiarowe rzeczy
> [w kompilatach]. Tak lepiej?

Lepiej, ale nadal nie wiem, czemu podany przeze mnie przykład, kompiluje co
najmniej kilkusetkilowe pecyny, dla jednej deklaracji zmiennej, jednego
obliczenia, jednego wyprowadzenia wyniku i jednego skoku? Skoro nie dodaje
nadmiarów, to co takiego istotnego tyle zajmuje?

>
>>> Pozwoliłem sobie nieco zmodyfikować poprzedni kod (mam nadzieję, że
>>> licencja tego nie zabrania). Wygląda teraz tak:
>>
>> To jeden z programików że tak powiem, szkoleniowych, gdy ktoś zaczyna
>> w tymże programować. Moje dialekty na PC, traktują numer linii nie
>> jako numer, lecz etykietę, równoważną np., ":dupa", wtedy, np. robiąc
>> podprogram, robisz nie "GOTO 20", lecz "GOTO dupa", to samo także z
>> GOSUB.
>> Nie ma na niego żadnej licencji.
>
> Interpreter i tak sobie te linie ponumeruje po swojemu w pamięci.

Mniejsza o to. Ma wiedzieć, dokąd skoczyć i co wykonuje.

> Wybrałem fortran, bo (jak widać) jego kod jest często identyczny

Nie ukrywam, czasem mnie kusiło ściągnąć sobie kompilator i sie pobawić.

> z basikiem. Gdy po raz pierwszy zobaczyłem basic, pomyślałem sobie
> o niem, że to taki uproszczony fortran, który można interpretować
> zamiast kompilować. W prostych komputerach ośmiobitowych miało to
> sens. Dlaczego dzisiaj wciąż ktoś męczy ten basic -- tego nie wiem.

Bo jest, że tak powiem, dość prosty, w szkolnych przykładach nawet chwilami
samokomentujący się, przede wszystkim, choć może dziś niedoskonały (w końcu
jest starszy ode mnie...), ale jednak, nadal w postaci różnych dialektów
występuje. Jest przede wszystkim bardzo ludzki, czego niestety, mimo w sumie
lepszości (i bycia jednak niższego poziomu), należy odmówić językowi C i
podobnym.

>
>> Ponoć dobrze się nadaje do obliczeń na liczbach zespolonych?
>
> Też. Ale python również ma typ liczb zespolonych. Fortran nadaje się
> do kompilowania dawno napisanych (i dobrze przeterstowanych) źródeł
> i łączenia tego z nowym kodem w nowych językach. W fortranie nikt
> już chyba nic nie pisze, bo co było potrzebne, dawno napisano.
>
>>> Skompilowało się do pliku "hf5bs" o długości 8968 bajtów. Działa.
>>> Następnie "strip hf5bs" -- i już jest 6352. Też działa.
>>
>> I o to chodzi. Pewnie jakieś drobne procedurki, trudno, przeboleję,
>> ale nie 2 mega...
>
> Z językami interpretowanymi nie da się inaczej.

To twórcy oprogramowania na C64 tego nie wiedzieli i zrobili kompilator,
który zwłaszcza przy większych programach, daje program objętościowo
mniejszy, niż z zapisu interpretera. Parę programów sobie na C64
skompilowałem i nawet są szybsze i mniej dysku zajmują. Miałem nawet jakiś
kompilator, który miał dwie wersje działania, jedna, z normalnym zestawem
instrukcji, przyspieszająca ok... powiedzmy (dokładnie już nie pomnę), 5
razy, co do wielu zastosowań wystarczało. Druga, z zestawem zubożonym,
przyspieszała jakieś 25-50 razy kod wynikowy.

>
>> Tak mi zostało po sytuacji, gdy działałem, a do dyspozycji, jeszcze
>> przed C64, miałem ledwie 3.5 kB RAM (VIC-20 bez rozszeszeń pamięci),
>> a kładłem na tym programy znacznie bardziej skomplikowane i musiałem
>> się postarać, aby się zmieściły i ruszyły.
>
> Za to w językach interpretowanych zapisany kod może być bardzo mały.
> Interpreter siedzi sobie w ROM i interpretuje.

A to prawda. Choć dobry kompilator, co z pewnością nie jest trywialne, może
też skompilować bardzo mały kod, musi tylko umieć oderwać to, co do
wykonania programu niepotrzebne.
Swego czasu, chwilę się pobawiłem takim bardzo niszowym językiem, pod DOS,
nazywa(ł) się Zdzich. Wspomniany program, na który narzekałem, ze się
kompiluje nawet do ponadmegowej pecyny, nie mylę tego z innym programem,
który stosuje trzecią metodę, obok kompilacji i interpretacji - binduje
program, nie rozeznałem, jak to robi ostatecznie, czy mimo to interpretuje,
czy (pre)kompiluje, w każdym razie, działa bardzo szybko, daje nawet zrobić
realtime animowaną figurę przestrzenną, z wypełnianymi w tym czasie
ściankami... Nazywa się, OIDP, Ybasic. A... Zdzich? Wspomniany program,
oczywiście, dostosowany składniowo do programu (interpretera?, Kompilatora?)
głównego, skompilował się do 41 bajtów... I działał... Chyba kompilowało do
*.COM (max 65535 bajtów, więc sporo by się dało jeszcze wcisnąć)

--
Łapy, łapy, cztery łapy,
A na łapach pies kudłaty.
Kto dogoni psa? Kto dogoni psa?
Może ty? Może ty? Może jednak ja...?