Posts by 1570

    Man will wirklich, wirklich Prozeduren mit Parametern, lokalen Variablen und Rückgabewerten haben. In BASIC V2 bekommt man so wie's ist ja nichtmal die Funktionalität eines Sets hin (Liste von Werten inkl. Funktion, die einem sagt, ob Wert X in der Liste ist), ohne dass man den Code dafür für jedes Set neu schreiben muss (weil der Code jeweils "hart" für das jeweilige Array geschrieben werden muss). Das ist schon übel.

    Und Sachen wie die Datentypen Byte/Word will man auch haben (inkl. Shift-Operationen etc.), weil der Code sonst sehr ineffizient wird, speziell auf 8 Bit.

    Alle alten Compiler unterstützen 16-Bit-Integer-Arithmetik, also die "falsche" Semantik. Gestört hat sich niemand dran.


    BASIC V2 selbst ist halt auch nur ein Hack, dann muss man auch nicht päpstlicher als der Papst sein.

    Naja, die ganzen theoretischen Erklärungen haben auch andere Themen wie z.B. Entscheidbarkeit ((Wann) kann man mit einer Grammatik entscheiden, ob ein gegebenes Programm der Grammatik entspricht? Welche Grammatiken sind überhaupt entscheidbar? Und so weiter), wofür man das entsprechende theoretische Handwerkszeug braucht (und die zitierten "Formeln" nunmal die ersten Schritte davon sind), während die grafischen Grammatiken nunmal konkrete Grammatiken sind. Insofern ist das nicht das Gleiche, hat aber natürlich aufeinander Bezug.


    Wenn man sich dann antlr o.ä. nimmt und was damit baut, braucht man klarerweise nicht den ganzen theoretischen Unterbau, weil genau dieses "Korsett" schon von antlr geliefert wird. Aber Studenten (an die sich Wirth wohl wendet) sollen ja nicht reine Programmierer werden.

    Der Compiler müßte in Zeile 100 einen Fehler ausspucken, da auf ein Element 50 zugegriffen werden soll, jedoch im späteren Programmcode nur ein Feld mit 41 Elementen erzeugt wird.

    In der Praxis wird der Compiler bei BASIC Zugriffe und Definitionen von Arrays (DIMs) auf interne dynamische Speicherverwaltung umbiegen, also aus z.B. A(10)=5 intern ein (Pseudocode) arraySet("A",10,5) machen müssen, wobei arraySet() dann auch die Array-Grenzen (zur Laufzeit) überprüft. Um so eine Runtime kommt man bei BASIC eh nicht drumherum, da man ähnliches für die Strings braucht. Zur Kompilierzeit passiert da erstmal recht wenig. Deswegen baut z.B. Blitz! auch in das Kompilat zwar einen Bereich mit vorinitialisierten einfachen Variablen ein, aber einen vorinitialisierten Bereich für Arrays gibt es im Kompilat/PRG nicht.


    Statische Arrays bringen also einen (etwas) einfacheren Compiler, (etwas) einfacherer Runtime und ein (etwas) schnelleren Code (da sich das Kompilat ein paar Lookups und Checks zur Dimensionierung des Arrays sparen kann), aber letztendlich macht's in Sachen Komplexität des Compilers den Braten nicht wirklich fett.

    Oder es ist jemand, der nicht so tief in der Materie drinsteckt, hier im Forum seine Vermutung schreibt und dann von denen, die sich damit besser auskennen, aufgeklärt wird. ;)

    Der Witz ist ja, dass man an der Stelle gar keine Ahnung zu haben braucht, sondern man muss nur richtig beobachten (können). Ist doch nicht so schwer, auf zwei Plattformen wirklich das Gleiche zu machen (und vielleicht auch etwas links und rechts zu schauen) und das dann zu bewerten. Mit Kenntnissen der inneren Funktion von RND hat das erstmal überhaupt nichts zu tun.


    Um mal einen Vergleich zu machen: Bei jemandem, der ernsthaft behauptet, dass abends die Ampeln in seinem Stadtteil alle immer rot sind, liegt das Problem auch nicht im Unverständnis der technischen Funktionsweise von Ampeln.


    Wirklich https://de.wikipedia.org/wiki/Liste_kognitiver_Verzerrungen lesen! Wer das getan hat, geht abends wirklich klüger ins Bett. :)

    Aber dass prinzipiell ein Emulator durch Fehler andere Ergebnisse als ein echter Rechner liefern kann, steht hoffentlich außer Frage. ;)

    Darum ging's hier aber nicht, es wurde VICE unter Linux und VICE unter Windows erwähnt.


    Wer dort dann einen Unterschied in der RND-Sache sieht, sollte sich mal die Liste kognitiver Verzerrungen zu Gemüte führen und sich echt Gedanken über die eigene Wahrnehmung machen.

    RND(negativeZahl) ist nur eine Art (richtig schlechter) Hash der Zahl.


    Nehmt doch einfach mal das Programm hier:

    Code
    1. 10 ti$="000000"
    2. 20 printti,rnd(-ti)
    3. 30 goto20

    ...da sieht man dann auch den Input für RND.


    VICE 3.5 unter Linux liefert da bei mir auch die "Zufallszahlen", die man da erwartet.


    RND ist halt richtig schlecht, z.B. für den Input von ca. -60 bis -130 bekommt man tatsächlich einfach aufsteigende Zahlen als Ergebnis, danach wird's aber wieder ein klein wenig besser.


    (ich war erst etwas erstaunt, dass die Zahlen nicht Duplikate haben, aber tatsächlich braucht jede Zeile länger als 1/60tel Sekunde, sodass sich TI von Zeile zu Zeile ändert - boah ist BASIC V2 langsam)


    Und das ist unter Windows und Linux natürlich identisch, und auch die Version von VICE spielt keine Rolle. Ihr müsst glaube ich mal etwas mehr überlegen, wie ein Emulator funktioniert. ;)

    Ja, klar...kann man alles machen. Für meinen konkreten Fall sehe ich die Notwendigkeit da aber nicht. Ich habe eine "Testsuite" für MOSpeed, die ich einmal durchkompiliere und dann im Schnelldurchlauf teste. Das meiste davon sind Spiele, die muss man anschauen, um Macken zu finden.

    Die kann man auf Autoplay umbauen (einfach die Tastatureingaben durch RND(1) ersetzen und entsprechend Seeden) und dann an Checkpoints (z.B. per POKE65535,0 getriggert und in VICE per watch store ffff abgefangen) die Bildschirmausgabe überprüfen, habe ich bei Gold Quest ansatzweise so gemacht, da aber eher im Kontext von Benchmarks. :)

    Danke für die Antwort! Korrektheit z.B. des Apfelmännchens kann man per Checksumme über die Ausgabe prüfen. Bei einem "Fail" muss es ja nicht unbedingt genauere Hinweise auf das "Warum" geben.

    Bisschen blöd sind natürlich Tests auf Fehlerbehandlung (z.B. POKE99999,0 muss Fehler werfen). Hm.

    Naja BIF hat aber offensichtlich Spaß an sowas. ;)


    Man kann auch die Time of Day-Funktion der CIAs benutzen. Vorteil: Funktioniert auch ohne IRQs bzw. ist im Zusammenhang mit Diskettenzugriffen etc. genauer. Nachteil: Nur 1/10tel Sekunde Genauigkeit, etwas seltsam anzusprechen wegen BCD und auf machen Geräten (C64DTV...) nicht verfügbar.

    Excelsheet erzeugen - Kopfdaten - Inhalt - Excel speichern... Das ist alles im Prinzip selbst erklärend. Aber es hilft bei der Orientierung ungemein, weil man nicht den ganzen Quelltext lesen und verstehen muss, sondern nur die paar Kommentarzeilen, um die passende Stelle zu finden.

    Das wäre allerdings auch genau etwas, bei dem Martin sagen würde, dass die Strukturierung durch Einteilen in Funktionen passieren sollte und Kommentare schlecht sind.

    Kann man aber meiner Meinung nach immer noch drüber streiten: Werden solche linearen Prozesse in Funktionen aufgebrochen (die aber jeweils nur von einer einzigen Stelle aus angesprungen werden), wird der eigentlich lineare Ablauf vermeintlich nichtlinear und der Betrachter des Codes ggf. verwirrt (wird die Funktion jetzt noch von woanders aufgerufen oder nicht?); die Sache wird unnötig kompliziert (Parameterübergabe nötig); es liest sich einfach schlechter (da Umherspringen im Code nötig).

    Speziell mit Syntaxhighlighting sehen vernünftige Inline-Kommentare häufig besser aus und sind übersichtlicher - ganz wie Du sagst.

    Mattes Filament würde bei den Seitenwänden auch helfen (plus evtl. die Z-Achse etwas stabilisieren? Sieht aber schon ganz gut aus so), aber wird's in der Farbe vermutlich nicht als Matt geben.


    Ansonsten ist der Standard wohl Grundieren+Lackieren...