Hallo Besucher, der Thread wurde 9,9k mal aufgerufen und enthält 37 Antworten

letzter Beitrag von BlackJack am

Neue Programmiersprachen für Commodore-Homecomputer?

    Zitat von mc71

    Bitte definiere das als Jahreszahl. Darf die Sprache schon vorher auf den 64er umgesetzt worden sein? Zählen auch neue Versionen vorher für den 64er existenter Software?


    Im Prinzip geht es mir darum: Ich suche Sprachen, die für den C64 entwickelt oder adaptiert wurden, obwohl es dafür bereits geeignetere Plattformen gab. (Compiler-Sprachen mit Linkern und Bibliotheken lassen sich wesentlich angenehmer auf Rechnern mit Festplatten verwenden z.B.)


    Die Frage dahinter ist, wie neuere Erkenntnisse und Erfahrungen im Compilerbau auf solch eine alte Plattform übertragen und auf ihr realisiert werden. Deshalb ist wäre zum Beispiel so etwas wie C# interessant. Aber eben auch Compiler für ältere Sprachen, die nach neueren Techniken gebaut werden.


    Ich schaue mir gerade ein paar jüngere FORTH-Interpreter an; die sind aber ziemlich konventionell entwickelt (also so, wie man Forth auch schon in den 80ern für Homecomputer entwickelt hat).

    Zitat von Microprofessor


    Ich schaue mir gerade ein paar jüngere FORTH-Interpreter an; die sind aber ziemlich konventionell entwickelt (also so, wie man Forth auch schon in den 80ern für Homecomputer entwickelt hat).


    Mehr wird auf einem Homecomputer der 80er wegen der knappen Ressourcen und Rechenleistung auch wohl kaum gehen. Neuere Programmiersprachen verwenden jede Menge Zeiger und Strukturen, Bibliotheken, usw. die du auf den C-64 deswegen einfach nicht umsetzen kannst. Schau dir mal an, wie groß auf modernen Rechnern ein einfaches "Hello-World" in Hochsprache nach dem Kompilieren, Linken usw. wird, da reichen mitunter für sowas simples die 64K nicht mehr! Basic (mit Abwandlungen wie Exbasic Level II, Simons Basic), Assembler, Logo, einfaches Pascal, Forth 86, meinetwegen auch noch Ansi-C, viel mehr macht auf dem C-64 einfach keinen Sinn! Wer für den C-64 programmieren will, solte hier seine Auswahl treffen, wer in einer anderen Sprache programmieren will, soll sich ne leistungsfähigere! Plattform suchen.


    Übrigens, "Brainfuck" als eine ernsthafte Programmiersprache zu bezeichnen, das ist ja auch schon Wahnsinn...!


    So, und jetzt ab nach Hanau!

    +1


    Vielleicht ist es auch so daß, wenn man schon jahrelang auf einer komfortableren Plattform programmiert hat, und wieder zu 8-Bit-Rechnern 'zurückkehrt', möglicherweise etwas den Bodenkontakt verloren hat und sich denkt, solche Programmierumgebungen müßten doch eigentlich auch auf den alten Rechnern möglich sein.


    Im Denial-Forum hatte ich da mal mit einem eine recht prototypische Diskussion in der Richtung - er wollte eine objektorientierte Sprache auf dem VC-20 realisieren ... hier der Abschnitt im Original:


    Zitat von Mike

    Yet another Quetzalcoatl or Tiny Basic Compiler? This time even proposed to be hosted on the VIC-20 itself and also doing compiles-on-the-fly?


    In any case, such a language would have to provide good support for modern control flow structures, 32-bit values, strings and float values. Otherwise this isn't going to gain an edge over hybrid BASIC + ML programs.


    Zitat von FD22

    I'd say it was more akin to TBC than Quetzalcoatl, since it's not intended to do cross-compilation - it is, as you affirm from my earlier post, a native VIC-20-hosted dynamic compiler. And my intention isn't to create 'yet another' VIC-20 product - my opening post in the blog explains clearly that this is actually a project intended for a custom homebrew machine, but using the VIC as a software/concept design host. Which is why I didn't post about it here, except to ask the 656x question, until an interest was expressed - it's VIC Jim, but not as we know it.


    And yes, the language design is already far enough along to support modern control flow structures (without, incidentally, any risk of stack-overflow), 8/16/32/64-bit integer and float, signed and unsigned numerics, strings limited only by memory size, arrays, jagged arrays, associative sets, hash tables, indexed and keyed dictionary structures, and strongly-typed primitives including Bit/Byte/Word/Long/Double, String, Array, Char, Float, Pointer, and Boolean. There is also an aggressive garbage-collector, optimiser, and what I call SAVE FINAL, which turns the dynamically-generated assembly into a fully dereferenced non-editable 'cooked' version of the code.


    Whether anyone aside from me ever chooses to use it, I do not predict - indeed, I'm designing it for use in a different computer and I'd be surprised if anyone else ever used it. But it'll work on the VIC-20, and if nothing else it's giving me an opportunity to write some nice 6502 and talk about it in a blog. And thus, it suffices.


    Dazu muß ich noch anmerken, daß FD22 im Forum zwar viel erzählt, bislang aber noch kein einziges Programm veröffentlicht hat ... das sind mir die liebsten. Meine Antwort darauf:



    Seitdem mag FD22 mich nicht mehr. Aber wen wunderts?

    Das Problem sehe ich nicht darin, eine neue Hochsprache zu entwickeln, dann müßte ich ja eine neue Sprache lernen, da bin ich zu faul. Nein, das Problem ist, daß die bisherigen Compiler schon sehr schlau arbeiten, aber nicht schlau genug.


    Es gibt derzeit kein Programm, das über den C++ Code guckt, sieht, ach der Vernunfti, der alte Sack, der hat ja nur ein Hello World mit cout und Streaming in einer Klasse untergebracht. Das kann ich, denn ich bin ein schlauer in C-Wandler, daraus mache ich dem fast einen Einzeiler.


    Vielleicht wird es in ferner Zukunft, so 2192, Compiler geben, die kapieren, was sie machen. Vielleicht ein Bewußtsein entwickeln, welches sie dazu befähigt, C++ Code zu nehmen, in optimalen ASM-Code direkt umzuwandeln, wie es heute ein Mensch in einigen Jahren nicht bewerkstelligen würde.

    Erste Grundregel der Informatik:


    Wenn Du programmierst, tut ein Computer grundsätzlich nur das, was Du schreibst, nicht das was Du willst.



    Davon abgesehen, bringt der Gebrauch von Computern genau nur dann was, wenn es eine gegenseitige Übereinkunft gibt, wie die gemeinsam benutzte Sprache zu verstehen ist. Ein System, welches bei der Kompilierung zu 'kreativ' ist, und wo sogar möglicherweise das Ergebnis von der Mondphase oder sonstigem abhängt, ist für die meisten Anwendungszwecke unbrauchbar.


    Lesenswert in 'Gödel, Escher, Bach': sind Computer super-flexibel oder super-starr?


    peiselulli: Genau, Halteproblem. Nicht nur das ist nicht entscheidbar. Genauso wenig ist z.B. entscheidbar, ob die einzige Aktion, die ein Programm macht etwa nur die Ausgabe von "Hello, World!" ist. Oder ob ein Program ein Virus ist. Oder ...!

    Mir ist immer noch nicht ganz klar, ob der Compiler ein Crosscompiler sein darf oder auf dem C64 selbst laufen muß. Für ersteren Fall wurde z. B. der C-Compiler cc65 entwickelt. Aber auch für Assembler existieren inzwischen eine Menge moderner Tools (, wie ich selbst lernen mußte), die die Programmierung wesentlich einfacher machen. Auch Inform als Programmiersprache für Textadventures würde hierhin passen. Die damit erzeugten Programme müßten aufgrund der Z-Maschine auch auf dem C64 lauffähig sein.
    Was aber die Verwendung eines Compilers auf dem C64 selbst anbelangt, so muß man sagen, daß hierfür die Kapazität des C64 schlicht nicht ausreicht. Die Sprache Pascal, für die es früher schon auf dem C64 Compiler gab, wurde von Wirth absichtlich so gestaltet, daß ein Programmtext in einem Durchlauf in die Zielsprache übersetzt werden kann. Der Vorteil war dabei auch, daß lokale Objekte nach Beenden ihres Scopes wieder vergessen werden konnten, so daß der dadurch freigewordene Speicherplatz wieder von anderen Objekten genutzt werden konnte. Ein weiterer Trick, damit ein umfangreicher Compiler wie der von UCSD-Pascal überhaupt in den Speicher paßte, war, den Compilercode in einem komprimierten p-Code abzulegen, der dann in Teilen (sogenannte Segmente) bei Bedarf von Diskette nachgeladen werden konnte.
    Die Frage bezieht sich jedoch auf moderne Compilertechniken und damit eben nicht auf die Single-Pass-Compiler von früher. Heutige Compiler verarbeiten einen Quelltext in mehreren Schritten. Eine wichtige Änderung hierbei ist die Verwendung eines Zwischencodes vor der Übersetzung in die eigentliche Zielsprache. Diesen Zwischencode kann man sich als so etwas wie Basic-Tokens vorstellen, in denen Operanden und Operation und andere Informationen festgehalten werden. Anders als früher lassen heutige Compiler mehrere Optimierungsdurchläufe über diesen Zwischencode drüberlaufen. Hierzu gehören Sachen wie Sprungoptimierung und das Löschen nicht verwendeter Codeteile oder Variablen. Dabei ist es jedoch notwendig. daß der Compiler nicht zwischendurch Informationen über Objekte wieder verwirft, sondern sie bis zum Schluß beibehält. Für eine Übersetzung braucht ein Compiler daher (mindestens) folgende Daten: 1.) eine Liste aller Objekte (Variablen, Konstanten, Funktionen...) 2.) eine Liste aller Zwischencodebefehle. Weitere Daten wären eine Liste aller verwendeten Labels zur Sprungberechnung, eine Liste aller verwendeten konstanten Strings zur Stringoptimierung...
    Hinzukommt, daß der Trend heute dahin geht, das Linken auf Zwischencode-Ebene durchzuführen und nicht mehr im Zielcode (vgl. LLVM), da dies noch besseren Code erzeugt. Diese Vorgehensweise erhöht den Speicherbedarf noch einmal gründlich, da Programme jetzt nicht mehr in vollständig getrennte Programmteile übersetzt werden können, sondern jediglich vorkompiliert werden in den Zwischencode, der dann später zu einem großen Code zusammengefügt und bearbeitet wird.
    Fazit: Selbst wenn man den Compilercode an sich mittels Segmentierung stoßweise in kleinen Blöcken von Diskette laden und ausführen würde, hätte man immer noch nicht genug Platz im Speicher, um diese gesamten Daten aufzunehmen. Und selbst wenn man jetzt zusätzlich eine MMU einführen würde, um die Daten teilweise auf Diskette auszulagern, bleibt am Ende die Frage: Wozu? Bereits in den 80ern haben große Softwarehäuser (z. B. Infocom, Interplay oder Lucasfilm Games) ihre Programme nicht auf dem C64 entwickelt. Heute dauert der gesamte Übersetzungsvorgang eines p-Code-Pascalcompilers nach p-Code inklusive einer Reihe von Optimierungsverfahren ein paar Sekunden. Auf dem C64 käme man mit einer halben Stunde nicht aus. So sehr ich den C64 auch mag... Ein Masochist bin ich nicht.

    Zitat von Vernunftmensch

    Es gibt derzeit kein Programm, das über den C++ Code guckt, sieht, ach der Vernunfti, der alte Sack, der hat ja nur ein Hello World mit cout und Streaming in einer Klasse untergebracht. Das kann ich, denn ich bin ein schlauer in C-Wandler, daraus mache ich dem fast einen Einzeiler.


    Vielleicht wird es in ferner Zukunft, so 2192, Compiler geben, die kapieren, was sie machen. Vielleicht ein Bewußtsein entwickeln, welches sie dazu befähigt, C++ Code zu nehmen, in optimalen ASM-Code direkt umzuwandeln, wie es heute ein Mensch in einigen Jahren nicht bewerkstelligen würde.


    Mal eine Frage an die Runde. Ich hatte früher unter Windows auch per VS in C++ programmiert. Ich hatte nie das Gefühl bzw. es war mir nie bewusst, dass der C++ nach C Code zwischenkompiliert worden wäre.


    Entweder verstehe ich dieses zwanghafte Wollen von Vernunfti den Code in zwei Schritten (eigentlich drei, wenn er ASM Code haben will) kompilieren zu müssen nicht, oder es liegt an meinem Unwissen, dass der Code tatsächlich zuerst in C zwischenkompiliert wird.


    Ansonsten würde ich erwarten, dass das Scheissding meinen C++ Code einfach in Maschinencode kompiliert, sofern es einen C++ Compiler für den C64 geben würde.

    Zitat

    Mal eine Frage an die Runde. Ich hatte früher unter Windows auch per VS in C++ programmiert. Ich hatte nie das Gefühl bzw. es war mir nie bewusst, dass der C++ nach C Code zwischenkompiliert worden wäre.


    Bei modernen Rechnern, insbesondere wenn es um Threads z.B. geht oder um Befehlssätze, die Kommunikation zwischen Prozessoren bewerkstelligen, da führt eine Umwandlung in C zu Datenverlust, die zu Geschwindigkeitsverlust führen. Die Prozessoren sind z.B. da auf Hochsprachen heute ausgelegt. Gebe ich Dir Recht.


    Aber bei den alten Rechnern, warum nicht C oder ASM als Zwischenschritt? ASM ist Maschinensprache mit Benennungen und Kommentaren. Die Umwandlung von C++ in C macht auch keinen Geschwindigkeitsunterschied, weil C äußerst hardwarenah ist.

    Wenn es diesen C++ geben würde, würde er es evtl tun. Andererseits ist so ein Zwsichenschritt oftmals bei der Optimierung hilfreich.


    cafebabe: Java auf dem c64 wäre natürlich extremst cool, aber ehrlich gesagt glaub ich nicht recht daran. Vielleicht wäre j2me so ein Ansatz gewesen, der hätte funktionieren können. Aber das ist ja nun auch vorbei.

    Zitat von Microprofessor

    Ich suche Sprachen, die für den C64 entwickelt oder adaptiert wurden, obwohl es dafür bereits geeignetere Plattformen gab.


    BASIC 2.0 - wobei das nicht wirklich an der Plattform hängt. Ein ordentliches 12K oder 16K BASIC hätte problemlos reingepaßt. Man hat einzig aus Kostengründen auf das Uralt-PET-BASIC von anno '77 zurückgegriffen weil man davon ausging, daß es in den meisten Fällen eh nur als Programmstarter genutzt werden würde.


    Zitat von Microprofessor

    Compiler-Sprachen mit Linkern und Bibliotheken lassen sich wesentlich angenehmer auf Rechnern mit Festplatten verwenden z.B.)


    Natürlich gibt es schnellere und größere Massenspeicher für den '64er als die olle 1541, spätestens seit Mitte der 80er auch als Festplatte.


    Außerdem hat bislang niemand von Compilern geredet?


    Zitat von Microprofessor

    also so, wie man Forth auch schon in den 80ern für Homecomputer entwickelt hat).


    FORTH wurde als eine recht minimalistische, nah am Prozessor arbeitende Sprache konstruiert. Da hast Du ziemlich wenig Spielraum, wenn Du nicht den ganzen Unterbau rauswerfen willst- dann ist es aber kein FORTH mehr, sondern nur noch ein kruder UPN-Interpreter.


    Zitat von M. J.

    Was aber die Verwendung eines Compilers auf dem C64 selbst anbelangt, so muß man sagen, daß hierfür die Kapazität des C64 schlicht nicht ausreicht.


    Daschama Blödsinn. Es gibt genügend Compiler für BASIC, C und PASCAL, die das Gegenteil beweisen. Natürlich wird es eng, wenn man ein komplettes Entwicklungssystem von Editor, Compiler, Quelltext und Compilat ohne Disk-Zugriff im Speicher halten will- möglichst noch mit einem Full-Screen-Editor. Da shat aber weder etwas mit der verwendeten Programmiersprache zu tun noch mit 'modernem Compilerbau'.


    Ebensowenig ist p-Code neu, alt oder überholt (siehe JAVA-Bytecode!), er hat den Vorteil kurz zu sein (wichtig bei 64K Adreßraum!) und er ist in gewissen Grenzen prozessor-unabhängig (siehe UCSD-Pascal), sodaß man seinen Compiler _einmal_ an den p-Code-Interpreter anpassen kann und nicht für jedes neue Zielsystem neu schreiben muß (auch das damals wie heute ein wichtiges Argument)


    Zitat von M. J.

    Heutige Compiler verarbeiten einen Quelltext in mehreren Schritten


    Damalige auch, selbst vernünftige Assembler brauchen 2 Durchläufe. Die Frage ist halt wie Disk-intensiv die Sache sein darf (gerade beim 64er mit seinem Schnarchlaufwerk) udn ob man Source und Compilat gleichzeitig im Speicher halten kann. Vergleiche auch: include-Datei.


    Zitat von syshack

    Ich hatte nie das Gefühl bzw. es war mir nie bewusst, dass der C++ nach C Code zwischenkompiliert worden wäre.


    Es fehlt dann noch der C-Präprozessssor... mit der lästigen Folge, daß ein 'richtiger' C-Compiler gar keine Chance hat gewisse Programmierfehler zu entdecken, weil die nötigen Kontrollstrukturen schon längst aufgelöst sind udn der Präprozessor andererseits keien Ahnung hat was in C erlaubt ist..


    Zitat von syshack

    Ansonsten würde ich erwarten, dass das Scheissding meinen C++ Code einfach in Maschinencode kompiliert


    Das hoffe ich auch immer wieder, daß man heutzutage auf deutlich höherer Ebene compiliert, wetten würde ich da aber nicht drauf... :-/

    Zitat von mc71

    Zitat von »syshack«Ansonsten würde ich erwarten, dass das Scheissding meinen C++ Code einfach in Maschinencode kompiliert

    Ich meinte damit, dass ein etwaiger C++ Compiler auf dem C64 einfach nach direkt lauffähige Maschinensprache kompilieren würde, also nicht noch p-Code, C Code, ASM Source (wobei Letzteres sogar noch nützlich sein könnte) etc.


    Zitat von mc71

    Das hoffe ich auch immer wieder, daß man heutzutage auf deutlich höherer Ebene compiliert, wetten würde ich da aber nicht drauf... :-/

    Das habe ich jetzt nicht wirklich verstanden, wie meinst Du das?

    Zitat von syshack

    Mal eine Frage an die Runde. Ich hatte früher unter Windows auch per VS in C++ programmiert. Ich hatte nie das Gefühl bzw. es war mir nie bewusst, dass der C++ nach C Code zwischenkompiliert worden wäre.


    Ist heute auch nicht mehr so. MSVC hat EINEN compiler, der beide Sprachen compilieren kann, wobei die Fähigkeit, C zu compilieren, leider immer mehr vor dem Anwender "versteckt" wird. In den Anfängen von C++ war es aber in der Tat so. Letztenendes ist C++ ein (meiner Meinung nach grandios missglückter) Versuch, objektorientiertes C in eine von C abgeleitete Sprache zu gießen. Wenn schon hätte ich VIEL lieber C# für den C64 ;) (ob man das auch in C "zwischenübersetzen" kann?)

    Zitat von mc71

    Daschama Blödsinn. Es gibt genügend Compiler für BASIC, C und PASCAL, die das Gegenteil beweisen. Natürlich wird es eng, wenn man ein komplettes Entwicklungssystem von Editor, Compiler, Quelltext und Compilat ohne Disk-Zugriff im Speicher halten will- möglichst noch mit einem Full-Screen-Editor. Da shat aber weder etwas mit der verwendeten Programmiersprache zu tun noch mit 'modernem Compilerbau'.

    Die Frage zielte aber auf neue Compiler mit modernen Übersetzungsverfahren und nicht die alten Basic-Compiler von früher. Von einer Entwicklungsumgebung war überhaupt nicht die Rede.

    Zitat von mc71

    Ebensowenig ist p-Code neu, alt oder überholt (siehe JAVA-Bytecode!), er hat den Vorteil kurz zu sein (wichtig bei 64K Adreßraum!) und er ist in gewissen Grenzen prozessor-unabhängig (siehe UCSD-Pascal), sodaß man seinen Compiler _einmal_ an den p-Code-Interpreter anpassen kann und nicht für jedes neue Zielsystem neu schreiben muß (auch das damals wie heute ein wichtiges Argument)

    Äh... Genau DEN UCSD-Pascal-Compiler hatte ich aber als gelungenes Beispiel dafür genannt, wie ein Compiler auf dem C64 aussehen könnte. Von daher verstehe ich die ganze Antwort nicht.

    Zitat von mc71

    Damalige auch, selbst vernünftige Assembler brauchen 2 Durchläufe.

    Wie ich bereits schrieb, war der Pascal-Compiler absichtlich als Single-Pass-Compiler (single pass = 1 Durchlauf) angelegt worden, um das Speicherproblem bei mehreren Durchläufen zu umgehen. Daß es auch früher Compiler gab mit mehreren Durchgängen, wird niemand bestreiten. Doch anders als damals handelt es sich heute eben nicht mehr nur um die klassischen Durchgänge Tokenisierung, Syntaxcheck, Codegeneration, sondern um komplizierte Optimierungsverfahren, die nacheinander auf den Zwischencode losgelassen werden. Und dafür braucht man halt sehr viel Speicher...

    Zitat von mc71

    Die Frage ist halt wie Disk-intensiv die Sache sein darf (gerade beim 64er mit seinem Schnarchlaufwerk) udn ob man Source und Compilat gleichzeitig im Speicher halten kann. Vergleiche auch: include-Datei.

    Include-Dateien sind das geringste Übel. Da kann der Compiler sich einfach merken, wo er die Übersetzung unterbrochen hat, dann den neuen Text reinladen und durchgehen, danach den alten Text wieder laden und an der gemerkten Stelle fortfahren. Auch das konnte der USCD-Pascal-Compiler damals schon. Andere Möglichkeit: Man packt in einem vorgelagerten Arbeitsprozeß alle Dateien in der Reihenfolge ihrer Verwendung in eine große Datei und benutzt die dann später für die Übersetzung.
    Das Auslagern von Code und Daten (Stichwort MMU) hatte ich übrigens im Fazit explizit genannt.

    Zitat von syshack

    Mal eine Frage an die Runde. Ich hatte früher unter Windows auch per VS in C++ programmiert. Ich hatte nie das Gefühl bzw. es war mir nie bewusst, dass der C++ nach C Code zwischenkompiliert worden wäre.

    Bjarne Stroustrup, der Erfinder von C++, hat damals halt keinen kompletten C++-Compiler geschrieben, sondern "nur" einen C++-zu-C-Konverter. Als sich C++ dann verbreitete, haben die Compilerhersteller ihre C-Compiler zu C++-Compilern erweitert.
    Es gab den von Vernunfti erwähnten Konverter vor dreißig Jahren also wirklich, nur wird er heute halt nicht mehr benutzt. Klar, man könnte diesen Weg gehen, um C++-Programme mit cc65 zu kompilieren - aber warum? Bei Projekten, die klein genug für den C64 sind, dürften die Vorteile von C++ gegenüber C schließlich kaum zum Tragen kommen.