On Sat, 13 Oct 2007, Maciej Bebenek wrote:

> Nie, pobieram dane, które są przetwarzane przez program zainstalowany na moim
> komputerze.

Ja w kwestii formalnej: tzw. "program" to są skądinąd dane do
przetworzenia na komputerze.

Mam na myśli program .EXE, i to nie tylko na tym poziomie, na którym
wnikamy w *format* tegoż EXE (no jakieś nagłówki czy inne deskryptory
to chyba DANE jak nic, prawda?), ale również w czasie kiedy jest w pamieci
i jest... pobierany do rejestrów. Jak każda dana. To że tylko do
niektorych rejestrów też nie jest dziwne, wiele procesorów tak
ma że NIEKTÓRE dane ładuje się tylko do NIEKTÓRYCH rejestrów....

Nazwanie przetwarzania tychże rejestów "wykonywaniem" jest czysto umowne,
bo przecież bez znaczenia jest, czy np. wartość do dowolnego rejestru
zostanie wczytana jako "dana" (z obszaru pamieci nazywanego "obszarem
danych") czy z takich szczególnych danych jak kod programu :) czy
wręcz zostanie wprowadzona poprzez algorytmiczną interprtację
danych nazywanych "programem" - mam na myśli taki przypadek, kiedy
wprowadzamy do rejestru np. wartość "2" w ten sposób, że go np.
zerujemy i dwa razy inkrementujemy.
Jest "dana"? - jest. Skąd się wzięła? - z tego co nazywamy "programem".
CAŁY "program" to są właśnie takie "dane"!
Gdzie granica? - patrz wyżej, w odpowiedzi na pytanie czy światło
jest falą czy cząsteczką. Prawidłowa odpowiedź: "zależy od wielkości
mikroskopu" :P

> Czym się różnią dane od programu, chyba nie muszę tłumaczyć.

Optymista :>

PAL-code w procesorze Alpha to "program", "dane", czy jeszcze
co innego? ;) (hint, bo nie każdy prawnik musi jarzyć ;), idzie
o definicje instrukcji, rozszerzające możliwości interpretacyjne
tego co nazywa się potocznie "listą rozkazów procesora",
fakt zapisania ich w kodzie procesora jest trzeciorzędny,
i tak nie ma do nich dostępu w trakcie dalszej pracy procesora
a myk polega na tym że NIE SĄ pobierane w trakcie ładowania
do procesora mechanizmem pobierania "rozkazów" przez procesor,
przecież to są "zwykłe dane" :))

Kolejny przykład "do prezentacji" to kod emulowanego procesora.
Twoim zdaniem taki *kod programu* to są dane czy nie? :)
A jeśli jednak SĄ, to niby dlaczego mam je traktować inaczej
(niż jako dane) jeśli są dekodowane *hardwareowo*, hm?

...i w ten deseń do dwoistości korpuskularno-falowej spokojnie
dorzucamy dwoistość danowo-programową.
Wbrew temu co piszesz, jakoby "chyba nie muszę tłumaczyć" czym
się różnią program od danych, istnienia ścisłej granicy
CZEGOKOLWIEK co da się opisać algorytmicznie nie da się
wskazać.
Tak samo, jak operując światłem przy wielkości przedmiotów
rzędu kilku metrów można zachowania cząsteczkowe pominąć
ze względu na PRAKTYCZNE ich znaczenie, tak samo można
udawać że nie dostrzegamy faktu iż program to dane.
Ale przesuwając granicę rozmiaru wcześniej czy później
oberwiemy dziwnymi zjawiskami. I tak też przy programie,
sprawą sporną jest WYŁĄCZNIE jak dokładnie przyglądamy
się temu, co mamy do czynienia.
"Prawne" istnienie tych zjawisk przez cały czas (w całej
skali obserwacji) nie podlega więc dyskusji - jak pytamy
czy "są" odpowiedź brzmi "są".
Ba, można wręcz wyrazić niezrozumienie, jakim prawem kawałek
tekstu stanowiący DANE ktoś śmie nazywać PROGRAMEM... :)
A to że komuś powyższe brzmi dwuznacznie w zależności od tego
czy ów tekst jest zapisany z rozszerzeniem ".C" czy ".PAS"
albo tam ".JPG" to już inna sprawa :]
Ubolewam, że w powyższym kontekście procesory CISC jakoś
zamarły w rozwoju, bo na pewno pojawiłby się taki co by
umiał interpretować kod .JPG wprost w rozkazach maszynowych :>
Przypominam że popularna dość architektura VAX miała (ze 30
lat temu) na liście rozkazów takie drobne operacje jak dzielenie
wielomianów. Rozkaz skoku do tablicy adresów z wyborem po wartości
warunku (inaczej: hardwareowa implementacja "case") jest
oczywisty.
To i przekształcanie .JPG na mapę bitową wprost do prezentacji
byłoby na miejscu, nie? ;)

I co, fakt że dekodowanie byłoby sprzętowe by coś miał ZMIENIĆ?
A jeśli nie, to co za różnica, czy procesor czyta kod JPG czy
jakiś inny? :)

pzdr, Gotfryd