atari-home.de - Foren
Software => Coding => Thema gestartet von: rainers am Mo 29.04.2013, 22:00:50
-
Hallo,
kann mir jemand einen Tip geben (meine Bücher geben nichts Brauchbares her), wie auf einfache Art und Weise der noch freie Hauptspeicher unter TOS 2.06 ermittelt werden kann? Also einfach die Summe des gesamten freien Speichers. Schön wäre eine Systemfunktion (GEMDOS, BIOS, XBIOS) oder ev. auch eine ST-Pascal-Funktion.
Danke.
-R.
-
schau doch mal beim toshyp (http://toshyp.atari.org) vorbei. dort dann bei gemdos und den speicherfunktionen.
-
Danke HamSTer für die tolle Seite, da kann ich ne Menge lesen, was ich noch nicht weiß.
Jedoch auf die Schnelle konnte ich unter der Rubrik "Speicherfunktionen" nichts finden, was dem entspricht, was ich möchte.
Aber schon für Deinen Link hat sich der Thread "gelohnt" ;)
-
malloc() mit -1 aufrufen.
-
Nee, das isses nich.
Die gibt ja nur die Größe des größten zusammenhängenden Speicherblocks zurück.
Ich möchte aber den gesamten freien Speicher abfragen ;-)
-
Nee, das isses nich.
Die gibt ja nur die Größe des größten zusammenhängenden Speicherblocks zurück.
Ich möchte aber den gesamten freien Speicher abfragen ;-)
Vorgehensweise:
Mit malloc(-1) den größten freien Speicherbereich ermitteln, diesen Speicher allozieren und merken wieviel das war. Dann wieder malloc(-1) und den Speicher allozieren und zum gemerkten Speicher dazuaddieren. Das solange wiederholen, bis malloc(-1) Null zurückliefert, anschließend den ganzen allozierten Speicher wieder frei geben.
-
@1ST1: Das ist Dein Ernst? Du glaubst wirklich, daß TOS (2.06) und MagiC (6.20) auf diese Art und Weise vorgehen?
Solange Du mir hier nicht ein seriöses Programmbeispiel lieferst, glaube ich das nicht.
Schreib doch nicht immer nur so vor Dich hin, mach doch irgendwas mal ganz konkret. Für einen ATARI-GOTT wie Dich muß doch das aus dem Ärmel geschüttelt sein. 8) 8) 8) 8) 8) 8) 8) 8)
-
Ich liege schon im Bett. Ich schätze aber, eine andere Wahl hast du nicht, wenn du es tatscächlich wissen willst. GEMDOS sieht scheinbar keine andere Funktion vor. Im Sinne von möglichem Multitasking sollte dein Programm aber immer nur so viel dazu allozieren, wie du absehbar brauchst. Die Strategie "ich hol mir jetzt mal allen Speicher an Land" macht höchstens in Single-Tasking-TOS Sinn, aber auch nur wenn keine ACCs geladen werden, die dynamisch bei Bedarf auch zusätzlichen Speicher anfordern. Unter MiNT/Magic verbaust du dir damit jegliche Multitasking-Kooperation.
Siehe auch Profibuch Seite 251-256 zu den Speicherfunktionen malloc, mxmalloc, mfree und mshrink.
-
@1ST1: Das ist Dein Ernst? Du glaubst wirklich, daß TOS (2.06) und MagiC (6.20) auf diese Art und Weise vorgehen?
Doch, das stimmt schon. So wird's gemacht. Was anderes ist nicht vorgesehen.
-
Doch, das stimmt schon. So wird's gemacht. Was anderes ist nicht vorgesehen.
Um hier noch eine Erklärung nachzuschieben: Deine Fragestellung bezog sich ja laut Thread-Titel auf Tos 2.06. Und dort ist tatsächlich keine andere Möglichkeit vorgesehen. Bei MiNT gibt es m.Wn. schon die Möglichkeit, die Anzahl freier Mem-Pages abzufragen (und die Größe einer Page natürlich auch). Und bei Magic dürfte es das auch geben, irgendwie. Aber um Details zu nennen, bin ich da leider schon zu lange raus aus dem Theme.
Aber abgesehen von der Möglichkeit, solches in Erfahrung zu bringen, um seine Neugierde zu befriedigen, hat die Kenntnis darüber keinen echten Nutzen. Das liegt daran, das TOS (genauso wie MiNT und Magic) keine virtuelle Speicherverwaltung beherrschen. Dadurch wird der Speicher nach längere Uptime irgendwann so fragmentiert, dass nur noch kleine "Speicher-Fitzelchen" zur Verfügung stehen. Und wenn Du dann doch mal 32k zusammenhängenden Speicher brauchst, aber nur noch 1000 einzelne freie Pages mit immerwieder dazwischenliegenden benutzten Pages vorfindest, wirst Du feststellen, dass Malloc(-1) für den größtverfügbaren Speicherblock doch dein Freund ist.
Ich hoffe, ich habe mich soweit verständlich ausgedrückt, ohne zu sehr theoretisch zu werden :-))
-
Dank Euch allen, insbesondere 1ST1 ;) (siehste mal, mit so einer Antwort, wie Deiner letzten, damit kann ich etwas anfangen ;) ).
Also es sollte wirklich nur "nice to have" sein. Dafür werde ich den Aufwand dann aber nicht betreiben.
Nochmals Danke.
-R.
-
Mit MiNT kann man in der Tat den freien Speicher (sehr viel) einfacher abfragen (http://wiki.sparemint.org/index.php/U:%5Ckern#.2Fkern.2Fmeminfo). Einfach /kern/meminfo auslesen.
Allerdings hat man (gerade da) ganz und gar keine Garantie dafür, daß man den Speicher anschließend auch allokieren kann (da kann einem ganz leicht ein anderer Prozeß dazwischen funken).
-
Versuch´s doch mal mit PRINT FRE(0).
-
nein omi es werden programmiersprachen verwendet ;D
aber das ergibt auch nur den grössten zusammenhängenden block freies st-ram
-
für mich als halblaie: was ist int_32t?
-
für mich als halblaie: was ist int_32t?
Lt. C++-Referenz das: Integer type with a width of exactly 32 bits.
-
ist das dann ein long? oder unsigned long? was besagt das t?
-
t wie "type", das ist einfach eine Namenskonvention. I.d.R. wird das auf einem Atari einem long entsprechen.
BTW am Atari geht es immer um C, nicht C++, da gibt es subtile Unterschiede trotz vieler Ähnlichkeiten.
Zum Type int32_t empfehle ich Recherche unter dem Stichwort stdint.h, das ist ein Feature von C99 und sehr sinnvoll.
Ein long kann auf unterschiedlichen Plattformen unterschiedlich viele Bits lang sein, mit einem int32_t wird passend zur Plattform sichergestellt, daß man kein long sondern 32bit signed bekommt.
-
Ich habe das mal als Übung für mich versucht. Dabei ist dies herausgekommen:
#include <tos.h>
#include <stdio.h>
int main(void){
int i,j=0;
long mem=1,frei=0;
long merk[255];
for(i=0;i<255;i++){
merk[i]=0;
}
i=0;
while(mem != 0){
mem = Malloc(-1);
if(mem>0){
merk[i] = Malloc(mem);
frei=frei+mem;
i++;
}
}
for (j=0;j<i;j++){
Mfree(merk[j]);
}
printf("Bytes frei %ld",frei);
return 0;
}
Dabei bekomme ich dann Warnungen bei Malloc und Mfree: Non-portable Pointer assignment in function main
Was heißt das? Bei Pointern steig ich momentan vollkommen aus.
-
Du hast nirgendwo einen Pointer deklariert, die Funktionen wollen aber einen verwenden.
Zwar sind in der Tat am Atari 32Bit Zahlen auch gleichzeitig Adressen und pointer, aber C unterscheidet da. Und das ist auch richtig so, damit der Programmier auch weiß, womit er arbeitet.
Ein Zeiger auf einen Speicherbereich ist in C immer zweigeteilt, einmal der Pointer selbst, dargestellt durch * und einmal der Typ der Daten, auf die der Pointer zeigt.
Nimm an, du hast im Speicher tolle Zeichen liegen, die als char abgespeichert sind.
Dann kannst du in einem "Pointer auf char" die Startadresse dieser tollen Zeichen ablegen.
char meinZeichen = 'z';
char *ptr_auf_meinZeichen = &meinZeichen; /* definiere "pointer auf char"und gibt ihm die Speicheradresse von meinZeichen */
Malloc und co wissen nicht, welcher Typ dahinter liegt, deswegen geben sie normalerweise einen "void Pointer" zurück. Den muss man dann zur Verwendung auf die Art der Daten casten, auf die man dann zugreifen möchte.
void *speicher;
char *ptr_auf_zeichen;
speicher = malloc(50000); /* wir holen uns mal Speicher */
ptr_auf_zeichen = (char *)speicher; /* in diesem Speicher liegen in Zukunft chars */
*ptr_auf_zeichen = 'A'; /* ein großes A in diesem Speicher ablegen*/
ptr_auf_zeichen++; /* und auf die nächste Stelle zeigen lassen...*/
Vorschlag: Arbeite Dich bitte in ein sauberes und modernes C Tutorial auf dem PC ein. Wenn das sitzt, kann man das Wissen auf den Atari anwenden. Umgekehrt läuft man Gefahr, uralte C Dialekte zu verwenden und z.B. solche Fallen, wo aus Faulheit Adressen als long deklariert werden, weiterzuverwenden.
-
Danke für die Erklärungen.
Ich habe hier das Buch "C Programmieren von Anfang an" von Helmut Erlenkötter. 16. Auflage von 2009.
Ist das brauchbar?
-
Danke für die Erklärungen.
Ich habe hier das Buch "C Programmieren von Anfang an" von Helmut Erlenkötter. 16. Auflage von 2009.
Ist das brauchbar?
Ja, in jedem Fall. Ich weiss z.B. aus dem alten Profibuch von 1988, daß da auch nicht ordentlich mit Pointern beschrieben wird, sondern auch immer nur mit long.
C hat den Vorteil, daß die Sprachbasis unabhängig ist. Alle Aufrufe, ob Windows oder TOS spezifisch, sind nur Funktionsaufrufe aus Bibliotheken. Die kann man dan separat erlernen, wenn die Grundlagen sitzen.
AUch genrelle fragen einfach hier reinstellen, auch wenns nur C allgemein und nicht Atari spezifisch ist. Helfen können wir immer zumindest versuchen ;)
-
die korrigierte lösung, nun ohne Warnungen, schaut so aus
#include <tos.h>
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
int main(void){
uint16_t i,j=0;
int32_t mem=1, frei=0;
void *merk[255];
for(i=0;i<255;i++){
merk[i]=0;
}
i=0;
while(mem != 0){
mem = (long) Malloc(-1);
if(mem>0){
merk[i] = (long *) Malloc(mem);
frei=frei+mem;
i++;
}
}
printf("%d Speicherbl”cke allociert.\n",i);
for (j=0;j!=i;j++){
Mfree(merk[j]);
}
printf("Bytes frei %ld",frei);
return EXIT_SUCCESS;
}
edit: korrektur im quelltext
edit2: weiteres edit im quelltext. zudem compilat angefügt.
-
merk = (long *) Malloc(mem);
Deine Merker sind vom Typ void *, warum weist Du long * zu? Ja es funktioniert, aber eigentlich musst du sinngemäß auch auf void * casten. (Das aber nur am Rande.)
-
hm..
hab dann ein
long *merk[255];
draus gemacht.
so ist es dann wohl doch irgendwie sinnvoller.
oder aber beim malloc
merk = (void *) malloc(mem);
??
-
Letzteres macht mehr Sinn, da Malloc ja generell Speicher hergibt, ohne zu sagen, daß er longs enthält.
Deswegen bekommst Du erst einen void * vom Malloc. Dein pointer würde dann auf den Typ zeigen, den Du da abspeichern möchtest. Für deine reine Zählung reichts es den bei void * zu belassen.
Aber stell Dir vor, du möchtest den Speicherplatz für ein Degasbild allozieren:
struct Degasbild
{
uint16_t res;
uint16_t palette[16];
uint8_t daten[32000];
};
struct Degasbild * meinBild;
meinBild = (struct Degasbild *) Malloc(sizeof(struct Degasbild));
Du hast einen Zeiger auf die Daten mit Struktur Degasbild. Dann lässt Du dir von Malloc genausoviel Platz geben, Malloc weiss aber nichts, welche Struktur das haben wird. Deswegen transformierst Du den void * den Malloc Dir eigentlich gibt, explizit über den Cast auf einen Pointer auf das Bild.
-
klasse 8)
Das macht sicher die Pflege von solcherlei Programmen leichter. Neue Anforderungen an das Bildformat oder andere Dinge müssen lediglich in der Struktur angepasst werden.
-
Genau und damit hast Du auch schon mit einfachem C einen Schritt Richtung Objektorientierung.
Das funktioniert natürlich auch mit allen möglichen Daten.
-
Hallo HamSTer,
danke für Dein Code-Beispiel. Hab's mir mal geklaut und wurstel das nach Pascal um.
-R.
-
in dem ATOS C-Kurs ist ein Projektbeispiel
#ifdef __TURBOC__
#include <tos.h>
#else
#ifdef __GNUC__
#include <osbind.h>
#else
#include <tosbind.h>
#endif
#endif
typedef struct cookie_entry {
union {
unsigned long name_long;
char name_array[4];
} name;
unsigned long value;
} CookieEntry;
int main(void)
{ CookieEntry **CookieJarPtr, *CookieJar;
long OldStack;
OldStack=Super(0L);
CookieJarPtr = (CookieEntry**)0x5a0L;
CookieJar=*CookieJarPtr;
Super((void *)OldStack);
return 0;
}
CookieJarPtr , ist demnach Verweis auf Verweis
Wie tief kann sowas gehen?
-
CookieJarPtr , ist demnach Verweis auf Verweis
Wie tief kann sowas gehen?
So tief man will (oder versteht). Zeiger sind die Grundbausteine für Arrays. So was geht z.B. auch:
int multi_array[8][8][8][8][8][8][8][8];
int main(int argc, char *argv[])
{
multi_array[0][0][0][3][3][3][3][3] = 0;
}
Benutzen tut's nur der, der's braucht, mehr als drei Dimensionen sind schwer vorzustellen ;)
-
Übliche Programmierpraxis ist ist bei Pointern nicht tiefer als zwei Ebenen zu gehen, also maximal "Pointer auf pointer". 3 Ebenen in einem Pointer als z.B. ***p habe ich z.B. aktiv noch nicht gesehen.
-
Ich stell hier einfach weiter frech fragen rein..
Bitfelder erschliessen sich mir noch nicht so ganz. Ist zB Folgendes erlaubt?
struct bla {
unsigned : 4;
unsigned kbshift: 1;
unsigned bell : 1;
unsigned repeat : 1;
unsigned click : 1;
} conterm = &0x484;
if (conterm.bell) printf("glocke ist an");
-
Ich stell hier einfach weiter frech fragen rein..
Bitfelder erschliessen sich mir noch nicht so ganz. Ist zB Folgendes erlaubt?
struct bla {
unsigned : 4;
unsigned kbshift: 1;
unsigned bell : 1;
unsigned repeat : 1;
unsigned click : 1;
} conterm = &0x484;
if (conterm.bell) printf("glocke ist an");
Nö. Aber fast richtig.
Es gibt in C keine Funktionalität, um eine Variable an einer absoluten Adresse zu deklarieren.
Was geht, ist folgendes:
struct bla {
unsigned : 4;
unsigned kbshift: 1;
unsigned bell : 1;
unsigned repeat : 1;
unsigned click : 1;
} *conterm = (struct bla *) 0x484;
if (conterm->bell) printf("glocke ist an");
Das sollte mit den meisten Atari-Compilern funktionieren, ist aber nicht garantiert. Der C-Standard schreibt nicht vor, ob Bitfelder "von links" oder "von rechts" gezählt werden. Das bleibt dem Compilerschreiber überlassen.
Ein m68k-Compilerbauer würde sich das Leben aber unnötig schwer machen, wenn er die Bitfelder anders herum zählen würde, als der m68k-Prozessor selbst das (bei bset/bclr beispielsweise) tut.
-
so funktioniert es nun auch:
#include <stdio.h>
#include <tos.h>
#include <stdlib.h>
typedef struct {
unsigned frei: 4;
unsigned kbshift: 1;
unsigned bell: 1;
unsigned repeat: 1;
unsigned click: 1;
} conterm;
int main(void){
long *oldstack;
conterm *wat = (void *) 0x484;
oldstack = (long *) Super(0x0);
if (wat->bell) printf("glocke ist an");
Super((void*) oldstack);
return EXIT_SUCCESS;
}
Ich denke ich werde einfach alle Kapitel ab den Zeigern aufwärts nochmals lesen müssen :o
EDIT: Compilat angehängt
-
Mit welchem Compiler gehen die Bitfelder? Bei Pure C und AHCC hätte ich schwere Zweifel, da die erst ab C99 im Standard sind, Pure C definitiv nur C90 unterstützt und sich Henk bislang nicht hat bewegen lassen, sämtliche C99 Features zu implementieren.
GCC ist kein geeigneter Kandidat für originale Atarihardware, der läuft nur sinnvoll für Systeme mit viel Speicher und CPU Upgrades. "Hello World" für reines TOS 110K, erm, disqualfiziert!
-
Mit welchem Compiler gehen die Bitfelder? Bei Pure C und AHCC hätte ich schwere Zweifel,
Geht mit beiden.
In PureC habe ich das schon slebst genutzt. AHCC kommt zumindest mit der Deklaration zurecht, habe es dort noch nicht bewußt getestet.
-
ja, mit pure c funktioniet das hier.
was mich generell stört sind auch die großen compilate. aber bis ich etwas brauchbares produzier soll das erst mal zurück stehen. ;)
-
Bitfelder gab's schon im K&R "Ur-C" und soweit ich weiß, können alle Atari-Compiler (mit Ausnahme des Alcyon-C, aber das dürfte kaum mehr einer kennen) damit umgehen. Trotzdem würde ich sie nicht verwenden. Zum einen, weil man nicht weiß, ob der Compiler "von links" oder "von rechts" zählt, zum anderen, weil die Größe eines Bitfelds immer ein Vielfaches von sizeof(int) ist.
Wenn man also - wie im Beispiel - so ein Bitfeld wie ein Stück Butterbrotpapier auf eine feste Adresse "durchpausen" will, ist man von der Breite eines ints abhängig. Bei einem Compiler, der ints 32 Bit breit gestaltet (Lattice & gcc, z.B.) landet man dann leider zwei Bytes daneben...
Übrigens ist mein kleinstmögliches "Hello world!"-Programm, mit gcc compiliert und lauffähig, genau 458 Bytes groß ;)
-
..
-
GCC ist kein geeigneter Kandidat für originale Atarihardware, der läuft nur sinnvoll für Systeme mit viel Speicher und CPU Upgrades. "Hello World" für reines TOS 110K, erm, disqualfiziert!
Ich denke das ist ein Vorurteil. Natürlich ist es mit GCC möglich kleinere Programme zu schreiben, man verzichtet dann auch mintlib, und evtl. weitere Komponenten. Was natürlich bedeutet das man teilweise alternativen zur Hand haben muss ;)
-
GCC ist kein geeigneter Kandidat für originale Atarihardware, der läuft nur sinnvoll für Systeme mit viel Speicher und CPU Upgrades. "Hello World" für reines TOS 110K, erm, disqualfiziert!
Ich denke das ist ein Vorurteil. Natürlich ist es mit GCC möglich kleinere Programme zu schreiben, man verzichtet dann auch mintlib, und evtl. weitere Komponenten. Was natürlich bedeutet das man teilweise alternativen zur Hand haben muss ;)
Naja, die Ersatzkomponenten muss man halt dann inmühsamer Kleinarbeit wieder selbstschreiben. Das hilft dann nicht, wenn man konkret entwickeln will. Deswegen verwende ich auf dem Atari AHCC und bin damit auch sehr zufrieden.
Für den gcc wäre es vllt mal sinnvoll, eine schmale libc für TOS anzubieten. Dann wird er als Crosscompiler wieder sehr sehr interessant.
-
Für den gcc wäre es vllt mal sinnvoll, eine schmale libc für TOS anzubieten. Dann wird er als Crosscompiler wieder sehr sehr interessant.
Es gibt nichts gutes, außer man tut es ;)
-
hm, ja das stimmt schon - aber ich denke fuer einen demo coder ist das ein geringes problem, weil eh auf unterer ebene programmiert wird und so viel mehr mit traps etc. Gearbeitet wird,... Also ich meine jedenfalls das jemand der viel in assembly programmiert eh schon "seine" lib hat...
wenn man komfort haben wil, dann kann man vielleicht eher auf die optimierung der groesse verzichten... Vielleicht muss man das sogar... Die libc funktionen sind ja alleine auch nicht so toll zu benutzen ;)
-
Deswegen nehme ich AHCC und hinke mit "meiner" Lib halt Zeit bedingt hinterher. Zeit für Atari ist halt knapp....
Kann vllt einer von euch mal in einem separaten Thread beschreiben, mit welchem Ansatz man denn mit dem gcc eine eigene libc anfangen würde? Zugriff auf XBIOS, BIOS und GEMDOS wäre Minimalfunktionaliät. Wenn man die hat, kann der Rest aufgebaut werden.
Mein Problem wenn ich jetzt spontan die newlib portieren wollen würde, wäre wohl, daß die TOS Bindings als Grundlage fehlen, um die Lücken zu füllen.
-
Die Frage von Rainer hat mich dazu bewogen etwas in C zu versuchen. Ich hatte also ein kleines Ziel, eine Aufgabe. Die fehlt mir nun. Das lesen in Büchern ist recht trocken. Wer stellt eine neue, erreichbare, Aufgabe? ;D
-
*Moderator Note* Offtopic bzgl GCC und MintLib in anderen Thread verschoben.