Sprzętowe wspomaganie przełączania procesów w procesorach ARM - jak to działa?

Witam,

Przeglądam sobie kolejne procesory ARM i zastanawia mnie jedna sprawa.
Nigdzie nie widzę mechanizmów sprzętowego wspomagania przełączania
procesów/wątków.

Czy to ja źle patrzę czy to dalej odbywa się jak kiedyś
- tzn zrzut wszystkich rejestrów do pamięci i pobranie nowego zestawu
dla kolejnego procesu.

Pamiętam że było coś takiego bodajże w procesorach Ubicoma ale w żadnym
z armów tego nie widzę.

Przeglądam sobie kolejne procesory ARM i zastanawia mnie jedna sprawa.
Nigdzie nie widzę mechanizmów sprzętowego wspomagania przełączania
procesów/wątków.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/Cjaebbeh.html



Czy to ja źle patrzę czy to dalej odbywa się jak kiedyś
- tzn zrzut wszystkich rejestrów do pamięci i pobranie nowego zestawu
dla kolejnego procesu.

Tak i nie - masz instrukcje, które to upraszczają, ale nie jest to
prosta podmiana indeksu w tablicy procesów(jak by to wyglądało przy
całkowicie sprzętowej obsłudze kontekstu).

Pamiętam że było coś takiego bodajże w procesorach Ubicoma ale w żadnym
z armów tego nie widzę.

Niezgodne z filozofią RISC.

Pamiętam że było coś takiego bodajże w procesorach Ubicoma ale w żadnym
z armów tego nie widzę.

Niezgodne z filozofią RISC.


Idąc tym tropem nie ma takich mechanizmów w żadnym procesorze bo nawet
x86 to dzisiaj RISC , o x64 nawet nie wspominając.

On 16.07.2013 12:58, Adam Górski wrote:

Pamiętam że było coś takiego bodajże w procesorach Ubicoma ale w żadnym
z armów tego nie widzę.

Niezgodne z filozofią RISC.


Idąc tym tropem nie ma takich mechanizmów w żadnym procesorze bo nawet
x86 to dzisiaj RISC , o x64 nawet nie wspominając.

Ni. x86 to dzisiaj nadal CISC. To np. Sandy Bridge na którym amd64 jest
uruchamiany/emulowany jest rzeczywiście RISC-like.

A wracając do problemu - sprzętowe implementacja zmian kontekstu to
zbędna komplikacja jeżeli można to zrobić RISC-like.

Np na cortex-m3 całość sprowadza się do ustawienia wskaźnika na
thread-control-block i wczytania rejestrów. Używasz instrukcji ogólnego
przeznaczenia a całe wsparcie sprowadza się do projektu architektury,
która to umożliwia.

W dniu 2013-07-16 13:24, Michoo pisze:
On 16.07.2013 12:58, Adam Górski wrote:

Pamiętam że było coś takiego bodajże w procesorach Ubicoma ale w
żadnym
z armów tego nie widzę.

Niezgodne z filozofią RISC.


Idąc tym tropem nie ma takich mechanizmów w żadnym procesorze bo nawet
x86 to dzisiaj RISC , o x64 nawet nie wspominając.

Ni. x86 to dzisiaj nadal CISC. To np. Sandy Bridge na którym amd64 jest
uruchamiany/emulowany jest rzeczywiście RISC-like.

Czy mógłby kolega zapodać kilka słów kluczowych lub sznurków ?

Mając dziesiątki lub setki o ile nie tysiące różnych wątków/procesów
ciągłe przeładowywanie rejestrów musi kosztować masę czasu jeżeli jest
to czysto programowe

A wracając do problemu - sprzętowe implementacja zmian kontekstu to
zbędna komplikacja jeżeli można to zrobić RISC-like.

Pewnie , tylko jest gdzieś granica opłacalności odnośnie minimalnego
czasu przydziału dla wątku/procesu.

Np na cortex-m3 całość sprowadza się do ustawienia wskaźnika na
thread-control-block i wczytania rejestrów. Używasz instrukcji ogólnego
przeznaczenia a całe wsparcie sprowadza się do projektu architektury,
która to umożliwia.

A ma może kolega jakiś sznurek do tego opisu thread-control-block ?

Pamiętam że było coś takiego bodajże w procesorach Ubicoma ale w
żadnym
z armów tego nie widzę.

Niezgodne z filozofią RISC.


Idąc tym tropem nie ma takich mechanizmów w żadnym procesorze bo nawet
x86 to dzisiaj RISC , o x64 nawet nie wspominając.

Ni. x86 to dzisiaj nadal CISC. To np. Sandy Bridge na którym amd64 jest
uruchamiany/emulowany jest rzeczywiście RISC-like.

Czy mógłby kolega zapodać kilka słów kluczowych lub sznurków ?

microcode, x86 context switch, TSS Descriptor, call gate


Mając dziesiątki lub setki o ile nie tysiące różnych wątków/procesów
ciągłe przeładowywanie rejestrów musi kosztować masę czasu jeżeli jest
to czysto programowe

Jak masz tysiące różnych wątków próbujących działać _na raz_ to masz
system który większość czasu jedyne co robi to marnuje zasoby na ich
przełączanie - niezależnie od tego czy masz wsparcie sprzętowe czy nie.

I tak najdroższe w całej zabawie w multi-tasking (nie dotyczy właśnie
maleństw w rodzaju m-3 z wewnętrznym ramem - tam to frunie)jest
zazwyczaj psucie cache, przeładowywanie MMU i tym podobne sprawy. Zmiana
kontekstu ma główne znaczenie przy wywołaniach systemowych.


A wracając do problemu - sprzętowe implementacja zmian kontekstu to
zbędna komplikacja jeżeli można to zrobić RISC-like.

Pewnie , tylko jest gdzieś granica opłacalności odnośnie minimalnego
czasu przydziału dla wątku/procesu.

Na x86 masz do tego instrukcję CISC, na m-3 robisz to 3 instrukcjami
RISC. I tak limitujące będzie (jeżeli chodzi o samo działanie procka)
odczytanie z pamięci czy to stanu (x86) lub rejestrów(arm).


Np na cortex-m3 całość sprowadza się do ustawienia wskaźnika na
thread-control-block i wczytania rejestrów. Używasz instrukcji ogólnego
przeznaczenia a całe wsparcie sprowadza się do projektu architektury,
która to umożliwia.

A ma może kolega jakiś sznurek do tego opisu thread-control-block ?

Ma. Wskazuje na Cortex-M3 Technical Reference Manual.