Forum: Compiler & IDEs for(i=0;i<256;i++) funktioniert nicht!


von danny (Gast)


Lesenswert?

Hallo Zusammen,

ich habe ein etwas komisches Verhalten mit einer for-Schleife:

unsinged char i;

for(i=0;i<256;i++)
 dooo();

endet in einer Endlosschleife! Kann mir das jemand erklären?

Danke!

von Klaus W. (mfgkw)


Lesenswert?

Ja.

i ist ein unsigned char (nicht unsinged char, vermute ich)
und kann als solches Werte von 0 bis 255 annehmen.
Hat es bereits den Wert 255 und man erhöht es nochmals
wird es wieder 0.

Damit ist i<256 immer erfüllt.

von test (Gast)


Lesenswert?

Hallo Dummy,

schau 'mal wie unsigned char definiert ist!

von Stefan Salewski (Gast)


Lesenswert?

>for(i=0;i<256;i++)
> dooo();

Ich hätte eh

for(i=0;i<=255;i++)

geschrieben -- 256 passt ja nicht mehr in ein Byte.

von Mmmh (Gast)


Lesenswert?

Stefan Salewski schrieb:
> Ich hätte eh
>
> for(i=0;i<=255;i++)
>
> geschrieben -- 256 passt ja nicht mehr in ein Byte.

Seufz.

von danny (Gast)


Lesenswert?

Ok Ok.. mir ist klar das unsigned char als [0; 255] definiert ist!

Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, dass er ein
CP   Rxy, 0xFF
BREQ adr
erstellt!

Macht er also nicht...

von Mmmh (Gast)


Lesenswert?

danny schrieb:
> Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, dass er ein
> CP   Rxy, 0xFF
> BREQ adr
> erstellt!
>Macht er also nicht...

Seufz!

von danny (Gast)


Lesenswert?

@Mmmh : Gibts es irgend einen "Compiler" der mir deine "Seufz!" 
übersetzen kann ;)

BTW:
for(i=0;i<=255;i++)
ist ja genau das Gleiche wie meine erste Schleife...

von Fabian (Gast)


Lesenswert?

Zum Glück macht er das nicht. Ich will immernoch durch mein Programm 
bestimmen, was es zu tun hat und nicht der Compiler.

Davon abgesehen ist unsigned char als [0..255] und nicht als [0; 255] 
definiert. (Wobei ich mir grad nicht sicher bin, ob ein char 
grundsätlich 8 Bit hat oder ob es bei anderen Sprachen/Systemen auch 
noch unterschiede gibt.

von Bernd O. (bitshifter)


Lesenswert?

Fabian schrieb:
> Zum Glück macht er das nicht. Ich will immernoch durch mein Programm
> bestimmen, was es zu tun hat und nicht der Compiler.
>
> Davon abgesehen ist unsigned char als [0..255] und nicht als [0; 255]
> definiert. (Wobei ich mir grad nicht sicher bin, ob ein char
> grundsätlich 8 Bit hat oder ob es bei anderen Sprachen/Systemen auch
> noch unterschiede gibt.
Ja, auf manchen System hat ein char nur 7 Bits.

Gruß,
Bernd

von Stefan Salewski (Gast)


Lesenswert?

>BTW:
>for(i=0;i<=255;i++)
>ist ja genau das Gleiche wie meine erste Schleife...

Würde ich nach kurzen Nachdenken auch meinen...

Ich liebe for-Schleifen eh nicht. Mit while sieht man irgendwie klarer. 
Übrigens hatte Wirth FOR aus seinem ersten Oberon-Compiler verbannnt, 
bei Oberon-2 kam das FOR dann aber doch wieder rein.

von Michael U. (amiga)


Lesenswert?

Hallo,

Mmmh schrieb:
> danny schrieb:
>> Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, dass er ein
>> CP   Rxy, 0xFF
>> BREQ adr
>> erstellt!
>>Macht er also nicht...
>
> Seufz!

Er macht, was Du ihm sagst...

Bestenfalls wäre es also CPI Rxy, 256 und das ginge schlecht.
Springen müßter er mit BRLO, Du hast ja nicht

for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges 
Konstrukt ergeben können.

Ein Computer macht nicht immer das, was er soll.
Er macht aber IMMER, was man ihm sagt.

Gruß aus Berlin
Michael

von danny (Gast)


Lesenswert?

Danke..danke..alles klar!

von Simon K. (simon) Benutzerseite


Lesenswert?

Stefan Salewski schrieb:
>>for(i=0;i<256;i++)
>> dooo();
>
> Ich hätte eh
>
> for(i=0;i<=255;i++)
>
> geschrieben -- 256 passt ja nicht mehr in ein Byte.

Dir ist aber schon klar, dass das genau so wenig funktioniert? Die 
Bedingung ist auch immer wahr.

von Stefan Salewski (Gast)


Lesenswert?

Autor:  Simon K. (simon)
>Dir ist aber schon klar, dass das genau so wenig funktioniert? Die
>Bedingung ist auch immer wahr.

Ja, wie ich weiter oben schon schrieb, nach etwas nachdenken schon.

von eklige Tunke (Gast)


Lesenswert?

Michael U. schrieb:
> for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges
> Konstrukt ergeben können.
Bevor er das ausprobiert, kleine Korrektur:
for (i=0; i == 255; i++)
;-)  <-- das ist ein Smiley, kein Code!

von Simon K. (simon) Benutzerseite


Lesenswert?

eklige Tunke schrieb:
> Michael U. schrieb:
>> for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges
>> Konstrukt ergeben können.
> Bevor er das ausprobiert, kleine Korrektur:
> for (i=0; i == 255; i++)
> ;-)  <-- das ist ein Smiley, kein Code!

