23.06.2018 18:53
[#271]
Re: CD32-AKIKO
@AmmigaCDTV, post #260
A co do kosztów produkowania układów itp. itd. to mi chodziło o inwestora, który ma te 200-300mln$ a nie 200 czy 300 tysięcy złotych.
te 200-300mln$ to duża przesada, myślę że to byłoby do wykonania z budżetem mniejszym niż 1% tej sumy, wystarczy 2 mln $
200-300 tyś $ przygotowanie masek do produkcji
1 mln $ produkcja 100 tyś sztuk układu ( myślę że przy tej ilości koszt jednej sztuki nie przekroczy 10$ )
200 tyś $ inne koszty związane z produkcją gotowych chipów ( prototypy, pierwsza testowa partia, cięcie wafli, miniPCB i zalanie tego w obudowę z tworzywa )
to góra 1,5 mln $ i mamy 100 tyś układów
Klienci na 100 tyś sztuk to raczej nie realne, ale jak widzę jakie jest zainteresowanie V2 to 30 tyś sztuk może i by poszło ?
koszt PCB, pasywnych elementów, gniazd, przetwornicy napięcia, interfejsów ( jak LAN czy USB ) i montażu tego wszystkiego na PCB wielkości Raspberry PI przy 30 tyś sztuk powinno zamknąć się w 10-15$ ( jakieś 500 tyś $ )
czyli max 2 mln $, może nawet i jakąś obudowę jak w Raspberry PI by zmieścił w tym, czyli mamy 30 tyś kompletnych komputerów i 70 tyś układów na magazynie :)
jakby sprzedać te 30 tyś sztuk nawet za połowę ceny która tu padała ( powiedzmy 799 zł zamiast 1499 zł, czyli jakieś 215 $) to cała inwestycja dałaby 100% zysku i zostało by 70 tyś sztuk układów do jakichś następnych projektów jak netbook, czy jakieś karty turbo do klasycznych Amig.
30 000 x 215$ = 6 450 000 $ ( wartość w detalu brutto )
- 1 100 000 $ (10-15% koszt dystrybucji lub upusty hurtowe dla pośredników )
- 1 000 000 $ ( 23% VAT )
- 300 000 $ ( pozostałe koszty, marketing, serwis, transport )
zostaje około 4 000 000, to 2x więcej niż poniesione koszty na wyprodukowanie
pozostaje jeszcze kwestia licencji na Kickstart/Workbench, no i samego kodu VHDL nad którym pracuje Apollo Team
Ostatnia aktualizacja: 23.06.2018 19:00:11 przez UJP
23.06.2018 19:00
[#272]
Re: CD32-AKIKO
@KM, post #264
Zamiast MMX trzeba było wrzuciś DSP Motoroli, który był na kartach dźwiękowych i popędzić go ile się da.To jest znacznie mniej wydajne i bardziej skomplikowane rozwiązanie. Zauważ, że nie zrobiła tego ani Freescale z architekturą PowerPC (a mieli swoje DSP), ani Intel z architekturą x86 oraz x86_64 (a mieli swoje DSP), ani ARM. We wszystkich najpopularniejszych platformach CPU dodano instrukcje SIMD (AltiVec, MMX, SSE, Neon), zamiast integrować jakieś procesory DSP.
czyli sama AGA plus coś do akceleracji 3DTa jasne. Niech jednostka 3D rysuje to samo na kilku bitplanach i jeszcze może niech paletę do cieniowania dobiera... Moim zdaniem dodawanie jednostki 3D do wiernej implementacji AGA (bez trybu przynajmniej HighColor czyli 16 bitów na piksel i chunky oczywiście) mija się z celem. Zdecydowanie bardziej z sensem byłaby prosta karta graficzna np. tylko z trybem 24-bit RGB, ale na tyle prosta, żeby ewentualni koderzy mogli ją też programować na poziomie rejestrów, a nie tylko poprzez system RTG i wtedy do niej można dodać prostą jednostkę 3D (którą później można rozbudowywać).
A teraz walcie rybą.Mi się nie chce, aczkolwiek jesteś wzorcowym przykładem powiedzonka „nie znam się, więc się wypowiem”. W dodatku od lat i nic się nie poprawiasz...
23.06.2018 19:19
[#273]
Re: CD32-AKIKO
@Krashan, post #272
Grzegorz nie wrzuciła, bo jak zauważyłes była stara, a oni chcieli rywalizować PPC z Intelem x86, więc na dobrą sprawę porzucili M68k (nie ma się co oszukiwać, że PPC było rozwinięciem M68k, bo nie było. Wzięli inżynierów, ich wiedzę, pomysły i zrobili nowy procesor PPC zupełnie niekompatybilny z M68k.) My z kolei chcemy mieć jak największą wierność oryginały, więc DSP Motoroli dostępne na kartach dźwiękowych i w Falconie jest jak najbardziej moim zdaniem na miejscu. Jeszcze raz podkreślę, nie mówię, że mieli zrobić jeden procesor z rozkazami 68k i DSP, wyobraźmy sobie kawałek krzemu a w nim mamy 2 osobne procesory 68K i DSP. Jakoś muszą się komunikować i to wszystko, ale ich samych nie tykamy, jedyne co możemy dodać jak się uprzemy to Ohypatchera, bo podobno miał jakieś rozkazy, pominięte w 68060, przydatne Amigowcom. A tak Apollo 68080 ma być "nowym PPC", bo to nie podbiło świata? Zresztą niech sobie robią co chcą. 
Ostatecznie zniechęciłeś mnie do Vampira.
Ostatnia aktualizacja: 23.06.2018 19:21:26 przez KM
Ostatecznie zniechęciłeś mnie do Vampira.
Ostatnia aktualizacja: 23.06.2018 19:21:26 przez KM
23.06.2018 21:19
[#274]
Re: CD32-AKIKO
@UJP, post #271
Do tego jeszcze trzeba by zapłacić karę za naruszenie praw patentowych przez CD32 ( nie pamiętam o co chodziło, ale nie można było jej sprzedawać w USA ).
Generalnie ja chciałem zrobić wszystko identycznie jak to było w oryginale, te same kości, ta sama płyta główna, stąd zawyżyłem ceny.
Ale to wiadomo, że ciężej byłoby znaleźć inwestora na to. Prędzej już byłoby realne to co pan mówi, ale ten pomysł też mi się nie podoba do końca bo byłoby to coś w połowie Amigą, w połowie Vampire.
Generalnie ja chciałem zrobić wszystko identycznie jak to było w oryginale, te same kości, ta sama płyta główna, stąd zawyżyłem ceny.
Ale to wiadomo, że ciężej byłoby znaleźć inwestora na to. Prędzej już byłoby realne to co pan mówi, ale ten pomysł też mi się nie podoba do końca bo byłoby to coś w połowie Amigą, w połowie Vampire.
24.06.2018 01:58
[#275]
Re: CD32-AKIKO
@KM, post #273
M68K porzucili bo to CISC a wtedy badania prowadzone od lat 70` potwierdziły że 95% używanych w oprogramowaniu rozkazów to proste instrukcja jak wywołania podprogramów, instrukcje obsługujące pętle, przypisania, instrukcje warunkowe które można wykonać w 1-3 takty zegara , a tylko 1-3 % to skomplikowane rozkazy charakterystyczne dla CISC które CPU zajmują wiele taktów zegara ( trzeba przełączyć wiele bramek ) i niepotrzebnie komplikują konstrukcję CPU ( przez co ciężko było osiągnąć większe zegary, typowe CISC miały zegary do 100MHz, a RISC szybko dobiły do 4000 MHz ), poza tym prosta konstrukcja pozwoliła umieścić w jednym chipie wiele jednostek CPU ( dziś konsumenckie procki mają 2 do 6 rdzeni, a serwerowe nawet 40, nie wspominając o GPU które są praktycznie procesorami a mają już kilka tysięcy rdzeni ).
Uboga lista rozkazów, wielość rejestrów i w końcu wieloprocesorowość bardzo utrudniły programowanie na niskim poziomie, na RISC nie jest praktycznie możliwe napisanie większego programu w asemblerze, nikt zdrowy na umyśle tego nie ogarnie, ale to nie problem, bo programuje się w językach wysokiego poziomu a kompilatory lepiej lub gorzej wszytko ogarną.
Myślę że programistów może ciągnąć do MC68k bo ten CPU to jeden z ostatnich "pełnokrwistych" CISC, pozwala stosunkowo łatwo programować w asemblerze, a dobry programista może uzyskać dużo lepsze wyniki wydajności kodu po uwzględnieniu zegara taktowania niż w RISC jak PPC, no i " obcuje z żywym sprzętem" a nie na "xx warstwie abstrakcji" jak pod dzisiejszymi systemami.
Dzisiejsze procki CISC jak x86 to naprawdę RISC, a bardziej skomplikowane rozkazy wykonywane są w formie mikrokodu ( pewnie i 68080 tak jest zrobiony ), ale z poziomu programisty pozostają CISC
Twórcy Vampire moim zdaniem nie chcą odtworzyć tego co było w latach 90` a zrobić to co mogło powstać później, w 21 wieku uwzględniając nowe technologie, zachowując jednocześnie kompatybilność wsteczną, nowy model Amigi
Podoba mi się ta idea bardziej niż Amiga NG na PPC i na pewno kupię V4 standalone jak będzie dostępny ( a tym bardziej gdy powstanie wersja ASIC) , ale już nie bardzo pasuje mi wciskanie nowego FPGA do oryginalnego sprzętu z epoki jak A600, który w końcu ogranicza A600 do funkcji zasilacza, klawiatury i obudowy.
Miałem V2 do A600 ale sprzedałem go i kupiłem za podobne pieniądze Apollo 1260 do A1200, może ma mniejsze możliwości ale mam świadomość że mam oryginalny sprzęt z epoki,najwyższy jaki był dostępny.
Jak za bardzo p.... to sorry, właśnie skończyłem 1L "wysoko oktanowego" płynu z kumplem i nie do końca mogę odpowiadać za swoje słowa
Uboga lista rozkazów, wielość rejestrów i w końcu wieloprocesorowość bardzo utrudniły programowanie na niskim poziomie, na RISC nie jest praktycznie możliwe napisanie większego programu w asemblerze, nikt zdrowy na umyśle tego nie ogarnie, ale to nie problem, bo programuje się w językach wysokiego poziomu a kompilatory lepiej lub gorzej wszytko ogarną.
Myślę że programistów może ciągnąć do MC68k bo ten CPU to jeden z ostatnich "pełnokrwistych" CISC, pozwala stosunkowo łatwo programować w asemblerze, a dobry programista może uzyskać dużo lepsze wyniki wydajności kodu po uwzględnieniu zegara taktowania niż w RISC jak PPC, no i " obcuje z żywym sprzętem" a nie na "xx warstwie abstrakcji" jak pod dzisiejszymi systemami.
Dzisiejsze procki CISC jak x86 to naprawdę RISC, a bardziej skomplikowane rozkazy wykonywane są w formie mikrokodu ( pewnie i 68080 tak jest zrobiony ), ale z poziomu programisty pozostają CISC
Twórcy Vampire moim zdaniem nie chcą odtworzyć tego co było w latach 90` a zrobić to co mogło powstać później, w 21 wieku uwzględniając nowe technologie, zachowując jednocześnie kompatybilność wsteczną, nowy model Amigi
Podoba mi się ta idea bardziej niż Amiga NG na PPC i na pewno kupię V4 standalone jak będzie dostępny ( a tym bardziej gdy powstanie wersja ASIC) , ale już nie bardzo pasuje mi wciskanie nowego FPGA do oryginalnego sprzętu z epoki jak A600, który w końcu ogranicza A600 do funkcji zasilacza, klawiatury i obudowy.
Miałem V2 do A600 ale sprzedałem go i kupiłem za podobne pieniądze Apollo 1260 do A1200, może ma mniejsze możliwości ale mam świadomość że mam oryginalny sprzęt z epoki,najwyższy jaki był dostępny.
Jak za bardzo p.... to sorry, właśnie skończyłem 1L "wysoko oktanowego" płynu z kumplem i nie do końca mogę odpowiadać za swoje słowa
24.06.2018 11:04
[#276]
Re: CD32-AKIKO
@UJP, post #275
Dzięki za informację, tych nigdy za wiele, czyli co Apollo chce zrobić Twoim zdaniem Risca na bazie M68k? A czy przypadkiem Motorola też nie próbowała i ostatecznie porzuciła, bo nie opłacało się, miała za mało mocy przerobowych, czy co tam? Bazuję na internecie, wikipediach itd. Nie wiem, czy wolno się zapytać wyrazić własne zdanie jak nie ma się studiów na kierunku technicznym skończonych.
24.06.2018 21:59
[#278]
Re: CD32-AKIKO
@UJP, post #275
Uboga lista rozkazów, wielość rejestrów i w końcu wieloprocesorowość bardzo utrudniły programowanie na niskim poziomie, na RISC nie jest praktycznie możliwe napisanie większego programu w asemblerze,
na PPC mozna bez stresu pisac niskopoziomowy software w czystym assemblerze, to wcale nie jest takie trudne, ale...
nikt zdrowy na umyśle tego nie ogarnie, ale to nie problem, bo programuje się w językach wysokiego poziomu a kompilatory lepiej lub gorzej wszytko ogarną.
Nikt zdrowy na umysle tego nie robi bo to strata cennego czasu. Po co programowac w assemblerze i przyklejac sie na sztywno do jednej architektury albo jednego procesora, skoro mozna pisac wygodniej i wieloplatformowo w jezykach wyzszego poziomu?
Napiszesz super wydajny program np. na 68040, a potem okaze sie ze na 68060 bez oxypatchera albo innych cudow na kiju nie dziala juz tak superwydajnie, bo sie troche oba procki jednak miedzy soba roznia. Albo napiszesz super kod na ppc603 ktory bedzie marnie chodzil na ppc750 bo sie znowu lekko architektura cpu zmienila.
Napiszesz to samo w jezyku wyzszego poziomu, chocby i w C i zmienisz docelowy CPU za pomoca jednego parametru przy wywolywaniu kompilatora.
Myślę że programistów może ciągnąć do MC68k bo ten CPU to jeden z ostatnich "pełnokrwistych" CISC, pozwala stosunkowo łatwo programować w asemblerze,
programistow do assemblera juz raczej nie ciagnie (chyba ze z sentymentu) bo i po co? Tak samo jak juz raczej nie znajdziesz ludzi z pasja dziurkujacych swoje oprogramowanie na kartach. Owszem, jest drobna garstka nostalgikow piszacych niskopoziomowo na atari2600, nes-a czy inne zabytki, ale to tylko margines.
a dobry programista może uzyskać dużo lepsze wyniki wydajności kodu po uwzględnieniu zegara taktowania niż w RISC jak PPC
z obecnymi kompilatorami dosc trudno juz wygrac. Owszem, zdaza sie, ale coraz rzadziej. Tym bardziej ze nowoczesne CPU potrafia twoj piekny kod zrobic dosc brzydkim chociazby przez potrzebe lekkiego przemieszania kodu (odejscia od kolejnosci wykonywania rozkazow wynikajacej z logiki programu)
no i " obcuje z żywym sprzętem" a nie na "xx warstwie abstrakcji" jak pod dzisiejszymi systemami.
Tym sie prawie nikt nie przejmuje, chyba ze programujesz mikrokontrolery i optymalizujesz kod tak, zeby sie zmiescic np. w 1kb Flash i 128b RAM.
Dzisiejsze procki CISC jak x86 to naprawdę RISC, a bardziej skomplikowane rozkazy wykonywane są w formie mikrokodu ( pewnie i 68080 tak jest zrobiony ), ale z poziomu programisty pozostają CISC
wiec dlaczego tak malo osob programuje w assemblerze skoro kodowanie pod CISC takie fajne?
Jak za bardzo p.... to sorry, właśnie skończyłem 1L "wysoko oktanowego" płynu z kumplem i nie do końca mogę odpowiadać za swoje słowa
Piles? Nie programuj. Programujesz? Nie pij. Potem sie czlowiek na trzezwo zastanawia co spieprzyl albo jak naprawil cos co nie dzialalo...
25.06.2018 15:21
[#282]
Re: CD32-AKIKO
@Krashan, post #272
Wprawdzie to nie "platforma CPU", a SOC -> ale Qualcomm od 12 lat dorzuca DSP ("Hexagon") do Snapdragonów. O ile pamiętam Samsung w Exynosie 4412 (ten od Galaxy S3) też DSP na pokładzie miał - i z tego co na szybko znalazłem teraz, nowe Exynosy DSP też mają (Ceva się do nich przyznaje; wydaje się że o ile do jednego core'a Hexagone da się dostać - tego od multimediów - to DSP w Exynosach jest zamknięte - tylko pod modem). Jakby poszukać - TI ma Keystone, pewnie by się jeszcze coś więcej znalazło.
Choć rzeczywiście, trochę inny target ;)
A tak off topic... NXP (zanim Qualcomm ich capnął) się już częściowo pozbyło balastu w postaci ColdFire i e200(PPC). Sprzedażą i supportem IP core zajmuje się firma zewnętrzna.
Choć rzeczywiście, trochę inny target ;)
A tak off topic... NXP (zanim Qualcomm ich capnął) się już częściowo pozbyło balastu w postaci ColdFire i e200(PPC). Sprzedażą i supportem IP core zajmuje się firma zewnętrzna.
25.06.2018 16:18
[#283]
Re: CD32-AKIKO
@mschulz, post #278
Napiszesz to samo w jezyku wyzszego poziomu, chocby i w C i zmienisz docelowy CPU za pomoca jednego parametru przy wywolywaniu kompilatora.
Z mojego punktu widzenia OK, można 99% programu napisać w C bez większej straty wydajności. Ale niektóre rzeczy po prostu warto napisać explicite w asm 68k, bo po prostu tak jest lepiej i możesz w ten sposób osiągnąć dokładnie to, co chcesz.
Jak ja obserwuję, jak ludzie walczą i dochodzą, by im GCC tryb adresowania (An)+, -(An), (x,PC), (x,PC,Xn) lub (x,An,Xn) osiągnął, to myślę - po co kombinować?
Warstwa C jako języka wyższego poziomu z reguły ucina możliwość ingerencji w kod np. korzystania ze znaczników procesora. Manipulacje rejestrami też nie zawsze są optymalne, jak piszesz jakieś bardziej złożone wyrażenie.
Jest coś takiego jak "register" w C, mało używany (no bo zazwyczaj wszystkie zmienne lokalne na początku wchodzą do rejestrów, a później do ramki stosu). A to błąd - ten modyfikator daje możliwość explicite określenie, które zmienne chcemy by były na 100% w rejestrze.
Wiele poleceń procesora jest zupełnie niewykorzystywane w odpowiedni sposób przez C.
Przykłady:
- SWAP pozwala trzymać więcej danych w rejestrach i mieć wrażenie jakbyś miał 16 rejestrów danych o rozmiarze słowa. Konia z rzędem temu jak ktoś jakoś sensownie osiągnie to w C (przesuwanie o 16 bitów to nie jest dokładnie ta operacja).
- ROL i ROR - pozwala rotować bity. Nie ma odpowiednika tego operatora w C.
- EXT - pozwala błyskawicznie rozszerzyć zakres liczby, np. z bajta w słowo.
- EXG - pozwala zamieniać rejestry miejscami, co - w pewnych przypadkach - może pozwolić na sprytne manipulacje oszczędzające czas procesora.
- DBcc - ta operacja zmniejsza o jeden rejestr danych i skacze przy spełnieniu warunku.
- Scc - ta operacja ustawia rejestr przy spełnieniu warunku.
- DIVS i DIVU - pozwala za jednym zamachem uzyskać wynik i resztę z dzielenia w jednym rejestrze.
- MOVEQ - pozwala szybko umieścić wartość -128.. 127 w całym rejestrze danych.
Poza tym asm przydaje się w:
- kodzie przerwań,
- kodzie, który powinien być wykonywany jak najszybciej, np. kod startowy,
- kodzie, gdzie liczy się kolejność i położenie elementów (biblioteki współdzielone, device itp.).
Także C jest w porządku, ale czasem warto zaprzęgnąć do pracy asembler i jawnie sprecyzować swoje zamiary.
Asembler moim zdaniem powinien być używany przede wszystkim przez funkcje niskiego poziomu na Amidze.
A na tym można budować procedury wyższego poziomu.Ostatnia aktualizacja: 25.06.2018 16:30:57 przez Hexmage960
25.06.2018 17:10
[#285]
Re: CD32-AKIKO
@Hexmage960, post #283
Widać, że nie zdarzyło Ci się disasemblować kodu M68k wygenerowanego przez dobry kompilator. GCC potrafi się posłużyć prawie wszystkimi wymienionymi instrukcjami. Trochę problemów jest jedynie z DIV i MUL (tymi z 68000), ponieważ w C obowiązuje zasada promocji typu, która powoduje, że operandy działania muszą mieć ten sam typ co wynik. Więc jeżeli wynik jest 32-bitowy, to operandy 16-bitowe zostaną rozszerzone, a potem kompilator wywoła funkcję biblioteczną. Ten problem nie występuje w 68020.
Moim optimum, szczególnie przy pisaniu „pod system” jest pisanie w C z użyciem wstawek asemblerowych w newralgicznych miejscach.
Moim optimum, szczególnie przy pisaniu „pod system” jest pisanie w C z użyciem wstawek asemblerowych w newralgicznych miejscach.
25.06.2018 21:57
[#286]
Re: CD32-AKIKO
@Krashan, post #285
W porządku, mogą te instrukcje się pojawiać w tym kompilatorze. Widziałem instrukcję SWAP przy przesuwaniu o 16 bitów i rzeczywiście instrukcja ta przyśpiesza to, ale nadal C nie ma interfejsu na tę instrukcję, chyba że przetłumaczy kod:
Tak samo rotacja. Kompilator musiałby przetłumaczyć:
Nie jest to jednak takie oczywiste ani naturalne i kompilator musiałby mieć bardzo mocno rozbudowany mechanizm badania związku między sąsiednimi operacjami.
Z kolei taki EXT rzeczywiście można by uzyskać w ten sposób:
Kompilator pracuje jednak szablonowo, i pewnych intencji programisty nie przewidzi.
Ciekaw jestem, czy taką przykładową procedurę uzyskałoby się w GCC i czy byłoby dużo z tym gimnastyki.
Jest to fragment programu. Pętla otwierająca biblioteki z obsługą błędów.
ULONG x; x = (x << 16) | (x >> 16);na
SWAP D0
Tak samo rotacja. Kompilator musiałby przetłumaczyć:
ULONG x; x = (x << 4) | (x >> 28);na
ROL.L #4,D0
Nie jest to jednak takie oczywiste ani naturalne i kompilator musiałby mieć bardzo mocno rozbudowany mechanizm badania związku między sąsiednimi operacjami.
Z kolei taki EXT rzeczywiście można by uzyskać w ten sposób:
WORD x = 3; LONG y = 2000000 + x;
MOVE.W #3,D0 MOVE.L #2000000,D1 EXT.L D0 ADD.L D0,D1
Kompilator pracuje jednak szablonowo, i pewnych intencji programisty nie przewidzi.
Ciekaw jestem, czy taką przykładową procedurę uzyskałoby się w GCC i czy byłoby dużo z tym gimnastyki.
Jest to fragment programu. Pętla otwierająca biblioteki z obsługą błędów.OpenLibs: LEA (libdata,PC),A2 LEA (libbase,PC),A3 MOVEA.L (4).w,A6 MOVEQ #LIBS-1,D2 .Loop: MOVEQ #KICK,D0 MOVEA.L (A2)+,A1 JSR (_LVOOpenLibrary,A6) MOVE.L D0,(A3)+ DBEQ D2,.Loop BEQ.S .Error ; ... libdata: DC.L dosname, intname, gtname, gfxname libbase: DS.L LIBS dosname: DC.B 'dos.library',0 intname: DC.B 'intuition.library',0 gtname: DC.B 'gadtools.library',0 gfxname: DC.B 'graphics.library',0
25.06.2018 22:10
[#287]
Re: CD32-AKIKO
@Hexmage960, post #286
Jestem prawie że pewien że GCC domyśli się z tymi shiftami że ma zrobić EXTa.
Z rotacją problem jest szeroko opisany i jest też sprawdzona metoda na zapisanie takiej operacji żeby GCC się domyślił. Na Amidze jeszcze nie sprawdzałem bo rotacji nie potrzebowałem, ale stawiam w ciemno że zadziała.
Moją definicją postępu jest używanie nowych narzędzi do coraz lepszego rozwiązywania starych problemów. Jeśli nowe narzędzia na to nie pozwalają, to stoimy w miejscu. C/C++ są na tyle nisko, by potencjalnie móc przełożyć wszystkie intencje programisty na język asemblerowy - jeśli nie w standardzie to w oparciu o rozszerzenia specyficzne dla platformy. Są na tym świecie ludzie, którzy siedzą i rozwijają tego typu narzędzia i chwała im za to. Wolę jednak męczyć się z C i przykładać rękę do rozwoju wskazując narzędziotwórcom miejsca do poprawki, niż męczyć się z asemblerem tylko dla danej platformy. Ktoś mi może zarzucić że to mało amigowe podejście ale widać różnych rzeczy różni ludzie szukają w tym hobby.
Z rotacją problem jest szeroko opisany i jest też sprawdzona metoda na zapisanie takiej operacji żeby GCC się domyślił. Na Amidze jeszcze nie sprawdzałem bo rotacji nie potrzebowałem, ale stawiam w ciemno że zadziała.
Moją definicją postępu jest używanie nowych narzędzi do coraz lepszego rozwiązywania starych problemów. Jeśli nowe narzędzia na to nie pozwalają, to stoimy w miejscu. C/C++ są na tyle nisko, by potencjalnie móc przełożyć wszystkie intencje programisty na język asemblerowy - jeśli nie w standardzie to w oparciu o rozszerzenia specyficzne dla platformy. Są na tym świecie ludzie, którzy siedzą i rozwijają tego typu narzędzia i chwała im za to. Wolę jednak męczyć się z C i przykładać rękę do rozwoju wskazując narzędziotwórcom miejsca do poprawki, niż męczyć się z asemblerem tylko dla danej platformy. Ktoś mi może zarzucić że to mało amigowe podejście ale widać różnych rzeczy różni ludzie szukają w tym hobby.
25.06.2018 22:42
[#288]
Re: CD32-AKIKO
@Hexmage960, post #283
Krashan na wiekszosc twojego posta juz odpowiedzial, ja dodam od siebie tylko tyle: zapoznaj sie z kompilatorami lepszymi niz gcc 2.95 czy tez vbcc. Zapewniam ze mozesz sie dosc pozytywnie zdziwic.
Tak, to praktycznie jedyne miejsce gdzie assembler sie przydaje. Moze nie w 100%. Czasami wygodnie napisac prolog handlera przerwania w assemblerze a reszte napisac w C. Tak robilem chociazby w AROS-ie.
Bez sensu. Kod startowy nie musi byc wykonywany jak najszybciej, bo jest uruchamiany tylko jeden jedyny raz w momencie startu programu. Duzo wazniejsza jest optymalizacja tych fragmentow programu ktore sa wykonywane najczesciej
w bibliotekach wspoldzielonych, device i tym podobnych tylko jedna rzecz ma stale miejsce, pierwsze 6 bajtow:
kolejnosc umieszczenia reszty kodu w bibliotece czy w device nie ma najmniejszego znaczenia. To struktura Resident jest punktem zaczepienia i to ona (plus np. tablica wektorow) mowi systemowi co gdzie jest umieszczone. A te smetne 6 bajtow kodu startowego da sie zalatwic prostym skryptem dla programu konsolidujacego. I juz masz gotowa biblioteke napisana w czystym C...
Assembler powinien byc stosowany tylko i wylacznie tam, gdzie jest to absolutnie konieczne. Kropka.
Ostatnia aktualizacja: 25.06.2018 22:43:44 przez mschulz
Poza tym asm przydaje się w:
- kodzie przerwań,
Tak, to praktycznie jedyne miejsce gdzie assembler sie przydaje. Moze nie w 100%. Czasami wygodnie napisac prolog handlera przerwania w assemblerze a reszte napisac w C. Tak robilem chociazby w AROS-ie.
- kodzie, który powinien być wykonywany jak najszybciej, np. kod startowy,
Bez sensu. Kod startowy nie musi byc wykonywany jak najszybciej, bo jest uruchamiany tylko jeden jedyny raz w momencie startu programu. Duzo wazniejsza jest optymalizacja tych fragmentow programu ktore sa wykonywane najczesciej
- kodzie, gdzie liczy się kolejność i położenie elementów (biblioteki współdzielone, device itp.).
w bibliotekach wspoldzielonych, device i tym podobnych tylko jedna rzecz ma stale miejsce, pierwsze 6 bajtow:
moveq #-1, d0
rtskolejnosc umieszczenia reszty kodu w bibliotece czy w device nie ma najmniejszego znaczenia. To struktura Resident jest punktem zaczepienia i to ona (plus np. tablica wektorow) mowi systemowi co gdzie jest umieszczone. A te smetne 6 bajtow kodu startowego da sie zalatwic prostym skryptem dla programu konsolidujacego. I juz masz gotowa biblioteke napisana w czystym C...
Asembler moim zdaniem powinien być używany przede wszystkim przez funkcje niskiego poziomu na Amidze.
Assembler powinien byc stosowany tylko i wylacznie tam, gdzie jest to absolutnie konieczne. Kropka.
Ostatnia aktualizacja: 25.06.2018 22:43:44 przez mschulz
26.06.2018 08:26
[#289]
Re: CD32-AKIKO
@mschulz, post #288
@MSchulz
Kod startowy piszą w asemblerze by głównie zaoszczędzić te kilkaset bajtów. Poza tym program DOS na Amidze po uruchomieniu otrzymuje bufor tekstowy w A0 oraz rozmiar tego bufora w D0. Trzeba to obsłużyć i przygotować listę parametrów dla main(). Najwygodniej zrobić to w asm.
I znowu, oszczędność. Poza tym w asemblerze można ulokować elementy tak jak się chce, by występowały w kodzie wynikowym. W C można rezerwować różne tablice w przestrzeni globalnej, ale standard tego języka nie daje gwarancji, że będą one obok siebie. Asembler taką gwarancję daje. Struktura ROMTag musi zaczynać się od "magicznej liczby", która jest wyszukiwana w kodzie biblioteki. Reszta rzeczy jest z nią połączona.
Tak jak pisałem, asembler daje pełną kontrolę i możliwość stosowania typowych dla niego konstrukcji. Stosuje się go tam, gdzie chce się zaoszczędzić czas procesora i miejsce w pamięci.
Programy skompilowane pod GCC mają tendencję szybko zwiększać swój rozmiar. Dlaczego tak się dzieje? Czy GCC nie może optymalizować rozmiaru swojego kodu?
@Teh_KaiN
W przypadku Amigi 68k naturalną rzeczą jest stosowanie asemblera tam, gdzie to jest po prostu tego warte. Być może GCC dla nowoczesnych platform jest na tyle rozbudowany, że potrafi wiele rzeczy zoptymalizować, co starsze kompilatory nie potrafią. Nie dziwne, działa na procesorach ~1GHz.
Moim zdaniem zamiast wymyślać takie funkcje inline do swojego programu, które nie zawsze dają gwarancję pomyślności tłumaczenia, zapisać funkcję w asemblerze. Ma to kolosalne znaczenie dla procesorów 68k o typowej dla nich wydajności.
Moim zdaniem naprawdę warto się z asemblerem choć oswoić i używać jako narzędzia do osiągnięcia specyficznych dla architektury zadań. Wiem, że przez użycie wstawki traci się przenośność kodu. Ale należy zapamiętać, że uniwersalność ponosi za sobą jednak pewne konsekwencje, głównie w szybkości kodu. Często tylko wyspecjalizowany kod może być wystarczająco szybki.
Kod startowy nie musi byc wykonywany jak najszybciej, bo jest uruchamiany tylko jeden jedyny raz w momencie startu programu. Duzo wazniejsza jest optymalizacja tych fragmentow programu ktore sa wykonywane najczesciej
Kod startowy piszą w asemblerze by głównie zaoszczędzić te kilkaset bajtów. Poza tym program DOS na Amidze po uruchomieniu otrzymuje bufor tekstowy w A0 oraz rozmiar tego bufora w D0. Trzeba to obsłużyć i przygotować listę parametrów dla main(). Najwygodniej zrobić to w asm.
kolejnosc umieszczenia reszty kodu w bibliotece czy w device nie ma najmniejszego znaczenia. To struktura Resident jest punktem zaczepienia i to ona (plus np. tablica wektorow) mowi systemowi co gdzie jest umieszczone. A te smetne 6 bajtow kodu startowego da sie zalatwic prostym skryptem dla programu konsolidujacego. I juz masz gotowa biblioteke napisana w czystym C...
I znowu, oszczędność. Poza tym w asemblerze można ulokować elementy tak jak się chce, by występowały w kodzie wynikowym. W C można rezerwować różne tablice w przestrzeni globalnej, ale standard tego języka nie daje gwarancji, że będą one obok siebie. Asembler taką gwarancję daje. Struktura ROMTag musi zaczynać się od "magicznej liczby", która jest wyszukiwana w kodzie biblioteki. Reszta rzeczy jest z nią połączona.
Tak jak pisałem, asembler daje pełną kontrolę i możliwość stosowania typowych dla niego konstrukcji. Stosuje się go tam, gdzie chce się zaoszczędzić czas procesora i miejsce w pamięci.
Programy skompilowane pod GCC mają tendencję szybko zwiększać swój rozmiar. Dlaczego tak się dzieje? Czy GCC nie może optymalizować rozmiaru swojego kodu?
@Teh_KaiN
Jestem prawie że pewien że GCC domyśli się z tymi shiftami że ma zrobić EXTa.
Z rotacją problem jest szeroko opisany i jest też sprawdzona metoda na zapisanie takiej operacji żeby GCC się domyślił. Na Amidze jeszcze nie sprawdzałem bo rotacji nie potrzebowałem, ale stawiam w ciemno że zadziała.
Moją definicją postępu jest używanie nowych narzędzi do coraz lepszego rozwiązywania starych problemów. Jeśli nowe narzędzia na to nie pozwalają, to stoimy w miejscu. C/C++ są na tyle nisko, by potencjalnie móc przełożyć wszystkie intencje programisty na język asemblerowy - jeśli nie w standardzie to w oparciu o rozszerzenia specyficzne dla platformy. Są na tym świecie ludzie, którzy siedzą i rozwijają tego typu narzędzia i chwała im za to. Wolę jednak męczyć się z C i przykładać rękę do rozwoju wskazując narzędziotwórcom miejsca do poprawki, niż męczyć się z asemblerem tylko dla danej platformy. Ktoś mi może zarzucić że to mało amigowe podejście ale widać różnych rzeczy różni ludzie szukają w tym hobby.
W przypadku Amigi 68k naturalną rzeczą jest stosowanie asemblera tam, gdzie to jest po prostu tego warte. Być może GCC dla nowoczesnych platform jest na tyle rozbudowany, że potrafi wiele rzeczy zoptymalizować, co starsze kompilatory nie potrafią. Nie dziwne, działa na procesorach ~1GHz.
Moim zdaniem zamiast wymyślać takie funkcje inline do swojego programu, które nie zawsze dają gwarancję pomyślności tłumaczenia, zapisać funkcję w asemblerze. Ma to kolosalne znaczenie dla procesorów 68k o typowej dla nich wydajności.
static inline uint32_t rotr32 (uint32_t n, unsigned int c)
{
const unsigned int mask = (CHAR_BIT*sizeof(n) - 1);
// assert ( (c<=mask) &&"rotate by type width or more");
c &= mask;
return (n>>c) | (n<<( (-c)&mask ));
}Moim zdaniem naprawdę warto się z asemblerem choć oswoić i używać jako narzędzia do osiągnięcia specyficznych dla architektury zadań. Wiem, że przez użycie wstawki traci się przenośność kodu. Ale należy zapamiętać, że uniwersalność ponosi za sobą jednak pewne konsekwencje, głównie w szybkości kodu. Często tylko wyspecjalizowany kod może być wystarczająco szybki.
26.06.2018 08:40
[#290]
Re: CD32-AKIKO
@Hexmage960, post #289
W C można rezerwować różne tablice w przestrzeni globalnej, ale standard tego języka nie daje gwarancji, że będą one obok siebie.
Do wymuszania konkretnej kolejnosci (o ile jest gdziekolwiek konieczna) stosuje sie skrypty programu konsolidujacego. Standard C kolejnosci nie gwarantuje bo nie musi (i prawie nigdy nie jest to konieczne).
Struktura ROMTag musi zaczynać się od "magicznej liczby", która jest wyszukiwana w kodzie biblioteki. Reszta rzeczy jest z nią połączona.
Wiem, i sam tez to napisalem. To ma byc argument na rzecz asemblera? bo przyznaje, nie zrozumialem o co ci z tym zdaniem chodzi.
26.06.2018 08:53
[#291]
Re: CD32-AKIKO
@Hexmage960, post #289
Jak już Mschulz powiedział, korzystając z linker scriptów możesz dokładnie panować nad tym które symbole gdzie zostaną ulokowane, w jakiej kolejności, z jakim wyrównaniem bajtów a nawet jakimi wartościami zostaną wypełnione bajty pomiędzy kolejnymi symbolami. GCC to nie tylko C, ale też linker który ma bardzo potężne opcje, o których mało kto wie.
W amigowym GCC, czy to starutkim 2.95 czy wariancie od Bebbo, w VBCC zresztą też, jesteś w stanie ulokować jawnie dany argument w rejestrze. Także możesz zrobić największą optymalizację jaką daje asembler, czyli skakać do kolejnych fragmentów kodu nie przekazując argumentów przez stos (stdcall) tylko przez rejestry (fastcall?). Ręczne pilnowanie zawartości rejestrów by wołać odpowiednio funkcje jest w moim mniemaniu upierdliwe, więc można to zostawić kompilatorowi. Optymalizacje na poziomie linkera (-lto) w połączeniu ze słówkiem regargs przy nagłówkach funkcji w amigowym GCC powinny to robić za Ciebie, a jeśli nie robią, to trzeba ten stan rzeczy zmienić.
W amigowym GCC, czy to starutkim 2.95 czy wariancie od Bebbo, w VBCC zresztą też, jesteś w stanie ulokować jawnie dany argument w rejestrze. Także możesz zrobić największą optymalizację jaką daje asembler, czyli skakać do kolejnych fragmentów kodu nie przekazując argumentów przez stos (stdcall) tylko przez rejestry (fastcall?). Ręczne pilnowanie zawartości rejestrów by wołać odpowiednio funkcje jest w moim mniemaniu upierdliwe, więc można to zostawić kompilatorowi. Optymalizacje na poziomie linkera (-lto) w połączeniu ze słówkiem regargs przy nagłówkach funkcji w amigowym GCC powinny to robić za Ciebie, a jeśli nie robią, to trzeba ten stan rzeczy zmienić.
26.06.2018 08:56
[#293]
Re: CD32-AKIKO
@Hexmage960, post #292
Tak, asembler wygeneruje tę liczbę (oraz wszystko pozostałe) w dowolnie wybranym miejscu kodu.
A w C wypelnisz strukture Resident (razem z RTC_MATCHWORD) i kompilator ja umiesi tam gdzie chce (albo gdzie go poinstruujesz). Na to samo wychodzi, wiec argument totalnie nietrafiony.
26.06.2018 09:12
[#294]
Re: CD32-AKIKO
@teh_KaiN, post #291
Jeśli chcecie doświadczyć mocy asemblera, i skorzystać z dobrodziejstw automatyzacji generowania kodu polecam sprawdzić kompilator języka Amiga E. Jego szybkość jest ogromna. I ma sporo możliwości. Pozwala m.in. bezboleśnie wprowadzać te instrukcje ROL.L, czy DBEQ w pełnej harmonii z kodem języka E.
No, ale to tylko jak ktoś chce pisać kod dedykowany dla Amigi.
Kompilator i linker GCC ma na pewno mnóstwo interesujących opcji. Ale ja powtarzam, żeby kod asm stosować tam, gdzie nie chcemy osiągać czegoś przez zawiłe opcje, albo wyszukane konstrukcje inline, ale jawnie napisać instrukcje, które nas interesują.
Na pewno budowanie bibliotek i tego typu rzeczy można zautomatyzować pisząc .. program w C, który tworzy plik binarny.
Ostatnia aktualizacja: 26.06.2018 09:13:29 przez Hexmage960
No, ale to tylko jak ktoś chce pisać kod dedykowany dla Amigi.
Kompilator i linker GCC ma na pewno mnóstwo interesujących opcji. Ale ja powtarzam, żeby kod asm stosować tam, gdzie nie chcemy osiągać czegoś przez zawiłe opcje, albo wyszukane konstrukcje inline, ale jawnie napisać instrukcje, które nas interesują.
Na pewno budowanie bibliotek i tego typu rzeczy można zautomatyzować pisząc .. program w C, który tworzy plik binarny.
Ostatnia aktualizacja: 26.06.2018 09:13:29 przez Hexmage960
26.06.2018 13:06
[#298]
Re: CD32-AKIKO
@AmmigaCDTV, post #295
Kurka wodna, ale wy macie wiedzę. Nie chcecie jej spożytkować na dorobienie obsługi Akiko dla innych gier 3D, które normalnie jej nie wykorzystują? Nie wiem, Alien Breed 3D i jeszcze jakieś inne.
na wiedzy się kończy przygoda...
Ostatnia aktualizacja: 26.06.2018 13:07:16 przez polutuje
26.06.2018 14:14
[#299]
Re: CD32-AKIKO
@polutuje, post #298
Niektórzy robią takie rzeczy. Trzeba trafić na osobę z wiedzą i mnóstwem wolnego czasu :D
Widziałem, że ktoś zrobił też Wolfenstein'a na CD32 wykorzystującego Akiko. Ale idea jaka przyświecała temu panu, to zrobienie Wolf'a na gołą CD32, przez to znacznie zmniejszył rozmiar okienka. Czy przerobienie wielkości okienka Wolf'a na większe dla CD32 z FAST RAM'em byłoby jakimś problemem? Tak jak patrzę jakiego kopa daje FAST RAM, to możnaby się nawet pokusić o okienko Full Screen dla CD32 + FAST.
Widziałem, że ktoś zrobił też Wolfenstein'a na CD32 wykorzystującego Akiko. Ale idea jaka przyświecała temu panu, to zrobienie Wolf'a na gołą CD32, przez to znacznie zmniejszył rozmiar okienka. Czy przerobienie wielkości okienka Wolf'a na większe dla CD32 z FAST RAM'em byłoby jakimś problemem? Tak jak patrzę jakiego kopa daje FAST RAM, to możnaby się nawet pokusić o okienko Full Screen dla CD32 + FAST.