Hello, Guest the thread was called101k times and contains 1748 replays

last post from Hoogo at the

Neuer Retro-Computer im 8-Bit Style

  • RexRetro "In den Speicher gebeamten Maschinencode", sowas gabs schon in den 80ern??

    ;-)


    sparhawk Muß ja nit zwangsweise Multitasking sein. Für 8-Bit System reicht auch Taskswitching.

  • ZeHa: Danke für Deine Antwort. Ich will mal versuchen, auf ein paar Punkte einzugehen.

    PROGRAM am Anfang: Habe ich nie verstanden, was das soll bei Pascal. Auch das "END" am Schluss. Gibt es dafuer einen sinnvollen Grund? Wenn es nur drum geht, das Programm zu benennen, kann ich das auch ueber den Namen der Datei oder durch einen Kommentar-Header machen.

    Ja, es gibt einen Grund für die Schreibweise. Von Wirth war eigentlich vorgesehen, daß zusätzlich zum Programm auch die Ein- und Ausgabekanäle definiert werden. Vielleicht hast Du mal in älteren Pascalquellen folgendes gesehen:

    Code
    1. PROGRAM irgendwas(INPUT, OUTPUT);
    2. ...

    Dies bezog sich im wesentlichen auf die allerersten Großrechner, auf denen Pascal eingesetzt wurde (damals noch mit Druckerausgabe!) und ist bei den Homecomputern z. B. in USCD-Pascal und dem späteren Turbopascal weggelassen worden, da die Standardkanäle für Tastatur und Bildschirm implizit definiert wurden und immer vorhanden waren. Übrig geblieben ist dann die reine Namensdeklaration.


    Doch schon beim 1978 vorgestellten Modula 2, dem Nachfolger von Pascal, erfüllte die Namensnennung einen neuen Zweck, und anstelle von PROGRAM schreibt man seitdem MODULE. In dieser Sprache ist ein Programm nichts anderes als eine Art zuladbare Bibliothek, die auch von anderen Programmen benutzt werden kann. Der Programmierer kann bestimmen, welche Elemente seines Moduls (Variablen, Prozeduren etc) nach außen sichtbar sind (= public). Diese Elemente werden mit Hilfe von IMPORT in das eigene Programm integriert. wofür jedoch der konkrete Name des Moduls notwendig ist.


    In Oberon, dem Nachfolger von Modula 2, wird dies ähnlich gehandhabt, weshalb auch hier zu Beginn nicht das Schlüsselwort PROGRAM, sondern ebenfalls MODULE verwendet wird. Die von mir vorgeschlagene Sprache baut auf Oberon auf, so daß auch im Programmbeispiel eigentlich oben ein MODULE stehen müßte. Allerdings gehe ich nicht davon aus, daß man auf dem Zielrechner ein kompliziertes System einrichten kann, welches in der Lage ist, den Binärcode von verschiedenen Modulen zu laden und in Echtzeit zu linken. Da also diese Funktion fehlt, habe ich das alte Schlüsselwort PROGRAM verwendet. Möchte man aber ganz korrekt sein, müßte dort in der Tat MODULE stehen, auch wenn, wie gesagt, diese Modulfähigkeit auf dem Rechner wohl leider nicht umgesetzt werden kann.


    Zu diesem Modulkonzept gehört auch, daß man in einer Quelldatei mehrere Module schreiben und kompilieren kann. Es macht also durchaus Sinn, deutlich das Ende des Moduls zu kennzeichnen. Hinzukommt, daß auch Prozeduren in Oberon mit END und darauffolgend dem Prozedurnamen abgeschlossen werden, also z. B.

    Code
    1. PROCEDURE irgendwas;
    2. BEGIN
    3. END irgendwas;

    Dieses klare Ende des Unterprogramms sorgt dafür, daß sich Fehler im Programm (z. B. fehlendes END irgendwo) viel leichter finden lassen. Aus Erfahrung kann ich Dir sagen, daß dies sehr nützlich ist, wohingegen die Klammerung in C schon mal dazu führen kann, daß vom Compiler völlig wilde Fehler ausgespuckt werden und man selber auf die Suche gehen muß, ob und wenn ja wo da vielleicht eine schließende Klammer fehlt.

    Dieses Sicherheitskonzept zur Verifizierung der Korrektheit eines Programms existiert übrigens auch in der Sprache ADA, die vornehmlich unter dem Gesichtspunkt der maximalen Sicherheit entworfen wurde. Wenn ich es jedoch recht in Erinnerung habe, hat man da dieses Konzept noch viel weiter getrieben und für meinen Geschmack schon zu weit.

    Variablen deklarieren

    In einer Antwort auf Retrofan habe ich bereits darauf hingewiesen, daß es in Basic durchaus üblich ist, die hauptsächlich verwendeten Variablen zu Beginn des Programms zu nennen, dort auch Arrays zu dimensionieren und "konstante" Variablen wie z. B. einen Zeiger auf den VICII-Chip oder Soundchip zu deklarieren. Im Grunde genommen sind es nur die kleinen Basic-Programme, die darauf verzichten.


    Nun ist es aber auch nicht so, daß man eine Schleifenvariable oben zu Beginn definieren muß. Im Gegenteil. Um a) Speicher zu sparen und b) das Programm zu beschleunigen, sollte man Schleifenvariablen in der Prozedur definieren, in der sie auch verwendet werden, also nicht

    sondern

    Dies erzeugt sowohl im alten UCSD-Pascal als auch in Java kürzeren und schnelleren Code, da der p-Code der virtuellen Maschinen extra hierfür 1-Byte-Befehle enthält, um solche lokalen Variablen schnell zu laden.


    Desweiteren sollte eine Prozedur nicht zu lang sein (normalerweise sagt man eine Bildschirmseite), so daß der Abstand zwischen Deklaration und Gebrauch nicht sonderlich groß ist. Möchte man aber wirklich unbedingt nur an einer Stelle vorübergehend eine lokale Variable definieren, geht dies auch über die WITH-Anweisung. Diese erfüllt zwei Funktionen:

    1.) Erzeugen eines temporären Zeigers auf eine Variable, z. B.

    Code
    1. WITH z = meinarray[index].offset DO
    2.     z := 1234
    3. END

    2.) Deklaration einer temporären Variable mit einfachem Datentyp:

    Code
    1. WITH i : INTEGER DO
    2.     FOR i := 1 TO 100 DO
    3.     END
    4. END

    Der einfache Datentyp (Integer, Char, Boolean...) ist deswegen erforderlich, weil der ursprüngliche Einsatz dieser Kontruktion ist, den Wert der Variablen in einem Prozessorregister zu halten, d. h. er muß in das Register (16 oder 32 Bit) passen, und die Variable hat keine Adresse, kann also nicht als call-by-reference übergeben werden. Hiermit kann man auf bestimmten Systemen schnelleren Code erzeugen. (Ein optimierender Compiler wie gcc würde dies natürlich von sich aus erledigen, aber hier geht es ja nicht um einen Compiler für den PC mit Gigabyte-Speicher.)

    Semikolons

    Die Regeln für ein Semikolon sind ganz einfach: Ein Semikolon trennt verschiedene Anweisungen (statements) voneinander. Das ist anders als in C. In C bedeutet ein Semikolon das Ende einer Anweisung. Es ist somit fast genauso wie der Doppelpunkt in Basic mit dem Unterschied, daß es in Pascal etc kein automatisches Ende einer Anweisung gibt durch das Zeilenende. Da END oder UNTIL keine Anweisungen sind, braucht vorher auch kein Semikolon zu stehen. (Kann es aber, Ein überflüssiges Semikolon wird vom Compiler einfach stillschweigend überlesen.) Daher sind folgende Schreibweisen völlig identisch:

    Code
    1. IF a > b THEN
    2.     print('a > b')
    3. END;
    4. IF a > b THEN
    5. print('a > b');
    6. END;

    Achtung: In Pascal war dies anders. Dort gab es z. B. auch das Problem des dangling else. Wirth hat diese Unzulänglichkeit ab Modula 2 bewußt abgeschafft, indem auch IF-Anweisungen stets mit END beendet werden müssen. In Pascal konnte man schreiben

    Code
    1. FOR i := 1 TO 100 DO
    2.     IF (a > i) THEN
    3. IF (b > i) THEN
    4.      print(a);
    5. ELSE
    6. print(b);
    7.     print(i);    

    Auf den ersten Blick sieht es so aus, als würde die Anweisung "print(i)" 100 mal in der FOR-Schleife ausgegeben werden, jedoch wird diese bereits nach dem "print(b)" durch das Semikolon beendet. Außerdem bezieht sich das ELSE nicht auf den zweiten IF-Zweig "b > 1", sondern auf den ersten. In Oberon heißt es daher nun

    Code
    1. FOR i := 1 TO 100 DO
    2. IF (a > i) THEN
    3. IF (b > 1) THEN
    4. print(a)
    5.      END    //    Hier wird die letzte IF-Anweisung beendet
    6. ELSE //    dieses IF bezieht sich folglich auf das erste IF
    7. print(b)
    8. END // Hier endet die erste IF-Anweisung
    9.     END;    //    und hier die FOR-Anweisung
    10. print(i); // Das print ist damit klar außerhalb

    Die END-Schreibweise mag daher zunächst nervig erscheinen, aber sie hilft dabei, wichtige Fehler zu vemeiden.


    Auch sieht es wohl Im Vergleich zu C so aus, als wäre ein END umständlicher als eine schließende Klammer }. Aus Erfahrung kann ich Dir aber sagen, daß Du mit zunehmenden Alter froh bist, wenn Du solch klare Marker im Programm hast, an denen sich das Auge schnell orientieren kann. Wem ein END zu fett erscheint, kann es übrigens auch klein schreiben als "end", denn die Groß- und Kleinschreibung ist egal.

    Zuweisung vs. Vergleich: Mir ist bekannt, dass es in vielen Sprachen eine syntaktische Unterscheidung gibt zwischen einer Zuweisung und einem Vergleich, aber ich finde das in den seltensten Faellen relevant. Daher waere auch hier fuer mich die Frage, ob das fuer einen Anfaenger nicht zu verwirrend ist.

    Im Gegenteil. Auch hier kann ich Dir aus eigener Erfahrung sagen, daß für einen Anfänger ein "x := x + 1" wesentlich einleuchtender ist als ein "x = x + 1". Letzteres sieht nämlich viel zu sehr nach einer aus der Mathematik bekannten Gleichung und damit einer Gleichsetzung aus, wohingegen bei dem ';=' direkt deutlich wird, daß es sich um eine Zuweisung handelt.

    NEXT: Das was Du schreibst sollte aber dann nicht der Fall sein, wenn man explizit die Zaehlvariable mit angibt, oder?

    Doch. Betrachte folgenden Fall:

    Code
    1. 10    FOR i = 1 TO 10
    2. 20    GOTO 130
    3. 30    PRINT i
    4. 40    NEXT i
    5. 50    END
    6. 110   FOR i = 11 TO 20
    7. 120   GOTO 30
    8. 130   PRINT i * 2
    9. 140   NEXT i
    10. 150   GOTO 110

    Natürlich ist das ein extrem konstruiertes Beispiel, aber es ändert nichts daran, daß ein einfacher Compiler da nicht mitkommt und diesen Code entweder nicht vollständig oder fehlerhaft übersetzt. Und einen Compiler, der eventuell falsch übersetzt, möchten wir nicht haben.


    Wichtig: Im Unterschied zum END von Oberon (oder auch dem Semikolon bei C) ist das NEXT in Basic nicht das syntaktische Kennzeichen für das Ende der FOR-Schleife, sondern eine eigenständige. konkrete Anweisung für sich: Suche im Stapel nach einer Sprungadresse, die mit der Variablen I verknüpft ist und springe dahin. Dieses Verhalten ist aber laufzeitabhängig und kann daher nicht vom Compiler in ein paar (Prozessor-)Befehle übersetzt werden. In Pascal, C, Python usw. ist dies jerdoch möglich, da dort jede Schleife ein genau definiertes Ende hat, und END keine Anweisung ist.


    Erschwerend kommt in Basic noch hinzu, daß der Stapel durch ein RETURN teilweise gelöscht wird. Diese Eigenschaften von Basic sorgen dafür, daß Basic als Compilersprache nichts taugt. Es ist auch der Grund, warum Compiler wie der Basic Boss große Eingriffe in das Basic vornehmen (Zur FOR-Schleife gehört nur das folgende NEXT, Variablen werden deklariert und bekommen einen festen Datentypen usw.), um den Code vollständig übersetzen und in eine schnelle Form gießen zu können. Mit anderen Worten: Sobald es darum geht, aus Basic eine compilertaugliche Sprache zu machen, halten all die Elemente Einzug, die man von Pascal (oder anderen Hochsprachen) kennt.

    Namespaces

    Mathematische Funktionen wie trunc (= floor), round, sin, cos, log, sqrt usw. müssen nicht importiert oder mit einem zusätzlichen "math." gekennzeichnet werden, da sie fester Bestandteil der Sprache sind. Wie ich schon schrieb, existieren für solche Grundfunktionen die normalen Kurzformen.


    Bei den Namespaces gebe ich zu Bedenken, daß es nicht nur darum geht, die Namen sauber zu trennen, sondern auch das Konzept von private und public einzuführen. Eine Variable oder Prozedur in einer Library ist zunächst private und wird mit Hilfe von '*' nach außen sichtbar (= public).


    Außerdem sollen nicht nur die Bezeichner des Hauptprogramms von denen der Library getrennt werden, sondern auch die der Library von denen aus dem Hauptprogramm. Was sich etwas merkwürdig liest, meint in der Praxis, daß auch der Programmierer einer Library seine Bezeichner frei definieren kann, ohne daß er damit rechnen muß, daß seine Library plötzlich nicht mehr mit einem Programm X kompiliert werden kann, weil der Programmierer von X den gleichen Namen gebraucht hat. Stell Dir mal vor, der Entwickler einer Bibliothek möchte später ein Element (Variable, Prozedur...) in seiner Bibliothek ergänzen. Dann müßte er ja alle Programme, die andere basierend auf seiner Bibliothek geschrieben haben, daraufhin untersuchen, ob da irgendwer den neuen Namen vielleicht schon verwendet hat.


    Kurz: Namespaces sorgen dafür, daß verschiedene Programmierer ihre Bibliotheken untereinander austauschen können und man so auch im Team an einem Projekt arbeiten kann. Zusammen mit dem private-publicä-Konzept ist dies ein ganz wichtiger Bestandteil der Softwareentwicklung.

    aber mir ist bewusst, dass ein komplexeres Programm irgendwann "eklig" werden wuerde

    Ein Grundgedanke bei der Entwicklung eines Programmiersystems ist es ja, die Tools wie Editor, Assembler, Compiler usw. in der Zielsprache selbst zu schreiben und diese mit Hilfe des Compilers zu übersetzen (s. bootstrapping Compiler). Dafür braucht man eine Sprache, die mächtig genug ist und gleichzeitig leicht zu handhaben. Basic (insbesondere mit Zeilennummern) ist dafür nicht geeignet. Daß sowas möglich ist, haben übrigens die Macher des UCSD-Systems damals schon gezeigt. Editor, Assembler, Compiler etc waren allesamt in Pascal selbst geschrieben und vom Compiler übersetzt. Das mag sich kompliziert anhören, ist aber wohl tatsächlich der schnellste Weg hin zu einem System. Die Programmierung in Assembler dürfte deutlich länger dauern und mit vielen Fehlern im Programm gepflastert sein.

  • Ich habe bei vielen Posts hier das Gefühl, dass etlichen die Hardware vom C64 eigentlich reicht, aber es am Basic hapert. Warum nicht “einfach” eine neue Programmiersprache/Betriebsystem für den Cevi ?

    Eine neue Programmiersprache habe ich ja nun hier (und auch schon woanders) vorgestellt. Du kannst die Reaktion darauf gerne selber nachverfolgen.


    Außerdem bitte ich zu bedenken, daß man auf dem C64 selbst bestenfalls einen p-Code erzeugen könnte, der dann interpretiert wird. Das wäre zwar immer noch um ein Vielfaches schneller als Basic (auch der p-Code Übersetzungen z. B. vom Austrocompiler), aber ob es schon ausreicht, um damit Actionspiele mit mehreren Figuren zu erzeugen, wage ich zu bezweifeln. Wie schon oft dargelegt wurde, ist der 6502-Prozessor kein gutes Ziel für einen Compiler, da ihm z. B. Befehle zur Handhabung von 16 Bit-Werten, lokalen Variablen oder Parametern fehlen. Solch elementare Konzepte einer Hochsprache müssen umständlich und mit viel Code nachgebildet werden. Guckt man sich z. B. das Ergebnis des C-Compilers cc65 für den 6502 an, sieht man, daß der Code meilenweit von dem entfernt ist, was ein Assemblerprogrammierer schreiben würde sowohl bezüglich Geschwindigkeit als auch Codedichte. Und der läuft auf dem PC und nicht auf dem C64 selbst.

  • Dieses klare Ende des Unterprogramms

    Aber wer hat's erfunden? - RETURN.

    daß es in Basic durchaus üblich ist, die hauptsächlich verwendeten Variablen zu Beginn des Programms zu nennen, dort auch Arrays zu dimensionieren und "konstante" Variablen wie z. B. einen Zeiger auf den VICII-Chip oder Soundchip zu deklarieren. Im Grunde genommen sind es nur die kleinen Basic-Programme, die darauf verzichten.

    Ja, das dient bei größeren Programmen auch der Optimierung, insbesondere sollten alle Einzevariablen am Programmanfang initialisiert werden, weil eine später nach einem Array initialisierte Einzelvariable den Interpreter zu zeitraubenden Verschiebungen im Variablenspeicher veranlasst.


    Wenig bekannt ist, dass dies bequem in Kurzschreibweise möglich ist, indem Einzelvariablen einfach am Anfang dimensioniert werden. Richtig gelesen: DIM lässt sich auch auf Einzelvariablen anwenden mit der Folge, dass sie automatisch im Speicher mit Default-Wert angelegt werden. Also es muss statt i=0:j=0:x=0:y=0:a$="":b$="" ... lediglich geschrieben werden dim i,j,x,y,a$,b$ ...


    Zur Optimierung können zudem Arrays auch dann explizit dimensioniert werden, wenn sie absehbar weniger als den Default-Wert von 11 Elementen benötigen, um Speicherplatz zu sparen.

    Auch hier kann ich Dir aus eigener Erfahrung sagen, daß für einen Anfänger ein "x := x + 1" wesentlich einleuchtender ist als ein "x = x + 1". Letzteres sieht nämlich viel zu sehr nach einer aus der Mathematik bekannten Gleichung und damit einer Gleichsetzung aus

    Ja, aber jede gute Einführung weist darauf zur Vermeidung von Verwirrung frühzeitig hin, das C64-Handbuch auf Seite 37.


    Übrigens noch mal zum Thema "Wer hat's erfunden": Das ist nichts anderes als Operatoren-Überladung (andersartige Funktionsweise von Operatoren in speziellerem Kontext, hier Gleichheit und Zuweisung), was dann später etwa in C++ als große neue Errungenschaft gefeiert wurde.


    Ein anderes Beispiel dafür in BASIC ist der Operator "+" (Addition und String-Konkatenation). Die Überladung ist in beiden Fällen unproblematisch und intuitiv.

    Es ist auch der Grund, warum Compiler wie der Basic Boss große Eingriffe in das Basic vornehmen (Zur FOR-Schleife gehört nur das folgende NEXT, Variablen werden deklariert und bekommen einen festen Datentypen usw.), um den Code vollständig übersetzen und in eine schnelle Form gießen zu können.

    BASIC BOSS kompiliert auch ohne genaue Typ-Deklarationen, aber mit denselben effektiver. Das leuchtet auch unmittelbar ein, zum Beispiel können etwa reine Zählvariablen, die nicht größer werden als 255, als Typ "Byte" deklariert werden und brauchen dann auch nur ein Byte im Speicher. (Oder vielleicht gar keinen Speicherplatz, weil das Kompilat dann etwa bei Schleifen direkt ein schnelleres CPU-Register verwendet.)

    Außerdem bitte ich zu bedenken, daß man auf dem C64 selbst bestenfalls einen p-Code erzeugen könnte, der dann interpretiert wird. Das wäre zwar immer noch um ein Vielfaches schneller als Basic (auch der p-Code Übersetzungen z. B. vom Austrocompiler)

    BASIC BOSS erzeugt anders als Austro keinen Zwischencode, sondern sehr wohl (natürlich schnelleren) Maschinencode. Die Beschleunigung von BOSS-Kompilaten im Vergleich zum interpretierten BASIC soll ("nicht selten") bis zu 100-fach sein, das käme von der Größenordnung in die Nähe von handgeschriebenem Assembler (100-1000-fach).

  • Kein Multitasking.

    Multitasking in der Form wie es auf dem Amiga gibt, geht auf dem C64 genauso. ;) 64KB sind halt etwas knapp für mehrere tasks, aber technisch geht das problemlos.

    Es ging nicht um die prinzipielle technische Machbarkeit, sondern darum, dass der Amiga von Anfang an mit einem preemptiven Multitasking-System kam und andere SOHO Systeme 1985 bestenfalls rudimentäres und kooperatives Task-Switching kannten - zumindest bei den verbreiteten und mitgelieferten Betriebssystemen (sonst kommt hier wieder jemand sehr schlaues und erzält von dem MP/M und Unix-Clone für 8088/x86-DOSen von 1981-84).


    Bloß kam mit dem Multitasking-System beim Amiga natürlich doch viele Einschränkungen, was ein "systemkonformes Programm" tun und lassen darf. Da es keinen Speicherschutz und keinerlei Virtualsierung gab, war dieses Multitasking doch sehr wackelig, was dem Amiga auch den Ruf einbrachte, eine buggy Maschine zu sein, wo andauernd der "GURU" den Spaß beendet.

    Spieleentwickler hatten i.d.R. auch kein Interesse, dass ein Multitasking-System dauernd reinfunkt und die Spieleperformance drückt. Genauso wenig wollte man um jede Ressource beim System "betteln", sondern alles bis zum letzten Byte aus der Kiste rausholen. Waren ja Anfangs nur 256KB, dann 512KB und dann meist 512KB Chip + 512KB Slow RAM. Wollte man bis zum Rand mit Spieledaten füllen und die CPU und Grafikchip zu 100% ausnutzen. Und Interrupts nutzen wie man wollte, und es nicht dem System überlassen. Also wurde als erstes das System "ausgeschaltet". Ging ja. Und am Ende des Spiels kam der große Reset.


    Dumm halt nur, dass Leute irgendwann mit 32Bit CPUs und viel Speicher meinten, ihr Spiel solle von etwas anderem als Diskette laufen, und die ganzen HDD-Controller und später CD-ROMs hatten natürlich systemkonforme Treiber, die nicht mehr funktionierten, wenn man gleich zu Beginn des Spiels das System deaktiviert. Oder man wollte doch das eine kleine Spielchen laufen lassen, während im Hintergrund die Datenbank neu indiziert wird (mit niedrigerer Priorität versteht sich). Die 25MHz 68040er CPU hätte ja genug Power, das casual 68000er Spielchen zu wuppen und RAM war inzwischen auch von 1MB (A500) auf 18MB gewachsen (A4000) und nach dem Spiel will man keinen Reset, sondern dass es sich sauber beendet.

    Aber nix da. Entweder Spiel oder systemkonforme Anwendung. Ich habe mit dem A4000 kaum noch alte Spiele vom 500er gespielt.


    Aber da wir hier eine reine single-tasking Spielkiste ohne DBMS, DTP und (offline) Raytracing Ambitionen basteln, ohne optionale CD-ROM- und Drucker-Treiber, ohne CPU-Power und RAM für "ernsthafte" Anwendungen, können wir guten Gewissens die ganze Kiste übernehmen und nach herzenslust die Hardware abknutschen.

  • sparhawk Muß ja nit zwangsweise Multitasking sein. Für 8-Bit System reicht auch Taskswitching.

    Öhm... Das IST Multitasking. ;)

    Ich habe bei vielen Posts hier das Gefühl, dass etlichen die Hardware vom C64 eigentlich reicht, aber es am Basic hapert. Warum nicht “einfach” eine neue Programmiersprache/Betriebsystem für den Cevi ?

    Der C64 ist einfach zu langsam. Für gute Sachen kommst nicht an Assembler vorbei.

  • Die Beschleunigung von BOSS-Kompilaten im Vergleich zum interpretierten BASIC soll ("nicht selten") bis zu 100-fach sein, das käme von der Größenordnung in die Nähe von handgeschriebenem Assembler (100-1000-fach).

    Für gute Sachen kommst nicht an Assembler vorbei.

    Aber was soll ich mich beklagen, bei einem Selbstgespräch werde ich vom Gegenüber immerhin verstanden.

  • Also ich hab grad mal ein BASIC-Spiel von mir mit BasicBOSS kompiliert, und komme auf ca. doppelte Ausfuehrgeschwindigkeit. Das macht es durchaus spielbarer, aber Faktor 100-1000 ist das noch laengst nicht...

  • Die Beschleunigung von BOSS-Kompilaten im Vergleich zum interpretierten BASIC soll ("nicht selten") bis zu 100-fach sein, das käme von der Größenordnung in die Nähe von handgeschriebenem Assembler (100-1000-fach).

    Für gute Sachen kommst nicht an Assembler vorbei.

    "Die Beschleunigung von BOSS-Kompilaten im Vergleich zum interpretierten BASIC soll [!] ("nicht selten") [wie selten?] bis zu 100-fach sein [...]"


    Solche Aussagen von Compilerherstellern würde ich immer mit Vorsicht genießen und selbst austesten. Streng genommen ist auch ein Faktor 0.5 im Bereich "bis zu 100". Und zwischen 100x und 1000x ist auch eine Zehnerpotenz, die entscheiden kann, ob das Spiel mit 3fps oder 30 fps läuft.


    Die andere - rein praktische Frage - ist der Workflow bei der Entwicklung. Da möchte ich eine IDE und einen sehr schnellen Compiler und Testen und Debuggen ohne viel Hin- und Her.

    Z.B bot sowas TurboPascal ab Version 4 - auch auf 4,7MHz 8088 Gurken-DOSe. Etwas ähnlich komfortables auf C64 oder allgemein auf Rechnern mit 1MHz 6502 mit 64KB RAM halte ich für schwierig. Nicht umsonst haben Apple II User für Compiler den Rechner mit mehr RAM, 80 Zeichen-Karte oder gar Z80 Karte aufgerüstet.


    Ein C128 erscheint mir als komfortablere Entwickler-Platform für sowas wie TP4 da schon deutlich geeigneter als der C64 (C65/Mega65 sowieso).


    Und egal wie gut und schnell und komfortabel der Basic-Boss nun ist: er war 1982-88 nicht da und auch dann nicht das, was man bekam, wenn man seinen neuen C64 anschaltete.

  • Für gute Sachen kommst nicht an Assembler vorbei.

    Aber was soll ich mich beklagen, bei einem Selbstgespräch werde ich vom Gegenüber immerhin verstanden.

    Tja, wenn du lieber in einer Blase lebst, kann dir das keiner verbieten. Ausserhalb musst du halt Fakten akzeptieren. ;)


    Ein C128 erscheint mir als komfortablere Entwickler-Platform für sowas wie TP4 da schon deutlich geeigneter als der C64 (C65/Mega65 sowieso).

    Wenn der C128 reichen würde, warum dann nicht auch der MEGA65? Weil es da die Software nicht gibt?

  • Also ich hab grad mal ein BASIC-Spiel von mir mit BasicBOSS kompiliert, und komme auf ca. doppelte Ausfuehrgeschwindigkeit. Das macht es durchaus spielbarer, aber Faktor 100-1000 ist das noch laengst nicht...

    Compiler Hersteller prahlen seit Anbeginn der Zeit, dass ihre Compiler besseren und schnelleren Code erzeugen, als der Durchschnitt-Coder mit handgeschriebenem Assembler hinbekäme ;-)

    Für moderne, hochoptimierende Compiler-Monster wie icc, gcc und clang, sowie überfrachtete ISAs und OoO-CPUs mit komplexen Pipelines mag das zutreffen, für 6502 (und zeitgenössische Compiler auf jener CPU) glaube ich da nicht so recht dran.

    Und dann bedenke man, dass selbst Intel bei eigenen Libs wie MKL oder Embree nicht allein dem eigenen "hochoptimierenden, auto-vektorisierenden, profilierenden" Compiler traut, sondern Leute da die innersten Schleifen mit SSE/AVX Intrinsics von Hand tunen - pro Mikroarchitektur-Generation (wohl unter Zuhilfenahme von viel vtune Profiling).

  • Ein C128 erscheint mir als komfortablere Entwickler-Platform für sowas wie TP4 da schon deutlich geeigneter als der C64 (C65/Mega65 sowieso).

    Wenn der C128 reichen würde, warum dann nicht auch der MEGA65? Weil es da die Software nicht gibt?

    Sorry, da war meine Aussage missverständlich formuliert. Ich meinte der C128 sei dafür geeigneter als der C64 und C65/Mega65 seien ebenso wie der C128 geeigneter als der C64.

  • Compiler Hersteller prahlen seit Anbeginn der Zeit, dass ihre Compiler besseren und schnelleren Code erzeugen, als der Durchschnitt-Coder mit handgeschriebenem Assembler hinbekäme ;-)

    da muss es schon ein sehr schlechter ASM Programmierer sein. :) Es muss einem halt klar sein, dass ein Compiler ein generisches Tool ist. Wen ich meinen Code genau auf mein Problem zuschneiden kann dann wird das immer die schnellere Lösung sein. Deshalb kann ein generisches Tool nie besser sein als Handcoded. Wenn einem der Overhead egal ist, dann hat natürlich so ein Tool Vorteile, aber es kommt immer drauf an was man erreichen will.

  • Also ich hab grad mal ein BASIC-Spiel von mir mit BasicBOSS kompiliert, und komme auf ca. doppelte Ausfuehrgeschwindigkeit.

    Derselbe Quellcode oder an BOSS angepaßt?

    Nee ohne Anpassungen

  • Das macht es durchaus spielbarer, aber Faktor 100-1000 ist das noch laengst nicht...

    Du hast halt nicht den richtigen synthetischen Benchmark mit den genau dafür optimierten Compileroptionen verwendet ;)

  • Sicher sind Herstellerangeben das eine, aber auch in mehreren Testberichten schnitt BASIC BOSS als schnellster Compiler ab. Und für ein maximales Ergebnis bedarf es wie gesagt einiger Anpassungen wie genauer Typ-Deklarationen.


    Der Ansatz, das selbst zu testen, ist natürlich richtig, aber mich wunderte halt die Entschlossenheit, nicht mal die Möglichkeit zur Kenntnis zu nehmen.