Aber das macht doch auch keinen Sinn, die Schleife würde nie ausgeführt 
werden, da bereits 0 != 255 ist.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Bernd O. schrieb:
> Ja, auf manchen System hat ein char nur 7 Bits.

Das wäre allerdings nicht C-Standard-konform.  Ein char muss
mindestens 8 bits haben, um eine konforme Implementierung zu
erreichen.

Es können allerdings mehr Bits sein, es gibt beispielsweise konforme
Implementierungen auf irgendeinem DSP, der als kleinste adressierbare
Einheit einen 32-bit-Integer hat.  Dort ist ein char dann auch 32
bits breit (aber sizeof(char) ist trotzdem 1!, denn das ist so
definiert).

danny schrieb:
> Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, [...]

Die Intelligenz des Compilers besteht darin, dass er dir bei
eingeschalteten Warnungen (-Wall -Wextra ist immer eine gute Idee)
sagt, dass du da soeben eine Endlosschleife von ihm verlangt hast
("comparison is always true due to limited range of operands" oder
sowas).

von Stefan E. (sternst)


Lesenswert?

eklige Tunke schrieb:
> Michael U. schrieb:
>> for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges
>> Konstrukt ergeben können.
> Bevor er das ausprobiert, kleine Korrektur:
> for (i=0; i == 255; i++)

Jap, aus der Immer-Schleife eine Niemals-Schleife zu machen, hilft ihm 
bestimmt weiter. ;-)

von Mmmh (Gast)


Lesenswert?

danny schrieb:
> @Mmmh : Gibts es irgend einen "Compiler" der mir deine "Seufz!"
> übersetzen kann ;)

Keine Ahnung. Aber ich gebe Dir eine.
Seufz hat einen Grundton von "Urgs" mit einer deutlichen 
"Umpf"-Komponente.
Und bevor Du weiterfragst: Es sind alles Elefanten. Bis ganz unten.

von Simon K. (simon) Benutzerseite


Lesenswert?

Ich behaupte ja, man kann keine Schleife mit 256 Durchgängen machen, 
wenn man nur von 0 bis 255 zählen kann.

von eklige Tunke (Gast)


Lesenswert?

Stefan Ernst schrieb:
> eklige Tunke schrieb:
>> Michael U. schrieb:
>>> for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges
>>> Konstrukt ergeben können.
>> Bevor er das ausprobiert, kleine Korrektur:
>> for (i=0; i == 255; i++)
>
> Jap, aus der Immer-Schleife eine Niemals-Schleife zu machen, hilft ihm
> bestimmt weiter. ;-)
Scheiße... ;-)
Damit ich doch Recht habe:
von einer Immer-Schleife zu einer anderen Immer-Schleife und dann zu 
einer Nimmer-Schleife... ;-)

