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ę.

Nie chodzi mi o MMU ani o MPU bo to dotyczy pamięci i izolacji procesów.
Chodzi mi o mechanizmy sprzętowego wspomagania przełączania procesów.
Jak to się może obecnie nazywać ?

Pzdr

Adam

do góry

On 16.07.2013 12:06, Adam Górski wrote:
> 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.

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.

--
Pozdrawiam
Michoo

do góry

>> 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.
>

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

Pzdr

Adam

do góry

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.


--
Pozdrawiam
Michoo

do góry

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 ?
Pewnie google wie ale może kolega wie lepiej...

Pzdr

Adam

do góry

On 16.07.2013 14:32, Adam Górski wrote:
> 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 ?

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.

--
Pozdrawiam
Michoo

do góry

>>>>>> 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.
>

Wielkie dzięki za informacje. Dalej już będzie z górki.

Adam

do góry