Zitat:

---

Holger:

Zitat:

---

gni:
Ich kennen keinen ANSI/ISO C Compiler, der das nicht macht. Wobei zb. der der SAS/C sogar etwas cleverer vorgeht als GCC. SAS/C kann erkennt auch Substrings am Ende eines Strings.

---

Dann hätte SAS/C also alle Leerstrings auf denselben Speicherbereich legen müssen?

---

Zitat:

---

Mit welchem Compiler haben die Commodore-Entwickler dann gearbeitet?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Warum man das *so* machen kann, habe ich oben erläutert. Weniger Tipparbeit, und bei gewissem Code (Module, die aus nem ROM ins RAM kopiert werden) sind die Nachteile kaum spürbar.

---

Hmm, über die nicht vorhandene Speicherersparnis und den kaum meßbaren Performancegewinn (wo es nicht gerade eine Einbuße verusacht), wurde ja schon gesprochen. Aber weniger Tipparbeit?
Für mich ist
bm=AllocBitMap();
immer kürzer als
bm=AllocMem(sizeof(struct BitMap), ...);
InitBitMap(bm);
und
ptr=" "
InitBitMap(bm);

ist keine wirkliche Verbesserung, selbst wenn es kürzer als Variante 2 wäre, stellt es doch nur ein Herumdoktorn an den Symptomen dar. Denn die das eigentliche Problem ist, daß man keine AllocBitMap-Funktion hatte. Die bedeutet nämlich auch weniger TippArbeit.

---

Zitat:

---

Zitat:

---

Anders herum hast Du sonst den "Verwaltungskram" (Speicher anfordern/freigeben) und den eigentlich benötigten Speicher, was den Gesamtspeicherplatz doch mehr reduziert als die "Holzhammermethode".

---

Könntest Du mir bitte erklären, was die "Holzhammermethode" gewesen wäre? Ich bin mit dieser Denkweise der ex-C= Entwickler nicht vertraut. Welche Alternativen spukten diesen Leuten denn noch im Kopf herum?

---

Die Holzhammermethode, die ich meine, ist die, die Du schon erkannt hast. ROM-Code, welcher später im RAM landet, so statisch wie möglich zu halten, um eine Speicherverwaltung im klassischen Sinn für kleine Datenbereiche zu umgehen. Das ist ne uralte Vorgehensweise. Beim PET/VC20/C64 etc. hat man oft so gearbeitet (da spielten Datentypen allerdings keine Rolle ).

Alternativen hatten die Cracks aus der Zeit sicher noch genug auf Lager, ich kenne selbst nur einen Bruchteil davon. Eine wäre z.B. die "Voraussage von Adresswerten". Eine gefährliche Annahme zwar, aber bei geschickter Auslegung des Codes funktioniert auch das. Wurde häufig auf dem C64 angewandt in Verbindung mit dem BASIC-Interpreter und der Zeropage. Da ergaben sich bestimmte Adressberechnungen quasi "von selbst" (als Ergebnis der Arbeit der BASIC-Routinen), was man sich dann im eigenen Programm sparen konnte.

Im AmigaOS habe ich sowas bisher aber zum Glück noch nicht entdeckt.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:
Ursprünglich mit "Greenhills C" (Cross-Compiler auf einer Sun), vermutlich Lattice C and später dann SAS/C. Teile des OS (zb. Intuition) wurden aber immer mit "Greenhills C" übersetzt. Wie gesagt das Zusammenfassen von Strings kenne ich nur von ANSI/ISO Compilern. Und SAS/C ist das erst seit 5.x (?) von 1990.

---

Gehört zwar nicht zum Thread, aber ich weiß nicht, ob Du meine Frage im "SASC"-Thread gelesen hast.

Besitzt Du den SAS und kann ich ggf. auf Dich zurückkommen, um die Kompatibilität der FileMaster-Sourcen zum SAS zu testen, wenn ich die GCC-freundlich umgebaut habe?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
Besitzt Du den SAS

---

Zitat:

---

kann ich ggf. auf Dich zurückkommen, um die Kompatibilität der FileMaster-Sourcen zum SAS zu testen, wenn ich die GCC-freundlich umgebaut habe?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:
Ja.

---

Danke schon mal im voraus.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]