aktualności

RISC-V Foundation ogłasza ratyfikację modelu programowego procesora RISC-V i specyfikację poziomów uprawnień

8
11 lipca 2019, 09:02 Adrian Kotowski

RISC-V Foundation ma powody do zadowolenia. Organizacja pochwaliło się osiągnięciem kamienia milowego dla rozwijającego się ekosystemu RISC-V, co może mieć spore znaczenie dla rynku chipów i przyciągnąć do projektu jeszcze większą liczbę podmiotów i uczelni, a także samych programistów i twórców systemów operacyjnych. Co konkretnie zapewnia wspomniana w tytule ratyfikacja? O tym przekonacie się w dalszej części newsa.

Ogłoszenie RISC-V Foundation dotyczy dwóch bardzo istotnych elementów, które będą mieć wpływ na kształt wszystkich przyszłych jednostek bazujących na tej architekturze. Zacznijmy od kwestii zatwierdzenia podstawowego modelu programowego procesora (ISA) RISC-V, który jest interfejsem do komunikacji między programami i sprzętem. Aplikacje zakodowane zgodnie z tą specyfikacją będą mogły działać na wszystkich przyszłych procesorach RISC-V, nawet jeśli wspomniana architektura ewoluuje poprzez dodanie nowych rozszerzeń. Jak twierdzi Krste Ananović, przewodniczący rady dyrektorów RISC-V Foundation, RISC-V został zaprojektowany z wykorzystaniem prostej, stałej bazowej ISA oraz stałych, modularnych rozszerzeń, co ma zapobiec fragmentacji i jednocześnie ułatwić dostosowanie modelu do własnych potrzeb.

Drugą kwestią jest zakończenie prac nad specyfikacją poziomów uprawień. To rozwiązanie służy do chronienia różnych komponentów ze stosu aplikacji i uniemożliwia wykonanie operacji niedozwolonych na konkretnym poziomie uprzywilejowania. W przypadku RISC-V opracowana architektura obejmuje wszystkie aspekty systemów, poza nieuprzywilejowaną częścią ISA, włączając w to instrukcje, dodatkową funkcjonalność niezbędną do uruchomienia systemów operacyjnych, a także techniki wykorzystywane przy podłączeniu urządzeń zewnętrznych. Każdy poziom uprawnień ma podstawowy zestaw uprzywilejowanych rozszerzeń z opcjonalnymi dodatkami i wariantami, takimi jak choćby nadzorca ISA, czy hiperwizor ISA.

Przy okazji ogłoszenia, RISC-V Foundation ujawniło, że w ciągu ostatnich kilku lat znacząca wzrosła liczba partnerów biorących udział w projekcie. Obecnie jest 275 takich organizacji (m.in. Nvidia, Samsung, Google), uniwersytetów (choćby ETH Zurich) i badaczy, a samo rozwiązanie jest już wykorzystywane komercyjnie. Warto wspomnieć, że RISC-V jest zupełnie darmowym i otwartym ISA, przez co to właśnie tę architekturę wskazywano jako następcę ARM w smartfonach Huawei, po „banie” ze strony amerykańskich władz i Qualcomma.

Rybaczek KoziołkaZobacz profil
Poziom ostrzeżenia: 0%
Rybaczek Koziołka2019.07.11, 09:28
świetna wiadomość :) z jednej strony mamy teoretyczny duopol a faktycznie monopol w najpopularniejszej arch x86 oraz głównie x86_64.
z drugiej strony w świecie mobilnym mamy ARM który podlega licencjonowaniu i wydajnościowo coraz bardziej dogania x86, oraz gasnący na rynku MIPS.

Teraz pojawia się Risc-V, gdzie licencjonowanie jest bezpłatne, ale trzeba się go trzymać. Kto zechce zrobi swój niezgodny wariant Risc-V, ale nie może też wtedy używać nazwy Risc-V. Dzięki temu unika się takiej fragmentacji jaka powstała w MIPS i która stała się gwoździem do trumny dla tej architektury.

