Przychodzi żaba do lekarza:
-panie doktorze, nie kumam.

Co zmienia wyrównanie adresu przy rozkazie
lda >adres
gdzie adres wskazuje na wnętrze relokowanego obszaru.

No a co ze starszym???

A starszy traktuje się tak samo, jak wszystkie inne starsze bajty wewnętrznych adresów tego pliku.

Istnieje jednak prostsza, krótsza i o niebo bardziej elegancka metoda (zastosowana juz przez ICD w kodzie SpartaDOS X, na wypadek, gdyby ktoś myślał, że to wynalazek L.K. Avalonu, podobnie jak śmigłowiec, samolot itp.):

     lda dadr
     sta vec
     lda dadr+1
     sta vec+1
     ...
dadr .word dane

Ostatnio edytowany przez drac030 (2005-09-10 00:18:20)

To chyba wynika z samej istoty sprawy, nieprawdaż?

Nie ma tu sprzeczności. Pismo mówi bowiem: można swobodnie i bez trudu korzystać z adresów bezpośrednich (natychmiastowych), gdy wyrówna się adres ładowania do granicy strony. Wtedy bowiem fixupowaniu podlegają tylko starsze bajty wewnętrznych adresów programu - a istotą rzeczy jest nie, że starsze czy nie starsze, ale że w każdym razie pojedyczne bajty programu podlegają fixupowaniu, i tym samym nie ma potrzeby dodawania z przeniesieniem całego adresu ładowania do wszystkich wewnętrznych adresów programu; a tylko starszy bajt adresu ładowania do wszystkich starszych bajtów jest dodawany i to bez przeniesienia.

Nie jest więc istotne, czy adres jest zapisany na dwóch kolejnych bajtach (lda adres / sta vec), czy na dwóch, ale nie kolejnych (lda #<adres / sta vec). Poniał? :)

Co więcej, jeśli założysz, że jakaś tablica ma ci się zaczynać od granicy stron, to taka relokacja sprawia, że ta tablica zawsze się od granicy stron będzie zaczynać.

Z informacji o fixupach dołączonej do relokowanego pliku binarnego.

Ostatnio edytowany przez drac030 (2005-09-10 00:39:04)

Banalnie prosto.

Może, w zasadzie, ale ma to dwa mankamenty:

a) wydłuża tablicę fixupów (na oko dwukrotnie)

b) wymaga, żeby tąż tablicę fixupów generował kompilator

Punkt b) to problem bez wyjścia, kiedy kompilator, którego używasz, nie generuje kodu relokowalnego.

A co, jeśli program ma np. 48k źródłówki i ponad 512 etykiet? :P

W Warszawie :) Uksword to inaczej UKSW, czyli Uniwersytet im. Kardynała Stefana Wyszyńskiego, dawniej ATK.

Dlatego, że jak masz lda #$84, wtedy tylko kompilator jest w stanie stwierdzić, czy to jest starszy bajt adresu, młodszy bajt adresu, czy w ogóle nie adres.

Bez kompilatora w ogóle trudno się obyć, ale rozumiem, że idzie o "bez kompilatora, który sam z siebie produkuje tablicę fixupów". A tych jest większość.

I jeśli idzie o "metodę relokacji", zakładam, że chodzi o metodę wytwarzania tablicy fixupów. Oto ona: kompilujesz program dwa razy, raz pod adres dajmy na to $2000, a drugi raz pod dajmy na to $3000 (może być $0100 i $0200 - non refert). Po czym porównujesz obydwie binarki i na podstawie różnic wytwarzasz tablicę fixupów.

Nie możesz tak zrobić dla pełnych adresów (kompilując np. jedną kopię pod $2000, a drugą pod $3001), bo fixupowanie musiałoby być dodawaniem z przeniesieniem, a nie jesteś w stanie zagwarantować, że dwa kolejne bajty, które dla generatora fixupów wyglądają na młodszy i starszy (z różnic adresów j.w.), należą rzeczywiście do tego samego adresu, a nie do dwóch różnych.

Ale za to nie będzie ci działać, jeśli pod $C0CE nie ma tego, co zakładasz, że jest (a np. w Atari 400 i 800 nie ma tam nic). Ciekaw jestem, czy w QMEG-OS jest, bo w moim ROM-ie dla 65c816 nie ma z całą pewnością.

Zastanawiam się w ogóle, jaki sens ma ta kombinacja (php / jsr $c0ce). Zakładając nawet, że pod tym adresem jest rozkaz RTI. O ile mi wiadomo, JSR odkłada na stos adres powrotny pomniejszony o jeden, a przerwanie nie. Wobec tego JSR $C0CE odłoży na stos adres ostatniego bajtu argumentu rozkazu JSR, a RTI do tegoż ostatniego bajtu powróci (bo RTS zwiększa adres o 1, ale RTI nie). Po wykonaniu JSR (na standardowym ROM-ie) zostanie wykonany nie rozkaz TSX, ale CPY #$BA (gdzie $C0 to opcod CPY #, a $BA to opcod rozkazu TSX). Zastanawiam się, co ci to daje.

Domniemywam, że owo JSR ma wstawiać na stos adres bezwzględny kodu znajdującego się za JSR. Nawet jednak, gdyby tak było (a nie jest, patrz wyżej), to RTI ten adres ze stosu zdejmuje zwiększając przy tym wartość wskaźnika stosu. A pierwsze przerwanie - które może wystąpić zawsze, a więc natychmiast po wykonaniu się RTI również - ten adres skutecznie zamazuje. Toteż późniejszymi rozkazami (tsx, lda nnn,x itd.) zdejmujesz ze stosu wyłącznie śmieci, a program idzie w maliny.

Ostatnio edytowany przez drac030 (2005-09-11 01:11:36)

Dziwne, a mi się udało :D

http://jaskier.atari8.info/Relocator.zip

W katalog Program wsadzasz dowolny program do przerelokowania. Jedyne ograniczenie to kompilacja w jednym bloku, czyli brak rozkazów ORG (za wyjątkiem pierwszego oczywiście). Ten pierwszy też jest zresztą specjalny bo musi wyglądać tak:

    org ADDR

a wartość ADDR będzie już automatycznie wsadzana przez generator fixupów.

No i teraz przechodzimy do katalogu Generator i go uruchamiamy. Spowoduje to stworzenie w katalogu Program końcowego exeka zawierającego kompilowany program wraz z odpowiednim relokatorem i tablicą fixupów. Relokator przepisuje program pod memlo i uruchamia go od jego pierwszego bajtu.

Sprawdzałem go kilka razy na prostym przykładowym programie (wypisującym na ekranie kropkę) i działa z różnymi wartościami memlo. Wszelkie zauważone błędy prosze jednak natychmiast zgłaszać. Dziękuję za uwagę :)