Zenon/Dial: Nie wiem jak inni, ale ja muszę Cię rozczarować: nie zwykłem uczestniczyć w przepychankach.

hahaha.
mam mala propozycje na starcie. przejdzmy na ty...

mozesz podac przyklady kompilatorow robiacych gdzie "optymalizacje robi assembler"? mozesz podac przyklad "oddzielnego narzedzia optymalizujacego kod maszynowy"? moze podasz swoja definicje kodu maszynowego - ktory najwyrazniej mylisz z kodem mnemonicznym...

rzeczywiscie wyglada ze masz wyksztalcenie informatyczne (nie wiem, nie sprawdzalem) - czysto teoretyczne. ciekawi mnie rowniez, co rozumiesz przez "wyksztalcenie informatyczne" - ukierunkowanie na programowanie, na projektowanie oprogramowania, na przetwarzanie danych, na systemy skladowania danych, na transmisje danych, a moze na nauczanie informatyki w szkole :) ? kazde z tych zagadnien jest "informatycznym" - lezy w tym samym worku bardzo glupiego okreslenia "ynformatyk" - okreslenia nic nie mowiacego o tym czym sie zajmujesz, poza tym, ze ma to cos wspolnego z szeroko pojeta informatyka.

zenon: tez mi sie zaczyna podobac - prawie jak dyskusja niegdys z tdc :]

to "przejdzmy na ty" bylo swoistego rodzaju przenosnia - przegooglaj to forum (tak, uzywajac googli, a nie wbudowanej wyszukiwarki), a byc moze zrozumiesz o co w tym zwrocie chodzi ;)

co do optymalizacji - nie znam kompilatora ktory by "proces optymalizacji" przenosil na assembler - jesli jest ten kompilator na tyle prosty, ze sam tego nie wykonuje - przekazuje to do odrebnego programu bedacego zazwyczaj bardzo prostym i bardzo ograniczonym optymalizerem. zazwyczaj - ale nie zawsze.

zachowales sie poprostu bardzo nieladnie proszac o przytoczenie przykladu assemblera optymalizujacego, po czym, na zart osoby o duzej wiedzy praktycznej w tej kwestii, jak i cieszacej sie tu sporym zasluzonym szacunkiem - zarzuciles mu brak wiedzy (ktory sam prezentujesz).
btw. x86 i "optymalizacja kodu skokow" to calkiem odrebne zagadnienie ;)

tebe: inna mozliwosc optymalizacji skokow - wyszukiwanie ewentualnego pewnego warunku, po czym zastepowanie jmp skokiem warunkowym (przy tym spelnionym warunku), jesli ten skok ma sie odbywac w obrebie zasiegu skoku warunkowego. inna sprawa ze w/g mnie taka optymalizacja powinna sie odbywac nie automatycznie, a conajwyzej tego typu propozycja mogla by byc programiscie sugerowana...

ok.

Niech będzie. Większość sytuacji optymalizacji kodu assemblera działa na poziomie odrębnego programu pracującego z listingiem, a nie assemblera.

Przykład z as86 w nasm wygląda następująco:

 -O number
     optimize branch offsets (-O0 disables, default).

optimize po polsku to optymalizacja

Naprawdę śmieszą mnie teksty assembler musi zachowywać się tak jak programista tego oczekuje w odniesieniu do mojego pytania o optymalizację podprocedur chociażby dlatego, że tego -O dla assemblera z zaświatów nikt nie ześle, a po to są dyrektywy assemblera decydujące jak ma tworzyć kod żeby wręcz do konkretnych procedur można było takie "optymalizacje" odnosić.

Doświadczenie tu obecnych jest dosyć specyficzne i nie mam zamiaru go negować. Mimo wszystko nie rozmawiamy jednak tutaj o ilości cykli dla DLI interrupt tylko o dosyć zaawansowanym i teoretycznie silnie w wielu miejscach opracowanym temacie jakim jest OS i mechanizmy, które dobry OS powinien wspierać i realizować. Rozmawiamy o praktycznych możliwościach realizacyjnych takiego "nowoczesnego" OS dla Atari w sposób, który pozwoli go wykorzystać praktycznie, a nie jako pokaz, że niby na 8bit się da. Win XP na Pentium I pewnikiem też się da uruchomić ;-) (akurat tego nie sprawdzałem).

Wiele "optymalizacji" może być przerzuconych na assembler (np. wyrównywanie bajtów dla silniejszych procesorów). W sztuczkach z atariki widziałem np. nop 2 bajtowy, którego wstawianie można przerzucić na assembler w zależności od użytej opcji co uogólnia i upraszcza kod. Akurat ten przykład z nop 2 bajtowym do makra wrzucić można łatwo.
Moja propozycja z inline procedur tak prosta w przypadku modyfikowanego kodu w realizacji nie jest i nie widze przeciwskazań zrobienie jej jako automatycznie realizowalnej przez assembler.

