Assambler programmieren.... -
Geizhals » Forum » Programmierung » Assambler programmieren.... - (160 Beiträge, 1846 Mal gelesen) Top-100 | Fresh-100
Du bist nicht angemeldet. [ Login/Registrieren ]
.......
Re(7): Assambler programmieren, EBNF und Grammatiken.... -*Hikfe*
15.02.2023, 21:01:52
Er spricht 32bit Code auf dem 386 an. Das war genau die Zeit, als Compiler tatsächlich oft schon dadurch überlegen waren, dass sie die damals noch einigermaßen knappe Ressource "Register" in komplexeren Funktionen effizienter nutzen konnten. Und natürlich mussten sich Assembler-Programmierer erstmal einige der Konstrukte abgewöhnen, die sie sich zu 8086 und 286 Zeiten angewöhnt hatten, als es noch keinen Cache gab und selbstmodifizierender Code daher keinerlei Penalties hatte.

Schon beim Pentium drehte sich das Blatt dann wieder. Der war zwar theoretisch schon superskalar, aber Instruction Pairing wurde von Compilern lange Zeit gar nicht oder nur halbherzig beachtet.

Heute dürfte das Problem weniger sein, dass Compiler so gut geworden sind, sondern das es immer weniger Programmierer zu geben scheint, die noch wissen, wie man überhaupt Assemblermodule richtig einbindet, geschweige denn dabei venünftig optimiert und nicht sinnlos rumbloatet.

Aus zstd/lib/decompress/huf_decompress_amd64.S :

* TODO: Support Windows calling convention.

/* Save all registers - even if they are callee saved for simplicity. */

Und mein persönlicher Favorit:

    addq $8, %rsp
    /* Restore stack (oend & olimit) */
    pop %rax /* oend0 */
    pop %rax /* oend1 */
    pop %rax /* oend2 */
    pop %rax /* oend3 */
    pop %rax /* ilimit */
    pop %rax /* olimit */
    pop %rax /* arg */

Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
......
Re(6): Assambler programmieren, EBNF und Grammatiken.... -*Hikfe*
05.02.2023, 21:00:52
Programmierer sind in hohem Maße reine Nutzer von Technologien. Wie
Autofahrer. Und beide haben meist wenig Ahnung, was in diesen Technologien
abläuft.


Naja, wenn dein Auto mal mitten in der Nacht auf einer Bundesstraße nicht mehr anspringt, kannst

a) jemanden um Hilfe rufen, der sich auskennt und so nett ist mitten in der Nacht zu dir zu fahren
b) jemanden dafür bezahlen, dass er sich auskennt und zu dir kommt
c) zfuß heimgehen und weinen, weil du nicht gelernt hast, wie ein Auto funktioniert

Ähnlich verhält es sich auch beim Programmieren. Du merkst halt sofort wer selbständig arbeiten kann, und wer beim kleinsten unvorhergesehen Problem sofort aufgibt und um Hilfe schreit. Also reine "Nutzer" erkennt man recht schnell.

Der Unterschied ist, dass eine ÖAMTC-Mitgliedschaft wesentlich billiger ist als bezahlter IT-Support.

Wenn du Libraries einbindest, liest du deren Source meist nicht.


Und das ist schon mal zu 100% falsch. Ich hab schon unzählige male in den Source-Code anderer Libraries schauen müssen, weil die Doku unvollständig oder unklar ist, oder ein merkwürdiger Bug auftritt, dem man selber einfach schneller auf die Schliche kommt als das dem Hersteller zu melden und zu hoffen, dass in den nächsten Wochen oder Monaten irgendwas passiert, währen du eine Deadline zur Fertigstellung deines Projekts hast.

Microsoft ist da so ein Paradebeispiel, die ändern ständig was in ihren Libraries und dann wunderst dich, warum das Ding nicht das macht, was man erwarten würd.

Was ein Compiler oder Interpreter innen drin tut, ist dir vollkommen egal.
Hauptsache, er tut.


Auch das ist falsch. Wenn ich in C# oder PHP z.B. große Datenmengen verarbeite, ist es sehr hilfreich zu wissen, welche Sprachkonstrukte und Funktionen man für seinen Anwendungsfall auswählt. Weil es gibt oft 10 verschiedene Arten etwas zu machen, und nicht jede ist gleich schnell oder ressourcenintensiv. Es zahlt sich eigentlich immer aus zu wissen, was da im Hintergrund eigentlich abläuft, wenn man seinen Code schreibt, auch wenn es nur ein oberflächliches Wissen ist.

Der Autofahrer bestimmt, wohin es geht und wie schnell. Und er passt auf, dass nichts passiert. Was vorne im Motor abläuft, ist irrelevant, solange es
vorwärts geht.


Es kann auch ned Schaden ein Grundwissen über Physik zu haben, und dass sich z.B. Autoreifen nicht bei jeder Temperatur und auf jedem Untergrund gleich verhalten. Auch schadet es nicht zu wissen, dass die Kraft zur Geschwindigkeit exponentiell steigt. Also ein bissl Mathematikwissen wär auch ned schlecht.

Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
........
Re(8): Assambler programmieren, EBNF und Grammatiken.... -*Hikfe*
06.02.2023, 22:46:43
Ich kann dir garantieren, dass sie bei AHS oder HLW Maturaniveau beginnen. Ob
der Student dann mitkommt oder nicht ist sein Problem.


