Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
TONY Montezuma's Gold na Atari 2600 Nowa produkcja Monochrome Productions dla konsoli Atari 2600 już dostępna w wersji cyfrowej.
VBXETERM 0.15 Nowa wersja emulatora terminala VBXETERM dodaje obsługę klawiszy strzałek oraz nowe czcionki.
Weekend z Borsuk Retro Gry TV Zapraszamy na weekendowe transmisje z udziałem gości, w tym budowę Custom Atari XL i naprawy sprzętu.
AltirraSDL Lobby Przeglądarkowy front-end dla emulatora Altirra z trybem gry wieloosobowej online od Ilmenita.
Test7800 0.8.0 Nowa wersja Test7800 wprowadza wsparcie dla większych kartridży Bankset oraz obsługę Quadtari.
atari.area forum » Posty przez drac030
Nie napisałeś Draco, jakiej przeglądarki używasz.
Firefoxa.
Po skasowaniu cookies jest to samo, to znaczy jak się da "Cytuj", to wiadomość trzeba wpisywać dwa razy, jak opisałem poprzednio.
Krap: na forum wchodzę po linku zapamiętanym w historii (http://atariarea.histeria.pl/forum/viewforum.php?f=1), zawsze tak robiłem, ale dopiero od dziś powoduje to problemy.
Oki, oki. Na razie skasowałem stare cookies, zobaczymy, co sie będzie działo teraz.
Odpowiem ci grzecznie, jak mi zagwarantujesz, że mnie Dely nie odstrzeli za pisanie na na temat ;-)
Ok, z tym nie na temat, to masz pan rację, tak jakoś wyszło.
No mi się też wydaje, że to przede wszystkim skrypt jest nowy, bo ma nowe logo ;-) i np. jak odpowiadam temu samemu gościowi na trzy różne posty, to moje odpowiedzi łączone są w jedną, co poprzednio nie miało miejsca. Oraz ma okienko na "szybka odpowiedź", które pojawia się, kiedy jest zbędne, a znika, kiedy by się przydało.
Ale jednak ten efekt z dwukrotnym logowaniem i traceniem tego, co się już raz napisało - moim przynajmniej zdaniem - kwalifikuje nowy skrypt do kosza.
A dlaczego do wczoraj/przedwczoraj wszystko działało jak należy?
Interfejs wymagal szybkich ukladow (serii ALS - pracujacej przy nawet kilkudziesiaciu MHz)
to czy zysk niebyłby jeszcze większy - jak widać układy kontrolera są taktowane jeszcze szybciej niż 6502, 65c816, czy FastRAM.
Ja tam elektronikiem nie jestem, ale wydaje mi się, że sformułowanie "szybkie układy" dotyczy w tym miejscu nie częstotliwości, z jaką są taktowane, ale szybkości, z jaką reagują na bodźce zewnętrzne. Różnice pomiędzy układem szybkim a wolnym - przy tej samej częstotliwości pracy - są rzędu nanosekund, ale pamiętam, że grało to jakąś rolę ...
[ Dodano: Sob Paź 30, 2004 15:15 ]
mam kawałek swojego programu umieszczonego w obszarze np. od $123456 - czyli w pamięci FAST:
czy jeśli wykonam LDA $123456 a LDA $3456, to czy ten drugi odwoła się fizycznie do $003456, czy do $123456 ?
Do $123456.
hmm... niby fakt, tyle że mój system HiDOS przy obsłudze IDE KMK używa własnego sterownika, który wspiera także użądzenia ATAPI oraz obie tabele partycji (starą (FDISK) i nową (PartitionWizard).
No ale jak będzie 512k ROM-u, to nie będzie potrzeby używania sterowników zewnętrznych, bo sterownik systemowy obsłuży wszystkie bajery. Co wskazuje, że w twoim DOS-ie uzyteczne byłoby, gdyby sterownik IDE występował w postaci ładowalnego modułu :)
[ Dodano: Sob Paź 30, 2004 15:15 ]
Kurczę, nie powiem, żeby mi się nowa konfiguracja Forum podobała. Po pierwsze primo, odpowiedź trzeba pisać dwa razy:
1) klikamy "Cytuj"
2) każe się logować
3) logujemy się
4) otwiera się okienko na odpowiedź
5) piszemy ją
6) wciskamy wyślij
7) pojawia się "Logowanie"
8) logujemy się
9) pojawia się ponownie okienko na odpowiedź - tym razem PUSTE
10) odpowiedź poprzednią trzeba wklepać jeszcze raz (albo wkleić z clipboardu)
11) i dopiero teraz "wyślij" działa
Co jest grane?
MM: Odpowiedzi przeniesiono do nowego topiku we WŁAŚCIWYM miejscu.
Pewnie tak samo obsluguje sie jak stacje dyskow, przez SIO ($e453), na poczatku pewnie wyslac do kazdej stacji po kolei zadanie podania STATUSu i na tej podstawie odnalezc napedy miekkie i twarde. Juz kiedys pytalem sie jak rozpoaznac KMK i SIO2IDE wiec pewnie to znajde.
Zczytujesz PERCOM-y wszystkich napędów i patrzysz na miejsca, które wymienił Caspar ("IDE" w 3 ostatnich bajtach, flagi gęstości itd.). Potem dla wszystkich znalezionych partycji dajesz komendę $EC żeby dowiedzieć się szczegółów.
"Wszystkie napędy" to wartości od 1 do 16 w DUNIT. Niestety, SpartaDOS 3.x (czyli Sparta dyskowa) zawiesza się, kiedy się próbuje gadać z napędami o numerach powyżej 8, oczywiście dotyczy to tylko używania SIO Sparty a nie systemowego. No ale warto to wiedzieć na wszelki wypadek :-)
Na 65c816 z odpowiednią ilością pamięci (15 MB na przykład) można by już pokusić się o gcc.
Myślę, że młodszą najpierw.
No ja to odebrałem w ten sposób, że Lizard planuje zbiorowe samobójstwo :D Ale potem, kiedy go przycisnąłem na GG, temat rozwinął, w związku z czym przyszłość wygląda nieco bardziej optymistycznie.
RAM od $C000 do $CFFF - nawet nawet, tyle że żdążyłem zauwarzyć, że full softu rozpoznaje OS'a po bajtach zaczynających się od $C000 lub kilka/kilkanaścia bajtów dalej... więc co z tym?
Masz niestety rację. No ale może zyski będą większe niż straty ... ?
Pod adresami $d1xx możnaby zostawić rejestry dla kompatybilności, a w obszarze nowych rejestrów ustawić odpowiednio dla trybu 16-bitowego '816. :lol: :lol: :lol:
Rejestrów pod $d1xx nie trzeba chyba koniecznie zachowywać, w końcu cały prawie soft, który z nich korzysta, można łatwo uaktualnić, a tak na codzień potrzebne są tylko sterownikowi w ROM-ie.
Magistralę ma ośmiobitową, toteż odczyt szesnastobitowy trwa dokładnie dwa razy tyle, co ośmiu bitów. Ale liczy się też zassanie rozkazu i adresu.
Ergo, jedno LDA szesnastobitowe (i z szesnastobitowym adresem) będzie trwało tylko o jeden cykl dłużej niż odpowiednie ośmiobitowe, czyli 5 cykli, w porównaniu do ośmiu, które zjada wciągnięcie analogicznej ilości danych rozkazami ośmiobitowymi.
Wynika z tego, że przesłanie danej z rejestru IDE do pamięci - odczyt w trybie absolutnym, zapis w pośrednim indeksowanym - trwa na 6502 aż 24 cykle:
lda ide_data
sta (bufp),y
iny
lda ide_data+1
sta (bufp),y
inynatomiast na 65c816 to samo powinno zająć tylko 16:
lda ide_data
sta (bufp),y
iny
inyno ewentualnie do 18 przy zastosowaniu 24-bitowego adresowania. Czysty zysk.
Myślę, że 1 MB na ROM + rejestry (pół na pół) "ought to be enough for everyone" 8) Czyli:
$000000-$EFFFFF - RAM
$F00000-$F7FFFF - ROM
$F80000-$FFFFFF - rejestry I/O
Oczywiście część tego ROM-u musi być przemapowana na $00D800-$00FFFF, bo kompatybilność, wektory przerwań itd. Ale na $00C000-$00CFFF może być RAM, nie?
65c816 jak dotąd nie ma koprocesora. Ale chyba MC 68882 by się nadał od biedy ... gdyby ktoś go umiał podpiąć.
65c816 oczywiście ma szesnastobitowe LDA/LDX/LDY/STA/STX/STY/INC/DEC itd.
Khm, że się wtrącę. gcc faktycznie winszuje sobie bardzo dużo pamięci i już na 14 MB mogą być problemy, a co dopiero na 4 MB. Ale to gcc 2.95.2, a kto powiedział, że koniecznie trzeba używać właśnie tej wersji? Z tego co pamiętam dobrze działające wersje gcc to 2.7.2, 2.6.5 oraz 2.3.3. (było jeszcze 2.8.1 ale to pomyłka). Wszystkie trzy życzą sobie dużo mniej RAM-u niż 2.95.2, są nowsze niż Pure C (tak mi się wydaje - ale może ktoś sprostuje) no i kompilują C++, o ile to komuś robi.
Wysiada, bo to nie ma być bardzo śmieszne. Pomysł Lizarda - który popieram - polega na tym, żeby 1 listopada przejść się do Mariusza Geislera i ułożyć mu jedynie właściwy znaczek ze zniczy. Samo przejście się też chyba wystarczy.
Zastanawiam się nad programami dla 6502, które korzystają z dodatkowej bankowanej pamięci (PORTB). Gdyby loader wiedział o tym, ktore banki są do dyspozycji i przydzielał (na sugestię) bloki pamięci rozszerzonej, a program używał tych przydzielonych banków to nie trzeba byłoby wybierać banków, nie ma napisywania ramdysku itp.
No ja to szczerze mówiąc widzę tak, że w momencie, kiedy dostaniesz x megabajtów pamięci liniowej, adresowalnej wprost, jeszcze w dodatku szybkiej, wtedy rozszerzenia starego typu po prostu przestaną być potrzebne. Może się będzie od biedy wykorzystywać tę pamięć na buforowanie zapisu na twardziel, ale innych zastosowań nie widzę.
Ergo, nie ma sie co gimnastykować i dawać w nowym formacie binarnym jakiegoś szczególnego supportu dla bankowanej pamięci. Jeśli o mnie chodzi - umówmy się, że najwyższą fazą rozwoju systemów operacyjnych zamkniętych w 64 kilobajtach jest SpartaDOS X - która ma dla bankowanej pamięci support prawie perfekcyjny - i ... zostawmy to po prostu tak jak jest.
Mój komputer, odkąd mam twardy dysk, ma 176 kilobajtów niepotrzebnej pamięci. Jest 64k podstawowe plus Sparta X zajmuje jeden bank pamięci, co daje razem 80k. Reszta się leży odłogiem.
Nie do końca o to mi chodziło, ale nowy sposób ładowania w pętli daje rzeczywiście nowe możliwości, np. umieszczanie porcji programu w różnych rodzajach pamięci.
Nie jest on taki znowu nowy, pliki $FFFF są ładowane dokładnie tak samo. Ale przyznaję ci rację, że to jest wynalazek wart zachowania.
Chodzi Ci chyba o komunikację między procesami - tego faktycznie nie ma. Ale w przypadku SDX jeden program może udostępniać funkcje innym, zewnętrznym programom. Ich programiści nie muszą wcześniej wiedzieć pod jaki adres skoczyć, co w przypadku relokacji jest ważne.
Tak jest, wiem o tym, jest to załatwione za pomoca symboli. Weź jednak pod uwagę, że symbole są trudne do zachowania - w tej roli - na 65c816, gdzie JSR "krótki" (16-bitowy) i JSR "długi" (24-bitowy) to są dwa oddzielne rozkazy, wymagające w dodatku różnych rozkazów RTS przy powrocie.
Dlatego jedynym sensownym rozwiązaniem dla systemu operacyjnego itp. jest wołanie funkcji przez przerwanie programowe (COP).
Mechaniżm symboli w SDX do złudzenia przypomina natomiast biblioteki DLL, które firma M. wprowadziła dobrych kilka lat później :lol:
Może Bill The Great kupił sobie 800XL. Idea plug&play też się pojawiła dobre 12 lat po tym, jak Atari Inc. wymyśliło "nowe urządzenia".
Jeżeli loader przydziela pamięć, to może się okazać, że istnieją dodatkowe warunki tego przydziału.
Tak jest, może się tak okazać. Ja zakładam jednak optymistycznie, że nawet Antic - z jego czterokilowym ograniczeniem - kiedyś wyjdzie z użycia. Dlatego nie uważam, żeby miało sens dostosowywanie formatu binariów do Antica akurat. Ostatecznie można to łatwo rozwiązać programowo. Jak kiedyś na Falconie potrzebowałem bloku pamięci z wyrównaniem do granicy 64 kilobajtów, to obeszło się bez supportu systemowego, wystarczyło że system w ogóle był w stanie zaalokować blok pamięci, dalej poradziłem sobie sam.
No właśnie, a jeżeli będzie już tworzona przez kompilator, to może warto się zastanowić, czy nie wykorzystać tego do bardziej zaawansowanych celów niż sama relokacja. Chodzi mi tu o dwie rzeczy: współpracę między załadowanymi programami oraz zarządzenie pamięcią. To pierwsze już (jak piszesz) jest w postaci symboli.
To już jest up to you, do czego co wykorzystasz.
Jeżeli mamy >64kB pamięci, to może też rozwiązać odwieczny problem wykorzystania dodatkowych banków w taki sposób, aby to loader, a nie program decydował, które banki należy przydzielić?
To chyba oczywiste: jeśli nie ma adresu ładowania wykazanego w nagłówku, to loader decyduje. Zauważ, że preselekcja rodzaju pamięci w nagłówku - zdaje się że napisałem coś o tym poprzednim razem - ma mieć charakter sugestii, a nie wiążącej decyzji. Wyobrażam sobie to w ten sposób, że jesli flaga sygnalizuje żeby program załadować do RAM-u powyżej 64k, to loader ma to zrobić, o ile ta pamięć istnieje i jest w niej miejsce. W przeciwnym razie ma spróbować wpakowac program do pamięci podstawowej i poddać się dopiero, kiedy to też się nie uda.
Zresztą to nie jest mój wynalazek, tak to jest zrobione na Atari ST.
A może przy 65816 nie dałoby się umieszczać pewne programy z innym PBR, tak aby miały do dyspozycji więcej ramu? (popraw mnie jak się tego nie da zrobić).
Da się, ale nie wiem, czy to jest potrzebne. To znaczy w przypadku naprawdę dużych programów, kiedy masz np. segment TEXT 64k, to wiadomo, że segmenty DATA i BSS znajdą się w innym banku. Wtedy można założyć, że loader ustawia - automatycznie - bank kodu na ten, gdzie jest TEXT, a bank danych na ten, gdzie jest DATA/BSS. Alternatywą jest pełne adresowanie (będzie wolniej), które i tak będzie konieczne w przypadku programów jeszcze większych...
Albo wyrównanie kodu do granicy strony, ale nie po to, by załatwić dzielone adresy, ale np. by precyzyjnie liczyć cykle?
Wybacz, ale rozważania PO CO kazać wyrównywać adresy do granicy stron naprawdę trochę wybiegają poza główny nurt tej dyskusji (oględnie mówiąc). Wystarczy, że może się to przydać - a już konkretnie komu do czego, to nie nasza sprawa w tej chwili.
To chyba mylisz komunikację między programami z obsługą wywołań systemu. W SDX jest to przyznaję rozwiązane bardzo pomysłowo, ale niewiele ma to wspólnego z tematem.
Nie mylę, bo możesz napisać dwa programy relokowalne, załadować je równocześnie i wzajemnie wywoływać funkcje za pomocą nowych symboli.
Ale to będzie jeden program, bo nie mamy multitaskingu. Jeśli jeden program wykorzystuje drugi jako zestaw podprogramów do wywołania, to trudno doprawdy nazwać to komunikacją pomiędzy programami.
Do nagłówka wprowadziłem następujące nowe pola:
- długość segmentu TEXT (to pole było i poprzednio, zmiana nazwy tylko)
- długość segmentu DATA;
- długość segmentu BSS;
- wielkość stosu;
- wielkość segmentu zawierającego symbole zewnętrzne;
Obecnie nagłówek wygląda tak:
- bajty 0-3: REL1
- bajty 4-5: flagi
Flagi obecnie są takie:
$0001 - LWD - 32-bitowe słowa w nagłówku (w przeciwnym razie 16-bitowe); danie 32 bitów zamiast 24 upraszcza loader.
$0002 - TSR - wiadomo;
$0004 - EXE - uruchomić program od offsetu wskazanego w nagłówku (w przeciwnym wypadku: nie uruchamiać; patrz dalej;
$0008 - INI - to samo, tylko że oczekuje się, że program wróci przez RTS oddając przy tym status wykonania (kod błędu albo $01); jeśli oba bity są ustawione, to najpierw wykonuje się INIT, a potem EXEC.
$0010 - STK - zaalokować stos o wielkości wykazanej w nagłówku; teraz mnie naszły wątpliwości, czy ta flaga jest w ogóle potrzebna.
$0020 - ZPG - zaalokować oddzielną stronę zerową dla programu;
$0040 - APG - wyrównać adres ładowania w górę do granicy stron;
$0080 - ABK - wyrównać adres ładowania w górę do granicy banków;
W starszym bajcie trzy bity kodują rodzaj pamięci, do którego należy załadować program. Powinno wystarczyć. Reszta na razie zarezerwowana.
Dalej nagłówek leci tak (słowami 16- albo 32-bitowymi, j/w):
słowo 0: długość segmentu TEXT
słowo 1: długość segmentu DATA
słowo 2: długość segmentu BSS
słowo 3: wielkość stosu
słowo 4: długość segmentu XREF
słowo 5: długość segmentu FIXUP
słowo 6: offset EXEC
słowo 7: offset INIT
bajt: wielkość opcjonalnego tekstu + tekst opcjonalny o tej wielkości.
Segment FIXUP (lista fixupów): pierwsze słowo (16 bitów) koduje format, dalej dane wyglądają w zależności od formatu. Format $0000: szesnastobitowe offsety bezwzględne licząc od początku pliku, i dla 16-bitowych adresów (co wystarcza jeśli program ma <= 64k i używa włącznie 16-bitowego adresowania wewnątrz siebie).
Segment XREF: future definition ;-) wyobrażam sobie to tak, że najpierw idzie typ symbolu, potem wielkość nazwy symbolu, potem onaż, a potem offsety w pliku binarnym, gdzie należy wstawić właściwy adres tudzież wartość. Ale to na razie zostawmy na przyszłość.
Na specjalne życzenie truba, który chce, żeby program składał się nie tylko z oddzielnych segmentów na kod i dane, ale wręcz z oddzielnie ładowanych i uruchamianych porcji kodu, można dać nastepujące zastrzeżenie co do loadera: program ten po załadowaniu pierwszego nagłówka i wszystkich wykazanych w nim segmentów, oraz ewentualnym zainicjowaniu ich, ma powtarzać te czynności w pętli aż do EOF, chyba że program zażąda przerwania tej pętli - tak jak to się obecnie dzieje, przez np. skok jmp (dosvec) z segmentu INIT, zamiast powrotu przez RTS.
Jezeli juz bysmy taki mieli, to dlaczego plik relokowalny musialby byc taki ubogi?Dlaczego by nie wprowadzic np. koncepcji zmiennych systemowych, czyli symboli, ktore normalnie w asemblowanym kodzie bylyby deklarowane jako zewnetrzne i podczas ladowania system (loader) przypisywalby im konkretne wartosci jak np. rozmiar dodatkowej pamieci, rodzaj procesora, czy chociazby numer banku
Bazując na poprzedniej dyskusji wprowadziłem do nagłówka nowe pola definiujące nowe bloki danych. Między innymi jest tam blok dla symboli zewnętrznych. Tak więc to jest załatwione. W ogóle wprowadziłem do pierwotnej propozycji dużo zmian, i mogę je tu przedstawić, o ile jesteś ciekaw.
Wiem, ze troche zagalopowalem sie teraz z fantazjowaniem, ale wg mnie relokowanie ma najwiekszy sens przy obecnosci rozbudowanego srodowiska systemowego, ktore w polaczeniu z duzym potencjalem formatu pliku dawaloby wielkie mozliwosci.
Z tym rozbudowanym środowiskiem trochę przesadziłeś. Powiedzmy, że relokacja jest niezbędna jeśli OS ma mieć jakiś mający ręce i nogi system zarządzania pamięcią: czyli funkcje malloc() i mfree(). Przejście z 6502 na 65c816 jest chyba dobrą okazją do wprowadzenia takiego mechanizmu dla pamięci powyżej $00FFFF (dla tego co poniżej nie ma to chyba sensu ze względu na kompatybilność).
Brak malloc()/mfree() zamyka możliwość wprowadzenia multitaskingu raz na zawsze, ze względu na konflikty.
Do takich celow proponowany przec Draco format w zupelnosci wystarcza i nawet nie musimy zawracac sobie glowy jakimis segmentami DATA czy BSS, bo ich przydatnosc wydaje sie wtedy watpliwa.
Niemniej format uzupełniłem o te segmenty :D
Analiza zwykłego kodu maszynowego i na tej podstawie relokacja nie wydaje mi się najlepszym rozwiązaniem. Daje stosunkowo ubogie możliwości w porównaniu do sytuacji, gdy asembler wie, że ma utworzyć kod relokowalny i sprawdza ew. konflikty oraz dostarcza dodatkowych możliwości programiście.
Chłop swoje, czort swoje. Trub, czy możesz mi logicznie wytłumaczyć, skąd ci się wzięła uporczywie przez ciebie lansowana koncepcja, że proponowany przez mnie format pliku relokowalnego nie może być, bądź też ma nie być tworzony przez kompilator?
Jeśli mi nie odpowiesz na to pytanie, tak żeby odpowiedź miała ręce i nogi, to kończę dyskutowanie z tobą; bo jak dotąd ja ci mówię A, a ty wyciągasz z tego wniosek, że nie A, tylko B. W ten sposób możemy gadać długo i bezowocnie, szkoda czasu.
Poza tym problem relokowalności wydaje mi się tylko jednym z elementów więszej całości jakim byłby pewnie system operacyjny,
Tak jest, ale o systemie może podyskutujemy kiedy indziej, żeby nie rozwadniać.
który mógłby obsługiwać programy relokowalne, np. umożliwiał komunikację pomiędzy nimi. W tej chwili tylko SDX potrafi to zrobić (za pomocą symboli).
To chyba mylisz komunikację między programami z obsługą wywołań systemu. W SDX jest to przyznaję rozwiązane bardzo pomysłowo, ale niewiele ma to wspólnego z tematem.
Może lepiej więc byłoby się zastanowić PO CO chcemy nowy format i czy napiszemy nowego OSa (oczywiście wielozadaniowego), asemblera a wtedy zastanówmy się jaki format binarki.
Odpowiedzi na te pytania znajdują się w poprzednich postach wątku. Po co chcemy nowy format:
1) mnie jest potrzebny format relokowalny, żeby uzyskać maksimum wolnej pamięci dla SysInfo;
2) format SDX się nie nadaje do tego celu (adresy dzielone);
3) przy okazji format można lepiej zdefiniować i szerzej wykorzystać; dlatego w ogóle poddałem to pod dyskusję.
Relokatora z TA możesz sobie uzywać sam, jeśli cię to satysfakcjonuje.
Nie mówię o pisaniu pod Spartę, tylko użycie formatu tego DOSa (a raczej koncepcji relokowania) także dla innych systemów. Wydaje się, że załatwia on w tej chwili większość problemów.
No ale ja nie mam ochoty używac formatu Sparty dla Sysinfo (bo wymagałoby to zmian w kodzie programu), a jeśli mam go - format Sparty - i tak modyfikować, to wolę coś takiego zdefiniować od nowa.
W końcu stary loader nowego formatu i tak nie będzie rozpoznawał, czy ten format będzie zupełnie nowy, czy będzie modyfikacja któregoś ze starych.
Ładujesz go do pamięci, a przy wyjściu mówisz systemowi, że część zajętą przez procedurę instalacyjną należy zwolnić.
Nie rozumiem, tzn. programista ma o to zadbać?
No pewnie, że programista. A pod SDX flagę INSTALL duch święty ustawia? :D
Zgadza się, tak się w tej chwili najczęściej robi, ale można też użyć obu relokowalnych, np. nie używając flagi INSTALL tylko ustawiając samemu MEMLO. Wtedy odpada problem szóstej strony, o którym piszesz.
Masz rację. Ale rozbudowa loadera tylko w tym celu to jednak overkill.
Laoo: podzielam Twoje wątpliwości.
Jakoś nie widzę, żeby Laoo miał jakieś wątpliwości - przynajmniej ze mną się nimi nie podzielił.
Draco, cały czas wydaje mi się, że próbujesz dostosować format do możliwości jakie daje MAE.
Nie bardzo widzę, na jakiej podstawie może ci się tak wydawać.
Do możliwości jakie daje MAE (MAC/65, QA, cokolwiek) dostosowany jest program mkrel.com. Nie byłby on potrzebny, gdyby asembler od razu generował kod docelowy.
esli blok TEXT (jeden za drugim) zostanie umieszczony pod $2000, a blok DATA pod $9000, dodatkowo 'vfname' zostanie zmodyfikowane bo jest typu .rw to czy rozkazy w bloku TEXT odwolujace sie do 'vfname' tez zostana zmodyfikowane, powinny byc bo inaczej ten przyklad nie zadziala.
Akurat z tego punktu widzenia przykład Lizarda nie jest najszczęśliwszy. Co ma robić kompilator: kompilator ma skompilować wszystko tak, jakby było pod adres $0000 (lub ewentualnie $000000). Po czym ma wygenerować listę fixupów, czyli offsetów do słów i długich słów wewnątrz programu, do wartości których nalezy po załadowaniu pliku dodać adres ładowania.
Koniec, kropka.
Napisałem poprzednio, że relokacja ma być transparentna dla programu. Rozwinę to teraz: dla programisty też. Ciebie, jak programisty, nie obchodzi pod jaki adres system operacyjny załaduje program, który piszesz, oraz w jaki to sposób zrobi. Żadnych specjalnych dyrektyw w kodzie źródłowym, dzielących dane na "relokowalne" i "nierelokowalne" ma nie być.
Po prostu relokowalne jest wszystko (i tylko to) co jest zdefiniowane jako adresy wewnętrzne programu. Czyli:
fopen kod
kod
kod
rts
...
jsr fopendeklaruje etykietę 'fopen' jako adres wewnętrzny, czyli tym samym argument jsr podlega relokacji. Ale:
cio = $e456
...
jsr ciodeklaruje etykietę 'cio' jako adres absolutny, czyli tym samym argument jsr nie podlega relokacji (a w kodzie wynikowym asembler ma wstawić literalnie $20,$56,$e4 i nie generować fixupa).
Ale programista o tym ma nie myśleć.
Być może są jakieś przeszkody żeby tak zrobić, ale przeszkody są po to, żeby o nich dyskutować (i je usuwać ;-)).
atari.area forum » Posty przez drac030
Wygenerowano w 0.137 sekund, wykonano 18 zapytań