von Stefan Salewski (Gast)


Lesenswert?

>Aber das macht doch auch keinen Sinn,

Dachte ich mir auch gerade...

Aber mit einer while-Schleife sollte man doch bei eimem Wertevorrat von 
0 bis 255 256 Wiederholungen realisieren können -- sowohl auf- als 
absteigend. Oder täusche ich mich erneut?

von Simon K. (simon) Benutzerseite


Lesenswert?

Du täuschst dich, denn du hast 257 Zustände. 256 mal "innerhalb" der 
Schleife und einen Zustand, der symbolisiert, dass die Schleife zu ende 
ist.

von Michael U. (amiga)


Lesenswert?

Hallo,

Stefan Ernst schrieb:
> eklige Tunke schrieb:
>> Michael U. schrieb:
>>> for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges
>>> Konstrukt ergeben können.
>> Bevor er das ausprobiert, kleine Korrektur:
>> for (i=0; i == 255; i++)
>
> Jap, aus der Immer-Schleife eine Niemals-Schleife zu machen, hilft ihm
> bestimmt weiter. ;-)

von meinem Tipfehler abgesehen: ich habe nicht gesagt, daß es in seinem 
Sinn funktioniert, ich habe nur gesagt, das könnte besagten ASM-Code 
erzeugen:
>> CP   Rxy, 0xFF
>> BREQ adr

;-))

Gruß aus Berlin
Michael

von yalu (Gast)


Lesenswert?

So geht's:
1
  uint8_t i;
2
3
  i=0;
4
  do {
5
    // ...
6
  } while(++i);

Das ist zwar nicht klinisch sauber, da der Additionsüberlauf genutzt
wird, aber auf Mikrocontrollern erlaubt :)

von Stefan Salewski (Gast)


Lesenswert?

>Du täuschst dich

Ich dachte etwas so:

i=0;
while (i++ != 0) {}

i=255;
while (i-- != 255) {}

Man nimmt also den Überlauf in kauf. Ich denke schon, dass das 
funktioniert.
Wobei ich mir nicht sicher bin, ob man eventuell Pre-Increment schreiben 
müsste, also ++i bzw. --i ?. Ja, ich liebe C nicht wirklich.

von Stefan Salewski (Gast)


Lesenswert?

Autor: yalu (Gast) schieb:

>So geht's:

Danke, so langsam errinnere ich mich wieder...

von eklige Tunke (Gast)


Lesenswert?

Stefan Salewski schrieb:
> Ich dachte etwas so:
>
> i=0;
> while (i++ != 0) {}
>
> i=255;
> while (i-- != 255) {}
>
> Man nimmt also den Überlauf in kauf. Ich denke schon, dass das
> funktioniert.
Warum denkst du nur und probierst es nicht aus?
yalus Lösung geht.

von Stefan Salewski (Gast)


Lesenswert?

>Warum denkst du nur und probierst es nicht aus?

Warum sollte ich?

>yalus Lösung geht.

Ja, denke ich auch.

von Klaus W. (mfgkw)


Lesenswert?

Stefan Salewski schrieb:
> i=0;
> while (i++ != 0) {}

das wird nie ausgeführt.
Du meinst vielleicht ++i statt i++?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

yalu schrieb:

> Das ist zwar nicht klinisch sauber, da der Additionsüberlauf genutzt
> wird, aber auf Mikrocontrollern erlaubt :)

Da du ein uint8_t benutzt hast, ist das sogar "klinisch sauber".
Der Überlauf einer vorzeichenlosen Zahl nach 0 ist definiert, und
bei einem uint8_t ist auch klar, dass der Typ genau 8 bits breit
ist.

von Stefan Salewski (Gast)


Lesenswert?

>Du meinst vielleicht ++i statt i++?

Ja. Ich sollte mich mich vielleicht doch mal wieder aufraffen etwas in C 
zu programmieren. Das Gedächtnis...

von Simon K. (simon) Benutzerseite


Lesenswert?

Ok, zusammen mit dem Überlaufbit hat man natürlich 9 Bits :-)

Wusste nicht, wie man das gescheit in der Schleife nutzen kann. Danke 
yalu!

von Flo (Gast)


Lesenswert?

