Code unverständlich

[Sepp (Gast)]

Moin,

kann mir mal einer erklären was diese Zeile macht?

MOV R1, #(2*3 + 4 - 0xFF<<3)

[hehe (Gast)]

sieht nach ARM aus, paar mehr infos wäre nett...

[Sepp (Gast)]

Kann da leider nicht mehr dazu sagen :/ Steht so im Skript... Versteh 
nur dass nicht was das bewirkt 0xFF<<3

[Heino H. (Gast)]

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

[Melanie (Gast)]

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. (Gast)]

Hallo Sepp,

(0xFF << 3) ist das gleiche wie 0xFF *2³ = 255 *2³ = ?

[Rolf M. (rmagnus)]

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.

[Thomas E. (thomase)]

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.

[Rolf M. (rmagnus)]

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...

[Paul B. (paul_baumann)]

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

[Thomas E. (thomase)]

Rolf M. schrieb:
> Das solltest du dir nochmal genau überlegen...

F...

Ich meinte natürlich das andere Rechts.

[Rolf M. (rmagnus)]

Thomas E. schrieb:
> Ich meinte natürlich das andere Rechts.

und das andere Byte, nehme ich an. ;-)

[Thomas E. (thomase)]

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.

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

der assemblerbefehl schreibt das Rrgebnis des eingeklammerten Terms in 
das register r1


und so geht es

2*3+4-0xff<<3 = 0d10 - 0b 00000000 00000111 11111111 11111000

 0b (1)00000000 00000000 00000000 00001010
-0b    00000000 00000111 11111111 11111000
-------------------------------------------
 0b    11111111 11111111 11111000 00011100 = 0xFF FF F8 1C

Namaste

[René H. (Gast)]

Thomas E. schrieb:
> Ich meinte natürlich das andere Rechts.

Rolf M. schrieb:
> und das andere Byte, nehme ich an. ;-

Lol

[Slippin J. (gustavo_f)]

Winfried J. schrieb:
> 2*3+4-0xff<<3 = 0d10 - 0b 00000000 00000111 11111111 11111000

Aber 0xff ist doch 0b 11111111!

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

<<3 verschiebt um 3 Bit nach links was einer Multiplikation mit 8 
entspricht. das wurd schon ganz am Anfang erklärt.

Namaste

[Stefan E. (sternst)]

Worauf Slippin damit hinweisen wollte ist, dass du 0xffff<<3 gemacht 
hast, nicht 0xff<<3.

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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.

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

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

[Stefan E. (sternst)]

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

[Bernd K. (prof7bit)]

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.

[Johann L. (gjlayde)]

Sepp schrieb:
> Moin,
>
> kann mir mal einer erklären was diese Zeile macht?
>
>

MOV R1, #(2*3 + 4 - 0xFF<<3)

Hängt davon ab, wer oder was diese Zeile verarbeitet.

[Boris O. (bohnsorg)]

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

[(prx) A. K. (prx)]

Boris O. schrieb:
> Es ist auch nicht gesagt, ob << ein arithmetisches
> oder binäres Shift ist,

Worin besteht der Unterschied?

[Bernhard M. (boregard)]

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?

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

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