Beiträge von Mike im Thema „Freier Speicher“

    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.