es geht nicht mit nur einer Abfrage (egal ob do while, while oder for) 
mit einem(!) 8 bit Zähler (256 Möglichkeiten) eine Schleife mit 256 
Durchläufen zu bauen.
Denn bei welchem Wert des Zählers soll er aufhören? 256 gibts nicht und 
alles andere wird schon vor dem 256. Durchlauf durchlaufen (was ein 
Wortspiel).

Viel Spaß beim Suchen der Möglichkeiten :-)

von Simon K. (simon) Benutzerseite


Lesenswert?

Flo schrieb:
> es geht nicht mit nur einer Abfrage (egal ob do while, while oder for)
> mit einem(!) 8 bit Zähler (256 Möglichkeiten) eine Schleife mit 256
> Durchläufen zu bauen.
> Denn bei welchem Wert des Zählers soll er aufhören? 256 gibts nicht und
> alles andere wird schon vor dem 256. Durchlauf durchlaufen (was ein
> Wortspiel).
>
> Viel Spaß beim Suchen der Möglichkeiten :-)

Siehe ein Beitrag über deinem. Das Überlaufbit fungiert als 9. Bit.

von Rolf Magnus (Gast)


Lesenswert?

Das Überlaufbit hat damit nichts zu tun. Man benutzt auch keine 9 Bits.

von Flo (Gast)


Lesenswert?

Dass geht aber nur mit einer Programmiersprache, mit der du auf das 
Carrybit zugreifen darfst.
Ist in C/C++ nicht der Fall / nicht zu empfehlen, da die Abfragen nicht 
immer unmittelbar nach den Operationen kommen, deren Ergebnis du haben 
willst.

von hilfe mein byte ist zu klein (Gast)


Lesenswert?

Oder zwei Schleifen bis 128... oder eine schleife mit 255 durchgängen 
und einer extra....oder gleich den passenden Datentyp nehmen ;-)

von Simon K. (simon) Benutzerseite


Lesenswert?

Rolf Magnus schrieb:
> Das Überlaufbit hat damit nichts zu tun. Man benutzt auch keine 9 Bits.

Entweder du erklärst das, oder ich unterstelle dir, dass du yalus 
Beitrag nicht gelesen hast.

EDIT: Ok, ich muss das noch mal ausprobieren bei Gelegenheit. Sicher, 
dass bei yalu's Methode 256 Iterationen gemacht werden?
Bin leider gerade in Klausurübungen vertieft.

von Stefan Salewski (Gast)


Lesenswert?

Autor: Rolf Magnus (Gast) schrieb:

>Das Überlaufbit hat damit nichts zu tun. Man benutzt auch keine 9 Bits.

Das wollte ich auch gerade schreiben, auch wenn es etwas nach 
Korintenkackerei klingen mag.

An yalus Beispiel sieht man, dass man zwar den Überlauf ausnutzt, aber 
kein Überlauf-Bit abfragen muss.

von 900ss (900ss)


Lesenswert?

Jörg Wunsch schrieb:
> Ein char muss
> mindestens 8 bits haben, um eine konforme Implementierung zu
> erreichen.
>
> Es können allerdings mehr Bits sein, es gibt beispielsweise konforme
> Implementierungen auf irgendeinem DSP,

Nicht auf irgendeinem, es gibt mehrere, z.B. TMS320C3x oder ADSP21020 
und noch andere. Das sind zwar alles seeeehr alte Dinger, aber immer 
noch viel benutzt in gewissen Technik-Bereichen. :-/
Hat aber einen Vorteil, eine Exception wegen "unaligned access" passiert 
dort nicht. :-) Ein Adressinkrement sind dort immer 32 Bit.

> der als kleinste adressierbare
> Einheit einen 32-bit-Integer hat.  Dort ist ein char dann auch 32
> bits breit (aber sizeof(char) ist trotzdem 1!, denn das ist so
> definiert).
Genauso verhält es sich.


> uint8_t i;

Soetwas gibt es dann auch nicht. Wenn man einen Zähler bis 255 braucht, 
dann kann man nicht mit dem Überlauf arbeiten, sondern man muß das 
explizit kodieren, ansonsten Pech gehabt :-) Der Compiler ist nicht so 
schlau und setzt das selber um.

von Rolf Magnus (Gast)


Lesenswert?

