Optimierungsgrad KERNAL /BASIC - fiktiver Talk

Es gibt 337 Antworten in diesem Thema, welches 62.639 mal aufgerufen wurde. Der letzte Beitrag (16. September 2017 um 00:34) ist von Boulderdash64.

  • Also wenn man ein nummerisches GET haben will ruft man einfach das Unterprogramm GETIN mit :sys getin: auf, den Tastencode kann man dann mit peek(780) lesen.

    Die von mir geposteten Unterprogramme zur GBC-Vermeidung sind auf mehrere Threads verteilt.
    Wie z.B. Feststring-Verwaltung, Garbage-Collection Vermeidung und ROM-RAM Kopy.

    Schönen Gruß.

  • (..) Eigentlich wären GET und INPUT doch eher Funktionen statt Befehle? Es ist irgendwie doof, sich ändernde Variablen auf der rechten Seite zu haben, A$=GET wäre einheitlicher (Vorsicht flach: STRINGenter ). und evtl. könnte dann das Unterprogramm entfallen, das explizit eine Variable sucht.

    Wieso?
    TI, TI$, ST, RND, .. um nur einige zu nennen, (hab ich welche vergessen?) ..
    ebenso PEEK(n) mit n € {Zeropage} sind in Basic V2 allerhand "Variablen" (im engeren und weiteren Sinn) die in einer Zuweisung rechts stehen können und sich ändern können.

  • Wieso?TI, TI$, ST, RND, .. um nur einige zu nennen, (hab ich welche vergessen?) ..
    ebenso PEEK(n) mit n € {Zeropage} sind in Basic V2 allerhand "Variablen" (im engeren und weiteren Sinn) die in einer Zuweisung rechts stehen können und sich ändern können.

    Ja neee.... Klar, die dürfen alle auf der rechten Seite einer Zuweisung stehen, und ändern dürfen sie sich auch.
    Aber das ist ja alles im Rahmen normaler Zuweisungen, mit (Let)Variable links vom Gleich.

  • Okay ...
    Bei den Strings: GC mit Backdeskriptoren und evtl. eine geschmeidigere Schnittstelle mit GET das ASC-Werte als Funktionswert zurückgeben kann und ebenso bei MID$ die Möglichkeit einen ASC-Wert zu bekommen statt einen neuen String anzulegen; die Feststringverwaltung könnte - bereichert um eine geläufigere Benutzerschnittstelle und im ROM mit untergebracht ebenfalls Vorteile bringen.

    Zur Numerik:
    Hier kommt anscheinend bislang die Taylor-Reihenentwicklung zur Anwendung die recht platzsparend ist, da dieselben (?) Routinen nur mit anderen Parametern "beliefert" die ganzen Winkelfunktionen, SQR, Power etc. liefern können. Schneller wäre CORDIC, wie jemand (wahrscheinlich Mike) schon vor Jahren in einem anderen Forum schrieb. Aber wäre es auch genauso platzsparend für die ganzen "Nebenfunktionen" ausser dem Sinus verwendbar? Angeblich geht sogar die Multiplikation ins "Cordic-Corsett"...

    Zur gegenwärtigen Platzaufteilung (alles ca.-Angaben)
    9 KB Basic im engeren Sinn = unteres ROM
    im oberen ROM bis ca. $E4XX;
    ab $E500 1,3 KB FullScreen-Editor
    ab $EA00: 0,7 KB Tastaturabfrage incl. IRQ
    ab $ED00: 0,5 KB serielle IEC-Routinen
    ab $EF00: 0,25 KB serielle RS 232-Schnittstelle
    ab $F000: restl. Kernal , File-IO, Load, Save u.a.

    Nicht nur aufgrund der vielen Tabellen kommt mir die Tastaturabfrage vor allem im Vergleich zu den diversen seriellen Routinen erstaunlich aufwendig vor.

  • Die Peeks und Pokes zum Stringtausch würden mit der schnelleren GBC nur noch auf den ersten Blick funktionieren. SObald eine GBC kommt würden so getauschte Strings Chaos produzieren.
    Falls man diese Inkompatibilität akzeptieren kann, dann sollte wenigstens ein SWAP-Befehl her.

  • ich sehe ein, dass man sich mehr oder minder entscheiden muss, entweder Garbage Collection a la Basic 4, oder Feststringverwaltung a la BIF.

    SWAP wäre ein neuer Befehl (mit Token) ...

    Wie würdet ihr es mit den vielen kleinen Aufbesserungen halten, die jetzt schon in Basic 2 enthalten sind, OHNE dass sie ein token haben? die mühsam aus dem Eingabestrom (Basic-Text) herausgefiltert bzw. gefischt werden müssen, wie z.B.:

    TI, TI$, "pi" (3.141592...), ST

    Gegenwärtig werden da jeweils einzeln Vergleiche durchgeführt und dann in den Extra-Code verzweigt. Ich frage mich warum das so ist, wo der Hersteller ja durchaus ein Token hätte "spendieren" können ... auch für diese vielen kleinen Kleckerkram-Routinen ...
    Lässt sich hier irgendwas zusammenfassen oder sparen?
    (Warum wird nicht die Echtzeituhr des CIA-Bausteins für TI / TI$ genutzt? Uhr an die Hardware delegieren, spart Raum und Zeit in der Interrupt-Routine)


    Ich frage mich, warum es hier bislang keine TOKENs gibt, bzw. warum dies keine Funktionen sind...

    Noch was anderes zum Thema dieses Threads:
    -> Sollten wir aus der Fragestellung mal eine echte "Compo" = einen Wettbewerb machen?
    -> oder eine kollaborative Anstrengung bzw. ein kollektives Projekt?
    In beiden Fällen z.b. mit einem Jahr Vorlauf ...

  • Noch was anderes zum Thema dieses Threads:
    -> Sollten wir aus der Fragestellung mal eine echte "Compo" = einen Wettbewerb machen?
    -> oder eine kollaborative Anstrengung bzw. ein kollektives Projekt?
    In beiden Fällen z.b. mit einem Jahr Vorlauf ...

    Gegenfrage: Welchen Nutzen hätte das Ganze?

    Ich lese hier auch immer (gern) mit, aber es wird letzten Endes wohl eine rein theoretische Sache bleiben, weil da wohl keiner ernsthaft beigehen wird. Ich sicherlich auch nicht. Möchtest DU?

    Selbst, wenn man das BASIC (stellenweise) 10-20% beschleunigen könnte, würde es (leider) kaum jemanden interessieren. Ist nun mal so.

    Bei dem Code-Wust kann man doch froh sein, dass es überhaupt läuft. Und da jetzt noch Hand anzulegen, kann nur in einer mittleren Katastrophe enden, es lauffähig zu halten/zu bringen.

    Zugegeben stellenweise schöne Denk-Gespinste, aber eben doch leider wohl alles nur Totgeburten, weil sie nie umgesetzt werden (würden).

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • Ich würde mein System mehr als manuelle Stringbereinigung ansehen.
    Durch das setzen des Stringgrenzenzeigers kann man String im Stringram kopieren oder einfach nur die Pointer tauschen.

    Mit dem Befehl smem merkt man sich die aktuelle Stringzeiger-Position.
    mir :sset: könnte man die auf die gemerkte Position zurücksetzen und so temporäre Strings vergessen.
    mit :sset adresse: könnte man den Stringzeiger auf eine beliebige Position setzen.
    z.B. um einen String an diese Adresse zu kopieren.

    Also in dem Feststring-Listing nutze ich den freien Platz, der entsteht, wenn es eine neue Zuweisung an den selben String gibt.
    Das beruht auf der Tatsache, daß der neue String, der gleichlang oder kürzer ist in die Lücke eingefügt wird.

    Meine Software-Lösung beruht darauf, unnötiges Stringanlegen zu vermeiden.

    Grundsätzlich halte ich das Prinzip der GBC-Vermeidung für das professionellste, da die GBC/ bzw. eine Programmunterbrechung dann überhaupt nicht stattfindet.


    Schönen Gruß.

  • Ob das etwas bringt, das System zu beschleunigen ?
    Selbstverständlich ja, und zwar mehr Geschwindigkeit.
    Und insbesondere für Anfänger mehr Einfachheit.

    Grundsätzlich bringen aber natürlich auch die von mir veröffentlichten Basic-Listings auch schon einen erheblichen Geschwindigkeitsgewinn.
    In Maschinensprache umgesetzt ist das natürlich noch schneller.

    Schönen Gruß.

  • Grundsätzlich könnte man natürlich auch mal überlegen, wo man insbesondere mehr Geschwindigkeit benötigt.
    z.B. beim Cursor-Setzen oder Sprite-Setzen oder Pixel-Setzen.

    Schönen Gruß.

  • BIF: EINFACH mal umsetzen/coden, was du alles so denkst.

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • Gegenfrage: Welchen Nutzen hätte das Ganze?

    Ich lese hier auch immer (gern) mit, aber es wird letzten Endes wohl eine rein theoretische Sache bleiben, weil da wohl keiner ernsthaft beigehen wird. Ich sicherlich auch nicht. Möchtest DU?

    Selbst, wenn man das BASIC (stellenweise) 10-20% beschleunigen könnte, würde es (leider) kaum jemanden interessieren. Ist nun mal so.

    Ich glaube, die Tageszeit hat nicht besonders begünstigt, dass du meiner Idee etwas abgewinnen kannst :wink:
    Die Frage nach dem Nutzen kannst du hier in diesem Forum bei vielen Dingen nicht stellen...weil viele Leute sehr verschieden empfinden ... ich versuche sie aber dennoch zu beantworten, weil ich diesen - subjektiven ! - Nutzen sehr wohl seh!

    In der Zeitschrift c't stand damals (TM), das heisst wohl Ende der 80er Jahre, als auch die C't-Hochsprachen-Benchmarks "erfunden" wurden (die ich dann auf meinem Basic 3.5 und Basic 7 - Rechner umsetzte und erstmals ein Gespür bekam wie langsam die im Vergleich zu manchem CP/M Rechner sind), dass eine Verdoppelung der Geschwindigkeit "gerade eben spürbar" sei. In diesem Sinn setze ich mir als Ziel, also eine Steigerung um 100% zu erreichen, wobei notwendigerweise eine Unschärfe bleibt, ob dies durchgängig ist oder vielmehr nur "im Mittel" und welcher Mix an Nutzungsprofil dabei zugrundeliegt. Ausserdem sehe ich folgendes: wenn schon damals mit maschinensprache ein Basic-Programm aufgemotzt werden konnte, vom sehr beschränkten Basic-V2 ausgehend, um wieviel "höhere Höhen" an Kunst wird erreichbar werden, wenn die Basis-Linie (durch das eingebaute Basic) nach oben verschoben wird? Wenn die Rom-Routinen des Basic verbessert werden, verschiebt sich das Gesamtsystem um mehrere Größenklassen.

    A.) Denn es wird viel Speicher frei, der bislang in POKE-Wüsten geopfert wurde;
    B.) es wird neue Kreativität frei, und stimuliert, wenn Basic schon von Haus aus schneller wird und die Hobby-Coder das neue "Normal" zu übertreffen suchen, mit neuen Algorithmen usw.

    Ich glaube es würde viele interessieren, aber es würde eine unterschiedlich lange Zeit dauern bis verschiedene Zielgruppen dessen Wert für die "Retro-Programmierung" lamgfristig erkennen. Wen spricht so ein runderneuertes ROM an?

    1. Inhaber von Retro-Hardware, die die (immer noch) bestehenden Beschränkungen als Herausforderung ansehen und die gern (wieder) ins Programmieren einsteigen würden;
    2. Programmierer von neuen Projekten, die für mehr Speed und tlw. Komfort und vor allem eine standardisierte Basis-Plattform dankbar wären;
    3. "Software-Archäologen" in der Tradition von Michael Steil die auch neue Projekte erstellen oder sogar am Portieren alter Basic 3.5 - 7 Programme aber auch direkt Basic V2 auf die neue Plattform (ich nenne sie vorläufig Basic 2.5) interessiert sind und daran Spaß haben, da das neue System schnelleren Turn-Around und im Idealfall lesbarere Programme fördert;
    4. Käufer von neuen alten Tastenkappen in neuen Farben und Materialien, neuen alten C64C- Gehäusen aus soliderem chlorchemie-frei hergestelltem Kunststoff :wink: , neuen alten Brotkastengehäusen ;
    5. Besitzer einer SuperPLA und einer SRAM-Umrüstplatine, die sich auch ein nach aussen unscheinbares, aber unter der Haube runderneuertes ROM für Ihren Rechner vorstellen können und sehnlichst wünschen :wink:
    6. alle, die sich Schritt für Schritt für alle Bausteine / IC's dieses alten 8bit-Rechners einen aktuellen Ersatz wünschen, der behutsam erneuert ist und - z.b. durch die Beschränkung auf die Original-Größe 8KB (16KB mit Kernel) - doch authentisch ist. Auch die Original-ROMs altern und gehen kaputt und werden knapper... die Frage ist, begnügen sich alle Interessierten mit einem Original-Eprom (ggf. mit Kernel-Umschalter oder Simons' Basic?), oder "darfs ein bisschen mehr sein, und doch original", verbunden mit der spannenden Aufgabe, jene 20% erhaltenswerte Lieblings-Software die nicht kooperiert, zu patchen dass sie doch läuft.
    7. Alle die sich einen Extrakt aus bisherigen Basic-Erweiterungen , Kernelumschaltungen etc. wünschen, eine Art Schnittmenge oder Standard, an dem man sich richten kann.
    Edit:

    Es ist ein bisschen wie die Sanierung der Wärmedämmung und der Heizungsanlage in einem denkmalgeschützten Haus:
    - Die Dämmung darf wenn dann nur innen angebracht werden, weil der Umbaute Raum nicht größer werden darf (= entspricht der Beschränkung der ROM-Größe auf das Original, 8KB)
    - Der Heizkessel (= Prozessor) wird entweder genausogroß oder kleiner sein als der alte, keinen neuen Wanddurchbrüche für Ölkeller o.ä. erfordern und keinen neuen angeflanschten Edelstahl-Kamin für die Brennwertheizung, sondern die Rohre werden im alten Ziegel-Klinker-Kamin verlegt = der Rechner braucht keine neue Zusatzhardware bzw. die Gatteranzahl bleibt ziemlich dieselbe und wird auch nur mit originalgetreuen Mhz-Zahlen getaktet sondern weiter mit größenordnungsmässig 1 Mhz.

  • [...] Wärmedämmung [...] Heizungsanlage [...] Heizkessel [...] Ölkeller [...] Kamin [...] Brennwert [...]

    Welch passendes Bild für diesen Thread: nichts außer heißer Luft.

    EINFACH mal umsetzen/coden, was du alles so denkst.

    +1

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Ich persönlich versuche natürlich die Programmieransätze erst mal in Basic umzusetzen.
    Mit einem guten Ansatz kann man natürlich auch da schon zu erheblichen Geschwindigkeitsgewinnen kommen.
    Die ein oder andere Innovation hab ich auch schon in Maschinensprache umgesetzt.
    Wie z.B. ein Kettenpoke.
    :poke adr,a,b,c,d,e,f,g:
    Also grundsätzlich muß man damit beim poken nicht mehr den Umweg über datas gehen.
    Bei Tests zeigt sich das man mit dieser einfachen Veränderung schon einen erheblichen Geschwindigkeitsgewinn erzielen kann.
    Auch die Listings werden dadurch erheblich kürzer und übersichtlicher.

    Schönen Gruß.

  • :poke adr,a,b,c,d,e,f,g:

    Ob so eine Schreibweise einen Code übersichtlicher macht, möchte ich bezweifeln.

    Wäre aber trotzdem für ein besseres, erweitertes Basic, auch für den C128 und einen dazu passenden Compiler, der noch einiges an Geschwindigkeit heraus holt, wenn man das Ganze dann in Maschinensprache übersetzt.

  • Meiner Meinung nach kürzer, schneller und übersichtlicher
    z.B.

    :poke53280,1,2,3,4,5:rem--farben setzen:

    im Vergleich:

    :poke53280,1:poke53281,2:poke53282,3:poke53283,4:poke53284,5:rem--farben setzen

    oder

    poke53248,1,2,3,4,5,6,7,8:rem---zeichen poken


    Wenn man zusätzlich die Fehlermeldung abschaltet hat man auch bei 2-Byte Pokes Vorteile:

    :poke781,a,a/256:rem-2-byte-poke

    statt
    poke782,a/256:poke781,a-peek(782)*256:rem-2-byte-poke


    Schönen Gruß.

  • Anknüpfend an deine Beobachtung hier:

    Ausserdem sehe ich folgendes: wenn schon damals mit maschinensprache ein Basic-Programm aufgemotzt werden konnte, vom sehr beschränkten Basic-V2 ausgehend, um wieviel "höhere Höhen" an Kunst wird erreichbar werden, wenn die Basis-Linie (durch das eingebaute Basic) nach oben verschoben wird? Wenn die Rom-Routinen des Basic verbessert werden, verschiebt sich das Gesamtsystem um mehrere Größenklassen.

    Das ist nun mal ein Aspekt, der in der "Schaffung" von BASIC-Erweiterungen bzw. mit SYS aufrufbaren Bibliotheken ganz besonders zum Tragen kommt. Letztenendes geht es ja immer darum, in wieviel Speicher gegebene Funktionalität untergebracht werden kann. Eine BASIC-Erweiterung soll idealerweise Befehle passend zur Anwendung oder zum Anwendungsbereich zur Verfügung stellen, die in purem (V2) BASIC entweder:

    - zu langsam sind,
    - unverhältnismäßig viel Platz als Unterroutine in Anspruch nehmen (-> "Kapselung" als BASIC-Befehl!),
    - wo das "Original" ggfs. fehlerhaft oder ebenfalls zu langsam ist (z.B. Quadratwurzel über Heron (zu langsam)), oder
    - überhaupt nicht in BASIC umsetzbar sind (Floppyspeeder, Änderungen des Tastaturmappings, IRQ-Routinen, etc.)

    Auf der Ebene der Einzelbefehle ist schnell was drangebaut - interessanter wird's schon, wenn man an den Unterbau drangeht und die Formelauswertung, Kontrollstrukturen und Speicherverwaltung modifiziert.

    Am Anfang dieses Threads wurde genau letzteres (also: verbesserter Unterbau) in den Vordergrund gestellt. Denn BASIC-Erweiterungen verschiedenster Coleur gibt's ja nun wie Sand am Meer und mit wenigen Ausnahmen werden sie meist nur von deren Programmierern selbst genutzt. Oder noch nicht mal das. Aber dazu später mehr.

    Zwischenzeitlich habe ich dann auch die Ansicht kundgetan, daß ein verbessertes BASIC V2 (wie laut meinem "Manifest") mit Sicherheit nicht in 9K (+7K KERNAL) zu haben ist. Insofern beißt sich die Diskussion hier an dieser Stelle fest. Was mit dieser Voraussetzung *möglicherweise* geht, ist, mit Hilfe eines unterlagerten Interpreters zeitunkritische Routinen ggfs. einzudampfen, so daß genügend Platz frei wird um echte Hemmschuhe (wie gesagt, die olle GC) loszuwerden. Alles darüber hinaus ist meiner Meinung nach Wunschdenken. Zudem besteht ja immer die Möglichkeit, anwendungsspezifische Bibliotheken in Maschinensprache als "Nachbrenner" einzusetzen.

    Da gibt es dann ein Problem bei unzähligen BASIC-Erweiterungen: die bringen vielleicht ein paar Befehle mit, die einem wirklich helfen, der viel größere Teil bleibt häufig ungenutzt. Die zugehörigen Routinen liegen dann als toter Code herum und nehmen schlimmstenfalls dem eigenen Programm soviel Speicher weg, daß das ganze zusammen nicht mehr in den Speicher paßt. Bei einigen der POKE+SYS-Erweiterungen die es früher auch mal zum Abtippen gab, hatte ich recht häufig den Eindruck, daß viele der angebotenen "Befehle" auch so mit ein paar POKEs erledigt waren, und ansonsten der Programmierer entweder keinen Plan oder keine Lust hatte, einen ordentlichen (De-)tokenizer bzw. die modifizierte Interpreterschleife zu implementieren (mein persönlich empfundener Tiefpunkt in der Hinsicht ist das U.M.H.-System in zwei Teilen aus der "Compute mit" - 9/86 und 12/86).

    Es gibt bei den POKE+SYS-Erweiterungen aber interessante Ausnahmen: als sehr gutes Beispiel etwa die Library eines Life-Simulators, der in der 64'er 1/86 (ab Seite 69) abgedruckt war. Das Programm zeigt wie's gemacht wird: zeitunkritische Routinen wurden in BASIC gelassen, die zeitkritischen Teile sind in Maschinensprache.

    Ich bin der Auffassung, daß man mit dem gleichzeitigen Einsatz von BASIC und Maschinensprache das beste von beiden bekommen kann: kompakter und einfach durchschaubarer Code für die zeitunkritischen Teile in BASIC, Maschinensprache für alles, was schnell sein muß und wo es nicht unbedingt auf extrem kleine Codegröße ankommt. Dann ist die Herausforderung nur die, die Aufteilung optimal zu wählen und man muß natürlich wissen, die man Daten zwischen den beiden Sprachen austauscht. Ersetze BASIC ggfs. durch eine dem Leser genehmere Skript-Sprache.

    Will man es noch etwas dekadenter, kann man ja gerne eine auf den Anwendungsbereich optimierte BASIC-Erweiterung schreiben, damit das ganze mit Befehlen anstatt POKE+SYS etwas professioneller aussieht. ^^

  • Also dazu hab ich ja auch schon mal was gesagt.

    Statt Poke+Sys schlage ich ein String Sys vor.

    :sys befehl$:

    Hierbei liegt der Maschinen-Code in Form von Strings vor und wird dann per Sys-Befehl aufgerufen.

    Schönen Gruß.