amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > negativer addresszeiger? [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

01.01.2011, 02:01 Uhr

AGSzabo
Posts: 1663
Nutzer
wir wollen das jahr mal nicht negativ anfangen aber mich quält folgende frage: es ist an der tagesordnung zu testen ob ein von einer funktion zurückgegebener addresszeiger null ist um zu sehen ob die funktion erfolgreich war, zB AllocMem(). Ist es nun auch erlaubt, davon aus zu gehen dass es niemals eine addresse geben kann, die im 32bit-raum negativ ist? ich will einen 3-state rückgabewert haben, zB positiv = ok, speicher erhalten, null = fail, garkein speicher verfügbar, und das besondere: negativ = kein fast ram (das nur so als beispiel, ich weiss es ist ein schlechtes beispiel, man soll ja vorher mit AvailMem() testen). aber das mit dem negativ, darf man das?

--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ - Antworten - Zitieren - Direktlink - ]

01.01.2011, 02:30 Uhr

thomas
Posts: 7716
Nutzer
Zitat:
Original von AGSzabo:
Ist es nun auch erlaubt, davon aus zu gehen dass es niemals eine addresse geben kann, die im 32bit-raum negativ ist?


Nein, das ist nicht erlaubt. Ein 32bit Pointer darf auch 32 Bits benutzen.

Aber da du ja Assembler programmierst, spricht doch nichts dagegen, mehrere Werte zurückzugeben, z.B. den Pointer in A0 und einen Fehler-Code in D0. Wenn D0 0 ist, enthält A0 die Adresse, in allen anderen Fällen beschreibt D0 den Fehler.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

01.01.2011, 04:01 Uhr

tboeckel
Posts: 124
Nutzer
Zitat:
man soll ja vorher mit AvailMem() testen

Wer erzählt denn so einen Unfug? Verlaß dich nicht auf AvailMem(). Verlaß dich nur auf AllocMem() und verwandte Funktionen. Entweder du kannst Speicher bekommen oder nicht. Vorheriges Testen bringt überhaupt nichts, weil jederzeit Speicher freigegeben werden kann, so daß die Info von AvailMem() bestenfalls nutzlos sind. AvailMem() kann dir unter OS3 vielleicht sagen, daß noch 1MB Speicher frei ist, aber du kannst mit 100%iger Sicherheit diesen Speicher nicht für dich reservieren, weil er fragmentiert ist und deswegen nicht als ein großer Block zur Verfügung steht. Und damit ist jegliche Info über "freien Speicher" absolut nutzlos. Versuch einfach die gewünschte Menge Speicher zu reservieren. Wenns nicht klappt, dann hilft dir auch die ausgeklügelste Logik nicht weiter.

Und mit dem Pager von OS4.1 wird die Situation sogar noch ins Gegenteil umgekrempelt: AllocMem() funktioniert, obwohl AvailMem() garantiert einen Fehlschlag vorhersagt.

Lange Rede, kurzer Sinn: stell keine Vermutungen an, sondern wisse! Niemand garantiert dir, daß 32bit das Maximum für alle Zeit darstellt.

[ Dieser Beitrag wurde von tboeckel am 01.01.2011 um 04:02 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

01.01.2011, 11:20 Uhr

Kronos
Posts: 1168
Nutzer
Zitat:
Original von thomas:
Zitat:
Original von AGSzabo:
Ist es nun auch erlaubt, davon aus zu gehen dass es niemals eine addresse geben kann, die im 32bit-raum negativ ist?


Nein, das ist nicht erlaubt. Ein 32bit Pointer darf auch 32 Bits benutzen.


Naja, nur ist das AmigaOS ja schon von haus aus mit diesen 31Bit-Addressen verseucht, da kommt es auf 1 oder 2 mehr Funktionen der Art auch nicht mehr an ;)

MfG
Kronos
--
Only the good die young all the evil seem to live forever

[ - Antworten - Zitieren - Direktlink - ]

