wie den Instruction Set nutzen?

> Wie lese ich das Carry Bit aus....
Welche Programmiersprache?
> Als Fehler sagt er...
Wer sagt das? Wenn du mit C programmierst, dann darf man deine Frage als 
Witz auffassen, oder?  :-/

Denn wenn das ein C-Programm ist, kannst du das Carry-Flag z.B. mit

1

 if (a>b) { ... }

auswerten. Dann wird a-b gerechnet, und wenn ein Unterlauf aufgetreten 
ist (also das Carry-Flag gesetzt wird), die Befehlsfolge {...} 
ausgeführt. Ergo: in C interessiert dich das Carry-Flag an sich gar 
nicht mehr, das macht alles der Compiler für dich.

erstmal danke für die schnelle Antwort
Aber auch wenn es sich wirklich um C handelt ist die Frage kein Witz! 
Denn ich habe das Problem, dass ich eine char Variable bitweise 
durchlaufen muss um sie in 8 Bit lange Blöcke zerlegen zu können.
Wollte das durch Schiften und anschließendes Auslesen des Carry bits 
realisieren.
Habe etwas ähnliches schonmal bei einem Infinion c167 gemacht und da ist 
es auch in C kein Problem das Carry bit auszulesen....

Hat dein C-compiler einen Inlineassembler dann kannst du aus asm 
mnemonik zurückgreifen.

Sonst musst du die Funktion in asm schreiben und vom c-compiler 
einbinden lassen.

@ Christian K. (mick-roc)

>Denn ich habe das Problem, dass ich eine char Variable bitweise
>durchlaufen muss um sie in 8 Bit lange Blöcke zerlegen zu können.

Aha, Fuzzy Logik oder was?

>Habe etwas ähnliches schonmal bei einem Infinion c167 gemacht und da ist
>es auch in C kein Problem das Carry bit auszulesen....

Nicht so viel kiffen, das schlägt auf's Gemüt und den ohnehin nur knapp 
zweistelligen IQ . . . .

Irgend welche der Arithmetik-Flags aus dem Statusregister in C 
auszulesen ist zwar möglich, aber ziemlich sinnlos, denn schon mit 
geänderten Optimierungseinstellungen, oder der nächsten Compilerversion 
muß der Code nicht mehr funktionieren.

Der Zustand der Flags gehört zum Innenleben der abstrakten C-Maschine 
und ist aus C-Sicht undefiniert.

Für besondere Zwecke stellen viele C-Compiler einen Inline-Assembler zur 
Verfügung, mit dem man sozusagen alle Sauereien machen kann. Aber man 
sollte im eigenen Interesse damit äußerst sparsam umgehen, wenn man 
nicht im unpassenden Moment später böse Überraschungen erleben will...

Einzelne Bits eines Bytes/Worts fragt man in C z.B. so ab:

1

 if (byte&(1<<position)!=0) {...}

Zum Verständnis wie der Compiler die Klammern von innen her aufdröseln:

1

(1<<position)

 erzeugt eine Maske, bei der eine 00000001 um "position" Stellen nach 
links verschoben wird. Mit position==3 ergibt sich also 00001000.
& ist der binäre UND-Operator. In

1

byte&(1<<position)

wird also byte mit der vorher erzeugten Maske UND-verknüpft.
Und wenn dann ganz zum Schluss das Ganze ungleich Null ist

1

(byte&(1<<position)!=0)

dann wird die Klammer ausgeführt.

Fertig, ganz ohne Carry.

Aber mein Tipp:
Kauf dir das Standardwerk von K&R "Programmieren in C" und lies dir das 
in Ruhe durch. C ist keine Sprache, in der überhaupt ein Carry-Flag 
definiert ist (weil das ja schon wieder recht Prozessorabhängig ist). 
Wozu also eines einsetzen?

EDIT:
> dass ich eine char Variable bitweise
> durchlaufen muss um sie in 8 Bit lange Blöcke zerlegen zu können.
char-Variablen sind beim PIC 8 Bit lang, wozu also noch zerlegen?

Ok, an lkmiller, uhu und winne ein Danke, ich denke es ist durgekommen, 
dass ich noch kein Profi bin....
aber solche Kommentare wie von falk verbitte ich mir! Kann ja wohl nicht 
wahr sein, dass man hier als Neuling gleich als dumm bezeichnet wird nur 
weil man IN EINEM FORUM eine Frage stellt, egal wie unqualifiziert sie 
sein mag!!!

Das Buch werd ich mir vermutlich mal anschaun, scheine wirklich Lücken 
zu haben....
Damit kann geschlossen werden.

Christian K. wrote:

> Das Buch werd ich mir vermutlich mal anschaun, scheine wirklich Lücken
> zu haben....

Es ist das Standardwerk über C - das sollte jeder C-Programmierer 
gründlich durcharbeiten.

Über Falk mußt du dich nicht aufregen; es reicht, von ihm zu lernen - 
der ist ein echter Elektronik-Experte und kein Diplomat.

>> Fertig, ganz ohne Carry.
> Dürfte aber zu deutlich größerem und länger dauerndem Code führen.
Ja, wahrscheinlich.
Aber C ist keine Sprache, die maximale Effizienz für sich beansprucht 
(dafür gibts ja Assembler). Sondern mit einem generisch geschriebenen 
C-Programm erreiche ich bestmögliche Portierbarkeit des Codes auf 
unterschiedliche Zielarchitekturen.

> Wenn man das braucht, muß man's aber eben in Assembler machen.
Wobei es heute in der Industrie billiger ist, einen schnelleren 
Controller zu nehmen, als einen schmächtigen von Hand so lange 
hinzutrimmen, dass er es gerade noch so packt. Nur, um dann mit der 
Markteinführung 6 Monate hinter der Konkurrenz zu sein :-(

> Naja, für die drei Zeilen Assembler bracht man keine 6 Monate.
Auch richtig.
Aber für solche Anwendungen sind recht gute Compilerkentnisse nötig, 
damit z.B. durch einen Interrupt nicht alles zerhagelt wird. Das sind 
dann die Programme, die eigentlich immer laufen, aber einmal am Tag 
Probleme machen :-o

Ich habe die Erfahrung gemacht, dass, wenn solche Tricks nötig sind, 
irgendwoanders im Systemdesign der Hund begraben ist. Und der wacht 
garantiert früher oder später als Zombie wieder auf  :-/


> Und bei sehr hohen Stückzahlen wird jeder halbe Cent, den man pro
> hergestelltem Gerät sparen kann, auch gespart.
Ich lass das Sparen dann den Einkauf machen  ;-)

Rolf Magnus wrote:

> Naja, ich wüßte keinen, der keins hat.

Beispielsweise MIPS, also auch PIC32.