"Process and experiment automation realtime language"
Das ist eine Sprache fuer Computer die technische Prozesse in Echtzeit steuern und regeln.
Weil alle hoeheren Programmiersprachen Wuensche offen lassen, bis heute. Und so werden immer neue erfunden.
Weil man das nur dort tut wo es unbedingt noetig ist, z.B. weil es nicht anders geht, oder weil man irgenwo das letzte an Geschwindigkeit herausholen will.
Das sollte man normalerweise gar nicht merken, ausser beim Einlesen von binaeren Daten, wenn man sich umstaendliches Programmieren spart weil die Byteordnung zufaellig stimmt.
Mein erster Programm-Text Editor waren die Lochkarten fuer die TR440, das war 1980. Das ging eigentlich recht gut weil man die Zeilen in denen man einen Fehler hatte leicht austauschen konnte. Wie das auf Lochstreifen gegangen ist war mir ein Raetsel, auch wieso man auf dieser Maschine vorher Lochstreifen verwendet hat, denn die erste TR440 war 1969, Lochkarten sind viel aelter.
Die TR440 hatte 1980 auch Bildschirmarbeitsplaetze und es gab dort einen Texteditor mit Namen "Korrigiere". Es gab Algol60, Pascal,Fortran und diverse andere Sprachen. Pascal wurde fuer die Uebungen der Informatik-Vorlesung verwendet. Jetzt habe ich gelesen dass es fuer die TR400 auch eine Maus gab, die habe ich nicht gesehen, war aber auch nie an einem Graphik-Terminal. Leider war diese deutsche Computerentwicklung ein totes Ende.
Sehr relevant ist die Byteorder! Das ist ein echtes Problem. Man kann sich nämlich kaum erlauben, dies (auf uC) portabel zu programmieren! Code-Größe und -Geschwindigkeit sind einfach zu wichtig.
Zeigergröße und Alignment waren bei mir nie problematisch. Wenn 'int *ap;' vereinbart wird, nimmt jeder C-Compiler das korrekte Adressenformat. Ein C-Compiler verwendet generell ein 2..4..8..16-Byte-Alignment, je nach Ebene und API. Der legt auch ein char[array] _nicht_ mit 1-Byte-Alignment an, sondern eher mit 4..8 Byte. Der nimmt einfach das für die jeweilige Plattform passende Alignment. Aufpassen muß man auf 'int' :: 'long'. Sobald ein Inhalt >2^16-1 werden kann, muß 'long' genommen werden. Oder int32_t.
Während meines Studiums programmierte ich ausschließlich mit PEARL. Der Rechner war von Krupp-Atlas, aus zwei Schränken bestand dessen Kern.
Leider braucht man dazu ein BS RTOS-UH, auf dem ein PEARL-Compiler läuft. UH ist eine Abkürzung von Universität Hannover. RTOS-UH braucht eine Plattform Motorola 68xxx oder PowerPC.
PEARL ist aber sehr interessant hinsichtlich Multitasking. Sie ersetzt vollkommen die in C notwendigen etwa 50 schrecklichen Thread-Funktionen.
==================================================================== Fortschritt: TASK PRIORITY 3; <Body> END;
ACTIVATE Fortschritt; TERMINATE Kontrolle; SUSPEND Ausgabe; CONTINUE Register; AFTER 5 SEC RESUME;
WHEN Komplett ACTIVATE Kontrolle; /*<Komplett> ist ein IRPT*/
AT 12:0:0 EVERY 30 MIN UNTIL 15:0:0 ACTIVATE Protokoll;
SEMA BOLT /*Variablen-Typen zur Synchronisation von TASKs.*/
RKI: DIGOUT(3) * (2:9) ->
WRITE Ausgabe TO RKI; ====================================================================
Vorstehend wird deutlich, wie übersichtlich und vielfältig Multitasking programmiert werden kann. Man sollte neben C, C++, C#, eine Multitasking-Sprache 'C&' kreieren. Da es die nicht gibt, betreibe ich ersatzweise Multiprocessing.
Oben schrieb ich: "Jedoch noch viel ungeeigneter ist Assembler." Die Antwort oben: "Assembler ist für ALLES perfekt geeignet, wenn man es kann."
Nur _deshalb_ schrieb ich die vorstehenden beiden Sätze als Antwort darauf.
Einen "Editor" in BASIC schreiben? Ja, das geht natürlich. Schließlich habe ich ja formal ein ganzes Rollenspiel mit KI-Charakteren, GUI und lustigen Bildchen dazu:
Und ebenso natürlich haben die Buben von Ultimate, Bug Byte, Quicksilva & Co die Spiele meist nicht auf der Gummitastatur entwickelt, den Z80-Schmöker von Rodnay Zaks [1] nebendran und die Flußdiagramme auf Zettelchen aufgemalt, so wie ich.
Der sich einen Knopf ans Ohr freute, als endlich HiSoft Devpac [2] mit einem ordentlichen (Dis)Assembler auf den Markt kam - mit Editor in Z80-Assembler natürlich, der in den oberen 32kB(!) RAM wohnen konnte, wo man voller Angstschweiß sündteure 64kBit-ICs eingelötet hatte. Statt der 32kBit- Ausschußware, die Sparfuchs Sir Clive damals ergattert hatte [3].
Diese Bänke konnte man dann mit einem Schalter, selbstgelöteter Z80-PIO oder dem Multiface One hin und herschalten, mußte also nicht DevPac nervtötend von Kassette (oder Microdrive) laden, falls der eigene Code abgesemmelt war. Denn den Luxus von ISP-Debugging war zu dem Zeitpunkt für Hobbyisten nur ein ziemlich feuchter Traum.
Matthew Smith [4], Schöpfer der epischen Spiele Manic Miner und Jetset Willy, hoch aufgestiegen und tief gefallen, hat sein ZX Spectrum Cross-Development Rig von denselben Leuten gekriegt, die auch das Team von Sir Clive für die Entwicklung vom Sinclair BASIC (und später auch der IF1 Firmware) versorgten. Eine oberhalb von £60'000 angesiedelte DEC VAX 11/780 [5].
Man munkelt auch, daß Manic Miner die ersten Gehversuche auf einem TRS-80 [6] machte, damit das Spiel rechtzeitig zum Release des Spectrum fertig wurde [7].
Ultimate (Pssst!, Cookie, Jetpac, Jetman, Atic Atack) beschritt schon damals einen zum typischen Kinderzimmer-Coder deutlich verschiedenen Weg, mit einer Multiuser-32-Bit-Workstation (vermutlich 68000), wo man für die Z80- Zielplattform crosscompilieren konnte [8].
Bei Hewson hatte man 1988 dem Vernehmen nach bereits IBM PC mit Z80 Crossassembler, der 200k Sourceode in wenigen Sekunden verdauen und ihn via Parallelport rüberschicken konnte.
Den letzten Schliff habe ich "Ring of the Inka" natürlich mit EightyOne, FUSE, Bas2Tap, BinTap auf dem PC gegeben. Sonst würde man komplett wahnsinnig werden, mit dem verkrüppelten Einzeileneditor in 16k ROM ohne jegliche Such- /Ersetzfunktion.
In Sachen "Editor" dürfte wohl Tasword Two von Tasman Software das Maß der Dinge darstellen [9], mangels Details kann ich nur vermuten daß man auch dort bestimmt nicht Hexcodes in ein BASIC-Listing eingetippt hat, wie es zu Zeiten von "Your Spectrum" [10] [11] oder "Your Sinclair" [12] gang und gäbe war.
Deinen Spruch "Was es damals sicher gab war BASIC." finde ich vor diesem Hintergrund also schon einigermaßen amüsant, "Ich käme nie auf die Idee, einen Editor in Assembler zu schreiben." grenzt bereits an Schwachsinn.
Volker
[1]Hallo Hans-Peter,
Du schriebst am Tue, 19 Sep 2023 10:14:54 +0200:
Der original Editor von FORTH (großgeschrieben) ist ein Festformat-Editor ohne Zeilenstruktur. Sowas ist natürlich einfach implementierbar, deswegen wurde so einer auch dafür benutzt.
Genau genommen ist "VB" (als "Visual Basic" interpretiert) nur eine IDE für einen allerdings spzifischen Dialekt eines fortgeschrittenen Basic (nein, hier nicht großgeschrieben, weil das nicht mehr das Original war) mit der Möglichkit, gar dem Zwang, zu etwas ähnlichem wie strikturierter Programmierung, d.h. echte Bedingungen, Schleifen und sogar Subroutinen als syteaktische Elemente.
Was niemand davon abhält, es für genau den Zweck mit weitester Verbreitung einzusetzen. Allerdings ist C sowieso keine Programmiersprache, allenfalls ein Zerrbild einer solchen.
Wobei sich hier wieder dir Frage aufwirft, wo das Ei sein Huhnauf dem Zielsystem finden soll - d.h. eine Interpretersprache kann man erst auf einem Zielsystem benutzen, wenn man dort schon den dazugehörigen Interpreter hat.
Ja, da ist Linux natürlich besonders variabel, das hat überall weitgehend dieseleb Struktur, dieselben Bibliotheken (evtl. in unterschiedlichen Versionen) und dieselben Systemanwendungen. Da ist Windows viel einfacher, da hat nur jede Version ihre eigenen, teilweise (bedienungs-) inkompatiblen Systemprogramme.
Ja, ".NET". Nett... gedacht, aber mit seinen ganzen, auch wieder teilweise inkompatiblen Varianten eher ein Sauhaufen und Born an Frustration für den Programmierer, der nicht "von Null anfangen" kann. Aber stimmt schon, Python entwickelt sich mit seinem Modul-Zoo auch schon sehr in die Richtung von Perl, das es als einzige Programmiersprache bisher fertigbringt, bei Aktualisierungen einiger seiner Module zu scheitern, weil die schon vorhanden sind.. (Auch wenn es dabei eher um fremdkompilierte externe Objekt-Module geht.)
Fazit: Systemunabhängigkeit wäre zwar öfters mal sehr nett, ist aber nicht.
Das ist nicht ganz richtig. Tatsächlich legt der Hersteller einer portablen Software mit Autobloat fest, auf welchen Zielsystemen sie lauffähig sein soll. (siehe unten)
Ein High-Level Assembler aus einem Konglomerat von mehreren Sprachen.
Wobei es im Interesse der Pfleger eines solchen Systems liegen sollte, solche Interpreter zum Lieferumfang des Systems zu machen. Bei Autobloat ist es genau umgekehrt, da liegt es im (Des-)Interesse des Programmierers, auf welchen Zielsystemen sein Programm lauffähig sein soll.
Gerade die Bibliotheken unterliegen einem ständigen Update, das eine ebenso ständige Anpassung der Software erfordern kann, die auf dem jeweiligen Linux laufen sollen.
Auch da ändern sich die Systembibliotheken und Anforderungen an Programme mit jeder neuen Version. Es gibt allerdings nur eine geringe Anzahl von Versionen, die eine Software gleichzeitig unterstützen muß,
Am übelsten ist die Borniertheit der Entwickler, die ein angeblich offenes System weitgehend geheim gehalten haben und damit die Portierung auf andere Plattformen als Windows torpediert haben. Viel einfacher kann man sich nicht ins Knie schießen :-]
So ist das (un)wohl DoDi
Am 16.09.2023 um 23:40 schrieb Rolf Bombach:
Da muß ich doch aus von Lutz Donnerhacke zusammengetragenen "Fachbegriffen der Informatik" zitieren.:
"FORTRAN ist älter als jeder Lötkolben, ist klobiger als jede Elektronenröhre und unpraktischer als Würfelzucker in Tuben. Ein streunender Kater, der nach einem nächtlichen Gesangsauftritt mit dem Inhalt eines Nachttopfs übergossen wurde, ist verglichen mit einem Stück FORTRAN77-Sourcecode eine ausnehmend elegante Erscheinung. Nun, immerhin kann FORTRAN die vier Grundrechenarten. " (Nico Hoffmann)
Bernd
Da Assembler eine Programmiersprache ist, kann nicht behauptet werden, C sei keine.
Daß C auch ein High-Level-Assembler ist, kann gesagt werden. Als Konglomerat von mehreren Sprachen kann sie nicht bezeichnet werden, denn es gibt praktisch keine Sprache, die nicht auf irgendwelchen früheren Sprachen basiert.
C basiert auf B; Der Entwickler von C mitentwickelte zuvor B. B wiederum basiert auf BCPL (vor Unix). Der Zeitstempel von Unix mit dem Wert 0 ist dem '01.01.1970 00:00:00' zugeordnet. C wurde eben _wegen_ Unix entwickelt, um den Unix-Kernel fortan in C schreiben zu können. Dieses Ziel war 1973 erreicht; 1974 erschien C; 1978 gabs ein C-Buch.
Wegen der Zielvorgabe von C (Unix) wurde C mit _sehr vielen_ Freiheiten ausgestattet. Andernfalls hätte C die Zielvorgabe nicht erreicht und wäre sinnlos gewesen. Der Nachteil von C sind diese Freiheiten, da die Mehrheit soviel Freiheit nicht verträgt! In intelligenter und disziplinierter Hand sind C/C++ nicht/kaum zu übertreffen.
Genau deshalb führt das Paar C/C++ unter den Compiler-Sprachen mit wohl 95% Anteil, wobei eine 3-stellige Anzahl von weiteren Sprachen sich den Rest von etwa 5% teilt. Fast alle der restlichen Sprachen haben folglich jeweils einen Anteil von weit unter 1%. So ist die aktuelle Realität.
Es gibt schon lange den zutreffenden Ausspruch: "An C/C++ kommt man nicht vorbei!". Wer sich da herumdrückt, ist in den meisten Fällen beruflich nahezu völlig abgehängt. Ganz schlecht für C-Hasser.
Am 20.09.23 um 16:27 schrieb Helmut Schellong:
Nö.
"C ist ein offener Geländewagen. Du kommst durch jeden Dreck, aber siehst hinterher entsprechend aus." "Einem C-Compiler kann man Goethes 'Faust' vorsetzen, und er wird nichts weiter ausgeben als ein paar Warnungen." ;)
Gab noch mehr solche Sprüche, finde sie aber nicht mehr. Schade, hätte ich aus meinem Weiterbildungslehrgang damals aufheben sollen. ;)
Richtig, C muss man lieben. ;) Aber wenn ich das richtig sehe, gehört die "digitalisierte" Welt doch den Interpretersprachen - läuft denn z.B. irgendwas im Netz heute noch ohne PHP ...
Ach Kinders,
Es gibt unterschiedliche Anwendungen, die programmiert werden. Je nach Anwendung nutzt man dann die Tools/ Programmiersprache, die dafür geeignet ist. Interpretersprachen sind weder prinzipiell besser noch schlechter. Häufig sind sie einfach zu langsam. Da sind compilierte Programme im Vorteil.
Eine "digitalisiete" Welt gibts nicht wirklich. PHP hat seinen Platz an ganz anderen Stellen, als im 4- bis 16-Bit µC Bereich ist das ist eine ganz andere "digitalisierte" Welt, als mit 32/ 64 Bit-Multicore-µC-Bereich, mit denen Multimedia-Konsolen und vieles mehr programmiert wird. Eine Spezialanwendung an einem Prüf- oder Forschungsplatz wird mit anderen Anforderungen laufen müssen/dürfen, als bei einem Massenprodukt. Beim einen dürften Hardwarebeschränkungen keine Rolle spielen, man nimmt eben mehr Rechenleistung und gut. Beim anderen zählt jedes Cent und man spart an Speicher und Rechenleistung wo immer es geht.
Kein vernünftiger Programmierer wird ein Massenprodukt mit 4/8-Bit µC mit PHP oder Python programmieren. Genausowenig wird man eine Webanwendung mit C interaktiv gestalten wollen. All diese Ebenen in einen Topf zu werfen und dann zu behaupten, 95 % aller Programme seien C/C++ ist einfach Unsinn, zumal die Basis nicht definiert wurde. Was sollen denn 100 % sein? Anzahl der geschriebenen Codezeilen, ausgelieferte Stück Hardware, im zeitlichen Mittel laufender Code ... ?
Just my 2 ct
Marte
Am 20.09.2023 um 21:55 schrieb Hartmut Kraus:
Mir sind mal noch die folgenden begegnet:
Das letzte Schöne, das in C geschrieben wurde, war Schuberts 9. Sinfonie.
C is a language that combines all the elegance and power of assembly language with all the readability and maintainability of assembly language.
Holger
Am 21.09.23 um 09:57 schrieb Holger Schieferdecker:
Richtig. "C ist ein besserer Assembler." ;)
Am 21.09.23 um 09:57 schrieb Holger Schieferdecker:
Nö. "C sieht aus wie eine Ansammlung von Schreibfehlern."
Am 21.09.23 um 09:57 schrieb Holger Schieferdecker:
Nein, nein, "The Day the Music Died" war doch erst der 3. Februar 1959. Jedenfalls, wenn man Donald McLean III Glauben schenken kann. ;)
Am 20.09.2023 um 21:55 schrieb Hartmut Kraus:
Den Spruch habe ich sogar schon von Arbeitgebern gehört. Von deren leitenden Angestellten (MdGL) erst recht.
Das trifft nur auf diejenigen zu, die mit C undiszipliniert umgehen.
Das ist gewollt, und sehr gut so.
Unter den vielen unixoiden Betriebssystemen liegen in den Verzeichnissen /bin /sbin /usr/bin /usr/sbin /usr/local/bin die ausführbaren Dateien (Executables). Mindestens 99% davon sind compilierte binäre Exe, in C oder C++ geschrieben.
Der Kernel und alle Libraries sind ebenfalls in C/C++ und zu kleinen Teilen in Assembler. Hinzu kommen (FreeBSD) fast 40000 fertig compilierte Packages - alle in C/C++ geschrieben.
Windows ist seit langer Zeit in C/C++/C# geschrieben (früher in Pascal).
Binäre Exe bilden folglich die übergroße Mehrheit. Interpreter-Skripte sind selten, und fast immer sind sie Frontend- oder Service-Skripte.
PHP arbeitet weit überwiegend serverseitig und ist dazu in HTML eingemischt. Die Webserver (z.B. Apache) sind - natürlich in C/C++ geschrieben. Qt und MySQL sind in C/C++ geschrieben. Weitere Datenbanken sind ebenfalls in C geschrieben.
Die verbreitete Code-Basis in C/C++ ist gigantisch groß. Im uC-Bereich (embedded) gibt es nahezu ausschließlich C/C++. Wobei der uC-Bereich größer ist, als alle anderen Bereiche.
C tut weh! (*)
Der C-Programmierer hat den Compiler im Kopf. Der FORTH-Programmierer hat den Compiler im Target.
Der schlechte C-Programmierer gibt auf und bezeichnet die Aufgabe als unlösbar. Der schlechte FORTH-Programmierer bringt sein Projekt zum laufen und veröffentlich das in der 'Vierten Dimension'
(*) C ist zB: (*(void(*)())0)()
Das hab ich vor Äonen mal in einem uC C-Projekt gefunden :] in FORTH umgeschrieben und binnen weniger Tage erfolgreich abgeschlossen.
Der C-Programmierer war sogar stolz darauf und meinte, jeder Kommentar sei überflüssig. Aber nichts desto Trotz, sein gesamtes Proggie funzte nicht. Na denn!
Wer weiss, für was der Obige Müll gut ist?
Auflösung auf Anfrage :)
Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang
Ach, dann sind C, C-Preprozessor, Make und vielleicht heute noch M4 und Autobloat für Dich keine unterschiedlichen Programmiersprachen?
DoDi
Ueblicherweise macht man noch einen ; dahinter dann wird die Funktion aufgerufen die an Adresse Null liegt. Auf einem PC gibt das ein Segmentation fault, aber ich will nicht ausschliessen dass es Systeme gibt wo an Adresse 0 eine wichtige Funktion liegt die er auf diese Weise aufgerufen hat, vielleicht ein Restart des gesamten Systems, bei Mikrokontrollern ist ja manches moeglich.
Vielleicht ist es auch ein Test fuer ein fehlertolerantes Programm das dieses Signal abfaengt statt abzustuerzen.
Dann hat er es in der gegebenen Zeit wohl nicht geschafft.
Er wollte halt nicht extra einen Pointer auf eine Funktion definieren, dort eine Null reinschreiben und sie dann aufrufen und dadurch ein paar Byte einsparen.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.