Also mir ist irgendwie noch nicht ganz klar wie ich an die Werte in einem Array komme:

Habs auf die Art versucht, wo ist der Fehler? Bzw. Was fehlt?

Angenommen ich bekomme ein Array der größe 3 mit 3 Integern gefüllt vom Hauptprogramm. Das erste Argument das übergeben wurde ist das array.

save … blabla

mov %g0,%i3
ldub [%i0+%i3], %i0

jmp…
restore

Also ich hatte gehofft, dass "0"te-Element des Arrays zu bekommen. Dem ist aber nicht so, was ist falsch?

save … blabla

mov %g0,%i3
ldub [%i0+%i3], %i0

jmp…
restore

Der Ansatz ist schon richtig, an der Stelle liegt das erste (oder das Nullte, je nach Bezeichnungsvorlieben) Array- Element. Der
Vollständigkeit halber: das nächste Element liegt dann
bei %i0+4 und nicht, wie vielleicht manche C-Programmierer erwarten
würden, bei %i0+1.

Das Problem bei deinem Programm ist nur: Erstens muss zum Laden
eines Worts ld statt ldub benutzt werden
(ldub lädt nur ein vorzeichenloses Byte). Außerdem könnte es im
späteren Programmverlauf zum Problem werden, dass %i0 sofort
überschrieben wird. Das Programm sägt sich sozusagen den Ast ab,
auf dem das Array sitzt [img]http://www.fb18.de/gfx/17.gif[/img]

ah, danke. Sind die folgenden Elemente dann +8 +12 +16 usw. ja?

ah, danke. Sind die folgenden Elemente dann +8 +12 +16 usw. ja?

Ganz genau. Adressen werden in Byte angegeben und da ein Wort
32 Bit=4Byte hat, sind die Wort-Adressen an Offsets,
die Vielfache von 4 sind.

unsigned short sollte man mit lduh laden oder? (oder hast du da schon herumoptimiert? (so immer 2 ushort mit addx oder sowas? *g*) ;))

unsigned short sollte man mit lduh laden oder?

Im Prinzip, ja. Nur hatte er oben Integers verwendet und Herr
Lehmann hat, wenn ich mich richtig erinnere, auch vorgesehen,
dass wir ints nehmen.

mh ja uns wurde gesagt dass wir short variablen nehmen sollen..

Hi,

bei uns will unser Einerkomplement nicht klappen bzw. das einbinden von dem atty in das einerkompliment.

! davon das Einerkomplement

! xor %o4,%g0, %o4 ! DAS KLAPPT NOCH NICHT
xor %o4,0xF, %o4

Danke im vorraus

! xor %o4,%g0, %o4 ! DAS KLAPPT NOCH NICHT

Wenn Du ein Register exklusiv-oder mit dem Register %g0 verknüpfst ändert sich der Wert doch gar nicht…? Nimm xnor.

ldub [%i0+%i3], %i0

das nächste Element liegt dann bei %i0+4 und nicht, wie vielleicht manche C-Programmierer erwarten würden, bei %i0+1.

Falsch. Anonymie arbeitet mit dem ldub-Befehl, also handelt es sich offenbar um ein Byte-Array. Dort ist das nächste Element bei %i0+1. Ansonsten wäre das ja eine ziemliche Speicherverschwendung.

Wenn man mit 32-Bit-Arrays arbeitet hast Du natürlich Recht, da muss man immer 4 auf die Adresse draufaddieren, um zum nächsten Element zu kommen. Und bei 16-Bit-Arrays nur 2.

Danke werde es ausprobieren.

ldub [%i0+%i3], %i0

das nächste Element liegt dann bei %i0+4 und nicht, wie vielleicht manche C-Programmierer erwarten würden, bei %i0+1.

C-Programmierer wuerden so etwas nicht erwarten, wenn es falsch waere.

M*holding up the C Flag*o

PS: "C Flag"… *giggle*

Anonymie arbeitet mit dem ldub-Befehl, also handelt es sich
offenbar um ein Byte-Array. Dort ist das nächste Element bei %i0+1.
Ansonsten wäre das ja eine ziemliche Speicherverschwendung.

Schon klar, ich hatte Herrn Lehmann nur so verstanden, dass für die
Array-Inhalte ints verwendet werden sollen. Insofern wollte ich
sowohl auf das ldub hinweisen als auch das mit den Adressen
erwähnen.

Aber dann habe ich Herrn Lehmann wohl missverstanden.

Anonymie arbeitet mit dem ldub-Befehl, also handelt es sich
offenbar um ein Byte-Array.

Schon klar, ich hatte Herrn Lehmann nur so verstanden, dass für die
Array-Inhalte ints verwendet werden sollen.

OK, glaub ich Dir natürlich, aber wo soll denn da der Vorteil sein?

Ausserdem: In den IP-Paketen liegen die Daten ja nun einmal in einem bestimmten Format vor - da sind keine zusätzlichen 0x0000 zwischen den Halfwords [img]http://www.fb18.de/gfx/17.gif[/img]

du kannst das durchaus im assembler mit integern rechnen (aber trotzdem ein short array übergeben) wie das geht steht auch in der rfc ;) man muss der summe nur immer das eigene carry wieder hinzuaddieren und am ende aus den 32 bit noch 16 bit machen

du kannst das durchaus im assembler mit integern rechnen (aber trotzdem ein short array übergeben)

Wie meinst Du das genau? Natürlich rechnet man mit Integern, die Register sind nun einmal 32 Bit breit und nicht 16. Genau dafür gibt es doch diese schönen Lade- und Speicherbefehle, die Dir das entsprechend konvertieren.

nein mit je 2 shorts "nebeneinander"

(C) Parallel Summation

On machines that have word-sizes that are multiples of 16 bits,
it is possible to develop even more efficient implementations.
Because addition is associative, we do not have to sum the
integers in the order they appear in the message. Instead we
can add them in "parallel" by exploiting the larger word size.

To compute the checksum in parallel, simply do a 1's complement
addition of the message using the native word size of the
machine. For example, on a 32-bit machine we can add 4 bytes at
a time: [A,B,C,D]+'… When the sum has been computed, we "fold"
the long sum into 16 bits by adding the 16-bit segments. Each
16-bit addition may produce new end-around carries that must be
added.

der überlauf der untern 2 bytes läuft dann automatisch in die summe der oberen 2 bytes rein. und man muss dann nur noch immer das carry beim nächsten durchlauf dazuaddieren.
damit könnte man dann die anzahl der ladeoperation und additionen halbieren…

C-Programmierer wuerden so etwas nicht erwarten, wenn es falsch waere.

M*holding up the C Flag*o

Ich wollte damit auch nichts gegen C (-Programmierer) sagen
(mach ich ja selbst ab und zu gerne). Nur muss man sich in C
bei der Ziegerarithmetik halt oft nicht um die Größe
der Einträge kümmern, das macht ja der Compiler für einen. Und
deshalb könnte man auf die Idee kommen, das ginge in Assembler auch
irgendwie automagisch mit den Adressen.