Ciekaw tylko jestem kiedy Risc-V doczeka się bezpłatnego komponentu GPU z akceleracją 3D :) aby nie powtórzyła się historia z ARM.
AbdulahZobacz profil
Poziom ostrzeżenia: 0%
Abdulah2019.07.11, 10:41
Nadchodzą nowe czasy. Już teraz wielkie korporacje, które nie były wcześniej kojarzone z hardwarem(np. Amazon, Google), zaczynają projektować własne chipy, co staje się coraz łatwiejsze, dzięki rozwijaniu narzędzi do projektowania. Risc-V może być brakującym elementem potrzebnym do tego, alby odłożyć x86 do lamusa.
Rybaczek KoziołkaZobacz profil
Poziom ostrzeżenia: 0%
Rybaczek Koziołka2019.07.11, 11:11
Ja z kolei czekam na kolejny ogromny przełom, takie 2 w jednym, a jest to:
1. Rezygnacja z pamięci typu DRAM na rzecz pamięci memrystywnych lub elektroniczno magnetycznych, tzw. MRAM. Są to pamięci trwałe, które teoretycznie wydajnością są porównywalne DRAM, przy znikomym zużywaniu podczas pracy.
2. Przestawienie produkcji procesorów uniwersalnych z cmos na układy memrystywne
3. Elementy memrystywne pozwalają na tworzenie procesorów metamorficznych, których sposób pracy zależy od zawartości ich 'pamięci'. Wtedy do procesora ładujesz sobie taką architekturę jaką chcesz :) W tej chwili to brzmi jak jakieś SciFi, ale jest to pewna analogia do programowalnych układów logiki typu FPGA, tyle że oparte na memrystorach co powinno zapewnić o wiele większą skalę integracji, przy znacznie uproszczonej (i zajmującej mniej miejsca) programowalnej bramce.
AbdulahZobacz profil
Poziom ostrzeżenia: 0%
Abdulah2019.07.11, 11:34
Rybaczek Koziołka @ 2019.07.11 11:11  Post: 1210708

3. Elementy memrystywne pozwalają na tworzenie procesorów metamorficznych, których sposób pracy zależy od zawartości ich 'pamięci'. Wtedy do procesora ładujesz sobie taką architekturę jaką chcesz :)

Ciekawe tylko jak z czasem ładowania. Już teraz cadence pozwala w uproszczony sposób robić customowe SoCki dostosowane pod konkretną aplikację. To daje kilkukrotną poprawę wydajności. Gdyby coś takiego dało się zrobić w locie, przy ładowaniu aplikacji, to faktycznie byłby przełom.... np. OS chodziłby na z góry zdefiniowanej architekturze, a aplikacje miałbym zdefiniowaną konfiguracje docelowej architektury, która byłaby tworzona przez środowisko uruchomieniowe i używana tylko pod daną aplikację. Taka docelowa architektura pełniłaby rolę opcjonalnego akceleratora.
Edytowane przez autora (2019.07.11, 11:40)
Rybaczek KoziołkaZobacz profil
Poziom ostrzeżenia: 0%
Rybaczek Koziołka2019.07.11, 16:07
-1#5
Architekturę ładujesz raz przy bootowaniu systemu. od zawsze aplikacje musiały być dostosowane do systemu czy raczej środowiska w którym są uruchamiane, inaczej wszelkie założenia biorą w łeb. system ładuje architekturę do procka, aplikacja na tej architekturze się uruchamia. zmiana architektury co chwila mija się z celem bo po co? no chyba że ....... w warstwie sprzętowej chcielibyśmy wykonać emulację innej architektury. byłby niezły szok :D zresztą już od jakiegoś czasu ludzie robią klony starszych komputerów np. amiga czy c64 czy atari/zx i tak dalej w oparciu o FPGA, więc się da. ale takiego FPGA nie będziesz przecież przeprogramowywał co sekundę :)

tak czy siak, w procesorach metamorficznych widzę przyszłość. w końcu taki procesor może mieć ogromną ilość bloków, więc teoretycznie różne kawałki procka można by zamodelować w odmienny sposób bo czemu nie ? :D

z tworzeniem architektury per aplikacja, to bym nie przesadzał, bo to by oznaczało konieczność ciągłego przeprogramowywania architektury. procesor zamiast wykonywać programy, byłby ciągle w trybie przeprogramowywania :) i to jest w przyszłości kolejne wyzwanie dla systemu operacyjnego.

btw. już były próby implementacji CPU, który miąłby możliwość bezpośredniego wykonywania P-Code np. z Javy. Oczywiście pomysł upadł z uwagi na koszt takiego dedykowanego rozwiązania, bo java wszędzie się jednak nie panoszy. powstały konstrukcje uproszczone, i na tym koniec.

a teraz uwaga. wyobraź sobie komputer który nie ma RAM :) ma jedynie sloty podobne do RAM, gdzie w dowolny sposób rozbudowujemy klaster procesorów metamorficznych. definiujemy konfigurację RAM, VRAM, CPU, GPU i co tam jeszcze wymyślimy kiedy i jak chcemy :D
Edytowane przez autora (2019.07.11, 16:10)
AbdulahZobacz profil
Poziom ostrzeżenia: 0%
Abdulah2019.07.11, 17:24
Rybaczek Koziołka @ 2019.07.11 16:07  Post: 1210766
Architekturę ładujesz raz przy bootowaniu systemu. od zawsze aplikacje musiały być dostosowane do systemu czy raczej środowiska w którym są uruchamiane, inaczej wszelkie założenia biorą w łeb. system ładuje architekturę do procka, aplikacja na tej architekturze się uruchamia. zmiana architektury co chwila mija się z celem bo po co? no chyba że .......

