Ujawniania szczegółów techniczncyh systemu AmigaOS 4 ciąg dalszy. Po serii artykułów opisujących: AmiDock i application.libary, Amiga Input, nowy FastFileSystem oraz dos.library, Hans-Joerg Frieden wytłumaczył w jaki sposób nowy AmigaOS podchodzi do tematu systemowych bibliotek. Dla klubowiczów dostępny jest nowy numer magazynu CAM.
Dodano: 2003-08-09 00:00, Autor: kb, Kategoria: AmigaOS, Liczba wyświetleń: 4264
AmigaOS 4 - biblioteki
Zobacz podobne newsy:
-
Discord (online: ) «»
-
Online: 14
AmiKit
Archi-TECH
Cizar
Dobrowit
Heng
IMPBot
Janusz82
juen
Laubzega
m...
MaaG^dA
NorBert
Patu
spazma
-
Jacek Rzeuski
Czytelnik
-
komentarz #1 wysłany: brak daty
Super, trochę się obawiałem, że nie dadzą rady zrealizować tego zamysłu.
-
Konrad Bielski
Redaktor
-
komentarz #2 wysłany: brak daty w odpowiedzi na komentarz #1
Twoje obawy, że GDB dodane do dos.library nie będzie miało właściwego front-endu również okazały się płonne.
-
Marcin Juszkiewicz
Czytelnik
-
komentarz #3 wysłany: brak daty
A jak to zostało rozwiązane w MorphOSie? Bo prawdę mówiąc to nigdy nie czytałem devel-doców od PowerUp.
-
Jacek Rzeuski
Czytelnik
-
komentarz #4 wysłany: brak daty w odpowiedzi na komentarz #2
Po pierwsze to GDB z dos.library nie ma kompletnie nic wspólnego i ja nigdy nie twierdziłem, że ma. Po drugie to skąd informacje, że jest front-end? Coś przegapiłem?
-
Jacek Rzeuski
Czytelnik
-
komentarz #5 wysłany: brak daty w odpowiedzi na komentarz #3
Właściwie to nijak. Niestety. Zmieniony jest ramlib. Próbuje ładować wersję PPC bibliteki (szuka pliku xyz.library.elf). Jeśli nie znajdzie, to wywołanie funkcji z biblioteki 68k wywołuje wyjątek przechwytywany przez emulator 68k. Słabe to jest, ale to było najprostsze do zrobienia i nie wymagało pracy projektowej.Nie jestem pewien jak jest rozwiązane jump-table w przypadku bibliotek PPC, ale skoro są one automatycznie używane bez konieczności rekompilacji programu, to jump-table musi być identyczne w wersji 68k jak i PPC. Czyli mamy dokładnie, to czego chcieli uniknąć autorzy AmigaOS4. A co więcej prawie niemożliwe stanie się napisanie wrappera dla systemu bibliotek z AmigaOS4 a tym samym dla aplikacji AmigaOS4...
-
Marcin Juszkiewicz
Czytelnik
-
komentarz #6 wysłany: brak daty w odpowiedzi na komentarz #5
AmigaOS 3.1 PPC
MSPANC całą gębą
-
Mariusz Barczyk
Czytelnik
-
komentarz #7 wysłany: brak daty w odpowiedzi na komentarz #6
Nie wiedzialem, ze AOS 3.1 ma takie ladne ikonki i gradienty
-
Konrad Bielski
Redaktor
-
komentarz #8 wysłany: brak daty w odpowiedzi na komentarz #4
Po pierwsze to GDB z dos.library nie ma kompletnie nic wspólnego i ja nigdy nie twierdziłem, że ma.Po drugie to skąd informacje, że jest front-end?
Widzisz, mam AmigaOS 4 zainstalowany na swojej Amidze, więc i wbudowany w niego debugger GDB z front-endem o którym mowa widziałem.
-
Albert Jasiński
Czytelnik
-
komentarz #9 wysłany: brak daty w odpowiedzi na komentarz #5
Powiedz mi Jacku, jaki ma system bibliotek użyty w mosie wpływ na sam system ? Czy go w jakiś sposób ogranicza ? A może jedyne ograniczenie to niemożność wrappowania bibliotek OS4 ?
Dlaczego jednak Fridenowie nie chcieli się pakować w system bibliotek znany z OS3.1 ?
-
Jacek Piszczek
Czytelnik
-
komentarz #10 wysłany: brak daty w odpowiedzi na komentarz #9
MorphOS od początku przewiduje dwie style pisania bibliotek. Jedne zgodne z wywoływaniem przez kod 68k, inne tylko dla PPC.
-
Jacek Rzeuski
Czytelnik
-
komentarz #11 wysłany: brak daty w odpowiedzi na komentarz #8
Hehe, ten slajd albo celowo ma dezinformować kogoś nie zaznajomionego z tematem albo po prostu nie chciało im się robić osobnego slajdu na temat debuggingu i wepchnęli to na slajd zatytułowany "DOS", bo tam akurat było wolne miejsce
Możesz rzucić jakiś screenshot tego front-endu? Może być na priv. Nawet wzór NDA do podpisu możesz załączyć ;->
-
Jacek Rzeuski
Czytelnik
-
komentarz #12 wysłany: brak daty w odpowiedzi na komentarz #10
Zgadza się tyle, że API jest to samo co w AOS 3.1. I to jest zasadnicza różnica w stosunku do OS4.x.
-
Jacek Rzeuski
Czytelnik
-
komentarz #13 wysłany: brak daty w odpowiedzi na komentarz #9
Na sam system ma niewielki wpływ. Natomiast może mieć spory wpływ na wygodę pisania aplikacji. To co proponuje się w OS4 pozwala na znacznie wygodniejsze modyfikowanie działania funkcji bibliotecznych niż stare SetFunction() i to w sposób obiektowy z poziomu języka wysokiego poziomu. Znakomicie też ułatwia pisanie wszelkich plug-inów. Obecnie jest to okrutne rzeźbiarstwo i co autor, to inny pomysł na rozwiązanie tego problemu.Friedenowie jasno powiedzieli czemu nie chcieli się pakować w stary system bibliotek. Bo niesie on ze sobą masę ograniczeń i upierdliwości a do tego tu dochodzi jeszcze zmiana CPU, co wymuszałoby opóźnienia związane z wykrywaniem typu kodu, co może znakomicie obniżyć wydajność często wywoływanych krótkich funkcji jak np. WritePixel(). Założyłbym się, że porównanie wydajności tej funkcji w obu systemach zdeklasowałoby rozwiązanie MorphOSowe. I to niezależnie od tego czy będzie to funkcja 68k czy PPC. Inna sprawa, że takich funkcji w systemie jest bardzo mało a dla większości dodatkowy nakład związany z ich wywołaniem by utonął w czasie wykonania samej funkcji.
Tym niemniej obiektowe podejście do całego systemu za pośrednictwem nowego interfejsu bibliotek cholernie mi się podoba. To może zaowocować całkowicie nowym podejściem do tworzenia aplikacji dla AmigaOS. Wreszcie AmigaOS ma szanse wkroczyć w XXI wiek. Widać to już choćby po przykładzie rozwiązania obsługi PCI opisanego w artykule. Osobom zaznajomionym z programowaniem polecam zastanowienie się jak to może wpłynąć np. na BOOPSI i pisanie własnych klas.
PS. Teraz jeszcze czekam na artykuł opisujący problem hooków w nowym AmigaOS, bo to kolejne PITA w AmigaOS.
-
Kornel Lesinski
Czytelnik
-
komentarz #14 wysłany: brak daty w odpowiedzi na komentarz #5
Polecam wskoczyć czasem na #morphos i zapytać. Ja tak zrobiłem i bez problemu uzyskałem odpowiedź.
Nazwa biblioteki (.elf) nie ma tutaj znaczenia. Wszystkie biblioteki na pegasosie mogą się nazywać normalnie i nie ma znaczenia czy są 68k czy ppc.
Skoki 68k<->PPC są wykonywane albo przez niby-instrukcję 68k albo za pośrednictwem struktury podczepionej pod r2, natomiast programy ppc mogą wywoływać funkcje bibliotek ppc bezpośrednio, bez udziału emulatora.
Jak widać nie jest to jakaś dramatyczna różnica od działania w os4.
Jednak trzeba przyznać, że nowy "jumptable" w os4 wygląda ciekawie szczególnie przez ukłon w kierunku obiektowości. Chociaż pierwsze co bym zrobił to makra usuwające FooIFace-> sprzed nazw funkcji, bo z ciągłym pisaniem tego można by zwariować.
Natomiast nie widzę przeszkód w stworzeniu odpowiednika GetInterface() dla morphosowych programów i bibliotek - skoro bezposredni skok jest możliwy, wystarczy tylko zbudować listę wskazników.
-
Kornel Lesinski
Czytelnik
-
komentarz #15 wysłany: brak daty w odpowiedzi na komentarz #13
do tego tu dochodzi jeszcze zmiana CPU, co wymuszałoby opóźnienia związane z wykrywaniem typu kodu, co może znakomicie obniżyć wydajność często wywoływanych krótkich funkcji jak np. WritePixel(). Emulowany sysspeed stawia 720000 pixeli na sekunde za pomoca graphics.library na ppc. Z jakis obskurnych wynikow jakie wygooglowalem wynika, ze to predkosc wcale nie gorsza od natywnego windzianego setpixela.
-
Albert Jasiński
Czytelnik
-
komentarz #16 wysłany: brak daty w odpowiedzi na komentarz #15
Takie porównania niekoniecznie muszą być miarodajne.
To że karta nie rysuje wolniej niż na PC nie onacza że CPU komputera nie jest niepotrzebnie zajmowany.
Żeby się dowiedzieć czegoś konkretnego, trzeba by było sprawdzić dokładnie ten sam sprzęt zarówno pod morphosem jak i pod Linuxem który jak mniemam ma bardzo zoptymalizowane wszystkie sterowniki i biblioteki. Co więcej test musiałby obejmować nie tylko prędość rysowania jak ale i monitorowanie zajętość CPU podczas wykonywania WritePixel.
Jeżeli się mylę to niech ktoś sprostuje (ale rzeczowo)
-
Kornel Lesinski
Czytelnik
-
komentarz #17 wysłany: brak daty w odpowiedzi na komentarz #16
Takie porównania niekoniecznie muszą być miarodajne.
I w sumie nie są, bo żaden programista o zdrowych zmysłach nie używa WritePixel.
Natomiast ten test pokazuje, że sytuacja nie jest tak katastrofalna jak przedstawił ją Jacek.
zarówno pod morphosem jak i pod Linuxem
Linux nie ma do czynienia z amigowymi bibliotekami i emulacją. Jak już porównywać to z AmigaOS.
-
Albert Jasiński
Czytelnik
-
komentarz #18 wysłany: brak daty w odpowiedzi na komentarz #17
I w sumie nie są, bo żaden programista o zdrowych zmysłach nie używa WritePixel.
Jacek podał WritePixel jako tylko przykład takiej funkcji którą się często wywołuje (jeżeli się z niej kożysta).
Takich funcji jest napewno więcej.
Linux nie ma do czynienia z amigowymi bibliotekami i emulacją. Jak już porównywać to z AmigaOS.
Ale właśnie o to chodzi żeby sprawdzić ile traci się z mocy procesora podczas częstego wywoływania funkcji takiej jak WritePixel z biblioteki zgodnej z API dawnego AmigaOS.
Sprawdzić to można porównując wyniki testów obciążenia procesora podczas wykożystania funkcji WritePixel pod MOsem z wynikami testów obciążenia procesora przeprowadzonych na Linuxie (który ma napewno bardzo nowoczesne API) przy wykożystaniu analogicznej Funkcji pod tym systemem.
Chodzi konkretnie o sprawdzenie ile task uzywający Writepixel potrzebuje mocy procesora pod linuxem a ile pod MOSEM ... uważam że kluczowe tutaj jest przeprowadzenie testów na tym samym sprzęcie.
No ale może się mylę może takie badanie trzeba inaczej przeprowadzić
-
Kornel Lesinski
Czytelnik
-
komentarz #19 wysłany: brak daty w odpowiedzi na komentarz #18
Jacek podał WritePixel jako tylko przykład takiej funkcji którą się często wywołuje (jeżeli się z niej kożysta).
Takich funcji jest napewno więcej
Tak często, żeby pare rozkazów procesora miało zauważalny wpływ na ogólną predkość programu? Nie znam.
Normalnie robi sie kilkadziesiat, najwyzej kilkaset wywolan do jakiejś wiekszej czynnosci (typu uruchomienie programu/otworzenie okna).
Jak pokazuje benchmark do zamulenia potrzeba by kilkaset *tysięcy*.
Np. w AmigaOS3 wywolania funkcji miedzy ppc<>68k byly tak wolne, że gry/playery sie robiło aby zadowalały się 2-3 odwołaniami na klatkę.
Ten "wolny" Morphos (wg warp race) jest w tym dokładnie 999x szybszy. Testowane na Amidze Jacka
Nadal nie rozumiem jak porowanie mos z natywnym api linuxa ma pokazać o ile wydajniejszy jest system bibliotek amigaos4.
To ze amigaone jest z linuxem sprzedawana nie znaczy ze linux jest amigowym systemem i nie robmy z niego punktu odniesienia.
-
Albert Jasiński
Czytelnik
-
komentarz #20 wysłany: brak daty w odpowiedzi na komentarz #19
Nadal nie rozumiem jak porowanie mos z natywnym api linuxa ma pokazać o ile wydajniejszy jest system bibliotek amigaos4.
Nie "o ile jest wydajniejszy system bibliotek OS4" tylko "jak bardzo niewydajny jest system OS3.x/MOS".
To sprawdzenia tego wystarczy wykonać testy pod MOSem i pod jakimś systemem z nowoczesnym API.
Jak jednak donoszą specjaliści (na moj prywatny Email), Linux ma bardzo mało wydajną grafikę z zupełnie innych powodów więc faktycznie jest kiepskim punktem odniesienia dla takich testów.
To ze amigaone jest z linuxem sprzedawana nie znaczy ze linux jest amigowym systemem i nie robmy z niego punktu odniesienia.
Napewno Amiga ma więcej wsólnego z linuxem niż z windowsami na PC do których Pan poorównywał wyniki testów uzyskanych pod sysspeedem (można poczytać parę komentów wyżej).
Tylko że ja nie robię przytyków typu:
To że Morphosowy motyklek jest niebieski nie znaczy że za punkt odniesienia należy brać windziany benchmark odpalony na PC.
-
Jacek Rzeuski
Czytelnik
-
komentarz #21 wysłany: brak daty w odpowiedzi na komentarz #19
Widać, że słabo znasz AmigaOS. Popatrz sobie choćby na takie funkcje w graphics.library jak SetFont(), SetAPen(), SetBPen() czy Move(). W innych bibliotekach też znajdziesz funkcje, które praktycznie nie robią nic poza ustawieniem jakiegoś pola w strukturze. Pewnie, że WritePixel() to specyficzny przypadek, ale właśnie on potrafi najwyraźniej ukazać różnice w prędkości obu rozwiązań. Nie znaczy to jednak, że takie SetAPen() nie jest wywoływane setki razy przy renderowaniu skomplikowanego GUI opartego na klasach, gdzie każdy element ma swoją funkcję do renderingu, która ustawia wszystkie potrzebne parametry RastPortu. Nie każdy jeszcze uzywa tylko skórek i BltBitmap() do namalowania czegoś na ekranie.
-
Kornel Lesinski
Czytelnik
-
komentarz #22 wysłany: brak daty w odpowiedzi na komentarz #21
SetAPen() nie jest wywo?ywane setki razy przy renderowaniu skomplikowanego GUI No wlasnie, setki. Temu daleko do "setki tysi?cy". Wystarczy spojrzec jak szybko morphos chodzi w praktyce - tych paru zb?dnych instrukcji nie wida?, szczególnie ?e zdecydowana wi?kszo?? bibliotek jest natywna. Jak wyjdzie OS4 na A1 to bedzie mozna sie po?ciga? miedzy 0.02 sekundy na zaemulowanie boopsi gui vs 0.015.
-
Kornel Lesinski
Czytelnik
-
komentarz #23 wysłany: brak daty w odpowiedzi na komentarz #21
[ups, sory za syfny koment powyzej]
SetAPen() nie jest wywoływane setki razy przy renderowaniu skomplikowanego GUI
No wlasnie, setki. Temu daleko do "setki tysięcy".
Wystarczy spojrzec jak szybko morphos chodzi w praktyce - tych paru zbędnych instrukcji nie widać, szczególnie że zdecydowana większość bibliotek jest natywna.
Jak wyjdzie OS4 na A1 to bedzie mozna sie pościgać miedzy 0.02 sekundy na zaemulowanie boopsi gui vs 0.015.
-
Kornel Lesinski
Czytelnik
-
komentarz #24 wysłany: brak daty w odpowiedzi na komentarz #20
Ok, masz racje, moja uwaga była nie na miejscu.
-
Albert Jasiński
Czytelnik
-
komentarz #25 wysłany: brak daty w odpowiedzi na komentarz #24
Chyba zaraz piwo wypije ze szczescia ... wreszcie po tylu latach mojego trollowania ktoś z oponentów przyznał mi rację ;D
To bardzo budujące .. zapewniam że teraz napewno moich komentów tu nie zabraknie
Wracając jednak do tematu rozmowy.
Teraz ja z kolei przyznać rację. Zastosowane API nie ma prawie żadnego znaczenia dla szybkości działąnia systemu. Znaczenie optymalizacji API (ale także i kodu programu) będzie w dalszym ciągu spadało wraz ze wzrostem wydajności procesorów.
Najlepiej to widać na przykładzie Amithlona który wydaje się być najwydajniejszym Amigowym rozwiązaniem ... biorąc oczywiście pod uwagę stosunek wydajności systemu do ceny sprzętu (zapominając o tym ile mocy tego sprzętu się zmarnuje na emulację).
Nie można jednak zapomnieć że straty na wydajności to nie jedyna wada starego API.
Z tego co Jacek (nie Jaca) napisał wynika że stare API jest też mniej wygodne dla programistów. A niewykluczone że będzie stważało problemy w przyszłości gdy konieczne będzie wdrożenie pewnych nowinek.
Czy nie lepiej było by jednak aby system opierał się na w miarę nowoczesnym szkielecie ?
-
Kornel Lesinski
Czytelnik
-
komentarz #26 wysłany: brak daty w odpowiedzi na komentarz #25
API jest też mniej wygodne dla programistów.
No, zalezy jak na to spojrzec. Jacek wspominal, ze to ulatwia pisanie pluginow. z drugiej strony niepotrzebnie dodaje pisania FooIFace-> przed kazda funkcja. Pozyjemy, zobaczymy.
Czy nie lepiej było by jednak aby system opierał się na w miarę nowoczesnym szkielecie ?
Co do nowoczesnosci API to rewelacyjniejsze by bylo jakby ukryto struktury systemowe. Wskazniki zamienione na handle. Tym sposobem nie ma ryzyka zawieszenia gdy sie uzyje handle po zamknieciu okna, takze mozna handle przekazac do innego procesu niezaleznie od modelu/ochrony pamieci. Forbid/LockIBase i inne takie funkcje nie byly by juz konieczne...
-
Jacek Rzeuski
Czytelnik
-
komentarz #27 wysłany: brak daty w odpowiedzi na komentarz #26
Mocno się zdziwię, jeżeli IFace-> nie ukryją w inline, żeby nie trzeba było tego klepać.
-
Kornel Lesinski
Czytelnik
-
komentarz #28 wysłany: brak daty w odpowiedzi na komentarz #27
Tez sie dziwie. To przeciez niepotrzebnie psuje kompatybilnosc zrodel (chcialo im sie poprawiac?).
Moze tylko w opisie to tak podali dla szpanu?
- Discord
-
Online: 14
- Menu
- Baza wiedzy
- Najpopularniejsze