Sens jest podwójny takiego assemblera. Mógłby np. tworzyć przenośny kod pomiędzy różnymi wersjami 6502, a nawet nie wszystkie Atarki mają owego 2 bajtowego "NOP-a" (dokładniej 3 bajtowego, 2 bajty argumentu).

Co do optymalizacji na poziomie asemblera, to zwykły dwuprzebiegowy asembler będzie umiał optymalizowac backward references, np. skoki, bez większego trudu. Robi to np. asembler Hisoftu na ST zatytułowany GenST (oczywiście tylko na wyraźne życzenie programisty). Robi to też mój (dotąd nieopublikowany) asemblerek dla 65C816 (też na życzenie). Dla 6502 może byłoby np. optymalizować w ten sposób pseudorozkazy w rodzaju JEQ, tzn. jeśli zasięg skoku na to pozwala, podmieniać to na BEQ. O ile się nie mylę, dla takiej optymalizacji skoków w przód trzeba zrobić co najmniej trzeci przebieg.

Nie dziwne, bo to jest system JEDNOZADANIOWY, nie ma w nim w ogóle niczego takiego, jak "procesy", więc i komunikacji międzyprocesowej również nie ma, gdyż nie ma się komunikowac co z czym.

Jeśli zaś chodzi o proste "pipki" typu DIR | MORE z poziomu command.com, to owszem, są w planach, aczkolwiek pewnie jeszcze nie w wersji 4.42.

Rozdział "Gospodarka pamięcią" przeczytałeś nieuważnie lub bez zrozumienia - bo i od kiedy to "od zawsze w ROM" są mechanizmy przydziału pamięci rozszerzenia?

Co to jest "połowiczna relokacja" i jak ona polepsza kompatybilność?

Nie są, tylko teoretycznie mogą być. Co do "ograniczeń w użyciu JMP", doprawdy, chciałbym wiedzieć, w którym miejscu tego manuala jest napisane coś, co sugeruje, że biblioteka SDX nie może się posługiwać akurat tym rozkazem, i dlaczego...

A to duży błąd. Jeśli mechanizm pozwala na uniknięcie przydziału tego samego banku dwóm programom, oraz pozwala na uzyskane informacji, które banki są aktualnie wolne, a które nie, to jest to już o niebo więcej niż "brak".

A jaki poziom byś chciał?

To zbędna komplikacja. Program najlepiej sam sobie będzie przełączał banki w zależności od własnych potrzeb, natomiast system wystarczy, jeśli się w tym nie pogubi i nie pokaszani układu banków ustawionego przez program.

Aha. To pod hasłem "kompatybilność" masz na myśli możliwość użycia takiej konstrukcji w źródle. Jednak żeby to uzyskać, niekoniecznie trzeba relokować z dokładnością do strony (aczkolwiek tak jest najłatwiej): http://atariki.krap.pl/index.php/ACX

Mylisz się, bo, jak nadmieniłem nieuważnie przeczytałeś manual. Gdybyś go przeczytał uważnie, to byś zauważył, że na str. 12 jest napisane "System dla własnych potrzeb zajmuje pamięć jak nastepuje: ... 3) biblioteka systemowa w module ROM".

Twój główny problem chyba polega na nieuważnym czytaniu.[1]

Zadam dodatkowe pytanie pomocnicze: czy student widział kiedykolwiek SpartaDOS X w działaniu, albo nawet może miał możliwość interakcji z tym DOS-em przez minimum pół godziny?

Twój drugi problem polega na tym, że używasz wyrazu "wiem" w sensie "nie mam o tym pojęcia, ale wydaje mi się".

[1] Odnoszę się w ten sposób do wyrażenia "teoretycznie można" oraz "ja mówię, jak to zostało zrobione", które świadczą, że nie doczytałeś hasła "ACX" nawet do trzeciego zdania.

a) Opieram się na zdaniu: brak było urządzeń korzystających z linii interrupt w SIO (mowa o oryginalnych produkowanych przez Atari). W tej chwili nie znalazłem źródła tej informacji.
b) Znalazłem to: http://tajemnice.atari8.info/ksiazki/pw … egowa.html i z tego wynika, że oryginalne procedury I/O używały polling.
c) Z opisu tutaj: http://atariki.krap.pl/index.php/SIO również nic nie wskazuje na to żeby linia interrupt w SIO była używana. Nie pamiętam czy w schemacie SIO2PC interrupt jest do czegoś używany.