01.01.2011, 11:37 Uhr

68kassembler
Posts: 62
Nutzer
@AGSzabo:
Das Problem bei deiner Aussage ist doch, das du hier von Negativen Angaben sprichst. Nun das ist ein Problem, weil:

1) Angaben über die Maximalen Freien Speicher immer Positiv oder 0 sind
2) Adressen immer Positiv sind!
3) Computer eigentlich keine Negativen Zahlen kennen.

Vor allen der letzte Punkt ist erst mal wichtig. Negative zahlen
werden durch (meistens) das hochwertigste Bit dargestellt. Daher, wenn du das erste Bit setzt, wird meistens diese Zahl dann Negativ, weil es so Definiert ist.

Und wenn es mal ein Amiga mit mehr als 2 GB RAM geben sollte, kann es in einen 32-Bit Wert dann "negative" angaben geben, weil eben genau diese Bit gesetzt wird. Korrekterweise muss man dann dieses Bit als Bestandteil der Zahl und nicht als Vorzeichen interpretieren.

Daher, ist das vorgehen, so wie du es meinst, so nicht umsetzbar.

Und außerdem weißt du ja gar nicht, wo der Speicher liegt. Es kann also sein, das der Speicher oberhalb dieser 2GB Grenze liegt. Dann wären auch Adressen Negativ.

Daher ist aus meiner Sicht, dein Vorgehen fragwürdig. Es wäre wirklich besser, wie es schon thomas angegeben hat. Gib doch einfach in z.b. A0 die Adresse zurück und in D0, ob es Funktioniert hat. So sparst du dir gleich noch einen Befehl.

Kann aber in höheren Sprachen ein Problem werden, wie z.b. C, weil diese Sprachen nur ein Rückgabe wert Akzeptieren. Das kann man aber auch lösen, in dem man einfach sagt, da kommt ein Struct und wenn der Zeiger auf diesen Struct null ist, hat eben nicht Funktioniert oder in dieser Struct kannst du den Fehler wert angeben. Oder du schreibst eine Funktion, wo man dann den Fehler genauer Abrufen kannst, dann brauchst du wirklich nur 0 zurück geben.

[ - Antworten - Zitieren - Direktlink - ]

01.01.2011, 11:50 Uhr

RhoSigma
Posts: 67
Nutzer
Hallo, gesundes Neues,

also meiner Meinung nach ist die Sache für ein in sich gekapseltes
(eigenes) Projekt vollkommen egal, ob man die Adresszeiger nun mit
31 od. 32 Bit behandelt, ich habe noch keinen Amiga mit mehr als
2GB (31Bit-Grenze) gesehen. Wichtig ist nur für sich selbst dann
eine Konvention aufzustellen, und dann dementsprechend zu pro-
grammieren, sprich in Assembler zwischen vorzeichenlosen (32Bit)
und vorzeichenbehafteten (1Bit-Vorz. + 31Bit Daten) Tests zu unter-
scheiden:

Hier meine persönlichen Aufzeichnungen dazu:
code:
  für Vorzeichenlose Operationen:
  -------------------------------

  Die folgenden Bedingungs-Codes erfordern die Beeinflussung des C-Flags,
  damit ergeben sich die folgenden Nutzungsmöglichkeiten: (hinter Befehl)

  Ja: ADD/SUB/NEG (aller Art, außer [ea,An]), ASx/LSx/ROx (aller Art),
  --- CMP (aller Art), RTE, RTR

  Nein: MOVE (aller Art, außer [ea,CCR] und [ea,SR]), LEA, PEA, EXG, SWAP,
  ----- LINK, UNLK, MUL/DIV (aller Art), CLR, EXT, AND/OR/EOR/NOT (aller Art),
        Bit-Befehle (aller Art), TAS, TST, CHK

   HS = CC = high or same >=             (HS nicht Motorola Std.)
   LO = CS = low          <              (LO nicht Motorola Std.)
   HI = high              >
   LS = low or same       <=

   CC = carry clear       C-Flag clear   (kein Datatype-Overflow)
   CS = carry set         C-Flag set     (Datatype-Overflow (Bit 8/16/32))


  für Vorzeichenbehaftete Operationen:
  ------------------------------------

  Die folgenden Bedingungs-Codes erfordern die Beeinflussung des V-Flags,
  damit ergeben sich die folgenden Nutzungsmöglichkeiten: (hinter Befehl)

  Ja: ADD/SUB/NEG (aller Art, außer [ea,An] und BCD-Varianten der Befehle),
  --- MUL/DIV (aller Art), ASx (aller Art), CMP (aller Art), RTE, RTR

  Nein: MOVE (aller Art, außer [ea,CCR] und [ea,SR]), LEA, PEA, EXG, SWAP,
  ----- LINK, UNLK, CLR, EXT, AND/OR/EOR/NOT (aller Art), LSx/ROx (aller Art),
        Bit-Befehle (aller Art), TAS, TST, CHK

   GE = greater or equal  >=
   LT = lower than        <
   GT = greater than      >
   LE = lower or equal    <=

   VC = overflow clear    V-Flag clear   (kein Vorzeichen-Overflow)
   VS = overflow set      V-Flag set     (Vorzeichen-Overflow (Bit 7/15/31))


  für beides gleichermaßen verwendbar:
  ------------------------------------

  Die folgenden Bedingungs-Codes erfordern die Beeinflussung des N/Z-Flags,
  damit ergeben sich die folgenden Nutzungsmöglichkeiten: (hinter Befehl)

  Ja: MOVE (aller Art, außer [SR,ea] und A/M/P-Varianten sowie Supervisor),
  --- SWAP, ADD/SUB/NEG (aller Art, außer [ea,An] und BCD-Varianten für PL/MI),
      MUL/DIV (aller Art), EXT, AND/OR/EOR/NOT (aller Art),
      ASx/LSx/ROx (aller Art), Bit-Befehle (außer für PL/MI), TAS,
      CMP (aller Art), TST, CHK (außer für EQ/NE), RTE, RTR

  Nein: LEA, PEA, EXG, LINK, UNLK, CLR
  -----

   EQ = equal             =              (testet nur Z-Flag)
   NE = not equal         <>             (testet nur Z-Flag)

   PL = plus              >= 0           (testet nur N-Flag)
   MI = minus             <  0           (testet nur N-Flag)

   T  = always true       1              (nur DBcc/Scc Befehle)
   F  = always false      0              (nur DBcc/Scc Befehle)


[ - Antworten - Zitieren - Direktlink - ]

01.01.2011, 12:30 Uhr

geit
Posts: 332
[Ex-Mitglied]

Negativ ist Böse. Was man machen kann, ist fixe Ergebnisse ausgeben. also -1 oder -2 abfragen, da man diese Werte nie von einem Alloc oder sonstwie bekommt.

Das ist nicht schön, aber eine Möglichkeit.

Mit Availmem zu prüfen ist natürlich Schwachsinn, da wir ein Multitasking System haben und ein anderer Task den Speicher noch vor dem Alloc klauen kann und die Abfrage dann sinnfrei macht.

Geit

[ - Antworten - Zitieren - Direktlink - ]

01.01.2011, 14:04 Uhr

AGSzabo
Posts: 1663
Nutzer
ich habs jetzt so gemacht dass d0 postitiv, null, -1 oder -2 sein kann. im fall positiv hat a4 als träger eines pointers einen sinn. sonst wird a4 nicht beachtet.
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 01.01.2011 um 14:04 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

01.01.2011, 17:39 Uhr

akl
Posts: 265
Nutzer
@AGSzabo:

Da beim Zweierkomplement glücklicherweise -1 mit 0xFFFFFFFF belegt ist und man rückwärts zählt (-2 ist 0xFFFFFFFE) kann man diese Werte vom Ende des Adressraums ziemlich entspannt als Fehlerwerte verwenden. Das wird auch an einigen Stellen im AmigaOS so gemacht (siehe z.B. Graphics/Layers/Intuition-Taglisten).

