Moin, kann mir mal einer erklären was diese Zeile macht?
1 | MOV R1, #(2*3 + 4 - 0xFF<<3) |
|
Forum: Compiler & IDEs Code unverständlichMoin, kann mir mal einer erklären was diese Zeile macht?
Kann da leider nicht mehr dazu sagen :/ Steht so im Skript... Versteh nur dass nicht was das bewirkt 0xFF<<3 Sepp schrieb: > Kann da leider nicht mehr dazu sagen :/ Steht so im Skript... Versteh > nur dass nicht was das bewirkt 0xFF<<3 https://en.wikipedia.org/wiki/Bitwise_operations_in_C#Left_shift_.3C.3C Sepp schrieb: > Kann da leider nicht mehr dazu sagen :/ Steht so im Skript... > Versteh nur dass nicht was das bewirkt 0xFF<<3 Muss man dir alles aus der Nase ziehen? Was für ein Skript? Worum geht es hier? Karl M. schrieb: > (0xFF << 3) ist das gleiche wie 0xFF *2³ = 255 *2³ = ? Ja. Für mich, der die Syntax des Assemblers deines geheimen Prozessors nur erraten kann, sieht die ganze Zeile irgendwie unsinnig aus. Sepp schrieb: > MOV R1, #(2*3 + 4 - 0xFF<<3) Sieht nach einem Move-Befehl aus. Damit schreibt man etwas von hier nach da. Genau genommen nach da von hier. So, wie man es von links nach rechts liest. "Da", also Destination ist R1. "Hier", Source, ist der Zahlenwert in der Klammer, der von dem werten Assembler ausgerechnet werden muß. Dieser wird dann Immidiate(#) nach R1 geschrieben. 2*3+4-2040 = -2030 = FFFFF812 In R1 steht dann FFFFF812. Sofern es da reinpasst. Was nicht passt, wird vorne abgeschnitten. Sepp schrieb: > nur dass nicht was das bewirkt 0xFF<<3 Das bewirkt, daß 0xFF um 3 Byte nach rechts geschoben wird. Was gleichbedeutend mit einer Multiplikation mit 8 ist. :
Bearbeitet durch User
Thomas E. schrieb: > Sepp schrieb: >> nur dass nicht was das bewirkt 0xFF<<3 > > Das bewirkt, daß 0xFF um 3 Byte nach rechts geschoben wird. Das solltest du dir nochmal genau überlegen... Rolf M. schrieb: > Für mich, der die Syntax des Assemblers deines geheimen Prozessors > nur erraten kann, sieht die ganze Zeile irgendwie unsinnig aus. Er selbst kann auch nur raten, wie man hier lesen kann: Sepp schrieb: > Kann da leider nicht mehr dazu sagen :/ Steht so im Skript... Versteh > nur dass nicht was das bewirkt 0xFF<<3 Es ist wahrscheinlich scheißegal, was das für ein Prozessor ist, weil man von ihm nr wissen will, was letzten Endes in dem Register "M1" steht, nachdem diese blödsinnige, "C"-artige Schieberei und die weitere Rechnerei gelaufen ist. Paul Rolf M. schrieb: > Das solltest du dir nochmal genau überlegen... F... Ich meinte natürlich das andere Rechts. :
Bearbeitet durch User
Rolf M. schrieb: > und das andere Byte, nehme ich an. Meine Güte. Ja, das 1-Bit Byte. Aber der Punkt am Ende dieses Satzes ist richtig. Immerhin. Und richtig ausgerechnet habe ich das auch. :
Bearbeitet durch User
der assemblerbefehl schreibt das Rrgebnis des eingeklammerten Terms in das register r1 und so geht es
Namaste :
Bearbeitet durch User
Thomas E. schrieb: > Ich meinte natürlich das andere Rechts. Rolf M. schrieb: > und das andere Byte, nehme ich an. ;- Lol Winfried J. schrieb: > 2*3+4-0xff<<3 = 0d10 - 0b 00000000 00000111 11111111 11111000 Aber 0xff ist doch 0b 11111111! <<3 verschiebt um 3 Bit nach links was einer Multiplikation mit 8 entspricht. das wurd schon ganz am Anfang erklärt. Namaste Worauf Slippin damit hinweisen wollte ist, dass du 0xffff<<3 gemacht hast, nicht 0xff<<3. Als kleine Hilfe will ich doch mal darauf hinweisen, dass es beim Rechnen nicht selten Vorrangregeln gibt, sowas wie Punkt-vor-Strich. Nicht jedem sind alle diese Regeln geläufig, erst recht nicht die irgendwelcher Assembler. Und üblicherweise spielt eine optische Gruppierung über Leerzeichen für Menschen eine grössere Rolle als für Maschinen. Paul B. schrieb: > Es ist wahrscheinlich scheißegal, was das für ein Prozessor ist, So ist es. Interessanter wäre die Dokumentation des Assembler selbst, also ob man von den Vorrangregeln von C ausgehen darf. Wobei ich auch einen Assembler kenne, dem das völlig schnurz ist und der konsequent von links nach rechts rechnet. Stefan E. schrieb: > Worauf Slippin damit hinweisen wollte ist, dass du 0xffff<<3 gemacht > hast, nicht 0xff<<3. ei was ein miFFFFt! Man sollte nach einem stressigen Tag halt nicht mit gemischten Zahlensystemen rechnen wollen. Das ist eh so eine Unsitte und wie AK schon schrieb eine Codezeile in der unklare Abarbeitungsregeln herrschen ist auch nicht das Wahre, vor allem ist ja da noch die Frage ist schieben gleichrangig mit multiplizieren. Wenn schon alles in eine Zeile dann sollte man mit Klammern dort für Klarheit sorgen. ... Zumal klassischer ASM gar keine C-Terme zulässt und dort schon über die Syntax mault. Das scheint mir auch so eine Unsitte, Progammiersprache als lebende eierlegende Wollmilchsau ohne klare Regeln und mit einer Vielzahl an Lehen aus anderen Sprachdialekten, was bei Swift zu ständigen Syntaxänderungen aus Bequemlichkeit führt. Basic hatte für seine Möglichkeit für unklare Programmstrukturen Spaghetticode und Nestys zu recht einen Schlechten Ruf. "moderne Sprachen" schaffen das schon in der Syntax durch beliebigkeit der selben. Frei nach dem Motto: Schreib doch was du willst in die Source, ich kompiliere es wie ich will. wen du Glück hast korreliert das Compilat mit deiner Erwartung an das selbe. Namaste Und nur mal so nebenbei: In C binden *+- stärker als <<, dort wäre es also tatsächlich gleichbedeutend mit: (2*3 + 4 - 0xFF)<<3 Winfried J. schrieb: > Frei nach dem Motto: > > Schreib doch was du willst in die Source, ich kompiliere es wie ich > will. > wen du Glück hast Ich glaube nicht dass der verwendete Assembler ohne Handbuch daherkommt in dem das alles ganz haarklein definiert ist. Insofern ist Dein wirres Geschwafel nicht ganz nachvollziehbar. Sepp schrieb: > Moin, > > kann mir mal einer erklären was diese Zeile macht? > >
Hängt davon ab, wer oder was diese Zeile verarbeitet. Johann L. schrieb: > Hängt davon ab, wer oder was diese Zeile verarbeitet. (4*3) + 4 - (0xff<<3) (((4*3) + 4) - 0xff) << 3 Und es fehlen die Varianten mit Überläufen und impliziten Typkonvertierungen. Es ist auch nicht gesagt, ob << ein arithmetisches oder binäres Shift ist, bzw. ob da unterschieden werden soll resp. unterschieden werden kann. 's braucht mehr inpuuht Boris O. schrieb: > Es ist auch nicht gesagt, ob << ein arithmetisches > oder binäres Shift ist, Worin besteht der Unterschied? A. K. schrieb: > Boris O. schrieb: >> Es ist auch nicht gesagt, ob << ein arithmetisches >> oder binäres Shift ist, > > Worin besteht der Unterschied? Ist das bei Links-Shift nicht völlig egal / gleich? A. K. schrieb: > Boris O. schrieb: >> Es ist auch nicht gesagt, ob << ein arithmetisches >> oder binäres Shift ist, > > Worin besteht der Unterschied? eventuell mit oder ohne carry? und Registergtröße ist natürlich im weiteren auch nicht unwichtig zu kennen. Namaste :
Bearbeitet durch User
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.
|
|