RSS

Programy będą już tylko rosły

Liczba odsłon: 19

Zaglądając do starych czasopism komputerowych, znaleźć można całkiem funkcjonalne programy pisane w języku asemblera, w stu lub w dwustu bajtach realizujące wcale nie takie trywialne zadania. Siadając potem do komputera PC i pisząc własny program można się złapać za głowę: byle prosta procedurka, sama z siebie niewiele znacząca, zajmuje dziesiątki lub setki bajtów — tyle, co kiedyś cały program!

Niestety, taki urok nowoczesnych platform 32-bitowych. Mikroprocesory 8-bitowe nie tylko używały krótszych danych (1 bajt) i adresów (zazwyczaj 2 bajty), ale też miały zestaw instrukcji ściśle przystosowany do pisania jak najkrótszych programów. W pamięci o rozmiarze kilkunastu lub kilkudziesięciu kilobajtów musiała się zmieścić cała aplikacja (by nie wspomnieć o stosowanych już wtedy komputerach przemysłowych, dysponujących często tylko kilkoma kilobajtami pamięci ROM i RAM w sumie).

Tymczasem nowoczesne procesory 32-bitowe z rodziny IA-32 poświęcają na niektóre rozkazy – na przykład przenoszenia danych – aż 7 bajtów. Proste odłożenie na stosie parametru dla podprogramu zajmuje 5 bajtów. W efekcie banalna operacja zablokowania odrysowywania elementu graficznego Windows na ekranie, zapisana w języku C w następujący sposób:

   SendMessage(hWnd, WM_SETREDRAW, 0, 0);

zajmuje aż 25 bajtów — po pięć na każdy parametr i pięć na wywołanie podprogramu SendMessage()! Gdy do obsłużenia jest kilkanaście kontrolek okna dialogowego, prosta procedura łatwo zajmie pół kilobajta pamięci.

Od zwiększonych rozmiarów kodu trudno jest uciec. Jest o co walczyć, gdyż większy program oznacza automatycznie więcej operacji dyskowych i mniej trafień pamięci podręcznej. Warto podkreślić, że konstruktorzy pierwszych procesorów AMD-64 uświadomili sobie ten problem: procesor 64-bitowy standardowo pracuje na danych 32-bitowych; przetwarzanie 64-bitowe – rzadko przecież potrzebne – uaktywniane jest na wyraźne życzenie programisty w tych miejscach, w których jest niezbędne lub może dać przyrost wydajności.


A kto zgadnie, do czego to należy (Oczywiście jest to assemblerowy odpowiednik SendMessage(hWnd, WM_SETREDRAW, 0, 0), hWnd jest jednego programu M$ :), jakiego, to akurat jest w tym wypadku nieważne :) ):
@vVal = SendMessage(hHandle, WM_SETREDRAW, FALSE, 0);
000080CA 4804 LDR R0, [PC,#0x010] ; [0x80DC] =FALSE (0x824C)
000080CC 6802 LDR R2, [R0, #0]
000080CE 4804 LDR R0, [PC,#0x010] ; [0x80E0] =WM_SETREDRAW (0x8250)
000080D0 7801 LDRB R1, [R0, #0]
000080D2 4804 LDR R0, [PC,#0x010] ; [0x80E4] =hHandle (0x8248)
000080D4 6800 LDR R0, [R0, #0]
000080D6 F000 ; pre BL/BLX
000080D8 F807 BL user32.SendMessageA ; 0x80E8

Życzę powodzenia! :)
Strzelam: ARM? :)
Poprawna odpowiedź :) to : rodzina ARM920T. Gratuluję poprawnej odpowiedzi. :)
Ale do rzeczy. :) Nareszcie Microsft udostępnił narzędzia do budowy swojego windowsa. Więc nie czekając, z kolegami zabraliśmy się do testu x86 versus native RISC :) No cóż, bo batalii z beznadziejnym kompilatorem M$ C for ARM (tu wielki pokłon dla wzorcowego kompilatora IAR'a :) ) naszym oczom ukazał się Windows XP Embedded for ARM family. :) Jeszcze w wersji beta. :)
Teraz może krótkie podsumowanie dokonanych (nie wszystkich zaplanowanych, wykonanych) zadań.
Dla użytkownika największyą zaletą będzie pewnie fakt, że system podczas normalnej pracy potrzebuje jedynie 11 watów energii. Oczywiście wliczając w to: twardy dysk, 1 GB DDRAM, prostą kartę graficzną (właściwie DAC:) symulowaną przez virtexa :)) kartę sieciową (również wifi), muzyczną, USB, itp.
Kolejną zaletą jest szybkość działania. Ekran powitalny ukazuje się około 10 sekund od włączenia i oczywiście stabilność działania. W zasadzie można już zrezygnować z zimnego resetu :) A to wszystko przy częstotliwości zegara 100MHz, oczywiście można więcej, ale chcę niesłyszący system :)
Poważną wadą w zasadzie jest całkowite uzależnienie się potencialnego użytkownika od dostawcy systemu. Nie można sobie, tak jak w klasycznym komputerze, zainstalować referencyjnych sterowników, czy systemu operacyjnego. Wszystko jest jedynie pod ściśle określony model. Jednak za to otrzymujemy 70MB obraz systemu all-in-one. :) Ze wszystkimi fajerwerkami XP, no może wersji Home. :)
Od strony programowej, również w tym wypadku tryb Thumb jest szybszy od zwykłego trybu 32bit. Jednak jeśli chodzi o system, to kodu programu było nieporównywalnie mniej niż danych, grafiki. Jednak dla jądra systemu, thumb potrzebował około 40% mniej miejsca.
Reasumując, zabawa warta zachodu :), jednak zwykłe pc'ty dalej będą. Systemy tego typu raczej znajdą zastosowanie w konkretnych przypadkach. Jednak ARM jest w stanie zaoferować ciekawe rozwiązania, nawet dla pc'ta.
@ LucASWw
Porównywanie “Windows XP Embedded for X” z “Windows XP” jest jakimś nieporozumieniem. Słowo “Embedded” oznacza że tu jest coś odmiennego (do innych zastosowań itp.). Twoje wyniki są bardzo interesujące, choć mógłbyś podać konkretne porównania prędkości (ilości cykli, czasu itp.) przy jakiś programach/operacjach.

No i wszystko wskazuje na to że M$ powinien wydać “Windows XP Embedded for x86” – na pewno będzie działał nieco lepiej niż ten co mamy go teraz ! :-) (oczywiście pod warunkiem, że zrobią go Ci sami ludzie co robili “Embedded for ARM” i z tymi samymi założeniami)