BOOL , Speicherbedarf und Laufzeittempo

[Joachim B. (jar)]

mal einige grundsätzliche Fragen

ich hab viele globale Flags, normal BOOL, im Standard C als int 
deklariert, ist aber nicht wirklich resourcenschonend, es würde auch 
unsigned char reichen, aber auch das sind pro Flag 7 verschwendete Bits, 
bloß ob ich die zu einem Array zusammenfasse und per Bitschieberei 
testen sollte ?

zum einen steht der geringe Platzgewinn, zum anderen die Rechenzeit und 
der Code Wachstum, wie löst ihr das ?

gruss
jar

[Nullpointer (Gast)]

Tja, wie du sagtest, wenn's schnell sein muss als byte, wenn's sparen 
muss als bit in einem byte

[Johannes M. (johnny-m)]

@Joachim B.:
Auf welcher Plattform arbeitest Du denn? Bei Embedded-Systemen, die 
bitadressierbare Speicherbereiche haben (z.B. 8051er) stellen die 
Compiler ja auch Bit-Typen zur Verfügung, die von der Zugriffszeit 
genauso schnell sind wie normale Variablen-Zugriffe.

Wenn Du keinen bitadressierbaren Speicher zur Verfügung hast: Manche 
Leute behelfen sich anstelle der Schiebereien mit Bitfeldern. Die 
erzeugen zwar im Prinzip den selben Code wie die Schiebereien, es gibt 
aber Leute, die mit der Schreibweise

flags.flag1 = 1;

besser klarkommen als mit

flags |= 1 << FLAG1;

[Joachim B. (jar)]

Johannes M. wrote:
> @Joachim B.:
> Auf welcher Plattform arbeitest Du denn?

AVR gcc , nur atmels

mache das gerade 8 Wochen, habe aber einiges an Prüftechnik in C 
geproggt, aber unter DOS (PC) und Atati ST, da war Speicher ja kein 
Thema, nu bin ich schon immer am Limit vom mega32 mit -Os bei 70%, der 
mega8 wurde mir viel zu schnell zu klein

also was sagt der Fachman, bitfriemeln unter AVR und gcc oder lieber 
byte Var als BOOL ?

[antworter (Gast)]

>nu bin ich schon immer am Limit vom mega32 mit -Os bei 70%, der
>mega8 wurde mir viel zu schnell zu klein

Meiner Erfahrung nach kann man die Binary-Größe drastisch reduzieren, 
wenn man sooft wie möglich (aber in sinnvollem Rahmen) Prozeduren und 
Hilfsfunktionen benutzt.
Wenn man von "größeren" Architekturen kommt, ist man gerade im Bereich 
"Zerstückelung" ungeübt/unbedarft, was dann auf dem uC zu unnötig großen 
Programmen führt.

Einen Geschwindigkeitsverlust muß man dabei nicht befürchtet, denn wenn 
diese gefragt ist, werden die Funktionen per inlining eh wieder 
"zusammengefügt".

Ansonsten findet google diverse Tutorials, um aus gcc kleinere binaries 
herauszukitzeln.

Ach ja... ab und zu mal in die generierte .map-File zu blicken lüftet 
ebenfalls manchen Schleier :-)