>> Das Überlaufbit hat damit nichts zu tun. Man benutzt auch keine 9 Bits.
>
> Entweder du erklärst das, oder ich unterstelle dir, dass du yalus
> Beitrag nicht gelesen hast.

Wo steht denn dort was von einem Überlaufbit? Man nutzt aus, daß ein 
8-Bit-Integer mit dem Wert von 255 bei einem Inkrement auf 0 springt 
(Überlauf). Mit dem Überlauf-Flag hat das aber nichts zu tun. Das gibt 
es in C auch gar nicht. Es wird im Prozessor zwar bei einem Überlauf 
gesetzt, aber für diese Schleife überhaupt nicht benutzt. Die würde ohne 
Existenz dieses Flags genauso funktionieren.

von yalu (Gast)


Lesenswert?

Flo schrieb:
> es geht nicht mit nur einer Abfrage (egal ob do while, while oder for)
> mit einem(!) 8 bit Zähler (256 Möglichkeiten) eine Schleife mit 256
> Durchläufen zu bauen.
> Denn bei welchem Wert des Zählers soll er aufhören? 256 gibts nicht und
> alles andere wird schon vor dem 256. Durchlauf durchlaufen (was ein
> Wortspiel).

Der Trick besteht darin, eine post-checked Loop zu benutzen. Bei dieser
wird der erste Schleifendurchlauf ausgeführt, obwohl die Bedingung
(i!=0) falsch ist, da die Abfrage ja erst am Ende kommt. Dieser
zusätzliche Schleifendurchlauf macht die 256 voll.

Bei einer pre-checked Loop (While- oder For-Schleife) stimmt deine
Überlegung, deswegen verliefen auch Stefan Salewskis Versuche mit der
While-Schleife im Sand.

von doc (Gast)


Lesenswert?

Exakt.
1
uint8_t j=0;
2
do {
3
 printf("%d ", j);
4
 j++;
5
} while (j);

Und siehe da, es geht mit 8 Bit.
Das mit dem gedachten Carry hatte schon was richtiges :-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

doc schrieb:
> Und siehe da, es geht mit 8 Bit.

Das ist doch aber nichts anderes als yalus Variante, nur dass er
das Inkrementieren in die while-Klausel verlegt hat (als Präfix-
Operator).

900ss D. schrieb:

> Nicht auf irgendeinem, es gibt mehrere, z.B. TMS320C3x oder ADSP21020
> und noch andere. [...]

Ich kannte sie gerade nicht mit Vornamen, daher habe ich das etwas
anonymisiert geschrieben. ;-)

>> uint8_t i;
>
> Soetwas gibt es dann auch nicht.

Richtig, daher ist diese Schreibweise auch sicher ("unsigned char i;"
wäre es nicht).  Wenn man nicht "exakt 8 bits breit" meint, sollte
man sich ohnehin besser angewöhnen, "uint_fast8_t" statt "uint8_t"
zu benutzen.  Dann hat der Compiler die Freiheit, auf einem 32-bit-
Prozessor auch 32 bits stattdessen zu nutzen, wenn diese schneller
sind (bspw. ein komplettes 32-bit-Register auf einer 32-bit-CPU).

von doc (Gast)


Lesenswert?

doc schrieb:
>> Und siehe da, es geht mit 8 Bit.

>Das ist doch aber nichts anderes als yalus Variante,

Deshalb schrieb ich ja auch :
>Exakt

:-)
Habs nur etwas deutlicher formuliert.

von 900ss (900ss)


Lesenswert?

Jörg Wunsch schrieb:
> Richtig, daher ist diese Schreibweise auch sicher ("unsigned char i;"
> wäre es nicht).

Ja, ich nutze eigentlich auch nur noch die "neuen" Typen. Und es gibt 
sooo viele Leute, die das nicht machen. Gestern hat man mir Code aus dem 
Jahre 2000 vorgelegt, den ich jetzt adaptieren soll.

Dort steht dann z.B. drin:

#define BIT_AND &
#define LOG_AND &&
#define BIT_OR |
#define LOG_OR ||

if( status BIT_AND BIT_RX )
  machWas();

Der ganze Code ist mit solchen Makros vollgestopt. Kann man nicht lesen.
Mir ist nichts mehr eingefallen :-(
Ähh ja, Offtopic :-)

