Assemblerprojekt - Wer hätte Lust?



  • plattform schrieb:

    Hat hier gerade wer erwähnt das C Plattformunabhängig wäre?

    Geh wo anders trollen 🙄



  • @Aha Ja, das trifft so ungefähr das was ich wollte. Der Schwerpunkt liegt eben im Maschienennahen programmieren und nicht im Globalen wie mit C oder C++. Der Assembler soll speziell auf jeden CPU anpassbar sein. Er soll vor allem hochspezialisierte Werkzeuge oder auch Routinen zur Einbindung in Hochsprachen erzeugen können. Die Entwicklungsumgebung soll grafisch sein und nicht wie bei Visual C++, das ja eigentlich nicht visuell ist, sondern auf sprachlichen Befehlen basiert ist. Man wird sich dafür etwas einfallen lassen müssen. Ein aufrufbares Befehlsverzeichniss wäre sicher auch sehr hilfreich.

    @plattform ANSI C scheint ja ziemlich standardisiert zu sein. Aber alles was weitergeht, wie C++ oder C# hängt auch stark von den aktuellen Versionen der Bibliotheken ab.

    @Trolldich Woher weisst du, dass plattform ein Troll ist?



  • Mal davon ab, dass ich so oder so keine Zeit habe, ist das wenn du mich Fragst ein riesen Aufwand bei quasi keinem praktischen Nutzen.
    Visuelle/grafische Programmierung wie zB. MindStorm o.Ae., bei denen man sich seine Programme zusammenklickt, haben den Vorteil der Uebersichtlichkeit und intuitiven Arbeit doch gerade wegen ihres hohen Abstraktionsgrades.
    Was fuer einen Sinn macht das dann im Zusammenhang mit Assembler, frage ich mich (oder besser dich)?
    Scheint mir einfach reichlich unausgegoren und widerspruechlich. Mal ein paar Denkanstoesse:
    1. Tippe ich ein Mnemonic schneller als dass ich es aus einem Menu auswaehle. Fuer eine Uebersicht gibt es Referenzen. Wer die nicht kapiert, sollte die Finger von Assembler lassen.
    2. Wie soll hierbei eine Visualisierung sinnvoll funktionieren? Die Mnemonics von Standard-Befehlen wie Grundrechenarten, Kopieren, etc, die die meisten CPU irgendwie koennen, einfach nur durch Symbole zu ersetzen, scheint mir wenig hilfreich. Eine generelle Umstrukturierung, weg von aufeinanderfolgenden Befehlen, ist mit minimaler Abstraktion nicht mehr vereinbar.
    3. Wie willst du geringe Abstraktion mit vermutlich doch einheitlicher Visualisierung und zT. sehr unterschiedlichen CPU wie x86 (PC, idR. 2 Operanden/Opc) vs. MIPS (zB. PS, idR. 3 Operanden/Opc) sinnvoll unter einen Hut bringen?
    3a. Wie soll die Visualisierung dann fuer Spezialbefehle funktionieren?



  • Vor allem in Assembler wo man wirklich mehr als genug tun muss um wenig zu schaffen, da hat man doch nicht auch noch die nerven irgendwelche Grafiken zusammenzuschubsen. Das lohnt doch wirklich nur, wenn man mit einer Grafik sehr viel ausdrücken kann <- direkter Widerspruch zu Assembler.



  • @Nobuo T: Ich kenne Mindstorm nicht und konnte eben so auf die Schnelle auch im Netz nichts darüber finden. Aber es soll erstmal wie gesagt nur ein Assembler für die unterste Programmierebene werden. So aufwendig wird das sicher nicht werden, sich für jeden Assemblerbefehl ein Symbol auszudenken. Und wenn sich keine Interessenten finden lassen, werde ich das Programm halt alleine entwickeln. Wie meinst du das mit dem Abstraktionsgrad? Meinst du damit z.B. die Klassen der MFC? Bei denen vielen Befehlen wird das ganze auch mittlerweile wieder unübersichtlich und anfällig für Fehler und Inkompatibilitäten. Kann sein, dass noch nicht alles so richtig ist, denn ich bin ja erst noch am Anfang und habe erst angefangen eine Befehlsliste für einen Pentium Pro Prozessor zu schreiben. Ob du mit dem Tippen wirklich schneller bist, müsste man erst mal messen können und dafür müsste der Assembler fertig sein!
    Was sind MIPS? Hmmm, ich denke man braucht für jeden IC einfach nur eine Befehlsliste, die man dann nur noch richtig einlesen muss.
    Das mit den Pfeilen für die Sprungbefehle hast du ja gelesen, oder?
    Für die Portbefehle "in" und "out" könnte man auch einfach nur Pfeile verwenden.
    Allein, das sowas besser ins Auge fällt hilft beim Programmieren unheimlich.

    @Hehe: Der Aufwand lohnt sich, wenn man einen kurzen und schnellen Code erzeugt, den man dann auch wiederverwenden kann. Das mit der grafischen Benutzeroberfläche wird für Programmierer anfangs gewöhnungsbedürftig sein, das stimmt.



  • Eric schrieb:

    @Hehe: Der Aufwand lohnt sich, wenn man einen kurzen und schnellen Code erzeugt, den man dann auch wiederverwenden kann. Das mit der grafischen Benutzeroberfläche wird für Programmierer anfangs gewöhnungsbedürftig sein, das stimmt.

    wie gesagt... dafür verwendet man C, da hat man schneller was gecoded als was zusammen geklickt. Und für sehr viele CPU's gibts C compiler.

    dann mach ein programm welches aus Zusamengeklickte symbole etc. C Code erzeugt, der dann wieder um auf gängen compiler läuft... naja viel aufwand für nichts sag ich mal.



  • Eric N. Falbe schrieb:

    Ich kenne Mindstorm nicht und konnte eben so auf die Schnelle auch im Netz nichts darüber finden.

    Wie hast du gesucht? Google liefert ~1M Ergebnisse. 😃
    Ich meinte das hier. Die Programmier"sprache" dazu heisst wohl Robolab und basiert auf LabView, falls das mehr bringt.

    Eric N. Falbe schrieb:

    So aufwendig wird das sicher nicht werden, sich für jeden Assemblerbefehl ein Symbol auszudenken.[...]Allein, das sowas besser ins Auge fällt hilft beim Programmieren unheimlich.

    Hehe, was fuer ein einfaches Symbol wuerdest du denn ganz spontan zB. dem tollen Befehl "arpl" zuordnen. 😃
    Wie gesagt, IMHO waere die Uebersichtlichkeit im Vergleich zu ordendlichem Code mit Syntax coloring wenn ueberhaupt nur minimal besser.

    Eric N. Falbe schrieb:

    Wie meinst du das mit dem Abstraktionsgrad? Meinst du damit z.B. die Klassen der MFC? Bei denen vielen Befehlen wird das ganze auch mittlerweile wieder unübersichtlich und anfällig für Fehler und Inkompatibilitäten.

    KA, ich arbeite nicht mit den MFC. Eine Definition von Abstraktion findest du hier.
    Was ich meine ist, dass du dich von den Prinzipien und Aufbau klassischen Assemblercodes nicht weit entfernen kannst, ohne zu abstrahieren (dh. Befehle und fertiger Code stimmen nicht mehr genau ueberein) und was du dann hast, ist kein Assembler mehr, sondern eine Art Hochsprache.

    Eric N. Falbe schrieb:

    Kann sein, dass noch nicht alles so richtig ist, denn ich bin ja erst noch am Anfang und habe erst angefangen eine Befehlsliste für einen Pentium Pro Prozessor zu schreiben. Ob du mit dem Tippen wirklich schneller bist, müsste man erst mal messen können und dafür müsste der Assembler fertig sein!

    Bei der Menge moeglicher Kombinationen bezweifle ich das ernsthaft.

    Eric N. Falbe schrieb:

    Was sind MIPS? Hmmm, ich denke man braucht für jeden IC einfach nur eine Befehlsliste, die man dann nur noch richtig einlesen muss.

    Aber von google und wikipedia hast du schon mal gehoert, oder?
    http://de.wikipedia.org/wiki/MIPS-Architektur
    Kurz: Eine von x86 deutlich verschiedene CPU.
    Einfach mit einer anderen "Befehlsliste" duerfte es da nicht getan sein.

    Eric N. Falbe schrieb:

    Das mit den Pfeilen für die Sprungbefehle hast du ja gelesen, oder?

    Ja. Wenn ich das wirklich uebersichtlicher finde, kann ich mir das aber auch in einem entsprechenden Editor neben meinen Quellcode malen lassen.

    Eric N. Falbe schrieb:

    Für die Portbefehle "in" und "out" könnte man auch einfach nur Pfeile verwenden.

    Und wie unterscheidest du die beiden dann? Verschiedene Farben? 🙄



  • Hallo,

    ich habe hier eine Assembler-Funktion für einen Blackfin DSP (aus http://www.ece.vt.edu/swe/chamrad/crdocs/CRTM02_060124_Blackfin.pdf):

    .global _fir_filter;
    .type _fir_filter, STT_FUNC;
    _fir_filter:
    [--sp] = ( p5:5 );
    LINK 20;
    [FP+16] = R1;
    [FP+20] = R2;
    W [FP+12] = R0;
    R0 = [FP+24];
    [FP+-8] = R0;
    R0 = [FP+-8];
    [FP+-12] = R0;
    R0 = [FP+20];
    R1 = R0;
    R1 <<= 1;
    R0 = [FP+16];
    R0 = R1 + R0;
    R0 += -2;
    [FP+-16] = R0;
    P0 = FP;
    P0 += -8;
    R3 = [P0];
    P5 = FP;
    P5 += -16;
    R1 = [P5];
    P2 = R3;
    P1 = R1;
    R2 = W [P2] (X);
    R0 = W [P1] (X);
    R0 = R2.L * R0.L (IS);
    R1 += -2;
    [P5] = R1;
    R3 += 2;
    [P0] = R3;
    W [FP+-18] = R0;
    R0 = 2 (X);
    [FP+-4] = R0;
    

    @Eric N. Falbe: Wie würde man den grafisch darstellen? Im Prinzip sind bloss lauter Zuweisungen, also Pfeil nach links, Pfeil nach rechts... 😉



  • Habe heute leider kaum Zeit zum schreiben.

    Mindstorm scheint eher für Mikrocontroller zu sein.
    Naja, ARPL müsste man entweder als ARPL-Symbol einfügen oder sich eine ganz neue Zeichensprache für die Mnemonics ausdenken.
    Mit grün für out und rot für in Befehle wäre man vielleicht schon etwas weiter.

    DSP geht auch eher in den Bereich Mikrocontroller.
    Ich wollte eigentlich erst mal einen sehr anpassungsfähigen Assembler für CPUs machen.



  • lol völliger schwachsinn hier. und wozu noch einen neuen assembler, es gibt schon den GNU assembler, was haste an dem auszusetzen?



  • Man kann den Sinn anzweifeln, aber ihn blöd anzumachen, weil er solch ein Projekt plant finde ich unpassend. Es hat doch jeder das Recht selber zu entscheiden was er entwickeln will.



  • Eric N. Falbe schrieb:

    Mindstorm scheint eher für Mikrocontroller zu sein.
    [...]DSP geht auch eher in den Bereich Mikrocontroller.
    Ich wollte eigentlich erst mal einen sehr anpassungsfähigen Assembler für CPUs machen.

    Wo machst du da den Unterschied? 😕
    Dieses Mindstorms arbeitet neuerdings zB. auch mit einem ARM als CPU. Den gibt es nicht nur in µCs/embedded systems, sondern in allem moeglichen - auch einzeln als "CPU-Chip".

    Eric N. Falbe schrieb:

    Naja, ARPL müsste man entweder als ARPL-Symbol einfügen oder sich eine ganz neue Zeichensprache für die Mnemonics ausdenken.

    Und was haben wir dann? Ein Konkurrenzprodukt zur AT&T-Syntax mit noch eigenwilligerer Symbolik und aufgezwungenem Coloring? 🙄

    Du scheinst uebrigens bisher immer noch einzig auf x86 fixiert und drueckst dich beharrlich um die Frage, wie du deutlich verschiedene Architekturen wie MIPS oder PPC unterstuetzen willst. Schau es dir mal an. Zumindest zu MIPS ist auch was in den FAQ verlinkt.



  • Naja, erst mal nur für den CPU denke ich doch mal.
    Es könnte aber auch so etwas wie eine Assembler Obersprache werden, mit der man den Assembler für jeden IC konfigurieren kann.
    Aber eigentlich gibt es ja für jeden Mikrocontoller eigene Entwicklungstools.
    Obwohl sowas sicher auch interessant wäre ...
    Aber wenn das Ding für x86 CPUs erst mal läuft, kann man es ja immer noch weiterentwickeln.



  • Es könnte aber auch so etwas wie eine Assembler Obersprache werden, mit der man den Assembler für jeden IC konfigurieren kann

    Finde mal eine Obersprache für Englisch, Russisch und Chinesisch. Denk an die zig verschiedenen Architekturen und CPU Familien und an deine utopische Idee...

    Aber eigentlich gibt es ja für jeden Mikrocontoller eigene Entwicklungstools

    Für jeden Mikrocontoller gibt es C- und vielleicht sogar C++ Compiler - und Debugger dazu. Wie denkst du, grafisch erstellte Assembler-Programme zu debuggen? Und wie soll überhaupt die Ausgabe deines Tools sein, damit meine ich, spuckt dein Tool gleich eine exe aus? Oder erstmal wahrscheinlich Objektdateien? In welchem Format und mit welchem Tool möchtest du sie dann verlinken?



  • naja, so absurd ist es eigentlich nicht.
    gcc hat auch ne generische darstellung von programmen bevor dann daraus ne art meta-assembler und dann erst das binary aus opcodes generiert wird anhand eine plattform abhaengigen beschreibung.

    ich wuerde im ersten schritt aus dem tool primitive c commandos generieren und mittels gcc dann erstmal auf jede plattform crosscompilieren. dann kann man langsam ebenen runter gehen.

    aber das ganze ist schon sehr aufwendig, fast wie compiler schreiben.



  • @abc.w Ich habe mich in den letzten paar Tagen erst mal mit C und visual C beschäftigt und meinen alten GNU Compiler rausgesucht. So wie es aussieht erkennt er nur einen 386'er Prozessor obwohl ich einen AMD mit über 2000 MHz habe. Also muss er wohl für verschiedene CPUs andere Übersetzungstabellen haben. Aber für welche CPUs genau er angepasst ist und wo genau diese Tabellen sind, konnte ich leider nicht herausfinden.

    @ rapso mit gcc meinst du den GNU-Compiler, oder?
    Ich weiss nicht, für welche CPUs der alle gemacht ist.
    Kennst du die neueste Version des GNU C-Compilers?
    Und weisst du für welche CPUs er genau gemacht worden ist?



  • Hallo Eric N. Falbe,

    ich gebe auf, Du hast noch einen langen, langen, langen Weg vor Dir...



  • Eric N. Falbe schrieb:

    @abc.w Ich habe mich in den letzten paar Tagen erst mal mit C und visual C beschäftigt und meinen alten GNU Compiler rausgesucht. So wie es aussieht erkennt er nur einen 386'er Prozessor obwohl ich einen AMD mit über 2000 MHz habe. Also muss er wohl für verschiedene CPUs andere Übersetzungstabellen haben. Aber für welche CPUs genau er angepasst ist und wo genau diese Tabellen sind, konnte ich leider nicht herausfinden.

    lol



  • @x: Kann sein, aber nur Lügen haben kurze Beine!
    Aber hauptsache man kommt da an, wo man hin will.
    @asdca : Was gibt es da zu lachen?
    Habe mittlerweile eine header-Datei mit Mnemonics gefunden.
    Die ist aber nicht zum übersetzen von Assembler Inline Code.
    Ich meine die, die beim Programmbeispiel Dr. Watson dabei ist.
    Sie heisst dasm.h und ist offensichtlich zum diassemblieren.


Anmelden zum Antworten