To kwestia podłączenia MMU :p

Zresztą, wirtual i MMU na 65c816 dzisiaj jest mniej więcej tak samo prawdopodobny, jak na Motoroli 68k 20 lat temu.

Pomysł polega na tym, że skoro już mamy więcej niż 64k pamięci, oraz życzymy sobie (Laoo np.) żeby był możliwy podział pliku binarnego na segment TEXT, DATA, BSS itp., to żeby rozmiaru tych segmentów sztucznie nie ograniczać.

O ile mi wiadomo, Atari ST na przykład zostało zaprojektowane na 4 MB pamięci. Jednak format pliku binarnego DRI (ten od plików PRG) pozwala teoretycznie na zbudowanie pliku o wielkości do 4 GB. Czy ewentualne pytanie do projektanta tego formatu, na co zamierza wykorzystać te 4 GB, albo czy ma na to jakiś pomysł, uznałbyś za sensowne?

Zgadza się, ale ani ten artykuł Biblia, ani gość jest wynalazcą podziału na TEXT/DATA/BSS.

No a do tego wystarczy przecież flaga w nagłówku (jak w Atari ST pod MiNT-em: shared text bit). Modyfikacji kodu nie trzeba zabraniać. Poza tym shared text ma sens jedynie w systemie z multitaskingiem, a do tego jeszcze trochę nam zostało.

M.in. dlatego nie bardzo chciałem implementować format pisany w artykule, po tekście widać, że facet jest teoretykiem.

No ale przecież to właśnie przewiduje przewiduje projekt. Zauważ, że dyskutujemy o formacie pliku binarnego, a nie o tym, w jaki sposób ma go produkować kompilator. Lizard dał ci przykład użycia dyrektyw .text, .data i .bss tak jak to jest robione na innych komputerach, na przykład na Atari ST, żeby daleko nie szukać. Problem w tym, że MAE czy MAC/65 takich dyrektyw nie mają.

No na SpartaDOS-ie świat się nie kończy.

Rozwiązuje się to w ten sposób, że TSR ma tylko segment TEXT, a procedurę instalacyjną na końcu. Ładujesz go do pamięci, a przy wyjściu mówisz systemowi, że część zajętą przez procedurę instalacyjną należy zwolnić.

W SDX natomiast masz dwa segmenty w jednym pliku, z tego jeden relokowalny, a drugi nie. Ten drugi ładujesz na stronę szóstą albo piątą i szóstą i on steruje instalowaniem. Tyle że dwóch stron może zabraknąć na installer, albo mogą być zajęte na coś innego - i co wtedy?

no to juz wiem co mam dodac do asemblera, DATA, TEXT, BSS :) i pewnie REL aby zasygnalizowac ze piszemy relokowalny

Nowy format pliku binarnego ?  Jak dotad jedynie Sparta udostepnia inny format plikow binarnych i potrafi go odczytac. Powstaje pytanie co bylo pierwsze kura czy jajko ? Najpierw powstaje format pliku binarnego a potem DOS, OS, czy może to niezbyt własciwa kolejnosc ?

Przyklad Lizarda:

    .text 
    lda vfname 
    ldx vfname+1 
    jsr fopen 

    .data 
vfname .rw fname         ; relocatable word ;) 
fname  .by "D:nazwa.ext" 

    .text 
fopen sta $0314 
    stx $0315  

Jesli 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.

A czy nie prosciej byloby zalozyc, ze relokowalne sa wszystkie odwolania w obszarze bloku. Zakladamy ze program relokowalny miesci sie poza obszarem strony zerowej i w pewnych granicach pamieci, np. $0400-$BFFF
Jesli adresujemy w obrebie programu to te rozkazy beda poddane relokacji, poza w/w zdefiniowanym obszarem nie beda poddawane relokacji (w koncu nie mozemy dopuscic aby program ladowal sie np. na caly stos czy w inne obszary ktore potrzebuje OS do dzialania)

    rel    ; informacja dla asemblera, ze teraz leci relokowalny kod i zeby zaczal go kontrolowac

    lda vfname      ; relokowac bo adresowanie w obrebie programu
    ldx vfname+1  ; relokowac bo adresowanie w obrebie programu
    jsr fopen         ; relokowac bo adresowanie w obrebie programu

vfname adr(fname)   ; relokowac, bo to adres adr() czy tez .rw

fname  .by "D:nazwa.ext"   ; nie relokowac, bo zaden rozkaz
              ; nie odwoluje sie do 'fname', rozkazy typu adr i .rw nie sa brane pod uwage

fopen sta $0314                  ; nie relokowac bo adresowanie poza programem
    stx $0315                   ; nie relokowac bo adresowanie poza programem

Asembler domyslnie zasembluje od najmniejszego dozwolonego obszaru ($400), koniec sam okresli po asemblacji, jesli jakis tryb adresowania odwola sie ponizej $400 i powyzej dlugosci programu nie bedzie relokowalny, pojawi sie ostrzezenie. Ofsety do bajtow ktore maja zostac poddane relokacji zostana umieszczone w tablicy na koncu wczytywanego bloku razem z informacja czy modyfikowane jest 16bit czy 24bit.

