Optimierungsgrad KERNAL /BASIC - fiktiver Talk

Zitat von Hoogo

Die Sprache sollte schon so Einsteiger-freundlich wie Basic sein, ähnlich nützlich sein, nach dem Einschalten incl. Editor da sein, keine externen Geräte brauchen und in 8KB (oder von mir aus auch 12 oder 16KB) passen. Halt, für was man Anfang der 80er Geld bezahlt hätte.

Ganz genau!
Ohne solche vernünftig gesetzten Restriktionen weichen die "Kollegen" nämlich gerne ins Aasen mit Speicher, x86-Rechenpower, Cross-Entwicklung aus ... also dahin wo die Aufgabe bequem und unspannend wird.

"Wir haben zuwenig Speicher ? - Zack, ein Modul in den Ex-Port!"
"Der Prozessor lahmt? - Ach entwickeln wir einfach auf einem anderen Rechner... und laden es rüber"
Dies sind gemessen an der olympischen Idee dieses Threads "Dopingversuche"

man muss wachsam sein gegenüber solchen Tendenzen die nicht authentisch im Sinne dieses Threads sind .. .der Olympische Gedanke sollte gewahrt bleiben

Zitat von Hoogo

Speicherbereiche mit irgendwas füllen muss es eh schon im ROM geben, um Arrays zu initialisieren.
Adressen der Screenzeilen werden im Rahmen des Reset auch initialisiert, ich meine, bereits dort nach berechneter Anfangsadresse.
CLR könnte so schnell und kurz sein..

Da liegt der Hase im Pfeffer: für eine universellere Füllroutine gäbe es auch im Basic selbst vielfältige Verwendung... wenn man da einiges zusammenlegen kann, würde viell. einiges gespart an Bytes..

Zitat von Hexworx

Zum 'Rennen' wird man es aber trotz alledem wohl leider eh nicht bekommen. Aber diese Fill-/Lösch-Funktion wäre eine schöne Sache gewesen, um in BASIC den Bitmap-Mode überhaupt halbwegs brauch-/nutzbar zu machen, ohne eine gähnend lange dauernde Lösch-Orgie vorweg.

Die verkorkste Bildschirm-Lösch-Funktion kommt von dem überstürzten Versuch, mit dem VC-20 eine "abstraktere" Bildschirmlogik zu erschaffen.

Beim Vorgänger PET nämlich erinnere ich mich dunkel, dass CLEAR SCREEN dort in etwa so aussah:
(alles in hex., Bildspeicher ab $8000 angenommen)

LDX#00
LDA#20
loop:
STA 8000, X
STA 8100, X
STA 8200, X
STA 8300, X
DEX
BNE loop
RTS
(Edit: kann sein, dass der 4. Block nur 24 bytes weniger gefüllt hat, insoweit verkürzte Darstellung)

Nix "Zeilenadressen mühsam berechnen", Farbram sowieso nicht, ABsolut-X-Indexierung statt Zeropage-Zeiger; Schleifenvariable Dekrementieren 1x je 4 Speicherbefehle ... also minimaler Overhead und maximal auf Geschwindigkeit getrimmt!

Garbage Collect : wäre toll , wenn man die Lösung von BASIC 4 aufs wesentliche eingedampft hier in den 9 KB mit unterbrächte.

macht wieder nur 2 Bytes Mehraufwand (s.o.) - pro String

Zitat von BlondMammuth

Was die Konzepte betrifft: Auch der Olympische Gedanke hindert die Athleten ja nicht, die neuesten Materialien und Technologien für das Schuh-Werk und beim Training die neuesten Erkenntnisse in der Sport-Medizin zu nutzen. Dieselben Technologien nutzen dann viele andere ausserhalb der Olympischen Spiele mit ganz anderen Zielsetzungen auch, aber die harte Grenze zwischen dem "fairen" Bewerb und dem Doping verschwindet deshalb ja nicht, und sollte es auch wirklich nicht!

Wie macht man es denn auf forum64, einen Moderator zu bitten 2 Themen daraus zu machen?

Neuer Thread: "Vision: Wie kann eine Von Grund auf unter modernen Erkenntnissen neu gestaltete System-Software auf Basis eines Original-C64 aussehen? In 16 KB ROM"

Bisheriger Thread: "Vision: Wie können möglichst viele Unzulänglichkeiten des BASIC V2 unter Nutzung moderner Analysemethoden behoben werden - in den vorhandenen 16 KB ROM"

Beides impliziert, dass Steckmodule usw. einen noch tiefergehenden Nutzen aus der verbesserten Firmware ziehen können.

Zu deiner Metapher - ich bitte dich keines Weges "den Mund zu halten", denn die Metaphern sind überzeugend - mit dem "Schuhwerk aus neuesten Materialien":

