Web Analytics
eXec.plMAGAZYN UŻYTKOWNIKÓW KOMPUTERÓW AMIGA
Amiga forum / Hyde Park / Małe dementi - nieprawdziwe informacje AmiZaPa na temat MorphOS-a

Czytasz wątek: Małe dementi - nieprawdziwe informacje AmiZaPa na temat MorphOS-a

Grzegorz
Nieaktywny użytkownik starego forum

Małe dementi - nieprawdziwe informacje AmiZaPa ... wysłany: 2008-07-23 20:37

Administrator raczył zamknąć wątek, w którym AmiZaP napisał kilka błędnych informacji na temat MorphOS-a. Postanowiłem sprostować je w oddzielnym wątku. Zaznaczam, że ograniczę się wyłącznie do sprostowania.
@AmiZaP
To wyjaśnij mi, do czego służy ta dziwna konstrukcja TRAP


Masz na myśli zapewne strukturę EmulLibEntry i parametr TRAP_LIB. Otóż jej użycie wynika z istniejącej w systemie emulacji procesora M68k. Z EmulLibEntry skorzystać trzeba, gdy natywna aplikacja PPC wywołuje kod 68k, albo wywołuje kod, który przekazuje parametry w emulowanych rejestrach procesora M68k. Typową sytuacją jest wywoływanie hooka, albo dispatcher klasy BOOPSI (który jest szczególnym przypadkiem hooka).
@AmiZaP
Gdy przecież pod OS 3.1 się tego nie stosowało


Oczywiście, że nie, bo w systemie 3.1 procesor M68k był rzeczywisty a nie emulowany. Dla porównania dodam, że w systemach PowerUP czy WarpOS przechodzenie między kodem PPC a 68k było znacznie bardziej skomplikowane niż ma to miejsce w MorphOS-ie.
@AmiZaP
I co jest grane, że wiele alokacji tak spowalnia działanie systemu?


Po pierwsze wiele alokacji nie spowalniało działania systemu, tylko powodowało fragmentację pamięci. Po drugie była to cecha alokatora pamięci z MorphOS-a 1.4. MorphOS 2.0 ma bardzo szybki i ograniczający fragmentację alokator oparty o TLSF.
@AmiZaP
Ja znalazłem też coś takiego: "The guest operating system is sandboxed in the sense that it does not run natively on the host and can only access host resources through the emulator." Czyżby to był przypadek MOS'a? Odwołania do urządzeń za pośrednictwem Quarka? Tak, czy nie?


Nie. Żaden sterownik sprzętu w MorphOS-ie nie odwołuje się do niego za pośrednictwem Quarka. Wszystkie odwołują się bezpośrednio do rejestrów sprzętu.
@AmiZap
Nie jestem developerem MOS'a, ale parę rzeczy widziałem i nie spodobały mi się. Znam też opinię Friedena na ten temat.


To pan Frieden jeden lub drugi został developerem MorphOS-a? Nic o tym nie wiem... A te rzeczy, które Ci się nie spodobały, jak widać istnieją wyłącznie w Twojej wyobraźni.



Odpowiedz

AmiZaP
Nieaktywny użytkownik starego forum

Małe dementi - nieprawdziwe informacje AmiZaPa ... wysłany: 2008-07-23 21:36

Jak tam sobie chcesz. Nie jest trudno ukrywać informacje o naturze systemu przed kimś kto nie ma dostępu do jego źródeł. Natomiast opinie o sandboksie w MOSie są dość stare i nawet pamiętam, że sami nie negowaliście ich tylko umniejszaliście ich znaczenie parę lat temu.
Jak widać ostatnio linia jest taka, że tylko wypowiedzi propagandowego guru od MOS'a mają działać ludziom na wyobraźnię.
Chciałbym jednak kiedyś poznać prawdę.
Mam wrażenie jednak, że od Ciebie jej się nie dowiem.
Ty wydzielasz tylko tyle ile trzeba, resztę przemilczając.

Odpowiedz

Grzegorz
Nieaktywny użytkownik starego forum

Małe dementi - nieprawdziwe informacje AmiZaPa ... wysłany: 2008-07-23 22:13

@AmiZaP
Jak tam sobie chcesz. Nie jest trudno ukrywać informacje o naturze systemu przed kimś kto nie ma dostępu do jego źródeł. Natomiast opinie o sandboksie w MOSie są dość stare i nawet pamiętam, że sami nie negowaliście ich tylko umniejszaliście ich znaczenie parę lat temu. Jak widać ostatnio linia jest taka, że tylko wypowiedzi propagandowego guru od MOS'a mają działać ludziom na wyobraźnię.


Widzę tu tylko niezdrowe emocje, natomiast żadnej merytorycznej dyskusji. Jeżeli mi nie wierzysz, zapytaj jakiegokolwiek innego członka MorphOS Teamu. Ale im pewnie też nie wierzysz. Wierzysz natomiast panu Friedenowi, który źródeł MorphOS-a nie widział. Cóż, można i tak.
@AmiZaP
Mam wrażenie jednak, że od Ciebie jej się nie dowiem.


