asm stirbt aus

[knivil]

Assembler eine sehr viel bessere Didaktik

Lol, vor allem bei CISC-Architekturen.

Zukunft dreht sich deutlich sichtbar um Parallelisierung

Naja, ich habe vor 12 Jahren meine erste Anwendung mit pthreads geschrieben. GPGPU ist so alt wie Shader selbst (fast).

Sonst hat man nur eine relativ abstrakte Vorstellung davon, wie Computer und Programme wirklich funktionieren.

Das kann man aber noch weiter treiben. Wer nie einen FPGA ..., nie einen Transistor auf dem Steckbrett, ... und natuerlich die Zunkunft und wieviel einem das bringt. Ich freue mich persoenlich auf eine zukuenftige Kopplung von Mikroprozessoren und FPGA. Xilinx und Altera haben da was mit Arm am basteln.

[Mechanics]

knivil schrieb:

Das kann man aber noch weiter treiben. Wer nie einen FPGA ..., nie einen Transistor auf dem Steckbrett, ...

Kann man, muss man aber nicht Ich habe im Studium einiges über Prozessorarchitekturen und die Physik dahinter gelernt und fand das auf jeden Fall interessant. Aber so wichtig wie Assembler finde ich das nicht. Wenn man kein Assembler kann, versteht man einfach nicht, wie C++ usw. wirklich funktioniert. Das sind einfach die Basics, die dazugehören.

[nachtfeuer]

knivil schrieb:

Assembler eine sehr viel bessere Didaktik

Lol, vor allem bei CISC-Architekturen.

Dieses Überlegung finde ich vor dem Hintergrund umfangreicher Api-Funktionsbibliotheken etwas gewagt, ganz davon abgesehen, dass viele Befehle sowieso nur alte Bekannte sind, oder einander wohltuend ähnlich oder manche exotischen Befehle sowieso nur für spezielle Bereiche interessant.

Aber Funktionsbibliotheken sind toll, und mal abgesehen von der gas-Sythax ist es schön in Linux Assembler und den klassichen C-Funktionen zu programmieren. Auf der Fasm-Seite gibts auch eine kleine Systemlib für sowat z.B.
http://flatassembler.net/examples/flibc.zip

[knivil]

Naja, wahrascheinlich hast du noch kein Arm oder eine andere RISC-Architektur programmiert. Allein die Tatsache, dass Befehle 3 Operanden, also Source- und Destinationregister besitzen, fuehlt sich einfach besser an. Push, pop, Lea und gefuehlte zwanzigtausend Addressierungsarten, bedingte Ausfuehrung von Instruktionen (keine jmps) ... oder oder oder ...

Wieviel Instruktionen und Register benoetigt ein einfaches minmax (ohne Laden der Werte in Register), also:

if (i > j)
{
  temp = i;
  i = j;
  j = temp;
}

Bei Arm sind es 2 Instruktionen und 2 Register. Wo braucht man das? Na Beispielsweise Bildverarbeitung und Medianberechnung bei 3x3. Toll das wir ausreichend Register zur Verfuegung haben: Laden, minimales Sortiernetzwerk mit 25 Vergleichen => 50 Takte, Median auswaehlen, fertig. Gibt es auch mit 64 oder 128 Register. Welch ein Glueck, dass sich fuer x86 durch die ganzen Erweiterungen mehr Register und Multimediabefehle wie SSE, bessere Sprungvorhersage etc. hinzugekommen sind. Fairerweise soll gesagt sein, dass x86 mittlerweile einige Befehle auch bedingt ausfuehren kann, bei Arm ist es Standard bei fast jedem Befehl.

[Burkhi]

Assembler wirst du auch bei sehr kleinen Mikrocontrollern immer benötigen, als Beispiel sei der ATtiny2313 von AVR genannt. Da hast du sehr wenig RAM (128 Bytes) und Programmspeicher (2KB), da könnte man selbst C Programme kaum drauf laufen lassen, weil da kaum eine Lib in den Programmspeicher passt.

Von Java & Co wollen wir da gar nicht erst reden.

Von daher wird ASM niemals aussterben.

[nachtfeuer]

knivil schrieb:

...

