also hier einige fragen:
soll 16-Bit-Zahl eine Struktur sein oder ist einfach gemeint, dass ich das ergebnis binär zurückgeben (also printen) soll?
beim einerkomplement gibt es ja zwei nullen mir ist das problem dabei noch nicht klar? kann ich nicht einfach jede zahl invertieren, zum bisherigen ergebnis addieren und die oberen 16 bit auf null setzen, das ganze so lange bis ich das ganze array abgearbeitet habe? inwiefern hat man da ein problem mit den beiden darstellungen der 0?

On a 2's complement machine, the 1's complement sum must be computed by means of an "end around carry", i.e., any overflows from the most significant bits are added into the least significant bits.

http://www.faqs.org/rfcs/rfc1071.html

kann ich nicht einfach jede zahl invertieren

Dass eine Zahl im Einerkomplement dargestellt wird heisst ja nicht, dass sie auf jeden Fall negativ ist.

Wie steht es mit seiner Frage zu der 16-Bit-Zahl? Die finde ich viel interessanter. Was ist damit gemeint? In C gibt es laut limits.h nichts 16-bittiges. Ich werde 32-Bit-Integer nutzen, von denen nur die untersten 16 Bit esetzt sind. Das erscheint mir aber nicht im Sinne der Aufgabe.

Wie also nun damit umgehen außer, dass ich lduh benutze um die Daten aus dem Array/Speicher zu holen?

Kann noch mal jemand die genaue Aufgabenstellung posten (hab den Zettel nicht) und mir sagen ob die Aufgabe abzugeben ist.

Vielen Dank

und mir sagen ob die Aufgabe abzugeben ist.

Ist sie. Den Zettel hab ich aber grade nicht zur Hand.

Aufgabe 10:
Internet-Prüfsumme: schreiben sie ein assembler-unterprogramm der signatur 16-bit-zahl pruefs(16-bit-zahl a[], int n), das das einerkomplement der einerkomplementsumme der n im array a übergebenen 16-bit-ketten berechnet.
abgeben per e-mail an den übungsleiter usw. wie bisher also

hat mal jemand ein Beispiel berechnet? Ich würde meinen algorithmus gerne mal mit einem Beispiel überprüfen

unsigned short a;
for(int i = 0; i < 1000000; i++)
{
a = i & 0x0000FFFF;
}

=> Ergebnisse:
pruefs(a,10000) ist f8fc
pruefs(a,1000000) ist 908d

wobei die 2. summe unrealistisch ist weil es so lange ip pakete nicht geben darf (aber berechnen kann mans ja trotzdem mal)

unsigned short a[ 1000000 ];
natuerlich… das forum hat die eckigen klammern geklaut *g*

Bei deinem Ansatz verwendest du ein unsigned short zum Speichern der 16-Bitzahl. Ich verstehe die Aufgabe aber so, dass man eine Struktur namens 16-Bit-Zahl erstellen soll, in der dann 16 integers oder unsigned shorts enthalten sind, die jeweils nur ein einzelnes Bit repräsentieren. Man könnte zwar auch nur einen einzigen unsigned short in der Struktur verwenden, aber dann bräuchte man eigentlich keine eigene Struktur dafür.
Ich weiss jetzt nicht, wie die Aufgabenstellung wirklich gemeint ist. Es wäre schön, wenn da jemand mal für Klarheit sorgen könnte.

Unser Übungsgruppenleiter sagte recht klar, das short der Datentyp unserer Wahl wäre.
Wie kommst du auf die Idee mit dem struct?

struct wohl weil sonst ja auf dem aufgabenzettel direkt short stehen könnte..
ich fands auch etwas verwirrend - aber unser übungsgruppenleiter sagte auch dass wie das mit normalen unsigned short machen sollen

Ein struct wäre dafür unsinnig. Ich nehme an da steht 16-Bit-Zahl, damit man mal drüber nachdenkt, was man da so nehmen kann. Ich habe in meinen Gruppen auch "short" verkündet und erwarte das auch. Ein strcut wäre überflüssig und extrem aufwändig dafür.

Sollen die Zahlen im Einerkomplement addiert werden?
Oder sollen die Einerkomplemente der Zahlen im Einerkomplement addiert werden?

=> Ergebnisse:
pruefs(a,10000) ist f8fc

Dieses Ergebnis bekomme ich nur dann raus, wenn ich jedes Arrayelement vor der Addition extra invertiere. Edit: ich hatte ürsprunglich übersehen, dass die Endsumme noch invertiert werden muss. Wie sieht das bei Deiner Lösung aus? Mit meiner jetzigen Lösung kann ich das Ergebnis f8fc gar nicht mehr nachvollziehen, hier kommt jetzt 200d raus. Ich kann mir allerdings nicht vorstellen, dass das so gewollt ist, denn aufgrund einer angenommenen Gleichverteilung der 16-Bit-Werte im Array würde das für die Qualität der Prüfsumme überhaupt nichts bringen.