OS zacznie czytac taki plik, odczyta naglowek, w ktorym bedzie informacja o dlugosci bloku i jego rodzaju w tym przypadku blok relokowalny. Na podstawie dlugosci bloku zarezerwuje obszar pamieci zaczynajacy sie od MEMLO, wczyta tam blok. OS zacznie czytac nastepny blok ktory jest tablica ofsetow. Procedury OS zaczna modyfikowac wczytany blok na podstawie tablicy ofsetow. W tablicy ofsetow powinna znalezc sie informacja czy ofset wskazuje na wartosc typu 16bit czy 24bit.

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 fopen

deklaruje etykietę 'fopen' jako adres wewnętrzny, czyli tym samym argument jsr podlega relokacji. Ale:

cio = $e456
...
    jsr cio

deklaruje 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ć ;-)).

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.

Nie rozumiem, tzn. programista ma o to zadbać?

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.

Laoo: podzielam Twoje wątpliwości.
Draco, cały czas wydaje mi się, że próbujesz dostosować format do możliwości jakie daje MAE, czyli narzędzia produkującego format pliku na podstawie kodu binarnego. To znacznie ogranicza.
Chyba najlepszym rozwiązaniem byłoby napisanie nowego asemblera, który wiedziałby o relokacji. Wtedy można byłoby uwzględnić wiele nowych rzeczy. Tylko kto go napisze?

Takim asemblerem na Atari jest chyba w tej chwili Fast Assembler, produkuje kod relokowalny w formacie Sparty X.

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.

No pewnie, że programista. A pod SDX flagę INSTALL duch święty ustawia? :D

Masz rację. Ale rozbudowa loadera tylko w tym celu to jednak overkill.

Jakoś nie widzę, żeby Laoo miał jakieś wątpliwości - przynajmniej ze mną się nimi nie podzielił.

O wlasnie. Nawiazujac do poprzedniej wypowiedzi truba juz chyba potrafie nazwac o co mi chodzilo i sprecyzowac moje "watpliwosci", jako bardziej "ideowe". Ostrzegam, ze bede fantazjowal ;) Relokowalny format binarny, to super pomysl, tylko trzeba zadac sobie pytanie o potrzebe takiego formatu. Normalnie dla standardowego ATARI OS wydaje mi sie on malo przydatny, gdyz pomijajac przypadki instalowania roznych rezydentnych nakladek w pamieci atari na raz przebywa i tak tylko jeden program i nie musi on dzielic zasobow z zadnym innym, przez co nie ma konfliktow adresowych. Relokacja wydaje sie jednak niezbedna dopiero przy wielozadaniowosci, lub przynajmniej przy powaznym wsparciu dla rezydowania w pamieci wielu programow przez system operacyjny. Prawdziwy multitasking na atari wydaje sie szalenie trudny do uzyskania, ale w przypadku 65c816 i duzej ilosci pamieci ta druga opcja jest jak najbardziej mozliwa. Dosc mile sa wizje wspierania przez atarowski OS odpowiednika windowsowego Alt+TAB, aby moc uruchomic sobie kilka narzedzi rownoczesnie i przelaczac sie pomiedzy nimi. I to wg. mnie ma sens. Tylko do tego potrzebny jest SILNY system operacyjny. 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 (wartosc PORTB) przydzielona programowi gdy potrzebuje on dodatkowej pamieci. 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.
Nie chce byc oczywiscie jednostronny i zdaje sobie sprawe, juz przy standardowym OSie jezeli nie pisze sie dema, to fajnie byloby zwrocic uwage na wartosc MEMLO i dopiero od niej ustawic program. Wlasnie ze wzgledu na rezydenty. 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.

No faktycznie... o tym ALTcie nie pomyslalem, to powaznie komplikuje sytuacje  ;) Wiem, ze to nie to samo, ale gdyby tak zastosowac Control+Tab ?  Ew. jakas kombinacja z klawiszami funkcyjnymi. Zawsze tez mozna wywiercic w obudowie nowa dziure (jedna wiecej nie zrobi roznicy) i dorobic jakis specjalny przycisk do przelaczania taskow. Moglby byc nawet obslugiwany sprzetowo przez jakis uklad, ktory wysylalby procesorowi przerwanie NMI, co skutecznie pozwalaloby na killowanie zawieszonych procesow  ;) (jakby jeszcze dodac jakis MMU to byloby gites)

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.

Tak jest, ale o systemie może podyskutujemy kiedy indziej, żeby nie rozwadniać.

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.

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.

ja jestem, jakby co. :>
nie odzywam sie, ale za to pilnie slucham...

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.

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.

dzięki :D

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.

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. Wystarczy, że znają nazwę funkcji. Dlatego mówimy o komunikacji między programami, a nie procesami. A samo wywoływanie funkcji często jest elementem komunikacji między procesami. RPC, jeden z pierwszych mechanizmów tego typu to nic innego jak takie wywoływanie. Nie ma co porównywać, ale idea jest podobna. Mechaniżm symboli w SDX do złudzenia przypomina natomiast biblioteki DLL, które firma M. wprowadziła dobrych kilka lat później :lol:

Jeżeli loader przydziela pamięć, to może się okazać, że istnieją dodatkowe warunki tego przydziału. Spróbuj np. uruchomić TD.COM z bardzo niskim memlo. Kaszana w połowie linii bierze się stąd, że pamięć obrazu została przydzielona na granicy 4kB, bo Sparta wszystko ładuje jak leci pod memlo. Jest to jedna z rzeczy, których nie trzeba teraz uwzględniać, ale można by zostawić dla niej miejsce, jeżeli chcemy by format był uniwersalny.