back2roots/padua/padua.7z/padua/text/TagItems/text0004.txt

Text File | 2014-05-19 | 3.7 KB | 79 lines

In article <[e-mail]>, Markus Wild writes:

> In article <Ebnir*[e-mail]> [e-mail] (Gerald Malitz) writes:
> >    Strings haben im Code-Hunk nichts zu suchen, denn sie sind
> >ja nun mal nicht executable.  Veraenderlich - im Sinne von nicht vor
> >Schreibzugriffen geschuetzt - sind sie beim Amiga ja in jedem Fall, Exec
> >bietet kein Protected-Memory.  Andererseits kann ein Programm mehrere
>
> Diese Unterscheidung ist ja nur wichtig, wenn Du residentfaehige Programme
> schreiben willst, deshalb hab ich das ja explit erwaehnt. In diesem Falle
> kannst Du Dir nicht mehrere Data-Hunks leisten, da Du ja mit A4 alle DATA
> Objekte erreichen musst. Chip-Data Hunks sind unter diesen Umstaenden auch
> speziell, und muessen wie CODE Hunks behandelt werden, denn wenn sie auch
> veraenderlich sind, hast Du im Nu ein nicht-pures Programm.

    Natuerlich koennen residentfaehige Programme mehrere Data-Hunks
haben, und sie haben sie auch.  Lediglich die globalen veraenderlichen
Daten muessen relativ adressiert werden.  Die Konstanten - um genau die
geht es ja - koennen ebenso wie der Code gemeinsam benutzt werden.  Sie
werden in jedem Fall absolut adressiert, ob sie nun in einem Code oder
einem Datensegment liegen.  Wenn Du das Beispielprogramm von Andreas mal
compilierst, hast Du (zumindest mit SAS) ein Executable mit drei Hunks:
dem Code-Hunk und zwei Daten-Hunks, einer enthaelt die globalen Variablen
des Programms (in dem Fall hauptsaechlich aus der Linklibrary), der andere
die Konstanten (in dem Fall den String "Hello World\n").  Letzterer muss
eben nicht in den Code-Hunk.

    Deshalb bekommt Andreas ja auch Probleme, wenn er dem Linker
die Option SMALLDATA mitgibt.  Dann werden diese beiden Data-Hunks
zusammengefasst.  Wenn er Pech hat, landet am Ende alles - auch die
Variablen - im Hunk fuer globale Konstanten.  Klar, dass das schief
geht.

> >die erste Wahl.  (Btw. wer seine Strings nun doch unbedingt unter den
> >Code gemixt haben will, soll sich aus dem Handbuch eine geeignete
> >Compileroption suchen.  Die gibt es naemlich auch.  Aetsch.  Helfen
> >wuerde es in diesem Fall aber auch nicht.)
>
> Aeh, wer sagt denn, dass Exec *nie* Protected Memory bieten wird?

    Und wovon traeumst Du Nachts ;^)

> Genauso wenig wie es Protected Memory gibt im Moment, gibt's Protected
> Hunks, also steht's 1:1, aetsch zurueck;-)))

    Abseits, ganz klar! =:^>  Dir fehlt nach wie vor der Grund,
Daten in den Code zu mischen - da sie ja so oder so nicht geschuetzt
sind und in jedem Falle absolut% adressiert werden muessen.

    % mindestens aber pc-relativ, das ist aber auch nicht ohne,
da bei SAS die Module auf 64K beschraenkt sind.

> Helfen tut es immer dann,
> wenn residentfaehige Programme mit moeglichst viel Data erzeugt werden
> sollen.

    Helfen kann ich nur dann, wenn Konstanten da sind, die aus
dem relativ zu a4 adressierten Bereich herausgenommen werden koennen.
Die muss ich aber nicht in ein Code-Segment packen, sondern kann sie -
wie oben beschrieben - auch in einem eigenen Daten-Segment unterbringen.

    Nebenbei: das Erzeugen residenter Progamme mit cres.o ist IMHO
sowieso nur ein Hack, fuer den man einen Preis zahlt.  Die globalen
Variablen sind auf 64K beschraenkt (schoenen Gruss an die DOSe), das
ganze fuehrt leicht zu Verwirrungen (Blink-Warnings) oder Abstuerzen
(Option SMALLDATA) und __saveds bzw. geta4() tun auch nicht mehr wie
gewuenscht.

> -Markus

    Tschuess, Gerald.

--
  // Gerald Malitz,  Bolchentwete 4,  3300 Braunschweig,  Voice: [phone]
\X/ [e-mail]    "Allein der K|ndigungsschutz f|r Schwangere hat den
ungeborenen Kindern tausendfach mehr geholfen als alle Kardindle, Staatsanwdlte
und Richter zusammengenomen"                                     Heiner Gei_ler