Dodatkowo znalazłem informacje, że w ROM istniały procedury SERIN, SEROUT czy jakoś tak, które miały obsługiwać przerwania od urządzeń ale nie znalazłem dokładniejszych informacji o tym jakie urządzenia z tego korzystały.

Nie znalazłem również źródeł szybkich I/O, które są używane w nowych "OS-ach" Atarowskich. Nie wiem jak w nich jest to zorganizowane. Trudno mi też powiedzieć jak wygląda sytuacja po instalacji turbo w stacjach i czy stacje nie produkowane przez Atari również nie obsługiwały linii interrupt w SIO.

Oczywiście pamięć bywa zawodna, a ja informację o interrupt w SIO znalazłem w opisie sprzętu, a nie opisu procedur SIO w ROM.

Wytknij mi jakiś błąd merytoryczny, a zacznę się tłumaczyć z doświadczenia jakie posiadam. :-)

Zabieram się na dziś za pisanie loadera, a nie OS-u.
OS ledwie projektuję, a od projektu do pisania może być bardzo daleka droga.

A zaboli kogoś jeśli mi nie wyjdzie? Lub raczej jeśli mi chęci nie stanie?

Wiesz... dla was guru to np. Drac030 ale on mi już wielokrotnie udowodnił, że nie rozumie nomenklatury jaka powstała przez te X lat od momentu gdy Atari 8bit przestało być produkowane.

Tak było kiedyś z DMA/bus masteringiem.

Tak jest teraz z WE/WY sterowanym przerwaniami, a nie z użyciem polling.

Może rzeczywiście czegoś nie wiem, zapomniałem. Informację zbieram po kawałeczku przez całkiem długi okres czasu więc coś mogło mi się zatrzeć w pamięci...
Stawiam jednak, że dla Drac030 WE/WY po przerwaniach to polling z opóźnieniami odczytu portów sterowanym przerwaniami zegarowymi.

Przynajmniej z procedur SIO jakie znalazłem wynika, że timeouty i opóźnienia są z użyciem przerwań timerów POKEY ustalane ale to nie jest WE/WY sterowane przerwaniami. Urządzenia w Atari według wszelkich szans nawet linii interrupt w SIO nie mają podłączonej do czegokolwiek.

Pomijając. Zbaczamy z tematu.
To co znalazłem potwierdziło jednak, że powinno udać się asynchroniczne WE/WY zrobić nawet jeśli mam rację, że "normalne" urządzenia w Atari korzystają wyłącznie z polling.

MM: Proszę przeczytać regulamin, szczególnie w punktach dot. poprawnego cytowania. Timer: 24h. Dziękuję za uwagę.

Konczac odpowiadam.
Nie ma!

P.-S. Co do braku przerwani w standardowym SIO, poczytaj moze troche i nie pisz glupot. To ze linia Interrupt nie jest uzywana przez urzadzenia nie znaczy ze nie jest to transmisja oparta o przerwania. Generuje je POKEY po odebraniu bajtu do bufora - teoretycznie w tym czasie (zanim bajt bedzie w buforze w calosci) komputer robic moze dowolne rzeczy. A ze czeka sobie tylko NA PRZERWANIE to inna sprawa i kwestia napisania procedur innych niz systemowe.
Tak samo jest przy nadawaniu na lacze szeregowe, tez jest generowane przerwanie.

No ale Ty wiesz lepiej, na pewno oprogramowales wiele procedur komunikacji na Atari i masz na to papier :P
A ja - biedny mis klepalem sobie rozne procedury transmisji przez lata - na przerwaniach, a szybkie bez (bo i tak sie nic w miedzyczasie zrobic nie dawalo). A teraz widze, ze zawsze robilem to zle i nie wiedzialem, ze oprogramujac obsluge przerwan pisze procedury nie oparte na przerwaniach - o ja glupiec ide sobie glowe rozbic o mur, i pokasuje z dysku te wszystkie programy, a moze poprosze wielu uzytkownikow by tez to zrobili, bo to nie ma prawa dzialac wg fachofcoof.

Ale po o mam pisac, widac z daleka, ze draco na atari sie nie zna absolutnie, pisze jakies nedzne wprawki programistyczne tylko, a i tak wiekszosc nie dziala. Jeszcze wiele sie musi nauczyc, nim papier na to dostanie, oj wiele!!! :)
A poza tym z terminologia lezy, nie stosuje nowoczesnego slownictwa informatycznego - pewnie go nie zna. To czlowiek z epoki, kiedy Mysz nazywalo sie "Manipulator stołokulotoczny". To skansenu z z takimi a nie programy pisac, dzis sie pisze wielkie systemy kompilatorami, ktore same optymalizuja kod (ciekawe kto optymalizuje kod kompilatorow), a nie jakies dlubaniny na piechote w assemblerze!!!