Das geht prinzipiell so lange, wie der allozierte Speicher (immer) größer ist, als das, was am Ende des Adressraums theoretisch an effektiv physikalisch verfügbarem RAM noch kommt.

Im dem Zusammenhang: Speicher, der von AllocVec zurückgegeben wird, ist grundsätzlich immer (mindestens) langwort-ausgerichtet.

Selbst wenn also im Bereich am Ende des Adreßraumes nicht sowieso ROM oder andere Nicht-RAM-Adressen liegen würden, würde bei AllocVec() grundsätzlich keine Adresse größer als 0xFFFFFFFC sein können.

Bis -4 hast Du also (mindestens) Luft ;-)


[ - Antworten - Zitieren - Direktlink - ]

01.01.2011, 19:04 Uhr

AGSzabo
Posts: 1663
Nutzer
@akl:

> Bis -4 hast Du also (mindestens) Luft ;-)

ja, ich habs jetzt mit d0 gemacht wie oben beschrieben. ich spare mir zwei cmp.l #$ffffffff und $fffffffe und mache statt dem ein tst d0 und dann wenn negativ noch ein cmp.w #$fffe. außerdem spare ich mir das verschieben von d0 nach a4 um in a4 nach moveq #-1 oder #-2 zu d0 disen wert in a4 zu haben (a4 direkt bräuchte ein move.l ...).

aber irgendwelche tricks gehen immer. Zb gibt es im layer einen pointer auf einen backfill-hook. setzt man den explizit nicht auf null sondern auf genau 1, bedeutet dies dass der backfill deaktiviert ist (siehe layers.h).

;-)
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ - Antworten - Zitieren - Direktlink - ]

02.01.2011, 12:25 Uhr

68kassembler
Posts: 62
Nutzer
@RhoSigma:

Ich halte diese Argumentation für nicht unbedingt gut, weil das Problem schon auftreten kann, bevor man 2 GB RAM im Rechner hat.

Z.b. man kann die Anfangsadresse des RAMs so beschreiben:
(x steht für irgendeine Zahl)

$00xxxxxx

In diesen Fall würde es keine Probleme geben, aber, was ist mit:

$FFxxxxxx

In diesen Fall gebe es durchaus Probleme. Man könnte genau hier z.b. 128 MB RAM legen.

Gut, ich weiß gerade nicht, ob es überhaupt irgendeinen Classic Amiga geben wird, wo dieses Problem auftritt, aber wenn man viele Zorro Karten verwendet, die viel "Speicher" brauchen (also viele Adressen) und man auch noch viel RAM eingebaut hat, dann kann es schon passieren, das man dann Plötzlich Adressen in so einen Bereich hat.

Ich hoffe mal, das dies so Verständlicher ist.

[ - Antworten - Zitieren - Direktlink - ]

02.01.2011, 19:17 Uhr

geit
Posts: 332
[Ex-Mitglied]

-3 bis plus 3 sind sicher, aber ganze Bytes im Pointer zu reservieren ist Blödsinn und gefährlich, speziell, wenn man die Software auf aktuellen Maschinen nutzen will.

geit

[ - Antworten - Zitieren - Direktlink - ]

02.01.2011, 19:37 Uhr

RhoSigma
Posts: 67
Nutzer
@68kassembler

nun gut, wenn man es so betrachtet, hast du da natürlich absolut recht, darum gehe ich persönlich bei Adresszeigern immer auf Nummer sicher und verwende vorzeichenlose 32Bit-Logik zu testen dergleichen.

