_ich_ will den ja auch nicht einbauen; beim ZX80 ff. war das ja auch nur eine Notlösung, um den Interpreter samt Zeichensatz in 4K ROM unterzubringen. Da war weder für ON...GOTO Platz noch für eine eigene Zeilennummer-Auswertung- also hat man den normalen Ausdrucks-Berechner genommen. Geht genauso gut, nur aus LIST 10-100 wird ein LIST 10,100 weil er aus der Standard-Form mit Bindestrich eine Differenz macht und versucht, ab Zeile -90 zu listen...
Optimierungsgrad KERNAL /BASIC - fiktiver Talk
Es gibt 337 Antworten in diesem Thema, welches 62.652 mal aufgerufen wurde. Der letzte Beitrag (
-
-
- Offizieller Beitrag
Äh .. spinn ich schon total? Turbo Pascal für C64? Ich kannte Oxford-Pascal, Profi-Pascal, G-Pascal, Kyan-Pascal .. Abacus-Pascal .. aber Turbo-Pascal? Wo gibts denn das?
Turbo Pascal mit dem CPM Modul

Bitte melde dich an, um diesen Link zu sehen. -
Turbo Pascal mit dem CPM Modul
Ach so, na mit Gewalt isses ja keine Kunst!

-
Ich als alter c64 Turbo Pascal User
(..)
Dann schreib doch bitte gleich "Turbo Pascal User mit dem C64/Z80-Modul", nicht dass falsche Hoffnungen geweckt werden
Edit:
TheRealWanderer:
Zitat ist verrutscht ... hatte mich an daybyter gewandt
sorry -
- Offizieller Beitrag
Bitte melde dich an, um diesen Link zu sehen.:
Warum soll ich das schreiben? Du kannst doch lesen!
Turbo Pascal mit dem CPM Modul sagt doch alles aus. Was soll das Wort "User" dabei?
Nimm bitte nicht alles wortwörtlich hier auseinander. Das nervt! -
- Offizieller Beitrag
Dann schreib doch bitte gleich "Turbo Pascal User mit dem C64/Z80-Modul", nicht dass falsche Hoffnungen geweckt werden
vielleicht sollte man auch mal erwähnen, das in diesem Thread nur lamentiert wird - nicht dass falsche Hoffnungen
(auf eine tatsächliche Umsetzung) geweckt werden!
-
Turbo Pascal kann auch in Vice genutzt werden - da ist eine Emulation für die CP/M-Cartridge vorhanden.
Spannend finde ich, das Oxford Pascal wie GPascal P-Code erzeugt. "Richtige" Compiler die Maschinensprache erzeugen scheinen beim C64 selten zu sein.
-
Tale-X: unsere Postings haben sich überschnitten .. dennoch betreffen sie im Grunde dasselbe Thema: nämlich, dass der so gelobte Beinah-orthogonale Befehlssatz des 6502 bei wirklich knappen Programmen wie es der Interpreter wohl ist, dem 8080 hinterherhinkt... und das scheint Compilerbauer abzuschrecken! Jedenfalls müsste man für über Guckloch-Optimierung hinausgehende Schritte gehörig "KI / Artificial Intelligence" investieren ... und das wäre erst recht ein Fall für die Cross-Entwicklungsumgebung ...
Falsche Frage. Du willst wissen, warum MS-Basic überhaupt einen eigenen String-Speicher hat- Sinclair-Basic kommt ja auch ohne aus. Es gibt zwar einen Arbeitsbereich für temporäre Strings und Formeln, aber der wird nach jedem Befehl zurückgesetzt. Daher gibts auch keine lästige Garbage Collection, die den Rechner scheinbar einfrieren läßt.
Wie macht das eigentlich die 8080-Version von MS-Basic? Die muß mit dem Prozessorstapel ja noch einen dritten dynnamischen Speicherbereich zügeln.
Also von Luft und Liebe ernährt sich Sinclair-Basic auch nicht, was die Strings angeht... irgendein Kern- oder Trommelspeicher wird auch dort für Strings beansprucht werden

Soweit ich sehen kann, setzt 8080-MSBASIC eine 4096-Byte-Ram-Karte voraus von der 3,9 KB vom Interpreter belegt werden und ganz am Ende werden mind. 30 Bytes für Stack freigelassen - sofern der Stack nach unten wächst - , weitere ca. 225 Bytes können wohl theoretisch für das erste Mini-Basicprogramm belegt werden. Wieviel der Nichterweiterte Zwerg-Speicher des Altair (wohl zum KIM 1 vergleichbar, vielleicht 128 Bytes.. 256) dazu noch zugeschlagen werden kann weiss ich nicht. Ebenso könnte ein Teil des Init-codes des Interpreters noch dem Stack und oder dem Programm "zugeteilt werden".
Insgesamt stimmt es sehr melancholisch wenn man sieht welch knappe Konstruktionen und 1-Byte Befehle (1-Byte-Restart-Kommandos für Syntax-Check z.B. oder mit 1 Byte Pseudo-"Operand" für Keyword-Checks) der 8080 ermöglichte. gefühlte sieben interne Register und 16bit Registerpaar ermöglichen einiges an Bewegungsfreiheit... im Vergleich zum 6502.
Soweit ich sehen kann, braucht Altairbasic nur 25 Bytes an Globalen Variablen (nicht gerechnet versprengte Flags ( Bytes) über den Code verteilt und Selbstmodifikationen) und 73 Bytes Input-Buffer. Da ist man beim C64 meilenweit entfernt von soviel Genügsamkeit.Obwohl, wie sieht es denn mit dem VC10-Ultimax-Mini-Basic aus? Das könnte doch als Blaupause für Erweiterungen dienen

-
Für was dient dieser Thread eigentlich noch? Ist das imaginärer Luftschloss Code oder passiert da noch was? Das ist nämlich so langsam ein Fall für die Laberecke und reine Fiktion statt Funktion.
Gruß
vom Pentagon / USER -
Bitte melde dich an, um diesen Link zu sehen.:
Warum soll ich das schreiben? Du kannst doch lesen!
Turbo Pascal mit dem CPM Modul sagt doch alles aus. Was soll das Wort "User" dabei?
Nimm bitte nicht alles wortwörtlich hier auseinander. Das nervt!Lediglich das Zitat war verrutscht .. du warst nicht angesprochen, pardon, wenn es anders rüberkam.
Wenn jemand von Turbo Pascal auf dem C64 spricht, ist nicht jedem automatisch klar, dass das CP/M und entsprechende Zusatzhardware voraussetzt, sondern es wird angenommen dass der 6502 dieses ausführt.@Pentagon: einige andere außer mir sowie ich selbst haben in diesem Thread bereits konkrete geänderte Code-Beispiele für das C64-ROM gepostet. Deswegen appelliere ich an Deine Geduld - die Stadt Rom wurde nicht an einem Tag gebaut und das ROM des C64 auch nicht

-
Falsche Frage. Du willst wissen, warum MS-Basic überhaupt einen eigenen String-Speicher hat- Sinclair-Basic kommt ja auch ohne aus.
Wie hat der Spektrum denn die Probleme von Variablen variabler Länge gelöst? Etwa bei Änderungen immer umkopieren, damit der Speicher am Stück gefüllt bleibt?
Nach Tante Google sind 26 Strings variabler Länge möglich, Stringarrays nur von fester Länge? -
@Hogo:
Immer umkopieren, das würde bedeuten, daß bei jeder Stringoperation eine Garbage-Collection stattfindet.
Grundsätzlich ist es am C64 möglich bei 1 Byte-Strings (oder zwei) den String innerhalb der Stringvariable zu speichern statt im String-Ram.
Dadurch hätte man schon eine Reduzierung der GBC am C64 erzielt.
Insbesondere GET könnte dann keine GBC mehr auslösen.Da wären wir auch schon beim GET-Befehl.
Viel Umsteiger scheitern bereits am GET-Befehl, da der C64 ein :GET A: nicht akzeptiert.
Das GET und Zwei-Buchstaben-Variablennamen sind meiner Meinung nach die größten Hindernisse für Umsteiger von anderen Programmiersprachen.Schönen Gruß.
-
@Hogo:
Immer umkopieren, das würde bedeuten, daß bei jeder Stringoperation eine Garbage-Collection stattfindet.So technisch/juristisch betrachtet kann man das sicher eine GC bei jeder Änderung nennen. ABer in dem Kontext bleibt da nicht viel übrig:
-Die festen Arrays werden einmal nach vorne geschoben und bewegen sich nicht mehr.
-Bei den paar Strings kann man den Speicher immer aufgeräumt halten. Quasi wie das Basic V2 mit seinen Basic-Zeilen umgeht. Das kann bei langen Programmen auch ein bisschen dauern, fällt aber bei 4KB nicht besonders auf.Grundsätzlich ist es am C64 möglich bei 1 Byte-Strings (oder zwei) den String innerhalb der Stringvariable zu speichern statt im String-Ram.
Gute Idee.
-
@Hogo:
Grundsätzlich wäre es auch denkbar, falls es sich um den gleichen String handelt, den String an der gleichen Adresse zu speichern, falls er kleiner oder gleich lang ist.Siehe auch den Thread Feststrings in der Basic-Ecke.
Also auch eine Feststring-Verwaltung wäre betriebssystemlich durchaus machbar.Schönen Gruß.
-
Ein faszinierendes Thema, die optimale Speichernutzung. Bei dermassen wenig Speicher kommt leider dazu, dass die Verwaltung a) selber Platz braucht und b) selber Zeit braucht. Sie braucht natürlich umso mehr Rechenzeit, je genauer der Speicher ausgefüllt werden soll, umgekehrt ist sie umso verschwenderischer, je weniger Rechenzeit man dafür opfern will.
Hier ein Gedankengang, der vielleicht anwendbar wäre, aber natürlich mit der existierenden BASIC-Lösung nichts zu tun hat(!):
Bitte melde dich an, um diesen Link zu sehen.
Beschrieben von Donald E.Knuth in seinem berühmte Werk "the Art of Computer Programming" ist das eine Methode, die Speicher grundsätzlich in Zweier-Potenzen vergibt. Das hieße in dem Fall, dass es recht leicht wäre, geeigneten Speicher zu finden (nämlich ein Stück, das die Größe der nächsten Zweierpotenz hat und nicht mehr gebraucht wird), andererseits wird da im Durchschnitt ein Viertel des Speichers brach liegen gelassen, und man braucht zur Verwaltung einen Speicherbaum, der mit zunehmender Fragmentierung selber wächst.
Wenn man sich überlegt, wie groß der Baum werden kann, und wie er im Speicher aussieht: Dann bräuchte jede Zweiteilung ein bit (das aussagt, ob das Ding im Ganzen bleibt oder geteilt wird), und zwei weitere bits je für die beiden Hälften. Man will die natürlich nicht jedesmal kompliziert suchen müssen, also würde man wohl eher versuchen, soviele solche Bits wie möglich in einem Byte unterzubringen, und bis dahin die Fragmentierung zu "steuern".
Für einen ganzen Bereich hat man ein Null-Byte. Teilt man es, hat man ein Bit besetzt, und zwei weitere definieren, wie es den Hälften geht. Dann braucht man für die zwei Hälften wieder je ein Bit, also zwei, und so weiter. Also kommt man mit 8 Bit auf 1+2+4 Bits, die man in einem Byte verwalten kann, und somit auf maximal eine Achtelung, die man so ausdrücken kann. Jeden solchen Bereich kann man mit einem eigenen solchen Fragmentierungs-Byte selbst wieder maximal achteln, also käme man auf maximal 64 Fragmente, wobei jedes Achtel natürlich sein eigenes Byte hätte, also sind wir schon auf 9 Bytes Verwaltungskosten. Noch eine Achtelung bringt uns auf 512 Fragmente (1+8+64 F-Bytes), und schließlich sind wir auf 4096 (mit 1+8+64+512 Bytes), und schließlich bei 32768 Fragmenten (mit 1+8+64+512+4096 Bytes), und spätestens da zahlt es sich nicht mehr wirklich aus.
Einen neuer String (oder was immer der Byte-Block dann symbolisieren kann) würde man dann so einfügen: Man "rundet" die Byte-Größe bis zur nächsten Zweier-Potenz "auf", und sucht dann (mit logarithmischem Aufwand) ein freies Fragment mit genau der Größe, und benutzt es. Wenn keines da ist, teilt man ein größeres Fragment so lange, bis man eines in der gewünschen Größe erhält.
Gibt man umgekehrt ein Stück Speicher wieder frei, sieht man systematisch nach, ob die andere Hälfte zufällig auch frei ist, und erhält so gleich ein größeres Fragment zurück.
So wird man durchschnittlich 25% des vorhandenen Speichers verschwenden, dazu ein paar hundert Bytes Verwaltungskosten, aber dafür eine vom Verwaltungs-Aufwand (vor allem von der Zeit her) her sehr effiziente Nutzung erhalten.
Nehmen wir an, wir fangen bei 64 Bytes an. Dann müssen wir 4 Bytes beackern, um auf 16-Byte-Stücke runter zu brechen (64k / 4096). Will man die noch einmal unterteilen, kann man das auf andere Weise tun, z.B. mit einem Bit pro zwei Bytes noch einmal linear runterbrechen.
Oder man beginnt mit 32 kb und bricht so in 8 Byte-Blöcke runter, die man mit je einem Byte dann noch einmal in einzelne Bytes zerlegt, wenn man will. Die Wikipedia-Seite beschreibt tatsächlich auch noch, dass man eine weitere Speicherverwaltung "draufsetzt", das wäre allerdings vielleicht schon zuviel verlangt für so ein kleines System - obwohl zu dem Zeitpunkt (1963), als Bitte melde dich an, um diesen Link zu sehen. dieses "kleine" System durchau als "großes" gegolten hätte.

