Assemblerprojekt - Wer hätte Lust?

abc.w

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.

Nobuo T

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.

abc.w

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?

rapso

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.