Ich habe in den 80er Jahren mal die ROMs von C128 und C116 (und C64) einer statistischen Analyse nach den am häufigsten verwendeten Opcodes der Maschinensprache unterzogen.

Das war ein Basic-Programm, das im Grunde das ganze ROM zeilenweise disassembliert hat (man konnte kumulativ neue Einsprungpunkte manuell vorgeben) und dann die Liste sortiert abgelegt hat.

Spitzenreiter war der Opcode $20 für JSR.
Häufigkeit des Vorkommens C128 > C116 >> C64
... woraus ich schloß, dass der C128 wesentlich tiefere "Schachtelung" (Hierarchie) von Funktionalität bietet und insofern "effizienter" ist (leider Fühlungsvorteile die man mit mehr ROM leichter in die Scheune fahren kann, weil die Suche nach bereits vorhandenen Routinen beim Programmieren eher fündig wird.)

Um wieviel mehr wären solche Auswertungen und Analysen unter Excel oder OpenOffice auf dem PC
fruchtbringend! Das zu deiner Idee "Neue Materialien". Die so auf dem PC gewonnenen Erkenntnisse könnte man dann als statistische Basis nutzen für die bessere neue Firmware für den 6502.

Nachtrag (ausnahmsweise nicht als Edit):

Michael Steil (der von der Pagetable-Seite, der das CBM BASIC V2 komplett disassembliert und auf dem PC zu einer Scriptsprache statisch rekompiliert hat und dabei natürlich gewaltige GEschwindigkeit erzielte - interessant wäre, wie sich dies in Relation zu nativem Visual BAsic auf Windows verhält!) ging gewissermassen den umgekehrten Weg. In Relation zu unserem Thema hier vielleicht nicht weiterführend, da er die Funktionalität nicht angetastet hat. Aber es ermöglicht vielleicht einen neuen Blick auf die Alte Software.
er hat auch alte Quelltexte aufgestöbert von Basic V2 und Software-Archäologie betrieben.

(WIMRE )
Diese alten Quelltexte sind in einer mit Makros auf 6502 hin umgebogenen PDP-11-Assemblersprache geschrieben !!!
Alle immediate-Operanden wurden oktal dargestellt
Und wurden offenbar auf einem Time-Sharing-Betriebssystem der mittleren Datentechnik erstellt!

neuer Thread hier:
Vision: auf der klassischen Original-Hardwarebasis eines C64 von Grund auf neu geschaffene moderne System-Software in 16 KB ROM?

Wenn es ein wirklich funktionsidentisches BASIC-Remake wäre, müsste es 50% weniger ROM beanspruchen für 100% dieselbe Funktionalität, um mich zu begeistern.

Ich habe aber gehört, dass basic heute sich anderen Sprachen stark angenähert hat. Dies müsste mindestens einfließen. Man könnte auch sagen "In Summe soll die Funktionalität gleich bleiben".

Die Änderungen würden eher subtil ablaufen, unter der Haube. Hier und da erweiterte Syntax-Möglichkeiten von Befehlen. Gestraffte Abläufe, bessere Suchverfahren (intern). Volle Dateikompatibilität zum bisherigen Basic 2, zusätzliche Funktionalität meinetwegen nur per SYS-Befehlen (mit Parameterübergabe) die aber fest im ROM sitzen /auch ohne eigene Token.

Hier in diesem Thread dürften die behutsamen Änderungen Vorrang haben.

Früher wurde hier hauptsächlich überlegt, ob man die Grafikbefehle von Basic 3,5 oder Basic 7 übernimmt.
Bei realistisch zurechtgestutzter Betrachtung sehe ich es so:

Als ich Facharbeit schrieb, bei der Kurven und Diagramme errechnet und am Bildschirm dargestellt werden sollten, sagte mein Lehrer sinngemäss: "Hauptsache, Sie haben einen Rechner der einen Hochsprachen-Befehl zum Setzen und Löschen eines einzelnen Bildpunkts in der Hires-Grafik kennt. Mehr braucht es eigentlich nicht."

Und hier ist es nun so, dass der original - C64 rein gar nichts, nüscht, nada, niente, zero an Grafikbefehlen in seinem Basic V2 hat. Kümmerlich! Ein schwaches Bild, wörtlich und übertragen.

Deshalb ist ein im ROM verankerter Befehl entsprechend "GRAPHIC 1,1" und "... 0" zur Modusumschaltung,
sowie ein Befehl zum Bildpunkt setzen und Löschen ein riesen Fortschritt (schon wegen der verschrobenen Speicheraufteilung.) Es braucht keine ELLIPSE, CIRCLE, BOX DRAWLINE und so weiter Instruktionen.

Der Unterschied zwischen "Bildpunkt-Setz-Befehl vorhanden " und "Nicht vorhanden" ist viel riesiger, als die Frage ob 10 oder 20 Grafikbefehle existieren.