Ich glaube allerdings nicht, daß die AutoConfig soweit geht, daß Speicher wirklich oberhalb der 2GB-Grenze zu liegen kommt. Ich habe z.B. das Mainboard voll (2MB Chip/16MB Fast) habe 64MB auf der CSPPC und 256MB auf der ZorRAM, letztere wird eingeordnet auf den Adressen $50000000-$60000000. Was den (administrativen) Speicher betrifft, den die Karten selbst zur AutoConfig o.ä. benötigen, der liegt eigentlich immer im Bereich des s.g. Expansions-Slots von $00E00000-$00F80000.

Die 4BM FlashRom der Deneb werden bei mir auf $40000000 eingeblendet.
Das einzige sind wirklich die 8MB Gfx-Speicher der CybervisionPPC, die auf $E0000000 liegen, aber da sollte man ohnehin nicht direkt drauf zugreifen.

Also generell ja, hast du absolut recht mit deiner Aussage, Nummer sicher ist IMMER der beste Weg :)

[ - Antworten - Zitieren - Direktlink - ]

04.01.2011, 15:57 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von geit:
-3 bis plus 3 sind sicher, ...

Jede Zahl, die nicht durch 8 teilbar ist, ist sicher...
Das schließt natürlich -3 bis +3 mit ein, da die 0 von vornherein als Fehlerwert belegt ist.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

04.01.2011, 16:07 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von AGSzabo:
ich will einen 3-state rückgabewert haben, zB positiv = ok, speicher erhalten, null = fail, garkein speicher verfügbar, und das besondere: negativ = kein fast ram

Das ist eine ziemlich seltsame Anforderung. Der Wert null besagt doch bereits, dass kein Speicher vom angeforderten Typ verfügbar ist, und der Aufrufer weiß doch selbst, welchen Typ er angefordert hat.
Hat er explizit CHIP oder FAST angefordert, bedeutet der Wert null, dass eben kein CHIP, bzw. FAST verfügbar ist, während der andere Typ verfügbar sein könnte, aber nicht überprüft wurde (was im Kontext einer Low-Level-Funktion zum Anfordern von Speicher auch ziemlich nutzlos wäre). Hat der Aufrufer beliebigen Speicher angefordert, bedeutet null auch "gar kein Speicher verfügbar".

Wobei AmigaOS ohnehin FAST-RAM bevorzugt, wenn man "beliebig" anfordert, und CHIP-RAM nur dann zurückgibt, wenn nichts anderes vorhanden ist. Man braucht also keine speziellen Fehlercodes, um diese anzufangen und dann genau das zu implementieren, was AmigaOS schon von Haus aus tut.

Will man den Benutzer darüber informieren, dass man auf "Notfall"-ChipRAM zurückgreifen musste, braucht man einfach nur "beliebigen" Speicher anzufordern und via TypeOfMem zu überprüfen, ob das Ergebnis Chip-RAM ist. Wenn ja, war nicht genug (oder gar kein) FAST-RAM vorhanden.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

04.01.2011, 19:28 Uhr

tboeckel
Posts: 124
Nutzer
Es sollte eigentlich mittlerweile ausreichend klar geworden sein, daß jegliche Vermutung über die Menge an freiem und allokierbaren Speicher absolut sinnlos ist. Entweder man kann Speicher bekommen oder man kann es nicht. Der einzige Weg diese Information in Erfahrung zu bringen ist es einfach zu versuchen, ganz ohne besondere Logik und mathematische Höhenflüge. Einfach nur AllocMem() oder ähnliche Funktionen aufrufen und entsprechend des Rückgabewerts handeln. Das ist alles nur eine Ja/Nein-Entscheidung und "vielleicht" oder "ein bißchen" gibt es dabei nicht. AvailMem() hat bei dem ganzen Vorgehen überhaupt nichts zu suchen, sondern macht die Sache garantiert nur schlimmer oder sogar komplett falsch.

Wir haben wirklich mehr als genug "Entwickler", die meinen schlauer als das Betriebssystem zu sein und die deswegen irgendwelche tollen Überprüfungen bezüglich freiem Speicher implementieren und deren Programme dann ähnlich tolle Fehlermeldungen ausgeben.