Nie wiem skąd to błędne wrażenie. Chętnie się dowiem, co takiego według Ciebie tu przemilczałem.


Odpowiedz

mguc
Nieaktywny użytkownik starego forum

Małe dementi - nieprawdziwe informacje AmiZaPa ... wysłany: 2008-07-24 12:49

@AmiZaP
Nie jest trudno ukrywać informacje o naturze systemu przed kimś kto nie ma dostępu do jego źródeł. Natomiast opinie o sandboksie w MOSie są dość stare i nawet pamiętam, że sami nie negowaliście ich tylko umniejszaliście ich znaczenie parę lat temu.



O ile mi wiadomo to system MorphOS zbudowany jest w oparciu o mikrokernel nazywający się Quark. Jednym z jego zadań jest ABox który uruchamia m.in. Ambienta (czyli desktop)

Odpowiedz

AmiZaP
Nieaktywny użytkownik starego forum

Małe dementi - nieprawdziwe informacje AmiZaPa ... wysłany: 2008-07-24 22:20

@mguc

O ile mi wiadomo to system MorphOS zbudowany jest w oparciu o mikrokernel nazywający się Quark. Jednym z jego zadań jest ABox który uruchamia m.in. Ambienta (czyli desktop)


Tu jest właśnie źródło pewnych niedomówień. Co to jest np. ABox? Czy to jest proces Quarka? Jeśli tak to znaczy, że MOS jednak byłby hostowany, czyli działał w oparciu o sandbox zapewniany przez Quarka.
Tymczasem Krashan twierdzi, że Quark jest odpowiedzialny tylko za obsługę przerwań w trybie chronionym (supervisora) procesora. Reszta sterowania jest wykonywana natywnie przez MOS i ma bezpośredni dostęp do urządzeń. Zasugerował tym samym podobieństwo roli Quarka do pewnej części exec.library z OS 3.x

A jeszcze jedna rzecz mnie nurtuje w tym kontekście.

Na wcześniejsze pytanie o rolę konstrukcji TRAP odpowiedział, że to umożliwia wykonywanie kodu emulowanego (m68k) lub przekazywanie parametrów za pomocą emulowanych rejestrów tegoż. I pewnie tak jest, ale teraz sobie przypomniałem, że przecież siedzieliśmy swego czasu nad nagłówkami dla MUI próbując je wyposażyć w odpowiedniki dla AmigaOS 4. I wtedy widziałem tą tajemniczą konstrukcję TRAP w części kodu przeznaczonego dla MOS'a. A przecież te nagłówki były opracowywane dla kodu kompilowanego natywnie pod PPC, a nie pod emulowane m68k.
Więc właściwie jak to jest? Musi tam być ta konstrukcja TRAP dla kodu natywnego/PPC dla MOS'a, czy nie? A jeśli musi to co ona w tym kontekście oznacza? I dlaczego (o ile tak jest) w kodzie natywnym PPC parametry dla hooków/dispatchera muszą być emulowane?

Tylko bardzo proszę o dostosowanie stylu odpowiedzi do miejsca - to jest forum publiczne, a nie jakaś rzeźnia.

Odpowiedz

mguc
Nieaktywny użytkownik starego forum

Małe dementi - nieprawdziwe informacje AmiZaPa ... wysłany: 2008-07-25 08:12

@AmiZaP

Co to jest np. ABox? Czy to jest proces Quarka? Jeśli tak to znaczy, że MOS jednak byłby hostowany, czyli działał w oparciu o sandbox zapewniany przez Quarka.



ABox jest jednym z zadań Quarka. Tym który ma nazwę i o którym się mówi. Są też inne (np. timery). Drivery z mosa bezpośrednio (jak napisał już Grzegorz) odwołują się do rejestrów hardwarowych sprzętu. Tyle mi wiadomo. Reszty bez dostępu do źródeł - nie da się stwierdzić. Zresztą - z tego co poczytałem to AmigaOS4 również oparta jest o mikrokernel (ExecNG ?).
@AmiZaP

Zasugerował tym samym podobieństwo roli Quarka do pewnej części exec.library z OS 3.x



Quark jest podobno bardzo prostym mikrokernelem. Czy prosty oznacza prymitywny ? Nie wiem. Ważne że działa i nie stwarza programiście problemów...

@AmiZaP

I dlaczego (o ile tak jest) w kodzie natywnym PPC parametry dla hooków/dispatchera muszą być emulowane?



Sądzę że wynika to z faktu, iż nigdy nie wiadomo kiedy dany kod wykonywany jest natywnie a kiedy poprzez emulator. Co z tego że program będzie natywny, mui jako takie natywne, ale akurat jedna czy druga klasa będzie dla m68k ?

Odpowiedz

Grzegorz
Nieaktywny użytkownik starego forum

Małe dementi - nieprawdziwe informacje AmiZaPa ... wysłany: 2008-07-25 09:32

