Udo K. schrieb: > Ich habe ja letztens seit langer Zeit wieder Nachhilfe in Mathe gegeben. > Ich habe ganz schön gestaunt, wie ich gesehen habe, dass bei > eine Mathe Schularbeit heute gar nicht mehr gerechnet wird! > Da gab es nur mehr Verständnisfragen - das Rechnen übernimmt eh > das Computerprogram. Einfach Irrsinn! So werden Massen an Klugscheißern generiert, die "alles verstehen" aber nix gebacken kriegen und für einfachste Rechnungen einen Computer oder Handy brauchen. Überschlagsrechnung? Abschätzung? Größenordnung? Wenn ich was WIRKLICH verstanden habe, dann kann ich es auch umsetzen. Denn viele dieser "Verständnisfragen" sind Dünnbrettbohrerei und oft als Multiple Choice angelegt. Da reicht raten, um im Mittel zu bestehen!
Joerg W. schrieb: >> Und wozu? Weil man zu faul oder zu doof ist auf eine Hochsprache zu >> wechseln? > > Nein. Weil man's kann. Und man bei Anwendungen wie z.B. Emulatoren > erhebliche Geschwindigkeitszuwächse gegenüber C-Compilaten erreicht. Dass C deutlich besser das geschriebene in Assembler übersetzt hatte Yalu schon vor 4 Jahren bewiesen: Beitrag "Re: C versus Assembler->Performance"
Udo K. schrieb: > Das stimmt schon. Aber in dieser Schularbeit gab es auch keinen > Rechenweg wie ihn aus meiner Schulzeit kenne (also länger als eine > Zeile). > Da fand ich auf dem Papier grad mal 1-2 einfache Gleichungen. > > Das war mehr eine Art von Multiple Choice Test mit hinterlistig > gestellten > Fragen zum ankreuzen. Genau dieser Schwachsinn hat rein gar nichts mit mathematischem Wissen und dessen Abfrage zu tun. Das ist importierter Irrsinn aus Amiland! > Der Taschenrechner ist inzwischen durch einen symbolischen Rechner > (wie Wolfram Mathematika) auf dem Laptop ersetzt worden. Völliger Käse. Denn damit lernt und trainiert niemand die Mathematik, weder das Verständnis der Zusammenhänge noch das Kopfrechnen etc. Verblödung mit Ansage! Das Leben ist KEIN Multiple Choice Test!
Cyblord -. schrieb: > Da habe ich in der Tat so meine Schwierigkeiten. Wundert mich nicht wenn Du Asm nach eigener Aussage für AVR nie verwendest. > Möglich ist natürlich alles in ASM. Aber irgendwann macht es keinen Sinn > mehr Darauf können wir uns verständigen. Allerdings nicht aus den angeführten Gründen, sondern weil Asm in der Implementierung neuer, noch nicht in einer vorhandenen Codebasis erarbeiteten Dinge ein Stück weit aufwändiger ist. Das ist aber alles auch extrem erfahrungsabhängig. > Und wozu? Weil man zu faul oder zu doof ist auf eine Hochsprache zu > wechseln? Weil Asm, dessen Freiheiten und Gestaltungsspielraum Spaß machen? Ohne erst IT studieren zu müssen? Und außerdem: Beim System-Design, beim Entwurf von Inter-Device Kommunikation und Netzen, Regelungen und Steuerungen steht sehr oft die Lösungsweise der Aufgabe, der Algorithmus, das Verfahren im Vordergrund und gerade nicht Details der Implementierung, in welcher Sprache auch immer. Das ist durchaus kreative, intellektuelle Anforderung genug.
> Dass C deutlich besser das geschriebene in Assembler übersetzt hatte > Yalu schon vor 4 Jahren bewiesen: > Beitrag "Re: C versus Assembler->Performance" Ja wenn das so ist, dass das schon BEWIESEN ist, dann habe ich wohl die letzten Jahre auf dem falschen Planeten gelebt: PDP11-Emulator: ca. 2x schneller (PowerPC, nur teilweise ASM) Gigatron-Emulator: über 4x schneller (STM32) Das soll nicht im Gegenzug bedeuten, dass Compiler zu doof sind, effizienten Code zu generieren. In den beiden von mir genannten Beispielen habe ich halt den Vorteil, dass ich das ganze überblicken und die Struktur des Programms an die Aufgabe anpassen kann. Ein Compiler wird wahrscheinlich nicht "auf die Idee kommen", alle relevanten Variablen zusammenzuzählen und daraus schlussfolgern, dass man alles in Registern halten kann. Zumindest nicht bei komplexeren Programmen. Wenn ich weiß, dass sich z.B. in einem Funktionspointer nur bestimmte Bits ändern können, dann kann ich z.B. auf PowerPC mit rlwinm nur diese Bits austauschen und muss nicht jedes mal den Pointer komplett neu berechnen. Und sorge nebenbei gleich mit dafür, dass der I-Cache möglichst effizient arbeiten kann (aligning). Jörg
Falk B. schrieb: > Völliger Käse. Denn damit lernt und trainiert niemand die Mathematik, Das ist wahr. Auch wenn man es 100% verstanden hat muß man es regelrecht trainieren um schneller und sicherer im Umgang damit zu werden. Als jemand der zur natürlichen Faulheit neigt habe ich das selbst deutlich erlebt: "Üben? Zeitverschwendung! Ich hab doch komplett verstanden wie es geht! Formel auswendig lernen? Wozu, ich weiß doch wie man sie herleitet!" Natürlich konnte ich es fehlerfrei durchführen, nur habe ich jedes mal dreimal so lange gebraucht wie manch anderer. Oft hats trotzdem noch gereicht für die volle Punktzahl aber manchmal ist mir dann einfach die Zeit ausgegangen, sehr ärgerlich. Der Effekt von Training (oder dem Fehlen desselben) war sehr deutlich.
:
Bearbeitet durch User
Joerg W. schrieb: > Gigatron-Emulator: über 4x schneller (STM32) Hast du ein Code-Snippet bei dem sich das unabhängig vergleichen lässt? D.h. wo der erzeugte Assembler-Code deutlich schlechter ist? Davon ab ist ein Emulator ein ziemlicher Sonderfall. Von da auf allgemeine Anwendungen zu schließen ist schon gewagt. Auch beim Emulator kann man die nicht-geschwindigkeits-relevanten Teile problemlos in C(++) schreiben.
Ich habe auch nicht geschrieben, dass das generell so ist. Sondern nur darstellen wollen, dass: > Dass C deutlich besser das geschriebene in Assembler übersetzt hatte > Yalu schon vor 4 Jahren bewiesen: > Beitrag "Re: C versus Assembler->Performance" eben nicht allgemeingültig ist. > Hast du ein Code-Snippet bei dem sich das unabhängig vergleichen lässt? Nein. Und zwar deswegen, weil das Programm völlig anders aufgebaut ist. Es gibt keine zentrale Schleife, sonder eine Art "Code-Inseln", die bei Vielfachen von 256 beginnen. Jede dieser Inseln steht für einen Befehl/Opcode. Und am Ende jeder dieser Inseln wird aus dem HIGH-Byte des nächsten Opcodes und der Basisadresse eine neue Sprungadresse berechnen und dorthin gesprungen. Das ganze geht ohne Stack und auch R14 wird als "normales" Register benutzt. Es lassen sich sowohl der ASM Quellcode (Projekt) als auch der übersetzbare C-Quellcode (Projekt-Thread) herunterladen. Wenn man genauso "denkt" wie der Compiler, dann wird der Compiler wohl in den meisten Fällen besseren Code erzeugen. Aber man kann ein Programm auch in manchen Fällen anders strukturieren als Eingabe->Berechnung->Ausgabe. Da ich das Ganze nur als Hobby betreibe, muss ich mich nicht um Wartbarkeit oder Portierbarkeit scheren, sondern es macht Spaß, noch das eine oder andere Prozent Geschwindigkeit aus dem Controller rauszukitzeln. Und für Portierbarkeit habe ich für C inzwischen meinen eigenen HAL (auch teilweise in ASM) geschrieben. Bzw. schreibe noch daran, weil sich so etwas beliebig erweitern lässt... Jörg
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.