letzter Beitrag von BlackJack am
Ich möchte lösen:
"KOTZE" 
Nett...
Aber erkläre uns doch mal bitte den Sinn dieses Konstrukts: In Zeile 0 geht's nach Zeile 100, okay. In Zeile 115 geht's mittels "Gosub" nach Zeile 20, in 23 - falls Aufgabe gelöst - schickt uns das "Return" zum Rest der Zeile 115 zurück, womit dann das Programm nach "Data" auch endet. Warum nicht auf die altbewährte und fehlersichere Art?
Klingt nach Morbus Wrth: In Pascal kann man Prozeduen nur aufrufen, wenn sie vorweg definiert wurden. Damit wandert das Hauptprogramm automatisch ans Ende des Quelltextes.
Klingt nach Morbus Wrth: In Pascal kann man Prozeduen nur aufrufen, wenn sie vorweg definiert wurden. Damit wandert das Hauptprogramm automatisch ans Ende des Quelltextes.
Wurde das nicht damals auch in irgendwelchen Zeitschriften als "Basic-Trick" propagiert, dass GOSUB schneller sei, wenn die Subroutinen am Programmanfang stehen? Nicht, dass es bei den paar Zeilen Programm hier irgendwie relevant wäre...
Ja bei interpretiertem Code läuft der Interpreter sequentiell durch alle Zeilen, beginnend am Anfang. Daher sind häufig aufgerufene Gosubs am Anfang schneller
Nä?! Da ist tatsächlich was enthalten, was Sinn ergibt und sie Geschwindigkeit optimiert? 
Zitat von ZeroZeroJa bei interpretiertem Code läuft der Interpreter sequentiell durch alle Zeilen, beginnend am Anfang. Daher sind häufig aufgerufene Gosubs am Anfang schneller
Zitat von MiksonNä?! Da ist tatsächlich was enthalten, was Sinn ergibt und sie Geschwindigkeit optimiert?
Stellt sich eher die Frage, wie das bei Sprüngen rückwärts im Programmtext großartig anders laufen sollte. Die Verkettung der Programmzeilen besteht eben nur aus dem Zeiger zum Anfang der nächsten Zeile. Zudem ist die Aussage von ZeroZero auch nur die halbe Wahrheit: bei Vorwärtssprüngen beginnt der Suchprozeß ab der aktuellen Zeile. DAS ist die eigentliche Optimierung!
Ich wusste doch, dass es da einen Haken gibt... Wäre ja auch echt zu schön gewesen 
bei Vorwärtssprüngen beginnt der Suchprozeß ab der aktuellen Zeile. DAS ist die eigentliche Optimierung!
Wenn irgendwo im Programmcode ein Gosub XXXX steht, ermittelt der Interpreter ab BASIC-START die erste Zeilennummer und muss dann durch die ganze Verkettung die richtige Zeilennummer finden, immer von Anfang an. Das C64-Basic führt keine Zeilennr.-Adress-Tabelle.
Deshalb ist jeder Sprungcode umso schneller, je schneller die Zeilennr gefunden wird.
Für einmalige Sprünge a la Goto 60000 macht das nichts, aber der 1000fache Aufruf von Gosub 10 ist wesentlich schneller als der Aufruf von Gosub 40000, wenn davor 500 Programmzeilen stehen.
Ab der aktuellen Zeile funktioniert, wie gesagt nur, wenn die angesprungene Zeilennummer größer ist als die aktuelle, ansonsten wird ebenfalls von vorne gesucht, und das wird etwa 90% häufiger sein als eine Vorwärtsreferenz.
Zitat von Mike[...] bei Vorwärtssprüngen beginnt der Suchprozeß ab der aktuellen Zeile. DAS ist die eigentliche Optimierung!
Zitat von ZeroZeroWenn irgendwo im Programmcode ein Gosub XXXX steht, ermittelt der Interpreter ab BASIC-START die erste Zeilennummer und muss dann durch die ganze Verkettung die richtige Zeilennummer finden, immer von Anfang an. Das C64-Basic führt keine Zeilennr.-Adress-Tabelle.
Was ist an meiner Aussage oben eigentlich mißverständlich?
Bei Vorwärtssprüngen muß der Interpreter eben *nicht* ab Programmstart suchen, sondern kann den Suchprozeß ab der Zeile starten, in der der Sprungbefehl steht. Und das tut er auch.
ZitatAb der aktuellen Zeile funktioniert, wie gesagt nur, wenn die angesprungene Zeilennummer größer ist als die aktuelle, ansonsten wird ebenfalls von vorne gesucht, und das wird etwa 90% häufiger sein als eine Vorwärtsreferenz.
Na also. DU bist es, der sich hier gerade selbst widerspricht. Also doch nicht 'immer von Anfang an'. 
Und die 90% sind nur eine Hausnummer. Gerade bei einem größeren Programm kann es aus o.g. Grund durchaus Sinn machen, Unterprogramme nahe bei und *unter* ihrem hauptsächlichen Aufrufer zu plazieren.
Und die 90% sind nur eine Hausnummer. Gerade bei einem größeren Programm kann es aus o.g. Grund durchaus Sinn machen, Unterprogramme nahe bei und *unter* ihrem hauptsächlichen Aufrufer zu plazieren.
Ja, bei seltenen Aufrufen, ansonsten ab nach vorne damit. Denn auch der Teil, aus dem die Subs häufig aufgerufen werden, muss vom Interpreter erst mal gefunden werden.
Der Grund, warum ich so sehr auf Gosubs am Programmanfang insistiere, ist der, dass das Basic des C64 extrem rudimentär ist, zudem rein interpretiert ist und somit, gerade bei größeren Projekten und ohne detaillierte vorherige Planung, zu schlimmem Spaghetticode führt. Eine wirkliche Strukturierung ist nicht wirklich möglich.
Die wenigsten werden die Fähigkeiten und die Disziplin haben, Ihr Programm von vornherein (also noch in der Papierphase) manuell auf Sprungoptimierung auszurichten.
Es ist zwar möglich, da hat Mike völlig recht, aber einfacher und "on the safe side" ist es, häufig verwendete Subs nach vorne zu legen. Wenn man einen Profiler hat, dann in der Reihenfolge vom häufigsten gerufenen zum am wenigsten gerufenen.
Alles andere ist bereits extrem hohe Kunst.
!