Unter AmigaOS4 kann man selbst bei angezeigten Null freien Bytes immer noch erfolgreich Speicher allokieren, weil es da einen Pager gibt, der genau das ermöglicht. Man darf halt nicht vorher denken, sondern nur nachher richtig reagieren.

Nähere Erläuterungen findet man hier. Der Artikel bezieht sich zwar auf das Speichersystem von AmigaOS4, erklärt aber sehr schön, warum AvailMem() ganz einfach nicht taugt.

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 01:42 Uhr

AGSzabo
Posts: 1663
Nutzer
das mit dem speicher war blos ein (wie ich schon schrieb, schlechtes) beispiel und nicht das was ich eigentlich vor hatte. ist zu kompliziert zu erklären und blos eine von vielen subroutinen in meinem "menu".
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 08:32 Uhr

Thore
Posts: 2266
Nutzer
Was Du brauchst ist ein doppelter Rückgabewert.
Beispielsweise in d0 der Wert (Adresse, NULL, Daten...) und in d1 der Typ um was es sich handelt.
So hast du nicht nur einen tristate sondern einen n-state mit weitaus weniger Aufwand und 32 * 32 möglichen Rückgabewerten.

Sobald Du Adressen zurückgeben willst, musst du bei deiner Idee aufpassen, daß sich die Zahlenbereiche nicht überschneiden.

Das funktioniert übrigens auch mit den AmigaOS API Funktionen im Einklang. Einfach neben dem Speicherbereich der z.B. AllocMem zurückgibt noch den Typ zurückgeben.

[ Dieser Beitrag wurde von Thore am 05.01.2011 um 08:36 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 09:07 Uhr

AGSzabo
Posts: 1663
Nutzer
@Thore:

Ja, so in etwa habe ich das jetzt gemacht. es spart sogar befehle. blos gehts bei mir nicht wirklich um speicher sondern um einen clickstatus im menu ... aber meine frage ist ja jetzt beantwortet. ;-)
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 11:04 Uhr

akl
Posts: 265
Nutzer
@tboeckel:

>Unter AmigaOS4 kann man selbst bei angezeigten Null freien Bytes immer
>noch erfolgreich Speicher allokieren, weil es da einen Pager gibt, der
>genau das ermöglicht

Es braucht nichtmal einen Pager, sondern lediglich einen funktionierenden LowMemory-Mechanismus (vgl. "avail flush")

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 11:06 Uhr

akl
Posts: 265
Nutzer
@Thore:

>Was Du brauchst ist ein doppelter Rückgabewert.

Logisch. Allerdings setzt das voraus, dass man seine Anforderungen sorgfältig definiert.

Also entweder

tristate_pointer = MyAllocVecDirectDropIn(size, flags)

oder eben

pointer = MyAllocVecSimilarReplacement(size, flags, &status);

Aber man kann natürlich auch erstmal lang und breit mit anderen (also uns) darüber diskutieren ;-) nur um dann die Anforderungen zu ändern...

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 12:23 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von AGSzabo:
das mit dem speicher war blos ein (wie ich schon schrieb, schlechtes) beispiel und nicht das was ich eigentlich vor hatte. ist zu kompliziert zu erklären ...

Wenn es so kompliziert zu erklären ist, dass man schlechte Beispiele braucht, um sich Hilfe zu holen, wird am Ende mit ziemlicher Sicherheit nur Murks bei rauskommen.
Zitat:
Original von AGSzabo:
blos gehts bei mir nicht wirklich um speicher sondern um einen clickstatus im menu ...

Oh je.
Der Klickstatus eines Menüs war zu "zu kompliziert zu erklären"?

Ich wollte jetzt gerade mit der rhetorischen Frage schließen, ob Du wirklich weißt, was Du da tust, aber dann fiel mir noch rechtzeitig ein, dass Du ja wirklich selbst sagst, dass Du das nicht weißt.