Verzichten kann man m.E. auf das Token "GO"

Die beiden Threads sind dialektisch aufeinander bezogen.
Man wird im Zuge der Arbeiten immer wieder auf Dinge stoßen die man an die jeweils andere Abteilung wird "outsourcen" wollen

Meine o.g. Überlegungen (#186) bezogen sich auf die Optimierung des bestehenden ROMs.
Der Befehl zum Setzen / Löschen eines Bildpunkts könnte irgendwo im ROM sitzen und zum Aufruf per SYS gestaltet sein. Wenn Platz ist....

Zitat von Hexworx

Es wäre wirklich mal interessant, was man im BASIC/KERNAL so freischaufeln könnte, so dass es soweit immer noch absolut rund läuft. Ich hätte da schon meinen Spaß dran und werde das mal nebenbei in Angriff nehmen

Es gab ja auch von Commodore verschiedene ROM-Versionen desselben Basic V2.

Man könnte ein "Diff" fertigen und daraus ableiten, welche Änderungen (Umfang) von Commodore selbst als "noch original" , "autorisiert" bzw. "kompatibel" angesehen wurden.

Zitat von Hexworx

Ein paar (oft gewünschte) kleine Verbesserungen hätten/sollten aber irgendwie Platz gefunden haben: RESTORE X / IF-THE-ELSE und ein (kombinierter?) CLS- bzw. FILL-Befehl á la CLS (Screen) bzw. CLS 32768,8192,0 (Bitmap löschen). Die CLS-Routine ist ja leider so blöd gestrickt, dass man da nicht mit einem Wert reingrätschen kann (fest SPACE $20). Mit den Dingern wäre einem schon viel mit geholfen gewesen.

Hier mal ein praktisch orientierter Umsetzungsvorschlag von meiner Wenigkeit:

Routine "Zeile füllen" ab $E9FF soll nutzbar werden mit beliebigen Füllbytes ausser "Space".
wird bisher im Kernel insg. 3x benutzt (scroll, insert Line, VIC_Init nach REset)

Neu:
===
; Einsprung kompatibel zu bisher: $E9FF
E9FF LDA #$20
; Einsprung neu, beliebiges Füllbyte in Akku mitgebracht: $EA01
EA01 JSR $E4D7 ; ex E4DA; neu: Aufrufe von E9F0 und EA24 werden dorthin ausgelagert;
ea04 LDY #$27 ; 39 + 1 = 40 Spalten
EA06 PHA ; neu: Füllbyte retten
EA07 LDA $0286 ; bisherige Rucksack-Routine E4DA "aufgelöst" , Farbram setzen
E40A STA ($F3),Y ; noch
E40c PLA ; neu: Füllbyte wieder holen
EA0d STA ($D1),Y ; Screenbyte füllen
EA0f DEY
EA10 BPL $EA06 ; Loop
EA12 RTS

bisheriger Einsprungpunkt E4DA wird E4D7 und der bisherige dort befindliche alte Rucksack-Routinen-Inhalt "Farbram-Adresse setzen" wird direkt in Routine E9FF /ab Ea07 gebracht, als Instruktionsfolge "LDA 286 ; STA (F3),Y".

E4D7 PHA
E4D8 JSR $E9F0 ; d1/d2 address pointer besetzen.(XR lesend benutzt)
E4Db JMP $EA24 ; f3/f4 aus d1/d2 besetzen. (benutzt ACCU, ORA)
E4De PLA
e4df RTS

(und der andere Rucksack E4D3 wird nach e4D0 vorverlegt, Erweiterung in ungenutzen Bereich um 3 Bytes, da beide Routinen nur 1x vom gesamten Kernel benutzt sind, ist es unproblematisch.)

Für die Routine "Bildschirm löschen" ab $E544 ist eine bytemäßig "aufkommensneutrale" kleine Änderung in Vorbereitung (edit) die es ermöglicht, nicht nur 1 Zeile sondern den ganzen Screen mit einem frei wählbaren Byte zu füllen . Dort würde dann EA01 statt E9FF aufgerufen.

Zitat von JeeK

Das wäre noch eine der leichteren Übungen.Die Garbcol-Implementierung aus dem 64er Oktober 1988 (die in der abgedruckten Version zwar buggy ist) ersetzt die bestehende GC-Routen genau mit der Back-Link-Implementierung des BASIC 4 (die dann auch in BASIC 3.5 und BASIC 7.0 Eingang fand), braucht aber nur geringfügig mehr Platz, der im konkreten Fall durch Verkleinerung der Einschaltmeldung und dem Freibereich im KERNAL-ROM ($aa-Füller) auskommt, also ohne auf Kosten der Tape- oder RS-232-Routinen zu gehen. Bei dem Algorithmus gibt es m.E. nichts mehr einzudampfen. Man könnte ihn ein paar mal von unterschiedlichen Entwicklern komplett von Null weg entwerfen und implementieren, wo sich dann vielleicht ein paar Byte Unterschied ergeben dürfte, mit einem Gewinn, der vermutlich eher lächerlich verglichen mit dem Aufwand sein dürfte - die Eindampfungsmöglichkeiten werden da vielleicht gemeinhin überschätzt.
Ad Kompatibilität: Da muss man sich auch im Klaren sein, dass hier jeder String am Heap 2 Bytes mehr braucht, was bei umfangreicheren Programmen, die mit großen Stringarrays arbeiten, dazu führen könnte, dass dieses nicht mehr lauffähig ist.

Fantastisch, faszinierend! Man muss das Rad nicht unbedingt neu erfinden. Schön, dass das schon jemand gemacht hat. (gab es nicht mal ein 64er Preservation project, wo man das nachlesen könnte? viele Dokumente-Erhaltungsprojekte sind leider um 2008 herum eingeschlafen.)

Besonders schön , dass es nicht auf Kosten der Tape- und RS232-Routinen ging. Das trägt dem olympischen Gedanken Rechnung.

Ad Kompatibilität:
Sicherlich gibt es im Extremfall Fälle, wo der Speicher dann nicht mehr ausreicht. Bei einer angenommenen mittleren Stringlänge von 16 Byte immerhin ein Mehrbedarf von 12,5%... aber wenn Programme den Speicher derart aufzehren , sind sie vermutlich eh mehr "Betreuungsintensiv" und bedürfen gewisser "Wartung"

Ich hätte die Probleme eher bei Programmen vermutet, die "oberschlau" sein wollen und in Eigenregie mit PEEK und POKE an Strings herumbasteln. Diese könnten auf die Nase fallen wenn der String intern "Länger" wäre. Aber auch hier gilt das weiter oben gesagte. Und gemessen am Gewinn an Leichtigkeit und Stetigkeit des Programmflusses (ich denke die neue GarbColl wird auch zu kleinen Rucklern führen aber halt nicht mehr so extrem wie in Basic V2) wäre das minimal.

- - -
Zu meinem obigen Beitrag ist mir noch eingefallen, dass ich zwar wüsste wie man in der CLear-Screen Routine ab E544 noch 5 Bytes freiklopft um den Bildschirm mit beliebigen Werten zu füllen und nicht nur "SPACE" ($20), ich aber dennoch nicht recht weiß, was das eigentlich soll.

Weil, wenn es nur darum ginge den Grafik-Bildschirmbereich zu löschen -
- gibt es überhaupt etablierte Standards, wo man beim C64 den "hintut" ? - Startadresse -,
dann everything boils down to a loop similar the following:

EA0A A9 xx LDA #$Byte
EA0C 91 D1 STA ($D1),Y
EA0E 88 DEY
EA0F 10 F6 BPL $EA07
EA11 60 RTS

so, in order to re-use those 8 Bytes of code (!) one has to shuffle around dozends of bytes in subroutines. One would be much better off with a complete re-implementation in unused area of kernel. Instead of overburdening the built-in CLS routine.

Verzeihung für die Sprachverwirrung. Mein Gehirn ist immer noch überlastet von Optimierungsvorgängen.

Danke für Deinen Beitrag.

Dennoch, bei näherem Hinsehen, führt er zu einem Verlust an Funktionalität in dem Sinn, dass der eine Schlüsseleigenschaft von Basic mindern würde:

https://de.wikipedia.org/wiki/BASIC#Allgemeines

• Für Anfänger leicht zu erlernen
• Universell einsetzbar
• Erweiterbarkeit der Sprache für Experten
• Interaktivität
• Klare Fehlermeldungen
• Kurze Antwortzeiten
• Hardwareunabhängigkeit
• Betriebssystemunabhängigkeit

(Von mir hervorgehoben)
Da BASIC konstitutiv die Eigenschaft "KLARE Fehlermeldungen" aufweist, erscheint mir der Vorschlag nicht ganz passend. Zudem gab es ja gerade von Microsoft Vorgängerversionen ebendieses Basic V2 die statt 9 KB eben nur 4 KB beanspruchten. Und genau die hatten auch die verkürzten Fehlermeldungen von denen der Kollege weiter oben schon sprach. (Zwei-Zeichen-Kürzel).

Wenn Du aber eine Idee hast, wie man die ganzen "bad subscript" "GOSUB / FOR.. without .. RETURN / NEXT" - und-umgekehrt - Fehler gepackt ablegen kann und on-demand entpacken kann und die Packroutine weniger Platz braucht als insgesamt damit eingespart würde - - - ich wäre dafür aufgeschlossen