So könnte man den Speicher effizient fragmentieren und defragmentieren. Ob sich das bei dem doch merkbaren Verlust von geschätzten 25% auszahlt, müsste man sich überlegen. Schneller als Garbage-Collection wäre es alle Mal. Man müsste halt drüber nachdenken. Ich kann es nicht wirklich beurteilen.
Was Strings betrifft, sehe ich noch ein anderes Thema, nämlich, dass sämtliche String-Operationen wieder neue Strings ergeben. Wie oft kommt es vor, dass man bloß das n-te Byte im String braucht, und dafür eine aufwendige MID$-Operation verschwendet? Eine Basic-Funktion, die ein Zeichen des Strings als numerischen Wert zur Verfügug stellt, ohne vorher einen neuen String anzulegen, wäre sicher in vielen Fällen ein enormer Geschwindigkeitsgewinn.
-
Eine vom intuitiven Lesen her verlockende Idee, wenngleich reichlich abstrakt, da es beim Buddy Memory management ja um "Prozesse" auf einem hochkomplizierten System (Unix, Linux, Windows NT) mit vielen gleichzeitig laufenden Programmen geht; mehrfacher "overkill" aus C64-Benutzersicht ...
kannst du das bitte herunterbrechen und zugleich klarer machen was das mit Strings auf einem 6502-System zu tun hat?Man "rundet" die Byte-Größe bis zur nächsten Zweier-Potenz "auf", und sucht dann (mit logarithmischem Aufwand) ein freies Fragment mit genau der Größe, und benutzt es. Wenn keines da ist, teilt man ein größeres Fragment so lange, bis man eines in der gewünschen Größe erhält.
In Wikipedia (deutsch) heisst der Abschnitt:
Fordert nun ein Prozess eine bestimmte Menge Speicher an, so wird zur nächsthöheren Zweierpotenz aufgerundet und ein entsprechender Block gesucht.
Es wäre wirklich absolut prima, dieses "suchen", "man sucht" noch etwas klarer zu fassen; könntest du das?
Wer sucht wie genau?
Ich meine, als 0815-C64-Programmierer kenne ich nur eine BAM in der Floppy, also eine Bitmap.Und auf dem 80x86 kenne ich einen Befehl BT (Bit Test), da kann man schauen ob das dem betreffenden Block entsprechende Bit gesetzt oder gelöscht (= frei) ist und bekommt eine Nummer in einem Register zurück.
Die haben aber linearen Aufwand beim Abklappern. Weit hinten = es dauert sehr lange, weit vorne (eher selten) dauerts kurz...
Das kann hier aber nicht gemeint sein!?Edit: zu dem MID$-Beispiel: dafür wäre prädestiniert, die VAL oder ASC-Funktion um einen zweiten Index in Klammern nachzurüsten, zu erweitern. Sieht zwar lustig aus, so ein B=VAL(A$)(17) wäre aber das intuitiv naheliegendste zumal Basic ja auch diverse "drangeprömpelte" Funktionalität aufweist.
Edit 2:
Du schriebst: "Also kommt man mit 8 Bit auf 1+2+4 Bits, die man in einem Byte verwalten kann,"
jaja, aber wie ist dieses Byte aufgebaut? wo steht es? wie steht es mit anderen derartigen Bytes in Beziehung? in einer BAM? hat diese dynamische Größe und "atmet"? oder ist sie fest? -
Das Ganze ist normalerweise als eine Art Binärbaum implementiert. Aufwand ist O(ln(x))
-
kannst du das bitte herunterbrechen und zugleich klarer machen was das mit Strings auf einem 6502-System zu tun hat?
Im Grunde ist es völlig egal, wieviele "Klienten" bei dieser Verwaltung Speicher anfordern oder zurückgeben, und zu welchem Zweck. Darauf kommt es überhaupt nicht an. Wichtig ist in dem Zusammenang, wie der Speicher grundsätzlich verwaltet werden kann, egal, wofür man (und wieviele "man") ihn verwendet.
Zu dem Runterbrechen:
Das Ganze ist normalerweise als eine Art Binärbaum implementiert. Aufwand ist O(ln(x))
Es müsste irgendwie ein Baum sein, allerdings würde ich davor zurückschrecken, es tatsächlich als Baum mit Zeigern etc. zu verwalten. Als fixe Datenstruktur hätte es zwar den Nachteil, dass man den gesamten Platz dafür sofort reservieren muss, egal, wieviel davon tatsächlich gebraucht wird. Allerdings sind dann die Verwaltungs-Zugriffe erheblich schneller.
Übrigens merke ich, dass ich oben teilweise nicht so gut nachgedacht habe, was den Speicherverbrauch anlangt. Ich versuche, es jetzt besser zu machen!
Wir haben da drin Bereiche von Blocks genormter Größen. Nehmen wir an, wir hätten 32k zu vergeben.
Dann brauchen wir die folgenden Bereiche:
Bereich - Größe - Verwaltungsbits
0 .. 32k .. 1 bit (fragmentiert) + 1 bit (besetzt)
1 .. 16k .. 4 bit (je erste oder zweite Hälfte bereits fragmentiert, erste oder zweite Hälfte besetzt)
2 .. 8k .. 8 bit=1 byte
3 .. 4k .. 2 bytes
4 .. 2k .. 4 bytes
5 .. 1k .. 8 bytes
6 .. 512 bytes .. 16 bytes
7 .. 256 bytes .. 32 bytes
8 .. 128 bytes .. 64 bytes
9 .. 64 bytes .. 128 bytes
10 .. 32 bytes .. 256 bytes
11 .. 16 bytes .. 512 bytes
12 .. 8 bytes .. 1kAb da empfiehlt es sich, die 8 bytes linear mit je einem Bit zu verwalten, sonst explodieren die Kosten.
Diese Verwaltungsbits müssen alle gleichzeitig existieren (weil man sie nicht dynamisch allokiert, sondern zwecks Effizienz die ganze Zeit im Speicher hält).
Wir haben folgende Operationen:
- Anfordern eines neuen Speicherfragments: Der Algorithmus beginnt bei Bereich 0, sieht nach, ob ein 16k-Fragment vorhanden ist. Falls nein, fragmentiert er. Falls ja, sieht er im Bereich 1 nach, ob in einer der beiden Hälften ein 8k-Fragment vorhanden ist. Dann im Bereich 2, ob in einem der Viertel ein 4-k-Fragment vorhanden ist. Und so weiter, bis er entweder so ein Fragment gefunden hat oder eines erzeugt hat. Wenn man alle Unter-Fragmente besetzt hat, besetzt man auch das eine Ebene höher, damit das Suchen effizienter wird.
- Freigeben eines Speicherfragments: Der Algorithmus markiert das freigegebene Fragment als unbesetzt, und das nächst höhere Fragment als "unbesetzt", damit die Suche in Zukunft dort wieder hineinsieht. Dann sieht er nach, ob das Nachbar-Fragment auch frei ist, und wenn ja, macht er dasselbe mit dem doppelt so großen Fragment eine Ebene höher (einen Bereich vorher), und dort wiederholt er das Spiel, bis er ein Nachbarfragment findet, dass seinerseits nicht frei ist. So ergeben sich nach Freigabe automatisch wieder größere Speicherbereiche.
Kleines Beispiel: Wir wollen 14 bytes speichern.
Der Speicher ist jungfräulich. Bereich 0 hat nur ein bit, das sagt "ich bin nicht fragmentiert", und eines, das sagt "ich bin nicht besetzt". Also fragmentieren wir. Es entstehen zwei 16k-Fragmente. Wieder ist das erste 16k-Fragment unfragmentiert und unbesetzt, wir fragmentieren, tragen im entsprechenden 16k-Bereich diese Fragmentierung ein, und gehen zu den 8k-Fragmenten. Dort wieder das erste unfragmentiert und ubesetzt, und so weiter bis zu den 16byte-Fragmenten. Wir finden eines, setzen es auf "besetzt" (aber nicht "fragmentiert"!) und geben die Addresse an das Programm zurück. Dieses speichert seinen String drin.
Dann kommt eine weitere Anforderung vom Programm, diesmal mit 5 bytes. Man beginnt wieder beim Bereich 0, der ist fragmentiert, geht zum Bereich 1, der ist fragmentiert, und so weiter, bis zum Bereich 11, der besetzt ist. Also geht man zum Nachbar-Fragment (16 bytes), das noch nicht fragmentiert oder besetzt ist. Man fragmentiert es, und nimmt sich im nächsten Bereich 12 die erste Hälfte davon (setzt also die 8 bytes auf "besetzt").
Wenn ein weiteres 8-byte-Fragment gebraucht wird, geht die Suche automatisch runter bis zu diesem Fragment, weicht dem ersten 16-bit-Fragment aus (das besetzt aber nicht fragmentiert ist), findet das besetzte (aber nicht fragmentiert) 8 byte-Fragment und stößt daneben auf die anderen 8 bytes, die nicht besetzt sind. Die werden besetzt, und da damit ein ganzes übergeordnetes 16-byte-Fragment verbraucht ist, wird es ebenfalls auf "besetzt" gesetzt, damit Suchen daran gleich vorbei gehen. Wird ein 8-byte-Fragment freigegeben, wird damit auch dieses 16-byte-"besetzt" wieder gelöscht, und der nächste Suchvorgang (für 8 bytes) schaut wieder dort hinein.
Man könnte diese Technik gut nutzen, um Strings variabler Länge zu speichern und wieder freizugeben, wobei es da um die Zeichenketten selber geht, und nicht um die Deskriptoren, die ja fixe Länge haben, also wohl in Tabellenform besser aufgehoben sind.
-
Theoretisch könnte man alle gelöschten Strings ab 3 Byte in einer Liste verketten.
Vor dem Speichern wird dann die Liste abgeklappert ob da noch eine Lücke frei ist.Grundsätzlich zeigt das Listing Feststring-Verwaltung wie der Basic-Programmierer die Stringaufräumung selber machen und temporäre Strings beseitigen kann.
Wenn man das tut tritt die GBC nur noch äußerst selten oder gar nicht mehr auf.Daher wären auch Befehle zur String-Verwaltung denkbar.
wie z.B. smem oder sset. Das Prinzip ist einfach:
man merkt sich die Position des String-Ram-Zeigers mit smem, dann führt man seine Stringoperationen durch und setzt den String-Ram-Zeiger mit sset auf die gemerkte Position zurück.
Dann kopiert man mit a$=a$+"" den String an die gemerkte Position und die temporären Strings werden vergessen.Schönen Gruß.
-
Manche der Ideen passen besser in den anderen Thread, aber ein paar der Stringsachen scheinen mir ganz billig zu sein und gut zum vorhandenen ROM zu passen.
@Hogo:
Grundsätzlich wäre es auch denkbar, falls es sich um den gleichen String handelt, den String an der gleichen Adresse zu speichern, falls er kleiner oder gleich lang ist.Ja, könnte auf einen einfachen Vergleich der Längen hinauslaufen. Plus Erkennen des Sonderfalls, dass der letzte String im Speicher angesprochen ist, den man auch verlängern kann. (Bzw der erste String, da ja V2 die Strings von hinten nach Vorne ablegt)
Siehe auch den Thread Feststrings in der Basic-Ecke.
...wenn ich das recht verstehe: Grenze des String-Stapels merken, neuen String anlegen, "von Hand" in den Speicherplatz des alten kopieren, Grenze wiederherstellen. Schön ist das ja nicht, könnte aber sein, dass es im Rahmen einer Umsetzung auf sowas hinausläuft.Also auch eine Feststring-Verwaltung wäre betriebssystemlich durchaus machbar.
Ohne Tricks müsste dafür aber schon bei der Deklaration was gemacht werden, neuen Variablen-Typen dafür einrichten oder sowas. Ich glaube, das zieht einen Rattenschwanz hinter sich her. Feste Strings sind nicht sehr oft nützlich, ich denke,das rechtfertigt den Aufwand nicht.
Buddy Memory Allocation
Interessant, vielleicht was für den anderen Thread. Es dürfte aber immer auch noch Zeiger geben, die auf diese Speicherbereiche zeigen, und im Falle von Strings auch noch die genaue Länge. Müsste man mal genauer checken, ob der Verschnitt und der Aufwand an Programm und Struktur sich lohnen. Aber aus dem Bauch würde ich sagen, dass das für diesen Zweck zu viel ist.
Was Strings betrifft, sehe ich noch ein anderes Thema, nämlich, dass sämtliche String-Operationen wieder neue Strings ergeben. Wie oft kommt es vor, dass man bloß das n-te Byte im String braucht, und dafür eine aufwendige MID$-Operation verschwendet? Eine Basic-Funktion, die ein Zeichen des Strings als numerischen Wert zur Verfügug stellt, ohne vorher einen neuen String anzulegen, wäre sicher in vielen Fällen ein enormer Geschwindigkeitsgewinn.
Nice. Ich hab kurz überlegt, ob man nicht auch einen 2. String in den Speicher des ersten zeigen lassen könnte, dürfte aber bei einer GC sehr unschön werden.
Theoretisch könnte man alle gelöschten Strings ab 3 Byte in einer Liste verketten.
Vor dem Speichern wird dann die Liste abgeklappert ob da noch eine Lücke frei ist.Könnte aber dazu führen, dass Du nach einiger Zeit eine risige Liste kurzer Schnipsel hast, die für nichts zu gebrauchen sind. Braucht außerdem Programm und Speicher für so eine Liste.
Noch ne Idee: Strings belegen ja eigentlich nur 3 Bytes, werden aber mit unbenutzten Bytes zur Größe von Floats aufgeblasen (von Arrays abgesehen). In einem Byte könnte man freien Platz speichern, der durch ablegen kürzerer Strings entsteht.
-