Abfrage freier Speicher / TOS 2.06

[HamSTer]

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?

[simonsunnyboy]

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

[HamSTer]

die korrigierte lösung, nun ohne Warnungen, schaut so aus

Code: [Auswählen]

#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.

[simonsunnyboy]

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.)

[HamSTer]

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);

??

[simonsunnyboy]

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:

Code: [Auswählen]

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.

[HamSTer]

klasse 

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.

[simonsunnyboy]

Genau und damit hast Du auch schon mit einfachem C einen Schritt Richtung Objektorientierung.
Das funktioniert natürlich auch mit allen möglichen Daten.

[rainers]

Hallo HamSTer,

danke für Dein Code-Beispiel. Hab's mir mal geklaut und wurstel das nach Pascal um.

-R.

[HamSTer]

in dem ATOS C-Kurs ist ein Projektbeispiel

Code: [Auswählen]

#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?

[mfro]

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:

Code: [Auswählen]

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

[simonsunnyboy]

Ü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.

[HamSTer]

Ich stell hier einfach weiter frech fragen rein..

Bitfelder erschliessen sich mir noch nicht so ganz. Ist zB Folgendes erlaubt?

Code: [Auswählen]

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");



[mfro]

Ich stell hier einfach weiter frech fragen rein..

Bitfelder erschliessen sich mir noch nicht so ganz. Ist zB Folgendes erlaubt?

Code: [Auswählen]

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:

Code: [Auswählen]

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.

[HamSTer]

so funktioniert es nun auch:

Code: [Auswählen]

#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 

EDIT: Compilat angehängt

[simonsunnyboy]

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!

[gstoll]

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.

[HamSTer]

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. 

[mfro]

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ß

[HamSTer]

  ..