Forum: Mikrocontroller und Digitale Elektronik Assembler wo sind eigentlich diese ganzen Genies??


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bastler (Gast)


Lesenswert?

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

:
von Programmierer (Gast)


Lesenswert?

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.

von Udo S. (urschmitt)


Lesenswert?

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
von Birgel (Gast)


Lesenswert?

> ... die RISC´s ...

Grauenhaft.

von Nop (Gast)


Lesenswert?

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.

von Teo D. (teoderix)


Lesenswert?

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!

von Programmierer (Gast)


Lesenswert?

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?

von Cihan S. (cihan_s)


Lesenswert?

Im C64 Forum rennen noch genug rum, die Kunstwerke mit Assembler 
programmieren.

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Lesenswert?

Cihan S. schrieb:
> Im C64 Forum rennen noch genug rum, die Kunstwerke mit Assembler
> programmieren.

Auf 6502 - nicht auf ARM...

von Ein Freund (Gast)


Lesenswert?

Bastler schrieb:
> sonst wäre ich Depp nicht schon so weit gekommen

Wie weit bist Du denn gekommen?

von Nick M. (Gast)


Lesenswert?

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.

von H.Joachim S. (crazyhorse)


Lesenswert?

Das ganze Thema ist (sinnloserweise) regelmässig für einen längeren 
trööt gut. Führt genauso regelmässig zu exakt nichts.

von Wolfgang (Gast)


Lesenswert?

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.

von R. F. (rfr)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Alexander S. (alesi)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

Ich denke, er will immer noch seinen (vermutlich geklauten) 
Elektro-Roller tunen.

von Stefan F. (Gast)


Lesenswert?

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.

von Horst G. (horst_g532)


Lesenswert?

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.

von Teo D. (teoderix)


Lesenswert?

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!

von ACDC (Gast)


Lesenswert?

Teo D. schrieb:
> PS: Nich vergessen hier gests um "Profis", nich um uns Bastlerhonks!

Der TO will offensichtlich irgendwas Häcken.

von Stefan F. (Gast)


Lesenswert?

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.

von leo (Gast)


Lesenswert?

ACDC schrieb:
> Der TO will offensichtlich irgendwas Häcken.

Beitrag "Firmware reverse Engineering Kosten"

leo

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Nick M. (Gast)


Lesenswert?

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.

von Tüftler (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Stefan F. (Gast)


Lesenswert?

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.
von (prx) A. K. (prx)


Lesenswert?

Tüftler schrieb:
> jeder schlägt sich gegenseitig den Schädel ein

Wäre dem wirklich so, wäre recht bald Ruhe. ;-)

von Jobst Q. (joquis)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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

von Nick M. (Gast)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

Jobst Q. schrieb:
> Es ist immer noch das schnellste Betriebssystem

Ja super und DOS ist schneller als Windows. Was sagt das aus? Nichts!

von (prx) A. K. (prx)


Lesenswert?

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.

