Beiträge von BlackJack

    BladeRunner: Welches aufgeblähte Programm und welcher Dataschrott? Bei Zeichenketten kann man die DATA-Zeilen nicht so einfach löschen weil da die Inhalte der Zeichenketten drin sind auf die die Variablen verweisen, das sind also grösstenteils keine ”toten” Daten. Und bei Zahlen wurde ja schon gesagt dass das Laden aus einer SEQ-Datei besser ist.

    ThomBraxton: Man muss nach dem Laden die Zeiger auf den Anfang der Arrays (Speicherstellen 47 und 48) und das Ende des BASIC-Programms (Speicherstellen 45 und 46) korrekt auf die mitgespeicherten Variablendaten setzen. Wenn das *im* Programm am Anfang passieren soll, dann eventuell auch noch den Zeiger auf das Ende der Arrays (Speicherstellen 49 und 50) weil beim RUN ja ein NEW mit drin ist.

    BIF: Dann denk das mal schön weiter — für mich hast Du die Ankündigung nicht erfüllt. Ich will die Technik ja gar nicht schlecht reden, es ist halt bloss keine Beschleunigung von READ/DATA. Da Du ja selber gesagt hast die Daten könnten auch aus einer SEQ-Datei kommen, hättest Du genau so gut ankündigen können Du hättest eine Methode um das lesen aus SEQ-Dateien unglaublich zu beschleunigen. Das ist schlicht Unsinn.

    BIF: Ich habe schon verstanden was Du da vorschlägst, und das ist auch eine interessante Idee, es hat bloss nichts mit der vollmundigen Ankündigung zu tun READ/DATA unglaublich schnell zu machen weil es letztendlich damit gar nichts zu tun hat. Du schreibst ja jetzt selber das die Daten auch aus einer SEQ-Datei kommen können. Was ja an sich noch langsamer ist als READ/DATA.

    Wenn ich die Technik tatsächlich für ein BASIC-Programm umsetzen wollen würde, dann würde ich wahrscheinlich ein Programm schreiben was das ganze halbwegs generisch macht. Man könnte zum Beispiel die Initialisierung am Anfang des Programms mit READ und DATA machen und auch skalare Variablen mit Werten belegen und diesen Teil durch einen speziellen Kommentar trennen. So ein Programm kann man dann ganz normal verwenden und es entwickeln.

    Und dann könnte man ein Werkzeug schreiben welches den speziellen Kommentar durch ein STOP ersetzt, das Programm startet und nach dem STOP dann die Variablen geeignet vom Programmcode trennt, alles aus dem Programm bis zum STOP entfernt bzw. durch entsprechende POKEs ersetzt um die Variablengrenzen zu setzen und das Ergebnis speichert.

    Die Frage ist ob es nicht einfacher ist das Programm durch einen ordentlichen BASIC-Compiler zu jagen.

    BIF: Ja tatsächlich das READ wird nicht schneller. Mit numerischen Daten ”funktioniert” das natürlich auch, nur dass man da dann die ganzen dann unnützen Daten noch mal als Text im Speicher hat, denn die DATA-Zeilen sind ja noch da. Bei Zeichenketten mag der Mehrverbrauch ja noch durchgehen weil die Zeichen selbst verwendet werden und nur 0 oder 2 Bytes pro Zeichenkette plus die Bytes für Zeilennummern, Zeiger auf die nächste Zeile, DATA-Token und Nullbyte am Ende der Zeile dazu kommen, aber bei Zahlen ist das dann doch ziemlich verschwenderisch.

    BIF: Mit anderen Worten: Das READ der DATA-Werte wird überhaupt nicht beschleunigt, denn das läuft genau so langsam ab wie immer. Von der Einschränkung auf Zeichenkettenfelder hast Du vorher auch nichts erwähnt.

    Ansonsten eine nette Idee die man aber vielleicht besser ohne DATA-Zeilen macht in dem man sich ein Werkzeug bastelt das initialisiserte Variablen an ein BASIC-Programm anhängen kann. Das muss man ja nicht auf Zeichenkettenfelder beschränken.

    @gHost: Es ging nicht ums hergestellt werden sondern ums kaufen können. Vergleich mal Anzahl und Preise von C64 und SCPU auf dem Gebrauchtmarkt. Dann noch wie viele Besitzer es jeweils von beiden Geräten gibt. Da macht ein C64 als Ziel für neue Software mehr Sinn als für die SCPU. Wenn man selber so ein Gerät besitzt und Spass daran hat dafür zu entwickeln, bitte gerne, aber von Software für den C64 haben halt potentiell sehr viel mehr Leute etwas.

    Jetzt habe ich doch tatsächlich die Installationsdisketten für Turbo/Borland Pascal 7 rausgesucht, ein externes USB-Diskettenlaufwerk an den Laptop angeschlossen, und das in Dosbox installiert. :smile: So sieht die Compilerkonfiguration in der BP-IDE auf der frischen Installation aus:
    Bitte melde dich an, um diesen Anhang zu sehen.
    Entspricht den Defaulteinstellungen des Compilers, und die in der Turbo Pascal IDE sieht genau so aus, abzüglich der Optionen die es nur für „protected mode” und Windows gibt. Bereichsüberprüfung für Arrays und Zahlenwerte sind da standardmässig ausgestellt.

    Emacs oder vi? Emacs natürlich. :smile: (Oder den Borland Pascal Editor, oder Sublime Text)

    @Redsoft: Ich habe hier die Handbücher zu Turbo Pascal 7, also das letzte was ich unter DOS verwendet hatte. Den ganzen älteren Kram habe ich schon vor Jahren, moment: Jahrzehnten, entsorgt.

    Wenn Du die Laufzeitprüfungen im Quelltext angeschaltet hast, spricht das doch aber dafür, dass sie per Voreinstellung erst einmal aus waren.

    @Redsoft: Also die Standardeinstellung vom Compiler beim „range checking” beispielsweise ist *keines* zu machen, mit der Begründung dass es das Programm langsamer macht. Steht so, inklusive der Begründung im Handbuch („Language Guide”). Und Projekte gab es in der IDE auch nicht, also auch keine Einstellungen pro Projekt. Man konnte die Einstellungen für den Compiler in der IDE global für alle Dateien machen. Pragmas in den Dateien selbst hatten höhere Priorität.

    Wenn man auf Typsicherheit Wert legt, weil teure Hardware oder Menschenleben davon abhängen, dann *sollte* man vielleicht verschiedene Datentypen für Zoll und Zentimeter definieren (können). Die Prüfung vom Compiler ist doch trivial: Unterschiedlicher Typ bei Zuweisung oder Operationen die einen anderen Typ erwarten ist dann halt ein Fehler. Beispiel in D:


    Und der Compiler sagt dann:

    Code
    $ gdc-4.6 test.d
    test.d:9: Error: cannot implicitly convert expression (length) of type centimeters to inch


    Ada geht noch viel weiter, dort kann man nicht nur ”inkompatible” Typen definieren um das ungewollte vermischen zu verhindern, sondern es gibt ganze Bibliotheken die Typen und Operationen und Ergebnistypen definieren. Dann weiss der Compiler zum Beispiel das bei Masse mal Geschwindigkeit, etwas vom Typ Kraft heraus kommt und prüft zur Übersetzungszeit ob man da keinen Mist macht.

    @Redsoft: Raumsonden gehen eher verloren weil jemand Werte in Inch und Zentimetern vermischt, wo Sprachen wie Ada helfen können wenn man entsprechende Typen deklariert und benutzt und der Compiler merkt wenn man Inch verwendet wo Zentimeter erwartet wird. Die Laufzeitprüfungen helfen nicht so viel, denn wenn das Programm in einer Sonde mit einem Laufzeitfehler abbricht, hat man ja auch irgendwo verloren. :wink: Das sind Sachen die sollte man vor dem Start gefunden und beseitigt haben.

    Sind die Laufzeitprüfungen bei den Wirth'schen Sprachen Bestandteil der Sprachdefinitionen? Soweit ich das in Erinnerung habe musste man das meiste davon explizit anschalten. Wenn man diese Prüfungen immer benutzt hat ist das vielleicht nicht so aufgefallen, weil man das in Turbo Pascal einmal in der IDE in den Einstellungen angehakt hat, und dann für jedes Projekt die Einstellungen verwendet hat. Auf der anderen Seite kann man auch bei vielen C-Compilern zusätzliche Laufzeitprüfungen einschalten. Hat bloss damals bei DOS kaum jemand gemacht, weder bei C noch bei Pascal, weil ja immer alles möglichst klein und schnell sein "musste".

    Edit: Ich kenn auch kein Smartphone mit weniger Speicher als dem C64 aber das habe ich ja auch gar nicht behauptet. Ich spreche vom Internet der Dinge, also irgendwelche vernetzten Mikroprozessoren und Du antwortest ”darauf” mit dem Platz von Smartphones in der Rechnerlandschaft‽

    Wenn man bei C wirren Code in den Rechner eintippt, dann ist das kein Problem der Sprache, sondern von dem der tippt. Es macht sich in jeder Programmiersprache besser wenn man keinen wirren, sondern sinnvollen Code schreibt. :wink: Die Sprache selbst ist syntaktisch keine Schönheit, aber eine pragmatische Schicht knapp über Assembler, und damit halt deutlich portabler. Portabler Makro-Assembler sozusagen.

    Wenn man was Mobilgeräte angeht möglichst viel mit *einer* Sprache erschlagen will, dann wäre das wohl JavaScript, oder irgendwas was sich gut zu JavaScript kompilieren lässt. JavaScript-fähige Browser laufen auf mehr Systemen als die JVM. Inklusive Apple-Produkten und Desktoprechnern ohne das man extra die JVM installieren muss.