Hallo Leute, Ich bins mal wieder, und bei dem Namen Bastler werden sicherlich schon einige schreiend davonrennen (Die die mich kennen) aber ich will jetzt doch mal wissen wo eigentlich die Leute abgeblieben sind, die damals bevor es compiler gab µC´s und den ganzen Kram programmiert haben. Ich interessiere mich doch sehr fürs Reverse Engineering besonders für die RISC´s (Hauptsächlich ARM)und würds dann doch gerne weitergehend lernen. Nun aber die Farge, ich kann mit dem Disassemblierten Zeug von IDA viel besser umegehn als mit dem was der Hex Rays decompiler so macht, warum auch immer. Ich bin noch dabei zu lernen, wie man den Krempel versteht, aber so arg schwer wie einige hier sagten scheint das nicht zu sein, sonst wäre ich Depp nicht schon so weit gekommen. Nun die Frage: Gibt es hier noch Leute die mit Assembler aufgewachsen sind, und mir ein bisschen tiefergehend erklären können, wie man disassemblierten ARM Maschinencode versteht, und am besten patcht? (Ich hab ein Paar Dinge mit einem µC vor, die mit Compiler nicht gehen auf dem µC da der Code zu ineffizient ist, daher bleibt nur: Schnellerer µC -> geht nicht, oder effizienterer Code.) Ich hoffe dass sich hier ein Paar von den alten Hasen finden lassen die vielleicht bereit sind ein bisschen was von ihrem Wissen weiterzugeben. Gruß Bastler
:
Bastler schrieb: > die mit Compiler nicht gehen auf > dem µC da der Code zu ineffizient ist Da bin ich gespannt, was das für Code ist und was man in Assembler besser hinbekommt.
Bastler schrieb: > Gibt es hier noch Leute die mit Assembler aufgewachsen sind, Ja Bastler schrieb: > und mir ein bisschen tiefergehend erklären können, wie man > disassemblierten ARM Maschinencode versteht, Nein, denn ich bin mit 8086 und 68000 Assemblercode aufgewachsen und habe seit 30 Jahren nicht mehr wirklich Assembler benutzt. Ausserdem kann man "das Verstehen" von disassembliertem Code eines (wahrscheinlich) C oder C++ Compilers nicht in einem Forumsbeitrag erklären, das muss man üben und zwar oft und lange. Bastler schrieb: > Ich > hab ein Paar Dinge mit einem µC vor, die mit Compiler nicht gehen auf > dem µC da der Code zu ineffizient ist, Die Mär dass man auf einem komplexen Controller "von Hand" schnelleren Code schreibt als mit einem C oder C++ Compiler hält sich lange, ist aber zu 90% falsch. In der Regel ist nicht Assembler oder Hochsprache das Problem, sondern ineffizente Algorithmen.
:
Bearbeitet durch User
Programmierer schrieb: > Bastler schrieb: >> die mit Compiler nicht gehen auf >> dem µC da der Code zu ineffizient ist > > Da bin ich gespannt, was das für Code ist und was man in Assembler > besser hinbekommt. Das ist wie immer bloß sein vom LKW gefallener E-Scooter, für dessen Motorcontroller er den Quellcode halt nicht hat.
Na dann sperr deinen Compiler in die Schublade und lerne erstmal einen µC komplett nur in Assembler zu programmieren. Dir scheint Tiparbeit ja zu liegen, da ist's dann auch wurst, dass das RISCs sind. :) Wundere dich aber dann nich, wenn in 1-2 Wochen deine Gyri in Rechtewinkel liegen. ;) Und später dann nich übersehen, das es sowas wie "InlineAssembler" gibt!
Nop schrieb: > Das ist wie immer bloß sein vom LKW gefallener E-Scooter, für dessen > Motorcontroller er den Quellcode halt nicht hat. Oh nein, wie konnte ich es vergessen. Na, ob der Motor schneller läuft wenn der Prozessor "dank" Assembler schneller wird?
Im C64 Forum rennen noch genug rum, die Kunstwerke mit Assembler programmieren.
Cihan S. schrieb: > Im C64 Forum rennen noch genug rum, die Kunstwerke mit Assembler > programmieren. Auf 6502 - nicht auf ARM...
Wenn in Stellenausschreibungen steht: ARM-Kenntnisse C-Programmierung Assembler-Kenntnisse Dann mach ich mir Sorgen um die Firma. Kann schon mal helfen ein Problem einzukreisen wenn man Assembler lesen kann. Aber schreiben? Nöö, die Zeiten sind lang vorbei. Ausser man verlangt von mir, dass ich Compiler bau.
Das ganze Thema ist (sinnloserweise) regelmässig für einen längeren trööt gut. Führt genauso regelmässig zu exakt nichts.
Bastler schrieb: > Gibt es hier noch Leute die mit Assembler aufgewachsen > sind, und mir ein bisschen tiefergehend erklären können, wie man > disassemblierten ARM Maschinencode versteht ... Zwischen "aufwachsen mit Assembler" und ARM liegt deutlich mehr als ein viertel Jahrhundert.
Hallo, Assemblerprogrammierung ist vor langer Zeit verwendet worden, weil die CPUs so wenig sinnvoll gebaut waren. Ich habe das auf dem 8048 lernen müssen, und im Vergleich zu manchem C-Code war mein Code auch schneller. Damals musste man um die Unzulänglichkeiten der CPUs drumherumprogrammieren. Beim Z80 war das dann more 'straight' und beim 6809 dann super. Heute sind Kenntnisse in Assembler noch für PICs erforderlich, da deren Compiler einen schlechten Ruf haben. Für den Arm brauche ich Assembler nur noch, um die Qualität des Codes zu bestimmen. Mehr nicht. Robert
Programmierer schrieb: > Da bin ich gespannt, was das für Code ist und was man in Assembler > besser hinbekommt. Jeglichen, aber wer tut sich das schon an. Udo S. schrieb: > Die Mär dass man auf einem komplexen Controller "von Hand" schnelleren > Code schreibt als mit einem C oder C++ Compiler hält sich lange, ist > aber zu 90% falsch Unsinn. Du hast dir wohl noch nie den Assembler-Output von Compilern angesehen. Der ist so grausam uneffektiv, da rollen sich einem die Fussnägel hoch. Keinerlei globale Optimierung erkennbar. Und auch lokal extrem blindfischig. Insbesondere Gnu. Der übliche Code zeigt meist auf 1 Blick, dass es in Assembler doppelt so schnell ginge.Manchmal mit Spezialinstruktionen die der Compiler nicht vetwendet eeil ihre Rahmenbedingungen so schwer in Formeln zu fassen sind auch 10-fach. Ich musste neulich eine Interrupt-Routine auf einem AVR in Assembler umschreiben, damit der Prozessor statt mit 8MHz mit 1MHz laufen konnte, was statt 65uA ittlerer Stromaufnahme zu 35uA Stromaufnahme der Schaltung führte. Dazu musste man aber 5 Register reservieren und vorbelegen, die vom restlichen Code (der egal wie langsam sein durfte) nicht verwendet werden und daher nicht gepusht werden müssen. Dazu sind Compiler zu doof. Wolfgang schrieb: > Zwischen "aufwachsen mit Assembler" und ARM liegt deutlich mehr als ein > viertel Jahrhundert. Denk ich auch. ARM werden kaum in Assembler programmiert werden. Bis auf kurze Stücke zur Initialisierung. Lieber kauft der Enwickler einen Core mit höherer Taktfrequenz.
MaWin schrieb: > ARM werden kaum in Assembler programmiert werden Quatsch: ARM-ASM-Tutorial MaWin schrieb: > Der übliche Code zeigt meist auf 1 Blick, dass es in Assembler doppelt > so schnell ginge. Dann zeig doch mal ein paar übliche Beispiele, gern für ARM.
MaWin schrieb: > Lieber kauft der Enwickler einen Core > mit höherer Taktfrequenz. Kauft? Wohl nicht. Er sagt seinem Cheffe, daß es nur mit einem dickeren µC geht - und der muß sich dann mit den Kostenplanern raufen, um das irgendwie in der Kalkulation unterzubringen. So herum. W.S.
Bastler schrieb: > ich will jetzt > doch mal wissen wo eigentlich die Leute abgeblieben sind, die damals > bevor es compiler gab µC´s und den ganzen Kram programmiert haben. Blöde Frage. Die sind gestorben oder im Ruhestand. > Gibt es hier noch Leute die mit Assembler aufgewachsen sind Frage mal den c-hater, der tut zumindest so als ob.
Bastler schrieb: > (Ich > hab ein Paar Dinge mit einem µC vor, die mit Compiler nicht gehen auf > dem µC da der Code zu ineffizient ist, daher bleibt nur: Schnellerer µC > -> geht nicht, oder effizienterer Code.) Trollalarm am Anschlag. Bastler schrieb: > ich will jetzt > doch mal wissen wo eigentlich die Leute abgeblieben sind, die damals > bevor es compiler gab µC´s und den ganzen Kram programmiert haben. Die haben mit ihren Assemblerkenntnissen einen C-Compiler geschrieben und programmieren jetzt in C. Einige programmieren gerade in C einen Compiler für einen noch höheren Abstraktionsgrad.
Ich denke, er will immer noch seinen (vermutlich geklauten) Elektro-Roller tunen.
MaWin schrieb: > Der übliche Code zeigt meist auf 1 Blick, dass es in Assembler doppelt > so schnell ginge Na und? Doppelt so schnell ist Pilelpalle. In der Zeit, wo jemand den Code optimiert, kommt der nächste Prozessor auf den Markt der diese Aufgabe für 20 Cent Aufpreis überflüssig macht.
MaWin schrieb: > Der übliche Code zeigt meist auf 1 Blick, dass es in Assembler doppelt > so schnell ginge.Manchmal mit Spezialinstruktionen die der Compiler > nicht vetwendet eeil ihre Rahmenbedingungen so schwer in Formeln zu > fassen sind auch 10-fach. Klar, der vor 20 Jahren hängen Gebliebene muss natürlich auch hier sein profundes Halbwissen absondern - geht ja gar nicht anders. Hauptsache Offtopic in jeden Thread reintröten; vollkommen egal, wie weit ab das vom Thema oder einer etwaigen Hilfe für den TO ist. MaWin schrieb: > Dazu musste man aber 5 Register reservieren und > vorbelegen, die vom restlichen Code (der egal wie langsam sein durfte) > nicht verwendet werden und daher nicht gepusht werden müssen. Dazu sind > Compiler zu doof. Herzlichen Glückwunsch - Du hast gerade öffentlich demonstriert, dass du dein Werkzeug (Compiler) nicht beherrschst. Nicht mehr und nicht weniger.
R. F. schrieb: > Heute sind Kenntnisse in Assembler noch für PICs erforderlich, da deren > Compiler einen schlechten Ruf haben. Quatsch... Programmiere du mal zB. einen 10F220 in C, das mehr kann als nur ne /huhu LED/ zu bedienen! Aberglaube, statt Wissen.... Ich glaub ich leb im Mittelalter. ;D PS: Nich vergessen hier gests um "Profis", nich um uns Bastlerhonks!
Teo D. schrieb: > PS: Nich vergessen hier gests um "Profis", nich um uns Bastlerhonks! Der TO will offensichtlich irgendwas Häcken.
W.S. schrieb: > Er sagt seinem Cheffe, daß es nur mit einem dickeren µC geht > - und der muß sich dann mit den Kostenplanern raufen, um das irgendwie > in der Kalkulation unterzubringen. Ist immer noch erheblich günstiger, als Assembler-Spezialisten zu bezahlen. Wenn das nicht so wäre, wäre die gesamte IT Branche bescheuert, bei dem Kurs den sie seit 40 Jahren fährt.
ACDC schrieb: > Der TO will offensichtlich irgendwas Häcken. Beitrag "Firmware reverse Engineering Kosten" leo
MaWin schrieb: > Du hast dir wohl noch nie den Assembler-Output von Compilern angesehen. Ich schon oft. > Der ist so grausam uneffektiv, da rollen sich einem die Fussnägel hoch. So geht es mir beispielsweise, wenn ich Code sehe, der für 8 Bit PICs übersetzt wird. Nicht aber bei Maschinen, deren Architektur für Compiler gestrickt ist.
Horst G. schrieb: > Vor 20 Jahren Bis weit in die 80er waren C Compiler recht einfach gestrickte Werkzeuge. Das änderte sich dann aber schnell. Die Maschinen wurden gross genug, um auch komplexe Compiler tragen zu können und die Entwicklung nahm entsprechend Fahrt auf. Die Werkzeuge für Mikrocontroller müssen das allerdings nicht in gleichem Rahmen wiederspiegeln.
:
Bearbeitet durch User
Bastler schrieb: > Ich hoffe dass sich hier ein Paar von den alten Hasen finden lassen die > vielleicht bereit sind ein bisschen was von ihrem Wissen weiterzugeben. 1976 SC/MP Etwa 1980 6502 Dann beruflich ab 19985 6502 und 6809, aber wenig Privat etwas 68000 Beruflich ganz wenig 8086 Irgendwann mal privat AVR oder PIC-Zeug in 8 Bit. Und dann wurde das völlig uninteressant, weil ich mit so kleinen µC nichts mehr gemacht hab. Ich las mal in einem Artikel eine entscheidende Bemerkung als der MSP430 vorgestellt wurde: Die Maschinenbefehle wurden auf Compiler hin optimiert. Man geht nicht davon aus, dass die Prozessoren in Assembler programmiert werden. Mein verstaubtes 8-Bit Wissen hilft niemanden. Auch nicht mir. Ich fahr aber auch keinen Tretroller von Pucky mehr.
Ein Freund schrieb: > Wie weit bist Du denn gekommen? Ich hab rausgefunden wie die E Scooter Firmware funktioniert, und wie der Motor gesteuert wird. 28kmh ist wirklich schnell genug (Schneller kann der Scooter nicht, der Motor ist für Drehmoment gebaut und nicht für Geschwindigkeit) aber die Leistung also Strom und damit die Kraft lässt sich noch etwas erhöhen, da der Motor einen Tempsensor hat, dürfte da auch nix überhitzen. Das waren grundelegnde recht Langweilige Geschichten (Values ändern) jetzt will ich mal versuchen das Programm selbst zu ändern. Leider geht das nur in Assembler. Dazu kommt noch, dass noch ein weiterer Scooter dazu gekommen ist, ein Ninebot G30D, bei dem ich wissen will wie die Firmware funktioniert. Ich weiß dass es geht einen ARM in Assembler zu programmieren, weil ich Leute kenne dies können, aber leider nicht die Zeit haben das zu erklären da die sowas auf Arbeit machen (Assemblercode und Teilassemblercode schrieben) Dazu kommt dass man auf einem STM32F103C8 wohl sowas wie den Kalman Filter nur mit Assembler zum Laufen kriegen könnte (Vielleicht) da jeder normale Compiler dafür zu schlechten Code erzeugt. Dass der C8T6 dafür eh schlecht ist,ist mir klar, das Ding hat ja nicht mal eine FPU, aber er ist nunmal da drin, jetzt kann ich sehen was man rausholen kann, oder es gleich lassen, aber letzteres ist die langweiligste Option. Dass RISC Prozessoren die verstöpseltsten Dinger sind, die einem nur begegnen können, weiß ich auch, aber lieber lese ich noch den Assemblercode und verstehe den als mir das anzutun was der HEX Rays decompiler da raushaut. Ich dachte immer der HEX Rays Decompiler sei dazu gemacht worden, das Reversen zu vereifnachen, nicht es noch schwiriger zu machen, abe vielleicht ist es bei anderen ja genau andersrum. Natürlich ist hier wieder genau das passiert was ich erwartet hatte, jeder schlägt sich gegenseitig den Schädel ein, eine Sachliche Diskussion ist unmöglich.
Horst G. schrieb: > Herzlichen Glückwunsch Uii Horst, Glatteis. Aufgabe ist den C Code
1 | uint8_t tab[256]; // alignt auf 256 boundary |
2 | uint8_t pos; |
3 | ISR(TIMER1_CAPT_VECT) |
4 | {
|
5 | tab[pos++]=ICR1L; |
6 | tab[pos++]=ICR1H; |
7 | TCCR1B^=(1<<ICES1); |
8 | }
|
auf einem ATmega48 in
1 | TIMER1_CAPT_VECT: |
2 | IN r2,0x3F |
3 | LDS r3,0x86 |
4 | ST Z,r3 |
5 | INC r31 |
6 | LDS r3,0x87 |
7 | ST Z,r3 |
8 | INC r31 |
9 | LDS r3,0x81 |
10 | EOR r3,r4 // constant 0x40 |
11 | STS 0x81,r3 |
12 | OUT 0x3F,r2 |
13 | RETI |
wobei die Register r2, r3 und r31 vom restlichen Programm nicht verwendet werden (r31 wird ausgelesen um zu wissen wie voll der Buffer ist), r30 mit HI(tab) initialisiert ist und r4 mit 0x40 initialisiert ist. Die Routine darf (auf 1MHz AVR) nur 16us dauern, sonst müsste man auf 8MHz hochtakten. Ich hoffe, es ist kein Fehler drin.
Nick M. schrieb: > 1976 SC/MP Elektor? Den kann ich den hiesigen Asm-Fans innigst ans Herz legen. Nicht dass ein Compiler (so es überhaupt einen dafür gab) damit glücklicher würde, aber ihn selber programmieren zu müssen ist eine Strafe. Allerdings war er nicht so schweineteuer wie die Konkurrenz, und darauf kam es damals an.
:
Bearbeitet durch User
Bastler/Tüftler, hast du etwa schon wieder deinen Namen innerhalb eines Threads geändert? Tüftler schrieb: > Ich hab rausgefunden wie die E Scooter Firmware funktioniert Hast du nicht, das hätten wir mitbekommen. Du bildest dir immer noch ein, es zu durchblicken, bloß weil dein Disassembler irgend etwas scheinbar lesbares ausgegeben hat. Dabei verstehst du von dem Code genau so wenig wie ich von Strickmustern oder Genomen. Wir hatten dir vor Monaten empfohlen, zu lernen, den STM32F103C8 in Assembler zu programmieren. Wie weit bist du denn damit gekommen? Du hast keine einzige Zeile selbst geschriebenen Code präsentiert und ich denke, das entspricht dem tatsächlichen Stand.
Beitrag #6514190 wurde vom Autor gelöscht.
Tüftler schrieb: > jeder schlägt sich gegenseitig den Schädel ein Wäre dem wirklich so, wäre recht bald Ruhe. ;-)
Wolfgang schrieb: > Zwischen "aufwachsen mit Assembler" und ARM liegt deutlich mehr als ein > viertel Jahrhundert. Der ARM-Prozessor wurde 1983 von Acorn entwickelt, hauptsächlich von Roger Wilson (der später zu Sophie Wilson wurde). Demnach wäre die Zeit "aufwachsen mit Assembler" um 1958 gewesen. Welche Prozessoren gab es damals? Speziell für den ARM wurde dann auch das Betriebssystem RiscOs geschrieben, in Assembler! Es ist immer noch das schnellste Betriebssystem für ARM-Prozessoren, auch für den Raspberry Pi.
(prx) A. K. schrieb im Beitrag #6514190: > Diverse Kisten haben einen oder mehrere zusätzliche Registersätze für > solche Spässe, etwa Z80, I8051, TI9900. Irgendwo musst du überlesen haben dass es um eine Stromaufnahme ging, die lieber unter 35uA fürs Gesamtsystem an einer CR2530 gehen sollte. Wobei es auch dafür inzwischen uC gibt, die das auch in C einhalten würden, ATmega48 war halt fa und am Anfang dachte ich nicht, dass es so schwierig werden würde, dass man sogar Assembler schreiben musste.
(prx) A. K. schrieb: > Elektor? Den kann ich den hiesigen Asm-Fans innigst ans Herz legen. Genau der. Was ein Compiler sein soll, wusste ich zu der Zeit noch nicht. Aber das Ding wollte ich! Ich kann mich noch erinnern, wie ich meine Mutter gebettelt hab zu National nach Furt (???, jedenfalls von MUC aus die Salzburger Autobahn) zu fahren damit ich da den Chip kaufen kann. Die waren da aber nicht auf solche Großbestellungen eingerichtet. :-)) Hab ihn aber doch da bekommen.
Jobst Q. schrieb: > Es ist immer noch das schnellste Betriebssystem Ja super und DOS ist schneller als Windows. Was sagt das aus? Nichts!
Nick M. schrieb: > Man geht nicht davon aus, dass die Prozessoren in Assembler > programmiert werden. Wohl so ungefähr jede Befehlssatz-Architektur, die in den letzten 20-30 Jahren völlig frisch definiert wurde, orientiert sich in dieser Richtung. Kurioserweise ist aber ausgerechnet MSP430 ziemlich angenehm auf Asm-Ebene.
Stefan ⛄ F. schrieb: > Hast du nicht, das hätten wir mitbekommen. Woran hast du das nun denn schon wieder mitbekommen? Dass ich bei dir mit dem Scooter noch noch nicht durch die Wohnzimmerscheibe gekracht bin? Ich kann das Ding sicher nicht from scratch in Assembler programmieren, aber ich hab mit IDA rausgefunden wie die Stromregelung funktioniert undzwar im Grunde ganz einfach: Das Fahrzeug hat drei Shunts deren Verlustleistung einen Spannungsabfall verurscahen, der Spannungsabfall wird von ADCs gemessen, und es gibt in der Firmware eine Value die nicht überschritten wird. Je höher der Strom ist, desto höher ist auch die Verlustleistung am Shunt, desto höher ist also auch der Spannungsabfall der ADC misst diesen Abfall und dessen Value wird mit einer in der Firmware abgegelichen. Wenn man diese ändert, ändert das den Maximalstrom.
Bastler schrieb: >> Hast du nicht, das hätten wir mitbekommen. > Woran hast du das nun denn schon wieder mitbekommen? Du hättest deine Erfolge hier detailliert berichtet. Deine Erkenntnisse zur Strombegrenzung sind ja phänomenal. Oder um es mit den Worten eines bekannten Schauspielers zu sagen: Nein! Doch! Oooh!
Bastler schrieb: > Wenn man diese ändert, ändert das den > Maximalstrom. 3 passende Widerstände hätte ich schon gefunden. Löten kann ich. Aber Respekt, dass du das rausgefunden hast!
Mal etwas Sachliches. Ich habe vor langer Zeit (mehr als 10 Jahre) auch mit Assembler programmieren "müssen" - war kein Problem. Wichtig ist dabei nur, das man jede Zeile kommentieren muss oder kommentieren sollte. Ich hatte mal einen Fehler gesucht und gefunden, das war eine Programmzeile Assembler. C-Code sieht von Hause übersichtlicher aus und lässt sich besser warten. Ich bin Hobbyprogrammierer geblieben - Assembler möchte ich eher vermeiden. Deshalb setze ich auf Arduino und schreibe Quellcode, das man später auch mal auf anderen Prozessoren oder Umgebungen verwenden kann. Wer etwas in Assembler macht kann bei einem Prozessorwechsel die Mühe seiner Arbeit wegwerfen - so einfach ist das.
Beitrag #6514222 wurde von einem Moderator gelöscht.
Jens G. schrieb: > Mal etwas Sachliches. Ich habe vor langer Zeit (mehr als 10 Jahre) auch > mit Assembler programmieren "müssen" - war kein Problem. Wichtig ist > dabei nur, das man jede Zeile kommentieren muss oder kommentieren > sollte. > > Ich hatte mal einen Fehler gesucht und gefunden, das war eine > Programmzeile Assembler. > > C-Code sieht von Hause übersichtlicher aus und lässt sich besser warten. > Ich bin Hobbyprogrammierer geblieben - Assembler möchte ich eher > vermeiden. Deshalb setze ich auf Arduino und schreibe Quellcode, das man > später auch mal auf anderen Prozessoren oder Umgebungen verwenden kann. > > Wer etwas in Assembler macht kann bei einem Prozessorwechsel die Mühe > seiner Arbeit wegwerfen - so einfach ist das. Das ist der Haken an der Sache, einfach Umkompillieren oder Porten kannste vergessen, und es ist ein Haufen Arbeit, das ist bei Assembler nunmal leider so.
Jobst Q. schrieb: > Welche Prozessoren gab es damals? Diese Diskussion gab es aber damals schon. Die damals vmtl verbreitetste Maschine für die "Massen" war die IBM 650. Programmierte man die in Asm/Maschinencode, standen die ganzen 2000 Worte Trommelspeicher zu Verfügung (das war das RAM). Nutze man hingegen ein beliebtes Hilfsprogramm, evtl. einen Interpreter, dann blieb nur noch die Hälfte übrig. Dafür wars aber viel einfacher. (Story aus dem Familienkreis) Für Josef "Hex" G. wär die aber nix. Dezimal bis unter zu den Röhren.
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > W.S. schrieb: >> Er sagt seinem Cheffe, daß es nur mit einem dickeren µC geht >> - und der muß sich dann mit den Kostenplanern raufen, um das irgendwie >> in der Kalkulation unterzubringen. > > Ist immer noch erheblich günstiger, als Assembler-Spezialisten zu > bezahlen. Das kommt auf den Einzelfall an - bei hoher Stückzahl kann sich optimieren durch Assembler lohnen.
Stefan ⛄ F. schrieb: > Doch Es hat einen einfachen Grund warum ich das nicht getan hab: Ich will mir meine Verbindungen mit Lime nicht versauen, indem ich hier Sachen rumtröte, von denen die möglicherweise ncit wollen, dass sie jeder weiß. Aber die Leistungsvalue vom G30D hat das Offset 0000663C -> 00006640 das steht der Wert bei dem für die Leistung, für 25A z.B. [46 F2 A8 12] Und nein, der hat keine Checksumme die ein Ändern dieser Value verhindert...
Oje, jetzt hat er auch noch Geheim-Tips.... Ich komm mir grad wieder vor wie 10. :D
Wenn du Kindergarten sehn willst frag mal bei Scooterhacking an, die verhalten sich wirklich wie 10, haben den Scooter schon vor mir reversed, sagen aber nicht wie, und das einizge was du findest ist ein komischer Generator für eine "Custom Firmware" Dass die Software von Ninebot geklaut und von denen (Modifiziert) im Internet zum Download angeboten wird, macht die Sache nicht besser, Reverse Engineeren ist eigentlich nur für private Zwecke erlaubt. Wenn einer durch deren Modifizierte Firmware heutr an der Wand hängt will ich nciht wissen was die fürn Ärger kriegen, und Ninebot ist ihre ABE los...
Wartet mal bis die Leute erfahren dass es schon seit über 100 Jahren ein Fahrzeug gibt, das ähnlich günstig, führerscheinfrei, simpel wartbar und noch schneller ist - und das ganz ohne Hacking!
Horst G. schrieb: > Herzlichen Glückwunsch - Du hast gerade öffentlich demonstriert, dass du > dein Werkzeug (Compiler) nicht beherrschst. Nicht mehr und nicht > weniger. Nein, das ist Unsinn. Ja, man kann bei gewissen Compilern unter gewissen Umständen eventuell bestimmte Register reservieren. Das ist aber nicht portabel, da kein C, sondern architektur- und compilerspezifische Erweiterung. De facto also kein bissel besser, als gleich Assembler zu verwenden. Und wer Assembler beherrscht, wird genau dies tun, wenn's absehbar eng wird. Zumal das längst nicht die einzige Stelle ist, wo die Compiler schwächeln...
Wenn schon nicht portabel, dann wenigstens zu 100%. Schon klar.
Ich dachte, wir hätten schon vor ein paar Jahren geklärt, daß Assembler wieder auf dem Weg nach vorn ist. Das war auch so um die Weihnachtszeit.
Programmierer schrieb: > Wartet mal bis die Leute erfahren dass es schon seit über 100 Jahren ein > Fahrzeug gibt, das ähnlich günstig, führerscheinfrei, simpel wartbar und > noch schneller ist - und das ganz ohne Hacking! Naja, ich verfüge durchaus über ein Versuchsfahrzeug das es auch locker mit einem Rennrad aufnehmen kann, aber das kann eben dank der Versäumnisse der Politik hier nicht auf öffentlichem Grund fahren, oder besser gesagt: Können tut es schon, aber dürfen tut es nicht. Ist ja schließlich kein Rennrad das den Berg mit 100 runter darf ohne danach Ärger zu kriegen...
Thomas E. schrieb: > Ich dachte, wir hätten schon vor ein paar Jahren geklärt, daß Assembler > wieder auf dem Weg nach vorn ist. Das war auch so um die Weihnachtszeit. ... Popcorn... Popcorn... ;DDD
Carl D. schrieb: > Wenn schon nicht portabel, dann wenigstens zu 100%. > Schon klar. Ist es. Spätestens dann, wenn du eine lib linkst. Der, der die mal übersetzt hat, wusste nämlich noch nichts von irgendwelchen reservierten Registern in der Zielanwendung... Kann manchmal (zufällig) klappen, aber eine Garantie gibt es natürlich nicht. Oder hast du mit C/C++-Gewichse inzwischen die Grundfesten der Informatik so weit erschüttert, dass man die Kausalität jetzt nicht mehr berücksichtigen muss? Tja, dann ist wirklich C/C++ die ultimative Lösung für alles. Man kann dann jedes Ergebnis schon haben, bevor das Problem überhaupt gestellt wird... Der Traum eines jeden Arbeitgebers. Er kann dann alle seine C/C++-Knechte schlicht entlassen. Keiner braucht die dann mehr...
Was muß bloß in der Kindheit (oder auch länger) schief gelaufen sein, um so ein Verhalten zu entwickeln.
Thomas E. schrieb: > Ich dachte, wir hätten schon vor ein paar Jahren geklärt, daß Assembler > wieder auf dem Weg nach vorn ist. Das war auch so um die Weihnachtszeit. Lustig, der war gut.
Carl D. schrieb: > Was muß bloß in der Kindheit (oder auch länger) schief gelaufen sein, um > so ein Verhalten zu entwickeln. Es eben schlicht so, dass die gesamte Softwareindustrie der Welt auf dem Holzweg ist, weil sie nicht dem c-hater folgen. Da kann der doch nichts für. Jesus war auch nicht freiwillig der Messias.
Bastler schrieb: > Hallo Leute, > > Ich bins mal wieder, und bei dem Namen Bastler werden sicherlich schon > einige schreiend davonrennen (Die die mich kennen) aber ich will jetzt > doch mal wissen wo eigentlich die Leute abgeblieben sind, die damals > bevor es compiler gab µC´s und den ganzen Kram programmiert haben. Ich > interessiere mich doch sehr fürs Reverse Engineering besonders für die > RISC´s (Hauptsächlich ARM)und würds dann doch gerne weitergehend lernen. > Nun aber die Farge, ich kann mit dem Disassemblierten Zeug von IDA viel > besser umegehn als mit dem was der Hex Rays decompiler so macht, warum > auch immer. Ich bin noch dabei zu lernen, wie man den Krempel versteht, > aber so arg schwer wie einige hier sagten scheint das nicht zu sein, > sonst wäre ich Depp nicht schon so weit gekommen. > > Nun die Frage: Gibt es hier noch Leute die mit Assembler aufgewachsen > sind, und mir ein bisschen tiefergehend erklären können, wie man > disassemblierten ARM Maschinencode versteht, und am besten patcht? (Ich > hab ein Paar Dinge mit einem µC vor, die mit Compiler nicht gehen auf > dem µC da der Code zu ineffizient ist, daher bleibt nur: Schnellerer µC > -> geht nicht, oder effizienterer Code.) > > Ich hoffe dass sich hier ein Paar von den alten Hasen finden lassen die > vielleicht bereit sind ein bisschen was von ihrem Wissen weiterzugeben. > > Gruß Bastler Naja, das mit den alten Hasen eben. Eher sind es ja Häschen die in der alten Zeit so rugeistern. Ich kenne die Zeit noch sehr gut. Assembler vs. schlecht gemachten C-Code samt Werkzeug? Faktor 10x in der Zeit damals. Es macht in der heutigen Zeit echt keinen Sinn mehr, ev. noch sequentiell in-line assembler zu nutzen. Den Rest holst du über Code-/Algorithmen die effizient sind. Statt Schleifen dann halt Schiebeoperationen nutzen. Assembler ist wie mit der Mistgabel gegen Hightech zu kämfpfen. Und unser Leben ist nun mal sehr endlich.
Stefan ⛄ F. schrieb: > Jesus war auch nicht freiwillig der Messias. Aber so sehr er sich bemüht - Moby kann er nicht ersetzen. ;-)
:
Bearbeitet durch User
Carl D. schrieb: > Was muß bloß in der Kindheit (oder auch länger) schief gelaufen sein, um > so ein Verhalten zu entwickeln. Betamax?-/
Wer glaubt, Assembler wäre effizienter, sollte sich folgendes Video anschauen: KEYNOTE: What Everyone Should Know About How Amazing Compilers Are - Matt Godbolt [C++ on Sea 2019] https://www.youtube.com/watch?v=w0sz5WbS5AM&t=18s Wer weiß was Assembler macht kann die ersten 15 Minuten überspringen. Assembler ist praktisch tot. Es dauert länger zu schreiben, der Code ist schlechter wartbar und in den allermeisten Fällen auch langsamer. Unsere (z.T. gut abgehangenen, d.h. veralteten) Compiler im uC-Bereich sind nicht repräsentativ, zum Teil ist der Output wirklich grauenhaft. Aber selbst dann lohnt sich Assembler allerhöchstens in ganz kleinen Hotspots, wenn überhaupt. Und man braucht Profiling um die Hotspots zu identifizieren.
Carl D. schrieb: > Was muß bloß in der Kindheit (oder auch länger) schief gelaufen sein, um > so ein Verhalten zu entwickeln. Ganz einfach: Ich habe viel zu viele Idioten (und ihre Werke) gesehen. Das ist alles.
Bastler schrieb: Das Fahrzeug hat drei Shunts deren > Verlustleistung einen Spannungsabfall verurscahen, der Spannungsabfall > wird von ADCs gemessen, und es gibt in der Firmware eine Value die nicht > überschritten wird. Je höher der Strom ist, desto höher ist auch die > Verlustleistung am Shunt, desto höher ist also auch der Spannungsabfall > der ADC misst diesen Abfall und dessen Value wird mit einer in der > Firmware abgegelichen. Wenn man diese ändert, ändert das den > Maximalstrom. Anstatt den Code zu knacken wärs doch bedeutend einfacher die Shunts zu messen und deren Widerstand zu verkleinern...
c-hater schrieb: > Ganz einfach: Ich habe viel zu viele Idioten (und ihre Werke) gesehen. > > Das ist alles. Wie? Wohnst du im Spiegelsaal?
Tilo R. schrieb: > Wer glaubt, Assembler wäre effizienter, sollte sich folgendes > Video > anschauen: > > KEYNOTE: What Everyone Should Know About How Amazing Compilers Are - > Matt Godbolt [C++ on Sea 2019] > https://www.youtube.com/watch?v=w0sz5WbS5AM&t=18s > > Wer weiß was Assembler macht kann die ersten 15 Minuten überspringen. > > Assembler ist praktisch tot. Es dauert länger zu schreiben, der Code ist > schlechter wartbar und in den allermeisten Fällen auch langsamer. > > Unsere (z.T. gut abgehangenen, d.h. veralteten) Compiler im uC-Bereich > sind nicht repräsentativ, zum Teil ist der Output wirklich grauenhaft. > Aber selbst dann lohnt sich Assembler allerhöchstens in ganz kleinen > Hotspots, wenn überhaupt. Und man braucht Profiling um die Hotspots zu > identifizieren. Das Problem ist doch ein ganz anderes. Ich muss an Stellen effizient sein die ein System erfordern was in Echtzeit arbeitet. Was ist denn eigentlich Echtzeit? " Es ist ein System das eine garantierte zeitliche Obergrenze hat". Also brauche ich mich i.d. R. nur darum zu kümmern. Ob dann "Set-Befehle" im ms Bereich abgearbeitet werden, egal. Den MAschinencode anschauen und wenn es notwendig ist, dort optimieren. Die 80er sind vorbei.
Tilo R. schrieb: > Wer glaubt, Assembler wäre effizienter, sollte sich folgendes Video > anschauen: Aha. Irgendein Video als ultimativer Beweis? > Assembler ist praktisch tot. Das stimmt nicht. In jeder wirklich wichtigen Lib und Anwendung findest du mehr oder weniger grosse Teile in handgemachtem Assembler. Schau dir z.B. einen beliebigen Media-Codec an. Der Kern ist in Assembler geschrieben. Oder schau dir beliebige Crypto-Libs an: der Kern ist in Assembler geschrieben. > Es dauert länger zu schreiben Das stimmt. > der Code ist > schlechter wartbar Auch das stimmt. > und in den allermeisten Fällen auch langsamer. Und das ist die freche Lüge, die die C-only-Apologeten immer wieder verbreiten. Es ist und bleibt aber eine LÜGE. > Und man braucht Profiling um die Hotspots zu > identifizieren. Häha. Assemblerprogrammierer brauchen KEIN Profiling. Die erkennen die Knackpunkte bereits beim Schreiben des Codes. Genau das ist nämlich ihr Job...
c-hater schrieb: > Man kann dann jedes Ergebnis schon haben, bevor das Problem > überhaupt gestellt wird... +100 Das war der schönste Satz der Woche! Tilo R. schrieb: > Aber selbst dann lohnt sich Assembler allerhöchstens in ganz kleinen > Hotspots, wenn überhaupt. Und man braucht Profiling um die Hotspots zu > identifizieren. Wer mach schon gern etwas "zu Fuß" wenn andere Wege einfacher sind? Es gibt heute nur wenige Gründe für Assebler: 1. Eine tote Leiche wiederzubeleben? 2. ODER ein Programm zu schreiben was später kaum einer nachmachen kann? 3. Schon beim nächsten Update ist viel Spaß. 4. Einen aufmüpfigen Typen eine Fleißarbeit zu beschaffen? 5. In einigen Fällen Speicherplatz oder ein paar Takte zu sparen?
Bei mir ähnlich, aber alles privat. 6502/6510, Z80, MC68HC11, AVR, AN2131, CY68013, STM32. Für den Z80 habe ich sogar eigenhändig einen Cross-Assembler und einen Disassembler in VB geschrieben, kurz nachm Krieg. Die letzten 3 habe ich aber nie in Assembler programmiert, so daß das ARM-Tuning des Tretrollers von meiner Seite auch flachfällt. Allerdings wollte ich dem TO trotzdem Mut machen. Besser ARM dran als ARM ab.
Angehängte Dateien:
-
code_web_kurz.jpg
430 KB
Bastler schrieb: > wo eigentlich die Leute abgeblieben sind, die damals > bevor es compiler gab µC´s und den ganzen Kram programmiert haben. Ich > interessiere mich doch sehr fürs Reverse Engineering null Problemo erkennt den Prozessor und ASM
Joachim B. schrieb: > erkennt den Prozessor und ASM Keine Lust. Aber bei 31F8 und 3200 war wohl eine Fliege zwischen Druckkopf und Papier geraten. Wenn man 'Brazil' gesehen hat weiß man, daß sowas böse enden kann :)
oszi40 schrieb: > Es gibt heute nur wenige Gründe für Assebler: > 1. Eine tote Leiche wiederzubeleben? Ja. > 2. ODER ein Programm zu schreiben was später kaum einer nachmachen kann? Nein. Assembler kann man nachvollziehen. Hochsprachen schwer. > 3. Schon beim nächsten Update ist viel Spaß. ??? > 4. Einen aufmüpfigen Typen eine Fleißarbeit zu beschaffen? ??? > 5. In einigen Fällen Speicherplatz oder ein paar Takte zu sparen? Manchmal nützlich.
anonymus schrieb: > Anstatt den Code zu knacken wärs doch bedeutend einfacher die Shunts zu > messen und deren Widerstand zu verkleinern... Wärs sicher gewesen, aber auch irgendwo langweilig, immerhin kann das jeder, mal abgesehen davon, dass der 3 SMD Shunts mit R001 hat, viel weiter runter geht also nicht... Außerdem kann man in der Firmware das max current viel genauer einstellen, und so auch z.B. unter der Überstromschwelle des BMS des Lithiumakkus bleiben (Wenn du zu viel Strom ziehst denkt das BMS irgendwann es wäre ein Kurzschluss und schaltet ab)
Jürgen S. schrieb: > Aber bei 31F8 und 3200 war wohl eine Fliege zwischen > Druckkopf und Papier geraten eher Scanfehler https://www.youtube.com/watch?v=7FeqF1-Z1g0
michael_ schrieb: > Nein. Assembler kann man nachvollziehen. Hochsprachen schwer. Ein winziges Stück schlecht kommentierter Assembler zwischendurch kann eine schöne Fußangel sein, sobald andere Hardware ins Spiel kommt. Mehr schreibe ich nicht.
michael_ schrieb: > Nein. Assembler kann man nachvollziehen. Hochsprachen schwer. Deshalb sucht der BND derzeit per Stellenausschreibung nach Personal fürs Reverse Engineering von Open Source Code. Wäre bei Assembler bestimmt einfacher.
:
Bearbeitet durch User
oszi40 schrieb: > Ein winziges Stück schlecht kommentierter Assembler zwischendurch kann > eine schöne Fußangel sein, Bei Reverse ist sowieso nichts kommentiert. Der Reass spuckt auch nur durchnumerierte Marken aus.
Ich bin Jahrgang '93 und habe Assembler gerade noch so mitbekommen. Habe meinen ersten Mikrocontroller in Assembler um ~2010 rum programmiert. War ein PIC16F84 und später ein PIC16F876. Waren relativ einfache Sachen die ich gemacht habe. z.B. 2*16 Zeichen LCD ansteuern oder ADC lesen. Mit Assembler habe ich heute eigentlich gar nichts mehr am Hut, außer dass ich manchmal DSP libraries nutze die intern noch händisch mit Assembler gemacht sind.
Bastler schrieb: > ich will jetzt doch mal wissen wo eigentlich die Leute abgeblieben > sind, die damals bevor es compiler gab µC´s und den ganzen Kram > programmiert haben. Und Du bist ganz sicher, dass mCs älter sind als Compiler?
Mein erster Computer Ende der 70er war der AIM-65 mit 6502 - und schon dafür gab es einen Compiler in 8KB ROM.
:
Bearbeitet durch User
Bastler schrieb: > wie man disassemblierten ARM Maschinencode versteht Die "Genies" sind hier, bei dem Versuch, die nicht dokumentierten ARM Assembler RISC OS Kernel Module nach C zu portieren :-) https://www.riscosopen.org/forum/forums/5/topics/15704 https://www.riscosopen.org/forum/forums/5/topics/15990
Bastler schrieb: > Nun die Frage: Gibt es hier noch Leute die mit Assembler aufgewachsen > sind, und mir ein bisschen tiefergehend erklären können, wie man > disassemblierten ARM Maschinencode versteht, und am besten patcht? Da besteht kein Zusammenhang. Der Assemblercode mit dem sich meine Generation von 40J beschäftigt hatte, war verhältnismäßig einfacher Code für 8-Bit Prozessoren. Davon abgesehen, daß ich da in Maschinencode programmiert hatte und nicht mit Assembler. So etwas war (wie C-Compiler auch) nämlich richtig teuer (Papier und Bleistift taten es auch). Die ARMs spielen da in einer anderen Liga. Das tut sich heute keiner freiwillig an. 1€ draufgelegt und den nächstschnellere uC gekauft falls es nötig sein sollte. Nötig ist es selten. Nachdenken über den Algorithmus hilft meistens auch. (prx) A. K. schrieb: > Mein erster Computer Ende der 70er war der AIM-65 mit 6502 - und schon > dafür gab es einen Compiler in 8KB ROM. Das war zu 100% ein Basic-Interpreter. Evt. sogar MS wie bei meinem Ohio C1P.
Scheinbar bist bei der 3er nun schon selbst weiter gekommen. Job geht leider vor. G30D ist easy. Lad dir einfach alle Kombinationen runter und diff... Klappt auch 100% bei den anderen cfw gen. Beschriftung/Adressierung quasi frei Haus. Es gibt zwar ein Repo mit einer Rails App, aber mehr als das steht dort auch nicht drin. Cooler Trick, ich weiß.... Wegen so dumme Sprüche zu STM32F103 bin ich da übrigens endgültig raus. Kindergarten.
Andreas B. schrieb: > Das war zu 100% ein Basic-Interpreter. Evt. sogar MS wie bei meinem Ohio > C1P. Zu PL/65 kann ich nichts sagen, aber Gary Kildalls PL/M war ein lupenreiner Compiler und lief zunächst auf 8008, bevor er auf 8080 portiert wurde. Der Name spielte ebenso auf PL/1 an wie PL/65 (doch, diese Sprache gab es auch einmal; für Mainframes. Das M in PL/M sollte dann die "Portierung" auf Micros andeuten) Andreas B. schrieb: > Davon abgesehen, daß ich da in Maschinencode programmiert hatte und > nicht mit Assembler. So etwas war (wie C-Compiler auch) nämlich richtig > teuer (Papier und Bleistift taten es auch). Bei CP/M war ein Assembler nebst Debugger im Lieferumfang (was wegen der erforderlichrn Anpassung an das Zielsystem auch kaum anders sinnvoll gewesen wäre).
:
Bearbeitet durch User
Percy N. schrieb: > Zu PL/65 kann ich nichts sagen, ... > Bei CP/M war ein Assembler nebst Debugger im Lieferumfang Öhm, wir sprechen hier von Homecomputern. (prx) A. K. schrieb: > AIM-65 mit 6502 Andreas B. schrieb: > wie bei meinem Ohio > C1P. Und (wenn es das für die Home PCs denn überhaupt gab) waren Assembler oder Compiler für den Durchschnittshobbisten in meinem Alter unbezahlbar. Später hatte ich dann CP/M auf einem Apple II Nachbau (mit ebenfalls nachgebauter CPM Karte) am Laufen. Aber auch da war so etwas wie ein Assembler in weiter Ferne.
:
Bearbeitet durch User
Andreas B. schrieb: >> Bei CP/M war ein Assembler nebst Debugger im Lieferumfang > Öhm, wir sprechen hier von Homecomputern. Du vielleicht, prx und ich reden über MCs. > (prx) A. K. schrieb: >> AIM-65 mit 6502 > > Andreas B. schrieb: >> wie bei meinem Ohio >> C1P. Da hat es auch wenig Sinn, einen PL/I-Compiler für einen BASIC-Interpreter zu halten. > > Und (wenn es das für die Home PCs denn überhaupt gab) waren Assembler > oder Compiler für den Durchschnittshobbisten in meinem Alter > unbezahlbar. Ich habe mit keiner Silbe von Hobby gesprochen. > Später hatte ich dann CP/M auf einem Apple II Nachbau (mit ebenfalls > nachgebauter CPM Karte) am Laufen. Aber auch da war so etwas wie ein > Assembler in weiter Ferne. Dann hast Du Dir wohl ein "gebrauchtes" CP/M andrehen lassen; bei CP/M bis 2.2 war ASM und DEBUG im Lieferumfang, ab 3.0 sogar (R)MAC und SID. MS-DOS war zur selben Zeit deutlich schlechter ausgestattet. Ach ja: von MS gab es damals den MACRO-80. Der war tatsächlich sauteuer (und zumindest für CP/M 3.0 eigentlich überflüssig).
:
Bearbeitet durch User
Bastler schrieb: > Leistungsvalue Bastler schrieb: > es gibt in der Firmware eine Value Bastler schrieb: > aber so arg schwer wie einige hier sagten scheint das nicht zu sein Weil Du gar keine Ahnung von Programmieren hast! Du hast nur ein paar Values geändert!
Andreas B. schrieb: > (prx) A. K. schrieb: >> Mein erster Computer Ende der 70er war der AIM-65 mit 6502 - und schon >> dafür gab es einen Compiler in 8KB ROM. > Das war zu 100% ein Basic-Interpreter. Evt. sogar MS wie bei meinem Ohio > C1P. Zu 33%. Für die 2 ROM Plätze à 4kB gab es neben PL/65 auch ein MS-Basic und FORTH zur Auswahl. Ein drittes der optionalen ROM enthielt den Assembler, den brauchte man bei PL/65 auch. Das Gerät ist dokumentiert, da muss man nicht falsch raten. Den PL/65 Compiler hatte ich kaum verwendet, aber aus Neugierde reverse engineered. Wollte wissen wie er arbeitet. In sich selbst war der nicht geschrieben. Auch in keinem anderen Compiler, sondern sehr sicher in Assembler. Recht spezielle Programmiertechnik.
:
Bearbeitet durch User
Percy N. schrieb: > Da hat es auch wenig Sinn, einen PL/I-Compiler für einen > BASIC-Interpreter zu halten. Naja... Von PL/I hatte PL/65 nur ein wenig von der Syntax genommen. Einen respektablen PL/I Compiler gab es hingegen für CP/M. Auch einige andere, wie Fortran und Cobol und diverse Pascals.
Percy N. schrieb: > Du vielleicht, prx und ich reden über MCs. Der AIM-65 war eine Art Schrumpfversion des SYSTEM65 Entwicklungssystems von Rockwell. Zum Homecomputer für Bastler wie mich wurde er erst, wenn man diverse Karten dranbastelte, wie einer Videokarte für einen Monitor, sowie Floppycontroller und genug RAM. Der Bus stand dafür offen zur Verfügung.
:
Bearbeitet durch User
Andreas B. schrieb: > Und (wenn es das für die Home PCs denn überhaupt gab) waren Assembler > oder Compiler für den Durchschnittshobbisten in meinem Alter > unbezahlbar. Die ROMs waren leidlich bezahlbar. Bei ASM und Forth hatte ich das sogar getan. Ferienjob als Schüler bringts rein, auf diese Art finanzierte ich auch das Gerät selbst. Basic und PL/65 flogen mir anderweitig zu.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Einen respektablen PL/I Compiler gab es hingegen für CP/M. Auch einige > andere, wie Fortran und Cobol und diverse Pascals. Ja, kostete das dann aber tatsächlich Geld. Was Assembler anging, kam man recht gut mit den Birdmitteln zurecht, nur konnten die leider nur 8080, kein z80 (gut, man konnte ein paar Makros basteln...). (prx) A. K. schrieb: > Zum Homecomputer für Bastler wie mich wurde er erst, wenn man diverse > Karten dranbastelte, wie einer Videokarte für einen Monitor, sowie > Floppycontroller und genug RAM. Und für den damaligen Preis von zwei Schachtel Disketten gab es schon bald den "teuren" Assembler. An den Preis für das Kaufwerk mag man erst gar nicht denken.
Einen nicht-symbolischen Assembler hatte der AIM-65 bereits vorneweg in den Monitor-ROMs drin. Ebenso Disassembler, immerhin war der als rudimentäres Entwicklungssystem gedacht. Zumindest von Rockwell. Siemens brachte das Gerät mit Gehäuse drumrum als PC-100 raus. Bei Rockwell durfte man das Gehäuse selber bauen, auch das Netzteil für 5V und 24V war nicht dabei.
:
Bearbeitet durch User
Percy N. schrieb: > Ja, kostete das dann aber tatsächlich Geld. Jedenfalls offiziell. Bekannter hatte später ein CP/M System mit nachempfundenen OS namens ZDOS oder so. Und zunächst ganz offiziell Pascal per Bytecode, später natürlich Turbo-Pascal.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Einen nicht-symbolischen Assembler hatte der AIM-65 bereits vorneweg in > den Monitor-ROMs drin. Ebenso Disassembler, immerhin war der als > rudimentäres Entwicklungssystem gedacht. Zumindest von Rockwell. Wenn es "nur" darum ging, ein Schaltwerk aus TTL-Chips durch programmierte Logik zu ersetzen, dürfte das vielfach sogar mindestens hinreichend gewesen sein.
:
Bearbeitet durch User
Es gibt noch Bereiche, da spielt Assembler eine Rolle. Bei der Programmierung von C-Compilern, kommt man aber nicht um den Assembler herum. Denn der binäre Maschinencode hinter jedem Basis-C-Befehl ist in Assembler programmiert. Diese werden als Module für höhere C-Befehle verwendet, die sozusagen auf den Basis-C-Befehlen aufbauen. Notwendig das anzufassen ist aber nur, wenn an den Prozessoren Änderungen oder Erweiterungen durchgeführt werden. Eigentlich hätte ich gedacht, dass bei dem Thema ein Poster mit seinem Realtime Buch geweckt worden wäre. Für ganz schnelle Anwendungen wird ASM auch noch verwendet. Auf der Suche nach verstecktem Code in Compilern und versteckten Erweiterungen in Prozessoren wird man sich damit beschäftigen müssen. Da ASM nicht mehr so viel benötigt wird, gibt es auch viel weniger die sich damit beschäftigen.
Beitrag #6514499 wurde vom Autor gelöscht.
Also ich benutze einen Hammer für Nägel und einen Schraubenzieher für Schrauben. Letzteren passend zum Schraubenkopf. Ich bekomme natürlich die Schraube auch mit dem Hammer in die Wand.
Wolfgang R. schrieb: > Also ich benutze einen Hammer für Nägel und einen Schraubenzieher für > Schrauben. Letzteren passend zum Schraubenkopf. Das kann doch jeder. Im Thread werden die Genies gesucht. ;-)
(prx) A. K. schrieb: > Wolfgang R. schrieb: >> Also ich benutze einen Hammer für Nägel und einen Schraubenzieher für >> Schrauben. Letzteren passend zum Schraubenkopf. > > Das kann doch jeder. Im Thread werden die Genies gesucht. ;-) A, sorry... war das nicht das hübsche Mädel aus der Lampe?
Assembler ist, wenn man mit der Handsäge einen Baum fällt. Compiler ist, wenn man einen Harvester nimmt. Das eine ist mühsam und kraftraubend, das andere ist effizient und nachhaltig.
H.Joachim S. schrieb: > Das ganze Thema ist (sinnloserweise) regelmässig für einen längeren > trööt gut. Führt genauso regelmässig zu exakt nichts. Doch es führt eigentlich immer zu den Erkenntnissen: -Es ist immer gut Assembler lesen zu können um die Leistungsfähigkeit seines C-Codes realistisch einschätzen zu können -wenn man heutzutage Assembler schreibt dann als inline code wo es wirklich nötig ist. -man kommt auch ohne Assemblerkenntnisse als 0815 Codierschwein gut über die Runden SCNR
Wolfgang R. schrieb: > Ich bekomme natürlich die Schraube auch mit dem Hammer in die Wand. Wenn Du als Schraubenzieher keinen Kuhfuß, sondern einen Latthammer verwendest, taugt der für beide Richtungen. Wolfgang R. schrieb: > A, sorry... war das nicht das hübsche Mädel aus der Lampe? Nein, Du meinst vermutlich die Zicke azs der Flasche. Peter D. schrieb: > Compiler ist, wenn man einen Harvester nimmt. > Das eine ist mühsam und kraftraubend, das andere ist effizient und > nachhaltig. Und Harvester setzt keine besonderen Fähigkeiten voraus...
:
Bearbeitet durch User
Nick M. schrieb: > ein Problem einzukreisen wenn man Assembler lesen kann. Das ist der eigentliche Witz an der Sache. Ich sehe ich mir den Assembler nur an, wenn der Compiler gefühlt "fehlerhaften" Code erzeugt und das Ergebnis "falsch" oder unerwartet reagiert. Und in den allermeisten Fällen ist es dann aber kein Compilerfehler, sondern ein "Nichtlesen" oder "Nichtverstehen" der Doku und ein daraus entstehendes Semaphorenproblem. Udo S. schrieb: > In der Regel ist nicht Assembler oder Hochsprache das Problem, sondern > ineffizente Algorithmen. Und die Verwendung umständlicher Datentypen. MaWin schrieb: > Du hast dir wohl noch nie den Assembler-Output von Compilern angesehen. Wenn ich ein Laufzeitproblem in einem 8-Pin µC habe, der eine Stromregelung machen muss, dann sehe ich mir mal den erzeugten Assembler an und versuche anschließend, den C-Code so zu schreiben, dass der Compiler kapiert, was ich will. Und erst, wenn ich dem das nicht beigebogen bekomme, dann werfe ich den Assembler an. Um besseren Code als der Compiler zu schreiben, muss ich die Prozessorarchitektur aber schon recht gut kennen. Und ich muss den Compiler gut kennen, wenn der Assemblercode neben dem oder interaktiv zum Compilercode laufen soll. > Der ist so grausam uneffektiv Ich kann relativ simpel ein ganz spezielles Problem in einer Assemblerroutine schnell und kompakt lösen. Aber ich kann eben nicht komplexe Aufgaben in Assembler schnell und kompakt lösen. Es ist wie beim Autofahren: Natürlich kann ich dank tiefgehendem Wissen um die Kinematik meines speziellen Fahrzeugs (Prozessorkenntnisse) und eingehender Ortskenntnis (Assemblerkentnisse) über Schleichwege und Abkürzungen durchaus mal schneller zum Ziel kommen. Allerdings schaffen das auch die Unbedarften, die einfach nur mit Navi auf der Hauptstraße fahren, an jeder Ampel und an jedem Fußgängerweg anhalten und sogar am Kindergarten entlang langsam machen. Sie brauchen halt nur ein wenig länger. Es "reicht" trotzdem in den meisten Fällen.
Gähhn. https://de.wikipedia.org/wiki/Mikrocomputer_f%C3%BCr_Ausbildung Hab die dicken Dokus weggeschmissen, seitdem ich mit Atmel AVRs "arbeite". War aber ne gute Grundlage, wie Brötchen essen bevor man sich die Hucke mit Alk vollhaut. Dann wird man nicht so schnell "blau", wenn man mit den ätzenden Befehlsfolgen von MAT85-Assembler mal gearbeitet hat. Und der Entstörkondensator beim Trafo eingebaut ist, damit das Programm nicht bei jedem Schaltkracher abstürzt. ciao gustav
:
Bearbeitet durch User
Ich halte nicht für Zielführend, die Vorteile von Assembler an 10 Zeilen isoliertem Programmcode zu diskutieren. Dass hand-gedengelter Code schneller sein kann, halte ich für offensichtlich. Er kann aber auch mit viel höherer Wahrscheinlichkeit schlechter sein, denn er wird von unvollkommenen Menschen erstellt. Ja, ein schnelleres/kompakteres Programm kann auf einem kleinere Mikrocontroller laufen. Doch das gleicht nur selten die Entwicklungskosten aus, die man in eine derartige Optimierung stecken müsste. Vergleiche doch nur mal die Preise von ATmega Controllern mit STM32. Dort bekommst du ein vielfaches an Leistung zum gleichen Preis. Teilweise sind die STM32 sogar billiger! Der richtige Weg ist irgendwo in der Mitte dazwischen. Code der von Menschen schnell erstellt, geprüft und geändert werden kann und zugleich eine gute Performance hat. Da ist man (unter anderen) mit C auf der richtigen Seite. Assembler hebe ich mir für die seltenen Spezialfälle auf, wo es wirklich nötig ist. Wenn wird deswegen irgendwann niemanden mehr haben, der Assembler beherrscht, dann ist das halt so. Davon geht die Welt nicht unter. Ich kenne auch niemanden, der noch Röhren in Handarbeit herstellt. Brauche ich auch nicht, denn diese Technik ist (so gut sie war) überflüssig geworden.
Wer mir im Berufsumfeld damit ankommt und einen Mikrocontroller komplett in ASM programmiert...den würde ich vom Hof jagen(ja, jetzt wird sicher jemand irgendein Beispiel konstruieren, wo es in 0.0001% der Fälle doch Sinn macht) Wartbarkeit & Verständlichkeit(nicht nur für den ASM Guru) ist einfach wichtiger und so schon schwer genug umzusetzen wenn sich da nicht alle gleichermaßen für verantwortlich fühlen und es nicht Teil der Firmenkultur ist. Da muss man sich nicht noch zusätzlich sein eigenes Grab schaufeln, indem man die ASM Hölle lostritt
Es soll Leute geben, die C für einen etwas eigenartigen Assembler halten.
Also ich finde mit Assembler spart man sich den Haufen Text (der auch noch weit in die Tiefe referenziert) von zB. C++. C geht noch Text-mäßig wie ich feststellen konnte, man kann das ähnlich Assembler benutzen also nur Variablen und Unterprogramme usw. Wie steht es eigentlich mit dem Bloating bei Hochsprachen und Controllern ? Ich habe gelesen dass die Hersteller gerne alles künstlich aufblasen damit es Konkurrenten schwer haben und der Kunde gebunden wird und ständig neu kaufen muss.
Moin schrieb: > Wie steht es eigentlich mit dem Bloating bei Hochsprachen und > Controllern ? Bei Java kam ja irgendwer auf die "grandiose" Idee, Header Dateien weg zu lassen. Was am Ende dazu führte, dass ein Pärchen aus Interface oder Abstrakten Klassen gepaart mit Implementierungen zum allgemeinen Pattern wurde. Also "back to the roots" sozuagen. Die vielen Klammern in C/C++/Java finde ich auch nervig. Ist aber immer noch angenehmer als ständig BEGIN und END schreiben zu müssen. Auf einer amerikanischen Tastatur sind die Tasten für Klammern und Semikolons auch viel angenehmer angeordnet. Ich hatte deswegen mal erwägt, mir so eine Tastatur zu besorgen. Aber ich bin zu alt dafür, das Umlernen klappte nicht. Dann tat sich die Hölle auf und brachte Python hervor. Musste ja irgendwann passieren, das war klar. Ich musste ein Jahr lang Sachen für Odoo (OpenERP) programmieren, das war ein Graus! Pythons Syntax kann ich ehrlich gesagt nur unter Drogen ertragen. Wie kommt man auf die Idee, dass der Einrückungstiefe und den Leerzeilen eine technische Funktion zuzuweisen? Dazu kommt dann noch, dass man nur zur Laufzeit erkennen kann, welche Eigenschaften die meisten Objekte tatsächlich haben (damit meine ich nicht die konkreten Values, sondern die Namen der Attribute und Methode). Ich hoffe, dass dieses Kapitel möglichst bald als peinlicher Ausrutscher beendet wird.
Beitrag #6514778 wurde von einem Moderator gelöscht.
Stefan ⛄ F. schrieb: > Bei Java kam ja irgendwer auf die "grandiose" Idee, Header Dateien weg > zu lassen. Viele C++ Programmierer würden sie auch gerne ad acta legen, aber es lässt sich technisch kaum machen. In Java braucht man schlicht keine Header und das ist enorm praktisch. Wenn man sehen will, welche Typen und Funktionen eine Library bietet, fügt man die JAR-Datei seinem Projekt hinzu, und die IDE zeigt im Klassenbrowser oder auch in der Autovervollständigung alles verfügbare an, natürlich zusammen mit der Javadoc-Doku. Wenn man unbedingt einen textuellen "Header" haben will, lässt man sich den einfach per "javap library.jar" generieren. Stefan ⛄ F. schrieb: > Was am Ende dazu führte, dass ein Pärchen aus Interface oder Abstrakten > Klassen gepaart mit Implementierungen zum allgemeinen Pattern wurde. Nur wenn man Sachen wie Strategy Pattern macht. Kann man in C auch, wenn man will. In Java macht man es auch nur wenn man es explizit braucht. Das Fehlen von Headern ist definitiv nicht der Grund dafür dass man Interfaces benutzt. Stefan ⛄ F. schrieb: > Wie kommt man auf die Idee, > dass der Einrückungstiefe und den Leerzeilen eine technische Funktion > zuzuweisen? Indem man eine Millionen schlecht eingerückte C oder C++-Quellen gesehen hat und sich gedacht hat, die Leute einfach dazu zu zwingen, es richtig zu machen. Finde ich großartig, dadurch ist Python-Code immer korrekt eingerückt und lesbar. Stefan ⛄ F. schrieb: > azu kommt dann noch, dass man nur zur Laufzeit erkennen > kann, welche Eigenschaften die meisten Objekte tatsächlich haben So ist das bei dynamischen Sprachen, und das hat nicht Python erfunden. Das erfreut sich großer Beliebtheit und ist insbesondere für Anfänger sehr praktisch. Stefan ⛄ F. schrieb: > Ich hoffe, dass dieses Kapitel möglichst bald als peinlicher Ausrutscher > beendet wird. Dynamische Sprachen wie Python, PHP, JS, Lua sind gekommen um zu bleiben. Ich bin mir gerade auch nicht sicher, ob das Konzept nicht sogar älter als statische Typisierung ist (LISP?).
Percy N. schrieb: > Es soll Leute geben, die C für einen etwas eigenartigen Assembler > halten. PL/65 ist weit eher eine strukturierte Assemblerprogrammierung als C. Keine Symboltabelle, keine Datentypen, keine Compilerchecks, keine Parameter in Funktionsaufrufen etc. Codegenerierung rein aus der Syntax heraus. Diverse Operandenausrücke werden direkt an den Assembler durchgereicht. Pech wenns relative Sprungziel zu weit weg ist. Fehler merkt oft erst der Assembler. Ich hatte das bei einem Z80 Terminalsystem später ähnlich gemacht. Codegenerierung direkt aus dem Yacc-Parser heraus.
:
Bearbeitet durch User
Beitrag #6514812 wurde von einem Moderator gelöscht.
(prx) A. K. schrieb: > Ich hatte das bei einem Z80 Terminalsystem später ähnlich gemacht. > Codegenerierung direkt aus dem Yacc-Parser heraus. Beitrag "Re: Retro Fieber: Z80 oder 68000 ?" Beitrag "Re: Retro Fieber: Z80 oder 68000 ?"
Beitrag #6514822 wurde von einem Moderator gelöscht.
Beitrag #6514823 wurde von einem Moderator gelöscht.
Beitrag #6514824 wurde von einem Moderator gelöscht.
Percy N. schrieb: > Es soll Leute geben, die C für einen etwas eigenartigen Assembler > halten. Nicht eigenartig, C ist ein Assembler mit -automatischer Variablen-Speicher-Allokation -etwas besser lesbaren Mnemnoics für Daten Transfer Befehlen -impliziter subroutine calling conventions Das heisst C nimmt einem etwas Handwerk ab, was man als Assemblerprogrammierer händisch machen müsste. Und der ganzen Rest an Anforderungen an den Programmierer wie: -wartbaren Code in lesbaren Codestil schreiben -Versions./Requirement -Algorithmen und deren fallstricke kennen ist eh gleich. Gut unter C steht man nicht so unter Druck optimierten Code zu schreiben, das kann man auf den Compiler und ein Hardware-Upgrade abschieben.
Beitrag #6514827 wurde von einem Moderator gelöscht.
Beitrag #6514828 wurde von einem Moderator gelöscht.
Beitrag #6514829 wurde von einem Moderator gelöscht.
Beitrag #6514834 wurde von einem Moderator gelöscht.
Beitrag #6514836 wurde von einem Moderator gelöscht.
Beitrag #6514837 wurde von einem Moderator gelöscht.
Beitrag #6514839 wurde von einem Moderator gelöscht.
Beitrag #6514840 wurde von einem Moderator gelöscht.
Beitrag #6514841 wurde von einem Moderator gelöscht.
Programmierer schrieb: > Indem man eine Millionen schlecht eingerückte C oder C++-Quellen gesehen > hat und sich gedacht hat, die Leute einfach dazu zu zwingen, es richtig > zu machen. Finde ich großartig, dadurch ist Python-Code immer korrekt > eingerückt und lesbar. Wenn Ich das sehen drücke ICH F12... (Ich nutze aber auch ne IDE und keinen Texteditor!) ... Da hat sich wohl ein Assembler-Freak verewigt. Da war/ist(?) das durchaus üblich (einfacherer/kleiner Parser?).
Programmierer schrieb: > In Java braucht man schlicht keine > Header und das ist enorm praktisch. Aber nur, wenn die Klassen Open-Source sind. Was im Java Umfeld zugegebenermaßen der Regelfall ist - außer bei SAP, soweit ich weiß. Programmierer schrieb: > In Java macht man es auch nur wenn man es explizit braucht. Dort wo ich arbeite (und vorher und auch davor arbeitete) leider immer. Wenn du dort irgendeine Klasse ohne Interface schreibst, wirft man dir vor, ein schlechter Programmierer zu sein. Alles muss austauschbar und wiederverwendbar sein, als wäre es eine öffentliche Library. Selbst wenn sonnenklar ist, dass es von dieser einen Klasse never ever mehr als eine Variante geben wird und diese niemals veröffentlicht wird. Dieses Pattern gehört (warum auch immer) unter Java Entwicklern zum guten Ton. Programmierer schrieb: > Indem man eine Millionen schlecht eingerückte C oder C++-Quellen gesehen > hat und sich gedacht hat, die Leute einfach dazu zu zwingen, es richtig > zu machen. Finde ich großartig, dadurch ist Python-Code immer korrekt > eingerückt und lesbar. Und du musst nur einmal aus Versehen eine Leertaste drücken oder auf die Entf. Taste kommen, schon ist das Programm kaputt ohne dass der Compiler/Editor es bemerkt. Ich finde das ziemlich riskant. >> dass man nur zur Laufzeit erkennen kann, welche Eigenschaften >> die meisten Objekte tatsächlich haben > So ist das bei dynamischen Sprachen, und das hat nicht Python erfunden. Dass stimmt wohl. Es ist nur ein weiterer Grund für mich, Python doof zu finden und ebenso alle anderen Sprachen die das tun. Alles voran Javascript.
Stefan ⛄ F. schrieb: > Pythons Syntax ... Einrückungstiefe und den Leerzeilen > eine technische Funktion .... ? Vermutlich waren die Meisten der Phytoner mit Fortran 77 groß geworden.
Teo D. schrieb: > Wenn Ich das sehen drücke ICH F12... (Ich nutze aber auch ne IDE und > keinen Texteditor!) > ... > Da hat sich wohl ein Assembler-Freak verewigt. Da war/ist(?) das > durchaus üblich (einfacherer/kleiner Parser?). Dazu fällt mir ein: Kennt wer die Sprache Spin? Die lief auf dem Propeller von Parallax. Der Chef-Kopf des Ganzen hat den Compiler für Spin in Assembler 8086 geschrieben. Ich hab ihn mal im Forum gefragt warum. Antwort: Ich kann nur Assembler. Der Mist ist ihm dann auf die Füße gefallen, als man die Idee hatte auch auf anderen Platformen eine IDE haben zu wollen. Compiler in Assembler schreiben! Im 21. Jahrhundert! Absurd!
Naja, wenn Python keine eigene Syntax gehabt hätte, hätte man wiederum dessen Existenzberechtigung hinterfragen können. Irgendwas muss ja anders sein (nicht unbedingt besser) sein, als das was schon da ist.
Bastler schrieb: > aber ich will jetzt > doch mal wissen wo eigentlich die Leute abgeblieben sind Das Problem sitzt viel tiefer. Frage doch mal, wo die ganzen Analog-Leute hin sind. Wer auch immer irgendwas programmiert, beweist damit schon, daß er von Elektronik keine Ahnung (mehr) hat. Ohne µC würden die Leute heute nicht mal mehr ein Radio selbst bauen können. Geschweige denn, einen Fernseher, so wie es früher diverse Leute getan haben. Und zwar mit üblen Bauteilen! Heute wäre das ein Klacks, aber sie schaffen es trotzdem nicht mehr. Ihr werdet wie immer anderer Meinung sein. Aber das liegt nur am nächsten riesigen Problem, namentlich dem lebenslangen Selbstbetrug und der grenzenlosen Selbstüberschätzung.
Uwe S. schrieb: > Wer auch immer irgendwas programmiert, beweist > damit schon, daß er von Elektronik keine Ahnung (mehr) hat. Diese Schlussfolgerung ist noch falscher als: Brot ist giftig, weil alle gestorbenen Brot gegessen haben. Du beleidigst damit fast jeden, der Ahnung von beiden Technologien hat. Ich musste in meiner Abschlussprüfung der Berufsausbildung Fehler in einem TV Schaltplan finden und auf englisch erklären. Ich musste auch einen Z80 in Assembler programmieren und einen PC in Pascal. Ja, analoge Schaltungen waren sicher nicht mein Schwerpunkt. Aber es machte durchaus einen wesentlichen Teil der Ausbildung aus.
Uwe S. schrieb: > Geschweige denn, einen Fernseher, so wie es früher diverse Leute > getan haben. Und zwar mit üblen Bauteilen! Auch heute bauen sehr viele Leute mit üblen Bauteilen Geräte wie Fernseher. Nur muss man sich dazu nicht einmal auf üble Elkos verlegen, auch die Firmware kann nun Übelkeit erregen, und zwar bei jedem hoffnungsvollen Update erneut.
Uwe S. schrieb: > Ihr werdet wie immer anderer Meinung sein. Aber das liegt nur am > nächsten riesigen Problem, namentlich dem lebenslangen Selbstbetrug und > der grenzenlosen Selbstüberschätzung. Wenn andere immer anderer Meinung sind, macht es ja evtl. Sinn, mal die eigene zu überprüfen?
Programmierer schrieb: > Finde ich großartig, dadurch ist Python-Code immer korrekt > eingerückt und lesbar. und C&P funktioniert einfach oft nicht mehr über verschiedene Texte :) Das zwingt natürlich zum Lernen! (prx) A. K. schrieb: > wie > Fernseher früher wurde halt an Röhren gewackelt und heute pauschal alle Elkos gewechselt :)))
:
Bearbeitet durch User
Joachim B. schrieb: > früher wurde halt an Röhren gewackelt und heute pauschal alle Elkos > gewechselt :))) ROFL... wie wahr!
Hallo, Peter D. schrieb: > Assembler ist, wenn man mit der Handsäge einen Baum fällt. > Compiler ist, wenn man einen Harvester nimmt. > Das eine ist mühsam und kraftraubend, das andere ist effizient und > nachhaltig. Kommt auf die Größe des Baumes an. rhf
https://flatassembler.net/download.php Ganz unten auf der Seite findest Du eine Version FASMARM speziell für ARM Prozessoren. Alternativ-Projekte sollte man immer unterstützen :-) c-hater schrieb: > Und das ist die freche Lüge, die die C-only-Apologeten immer wieder > verbreiten. Es ist und bleibt aber eine LÜGE. das ist richtig und gerade die Geschwindigkeit ist nun mal der Vorteil von Assembler. Das muß man leider auch wiederholen, weil es heutzutage genug Leute gibt, die jede Lüge am Ende glauben. Natürlich ist auch klar, daß aufgrund der Schwierigkeit der Programmierung sich sehr schnell Grenzen auftauen ... deshalb gibt es ja unterschiedliche Programmiersprachen. Für gewerbliche Programmierung ist somit Assembler in der Regel absolut ungeeignet ... aber es gibt ja auch noch den Spaß-Faktor ?! Ansonsten wäre jede Freizeit & Hobby-Aktivität sinnlos rein wirtschaftlich gesehen.
:
Bearbeitet durch User
dunky schrieb: > Wer mir im Berufsumfeld damit ankommt und einen Mikrocontroller komplett > in ASM programmiert...den würde ich vom Hof jagen Ich hätte auch ein unbefriedigendes Gefühl, wenn ich wüßte, daß einen Tag nach der Rente sämtlicher unwartbarer Assemblercode in dev/null landet. Man will doch lieber was bleibendes hinterlassen.
Hatten wir diese Diskussion nicht schon gefühlt 0x3E8 mal?
Wolfgang R. schrieb: > Hatten wir diese Diskussion nicht schon gefühlt 0x3E8 mal? Ich dachte, es wäre die selbe 4E4. :D
Uwe S. schrieb: > Geschweige denn, einen Fernseher, so wie es früher diverse Leute getan > haben. Und zwar mit üblen Bauteilen! Wenn ich mir meinen ersten DUAL CD120 CD-Player so ansehe, dann war das ein wahres Meisterwerk aus der Feinwerktechnik-Werkstatt. Das war absolutes mechanisches High-End. Die heutigen Spritzgussplastiklaufwerke sind da mit Sicherheit weit "üblere" Bauteile. Und trotzdem können die billigen Plastikdinger CDs abspielen, wo ich auf dem alten DUAL-Player nur "kritzkratzkreischbritzelbritzel" herausbekomme. Im Rückblick sich mag das, was früher gemacht wurde, romantisch gesehen als große Denkleistung darstellen. Es war aber eben einfach Stand der Technik, die sich in den meisten Fällen durch simples ingenierumäßiges Vorgehen weiterentwickelt hat.
Peter D. schrieb: > Man will doch lieber was bleibendes hinterlassen. Man hinterläßt wahrscheinlich genug blebendes, was andere zu Grabe tragen müssen. Da muss man nicht noch einen weiteren Misthaufen mit Assembler eröffnen um seine Kollegen zu ärgern(wobei man das manchmal sicher auch will :) )
Peter D. schrieb: > Man will doch lieber was bleibendes hinterlassen. Deswegen sammle ich Elektroschrott und alte Rechenmaschinen... das wird ein Spaß für die Nachkommen... ;-)
Lothar M. schrieb: > Es war aber eben einfach > Stand der Technik, die sich in den meisten Fällen durch simples > ingenierumäßiges Vorgehen weiterentwickelt hat. echt, wo hat sich der Markt großflächig vom schmierenden sich auflösenden Riemen verabschiedet? Der Dual 701 dd Plattenspieler (von 1975) war innovativ und trotzdem gab und gibt es viel mehr Riemenantriebe die heute Schrott sind. Mein 701 spielt noch immer 45 Jahre später. https://www.hifi-wiki.de/index.php/Dual_CS_701 http://www.hifimuseum.de/der-dual-701.html einzige Fehler jetzt Silikondämpfer tut nicht mehr, Glimmleuchte ist dunkel! Das war es aber auch.
:
Bearbeitet durch User
Für die Freunde der Assemblerprogrammierung sei angemerkt, dass eine ganz große Renaissance des direkt erstellten Maschinencodes wieder bevor steht. Die QCASM, der Quanten-Computer-Assembler Entwicklungen stehen an. Aber die Zeitspanne bis fast nur noch in höheren Programmiersprachen für die QC programmiert wird, wird deutlich weniger Jahre sein.
Lothar M. schrieb: > Stand der Technik, die sich in den meisten Fällen durch simples > ingenierumäßiges Vorgehen weiterentwickelt hat. hört man noch was von fuzzy Logik?
Zum Thema Interfaces in Java. Stefan ⛄ F. schrieb: > Programmierer schrieb: >> In Java macht man es auch nur wenn man es explizit braucht. > > Dort wo ich arbeite (und vorher und auch davor arbeitete) leider immer. > Wenn du dort irgendeine Klasse ohne Interface schreibst, wirft man dir > vor, ein schlechter Programmierer zu sein. > > Alles muss austauschbar und wiederverwendbar sein, als wäre es eine > öffentliche Library. Selbst wenn sonnenklar ist, dass es von dieser > einen Klasse never ever mehr als eine Variante geben wird und diese > niemals veröffentlicht wird. > > Dieses Pattern gehört (warum auch immer) unter Java Entwicklern zum > guten Ton. Ich halte es für schlechten Stil, ja sogar falsch. Es ist unnötig, vergrößert die Codebasis, fügt Redundanz hinzu und erschwert die Wartbarkeit (wenn auch, dank der heutigen Tools, nur geringfügig). Zudem verführt es dazu, bei den Zugriffsmodifikatoren nachlässig zu sein, weil man das wirklich öffentliche eh nochmal im Interface freigibt. Ich halte dieses Anti-Pattern für einen Cargo-Kult, der mutmaßlich von ehemaligen C-Programmierern nach java gebracht wurde. Es ist ein weiter Weg, der zwischen dem "ich krieg alles hin" und der idiomatischen Sprachbeherrschung, also der Nutzung so, wie es der Sprache entspricht, liegt. Es gibt den bösen Spruch "Ein C-Programmierer kann in jeder Sprache C programmieren." Ein Funken Wahrheit ist dran. (Ich habe beruflich ein paar Jahre Software entwickelt, u.a. in Java, C, C++, C# und ein paar hässlicheren Sprachen, weiterhin viele Tausend Zeilen Code auditiert. In keiner dieser Sprachen würde ich mich als Experten bezeichnen. Aber dass es diese sprach-kulturellen Unterschiede gibt, und dass auch erfahrene Programmierer nicht immer elegant und dem Stil der Sprache angemessen programmieren, da bin ich mir sicher.)
Wolfgang R. schrieb: > Hatten wir diese Diskussion nicht schon gefühlt 0x3E8 mal? Blick in die Zukunft: Sie wird auch solange anhalten, wie es Menschen und Computersprachen gibt. Arbeitshypothese: Aus der Vehemenz, mit der sie geführt wird, kann man direkt die Borniertheit und Intoleranz der Teilnehmer ableiten.
Joachim B. schrieb: > hört man noch was von fuzzy Logik? Natürlich hört man davon noch einiges, aber nur nicht mehr als Hype. Als der Hype anfing, war das schon ein alter Hut, der schon über dreißig Jahre alt war. Jetzt sind es schon fast rund sechzig Jahre.
Joachim B. schrieb: > wo? Dort wo es hingehört, nähmlich unter den Grundlagen der Regelungstechnik als eine Spielart verschiedener Regler.
Dieter D. schrieb: > Joachim B. schrieb: >> wo? > > Dort wo es hingehört, nähmlich unter den Grundlagen der Regelungstechnik > als eine Spielart verschiedener Regler. jedenfalls unter üblichen Sprachsteuerungen wird es wohl kaum verwendet, die werden gefühlt eher schlechter als besser. Siehe alle Tests mit Sprachsteuerungen im PKW.
Joachim B. schrieb: > jedenfalls unter üblichen Sprachsteuerungen wird es wohl kaum verwendet, > die werden gefühlt eher schlechter als besser. Die Spracherkennung basiert auf einer Analyse mit Algorithmen und künstlichen neuronalen Netzen. Fuzzy-Anteile finden sich in der Regelung für die Pegelanpassung der Lautstärken der einzelnen Frequenzabschnitte des Spektrums. Also befindet sich das nur in der Vorverarbeitung der Signaldaten. Danach sind erst die Module der Spracherkennung an der Reihe im Datenfluss.
:
Bearbeitet durch User
Moin schrieb: > Also ich finde mit Assembler spart man sich den Haufen Text (der auch > noch weit in die Tiefe referenziert) von zB. C++. :D Schreib doch gleich Hex-Code, das ist bestimmt noch kürzer als Assembler-Quelltext! ;D
Hier ein Vergleich von Yalu & Moby: Beitrag "Re: C versus Assembler->Performance" Der Der Hand-Assembler war weder kürzer noch sicher.
Stefan ⛄ F. schrieb: > Da kann der doch nichts > für. Jesus war auch nicht freiwillig der Messias. Hat jemand die erforderlichenen Teile für ein Holzkreuz? Nägel hab ich noch... :-) Robert
Ich habe auf 8086 und AVR Assembler programmiert. Auf dem 8086 sogar teilweise die Umsetzung der Codegenerierung. Fuer einen 6502 habe ich einen Disassembler geschrieben, da wir fuer ein Reverseengineering the Source nicht hatten. ASM hatte damals einen Zweck und war lehrreich und interessant. Ohne Anwendung schlage ich einen einfachen Controller vor, zB einen AVR.
Stefan ⛄ F. schrieb: > Programmierer schrieb: >> In Java braucht man schlicht keine >> Header und das ist enorm praktisch. > > Aber nur, wenn die Klassen Open-Source sind. Was im Java Umfeld > zugegebenermaßen der Regelfall ist - außer bei SAP, soweit ich weiß. Bei Java steckt im .class File alle Info, die man braucht, um die darin enthaltenen Klassen/Interfaces zu benutzen. Alles was public deklariert wurde, steht dort mit Klarnamen drin. Was fehlt ist nur die Source-Darstellung der Implementierung und Details zu den nur intern verwendeten Namen. Wäre das anders, hätten der/die Class-Loader echte Probleme.
Evtl. sollte man hier ein für alle mal zwischen Beruf & Hobby unterscheiden. Wenn hier jemand Hobbymäßig Assembler programmieren will...gerne nur zu. Ist sicher lehrreich. Man arbeitet eher alleine dran und kann es so machen wie man will. Kein Ding. Im Beruf arbeiten meist mehrere Leute an Software. Es muss dokumentiert werden, man muss sich in unterschiedliche Stile eindenken usw usw. Dazu Zeitstress und einige der Dinge sind auch eher unliebsam bzw. werden gerne hintenangestellt. Auch wenn sie wichtig sind und sich langfristig immer rächen, wenn man drauf scheisst. X Leute fummeln im lauf der Jahre etwas zurecht...teilweise ohne den Überblick zu haben was die Software in allen Details macht. Teils ist Doku veraltet oder nicht mehr da. Leute haben das Unternehmen verlassen, gepflegt wurde vieles nicht unbedingt etc etc Ich muss mich hier gerade durch Code wühlen wo in den Kommentaren etwas von 1996 dran steht. Ich schicke Stossgebete gen Himmel das es kein Assembler Code ist... Da können einige ihre Kriegsgeschichten aus den 80ern mal Stecken lassen. Ja es waren andere Zeiten und ich finde es beachtlich was da geleistet wurde. Trotzdem freut man sich heute, wenn man mit dieser alten Gammelscheisse nix mehr am Hut. Da ist es Schlimm genug wenn man sich mit uraltmist aus den 90ern rumplagen darf
Bastler schrieb: > Ich hoffe dass sich hier ein Paar von den alten Hasen finden lassen die > vielleicht bereit sind ein bisschen was von ihrem Wissen weiterzugeben. Zuse ist leider schon gestorben. mfg Klaus
Carl D. schrieb: > Bei Java steckt im .class File alle Info, die man braucht, um die darin > enthaltenen Klassen/Interfaces zu benutzen. Nein, die Doku fehlt.
A. B. schrieb: > Trotzdem freut man sich heute, wenn man mit dieser > alten Gammelscheisse nix mehr am Hut. Da ist es Schlimm genug wenn man > sich mit uraltmist aus den 90ern rumplagen darf Ist halt alles relativ und auch der TO hat sicher nicht an (uns) Opas aus den 70/80ern gedacht, als er nach alten Hasen verlangt hat. Außerdem hat es die "Assembler-Cracks" so wohl nicht gegeben. Es gab Leute, die auf Rechnern Programmiert haben und das kaum in Assembler und es gab Leute, die auf - aus heutiger Sicht - lächerlich "kleinen, in alles Bereichen eingeschränkten" Controllern gearbeitet haben und aus der Not, um buchstäblich jedes Bit kämpfen zu müssen, eine Tugend gemacht haben. Von daher ist z.B. der Begriff "selbstmodifizierender Code" gekommen. Natürlich gab es da auch Spezies, die problemlos Oktal-Zahlen schreiben und lesen konnten...aber wie gesagt, alles mehr aus Not. Viele meiner früheren Kollegen haben förmlich nach so etwas wie einer Hochsprache für Controller geschrien und als es endlich Pascal-Compiler für Z80 ab, da war die Freude schon groß! Gruß Rainer
Bei dem laut Nachrichten beschriebenen Schadensbild liegt es nahe das hier eine Organisation einige Spezialistenkreise beteiligt haben müßte, die auf der Ebene der Maschinensprachen (Assembler) fit waren und es noch sind. https://www.tagesschau.de/ausland/usa-cyberangriff-101.html
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Carl D. schrieb: >> Bei Java steckt im .class File alle Info, die man braucht, um die darin >> enthaltenen Klassen/Interfaces zu benutzen. > > Nein, die Doku fehlt. Naja, das Äquivalent zur .class ist eben die Kombination .h und .a/.lib/.<OS-spezifisch>. Es ging mir um das technische Minimum, um externen Code nutzen zu können. Ob in der .h sinnvolle Doku steht, hängt vom Schreibenden und vom Leser ab. Wäre sicher lustig, wenn man nur dann erfolgreich Software bauen könnte, wenn man die Doku aller beteilgten Komponenten gelesen hätte. Das wäre das Ende der Cut&Paste-Programmierung. Genauso wäre es lustig, wenn die Schnittstelle eines "Moduls" jedesmal so überraschend anders wär, daß man (trotz entsprechender Erfahrung) ohne Doku nicht ahnen könnte, wie das funktioniert. Professionell mag man Doku brauchen, weil es wirklich neu ist, weil es entsprechende Regularien gibt, weil man eine Ausrede braucht, warum was nicht geht ("die Doku fehlt/ist falsch/lückenhaft). Hier ist aber Hobby und da zieht manches davon nicht.
Dieter D. schrieb: > Bei dem laut Nachrichten beschriebenen Schadensbild liegt es nahe das > hier eine Organisation einige Spezialistenkreise beteiligt haben müßte, > die auf der Ebene der Maschinensprachen (Assembler) fit waren und es > noch sind. > https://www.tagesschau.de/ausland/usa-cyberangriff-101.html Es könnte auch ganz anders sein - Fehler in "eigenen Systemen" anderen in die Schuhe schieben zu wollen. Passt aber hier nicht ganz zum Thema.
Ob das zum Fall in den Nachrichten passt oder nicht: Um als Hacker Bugs auszunutzen sind Lowlevel-Kenntnisse ungemein hilfreich. Wobei das bei Assembler nicht aufhört, das geht mitunter auch runter in Maschinencode, beispielsweise wenn Operanden von Befehlen als Opcodes genutzt werden. Return oriented programming ist auch nicht so richtig compilertauglich, auch wenn ich mir dabei vereinfachende layers vorstellen kann. Natürlich gibt es diese Leute. Nur ist das ein völlig anderes Genre als die Programmierung kleiner Mikrocontroller. Und es hat mit der Frage, ob man Hochsprachen Scheisse findet und Assembler vergöttert, herzlich wenig zu tun.
(prx) A. K. schrieb: > Um als Hacker Bugs auszunutzen sind Lowlevel-Kenntnisse > ungemein hilfreich. [...] Natürlich gibt es diese Leute. > Nur ist das ein völlig anderes Genre als die Programmierung > kleiner Mikrocontroller. Und es hat mit der Frage, ob man > Hochsprachen Scheisse findet und Assembler vergöttert, > herzlich wenig zu tun. Naja, bei "Assembler vergöttern" steht ja die Behauptung im Raum, es ließen sich nur mittels Assembler WIRKLICH laufzeitoptimale Programme erstellen. Das mag zwar auf Mikrocontroller einigermaßen zutreffen, also auf Maschinen ohne Cache und mit in-order-Architektur; auf alles PC-ähnliche jedoch trifft es m.E. nicht zu. Ich mache gerade die interessante Erfahrung, dass eine mundgeklöppelte Assemblerroutine von einer VIEL einfacheren Hochsprachen-Routine deutlich (mehr als Faktor Zwei) geschlagen wird, weil letztere besser an das Verhalten des Cache angepasst ist -- die wesentlich komplizierteren Adressrechnungen, die dafür notwendig sind, fallen laufzeitmäßig praktisch nicht ins Gewicht. Es ist ungewohnt, wenn nicht die Befehlsausführungszeit dominiert, sondern die Zugriffszeit auf die Daten.
Egon D. schrieb: > Das mag zwar auf Mikrocontroller einigermaßen zutreffen, > also auf Maschinen ohne Cache und mit in-order-Architektur; > auf alles PC-ähnliche jedoch trifft es m.E. nicht zu. In dem Video, das hier letzthin verlinkt wurde, ist ein schönes Beispiel drin. Der Compiler weiss, dass ein bestimmter Befehl eine nicht offensichtliche Abhängigkeit hat, die auch nicht klar dokumentiert ist. Also packt er einen völlig unnötig wirkenden Dummy-Befehl davor, und schwupps, schon rennt die Kiste. In dem Fall reicht es, wenn einer das weiss. Nämlich derjenige, der sowas in den Compiler einbaut. Der Rest der Welt wundert sich höchstens, beim Blick in den erzeugten Code. Um solche Effekte zu verstehen, benötigt man Einblick in die OOO Implementierung von Prozessoren. Assembler-Kenntnisse helfen dabei nicht.
:
Bearbeitet durch User
Vor langer Zeit bin ich mal einem ähnlich bizarren Effekt begegnet, wie in dem Video. Wievielen Leuten, die x86 Assembler verstehen, ist klar, dass die dynamischen Rotate-Befehle bei CL=0 abhängig von der CPU ein völlig anderes Laufzeitverhalten haben können, als bei anderen Werten? Blick in die Doku hilft da nicht wirklich. Eigentlich erwartet man das gleiche Verhalten bei allen Werten von CL, seit die ALUs das nicht mehr bitweise machen. Banaler Hintergrund ist die Implementierung auf dem ollen 8086/88 mit Iteration per Microcode. Mit jeder Iteration wurde das betreffende Bit ins Carry geschoben. Bei 0 blieb folglich das Carry-Flag unverändert. Seither ist diese Eigenschaft in der x86 Definition eingebrannt. In der Implementierung von Prozessoren hatten nun alle Prozessorbauer ab Pentium Pro und AMD K5 die Aufgabe, sich dazu was einfallen zu lassen. Macht man ROR x,CL abhängig vom vorherigen Zustand des Carry-Flags, funktioniert das zwar problemlos, aber beispielsweise mancher Crypto-Code, der diese Befehle intensiv verwendet, wird durch diese Abhängigkeit bös ausgebremst. Oder man erspart ihm spekulativ die Abhängigkeit vom vorherigen Carry. Liegt er damit aber falsch, gibts den gleichen Effekt wie bei einer falschen Sprungvorhersage: Der Prozessor verwirft alle zwischenzeitlichen Ergebnisse und setzt neu auf. Was eine übel teure Sache ist.
:
Bearbeitet durch User
Eigentlich wollte ich ein Haufen Zitate in meinen Post machen, aber das lohnt nicht wirklich. Behauptungen wie „Assembler ist immer langsamer“, „Assembler ist tot“ ist genauso falsch wie „Compiler liefern schlechten Code“. Es sind unbegründete und undifferenzierte Verallgemeinerungen. Und ehrlich, nirgends aus den Aufzählungen der Fürsprecher kann ich rauslesen, dass das ASM-Proggen deren Lebenstraum wäre. Jeder der schon einmal an die Grenzen von Ressourcen gestoßen ist, Speicher (Flash oder RAM), Geschwindigkeit etc. und damit einhergehend bestehende Produkte oder Projekte im Weiterkommen behindert werden (große bzw. grundlegenden Änderungen, Abbruch), hat mit ASM eine Option. Um jetzt mal bissel messbar zu werden: Warum sind denn in den Kühlschränken, Waschmaschinen und Trocknern nicht die „fetten“ ARMs verlötet, sondern „alte“ und ressourcentechnisch eher schmale Chips? Und wenn ich 1000-fach verbaute Hardware habe und ein cooles AddOn platzieren kann mit dem der Kram nicht auf dem Elektroschrott landet, dann tue ich es. Und im Privaten nicht anders: Wenn ich ein weiteres Protokoll für mein IRMP-Monster in das Teil reinkriege, dann schreibe ich auch mal drei Zeilen ASM. Ach ja: Ich hätte gerne von den „ich beherrsche meinen Compiler viel besser als Du“ Entwicklern schon gern gewusst, wie konkret sich Register reservieren lassen - und bitte seid nicht so weltfremd und schränkt das Ganze darauf ein, dass man keine LIBs verwenden darf... Und bitte nicht damit rausreden, das wäre ein Sonderfall. Also ich lerne gerne Neues.
Uwe D. schrieb: > Um jetzt mal bissel messbar zu werden: Warum sind denn in den > Kühlschränken, Waschmaschinen und Trocknern nicht die „fetten“ ARMs > verlötet, sondern „alte“ und ressourcentechnisch eher schmale Chips? Warum kennt fast jeder bei seinem Smart-TV irgendwelche Fehlfunktionen? Je weniger Code, umso weniger Fehler. Ich bin überhaupt kein Fan unnötig komplexer Elektronik im Haushalt.
Jens G. schrieb: > C-Code sieht von Hause übersichtlicher aus und lässt sich besser warten. > Ich bin Hobbyprogrammierer geblieben - Assembler möchte ich eher > vermeiden. Deshalb setze ich auf Arduino und schreibe Quellcode, das man > später auch mal auf anderen Prozessoren oder Umgebungen verwenden kann. > > Wer etwas in Assembler macht kann bei einem Prozessorwechsel die Mühe > seiner Arbeit wegwerfen - so einfach ist das. Das mit der Wartung bzw.Pflege stimmt. Sofern der Programmierer den Code kommentiert und dokumentiert hat. Ich habe vor Jahren ein paar Programme Fremdprogrammieren lassen. Spätere Änderungen brachten dann die Ernüchterung. Fast nichts erklärt. Antworten wie "das kann man aus dem Code rauslesen" sind Blödsinn. Man braucht Wochen, um solche Programme zu analysieren (was hat sich der dabei gedacht?). Aus Erfahrung sind 99% der C-Programmierer zu faul zu dokumentieren. Beim Assembler ist das Pflicht, bei C wird es gerne mal "vergessen". Das Argument mit der Portierbarkeit ist oft genannt und gut gemeint. Aber mal ehrlich: Wie viele Projekte werden portiert? Ich kenne keins und hatte in 30 Jahren kein einziges. Außerdem: Wenn Du ein Programm z.B. für einen AVR auf einen ARM portieren willst, dann hast Du 90 Prozent mit der Neuprogrammierung der Peripherie zu tun. Dabei meine ich natürlich nicht die banalen Standardfunktionen ala Arduino wie DigitalWrite usw. Der Aufwand zur Umprogrammierung der Peripherie ist so groß, da kann man die paar restlichen Funktionen auch gleich neu schreiben. Sind so meine Erfahrungen der letzten 30 Jahre. Und ja: Inline-Assembler setze ich relativ oft ein. Z.B. bei Interruptfunktionen wo es auf Laufzeit ankommt. Dabei ist der Geschwindigkeitsgewinn (bei GCC) immer so 30-50%. Bei einem 300MHz-Kontroller wird es schwierig "eben einen schnelleren" zu nehmen. Ich habe 1989 mit Assembler 8048 angefangen. 1991 dann 8051 ausschließlich in Assembler. 1998 78K3 16Bit auch rein in Assembler. 2000 M16C in Assembler und AVR in C. 2007 ARM7 in C 2012 Cortex M3 und 2016 Cortex M7 Gruß Joachim
Joachim M. schrieb: > Das Argument mit der Portierbarkeit ist oft genannt und gut gemeint. > Aber mal ehrlich: Wie viele Projekte werden portiert? Ich kenne keins > und hatte in 30 Jahren kein einziges. Nunja... Da lassen sich als Gegenbeispiel die Arduino Libraries/Programme aufführen. Welche sich oft unverändert auf jeglicher Hardwarewplattform ausführen lassen, für die es eine Boarddefinition gibt. Joachim M. schrieb: > dann hast Du 90 Prozent mit der Neuprogrammierung der > Peripherie zu tun. Dabei meine ich natürlich nicht die banalen > Standardfunktionen ala Arduino wie DigitalWrite usw. Es ist schon klar, dass es ein HAL für jede konkrete Plattform geben muss, um dem Problem aus dem Wege zu gehen. Wenn man allerdings Hardwarezugriffe in die Anwendung einflechtet, ohne eine Abstraktionsschicht dazwischen, dann ja, dann hat man die von dir genannten Probleme. Das ist dann aber auch eine Frikadelle, die man sich selber (oder der Vorgänger) ans Knie genagelt hat.
Arduino Fanboy D. schrieb: > Wenn man allerdings Hardwarezugriffe in die Anwendung einflechtet, ohne > eine Abstraktionsschicht dazwischen, dann ja, dann hat man die von dir > genannten Probleme. > > Das ist dann aber auch eine Frikadelle, die man sich selber (oder der > Vorgänger) ans Knie genagelt hat. Naja, Dein Name sagt ja aus, womit Du Dich beschäftigst. Sorry, soll nicht abwertend klingen, aber Arduino ist meiner Meinung nach eher was für Hobbybastler. Bei mir waren Mikrokontrolleranwendungen meistens sehr zeitkritisch. Da kann man um z.B. einen Port zu setzen, nicht noch "Abstraktionsschichten" drüberbasteln. Um ein Bit an einen Port zu schreiben, kann man sich oft diesen Arduino-Müll nicht erlauben:
1 | void digitalWrite(uint8_t pin, uint8_t val) |
2 | {
|
3 | if (port == NOT_A_PIN) return; |
4 | if (timer != NOT_ON_TIMER) turnOffPWM(timer); |
5 | out = portOutputRegister(port); |
6 | uint8_t oldSREG = SREG; |
7 | cli(); |
8 | if (val == LOW) { |
9 | *out &= ~bit; |
10 | } else { |
11 | *out |= bit; |
12 | }
|
13 | SREG = oldSREG; |
14 | }
|
4 "ifs" wegen einem Portzugriff sind eben in "richtigen" Anwendungen ein no-go. Wenn man natürlich nur LEDs blinken lässt oder irgendwelchen Schnickschnack, dann ist es egal, wie lange es dauert, bis ein Kommando an der Peripherie "ankommt". Wer natürlich nichts mit Echtzeit zu tun hat, der kann das ganze über Libs oder Treiber usw. machen. Gruß Joachim
Joachim M. schrieb: > Bei mir waren Mikrokontrolleranwendungen meistens sehr zeitkritisch. Da > kann man um z.B. einen Port zu setzen, nicht noch > "Abstraktionsschichten" drüberbasteln. > Um ein Bit an einen Port zu schreiben, kann man sich oft diesen > Arduino-Müll nicht erlauben:void digitalWrite(uint8_t pin, uint8_t val) ... > 4 "ifs" wegen einem Portzugriff sind eben in "richtigen" Anwendungen ein > no-go. Ich kenne mich mit Arduino auch nicht aus. Aber wenn ich den Code sehe, dann frage ich mich: wie viel davon ist nach dem compilieren noch übrig? Es ist durchaus denkbar, dass ein optimierender Compiler das größtenteils eliminiert. Selbst die Fallunterschiedung (| vs &~) je nach dem, ob das Bit gesetzt oder gelöscht werden muss, kann u.U. entfallen, wenn der compiler sieht, dass immer gesetzt oder gelöscht wird.
:
Bearbeitet durch User
Joachim M. schrieb: > 4 "ifs" wegen einem Portzugriff sind eben in "richtigen" Anwendungen ein > no-go. Ja schon. Andererseits sind viele Arduino Nutzer froh, dass es nicht in einer Scriptsprache programmiert werden muss, die nochmal um ein vielfaches langsamer ist.
Tilo R. schrieb: > Ich kenne mich mit Arduino auch nicht aus. Aber wenn ich den Code sehe, > dann frage ich mich: wie viel davon ist nach dem compilieren noch übrig? Viel, das zeigen diverse Performance-Tests die neugierige Leute veröffentlicht haben. Ich erinnere mich an 70 Taktzyklen für einen simplen digitalWrite() Aufruf. Ich hoffe dass es inzwischen besser geworden ist. Gerade digitalWrite() halte ich für völlig überflüssig. Da hätte man wesentlich kompaktere Funktionen oder Makros verwenden können, die solche Aufrufe auf einen einzigen Assembler Befehl reduziert hätten. Man müsste PC5 dann einfach nur so nennen und nicht "Pin 5". Diese Abstraktion hilft niemanden, denke ich.
Egon D. schrieb: > Ich mache gerade die interessante Erfahrung, dass eine > mundgeklöppelte Assemblerroutine von einer VIEL > einfacheren Hochsprachen-Routine deutlich (mehr als Faktor > Zwei) geschlagen wird, weil letztere besser an das > Verhalten des Cache angepasst ist .... Im Bereich der Code-Opimierung, so dass Hochsprachen-Compiler (und auch Interpreter) sehr effektive Ergebnisse im Gesamtsystem erbringen, sind heute die Genies der Maschinensprachen und Assembler zu finden. Die Anforderung nach Vielseitigkeit (Fremdwort Diversität) gehört da bereits dazu.
Joachim M. schrieb: > Wenn Du ein Programm z.B. für einen AVR auf einen ARM > portieren willst, dann hast Du 90 Prozent mit der Neuprogrammierung der > Peripherie zu tun. Ich habe es noch nie erlebt, daß ein Programmcode zu 90% aus Hardwarezugriffen besteht. Dagegen ist es bei mir typisch, daß >90% Statemaschinen, Parser, Protokolle, Berechnungen, Tabellen, Regelkreise usw. sind. Es sind also <10% anzupassen, wenn man einen anderen MC nimmt (Schnittstellen, Timer, ADC/DAC, IO-Pins).
Joachim M. schrieb: > Aber mal ehrlich: Wie viele Projekte werden portiert? Ich kenne keins > und hatte in 30 Jahren kein einziges. Das ist nicht der Punkt. Man spart einfach viel Zeit und Fehlersuche, wenn man seine Libs weiter verwenden kann (LCD, Entprellen, Encoder, Scheduler, Parser, PID-Regelung, ...).
Uwe D. schrieb: > Warum sind denn in den Kühlschränken, Waschmaschinen und Trocknern nicht > die „fetten“ ARMs verlötet, sondern „alte“ und ressourcentechnisch eher > schmale Chips? Weil vieles davon da seit zig Jahren drin ist. Wenn die Waschmaschine selber das Waschmittel bestellt, den Verschmutzungsgrad analysiert und im Fenster YouTube abspielt, könnte sich das vielleicht ändern.
Und wer macht jetzt endlich den geklauften Roller schneller?
Peter D. schrieb: > Ich habe es noch nie erlebt, daß ein Programmcode zu 90% aus > Hardwarezugriffen besteht. > Dagegen ist es bei mir typisch, daß >90% Statemaschinen, Parser, > Protokolle, Berechnungen, Tabellen, Regelkreise usw. sind. Es sind also > <10% anzupassen, wenn man einen anderen MC nimmt (Schnittstellen, Timer, > ADC/DAC, IO-Pins). Ich meine nicht 90 Prozent Code, sondern den Zeitaufwand zur Portierung der Peripheriefunktionen. Klar - wenn man das Teil nur als Rechengehirn benutzt und außer ein paar Standardschnittstellen UART und Co nichts braucht, dann ist es anders. Aber wenn man wirklich die Spezialfeatures der Kontroller nutzt, wird ein Wechsel sehr arbeitsintensiv. Als Beispiel nenne ich mal die mächtigen Timer der SAM3X/SAMS7 Kontroller. Da lassen sich sehr komplexe Funktionen damit bauen, die fast Null Laufzeit in der Anwendung benötigen. Die Timer sind verkettet, triggern sich gegenseitig und lösen Events aus, z.B. eine SPI-Übertragung per DMA. Solche Dinge kann man nur "zu Fuß" programmieren. Und es ist extrem schwierig genau die gleichen Funktionen auf einem x-beliebigen anderen Kontroller umzusetzen. Peter D. schrieb: > Man spart einfach viel Zeit und Fehlersuche, > wenn man seine Libs weiter verwenden kann (LCD, Entprellen, Encoder, > Scheduler, Parser, PID-Regelung, ...). Schon klar. Allerdings hatte ich schon früher in Assembler viele solche fertigen Module wie LCD, Tastatur oder auch Rechenfunktionen (Festkommaarithmetik) programmiert. Das Benutzen auf einem anderen Kontrollertyp war nur Fleissarbeit. Abtippen der Befehle mit der entsprechend anderen Syntax. Die Assemblerbefehle sind ja weitgehend identisch. Der Entwicklungsaufwand für die jeweilige Funktion musste nur einmal geleistet werden. Dass alles verloren war, wie hier im Thread geäußert, kann ich nicht nachvollziehen. Natürlich kostet es schon mehr Arbeit als nur eine Zeile C zu schreiben. Gruß Joachim
Stefan ⛄ F. schrieb: > Und wer macht jetzt endlich den geklauften Roller schneller? Der, der die Benutzung von Hochsprachen rundweg ablehnt, denn irgendwie muß er die verplemperte Zeit wieder reinholen.
(prx) A. K. schrieb: > Uwe D. schrieb: >> Warum sind denn in den Kühlschränken, Waschmaschinen und Trocknern nicht >> die „fetten“ ARMs verlötet, sondern „alte“ und ressourcentechnisch eher >> schmale Chips? > > Weil vieles davon da seit zig Jahren drin ist. Wenn die Waschmaschine > selber das Waschmittel bestellt, den Verschmutzungsgrad analysiert und > im Fenster YouTube abspielt, könnte sich das vielleicht ändern. Ja, da hast Du recht - mir ist die auf den Kopf gestellte Kostenpyramide sehr bewusst. Es gibt aus meiner Sicht nicht „die“ Antwort. Es kommt halt auf den konkreten Fall an. Sobald Zeit teuer wird, dann macht neben der besseren Hardware - sofern diese sich problemlos einsetzen lässt - eben die Optimierung des Codes sehr wohl Sinn. Und wenn der Roller „getunt“ werden soll, dann macht der Weg via ASM schon Sinn. Oder der Speicher für Fließkomma nicht mehr reicht.... oder...oder...oder
Carl D. schrieb: >> Und wer macht jetzt endlich den geklauften Roller schneller? > Der, der die Benutzung von Hochsprachen rundweg ablehnt, denn irgendwie > muß er die verplemperte Zeit wieder reinholen. Den habe ich ja schon vorgeschlagen, aber interessanterweise hält er sich aus den Threads von Bastler weitgehend heraus.
Stefan ⛄ F. schrieb: > Tilo R. schrieb: >> Ich kenne mich mit Arduino auch nicht aus. Aber wenn ich den Code sehe, >> dann frage ich mich: wie viel davon ist nach dem compilieren noch übrig? > > Viel, das zeigen diverse Performance-Tests die neugierige Leute > veröffentlicht haben. > > Ich erinnere mich an 70 Taktzyklen für einen simplen digitalWrite() > Aufruf. Ich hoffe dass es inzwischen besser geworden ist. > > Gerade digitalWrite() halte ich für völlig überflüssig. Da hätte man > wesentlich kompaktere Funktionen oder Makros verwenden können, die > solche Aufrufe auf einen einzigen Assembler Befehl reduziert hätten. > > Man müsste PC5 dann einfach nur so nennen und nicht "Pin 5". Diese > Abstraktion hilft niemanden, denke ich. Ja die Arduino Libs sind eher suboptimal umgesetzt. Ich habe mich dort auch küzlich erst mit der gräßlichen "Wire" Bibliothek rumgeärgert. Im Endeffekt hab ichs neu geschrieben mit über 1K Code Ersparniss auf dem AVR. Aber wenn man mit der Sprache richtig umgehen kann, dann man auch C++ Code so schreiben das er sehr effektiv wird und dabei trotzdem lesbar bleibt:
1 | static IOPin<AVR_IO_PB0> RefCapacitor; |
2 | |
3 | void my_func() |
4 | {
|
5 | ...
|
6 | RefCapacitor.setOutput(); |
7 | RefCapacitor.enableOutput(); |
8 | |
9 | RefCapacitor.disableOutput(); |
10 | RefCapacitor.clearOutput(); |
11 | ...
|
12 | }
|
Das faltet der Compiler in genau 4 Instruktionen zusammen. RefCapacitor belegt auch keinen Ram. Der, zugegeben sehr aufgeblähte, Quellcode für die Klassen hier, falls es jemanden Interessiert. (Repo wird nicht mehr gepflegt, bin am Umziehen zu gitlab) https://github.com/amesser/ecpp/blob/master/src/ecpp/HAL/AVR8/IOPort.hpp Manchmal ist C++ aber auch zum Haare raufen, heute hats ne Stunde gedauert bis ich verstanden hab, warum den Compiler meinen Code nicht mochte. Falsch:
1 | if (::std::holds_alternative<::std::monostate>(container_)) |
2 | return &(container_.emplace<Action>(args...)); |
richtig
1 | if (::std::holds_alternative<::std::monostate>(container_)) |
2 | return &(container_.template emplace<Action>(args...)); |
(Wen es interessiert: container_ ist eine von ::std::variant abgeleitete Klasse die selbst ein Template ist, deswegen kann der Compiler nicht erahnen, das emplace() eine Template-Funktion ist und braucht deswegen den extra Hinweis. Die Fehlermeldung von GCC war "expected primary expression instead of >")
Joachim M. schrieb: > Sorry, soll nicht abwertend klingen, aber Arduino ist meiner Meinung > nach eher was für Hobbybastler. Ah guge an, ein "Profibastler". Paß auf was du schreibst, sonst Copy und Paste ich dich, das dir die Ohren schwelen! ;P
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.