@AmiZaP
Tu jest właśnie źródło pewnych niedomówień. Co to jest np. ABox? Czy to jest proces Quarka?


Jest to jedyny proces Quarka.
@AmiZaP
Jeśli tak to znaczy, że MOS jednak byłby hostowany, czyli działał w oparciu o sandbox zapewniany przez Quarka.


Nie, bo Quark nie dostarcza żadnego sandboxa. Quark robi to, co wymaga trybu nadzorcy procesora. Podobny element systemu znajduje się również w AmigaOS 4. Różnica jest taka, że w MorphOS-ie mikrokernel jest wyraźniej oddzielony od tego co pracuje w trybie użytkownika. Wynika to z planów dotyczących QBoxa - "nowego" MorphOS-a zrywającego z kompatybilnością z AmigaOS 3.x, zapewniającego pełną ochronę pamięci dla każdego procesu i tak dalej. Gdyby to zrealizowano, to procesy QBoxa byłyby po prostu procesami Quarka, a jednym z nich byłby ABox, czyli cały MOS jakiego znamy dzisiaj. Oczywiście wymagałoby to rozbudowy Quarka o stworzenie sandboxa dla procesu ABox, bo wtedy nie mógłby już mieć dostępu do sprzętu. Plany dotyczące QBoxa zostały jednak zarzucone, a Quark pozostał prostym szkielecikiem obsługującym przerwania, timery procesora i tym podobne rzeczy wymagające trybu nadzorcy.

@AmiZaP
Musi tam być ta konstrukcja TRAP dla kodu natywnego/PPC dla MOS'a, czy nie? A jeśli musi to co ona w tym kontekście oznacza? I dlaczego (o ile tak jest) w kodzie natywnym PPC parametry dla hooków/dispatchera muszą być emulowane?


Musi być. Wynika to z faktu, że dispatcher klasy BOOPSI (a więc i MUI) jest hookiem. W natywnych klasach BOOPSI/MUI parametry dla dispatchera muszą być przekazywane w emulowanych rejestrach 68k dlatego, że kod tych klas może być wywoływany przez aplikacje 68k. Ogólniej - struktura EmulLibEntry musi pojawić się wszędzie tam, gdzie istnieje możliwość przejścia z kodu PPC na 68k lub odwrotnie. Jest to swego rodzaju interfejs między emulatorem Trance a resztą systemu.

Odpowiedz

AmiZaP
Nieaktywny użytkownik starego forum

Małe dementi - nieprawdziwe informacje AmiZaPa ... wysłany: 2008-07-27 00:47

W taki razie, by zakończyć ten wątek pod nieco mylącym tytułem, bo ja przecież tylko pytam - proponuję aby wszyscy pooglądali sobie jeszcze przykładowe kody wywoływania hook'ów. Szczególnie w kontekście, że MorphOS musi emulować rejestry m68k i korzystać w tym celu z TRAP_LIB oraz struktury EmulLibEntry.

Pod MOS'em wygląda to np. tak:



   #define M_HOOK(n, argA2, argA1) \
	LONG n##_GATE(void); \
	LONG n##_GATE2(struct Hook *h, argA2, argA1); \
	struct EmulLibEntry n = { TRAP_LIB, 0, (void (*)(void))n##_GATE }; \
	LONG n##_GATE(void) { \
		return (n##_GATE2((void *)REG_A0,\
								(void *)REG_A2,\
								(void *)REG_A1));}\
	struct Hook n##_hook = { {NULL, NULL}, (void *)&n , NULL, NULL}; \
	LONG n##_GATE2(struct Hook *h, argA2, argA1)


A pod AmigaOS 4.x wygląda to np. tak:



 #define M_HOOK(n, y, z) \
    uint32 n##_func(struct Hook *h, y, z); \
    struct Hook n##_hook = { {NULL, NULL}, (HOOKFUNC)n##_func, NULL, NULL}; \
    uint32 n##_func(struct Hook *h, y, z)


Tylko dla przypomnienia, pod AmigaOS 3.x wygląda to tak:



  #define M_HOOK(n, argA2, argA1) \
	LONG SAVEDS n##_func( pREG(struct Hook *h, a0), pREG(argA2, a2), pREG(argA1, a1) ); \
	struct Hook n##_hook = { {NULL, NULL}, (HOOKFUNC)n##_func, NULL, NULL}; \
	LONG SAVEDS n##_func( pREG(struct Hook *h, a0), pREG(argA2, a2), pREG(argA1, a1))
  #endif



Jak widać w kodzie dla AmigaOS 4 takich konstrukcji używać nie trzeba i nie muszę dodawać co bardziej mi się podoba. Szczególnie, że o gustach się przecież nie dyskutuje.


Odpowiedz

Powrót na górę ⇑ / Najnowsze wątki / Aktualności

Menu
Baza wiedzy

AmigaOS

Oprogramowanie

Katalog gier

Czasopisma o Amidze

Teraz Polska

Dev

AmigaOS.pl