von Bastler (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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!

von Nick M. (Gast)


Lesenswert?

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!

von Jens G. (jensg)


Lesenswert?

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.

von Bastler (Gast)


Lesenswert?

Nö.

von Stefan F. (Gast)


Lesenswert?

Doch

Beitrag #6514222 wurde von einem Moderator gelöscht.
von Bastler (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Jens G. (jensg)


Lesenswert?

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.

von Bastler (Gast)


Lesenswert?

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

von Teo D. (teoderix)


Lesenswert?

Oje, jetzt hat er auch noch Geheim-Tips.... Ich komm mir grad wieder 
vor wie 10. :D

von Bastler (Gast)


Lesenswert?

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

von Programmierer (Gast)


Lesenswert?

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!

von c-hater (Gast)


Lesenswert?

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

von Carl D. (jcw2)


Lesenswert?

Wenn schon nicht portabel, dann wenigstens zu 100%.
Schon klar.

von Thomas E. (thomase)


Lesenswert?

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.

von Bastler (Gast)


Lesenswert?

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

von Teo D. (teoderix)


Lesenswert?

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

von c-hater (Gast)


Lesenswert?

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

von Carl D. (jcw2)


Lesenswert?

Was muß bloß in der Kindheit (oder auch länger) schief gelaufen sein, um 
so ein Verhalten zu entwickeln.

von Stefan F. (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von goc911 (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Teo D. (teoderix)


Lesenswert?

Carl D. schrieb:
> Was muß bloß in der Kindheit (oder auch länger) schief gelaufen sein, um
> so ein Verhalten zu entwickeln.

Betamax?-/

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von anonymus (Gast)


Lesenswert?

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

von Thomas E. (thomase)


Lesenswert?

c-hater schrieb:
> Ganz einfach: Ich habe viel zu viele Idioten (und ihre Werke) gesehen.
>
> Das ist alles.

Wie? Wohnst du im Spiegelsaal?

von goc911 (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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

von oszi40 (Gast)


Lesenswert?

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?

von J. -. (Gast)


Lesenswert?

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.

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

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

von J. -. (Gast)


Lesenswert?

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 :)

von michael_ (Gast)


Lesenswert?

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.

von Bastler (Gast)


Lesenswert?

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)

von Joachim B. (jar)


Lesenswert?

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

von oszi40 (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von michael_ (Gast)


Lesenswert?

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.

von Markus (Gast)


Lesenswert?

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.

von Percy N. (vox_bovi)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

Mein erster Computer Ende der 70er war der AIM-65 mit 6502 - und schon 
dafür gab es einen Compiler in 8KB ROM.

von michael_ (Gast)


Lesenswert?

(prx) A. K. schrieb:
> gab es einen Compiler in 8KB ROM

Basic?

von (prx) A. K. (prx)


Lesenswert?


: Bearbeitet durch User
von Lothar (Gast)


Lesenswert?

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

von Andreas B. (bitverdreher)


Lesenswert?

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.

von Tretmühe (Gast)


Lesenswert?

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.

von Percy N. (vox_bovi)


Lesenswert?

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
von Andreas B. (bitverdreher)


Lesenswert?

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
von Percy N. (vox_bovi)


Lesenswert?

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
von Chregu (Gast)


Lesenswert?

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!

von (prx) A. K. (prx)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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
von Percy N. (vox_bovi)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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
von Percy N. (vox_bovi)


Lesenswert?

(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
von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

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.
von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Lesenswert?

(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?

von Peter D. (peda)


Lesenswert?

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.

von C. A. Rotwang (Gast)


Lesenswert?

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

von Percy N. (vox_bovi)


Lesenswert?

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
von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Lesenswert?

Percy N. schrieb:
> Nein, Du meinst vermutlich die Zicke azs der Flasche.

Genau die. ;-)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Karl B. (gustav)


Lesenswert?

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
von Stefan F. (Gast)


Lesenswert?

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.

von dunky (Gast)


Lesenswert?

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

von Percy N. (vox_bovi)


Lesenswert?

Es soll Leute geben, die C für einen etwas eigenartigen Assembler 
halten.

von Moin (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.
von (prx) A. K. (prx)


Lesenswert?

(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.
von Erro, dum vivo (Gast)


Lesenswert?

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.
von Teo D. (teoderix)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

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.

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Stefan ⛄ F. schrieb:
> Pythons Syntax ...  Einrückungstiefe und den Leerzeilen
> eine technische Funktion .... ?

Vermutlich waren die Meisten der Phytoner mit Fortran 77 groß geworden.

von Nick M. (Gast)


Lesenswert?

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!

von Stefan F. (Gast)


Lesenswert?

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.

von Uwe S. (bullshit-bingo)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von A. B. (funky)


Lesenswert?

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?

von Joachim B. (jar)


Lesenswert?

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
von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Lesenswert?

Joachim B. schrieb:
> früher wurde halt an Röhren gewackelt und heute pauschal alle Elkos
> gewechselt :)))

ROFL... wie wahr!

von Roland F. (rhf)


Lesenswert?

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

von Robert K. (Firma: Zombieland) (rko)


Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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.

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Lesenswert?

Hatten wir diese Diskussion nicht schon gefühlt 0x3E8 mal?

von Teo D. (teoderix)


Lesenswert?

Wolfgang R. schrieb:
> Hatten wir diese Diskussion nicht schon gefühlt 0x3E8 mal?


Ich dachte, es wäre die selbe 4E4. :D

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von A. B. (funky)


Lesenswert?

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 :) )

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Lesenswert?

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

von Joachim B. (jar)


Lesenswert?

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
von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

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.

von Joachim B. (jar)


Lesenswert?

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?

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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

von Einer K. (Gast)


Lesenswert?

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.

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

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.

von Joachim B. (jar)


Lesenswert?

Dieter D. schrieb:
> Natürlich hört man davon noch einiges

wo?

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Joachim B. schrieb:
> wo?

Dort wo es hingehört, nähmlich unter den Grundlagen der Regelungstechnik 
als eine Spielart verschiedener Regler.

von Joachim B. (jar)


Lesenswert?

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.

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

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
von M.A. S. (mse2)


Lesenswert?

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

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Hier ein Vergleich von Yalu & Moby:

Beitrag "Re: C versus Assembler->Performance"

Der Der Hand-Assembler war weder kürzer noch sicher.

von R. F. (rfr)


Lesenswert?

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

von Purzel H. (hacky)


Lesenswert?

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.

von Carl D. (jcw2)


Lesenswert?

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.

von A. B. (funky)


Lesenswert?

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

von Klaus R. (klara)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

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.

von Rainer V. (a_zip)


Lesenswert?

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

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

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
von Carl D. (jcw2)


Lesenswert?

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.

von Jens G. (jensg)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Egon D. (Gast)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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
von Uwe D. (monkye)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Joachim M. (jmlaser)


Lesenswert?

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

von Einer K. (Gast)


Lesenswert?

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.

von Joachim M. (jmlaser)


Lesenswert?

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

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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
von Stefan F. (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

Und wer macht jetzt endlich den geklauften Roller schneller?

von Joachim M. (jmlaser)


Lesenswert?

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

von Carl D. (jcw2)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

(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

von Stefan F. (Gast)


Lesenswert?

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.

von Andreas M. (amesser)


Lesenswert?

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 >")

von Teo D. (teoderix)


Lesenswert?

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

von Dennis H. (c-logic) Benutzerseite


Lesenswert?

Wolfgang R. schrieb:
> 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.

Er hat Schraubenzieher gesagt !!!
Teert und federt ihn.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Andreas M. schrieb:
> https://github.com/amesser/ecpp/blob/master/src/ecpp/HAL/AVR8/IOPort.hpp

Der Code ist Zucker um SFR-Adressen wie
1
constexpr volatile uint8_t* pin = &PINB;
usw, was aber kein gültiges C++ ist. Gemeinerweise akzeptiert GCC v5 
solchen Code, aber v6+ quittiert ihn mit einer Fehlermeldung.

> Manchmal ist C++ aber auch zum Haare raufen

+1

von Martin V. (oldmax)


Lesenswert?

Hi
Nun ist es wieder da, diese ewige Diskussion über Programmiersprachen. 
Hier mal meine Meinung dazu:
Gute Programmierer wissen um die Vor- und Nachteile einer jeden Sprache 
und kennen auch den Unterschied zwischen Maschinencode und Assembler. 
Die Halbgaren dürfwen das gern weiter durcheinander werfen, ist ja doch 
egal, aber nur mal so zum Nachdenken
ein Z80 Maschinencode: C3C302  (Hexadezimale Darstellung, real aber
                                11010011
                                11010011
                                00000010 )
Assembler:             jp Main
Main = Adresse  02C3h
Also, 80% der Beiträge sind basierend auf
Ich hab ein bisserl "C" gelernt und erwarte, das alle "C" nachmachen und 
die andere Seite auch mit "Assembler ist ein Zeichen für Experten" einen 
völlig falschen Standpunkt vertreten.
Alles Quatsch! Experten, oder besser Profis wissen um die Vielfalt der 
Sprachen und wenden das an, welches dem zielführend ist.
Außerdem beteiligen sich so wie ich das sehe, nur wenige Profis an 
solchen Diskussionen, weil sie dafür vermutlich keine Zeit haben und 
werden, wenn sie solche teilweise haarsträubenden Beiträge lesen, 
höchstens ein müdes Lächeln übrig haben. Allein schon der Gedanke, 
Profis wären mal eben so in der Lage ein disassembliertes Programm zu 
entschlüsseln, zeigt, wieviel Ahnung da vorhanden ist. Erstens, ein 
disassemblierter Code kann nur aus der Maschinensprache entstammen und 
zweitens ist noch lange nicht gesagt, in welcher Sprache der Code 
ursprünglich entstanden ist. Das, was auf einer Maschine läuft, auch im 
PC und sonstwo auf elektronischen Geräten ist, "Trara", Maschinencode. 
Und da sind absolut keine Kommentarzeilen vorhanden.
Man kann, und das ist sehr zeitraubend, Maschinencode disassemblieren 
und mit viel Akrebie versuchen, den Verlauf des Programmes 
nachzuvollziehen. Spätestens aber, wenn ein Programmierer oder Compiler 
aus einer unbekannten Tabelle einen Wert in ein Register kopiert, mit 
Push auf den Stack legt und mit einem Return auf diese Adresse springt, 
ist es mit einem einfachen Lesen von Assemblercode vorbei.
So, und nun tobt euch weiter aus mit dieser völlig nutzlosen Diskussion, 
ob Assemblercode schneller oder "C" übersichtlicher ist.
Gruß oldmax

von Peter D. (peda)


Lesenswert?

Wenn ich mal so an meine Assemblerzeiten zurückdenke, da habe ich auch 
viele Schweinereien gemacht.
Ich hab z.B. gerne konstante Argumente einfach mit DB-Anweisungen hinter 
den Call geschrieben, anstatt umständlich Register laden zu müssen oder 
sie in den Stack zu pushen. Die Unterfunktion mußte dann nur die 
Returnadresse in ein Pointerregister laden und konnte damit bequem die 
Argumente lesen. Und zum Schluß genau hinter das letzte Argument zurück 
springen.
Viel Vergnügen, wenn man sowas wieder disassemblieren will. 
Insbesondere, wenn die Argumentenliste variabel ist.

von Martin V. (oldmax)


Lesenswert?

Hi
Nun ja, von einem Experten in Sachen Controllerprogrammierung bin ich 
weit entfernt, hab aber auch in den 80er Jahren mit einem ZX81 und dem 
Z80 Prozessor erste Schritte in Richtung Programmierung gehabt. Damals 
erhielt ich mit meinen 30 Lenzen auch einen Job an einer Industrieanlage 
mit "Frei programmierbarer Steuerung". Die Anführungsstriche sind 
deshalb, weil frei Programmierbar damals noch nicht ganz so einfach war. 
Da lief noch viel über EProms, die nur bei Anlagenstillstand eingesetzt 
werden konnten und man daher schon sehr genau vorarbeiten mußte, um 
keinen Fehler zu machen. Die waren richtig teuer, an so einer Anlage und 
konnten gern auch mal 5 stellige Kosten bewirken. Die Programmierung war 
eine Art Anweisungsliste, kurz "AWL". Das ich diesen Job u. a. über 35 
Jahre hatte, zeigt, das meine Fehlerquote klein war, auch zur Zeit der 
wirklich frei programmierbaren Steuerungen. In Sachen Programmiersprache 
hab ich dann auch nach Basic Paacal und Datenbanken gemacht. Aber eben 
auch hauptsächlich nur so zum Hobby und Weiterbildung. µC's mache ich 
nur hobbymäßig und wenn man mich ärgert. So hatte ich die letzten zwei 
Arbeitsjahre eine "Rentneruhr" auf meinem Schreibtisch, die im 1/10 
Sekundentakt rückwärts lief, und auf der Anzeige (7 Segment) zur 
richtigen Zeit "PAUSE" oder "FEIErAbENd" anzeigte. Sollte meinen 
Vorgesetzten zeigen, wie schnell die Zeit vergeht und das man mit der 
Einarbeitung eines Nachfolgers nicht allzulange warten sollte. Aber das 
ist Schnee von gestern. Jetzt genieße ich meinen Dauerurlaub.
Tja, die gute alte Zeit.....
gruß oldmax

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Peter D. schrieb:
> Viel Vergnügen, wenn man sowas wieder disassemblieren will.
> Insbesondere, wenn die Argumentenliste variabel ist.

Der erwähnte PL/65 Compiler bestand quasi daraus. So in der Art
   if (expect("goto"))
     emit("jmp ...")
wobei beide Aufrufe ihren String direkt hinter dem Aufruf hatten.

: Bearbeitet durch User
von Yalu X. (yalu) (Moderator)


Lesenswert?

Peter D. schrieb:
> Wenn ich mal so an meine Assemblerzeiten zurückdenke, da habe ich auch
> viele Schweinereien gemacht.

Auch selbstmodifizierender Code gehörte dazu (prominentestes Beispiel:
Apple-Systemsoftware vom Woz). Leider geht das auf Harvard-Prozessoren
wie dem AVR nicht mehr, da hier nicht direkt in den Programmspeicher
geschrieben werden kann ;-)

von Einer K. (Gast)


Lesenswert?

Yalu X. schrieb:
> da hier nicht direkt in den Programmspeicher
> geschrieben werden kann ;-)

U.A. AmForth tut das, über einen Kurzausflug über den Bootloaderbereich.
Kann man also schon unter "selbst modifizierender Code auf Harvard/AVR" 
einordnen, wenn man es möchte.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.