Rozwój oprogramowania komórki

Rozwój oprogramowania dla mikroprocesora Cell obejmuje połączenie konwencjonalnych praktyk programistycznych dla rdzenia PPU kompatybilnego z PowerPC oraz nowych wyzwań związanych z tworzeniem oprogramowania w odniesieniu do koprocesorów SPU o ograniczonej funkcjonalności.

Linux na komórkę

Przyjęto strategię opartą na oprogramowaniu open source, aby przyspieszyć rozwój ekosystemu Cell BE i zapewnić środowisko do tworzenia aplikacji Cell, w tym kompilator Cell oparty na GCC, binutils i port systemu operacyjnego Linux.

Oktopiler

Octopiler to prototyp kompilatora IBM , który umożliwia programistom pisanie kodu dla procesorów Cell .

Przenośność oprogramowania

Dostosowanie VMX do SPU

Różnice między VMX a SPU

Technologia VMX (Vector Multimedia Extensions) jest koncepcyjnie podobna do modelu wektorowego zapewnianego przez procesory SPU, ale istnieje wiele znaczących różnic.


Porównanie VMX do SPU niedokończone
funkcja VMX SPU
rozmiar słowa 32 bity 32 bity
liczba rejestrów 32 128
szerokość rejestru 128-bitowe czterosłowo 128-bitowe czterosłowo
formaty liczb całkowitych 8, 16, 32 8, 16, 32, 64
wsparcie nasycenia Tak NIE
kolejność bajtów duży (domyślnie), mały duży endian
tryby zmiennoprzecinkowe Java, nie-Java pojedyncza precyzja, IEEE podwójna
Wyrównanie pamięci tylko czterosłowa tylko czterosłowa

Java Tryb VMX jest zgodny z podzbiorem Java Language Specification 1 domyślnego standardu IEEE , rozszerzonym o zgodność z IEEE i C9X , w przypadku gdy standard Java milczy. W typowej implementacji tryb inny niż Java konwertuje odbiegające od normy na zero, ale tryb Java przechwytuje emulator, gdy procesor napotka taką wartość.

Podręcznik IBM PPE Vector/SIMD nie definiuje operacji dla zmiennoprzecinkowych podwójnej precyzji, chociaż IBM opublikował materiał sugerujący pewne liczby wydajności podwójnej precyzji związane z technologią Cell PPE VMX.

Wewnętrzne

Kompilatory dla Cell [ kto? ] zapewniają elementy wewnętrzne , które udostępniają przydatne instrukcje SPU w językach C i C++. Instrukcje, które różnią się tylko typem operandu (takie jak a, ai, ah, ahi, fa i dfa dla dodawania) są zwykle reprezentowane przez pojedynczą wewnętrzną instrukcję C/C++, która wybiera odpowiednią instrukcję na podstawie typu operandu.

Przenoszenie kodu VMX dla SPU

Istnieje ogromna ilość kodu, który został opracowany dla innych mikroprocesorów IBM Power , który potencjalnie mógłby zostać zaadaptowany i ponownie skompilowany, aby działał na SPU. Ta baza kodu zawiera kod VMX, który działa w wersji PowerPC systemu Mac OS X firmy Apple , gdzie jest lepiej znany jako Altivec . W zależności od tego, ile specyficznych funkcji VMX jest zaangażowanych, wymagana adaptacja może wahać się od prostych, przez uciążliwe, do całkowicie niepraktycznych. Najważniejsze obciążenia dla SPU są generalnie dość dobrze odwzorowywane.

W niektórych przypadkach możliwe jest bezpośrednie przeniesienie istniejącego kodu VMX. Jeśli kod VMX jest bardzo ogólny (nie zawiera kilku założeń dotyczących środowiska wykonawczego), tłumaczenie może być stosunkowo proste. Dwa procesory określają inny format kodu binarnego , więc wymagana jest co najmniej ponowna kompilacja. Nawet jeśli instrukcje z tymi samymi zachowaniami, nie mają one takich samych nazw instrukcji, więc to również musi zostać zmapowane. IBM udostępnia wewnętrzne elementy kompilatora , które w przejrzysty sposób dbają o to odwzorowanie, jako część zestawu narzędzi programistycznych.

Jednak w wielu przypadkach bezpośrednio równoważna instrukcja nie istnieje. Obejście problemu może być oczywiste, a może nie. Na przykład, jeśli wymagane jest zachowanie nasycenia w SPU, można je zakodować, dodając dodatkowe instrukcje SPU, aby to osiągnąć (z pewną utratą wydajności). Z drugiej strony, jeśli wymagana jest semantyka zmiennoprzecinkowa Java, jest to prawie niemożliwe do osiągnięcia na procesorze SPU. Osiągnięcie tych samych obliczeń na SPU może wymagać napisania od podstaw zupełnie innego algorytmu .

Najważniejszym koncepcyjnym podobieństwem pomiędzy VMX a architekturą SPU jest obsługa tego samego modelu wektoryzacji. Z tego powodu większość algorytmów dostosowanych do Altivec zwykle z powodzeniem dostosowuje się również do architektury SPU.

Eksploatacja lokalnego sklepu

Przesyłanie danych między lokalnymi magazynami różnych SPU może wiązać się z dużymi kosztami wydajności. Lokalne magazyny poszczególnych SPU można wykorzystać przy użyciu różnych strategii.

Aplikacje o dużej lokalności, takie jak gęste obliczenia macierzowe, reprezentują idealną klasę obciążenia dla lokalnych sklepów w Cell BE.

Obliczenia przesyłane strumieniowo można skutecznie dostosować za pomocą potokowania programowego transferów bloków pamięci przy użyciu strategii wielu buforów.

Pamięć podręczna oprogramowania oferuje rozwiązanie dla dostępu losowego.

Bardziej wyrafinowane aplikacje mogą wykorzystywać wiele strategii dla różnych typów danych.

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Cell_software_development&oldid=1119174228 ”