Aber im Ernst, Du solltest wirklich versuchen, es herauszufinden, und damit meine ich, bevor Du weiteren Code schreibst.

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 12:25 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von akl:
Es braucht nichtmal einen Pager, sondern lediglich einen funktionierenden LowMemory-Mechanismus (vgl. "avail flush")

Na wenn wir schon beim Haarspalten sind, braucht man nicht mal den, weil Kollege Zufall im Multitasking-System genauso zwischen AvailMem und AllocMem für freien Speicher sorgen kann.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 13:59 Uhr

akl
Posts: 265
Nutzer
@Holger:
Haarespalten würde ich das nicht nennen. Der LowMemory-Mechanismus greift noch innerhalb von AllocMem - und zwar wird von dort aus aufgeräumt, nachdem es eigentlich bereits fehlgeschlagen war. Der Unterschied kann dementsprechend gewaltig sein, und deutlich größer als das, was zufällig wieder freiwerden würde. Leider war das in vielen AOS-Versionen nie richtig implementiert.

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 15:20 Uhr

Thore
Posts: 2266
Nutzer
@akl:
> Aber man kann natürlich auch erstmal lang und breit mit anderen (also uns) darüber diskutieren

Hab nur weiter gedacht und gemeint, später braucht er sicher mehr als nur 3 ;) Ich kenn ihn inzwischen...

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 18:57 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von akl:
Der LowMemory-Mechanismus greift noch innerhalb von AllocMem - und zwar wird von dort aus aufgeräumt, nachdem es eigentlich bereits fehlgeschlagen war. Der Unterschied kann dementsprechend gewaltig sein, und deutlich größer als das, was zufällig wieder freiwerden würde.

Nun ja, der Knackpunkt ist, dass der LowMemory-Mechanismus die Erfolgschancen erhöht, während die Tatsache, dass andere Programme zwischen AvailMem und AllocMem dazwischenfunken können, auch zu einer Verringerung der Chancen führen kann, was wesentlich gefährlicher wäre, wenn man sich auf AvailMem verlässt. Ansonsten ist der Differenz zwischen AvailMem und nachfolgenden AllocMem durch zufällige Aktionen im Multitasking beliebig und somit auch beliebig groß, während die LowMemory-Handler die benötigte Speichermenge übergeben bekommen und somit nicht mehr als nötig freigeben müssen.
Man kann also nicht wirklich behaupten, dass LowMemory-Handler tendenziell mehr freigeben als durch zufällige Aktionen anderer Programme frei werden könnte.
Die Implementierung unter AOS3.x steht wiederum auf einem anderen Blatt. Avail Flush ist im Grunde genommen ein Hack. Es wird eine "große" Speichermenge angefordert, wobei es keine exakte Definition gibt, was "groß" in diesem Zusammenhang bedeutet. Es könnte theoretisch a) die Anforderung erfüllt werden, ohne dass der gewünscht "Flush" Effekt eintritt oder b) jeder LowMemory-Handler für sich entscheiden, seine gecachten Ressourcen nicht freizugeben, da bereits klar ist, dass auf keinen Fall genug Speicher für die Anforderung frei wird und das Wegwerfen der Caches keinen Nutzen erfüllt.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 21:54 Uhr

AGSzabo
Posts: 1663
Nutzer
@Holger:

keine sorge, der code läuft bestens, auch dann wenn ich im moment nicht auswendig weiss, was genau ich da gemacht habe. :D ich bezweifle das andere programmierer immer ihr ganzes projekt mit jedem detail im kopf haben ...
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ - Antworten - Zitieren - Direktlink - ]

05.01.2011, 23:12 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von AGSzabo:
ich bezweifle das andere programmierer immer ihr ganzes projekt mit jedem detail im kopf haben ...

Nicht jedes Detail, aber den Teil, für den man gerade eine Anfrage in einem Forum verfasst, sollte man schon im Kopf haben. Und wenn nicht, sollte man lieber sein Gedächtnis auffrischen, statt sich unpassende Beispiele auszudenken.

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > negativer addresszeiger? [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.