Aber neben Platz und finanziellen Aufwand gab es schon zur Minicomputer Zeit auch andere Gründe warum nur wenige Leute Computer benutzen konnten: Man braucht auch Software. Und die war entweder nicht existent, oder extrem teuer, weil der Programmieraufwand gross war und unter wenigen Usern aufgeteilt werden musste.
Die Alternative eigene Software zu schreiben war noch teuerer, wenn man seine Zeit mit Geld aufwiegen musste, weil die vorhandenen Software Werkzeuge (batch-orientierte Assembler und Compiler) extrem umständlich waren, und "dank" Lochstreifen als einziges billiges Speichermedium auch sehr langsam. Diese traf einem vor allem beim Debuggen, das dank primitiven Sprachen mit vielen Bugquellen zusätzlich lange dauerte. Und man musste beim ersten Programm zusätzlich noch viel Zeit in dessen Erlernen stecken, weil man viele für die eigentliche Aufgabenstellung irrelevante Details erlernen musste.
Bei den ersten Mikrocomputern kam noch das komplette fehlen von Software dazu. Nicht mal Werkzeuge zum Software machen gab es. Nur die wenigsten Benutzer hätten mit handübersetzten Maschinencode ein Interesse daran gehabt. Und Lochstreifen hatten die Geräte auch keine von sich aus, also musste man selbst fertige Programme jedes mal wieder eintippen (und Tippfehler debuggen), bevor Audio-Tonband als Massenspeicher aufkam.
Erst durch den Basic Interpreter wurde Software für die Massen der Normalsterblichen nicht-Techniker schreibbar, und damit der Mikrocomputer für viele Anwender nutzbar, sei das durch interessierte Benutzer die nun selber schreiben konnten, oder durch kopieren von diesen. Basic ist damit ein genauso wichtiger Teil der Mikrocomputer Revolution wie der Mikroprozessor selber.
Der Vortrag teilt sich in 3 Sektionen:
Ziel war es, trotz Multiuser Betrieb, einen offenen Zugriff ohne Accounts zu haben, der Name JOSS stand auch für JOHNNIAC Open Shop System, also eine für jeden offene Werkstatt. Der Benutzer soll einfach ein freies Terminal finden können, dies einschalten und loslegen. Es gab keine Files die beschützt werden müssen, also war keine Security nötig. Die Disk war ohnehin nur 3 mal RAM gross, und nur für Swap benutzt. Das System sollte in erster Näherung als "Taschenrechner" laufen (damals waren nicht mal elektronische Tischrechner erfunden) und einfach Kommandos ausführen. Nebenbei sollte es auch als Kommandos eingegebenen Programcode aufzeichnen und später ausführen, wie heute ein programmierbarer Taschenrechner.
Das resultierende System ist zwar ausgestorben, aber es hat einige auf ähnlichen Grundlagen aufbauende System inspiriert. Darunter auch Basic.
Dies musste aber geschehen, ohne sie dabei in "sinnlosen" Details zu ertränken, mit denen nur Techiker die die Innereien verstehen sich anfreunden können. Der Name Basic war ursprünglich ein Akronym, BASIC, das für Beginners All-purpose Symbolic Instruction Code steht, und somit genau auf diese Lern-Zielsetzung hinweist.
Die meisten dieser Details haben nur damit zu tun Berechnungen effizienter zu machen, also Programmiererzeit zu opfern, um Rechnerzeit (oder Speicherplatz) zu sparen. Dies machte damals, als Programmierer billig und Rechner teuer waren, halbwegs Sinn. Dem Basic-Miterfinder Thomas Kurtz half aber ein Erlebnis dieser Ansicht gegenüber kritisch zu werden: Er hatte nach mehrerer Monaten Assembler Programmierei 60 Minuten Debug Rechnerzeit verheizt, ohne zu einem Resultat zu kommen. Danach hatte er trotz "das ist ineffizient" Sprüchen es mit Fortran probiert, und in wenigen Versuchen ein Ergebnis bekommen, und dafür 5 Minuten Ablauf Rechnerzeit verbraucht. In korrektem Assembler hätte er es theoretisch in einiges weniger an Ablaufzeit geschafft, wären da nicht nicht die vielen abgebrochenen Debug-Läufe dazu aufaddiert. Er erkannte, Debuggen muss man bei Rechnerzeit Effizienzrechnungen mit einbeziehen, und dann sterben so simplizistische Ansichten. Leider geschieht dies nur allzu langsam, auch heute.
Aber auch Fortran hatte viele unnötigen Details, die bei viele Male Debuggen und dann nur ein mal ablaufen von Studentenprogrammen zum Nachteil werden. Auch die Alternative Algol (Vorläufer von Pascal) wurde verworfen, weil es zwar schön strukturiert ist, aber die Strukturierung ebenfalls als unnötige Details empfunden wurde, nur von Nutzen bei grossen Projekten. Vereinfachte Subsets der beiden Sprachen wurden probiert und dann verworfen, weil die entfernten Elemente zu zentral waren.
Auch der Betrieb mit Lochkarten (oder gar Lochstreifen) wurde als zu umständlich angeschaut. Statt dessen sollte der Benutzer nur einen Fernschreiber benutzen müssen. Sein Code wird direkt im Speicher (bzw auf Swapdisk Platz) temporär gespeichert, dort editiert, und von dort unsichtbar Compiliert und ausgeführt (und nach der Ausführung das Compilat weggeworfen). Damit entstand eine Umgebung wie bei JOSS, aber mit einem echten Compiler, damit grossse Programme möglich waren (weil kein Interpreter den Speicher teilen muss). Und die Programme liefen schneller als bei einem Interpreter.
Neben dem unsichtbaren Compilieren gab es auch sonst keine Trennung von System/Editor/Sprache/Ablauf. Alles erscheint aus einem Guss, alles ist immer präsent, auf einer einzigen Kommandozeile, keine Modi, keine inkonsistenten Syntaxe, keine Verwirrung dadurch.
Speziell war auch der verwendete Rechner, der GE265. Dieser war eine Kombination aus:
Das Ur-Basic hatte, wegen diesem asymmetrischen Doppelprozessor Aufbau, keinen INPUT Befehl, weil es zur Laufzeit vom GE235 aus keinen Zugriff auf den Fernschreiber des Benutzers hatte, und man den GE235 nicht mit auf Benutzereingaben warten lassen blockieren wollte, da kein Prozessumschalten auf dem Einzelprogram GE235 möglich war, und der Datanet-30 nicht genug Kontrolle dafür ausüben konnte. Daher gab es für Eingabedaten DATA Zeilen im Programmcode (es waren auch keine Files auf Disk möglich!) und den READ Befehl der aus diesen las. Ausgabe war bereits normal mit PRINT, da dies auf Disk gespoolt wurde, und ebenfalls nach der Ausgabe automatisch wieder gelöscht wurde.
Hier wurde gezielt von Compiler auf Interpreter umgestellt. Einerseits waren die Rechner schneller im interpretieren, weil modernerer Befehlssatz. Anderseits langsamer im Rechnen weil schmalere Register. Und zumindest beim PDP-8 war damit eine Aufteilung Interpreter PDP-8 Maschinencode vs Basic Daten (auch der zu interpretierende Bascicode!) in 2 Speicherbänke möglich. Und ohne User Maschinencode war sicherer Multiuser Betrieb auch mit nur einem Prozessor und Interpreter-internem Timesharing möglich. Und kompakter war das Basic Programm dadurch auch noch.
Für die Verbreitung von Basic zum den Mikrocomputern entscheidend war Bob Albrecht, ein Applikationsanalyst bei Control Data Corp (CDC), der Kunden die bei IBM Fortran gelernt hatten (bzw eben nicht gelernt hatten!) Nachhilfeunterricht gab, damit sie CDC Rechner benutzen konnten (und dafür auch kaufen wollten). Nachdem er um 1970 herum Basic kennenlernte, erachtete er Fortran als tot, und fing an mit einer PDP-8 und einem Fernschreiber und Basic zu missionieren, und es so unter die Leute zu bringen. Zuerst in Form eines fahrendes Rechnerdemos in einem VM Bus mit dem er Schulen besuchte, später mit einem Internetcafe-artigen Betrieb in Menlo Park (Silicon Valley), sowie mit einer Zeitschrift (aus dessen wachsenden Programmlisting Teil das Dr Dobbs Journal (DDJ) sich abspaltete) das später Basic Interpreter Techniken programmieren den Mikrocomputer Techies beibrachte.
Dort im "Internetcafe" lernten sich auch mehrere der späterern frühen Mikrocomputerbastler kennen (Z.B. die Gruppe die den Sol-20 baute), und auch ein Teil der späteren Gründer vom Homebrew Computer Club aus dem heraus z.B. Apple entstand (Wozniak sah dort seinen ersten Mikroprozessor, einen 8008).
Bereits dort entstanden auch die ersten Iterationen des Konfliktes zwischen der Ansicht dass echte Hacker Assembler benutzen vs den "Normalsterblichen" die "faschistoides" Basic benutzen. Das frühe Basic kannte damals noch keine PEEK()/POKE/SYS/USR() Befehle, mit denen es erst möglich wurde, Basic-Komfort mit Assembler-Hardwarezugriff und -Geschwindigkeit zu kombinieren.
Trotzdem galt auch dort bereits die anfangs 1980er sehr treffend formulierte Erkenntnis, dass man mit einem Tag Rechnerzugang entweder in Basic 10min schreiben kann, aber danach in 8h laufen lassen muss, oder in Assembler 10min laufen lassen kann, aber davor in 8h schreiben muss. Die meisten Leute ziehen 7h50m mehr andersweitig nutzbarer Zeit vor, und sei dies nur schlafen während der Rechner üner Nacht rechnet. Mein Vater hat diese Entdeckung wiederholen dürfen, als er Weihnachten 1984 auf meinem Dragon 32 in einer Woche ein Projekt durchrechnete und sich davon überzeugte, und danach in der Firma mehrere Wochen in Fortran "ernsthafte" Rechnungen machte welche das Management dann überzeugten. Die selbige Erkenntnis brachte auch die Unix Leute dazu, derart auf Shellscripts statt compilierten Code zu setzen. Auch die im Web eingesetzten perl und PHP Scripte folgen der selbigen Erkenntnis, im Gegensatz zu C oder C++ oder Java oder C# die geistig im Batch Zeitalter stehengeblieben sind.
Auf einem mit mehr Speicher sowie einem Fernschreiber Interface erweiterten Altair musste man "nur noch" einen Bootlader eineditieren (ausser man erweiterte den Rechner auch mit einer PROM Karte und hatte einen PROM Brenner zum das dafür nötige PROM zu brennen), und konnte den Rest per Prozessor von Lochstreifen einlesen lassen.
Der Processor Technology Sol-20 und der Apple 1 waren bereits beide so fortschrittlich, dass sie neben genug Speicher (1-stellige kBytes) auch einen Speichereditor auf Hexzahlen Basis in PROM Chips (Sol-20 1-2k, Apple 1 256 Bytes!) beinhalteten, der zusammen mit den eingebauten Schreibmaschinen Tastaturen und Schwarzweiss TV Monitor Anschlüssen lief. Ausserdem hatten sie einen Audio-Tonband Anschluss (3-30 mal schneller als Lochstreifen) und einen darauf aufbauenden Bootlader (im Sol-20 beides fest eingebaut, Apple 1 beides als Erweiterungskarte, mit weiteren 256 Bytes an PROM).
Diese Software-leere Welt animierte Bill Gates und Paul Allen einen Basic Interpreter für den Altair zu schreiben. Eine kleine Version die mitsamt Benutzerprogram in die 4k DRAM Erweiterungskarte des Altair passte und eine grosse die 8k (2 Karten) brauchte. Das ganze war ein Hack, der in ein paar Wochen gemacht wurde, nachdem sie MITS (dem Altair Hersteller) ein Angebot gemacht hatten, bevor auch nur 1 Zeile geschrieben war. MITS hatte geantwortet, dass sie das erste Basic nehmen, dass ihnen fertig laufend demonstriert wird, was dann die Eile ergab. (Diese Taktik wurde übrigens sowohl 1980 mit MS-DOS gegenüber IBM (noch nicht eingekauft), wie auch 1983 mit Windows gegenüber Endkunden vermarkten (noch nicht mal schreiben angefangen) wiederholt).
Später wurde dieses Basic bzw Microsoft berühmt (und berüchtigt) durch ihre Beschwerde, dass Leute ihr Basic kopierten statt bei MITS zu kaufen, was nur mit der defekten 4k DRAM karte möglich war (Microsoft bekam pro Exemplar Bezahlung).
Eine Folge dieser Beschwerde war die Entstehung eines vollständig als offenen Source (in Zeitschrift Form publiziert!) erhältlichen TinyBASIC durch Tom Pittman. Dieses lief auf 6800 Prozessoren (Microsoft unterstützte damals nur den 8080 das Altair) und war damit auch leicht auf einen 6502 zu portieren. Dieses wiederum animierte Steve Wozniak ein Basic für den Apple 1 anzubeiten. Es war ihm aber zu schwach, also schrieb er ein erweitertes. Apple bot dies auf einem Kassetten-Tonband, zusammen mit der Tonband Schnitstelle an. Auch da bereits die Apple Taktik, komfortable Software als Verkaufsargument für durchschnittliche Hardware anzuschauen.
Sehr bald wurde Klar, dass Basic für die meisten Leute alles ist was sie programmieren können und wollen, und dass nach jedem Einschalten wieder von Tonband einzulesen unerwünscht ist. Und da ROM Chips auch noch pro Bit billiger sind als RAM, kam die 2. Welle an massenproduzierten Mikrocomputern mit Basic in ROM eingebaut, Tonband wird nur noch für Benutzerprogramme (und -daten) speichern benutzt. Hierdurch waren dann auch grössere Basics möglich, mit 8k oder 16k oder gar 32k ROM. Und das ist nur das Basic, ohne Benutzerprogram/-daten. Das ist was im Apple ][, in den Commodore Rechnern, dem Atari 800 (als ROM Modul!), dem TI 99/4A, und später dem Dragon, sowie auch in Sinclair und Amstrad und MSX usw eingebaut wurde. Die Bootzeiten solcher Rechner, nur Bruchteile von Sekunden, trotz nur wenige-MHz 8bit Prozessor, stellen heutige PCs weit in den Schatten.
Mikrocomputer Hersteller, auf der Suche nach einem fertigen Basic (weil einkaufen billiger und schneller ist als selber schreiben) kauften diese Interpreter fast immer von Microsoft, weil die Firma bekannt für Basic war. MS Basic wurde damit zum Standard auf Homecomputern. Und da die billigsten ROMs industriell vorprogrammiert produziert werden müssen, und nicht zuhause kopiert werden können, kam MS damit zu sehr viel Geld, und hat letzlich von der Altair Basic Kopiererei profitiert, durch die einerseits Bedarf generiert wurde und anderseits ihr Name in die Welt hinaustragen wurde. Diese unabsichtliche Strategie verbreitete später auch MS Word und Office, weil überdurchschnittlich schwacher Kopierschutz.
Inzwischen hatten manche Altair Rechner (und die Klone) auch die langsam billiger werdenden Floppy Laufwerke und Controller erhalten, und ein sehr primitives (weniger als 10 Kommandos!) Betriebssytem namens CP/M wurde dafür geschrieben, mitsammt Hardware abstrahierende Treibern, wenn auch diese nur für Disk und dummes Terminal waren (der Kern von CP/M waren Filesystem und Kommandointerpreter, beide Hardwareunabhängig). Microsoft witterte eine Chance und offerierte ihr Basic für alle Systeme die einen CP/M Port haben, als generisches MBASIC.COM, sowohl via den Hersteller und auch direkt an den Endbenutzer, statt nur via den Hersteller spezifisch für die Hardware angepasst.
Das alles galt auch bereits zu dem Zeitpunkt, als IBM für ihren PC sowohl ROM Basic wie auch Disk Basic (GWBASIC.COM) von Microsoft einkauften. Dies gab dann MS die Gelegenheit, nach IBMs Desaster beim CP/M Einkauf, mit MS-DOS und später Windows die Welt zu dominieren.
Später versuchte Microsoft, auf der Basis von standardisierten Hardware Komponenten (Z80 Prozessor, TMS9918 Videochip, AY-3-8910 Soundchip, 8255 PIO Chip) und ein inzwischen gross gewordenes Basic namens MSX (MicroSoft eXtended), einen Rechnerstandard zu setzen. Es war aber zu spät zum damit die etablierten 8bit Rechner zu verdrängen (Atari 800 und C64 und Sinclair Spectrum, ausser in Asien wo diese noch nicht etabliert waren), und zuwenig zum 16bit aufhalten. Es floppte, vergleichbar mit dem Win-CE PDA Flop später.
Einerseits hat Microsoft, deren Erfolg mit Basic begann, es im PC Bereich am Leben erhalten. Unter DOS wurde nach dem Erscheinen von TurboPascal das QuickBasic 4.0 (QB4) produziert, welches einen GUI-artigen Editor beinhaltet, in dem Basic Zeilen decompiliert und editiert werden. Seit MS-DOS 5.0 ist ein Subset davon namens QBASIC.EXE enthalten. Daraus entstand unter Windows dann Visual Basic (VB), das eigentlich ein GUI Toolkit mit Basic zum Abläufe auscoden ist. Später wurde VB zur Basis von MS ihrer vereinheitlichten Macro-/Scriptsprache für Office Applikationen, Visual Basic for Applications (VBA) erweitert.
Anderseits passierte am genau entgegengesetzten Ende gegenüber der hochleistungs PC Computerei eine weitere Basic Revolution. Intel hatte nach 1971/72 den 4004/8008 Mikroprozessoren auf einem Chip weitergemacht, und 1977 einen vollen Prozessr+ROM+RAM+Timer+IO Rechner auf einen einzelnen Chip integriert, den 8048 Mikrocontroller, und diesen dann 1980 in Form des 8051 erweitert. Intel nahm dann einen dieser mit mehr Speicher, den 8052AH, und baute einen Basic Interpreter in dessen 8k ROM ein. Dieser benutzte das interne 256Byte RAM für den Basic Status, und die 4 8bit Ports (teils) zum das Speicherzugriffsverhalten eines normalen Prozessors zu simulieren. Daran hängt man normale Speicherchips an, in denen dann der Basic Code und dessen Daten kommen. Der ganze 8052AH sieht von aussen aus wie ein Prozessor der Basic statt Maschinencode ausführt, und wurde, voll der Minicomputer Basic Tradition folgend, als einfach zu programmierendes System für nicht geschwindigkeitskritische Steuerungen verkauft.
Später wurde unter dem Namen BasicStamp das selbige mit einem PIC16 Microcontroller von Microchip wiederholt, nur noch einiges minimaler. Nur 3k an ROM, nur um 100Bytes an RAM, und die Variablen (ganze 26 8bit Ganzzahl Variablen namens A bis Z sowie ein(!) String namens $) mussten auch ins interne RAM. Nur der auf einem PC vorcompilierte Basic Code kommt von extern, per einigen wenigen IO Pins (der PIC hat nur 16 davon) aus einem SEEPROM Chip ausgelesen. Inzwischen gibt es auch Kopien dieser Variante, mit grösseren Chips, z.B. das auf PIC18 laufenden PICBasic, oder der Wilke BasicTiger der selbst das Basic-Program in internes Flash speichert.
Da Basic mit dem Ziel entwickelt wurde, keine unnötig komplizierten Kenntnisse erlernen oder berücksichtigen zu müssen, fehlt folglich vieles was in anderen Sprachen drin ist und als nicht nötig empfunden wurde. Am Schluss verbleibt:
Als Beispiele dienen das vom Microsoft stammende spät-1970er Commodore CBM Basic V2.0 (das im 64er und davor im VC-20 unverändert seit dem CBM 3000 übernommen wurde), sowie das 1982er Microsoft Basic des Dragon 32 das der direkte Vorläufer vom MSX Basic ist. Diese aus genau einem Grund, weil der Schreiber beide benutzt hat, und von diesen beiden dissassemblierte ROM Listings hat, noch aus der Zeit als diese beiden Rechner im Gebrauch waren, und noch kein heutiger PC in Sicht war.
Die beiden Rechner sind sich recht ähnlich, und typisch für spät-1970er und früh-1980er Homecomputer:
Adressaufteilung ist bei den beiden: C64 hat 2 8k ROMs A000..BFFF und E000..FFFF (mit einem Loch dazwischen(!)), D000..DFFF ist IO, C000..CFFF ist 4k RAM die das Basic nicht nutzen kann(!), 0000..9FFF ist 40k nutzbares RAM. Dragon hat 2 8k ROMs 8000..9FFF und A000..BFFF, und die letzten 32Bytes noch BFxx->FFxx gespiegelt. IO ist auch alles in FFxx drin. D000..FFDF ist ungenutzt. 0000..7FFF ist 32k RAM.
Man sieht schon mal 3 grosse Diferenzen:
Bei beiden Prozessoren ist der RAM Bereich 0000..00FF besonders schnell zugreifbar, und daher für Basic-interne und Treiber-interne Steuerdaten benutzt. Da wären z.B.:
Für Basic Programme und Variablen und Strings steht der restliche Speicher zur Verfügung. Beim C64 0800..BFFF 38k, die berühmten "38911 Basic Bytes Free", beim Dragon 3600..7FFF, ganze 18.5k, also nur halb soviel Platz. Dieser wird dynamisch verteilt. Von vorne wächst der Basic Code. Dahinter gleich anschliessen kommen die Variablen (die bei jedem Program Editieren gelöscht werden). Dann folgt der Stringspace bis zum offiziellen Speicherende. Dahinter können noch Videospeicher oder Maschinencode Blöcke folgen, wenn der Benutzer den Endwert fälscht. Letztere können beim C64 auch in die nicht vom Basic nutzbaren 4k Speicher von C000..CFFF abgelegt werden.
Die Basic Befehle (und Funktionen) werden als 1-Byte Tokens gespeichert (kompakter, und schneller zum in der Befehlstabelle nachschauen), mit Werten oberhalb von 128 (und so nicht mit 7bit ASCII verwechselbar), z.B. im C64: 128=END, 129=FOR, 130=NEXT, 131=DATA, ..., 162=NEW. Nur die Variablennamen (kurz und viele) und Konstanten (oft kürzer als in 5-Byte binär Form) werden als ASCII Text gespeichert. Der Leerschlag nach dem Befehlswort entfällt auch.
Jede Zeile wird direkt nach dem Eintippen derart teil-compiliert und dann an der richtigen Stelle in die Liste eingelinkt, und zwar in der richtigen Reihenfolge im Speicher liegend (braucht Kopiererei), nicht im Speicher herum springend (bräuchte Garbage Collection). Beim LIST Befehl wird wieder decompiliert und rekonstruiert, es ist kein "Rohtext" zum auslisten da. Es gibt keinerlei zeilenübergreifende Compilierungsvorgänge (FOR/NEXT ist eh das einzige mehrzeilige Konstrukt, da es kein blockorientiertes IF/THEN/ELIF/ELSE/ENDIF gibt). Auch auf Band wird der teil-compilierte Code gespeichert und wieder eingelesen (CP/M und MS-DOS Basic kann optional ASCII machen, C64 kann zu ein File "drucken").
Hinter dem Code folgen dann die Variablen. Genauer folgt hier ein Array von Name/Wert Paaren, ohne Platz für Links zu verbrauchen, 2 Bytes für den Namen, 5 Bytes für den Wert. Bei Zahlen ist dies direkt der Fliesskommawert, bei Strings sind dies 1 Byte Längenangabe (Strings haben max 255 Zeichen) und 2 Bytes Link in den Stringspace.
Dahinter folgt als letztes der Stringspace. Hier wird für jeden String der zusammengesetzt wird Platz vergeben (Stringkonstanten haben bereits ihren Platz im Code drin). Der Platz wird einfach vorzu abgeschnitten bei jedem Teilstring anhängen, bis der String fertig ist. Wenn der Platz ausgeht, wird per Garbage Collector der Leerplatz von nicht mehr existenten Strings "eingesammelt", indem alle Strings nach vorne kompaktiert werden, inklusive ihre Links anzupassen. Auf diese Art und Weise können Strings ohne anfällige malloc()/free() beliebig lang benutzt und erweitert werden, brauchen keine max-String grosse Platzreserve, und es gibt dank Längenangaben keine Bufferoverflows und ein schnelles Stringende finden. Aber bei Garbage Collection kann den Rechner minutenlang "einfrieren". Die Erfinder von C hätten hier einiges lernen können. Zitat von einem Kollegen: "Wenn man kapiert hat, dass C keine Strings hat, kann man dann damit Strings verarbeiten".
War die Eingabe ein Edit wird nun das Programm modifiziert. Es wird durch umkopieren Platz geschaffen und die Zeile mit Link und Zeilennummer eingefügt. War es ein Kommando, wie z.B. RUN wird es sofort ausgeführt, wie wenn es Teil der Programmausführung wäre. Dazu wird der Token genommen, und die Zahl als Index in eine Tabelle von 2 Byte Werten benutzt, welche die für diesen Befehl zuständige Routine im Interpreter identifizieren, und diese angesprungen. Das ganze ist also ein "Case" Konstrukt.
Diese Routinen beinhalten nun die befehlstypische Logik. Im Fall von RUN werden die Variablen gelöscht (sofern nicht bereits durch Editieren) und die Basic-internen Angaben über wo man gerade ist werden auf die erste Programmzeile gestellt. Ausserdem wird von Tastatureingaben teil-compilieren und interpretieren auf Programmzeilen nur-interpreteren umgestellt. Einerseits ist die Quelle anders, anderseits entfällte der teil-compile Schritt, weil der ja beim editieren schon stattfand. Dadurch wird Basic einiges schneller. Dies ist analog zur "äuseren Interpreter" und "inneren Interpreter" Aufteilung von Forth, nur dass dort der Code weitaus weiter compiliert wird, und dementsprechend schwieriger bis unmöglich zum decompilieren ist.
Benötigt ein Befehl Argumente, kann dessen befehlstypische Logik dazu Hilfsroutinen im Interpreter aufrufen, welche diesen evaluiert. Im Fall von numerischen Ausdrücken wird dazu etwas Speicher namens Fliesskomma Akkumulator (FAC) benutzt, in dem der aktuelle Zahlenwert aufgebaut wird. Für mehrere Operanden einer Funktion, sowie Addition/Multiplikation/Exponent gibt es dazu auch 3 Hilfs-FACs. Für Klammerausdrücke, die beliebig oft verschachtelt sein können, werden die Hilfs-FACs bei "(" auf einen Stack gespeichert und bei ")" wieder zurückgeholt.
Auf diese anwendbar gibt es Routinen für Addition, Subtraktion (A-B wird als A+(-B) gerechnet), Multiplikation, Division (A/B wird erstaunlich nicht als A*(1/B) gerechnet), Polynomberechnung mit x hoch 0,1,2,3,... bzw x hoch 1,3,5,7,... Serien (letzteres für McLaurin und Taylor Reihen berechnen), sowie transzendente und logarithmische Funktionen via eben diese Reihen.
Selbst diese detailierte Logik ist bei beiden Rechnern identisch. Sogar die Zerlegung auf Subroutinen ist identisch. Das geht soweit, dass im Dragon, trotz des 6809 Prozessors der einen in Hardware implementierten 8bit*8bit Multiplikations Befehl hat, die nötige 32bit*32bit Mantissen Multiplikation mit genau der selbigen Shift-Logik berechnet wird wie auf dem 6502! Der MUL Befehl wird einfach ignoriert, was Multiplikation und damit auch Polynome und Transzendentale um ein Mehrfaches langsamer als nötig macht.
Werden als Teil eines Ausdruckes Variablen verwendet müssen deren Werte geholt werden. Dazu wird mit dem Variablenamen eine lineare Suche(!) des Variablenspeichers durchgeführt. Die Variablen sind nicht alphabetisch geordnet, es ist daher keine binäre Suche möglich, trotz konstanter Grösse. Da wurde ebenfalls viel Geschwindigkeit verschenkt.
Ist ein Befehl eines Programmes fertig, wird zur nächsten Zeile übergegangen und diese ausgeführt. Dies geht solange bis beim Programende angekommen wird, oder ein Programmablauf steuernder Befehl ausgeführt wird (GOTO/IF/GOSUB/RETURN/FOR/NEXT).
Die Sprünge GOTO, IF und GOSUB suchen einfach der gelinkten Liste der Zeilen nach, solange bis die richtige Zeilenummer auftaucht. Für Zielen mit Zeilennummer kleiner als der aktuellen wird von vorne gesucht. Für solche mit Nummer grösser wird ab der jetztigen Position weitergesucht, damit werden die zumeist kurze Distanz vorwärts laufenden IF und die den Else-Teil überspringenden GOTO einiges schneller. Die relativ simple Technik von den letzten paar GOTO, IF und GOSUB das Nummer->Zielort Resultat in einem Cache zu speichern wurde nicht verwendet.
GOSUB merkt sich die aktuelle Position (und nicht nur Zeilennummer) jedes Aufrufes auf einen Stack (den selbigen auf den Klammerausdrücke die Hilfs-FACs speichern) damit verschachtelte Subroutinen möglich sind, von dem aus dann RETURN diese ohne Zeilensuche schnell nehmen kann. Das GOSUB selber ist wegen der üblichen Anordnung der Subroutinen am Programmende relativ langsam zu benutzen.
Besonders aufwendig ist FOR, welcher zusammen mit NEXT auch der einzige mehrteilige Befehl ist. Nicht nur merkt es sich den Ort des FOR, und vermeidet damit eine Zeilensuche von vorne, es muss seine Indexvariable auch nur einmal suchen. Alle Zuweisungen und Tests auf diese laufen damit einiges schneller ab. Und da die Zuweisung für nächsten Wert berechnen und der Test auf Ende beides fixe Operationen sind, mit nur 2 Zahlenwerte als Parameter, werden auch diese nur einmal bestimmt, und dann mit abgespeichert und direkt benutzt. Auch dazu dient, damit verschachtelte Schleifen möglich sind, der selbige Stack wie bei GOSUB und Klammern. Daher sind FOR/NEXT weitaus schneller als die genau identisch wirkende mit normaler Arithmetik und IF/GOTO ausgeführte Variante.
Als wichtigstes ist hier das implementierte Terminal zu nennen. Während im Dragon einfach ein Glass TTY simuliert wird, ist der C64 sein Terminal direkt komfortabel. Dabei geht es gar nicht einmal um Escape Sequenzen, welche bei beiden fehlen, sondern darum, dass das C64 Terminal die Ausgabe editieren und wieder eingeben kann!
Alle Basics können ihr Programm editieren indem man per Kommandozeile Zeilen addiert, löscht oder ersetzt, was aber auf neu eintippen von zu ändernden Zeilen rausläuft, und recht mühsam ist.
Auf dem Dragon ist ein EDIT Zeilennummer Befehl vorhanden, der mit in etwa mit dem MS-DOS EDLIN vergleichbaren "Komfort" eine neue Variante einer Zeile produzieren kann. So mühsam, dass ich mir es nie angewöhnt habe. Neu eintippen weiss man schon wie es geht, und es ist genauso schnell, und pure Tipperei ohne lesen/planen/befehl/tippen Zyklus.
Auf dem C64 kann dagegen eine Zeile (oder mehrere Zeilen) mit LIST ausgelistet werden, dann im Bildschirmspeicher editiert werden, und die geänderten Zeilen als neue Kommandos abgeschickt werden, wie wenn voll getippt, womit sie neu eingefügt/ersetzt werden. Dabei können Befehle auch nur unverändert wiederholt werden, wie bei einer Shell History, wobei nicht nur Befehle, sondern auch INPUT Eingaben wiederholbar sind. Man kann auch ähnliche Zeilen durch mit-editieren der Zeilennummer von vorherigen ableiten. All das ohne ein einziges Feature im Basic drin, Basic sieht nur traditionelle neue Zeilen, aber der User hat editiert, und das im Vollbildschirm Modus, mit mehreren ausgelisteten Zeilen im Sichtfeld!
Dazu brauchte das Terminal nur den Cursortasten zu folgen (Basic weiss nix von denen), direkt die Zeichen im Videospeicher zu ändern (es ist kein separater History Speicher vorhanden), und von jeder Cursorposition wissen, zu welcher Eingabe oder Ausgabe Zeilengruppe (umgebrochene Einzelzeile!) sie gehört, und damit welcher Zeilenblock als neue Eingabe dem Basic zu schicken sein wird, wenn Return gedrückt wird. Der Cursor ist nach Return stets auf dem ersten Zeichen der nächsten Zeilengruppe. Dazu wird neben dem Videospeicher nur eine Liste von Koordinaten der Zeilengruppenenden der max 25 sichtbaren Zeilen benötigt. Einzige Limite ist, dass mangels Scrollback Speicher max 25 Zeilen an gemischter Ein- und Ausgabe so editierbar sind.
Das Resultat ist weitaus besser als beim Dragon. Vergleicht man das mit dessen "nur Zeile ändern und ersetzen" Editor, der weniger kann und schwieriger ist, und Basic Erweiterung brauchte, ist der Unterschied wie Tag und Nacht. Das generische "Aufsetzfeature" ist dem spezifischen eingebauten weit überlegen.
Der C64 Terminal Editor wurde dann auch logischerweise von anderen Programmen benutzt. Sowoh der typische "Monitor" Debugger, wie auch ein Assembler wurden beide als pure TTY Kommandozeilen geschrieben, die einen LIST-artigen Befehl hatten, dort wo editieren erwünscht ist.
Die Firma HP hat überigens, als Teil ihrer HP2000 Minicomputer, RS232 Terminals eingeführt die genauso arbeiten. Ich hab diese aber erst kennengelernt, als ich Unix (und moderne Pfeil-aufwärts Shell History) kannte, und diese an einem HP-UX Rechner angeschlossen waren. Jedesmal als ich wie gewohnt History holen wollte lief der Cursor herum, statt dass die Shell mit History reagierte. Ich fand dies frustrierend, und habe erst viel später kapiert, dass da die C64 Erfahrungen angebracht gewesen wären. Dabei fiel aber auch die Limite auf, dass History auch durch Ausgaben längst weggescrolle Kommandos kennt, während diese Terminals kein Scrollback kannten, oder diese zumindest nicht sichtbar war. Alles in allem genau ein "früher gab es total anderes" Feature, genau passend zum Thema dieses Jahr.
[Wexelblat] Richard L Wexelblat, History of Programming Languages
Academic Press, 1978, ISBN 0-12-745040-8 (Englisch)
beinhaltet [Baker] und [Kurtz] und einiges anderes
[Baker] Charles L Baker, JOSS - JOHNNIAC Open-Shop System
= [Wexelblat] Seiten 495..513 (Englisch)
Beschreibung von JOSS und seiner Entstehung
[Kurtz] Thomas E Kurtz, Basic
= [Wexelblat] Seiten 515..549 (Englisch)
Beschreibung von Ur-Basic und seiner Entstehung
[Levy] Steven Levy, Hackers - Heroes of the Computer Revolution
Dell Publishing, 1984, ISBN 0-440-13405-6 (Englisch)
(im 2. Abschnitt) Hacker und Basic, von Albrecht bis Wozniac
[Janneck] Jörn W. Janneck & Till F. Mossakowski,
Das Dragon 32/64 Lexikon
Röckrath Mikrocomputer, 1984 (Deutsch)
Hardwareaufbau und Dissassmbliertes ROM Listing vom Dragon 32 und 64
[Angerhausen] Angerhausen & Brückmann & Englisch & Gerits, 64 intern
Data Becker GmbH, 1983, ISBN 3-89011-000-2 (Deutsch)
Hardwareaufbau und Dissassmbliertes ROM Listing vom Commodore C64
Diese Seite ist von Neil Franklin, letzte Änderung 2007.04.27