> Wenn man nicht "exakt 8 bits breit" meint
Schön formuliert :-)

von doc (Gast)


Lesenswert?

>Mir ist nichts mehr eingefallen :-(

Search & Replace.

von yalu (Gast)


Lesenswert?

doc schrieb:
> Das mit dem gedachten Carry hatte schon was richtiges :-)

Mit dem Carry hat das wirklich nichts zu tun. Für einen AVR wird die
Do-Schleife bspw. so übersetzt:
1
  ldi r24,lo8(0)
2
.L2:
3
  ; ...
4
  subi r24,lo8(-(1))
5
  brne .L2

Das einzige Prozessorflag, das abgefragt wird, ist das Zero-Flag.

von doc (Gast)


Lesenswert?

> Das mit dem gedachten Carry hatte schon was richtiges :-)

>Mit dem Carry hat das wirklich nichts zu tun.

Stimmt, da wird kein Carry-Bit benutzt. Deswegen ist es ja auch nur 
GEDACHT.
Hätte ich es anders gemeint, hätte ich das auch anders geschrieben.
Gedacht als Denkhilfe halt..

grummel...
Ich geh lieber programmieren... tschö.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

900ss D. schrieb:

> #define BIT_AND &
> #define LOG_AND &&
> #define BIT_OR |
> #define LOG_OR ||

Das erinnert mich an ein Stück Software namens "team".  War ein
wirklich interessantes Stück von der Funktion: ein Ringpuffer
zur Zwischenspeicherung von Daten für ein Magnetbandgerät, damit
das Band am gleichmäßigen Laufen ("streaming") bleibt.  Anders als
das "creeping featurism"-Teil von GNU (heißt wohl "buffer") kam
team mit den Möglichkeiten eines V7 UNIX aus: für jeden der
umzuschaltenden Puffer wurde ein eigener Prozess per fork()
erzeugt, alle diese Prozesse haben sich die Deskriptoren für stdin
(Quell-Datenstrom) und stdout (Magnetband) geteilt, und die
Synchronisation zwischen den Prozessen (wer liest und wer schreibt)
erfolte über Pipes zwischen diesen.  Wirklich "cool", wie man das
heutzutage nenne würde.

Aber der Sourcecode.  Oh Gott. :-)
1
# define call           (void)
2
# define were           if
3
# define fast           register
4
# define global         /* extern */
5
# define local          static
6
# define when           break; case
7
# define otherwise      break; default
8
# define mode(which,name) typedef which name name; which name
9
# define bool   int
10
# define true           1
11
# define false          0
12
# define nil(type)      ((type) 0)
13
# define scalar         int

:-)

von Rolf Magnus (Gast)


Lesenswert?

Aber wozu denkst du's dir denn, wenn's gar nicht verwendet wird?
duck

900ss D. schrieb:

> Dort steht dann z.B. drin:
>
> #define BIT_AND &
> #define LOG_AND &&
> #define BIT_OR |
> #define LOG_OR ||
>
> if( status BIT_AND BIT_RX )
>   machWas();

Der wußte wohl nicht, daß es einen Standard-C-Header gibt, der dafür 
extra schon Makros mitbringt.
http://en.wikipedia.org/wiki/Iso646.h

von Michael G. (linuxgeek) Benutzerseite


Lesenswert?

danny schrieb:
> Ok Ok.. mir ist klar das unsigned char als [0; 255] definiert ist!
>
> Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, dass er ein
> CP   Rxy, 0xFF
> BREQ adr
> erstellt!
>
> Macht er also nicht...

Bevor Du die Qualitaet des Compilers anzweifelst solltest Du erst einmal 
semantisch korrekten Code schreiben, was haeltst Du davon?

von Simon K. (simon) Benutzerseite


Lesenswert?

Michael G. schrieb:
> danny schrieb:
>> Ok Ok.. mir ist klar das unsigned char als [0; 255] definiert ist!
>>
>> Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, dass er ein
>> CP   Rxy, 0xFF
>> BREQ adr
>> erstellt!
>>
>> Macht er also nicht...
>
> Bevor Du die Qualitaet des Compilers anzweifelst solltest Du erst einmal
> semantisch korrekten Code schreiben, was haeltst Du davon?

Danke für deinen Kommentar.

von 900ss (900ss)


Lesenswert?