Dunkel kann ich mich noch erinnern, dass ich mich mit meinem passablen Abi (inkl. Einserbereich in Mathe- und Physikleistungskurs) eigentlich ganz gut vorbereitet fühlte auf ein Informatik-Studium. Aber die Erstsemester-Veranstaltungen in Analysis und Linearer Algebra haben mir den Zahn dann ganz schnell gezogen. Mein Leistungskurs-Vorwissen hat maximal die ersten ein bis zwei Wochen etwas erleichtert, aber dann waren sie mit der Wiederholung auch durch und es ging ganz schnell in medias res. Ich möchte nicht wissen, welche Qualen die Leute mit Mathe nur im Grundkurs oder gar vorzeitig abgewählt (das ging damals an einigen Schulen noch) gelitten haben. Es haben auch verdammt viele aufgegeben, gefühlt die Hälfte war vor dem Vordiplom entschwunden.

Aber versuch's selbst!


"Gratulation! Worauf warten Sie noch? Zeit für ein Informatikstudium!" - Hurra! Und 20 Minuten waren ein Witz, das klickt man in einer Minute weg.

Die Bellman-Frage beantwortest Du aber nicht auf Maturaniveau. Nicht mal unbedingt nach einem abgeschlossenen Studium. Der Name klingelte zwar noch bei mir, aber ich gebe zu, dass ich auch nicht sicher war, ob ich ihm Binärbäume oder Graphen zuordnen sollte. Antwort 2 habe ich dann wegen der "Spezialisierung" ausgeschlossen und damit die richtige gefunden.

Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
...........
Re(11): Assambler programmieren, EBNF und Grammatiken.... -*Hikfe*
07.02.2023, 21:50:27
> nicht fröhlich alignments durch ihren Code sprenkeln wie es ein Compiler tun würde

Die können auch heutzutage noch Sinn ergeben, unter gewissen Umständen meckert der Kernel sogar wenn man keine vernünftige Ausrichtung vornimmt, weil iTLB page crossings in Hotspots sehr schnell sehr teuer werden können. Gut, das klassische Bytestream alignment früherer x86 CPUs braucht man heutzutage nicht mehr wirklich, aber mir ist lieber man nutzt NOPs dafür, als sie zu einem Allzweck-Synchronisationsprimitiv verkommen zu lassen. Und die Dinger kosten heutzutage überhaupt nichts mehr, da sie bereits vor'm Renamer zusammengefaltet werden.

> Gilt natürlich nicht für Copy-Paste-Programmierer die nach kLOC bezahlt werden

kLOC Ratings hab ich schon eine gefühlte Ewigkeit nicht mehr gesehen. Heutzutage hält man sich da eher an irgendwelchen Milestones fest. Wie genau die umgesetzt werden ist irrelevant, sie müssen halt irgendwelche schwindeligen Unit Tests bestehen und bei der Integration nicht in sich selbst zusammenkrachen. Da muss man fast schon dankbar sein, wenn die formale Korrektheit der Implementierung berücksichtigt wird - ich blicke da mit Schaudern auf den Schmonz, der einem in Baseband-Firmwares entgegengeflogen kommt.

> Eyecatcher?

Makros wenn ich raten müsste, wobei das bei mir auf einer Stufe steht mit Leuten die ihre Structs typedef'en.

07.02.2023, 21:50 Uhr - Editiert von scientificallyilliterate, alte Version: hier
Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
.
Re: Assambler programmieren, EBNF und Grammatiken.... -*Hikfe*
17.02.2023, 12:31:35
ich schreib mal hier was zum ASM Code:
Ist wohl kein echter Prozessor, zumindest nix bekanntes, da man ja auch Annahmen treffen soll, denke ich dass da vielleicht einige der Annahmen in der Lehrveranstaltung besprochen wurden und ich hier eher aus der Luft greife.

Aber dennoch:

la ist vermutlich load address
Ohne weitere Parameter kann man Annehmen dass der Wert in ein Adressregister gespeichert wird, nennen wir es A0

lv ist vermutlich load value
Ohne weitere Parameter kann man Annehmen dass dieser Wert in einem Datenregister gespeichert wird, nennen wir es D0

lit wird literal sein
Ohne weitere Parameter kann man Annehmen dass der Wert in ein Register wie den Akkumulator (ACC) gespeichert wird.

add und mul wird addieren und multiplizieren sein
Auch hier keine Parameter, also Annahme: Addiert/Multipliziert ACC mit D0, speichert in D0

sto wird STORE sein, also Annahme: speichert den Wert von D0 an der Adresse A0

Also er nimmt 32, addiert die 5 und dann multipliziert er mit 5 und speichert das Ergebnis auf die Adresse 40 die in a0 geladen ist.

int main() {
    int x = (32 + 5) * 5;
    int* ptr = (int*) 40;
    *ptr = x;
    return 0;
}

In jedem echtem ASM haben die Befehle mehr Parameter mit denen man festlegt welche Register verwendet. Aber kurzformen der gleichen Befehle wo man einen Teil der Parameter weglässt und es wird ein vordefiniertes Register verwendet sind üblich, hier wurde das aber extrem gemacht und normal hat man ja ein manual in das man schauen kann was dann hier vordefiniert ist.



Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
 

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung