26

Odp: Kodowanie z perspektywa relokacji.

drac030 napisał/a:
Jaskier napisał/a:

Dziwne, a mi się udało :D

Tak? A nie wykłada się aby na kombinacjach typu:

Nie widzę powodu aby miałby się wykładać. Nigdzie nie zakładam, że rozkazy następują w określonej kolejności. Właściwie nigdzie nie zakładam, że jakiekolwiek rozkazy występują :)
Tablica fixupów jest generowana na podstawie wzorca skompilowanego pod $8000 oraz 256 próbek testowych skompilowanych pod adresy od $4000 do $40ff.

Aby odpackować teksty trzeba najpierw odpackować  program do ich odpackowywania - Energy #1

27

Odp: Kodowanie z perspektywa relokacji.

No tak, przyznaję, w ten sposób może to i działać. Ja jednak pozostanę chwilowo przy mojej metodzie, która zakłada, że program kompilowany jest dwa razy, a nie 257 razy. :)

KMK
? HEX$(6670358)

28

Odp: Kodowanie z perspektywa relokacji.

Oj narzekasz. Masz gotowe rozwiązanie. Tylko brać i używać :)
A tak właściwie nie wiem, czy zdajesz sobie sprawę, ale przez ciebie spędziłem 3 niedzielne godziny na kodowaniu zamiast na słodkim nieróbstwie :)

Aby odpackować teksty trzeba najpierw odpackować  program do ich odpackowywania - Energy #1

29

Odp: Kodowanie z perspektywa relokacji.

Innymi słowy przyczyniłem się walnie do twego rozwoju - nie ma sprawy, nie oczekuję wiele w zamian, wystarczy mi jakieś osiem piw na najbliższym party :P

KMK
? HEX$(6670358)

30

Odp: Kodowanie z perspektywa relokacji.

LOL

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

31

Odp: Kodowanie z perspektywa relokacji.

Draco: ja wiedzialem, ze chodzi o piwa. A tak sie zes wykrecal w watku o zrzucie na procki :)

32

Odp: Kodowanie z perspektywa relokacji.

Metoda z zastosowaniem tablic fixup'ow, rozumiem, ze rozwiazuje problem niemozliwosci korzystania z konstrukcji typu:

lda <adres
sta addr
lda >adres
sta addr

Fajnie, tylko dzieje sie to kosztem raczej sporego nakladu dodatkowych danych stanowiacych zawartosc tych tablic. Interesowaloby mnie na ile statystycznie mozna ocenic procentowy udzial tej tablicy w stosunku do calosci ladowanego pliku.
Na szczescie, obszar pamieci zajmowany przez te tablice po ich wykorzystaniu zostaje zwolniony, wiec jest to "problem" tylko dla pamieci zewnetrzenej.

Ale nie o tym zamierzalem pisac.
Jest jeszcze inna kwestia mocno mnie zastanawiajaca.
Wyobrazam sobie ze programy rezydentne mozna podzielic na dwa ich typy. Pierwszy to taki, ktorego zaleta jest to, ze maksymalnie powieksza bufor dla uzytkownika, ale nie ulatwia wpolistnienia innych rezydentrow w pamieci. Drugi natomiast spelnia ten dodatkowy warunek. Kryterium podzialu jest, wedlug mnie, sposob uzywania pamieci na stronie zerowej. Jesli program przywraca zawartosc zastana obszaru strony zerowej jaka dotyka, do stranu sprzed, to znaczy, ze mozna zakwalifikowac go do tej drugiej kategorii.
Tak mysle, ale sa to tylko moje teoretyczne dywagacje, a ciekaw jestem, czy istotnie programy rezydentne pisane dla SDX postepuja w wyzej opisany sposob, czy tez gospodarowanie strona zerowa jest jakos inaczej rozwiazane. A jesli program rezydentny dziala w tle na przerwaniach i korzysta ze strony zerowej, to czy zawsze powinien co ramke przywracac zawartosc uzywanych komorek?

33

Odp: Kodowanie z perspektywa relokacji.

Wiele zależy od tego, co program robi. Rezydenty zastępują często albo uzupełniają jakieś procedury systemowe, to i wtedy nie korzystają ze strony uzytkownika ($80-$FF), ale z komórek strony zerowej przeznaczonej dla tych procedur systemu, do których rezydent się podpina. I tak np. ramdysk może korzystać z adresów uzywanych przez SIO, QE korzysta z adresów używanych przez edytor ekranowy itd.

KMK
? HEX$(6670358)

34

Odp: Kodowanie z perspektywa relokacji.

marok napisał/a:

Metoda z zastosowaniem tablic fixup'ow, rozumiem, ze rozwiazuje problem niemozliwosci korzystania z konstrukcji typu:

lda <adres
sta addr
lda >adres
sta addr

Nie tylko ten problem. Generalnie nie masz ograniczeń co do tworzenia programu. Możesz dowolnie umieszczać tablice, wskaźniki itp.

marok napisał/a:

Fajnie, tylko dzieje sie to kosztem raczej sporego nakladu dodatkowych danych stanowiacych zawartosc tych tablic. Interesowaloby mnie na ile statystycznie mozna ocenic procentowy udzial tej tablicy w stosunku do calosci ladowanego pliku.
Na szczescie, obszar pamieci zajmowany przez te tablice po ich wykorzystaniu zostaje zwolniony, wiec jest to "problem" tylko dla pamieci zewnetrzenej.

Player CMC z 2019 bajtów rozrósł się do 3503 (wliczając kod relokatora) :)

Aby odpackować teksty trzeba najpierw odpackować  program do ich odpackowywania - Energy #1