Jörg Wunsch schrieb:
> Aber der Sourcecode.  Oh Gott. :-)

Ja das genauso schlimm :-)

Rolf Magnus schrieb:
> Der wußte wohl nicht, daß es einen Standard-C-Header gibt, der dafür
> extra schon Makros mitbringt.

Da schlägt es einen nieder. Das gibt es sogar vorgekaut ;-)
Nun ja, nicht mein Stil. Kann man sich wohl drna gewöhnen, wenn man es 
muß.

von Simon K. (simon) Benutzerseite


Lesenswert?

Dann kann man nachher Programme schreiben im Stil von

int main()
{
    Use Elevator() in case of "Fire";
}

oder sowas ;)

von helferlein (Gast)


Lesenswert?

for(i=0;dooo(),++i;);

von Klaus (Gast)


Lesenswert?

helferlein schrieb:
> for(i=0;dooo(),++i;);

Was will uns dieser Beitrag sagen?!?

von Malte _. (malte) Benutzerseite


Lesenswert?

Jörg Wunsch schrieb:
> Es können allerdings mehr Bits sein, es gibt beispielsweise konforme
> Implementierungen auf irgendeinem DSP, der als kleinste adressierbare
> Einheit einen 32-bit-Integer hat.  Dort ist ein char dann auch 32
> bits breit (aber sizeof(char) ist trotzdem 1!, denn das ist so
> definiert).

D. h. folgender Code würde nicht wie erwartet funktionieren?
1
#define BUFFSIZE 128
2
char * buff = malloc(sizeof(char)*BUFFSIZE);
3
if (buff) {
4
  uint8_t i;
5
  for (i = 0; i < BUFFSIZE; i++) {
6
    *(buff+i) = 42;
7
  }
8
}
weil malloc nur 128 Byte reserviert, aber 128 mal in 32 Bit Schritten 
weiter gegangen wird?

von Klaus W. (mfgkw)


Lesenswert?

Falsch.
Genauer gesagt: der Code würde arbeiten wie ich es erwarte.
Was du erwartest weiß ich nicht genau :-)

Auf einem solchen System ist doch wie gesagt ein char
32 Bit groß (also nicht ein Byte, sondern 4).

Mit sizeof(char) ist dort 1, sizeof(char)*128 ist 128.
Also reserviert malloc(sizeof(char)*BUFFSIZE) dann
128 char, also 128*4 Byte.

Mit *(buff+0) bis *(buff+127) greift man auf jeweils eines
dieser 4-Byte-char zu und alles ist in Ordnung.
Außer daß jede 42 in 4 Byte gespeichert ist, weil ein char
ja so groß ist.

von Karl H. (kbuchegg)


Lesenswert?

Malte __ schrieb:
> Jörg Wunsch schrieb:
>> Es können allerdings mehr Bits sein, es gibt beispielsweise konforme
>> Implementierungen auf irgendeinem DSP, der als kleinste adressierbare
>> Einheit einen 32-bit-Integer hat.  Dort ist ein char dann auch 32
>> bits breit (aber sizeof(char) ist trotzdem 1!, denn das ist so
>> definiert).
>
> D. h. folgender Code würde nicht wie erwartet funktionieren?

Kommt auf deine Erwartungen an :-)

>
1
> #define BUFFSIZE 128
2
> char * buff = malloc(sizeof(char)*BUFFSIZE);
3
> if (buff) {
4
>   uint8_t i;
5
>   for (i = 0; i < BUFFSIZE; i++) {
6
>     *(buff+i) = 42;
7
>   }
8
> }
9
>
> weil malloc nur 128 Byte reserviert,

warum sollte es?

Hinweis. Der C-Standard weiß eigentlich nichts von Bytes, so wie wir den 
Begriff benutzen. Im C-Standard ist Byte synonym zu sizeof(char) zu 
sehen. malloc allokiert in dem Fall 128 C 'Bytes', die auf diesem System 
dann 512 unsere üblichen 8 Bit Bytes entsprechen. In diesem Sinne ist 
die übliche Beschreibung für malloc, dass es 'Bytes' allokiert 
eigentlich nicht richtig. malloc allokiert die angegebene Anzahl 
char-Einheiten :-)

von Bleifuss (Gast)


Lesenswert?

