www.mikrocontroller.net

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


Autor: danny (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: test (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Dummy,

schau 'mal wie unsigned char definiert ist!

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Mmmh (Gast)
Datum:

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

Seufz.

Autor: danny (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Mmmh (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: danny (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Bernd O. (bitshifter)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: danny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke..danke..alles klar!

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: eklige Tunke (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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).

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht 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. ;-)

Autor: Mmmh (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Autor: eklige Tunke (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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... ;-)

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So geht's:
  uint8_t i;

  i=0;
  do {
    // ...
  } while(++i);

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

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Autor: yalu (Gast) schieb:

>So geht's:

Danke, so langsam errinnere ich mich wieder...

Autor: eklige Tunke (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Warum denkst du nur und probierst es nicht aus?

Warum sollte ich?

>yalus Lösung geht.

Ja, denke ich auch.

Autor: Klaus Wachtler (mfgkw)
Datum:

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

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 :-)

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Überlaufbit hat damit nichts zu tun. Man benutzt auch keine 9 Bits.

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: hilfe mein byte ist zu klein (Gast)
Datum:

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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: doc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Exakt.
uint8_t j=0;
do {
 printf("%d ", j);
 j++;
} while (j);

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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).

Autor: doc (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht 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 :-)

Autor: doc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Mir ist nichts mehr eingefallen :-(

Search & Replace.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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:
  ldi r24,lo8(0)
.L2:
  ; ...
  subi r24,lo8(-(1))
  brne .L2

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

Autor: doc (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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ö.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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. :-)
# define call           (void)
# define were           if
# define fast           register
# define global         /* extern */
# define local          static
# define when           break; case
# define otherwise      break; default
# define mode(which,name) typedef which name name; which name
# define bool   int
# define true           1
# define false          0
# define nil(type)      ((type) 0)
# define scalar         int

:-)

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht 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ß.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann kann man nachher Programme schreiben im Stil von

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

oder sowas ;)

Autor: helferlein (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
for(i=0;dooo(),++i;);

Autor: Klaus (Gast)
Datum:

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

Was will uns dieser Beitrag sagen?!?

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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?
#define BUFFSIZE 128
char * buff = malloc(sizeof(char)*BUFFSIZE);
if (buff) {
  uint8_t i;
  for (i = 0; i < BUFFSIZE; i++) {
    *(buff+i) = 42;
  }
}
weil malloc nur 128 Byte reserviert, aber 128 mal in 32 Bit Schritten 
weiter gegangen wird?

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht 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 :-)

>
> #define BUFFSIZE 128
> char * buff = malloc(sizeof(char)*BUFFSIZE);
> if (buff) {
>   uint8_t i;
>   for (i = 0; i < BUFFSIZE; i++) {
>     *(buff+i) = 42;
>   }
> }
> 
> 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 :-)

Autor: Bleifuss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit Pointercasting kann man sich dann aber eine rostige Scud durch den 
Fuss schiessen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Bleifuss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann sollte sizeof(irgendein_int32_typ) aber auch 1 zurückgeben....

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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. ;-)

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.