Wie gesagt: Addition im Einerkomplement heisst NICHT, dass man die Einerkomplemente erst bilden muss. Sie liegen bereits vor!

Das besondere am Einerkomplement ist ja "nur" die Behandlung eines Überlaufs. Wenn man lediglich per "add" alle Elemente addiert, würde ja (-1) + (-1) = (-3) ergeben, und das ist definitiv falsch.

10000 als Testfall finde ich nicht interessant, weil da nur positive Zahlen vorkommen. Ich habe folgenden Testfall verwendet:

int main() { unsigned short a[ 65000 ]; for(int i = 0; i < 65000; i++) { a[ i ] = i; } printf("%04x\n", add1c(a, 65000)); return 0; } Das Ergebnis lautet hier cfe9. Kann das jemand bestätigen?

also wie jetzt.

Ich habe jedes Element des Arrays's invertiert, dann diese einzeln addiert und die Überläufe entsprechend behandelt.

Und am Ende die Summe erneut invertiert.

Dann kommt logischerweise, wenn ich 3 mal die 6 als Element nehme 18 raus . Was ja additiv korrekt ist, aber das kanns ja irgendwie nicht sein. Das ganze muss ja anders gemeint sein, sonst kann ich ja einfach ganz normal addieren lassen. Wie ist es gemeint?

Ich habe jedes Element des Arrays's invertiert

Soweit ich das aus diversen Internetquellen gelesen habe, ist das schlicht falsch.
Und soweit ich da selbst drüber nachdenke, ist es unsinnig.

dann diese einzeln addiert und die Überläufe entsprechend behandelt.

Und am Ende die Summe erneut invertiert.

Das ist dann auch alles richtig.

Dann kommt logischerweise, wenn ich 3 mal die 6 als Element nehme 18 raus . Was ja additiv korrekt ist, aber das kanns ja irgendwie nicht sein. Das ganze muss ja anders gemeint sein, sonst kann ich ja einfach ganz normal addieren lassen. Wie ist es gemeint?

Probier doch einfach mal weniger triviale Werte wie etwa -1…

also uns wurde gesagt dass wir im internet für den algorithmus nachgucken können… und ich glaub das ist dieser:

[EditTri: aus RFC1071, sucht man schön]

den hab ich als hilfe zur erstellung des assemblercodes verwendet.. (weil ich auch nicht genau wusste was man nun bei der einerkomplement-addition beachten muss..

[EditTri: Algorithmus gelöscht]

also uns wurde gesagt dass wir im internet für den algorithmus nachgucken können…

Selbstverständlich! Eigenrecherche wird sogar begrüsst.

und ich glaub das ist dieser:

Bitte keine kompletten Algorithmen posten.

und ich glaub das ist dieser:

Bitte keine kompletten Algorithmen posten.

Jup, ich war mal so frei da ein wenig zu editieren. Für laufende Übungsaufgaben ist das eine reichliche Hiflestellung so geschenkt wie der T3-Schein ist [img]http://www.fb18.de/gfx/25.gif[/img]

Alles klar, also Cfe9 habe ich auch raus, nachdem ich die Invertierung wie oben beschrieben rausgenommen habe :).

ok tut mir leid… ich dachte so einfach wie das im netz zu finden ist kann man das auch posten *g* (und war ja immerhin kein assembler und nicht genau so wie wir das brauchen)

ja und cfe9 hab ich auch heraus (und bei 10000 elementen 200d)

hab da auch mal ne frage
fred meinte irgendwo weiter oben, dass die zahlen bereits im 1-komplement vorliegen. ich hab mir mal ne -1 mit dem programm von blatt 5 als bitkette anzeigen lassen. das ergebnis war ffff, aber ist das nicht -1 im 2-komplement?
im 1-komplement müsste es doch fffe sein, jedes bit gekippt halt.

ich hab mir mal ne -1 mit dem programm von blatt 5 als bitkette anzeigen lassen.

Kann ich das mal sehen? Natürlich darfst Du im C-Programm nicht "-1" schreiben, sondern musst ~1 verwenden.

hm, ja gut das leuchtet irgendwie ein.
wenn im array nur positive werte stehen, dann muss man doch auf nichts weiter achten oder? einfach alle aufsummieren und beim ergebnis die bits umdrehen.

wenn im array nur positive werte stehen, dann muss man doch auf nichts weiter achten oder? einfach alle aufsummieren und beim ergebnis die bits umdrehen.

Naja, bei genügen Elementen im Array wirds da auch irgendwann einen Überlauf geben, den man dann berücksichtigen muss. Aber um ein kleines Beispiel nachzuvollziehen hast Du natürlich Recht. Wenn man beispielsweise die Zahlen 1, 2, 3, 4 und 5 zusammenrechnet und alle Bits invertiert sollte ~(1+2+3+4+5) = ~(15) = ~(0x000f) = 0xfff0 rauskommen.