Już pisałem po co - ogromny boost performancowy. Miałbyś customowe cory, dostosowane tylko to jednej aplikacji. Oczywiście nie było by sensu każdą aplikacje w ten sposób startować, a jedynie wymagające programy (jak pisałem, opcjonalna akcekeracja). W ten sposób działają urządzenia wbudowane: Rozmaite aplikacje są odpalane na osobnych gołych corach(bez OSu) a dodatkowo jest jakiś OS na osobnym chipie pełniący funkcję kontrolera. Jeżeli te cory są wyspecjalizowane, to jest to bardzo efektywny system... ale wadą tego systemu jest mała elastyczność, stąd taka architektura występuje w urządzeniach wbudowanych, firmwarach, itp... ale gdyby była pewna elastyczność, tzn. możliwość startowania w locie customowej architektury, która pełniłaby rolę akceleratora jakiejś aplikacji (niekoniecznie całej aplikacji, ale jakiegoś konkretnego workflowu), to korzyści z tego byłyby ogromne. Miałbyś elastyczność PCta a wydajność dedykowanego urządzenia.
NamonakiZobacz profil
Poziom ostrzeżenia: 0%
Namonaki2019.07.11, 17:35
Rybaczek Koziołka @ 2019.07.11 16:07  Post: 1210766
z tworzeniem architektury per aplikacja, to bym nie przesadzał, bo to by oznaczało konieczność ciągłego przeprogramowywania architektury. procesor zamiast wykonywać programy, byłby ciągle w trybie przeprogramowywania :) i to jest w przyszłości kolejne wyzwanie dla systemu operacyjnego.

btw. już były próby implementacji CPU, który miąłby możliwość bezpośredniego wykonywania P-Code np. z Javy. Oczywiście pomysł upadł z uwagi na koszt takiego dedykowanego rozwiązania, bo java wszędzie się jednak nie panoszy. powstały konstrukcje uproszczone, i na tym koniec.

wiele programów definiuje własne VM; nie tylko emulatory oraz java i .net, często jako technika anty-RE
RISC-V nie ma szans trafić pod strzechy z powodu mniejszej dostępności oprogramowania na te architekturę i braku kompatybilności z x86
intel dawno temu wprowadził itanium a dziś przestał je produkować nawet w serwerach wygrała x86_64 dzięki kompatybilności z x86
nie wiem kto wymyślił (przetłumaczył?!) nazwę procesor metamorficzny ale coś, ktoś nie doczytał https://pl.wikipedia.org/wiki/Metamorfizm
ciekawe czy podlegają mojemu ulubionemu metamorfizmowi impaktowemu ...
a może to facja (g)łupków niebieskich?
Edytowane przez autora (2019.07.11, 19:05)
anemusZobacz profil
Poziom ostrzeżenia: 0%
anemus2019.07.12, 03:21
Rybaczek Koziołka @ 2019.07.11 11:11  Post: 1210708
Ja z kolei czekam na kolejny ogromny przełom, takie 2 w jednym, a jest to:
1. Rezygnacja z pamięci typu DRAM na rzecz pamięci memrystywnych lub elektroniczno magnetycznych, tzw. MRAM. Są to pamięci trwałe, które teoretycznie wydajnością są porównywalne DRAM, przy znikomym zużywaniu podczas pracy.
2. Przestawienie produkcji procesorów uniwersalnych z cmos na układy memrystywne
3. Elementy memrystywne pozwalają na tworzenie procesorów metamorficznych, których sposób pracy zależy od zawartości ich 'pamięci'. Wtedy do procesora ładujesz sobie taką architekturę jaką chcesz :) W tej chwili to brzmi jak jakieś SciFi, ale jest to pewna analogia do programowalnych układów logiki typu FPGA, tyle że oparte na memrystorach co powinno zapewnić o wiele większą skalę integracji, przy znacznie uproszczonej (i zajmującej mniej miejsca) programowalnej bramce.

Średnio bo koszta jako pamięci i stany nieustalone w wypadku przetwarzania w bardziej skomplikowanych strukturach. Znam wiele ludzi wątpiących czy memrystory w ogóle się przydadzą nawet do przetwarzania neuronowego, a do binarnego wykluczają (zajmują się takimi rzeczami).
Wracając do coś co nieszczęśliwie nazwałeś procesorem metamorficznym to nie ma sensu w takim wydaniu z wielu powodów. Po pierwsze ładowanie przez system jest koniecznością według wspólnego modelu bo współpraca aplikacji, bibliotek i podsystemów programowych i sprzętowych była by niemożliwa.
W sumie można by zrealizować ale w strukturze warstwowej ale nie wiem czy narzut nie pożarł by ewentualne zyski. Ale jakby zrobić interfejs dla koprocesora będącego w istocie takim układem to mogło by wypalić o ile znalazła by się możliwość implementacji (memrystory wątpię jak wspomniałem)
Edytowane przez autora (2019.07.12, 03:31)
Zaloguj się, by móc komentować
1