Hello, Guest the thread was viewed17k times and contains 249 replies

last post from Mike at the

Warum ist der BASIC V2 Interpreter so wie er ist ?

    Hallo Leute,

    Ich habe mir Anfang letztes Jahr einen TheC64 Maxi gekauft und so bin ich hier gelandet.

    Seit dem Lock down ist das eine schöne Beschäftigung und ein schwelgen in Erinnerungen.

    Da erstaunlich viel Literatur und Magazine (vor allem die 64er und deren Sonderhefte + Dickimage) als PDF und Download erhältlich sind, habe ich zunächst viel gelesen und ausprobiert.

    Auch mit dem BASIC und Compilern habe ich mich beschäftigt.

    Zu meiner Frage(n):

    Warum das BASIC V2 so langsam ist weiß ich nun, nur leider nicht wieso?

    War es nicht möglich andere Datentypen als Floating Point (der C64 INT ist ja auch nur ein FLOAT) zu nutzen?

    Muß eine Konstante im Code (z.B. POKE 646,5) erst als STRING gelesen und dann in eine FLOAT konvertiert werden, obwohl klar ist das einem POKE Befehl zwei Glanzzahlen folgen müssen?

    Oder ist die STRING Geschichte einfach der kleinste gemeinsame Nenner?

    Gibt es andere BASIC Dialekte für den C64, die es besser machen?

    Diese Fragen habe ich leider in keinem Buch behandelt gesehen und vielleicht könnt ihr mir helfen diese Wissenslücke zu schließen.


    Grüße hL

    Schwierige Fragen, wenn man nicht dabei war :)

    Im Nachgang ist es ja immer einfach, schlauer zu sein ;)


    Bei POKE müssen ja nicht zwei Ganzzahlen folgen, das können auch in Grenzen komplexe Berechnungen sein: POKECP+5*40,32+CH


    Wären es immer INTs, hätte man ganz schnell Probleme mit dem Grenzbereich (-32768 bis 32767 osÄ). Da scheint generell Floating Point die sinnvollere, weil vielfältiger verwendbare, Variante zu sein.


    Es ist ein Abwägen von notwendigem Speicherplatz und verfügbarer Funktion.

    Quote from HeisseLuft

    Warum das BASIC V2 so langsam ist weiß ich nun, nur leider nicht wieso?

    Den Satz musste ich zweimal lesen. ;) Afaik hat Commodore das BASIC, das ja von MS lizensiert war (dazu gibt's 'ne haarsträubende Geschichte, wie Jack Tramiel dem jungen Bill Gates die Bude eingerannt hat) selber modifiziert und es musste beim C64 einiges schnell gehen, nachdem der VC20 ein so großer Erfolg geworden war. Da hat man wohl einiges mit heißer Nadel gestrickt. Das BASIC V2 hat ja einige Macken (z.B. die Garbage Collection). Das hier ist vielleicht interessant.

    Quote from HeisseLuft

    Gibt es andere BASIC Dialekte für den C64, die es besser machen?

    Ja. Z.B. Simons' BASIC. Guck mal hier und hier!

    Hi Endurion und Telespielator,


    das mit den Berechnungen im POKE Befehl ist nachvollziehbar.

    Das BASIC V2 kam wohl auch so beim VIC20 zum Einsatz und bis bis zur 16KB hätte es da ja ein „richtiger INT“ getan.


    Simons BASIC kenne ich. Damit habe ich in meiner Jugend einiges programmiert.

    (btw. Ich habe wenig bis keine Listings dazu gefunden, wisst ihr Links dazu?)


    Aber ich habe gelesen das Simons BASIC auch recht langsam ist und keine erweiterten Variablen Typen bietet.


    Gibt es BASIC Erweiterungen wo das der Fall ist?


    Ich habe 1989 aufgehört mich mit dem C64 zu beschäftigen und war jetzt erfreut, zahlreiche Compiler zu finden, in deren Beschreibung stand, das sie auch Simons BASIC Programme compilieren können. Na ja , nur um in den entsprechenden Kapitel dann zu erfahren, das dies nur unter großen Einschränkungen möglich ist und gemeindlich keinen Sinn macht.


    Gibt es eine BASIC Erweiterung die andere Datentypen anbietet (vor allem WORD (0-65536)?


    Grüße hL

    Sorry SC,


    hatte dich noch nicht gesehen.

    Hi SC

    ah ich glaube ich habe es noch nicht richtig formuliert:

    Gibt es eine BASIC Erweiterung, bei der nicht nur ein erweiterter Befehlssatz geboten wird, sondern auch eine signifikant schnellere Abarbeitung des Codes?

    Hallo OG,


    genau mit dem Compiler experimentiere ich zur Zeit.

    Daher habe ich mich gefragt, wenn schon so ein enormer Geschwindigkeitswachs , nur durch die Verwendung alternativer Datentypen möglich ist (ohne Cmpileranweisungen wie „fastfor“ etc. ) , warum finde ich keine BASIC Erweiterungen die dies anbieten?

    Quote from HeisseLuft

    War es nicht möglich andere Datentypen als Floating Point (der C64 INT ist ja auch nur ein FLOAT) zu nutzen?

    Dann müssten alle Rechenroutinen sowohl als FP- als auch als INT-Variante existieren. Das ist natürlich blöd, wenn man auf den Speicherverbrauch des Interpreters achten muss, zumal die Behandlung von FP einen nicht unerheblichen Teil des ROMs in Anspruch nimmt. Wenn man sich dann noch vor Augen führt, dass die MS Basic-Variante, von der Commodore absprang, sogar Optionen für die FP-Genauigkeit (9 Digits, 40 bit, vs. 6 Digits, 32 bit, einschließlich verkürzten BASIC-Fehlermeldungen) hatte (https://www.pagetable.com/?p=46), sowie sin-cos-tan weglassen konnte, beides, um Speicher zu sparen, dann weiß man, was damals Priorität hatte.

    Der Hauptgrund war wohl, daß man den C64 nicht mit einem größeren ROM verteuern wollte.

    Allerdings erklärt das nicht, wieso keines der Nachfolgerechner, die zum Teil ein erheblich erweitertes BASIC und auch wesentlich mehr ROM hatten, nicht mal dahingehend optimiert wurden.


    Ein richtig gut optimiertes BASIC ist GFA-BASIC, aber das gibt es leider nicht auf dem C64. Auf Amiga und PC konnte es Amiga-BASIC bzw. QBASIC um ein Vielfaches abhängen. Da sieht man, daß nicht nur Commodore da nie optimiert hatte, sondern auch Microsoft da überhaupt kein Interesse zeigte.

    Microsoft BASIC ist in erster Linie eine Implementierung von BASIC gewesen. Und BASIC, so wie seine Erfinder es eigentlich entworfen haben, kennt keine anderen Datentypen als String und Float. Das wurde gemacht, weil es a) verhinderte, dass sich unerfahrene Programmierer mit Datentypen rumärgern mussten und b) weil BASIC als Lernsprache für ein universitäres Umfeld gedacht war und da wurde eben viel und genau gerechnet, weswegen Gleitkommazahlen sinnvoller waren. Der ganze Integermurks wurde nur von MS drangefummelt, weil man damit in Arrays Speicher sparen wollte. Um Geschwindigkeit ging es da gar nicht.

    Quote from LogicDeLuxe

    Microsoft da überhaupt kein Interesse zeigte.

    ...warum auch? Die haben ihren Kram ja auch so verkauft bekommen und hatten da schon andere Projekte auf dem Tisch...

    Für viele Sachen ist ist die Geschwindigkeit von Basic durchaus ausreichend.

    Auch für Spiele.

    Aber natürlich sind auch in Basic verschiedene Lösungsansätze bei der Problemlösung möglich, die auch Geschwindigkeitsmäßig unterschiedlich ausfallen.
    Oder im Klartext blitzschnell oder ziemlich langsam hängt auch davon ab, wie man es macht.


    Schönen Gruß.

    Quote from EgonOlsen71

    Microsoft BASIC ist in erster Linie eine Implementierung von BASIC gewesen. Und BASIC, so wie seine Erfinder es eigentlich entworfen haben, kennt keine anderen Datentypen als String und Float. Das wurde gemacht, weil es a) verhinderte, dass sich unerfahrene Programmierer mit Datentypen rumärgern mussten und b) weil BASIC als Lernsprache für ein universitäres Umfeld gedacht war und da wurde eben viel und genau gerechnet, weswegen Gleitkommazahlen sinnvoller waren. Der ganze Integermurks wurde nur von MS drangefummelt, weil man damit in Arrays Speicher sparen wollte. Um Geschwindigkeit ging es da gar nicht.

    Naja nicht ganz. Auch beim Microsoft-BASIC war in den Anfängen Floating-Point eine Option, wenn ich mich recht erinnere (an diverse Seiten zur BASIC-Interpreter-Historie).

    Es gab auch ausgesprochene Varianten von BASIC, die nur Integer-Arithmetik hatten, so wie Apples Integer-BASIC. Aber auch in sehr reduzierten Umgebungen, wo der Platz für einen Interpreter limitiert war, gab es immer wieder BASIC-Varianten, die sich auf Integer beschränkten. Aber das war dann üblicherweise ein Entweder-oder.

    Quote from HeisseLuft

    Hallo OG,


    genau mit dem Compiler experimentiere ich zur Zeit.

    Daher habe ich mich gefragt, wenn schon so ein enormer Geschwindigkeitswachs , nur durch die Verwendung alternativer Datentypen möglich ist (ohne Cmpileranweisungen wie „fastfor“ etc. ) , warum finde ich keine BASIC Erweiterungen die dies anbieten?

    Das BBC-Micro-BASIC ist in etlichen Aspekten flotter. Ich bin mir jetzt nicht sicher, ob dort tatsächlich eine Integerarithmetik implementiert ist, aber es gibt den Integer-Datentyp und zumindest bei FOR-NEXT wird damit wirklich als Integer gerechnet.

    Einbuchstabige Variablen werden über eine Tabelle schnell gefunden. Witzig ist auch, dass man Inline-Assembler-Code verwenden kann (wie man es etwa auch von C her kennt). Lediglich bei Strings hapert's, da es keine Garbage-Collection gibt (nicht mal eine schlechte) und daher gibt's da auch entsprechende Probleme bzw. man muss sich darüber mehr den Kopf zerbrechen, als einem lieb ist.


    Wie schon in anderen Posts angedeutet, ist eine Erweiterung zum bestehenden BASIC konzeptionell an den Kerninterpreter angelehnt. Wenn man das (mehr oder weniger) alles wegwirft, hat man gleich einen komplett neuen Interpreter. Eine Erweiterung, die so fundamental in die Strukturen eingreift, ist dann eigentlich auch keine "Erweiterung" mehr, sondern ein faktisch komplett neuer Interpreter. Das macht man vielleicht am Anfang, wenn man noch nichts hat und neu entwickeln muss, nicht aber wenn man eine Interpreterkern hat, der schon eine Historie der Produktpalette etabliert ist.


    Ich kann mich aber immer wieder (vage) an Listings oder Anwendung des Monats etc. erinnern, die sich zur Aufgabe gemacht haben, gewisse Aspekte des Interpreters zu verbessern, wie etwa schnelle Variablen, eine flotte Garbage-Collection, usw. Die GC ab BASIC 3.5 bei C16 und Konsorten und dann BASIC 7.0 beim C128 in der Implementierung von BASIC 4.0 ist meines Wissens auch die einzige strukturelle bzw. tiefergehende Änderung im Kern des Interpreters, mal abgesehen von diversen Behebungen in der Float-Arithmetik.


    Außerdem muss man sagen, dass Commodore von sich aus, speziell im Druck der Entwicklung, sich nicht getraut hat, einen so massiven Sprung zu wagen, etwa bei C128, wo man massenhaft mehr ROM-Speicher hatte. Da war es wichtiger, entsprechende Befehle zu ergänzen, um die Hardware (Sound, Grafik) halbwegs vernünftig in BASIC beherrschen zu können. Schon alleine das bedingt eine entsprechende "Beschleunigung". Dieser Weg war für Commodore sicher weniger risikobehaftet.

    Quote from JeeK

    Es gab auch ausgesprochene Varianten von BASIC, die nur Integer-Arithmetik hatten, so wie Apples Integer-BASIC.

    Ja, schon. Aber das war eben nie die Idee oder das Ziel hinter BASIC als Programmiersprache. Die Idee war, einen(!) Datentyp für Zahlen zu haben, mit dem man vernünftig rechnen kann und das man sich keine Gedanken um dessen Einschränkungen oder nötige Konvertierungen machen muss. Klar, das klappt auch mit Gleitkommazahlen nicht vollständig, weil die Genauigkeit begrenzt ist. Es war nie das Ziel, die maximale Leistung aus dem Rechner herausholen zu können damit.

    Dieselbe Situation findet man heute auch: Wieso gibt es Sprachen wie Python, die üblicherweise interpretiert und nicht besonders schnell ausgeführt werden? Weil es für viele Dinge schnell genug ist und die Vorteile, zumindest aus Sicht der Erfinder und Nutzer, größer sind als die Nachteile. Und so war auch BASIC gedacht. Weil dann aber jeder Hersteller unkontrolliert seine eigene Suppe gekocht hat, haben wir jetzt alle möglichen Zwischenformen und Bastardierungen. Die BASIC-Erfinder haben dann ja nochmal versucht, mit TRUE BASIC gegenzusteuern, aber das hat nichts mehr geholfen, die Katze war aus dem Sack.


    Quote

    Ich bin mir jetzt nicht sicher, ob dort tatsächlich eine Integerarithmetik implementiert ist, aber es gibt den Integer-Datentyp und zumindest bei FOR-NEXT wird damit wirklich als Integer gerechnet.

    Angeblich schon. Allerdings sind die Integerwerte beim BBC BASIC 32 Bit-Werte.

  • androSID

    Changed the title of the thread from “Warum ist der BASIC V2 Interpreter so wie ist ?” to “Warum ist der BASIC V2 Interpreter so wie er ist ?”.
    Quote from Telespielator
    Quote from HeisseLuft

    Warum das BASIC V2 so langsam ist weiß ich nun, nur leider nicht wieso?

    Den Satz musste ich zweimal lesen. ;) Afaik hat Commodore das BASIC, das ja von MS lizensiert war (dazu gibt's 'ne haarsträubende Geschichte, wie Jack Tramiel dem jungen Bill Gates die Bude eingerannt hat) selber modifiziert und es musste beim C64 einiges schnell gehen, nachdem der VC20 ein so großer Erfolg geworden war. Da hat man wohl einiges mit heißer Nadel gestrickt. Das BASIC V2 hat ja einige Macken (z.B. die Garbage Collection).

    Das Basic stammt vom PET 2001 und hat sich von dort über die CBM-Reihe und den VC20 zum C64 kaum verändert. Es wurden lediglich von Basic 1 nach Basic 2 einige grobe Fehler bereinigt.

    Zu Zeiten des PET waren ROMs teuer und man wollte billiger sein als die Mitbewerber (z.B, Apple). Das war für den Verkaufserfolg wichtiger als ein besseres Basic.

    Außerdem war nicht viel Zeit, weil man vor dem Apple II auf dem Markt sein wollte. Das wurde auch geschafft, es ging dabei um wenige Monate. Da war auch keine Zeit für ein ausgreifteres Basic.


    Warum das Basic für den C64 nicht überarbeitet wurde, kann ich nicht sagen, aber vermutlich ging es auch da wieder um Geld und Zeit.

    Und viele Computer mit einem tollen Basic waren längst nicht so erfolgreich wie der C64. Also hat Commodore doch alles richtig gemacht.

    Quote from EgonOlsen71

    Microsoft BASIC ist in erster Linie eine Implementierung von BASIC gewesen. Und BASIC, so wie seine Erfinder es eigentlich entworfen haben, kennt keine anderen Datentypen als String und Float. Das wurde gemacht, weil es a) verhinderte, dass sich unerfahrene Programmierer mit Datentypen rumärgern mussten und b) weil BASIC als Lernsprache für ein universitäres Umfeld gedacht war und da wurde eben viel und genau gerechnet, weswegen Gleitkommazahlen sinnvoller waren. Der ganze Integermurks wurde nur von MS drangefummelt, weil man damit in Arrays Speicher sparen wollte. Um Geschwindigkeit ging es da gar nicht.

    Die Integer-Implementierung von Commodore-Basic ist sogar langsamer als die Fließkommarithmetik. Denn das Basic beherrscht keine Integerarithmetik. Aller Integerwerte müssen zum Rechnern erstmal nach Fließkomma konvertiert werden - und dann wieder zurück.


    Es ging also tatsächlich nur darum, Speicherplatz zu sparen.

    Quote from detlef

    Außerdem war nicht viel Zeit, weil man vor dem Apple II auf dem Markt sein wollte.

    Mit welchem Rechner meinst Du jetzt? Der einzige, der vor dem Apple II auf dem Markt war, war ja der PET 2001, der das ursprüngliche von MS übernommene BASIC beinhaltete.

    Quote from Telespielator
    Quote from detlef

    Außerdem war nicht viel Zeit, weil man vor dem Apple II auf dem Markt sein wollte.

    Mit welchem Rechner meinst Du jetzt? Der einzige, der vor dem Apple II auf dem Markt war, war ja der PET 2001, der das ursprüngliche von MS übernommene BASIC beinhaltete.

    Genau, Und der hat (im Prinzip) das gleiche Basic wie der C64. Da hat sich kaum was verändert. Deswegen gibt's auch keine Grafikbefehle. Die hatte der PET nämlich auch nicht. ;)