Freier Speicher

Es gibt 38 Antworten in diesem Thema, welches 5.417 mal aufgerufen wurde. Der letzte Beitrag (30. März 2015 um 23:59) ist von Hexworx.

  • Hallo!

    In meinem Programmier-Handbuch zum C64 steht daß man die restliche freie Speicherkapazität mit FRE(0) ermitteln kann, falls der Wert negativ ist -> einfach 65536 dazuzählen.

    Hab ich gemacht, Ergebnis 38909, der Startbildschirm sagt aber bekanntlich 38911, woher kommt hier diese Differenz von 2 Byte?

    lg, Markus

  • Na sowas, ich habe gerade ein Deja-vu ^^

    Bitte melde dich an, um diesen Link zu sehen.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Vielleicht muß man nur 65534 dazuzählen, wenn man auf das richtige Ergebnis kommen will.

    Also grundsätzlich wird fre() glaub ich aus dem Zeiger für "Ende der Datenfelder" und "String-Grenze" ermittelt.
    Der Stringgrenzen-Zeiger steht beim Start auf 40960, das Basic-RAM geht aber nur bis 40959. Das ergibt dann schon mal minus 1.
    Wenn das Ende der Datenfelder +1 ist ergibt das dann die Differenz von den zwei fehlenden Bytes.

    Auf die hundertprozentige Exaktheit wurde hier vermutlich keinen Wert gelegt, die muß man dann als Programmierer erst herstellen.

    Schönen Gruß.

  • Mal auf die Schnelle (neben Claus' Link) Folgendes gefunden:

    Compute Gazette Issue 43 - Jan 1987 says:

    ___________________________________________________________
    Meine Kreationen: Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.
    | Bitte melde dich an, um diesen Link zu sehen.
    Avatar: Copyright 2017 by Saiki

  • Das mit den zwei Nullen am Programmende stimmt zwar, ich glaub aber daß es an den zwei Zeigern liegt, aus den fre() berechnet wird.
    1. Der String-Anfangs-Zeiger.
    2. Der Variablenfelder-Ende-Zeiger

    Der String-Anfang beginnt beim Ende des freien Speichers +1
    Und das Variblenfelder-Ende ist am Anfang des freien Speichers -1

    Daraus ergeben sich meiner Vermutung nach die zwei zusätzlichen Bytes.
    Man müßte aber wohl mal in ROM-Listing gucken, wie das genau gemacht wird.

    Schönen Gruß.

  • PRINT FRE rechnet ab Ende Arrays ($31/32), was standardmäßig bei $0803 liegt.

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • Zitat von BIF

    Auf die hundertprozentige Exaktheit wurde hier vermutlich keinen Wert gelegt, die muß man dann als Programmierer erst herstellen.


    m(

    Aber egal - zunächst mal ein bischen Mathematik:

    Wenn man zwei (ganze) Zahlen A und B hat und A kleiner B ist und ausrechnen will wieviel Zahlen man mit A und B und den Zahlen dazwischen hat, dann rechnet man B - A ... PLUS 1!

    Also, als Beispiel nehmen wir mal 3 und 10; 10 - 3 + 1 = 8; und 3, 4, 5, 6, 7, 8, 9, 10 *sind* genau 8 Zahlen.

    Soweit klar?

    Das für BASIC verfügbare RAM startet ab 2048. Hier schreibt das BASIC ein Nullbyte rein, damit der Interpreter beim Programmstart ab einem "Zeilenende" loslaufen kann. Damit ist die erste verfügbare Speicherstelle 2049. Und die letzte verfügbare Speicherstelle ist 40960-1, also 40959.

    Und 40959 - 2049 + 1 = 38911.

    Jetzt steht nach dem Start des Interpreters und nach NEW im BASIC-RAM aber nicht nichts drin, sondern ein leeres Programm. Das besteht nur aus der Endemarkierung: Zwei Nullbytes im Linkpointer. Als Zeilenende steht die Null in 2048 drin.

    Daher nur noch 38909 von der FRE()-Funktion (mal abgesehen von dem signed-16-Bit-Int Blödsinn).

    Tatsächlich wird der freie Speicher aber begrenzt - wie bereits zuvor geschrieben - nach unten durch das Ende der Arrays (in $31/$32, und worauf dieser Zeiger zeigt, ist wirklich *leer*) und nach oben durch den Anfang des String-Heaps (in $33/$34, und worauf dieser Zeiger zeigt, ist das erste belegte Byte vom String-Heap - ist also *nicht* leer) ... und damit ist bei einer Subtraktion dieser beiden Zeigerwerte auch das "+1" schon drin ...

    ... und damit ist das ganze auch *auf's Byte* exakt!

    Die Routine steht im BASIC-ROM ab $B37D.

  • @Markusk:
    Ich hab das auch mal am EMU ausprobiert und mußte feststellen, daß Mike eigentlich recht hat.
    Also, fre() scheint richtig zu arbeiten.
    Möglicherweise bist du einem anderen Phänomen aufgesessen.
    Wenn man eine Variable neu einführt, dann verschiebt sich auch der Feld-Ende-Zeiger weiter nach oben.
    Gegebenenfalls ist es besser alle benutzten Variablen vorher mit dima,b,c anzulegen, um Verschiebungen beim Zeigerauslesen während des Programmablaufs zu verhindern.
    Also mit jeder neu angelegten Variable verringert sich auch der freie Speicher um ein paar Byte.

    Schönen Gruß.

  • Ein Super-MOD möge doch (wie schon durch Claus in Posting Bitte melde dich an, um diesen Link zu sehen. erkannt)

    die beiden Threads zusammenfügen.

    :dafuer:

    Avatar: Bitte melde dich an, um diesen Link zu sehen. Foto von Bitte melde dich an, um diesen Link zu sehen. Lizenziert unter CC BY 3.0 über Wikimedia Commons. Bitte melde dich an, um diesen Link zu sehen.

  • Offensichtlich ist das Thema ein Dauerbrenner.
    Interessant wäre wohl die Frage, mit welcher Methode, bzw. welchem Programm die 2 Phantombytes berechnet wurden.

    Schönen Gruß.

  • Ich denke mal man kann unterscheiden zwischen

    freien Basic Speicher

    und

    freiem Variablen-Speicher.

    fre(0) ermittelt den freien Variablen-Speicher und nicht den freien Basic-Speicher.

    Der Basic-Speicher setzt sich wohl aus dem Basic-Programm+Varialblen-Speicher-Bereich zusammen.


    Schönen Gruß.

  • Ich denke mal man kann unterscheiden zwischen

    freien Basic Speicher

    und

    freiem Variablen-Speicher.


    Wie auch immer du das jetzt gemeint hast...

    Es gibt halt nur einen Speicher. Ob ich den nun mit einem (BASIC)-Programm verbrate oder mit den (BASIC)-Variablen (z. B. durch zu groß dimensionerte Arrays oder ungenutzte Strings). Speicher bleibt Speicher.

    Der Speicher setzt sich ja in dieser Reihenfolge zusammen:

    BASIC-Programm | Variablen | Arrays (reserviert) | FRE | Strings

    D. h., das BASIC-Programm schiebt die Variablen und Arrays vor sich her, wenn es größer wird. Die Strings kommen von hinten entgegen.

    Beispiel:

    10 REM
    DIM A(100)
    B=1
    A$="TEST"

    PRINT FRE(0) + 65536 = 38373

    Danach:

    $2B/2C: $0801-$0808 (BASIC-PRG.) -> 8 Bytes
    $2D/2E: $0809 (Variablen A$ u. B) - zwei Variablen à 7 Bytes -> 14 Bytes
    $2F/30: $0817 (Array-Beginn für A) *
    $31/32: $0A17 (Array-Ende für A) *
    $33/34: $9FFC (String-Speicher-Beginn [A$]) -> 4 Bytes

    * $0A17 - $0817= $0200 = 512 =7 + (101 x 5) -> 512 Bytes

    $9FFC (40956) - $0A17 (2583) = 38373

    8 + 14 + 4 + 512 = 538

    38911 - 538 = 38373

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • Das ist eben gerade der Unterschied mit den zwei Bytes.

    Der Variablenspeicher, der beim Start mit fre(0) ermittelt wird ist um 2 Byte kleiner, als der Basicspeicher für ein Basic-Programm, ohne Variablen selbstverständlich.

    Also rein rechnerisch ist das zwar fast gleich, wenn noch keine Variablen angelegt worden sind, aber nicht ganz gleich.

    Wenn bereits Variablen angelegt worden sind, dann hat fre(0) aber keine Aussagekraft mehr darüber, wie groß das Basic-Programm noch werden kann.

    Also, man kann aus dem freien Variablenspeicher mit Einschränkung natürlich auch Rückschlüße über den freien Basic-Programmspeicher ziehen, wenn z.B. alle Variablen gelöscht sind.
    Aber im Prinzip, berechnet fre(0) in Zusammenarbeit mit der Garbage-Collection den freien Variablenspeicher.

    Schönen Gruß.

  • Aber im Prinzip, berechnet fre(0) den freien Variablenspeicher.


    NEIN!

    Der verfügbare(!) BASIC(& Variablen)-Speicher ist und war nie wirklich 38911 Bytes! Durch die drei '00'-Bytes werden immer zwei Bytes 'geklaut' (wobei die aber eben als Flags nötig sind).

    Wenn bereits Variablen angelegt worden sind, dann hat fre(0) aber keine Aussagekraft mehr darüber, wie groß das Basic-Programm noch werden kann.


    Doch! Siehe oben.

    Hör' doch auf, den Programm- und den Variablen-Speicher zu trennen. Das ist doch alles eine Wurst.

    Menno, BIF :böse

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • In Basic gibt es nun mal den Unterschied zwischen Programm und Variablenspeicher.
    Diese Unterschiede werden durch die Speicherstellen in der Zeropage ab 43 festgelegt.

    Die drei Nullbytes am Anfang, oder am Programmende bilden die End-Markierung des Basic-Programms.
    Danach beginnt für das Basic der Variablenspeicherbereich.
    Und der freie Variablenspeicher der mit fre(0) berechnet wird, wird durch den Felder-End-Zeiger und den Stringrenzen-Zeiger begrenzt.

    Schönen Gruß.


  • NEIN!
    [...]


    Doch!
    [...]
    Menno, BIF :böse

    :wilkommen: Willkommen im Club.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • :lol33::lol27:LOL28

    Made my day again.

    BIF erklärt uns die zweigeteilte Speicherzelle.

    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?

  • Ach kommt, für den geflegten BASIC Peekaboopoker ist doch wichtig zu wissen, ob nun sein Bitte melde dich an, um diesen Link zu sehen. wegen zuviele POKE-Zeilen in BASIC, zuviele Variablen oder wegen Vollmond an einer Purpurnacht auftritt. :bgdev

    BIF erklärt uns die zweigeteilte Speicherzelle.

    Zweigeteilt? Nein. Hier sieht man schön die Bitte melde dich an, um diesen Link zu sehen.. :thumbsup:

    ___________________________________________________________
    Meine Kreationen: Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.
    | Bitte melde dich an, um diesen Link zu sehen.
    Avatar: Copyright 2017 by Saiki

  • Mometan mein Lieblingsthread hier im F64...

    lg, duke :anonym