Mit Pointercasting kann man sich dann aber eine rostige Scud durch den 
Fuss schiessen.

von Karl H. (kbuchegg)


Lesenswert?

Bleifuss schrieb:
> Mit Pointercasting kann man sich dann aber eine rostige Scud durch den
> Fuss schiessen.

Auch nicht.
Das ist alles so abgestimmt, dass ein Rädchen ins andere greift :-)

Einzig und alleine auf Hardware-Bytes kann man dann nicht mehr direkt 
zugreifen.

ALlerdings macht man so etwas ja auch nicht nach Lust und Laune. 
Meistens stecken da Hardware-Restiktionen dahinter. D.h. dass es bei 
besagtem DSP höchst wahrscheinlich gar nicht möglich ist, auf 8 Bit 
Bytes im Speicher zuzugreifen.

von Malte _. (malte) Benutzerseite


Lesenswert?

Klaus Wachtler schrieb:
> Genauer gesagt: der Code würde arbeiten wie ich es erwarte.
> Was du erwartest weiß ich nicht genau :-)
Ich denke meist kann man von einem Code erwarten, dass nicht das Ziel 
ist in nicht zugewiesenen Speicher zu schreiben ;-)

Karl heinz Buchegger schrieb:
> malloc allokiert in dem Fall 128 C 'Bytes', die auf diesem System
> dann 512 unsere üblichen 8 Bit Bytes entsprechen.
Ok, dass macht dann wieder Sinn.

von Bleifuss (Gast)


Lesenswert?

Dann sollte sizeof(irgendein_int32_typ) aber auch 1 zurückgeben....

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Klaus schrieb:

>> for(i=0;dooo(),++i;);
>
> Was will uns dieser Beitrag sagen?!?

Dass diese Schleife ebenfalls 256mal durchlaufen wird und dabei
256mal die Funktion dooo() aufgerufen wird.  Ist allerdings schon
beinahe IOCCC-verdächtig. ;-)

von yalu (Gast)


Lesenswert?

Bleifuss schrieb:
> Dann sollte sizeof(irgendein_int32_typ) aber auch 1 zurückgeben....

Tut es auch. Noch besser: Auf dem TMS320C3x und -C4x ist auch

  sizeof(double) == 1

von Simon K. (simon) Benutzerseite


Lesenswert?

Jörg Wunsch schrieb:
> Klaus schrieb:
>
>>> for(i=0;dooo(),++i;);
>>
>> Was will uns dieser Beitrag sagen?!?
>
> Dass diese Schleife ebenfalls 256mal durchlaufen wird und dabei
> 256mal die Funktion dooo() aufgerufen wird.  Ist allerdings schon
> beinahe IOCCC-verdächtig. ;-)

Aaaah. Gut entziffert!

Btw, for-Schleifen wo nicht alle 3 "Teile" vorhanden sind, sind meist 
einfacher durch while oder do-while darstellbar. So als Faustregel.

von Klaus W. (mfgkw)


Lesenswert?

Jörg Wunsch schrieb:
>>> for(i=0;dooo(),++i;);
>>
>> Was will uns dieser Beitrag sagen?!?
>
> Dass diese Schleife ebenfalls 256mal durchlaufen wird und dabei
> 256mal die Funktion dooo() aufgerufen wird.  Ist allerdings schon
> beinahe IOCCC-verdächtig. ;-)

Jein.

dooo() wird 256 mal aufgerufen, weil es im Test steht.
"Die Schleife" im Sinne des Schleifenrumpfes (das Nichts vor
dem Semikolon) wird nur 255 mal durchlaufen.

Nur zur Sicherheit, um Mißverständnisse durch neue Unklarheiten
zu ersetzen...

von Simon K. (simon) Benutzerseite


Lesenswert?

Klaus Wachtler schrieb:
> Jein.
>
> dooo() wird 256 mal aufgerufen, weil es im Test steht.
> "Die Schleife" im Sinne des Schleifenrumpfes (das Nichts vor
> dem Semikolon) wird nur 255 mal durchlaufen.
>
> Nur zur Sicherheit, um Mißverständnisse durch neue Unklarheiten
> zu ersetzen...

Ah, ja, wichtiger Hinweis! Dann kann man natürlich keine andere Schleife 
benutzen um den "Effekt" zu benutzen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.