Zum Teil schon wieder so gewagt
Würde mich jetzt aber nicht so an den Begriffe Risc und Cisc orientieren, da ältere oder kleinere Mikros ja auch "Risc" wären. Und die 68000er waren eigentlich auch viel besser, als die Intelteile, nur leider nicht so schön kompatibel. Hätte die Dinger sich vernünftig weiterentwickelt, hätte heutzutage wohl kaum einer einen Intel-Prozessortyp-PC.

Risc müsste man fairerweise gleich denken als (RISC+Hochsprachencompiler), was dann wieder wenig mit Assembler zu tun hätte, sondern eher mit der Beschränktheit von Compilern. Aber die vielen Möglichkeiten beim Intel kommen mir manchmal ziemlich überflüssig vor, wozu soll das gut sein, x auf 5 oder mehr unterschiedliche Arten hinzubekommen?

Und jetzt mal unabhängig von Risc und Cisc und Didaktik: Weißt du ein gutes Entwicklungskit für die neueren ARMS?
( http://www.heise.de/ct/artikel/Prozessorgefluester-1370336.html macht ja Lust auf mehr )

[Scheppertreiber]

Burkhi schrieb:

Assembler wirst du auch bei sehr kleinen Mikrocontrollern immer benötigen, als Beispiel sei der ATtiny2313 von AVR genannt. Da hast du sehr wenig RAM (128 Bytes) und Programmspeicher (2KB), da könnte man selbst C Programme kaum drauf laufen lassen, weil da kaum eine Lib in den Programmspeicher passt.

Von Java & Co wollen wir da gar nicht erst reden.

Von daher wird ASM niemals aussterben.

Den ATTiny2313 habe ich gerade in der Mangel. Das geht mit C richtig gut

[knivil]

@nachtfeuer: fuer den Einstieg wuerde ich nichts kostenintensives nehmen. Privat habe ich nur das von http://mbed.org/ . Daneben gibt es noch BeagleBoard und sein Nachfolger Pandaboard. Aber Entwicklungskits mit viel Support etc. gibt es da nicht.

Das geht mit C richtig gut

Ja, nutze ich neben C++ auch meistens. Aber ich schau mir bei einigen Funktionen den ASM-Code an und doktere daran rum, bis der ASM-Code passt. Andernfalls muss ich selbst einschreiten.

[Gast]

Das reine in asm programmieren stirbt immer mehr aus. Aber in intrinsics (oder halt inline assembler) lebt es noch ewig weiter.

Habe letztens versucht einem Compiler beizubringen, anstatt der Instruktion MUL eine Instruktion MULS (Multiplikation mit Sättigung bei Überlauf) zu benutzen. Ohne (inline/intrinsics) asm keine Chance.

[mfq]

nachtfeuer schrieb:

Und jetzt mal unabhängig von Risc und Cisc und Didaktik: Weißt du ein gutes Entwicklungskit für die neueren ARMS?

Wie Knivil schon meinte, zum Anfang lieber was kleineres. Ziemlich interessant sieht das Maple-Board aus. Hat einen Cortex-M3 in Form des STM32 F103RB von STMicro drauf. Das tolle daran ist, dass das Board dort wo es geht, mit den Arduinos kompatibel gehalten wurde. Die komplette Toolchain ist in Form von Opensource-Software verfügbar und es gibt ähnlich Arduino eine Library, die einiges abstrahiert und einen in einem recht bequemen C++-Dialekt programmieren lässt. Nötig ist die Nutzung davon aber natürlich nicht. Theoretisch sollte man dort alles, was der GCC für ARM-Targets bauen kann, auch zum Laufen bekommen. Das ganze ist auch außerhalb des Datenblatts recht brauchbar dokumentiert. Kostet 40 €.

Gibt jetzt anscheinend auch eine etwas teurere Variante mit 1 MiB onboard SRAM. Dafür wurde halt die Kompatibilität mit dem Arduino-Layout aufgegeben. Sieht ebenso interessant aus, dürfte aber noch schwer verfügbar sein. Das normale Maple bekommt man halt an jeder Ecke.

Ansonsten gibts eben noch Beagle- und Pandaboard, die aber in einer völlig anderen Liga spielen.

http://leaflabs.com/devices/maple/

In Deutschland kaufen kann man die Maples z.B. bei Watterott, die btw auch gerade PandaBoards auf Lager haben.