amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > Mono für Amiga [ - Search - New posts - Register - Login - ]

First 1 2 3 4 5 -6- [ - Post reply - ]

2004-07-20, 16:31 h

Solar
Posts: 3680
User 		Hmm... ich weiß ja, wem ich da widerspreche, aber... gni, wenn das, was ich jetzt sage, Unsinn ist, nicht Kopf abreißen, sondern aufklären, bitte!

Zitat:
Original von gni:

Der GCC (genauer der Compiler) erzeugt Assemblerbefehle, die dann von einem Assembler (meist (G)nu (AS)sembler) zu einem Objektfile gemacht werden.

Das ist meines Wissens nicht korrekt. Ich habe mich vor Zeiten mal mit den Internas von GCC auseinandergesetzt, insbesondere dem Backend-Interface - allerdings nur oberflächlich. Aus der Zeit meine ich mich erinnern zu können, daß der ASM-Code, zu dem man seinen C/C++-Code wandeln kann, quasi eine Rückübersetzung aus einem schon tiefer gehenden internen Format sei; GCC würde nicht den Umweg über ASM-Code machen, sondern direkt die interne Repräsentation (Trees?) an den Code-Generator von GAS übergeben.

Zitat:
Original von whose:

Z.B. einen groben Überblick, wie der GCC den Code normalerweise erzeugt.

GCC Internals Documentation, http://gcc.gnu.org/onlinedocs/gccint/


Zitat:
Wo muß man einhaken, wenn man ein anderes Object-Format erhalten will, weil man einen GCC-fremden Linker verwenden möchte?

Zunächst einmal sollte man prüfen, ob nicht schon eine Neukonfiguration / Neukompilierung der Toolchain das gewünschte Format abwirft. Ansonsten - und das sage ich mit demselben Vorbehalt wie oben mein Widerspruch zu gni - meine ich, die Trees (Kap. 8 der Internals-Docs) als den Interface-Punkt für andere Backends im Kopf zu haben.

Das ganze Thema interessiert mich ebenfalls; weitere Erkenntnisse bitte auch in meine Richtung...

[/quote]
Das macht der Assembler. Der muß halt verstehen, was aus dem Compiler rauskommt.

[/quote]



[ - Answer - Quote - Direct link - ]
2004-07-21, 01:07 h

whose
Posts: 2156
User 		@gni + Solar:

Also, ich habs mir nochmal genauer angeschaut (an der Stelle: Danke für den Link, Solar :) ).

Der GCC erzeugt definitiv Assembler-Code. Man kann ihn aber in der Ausgabe des Assembler-Codes weitgehend frei konfigurieren. Ich müßte jetzt also erstmal klären, welcher Assembler beim StormC im GCC-Modus zum Einsatz kommt. Ists der AS, habe ich schon wieder ein Problem, dann bräuchte ich Informationen über den AS-Pass, die auf den GCCint-Pages nicht zu finden sind (oder ich bin blind, kann ja auch sein ;) ).

Sollte es der StormASS sein, ists schon bedeutend einfacher. Dann muß ich mir zum Vergleich mal ansehen, wie die das bei StormC-GCC gehandhabt haben mit der Konfiguration des Assembler-Outputs. Dann fand die Modifikation an dieser Stelle statt und ich muß mir um den Linker keine Gedanken machen. Dann wäre es so, wie ich es vermute, nämlich daß der Output des GCC an den Rest des StormC angepaßt wurde (in diesem Fall StormASS) und die zwei Quelldateien, die den ARexx-Output besorgen, eine Entsprechung beim 3.4.1 haben müssen. Dann sollte es nicht so ein Riesen-Problem werden. Könnte zwar länger dauern bis da Ergebnisse kommen (ich kenn mich ;) ), aber unmöglich ists nicht.

Wäre halt nur super, wenn ich Euch auch weiterhin mit Fragen zu dem Thema löchern darf ;)

Grüße


[ - Answer - Quote - Direct link - ]
2004-07-21, 08:46 h

Solar
Posts: 3680
User
Zitat:
Original von whose:
@gni + Solar:

Also, ich habs mir nochmal genauer angeschaut (an der Stelle: Danke für den Link, Solar :) ).

Na aber gerne doch, jetzt wo wir anscheinend vom Flaming zur gehaltvolleren Themen übergegangen sind. ;-)

Zitat:
Der GCC erzeugt definitiv Assembler-Code. Man kann ihn aber in der Ausgabe des Assembler-Codes weitgehend frei konfigurieren.

Ich bin baff. Das eröffnet evtl. für mein OS-Projekt ganz neue Möglichkeiten...

Zitat:
Ich müßte jetzt also erstmal klären, welcher Assembler beim StormC im GCC-Modus zum Einsatz kommt. Ists der AS, habe ich schon wieder ein Problem, dann bräuchte ich Informationen über den AS-Pass, die auf den GCCint-Pages nicht zu finden sind (oder ich bin blind, kann ja auch sein ;) ).

GAS ist Teil der GNU binutils, http://www.gnu.org/software/binutils/. Wobei auch GAS wiederum auf den BFD-Bibliotheken aufsetzt... die aber auch in den binutils stecken. ;-)

[ - Answer - Quote - Direct link - ]
2004-07-21, 10:39 h

whose
Posts: 2156
User
Zitat:
Original von Solar:

GAS ist Teil der GNU binutils, http://www.gnu.org/software/binutils/. Wobei auch GAS wiederum auf den BFD-Bibliotheken aufsetzt... die aber auch in den binutils stecken. ;-)

Und nochmal: Danke für den Link! :)

Dann hab ich ja jetzt alles zusammen, um da mal Vergleiche mit dem StormC-GCC anstellen zu können.

Grüße


[ - Answer - Quote - Direct link - ]
2004-07-21, 12:57 h

gni
Posts: 1106
User
Zitat:
Solar:
Zitat:
von gni:
Der GCC (genauer der Compiler) erzeugt Assemblerbefehle, die dann von einem Assembler (meist (G)nu (AS)sembler) zu einem Objektfile gemacht werden.
Das ist meines Wissens nicht korrekt.
Ich bin zwar kein GCC Experte, aber meine obige (vereinfachte ;-) Darstellung ist korrekt.
Zitat:
Ich habe mich vor Zeiten mal mit den Internas von GCC auseinandergesetzt, insbesondere dem Backend-Interface - allerdings nur oberflächlich. Aus der Zeit meine ich mich erinnern zu können, daß der ASM-Code, zu dem man seinen C/C++-Code wandeln kann, quasi eine Rückübersetzung aus einem schon tiefer gehenden internen Format sei; GCC würde nicht den Umweg über ASM-Code machen, sondern direkt die interne Repräsentation (Trees?) an den Code-Generator von GAS übergeben.
Zuerst werden TREEs erzeugt, dann RTL und zum Schluß generiert das Backend Assembler. Für whose wird wohl nur der Backendteil interessant sein. GAS ist _kein_ Code-Generator, es ist der separate GNU Assembler.
Zitat:
Zunächst einmal sollte man prüfen, ob nicht schon eine Neukonfiguration / Neukompilierung der Toolchain das gewünschte Format abwirft.
Im Falle von StormC ist das wohl nicht der Fall ;)

[ - Answer - Quote - Direct link - ]
2004-07-21, 13:02 h

gni
Posts: 1106
User
Zitat:
whose:
Der GCC erzeugt definitiv Assembler-Code. Man kann ihn aber in der Ausgabe des Assembler-Codes weitgehend frei konfigurieren.
Man kann nur zwischen MIT und Motorola Syntax wählen. MIT versteht auf dem Amiga nur GAS. Inwieweit die generierten Motorola Assmeblermnemonics kompatible zu nicht GAS Assembler sind, ist mir nicht bekannt.
Zitat:
Ich müßte jetzt also erstmal klären, welcher Assembler beim StormC im GCC-Modus zum Einsatz kommt. Ists der AS, habe ich schon wieder ein Problem, dann bräuchte ich Informationen über den AS-Pass, die auf den GCCint-Pages nicht zu finden sind (oder ich bin blind, kann ja auch sein ;) ).
Gute Frage ;) Jedoch was willst/mußt Du wissen?
Zitat:
Dann wäre es so, wie ich es vermute, nämlich daß der Output des GCC an den Rest des StormC angepaßt wurde (in diesem Fall StormASS) und die zwei Quelldateien, die den ARexx-Output besorgen, eine Entsprechung beim 3.4.1 haben müssen. Dann sollte es nicht so ein Riesen-Problem werden. Könnte zwar länger dauern bis da Ergebnisse kommen (ich kenn mich ;) ), aber unmöglich ists nicht.
Gehts Dir um m68k, PPC oder beides? Die m68k Patches von 2.95.x an 3.x anzupassen ist _nicht_einfach. Wenn Du versuchst der StormIDE einen neuen Compiler zu verpassen solltest Du die Stormänderungen sauber einpassen. H&P haben das nicht getan.

[ - Answer - Quote - Direct link - ]
2004-07-21, 13:03 h

gni
Posts: 1106
User
Zitat:
Solar:
Zitat:
whose:
Der GCC erzeugt definitiv Assembler-Code. Man kann ihn aber in der Ausgabe des Assembler-Codes weitgehend frei konfigurieren.
Ich bin baff. Das eröffnet evtl. für mein OS-Projekt ganz neue Möglichkeiten...
Inwiefern?

[ - Answer - Quote - Direct link - ]
2004-07-21, 13:41 h

Solar
Posts: 3680
User
Zitat:
Original von gni:
Zitat:
Solar:
Zitat:
whose:
Der GCC erzeugt definitiv Assembler-Code. Man kann ihn aber in der Ausgabe des Assembler-Codes weitgehend frei konfigurieren.
Ich bin baff. Das eröffnet evtl. für mein OS-Projekt ganz neue Möglichkeiten...
Inwiefern?

Ach, wir hatten mit verschiedenen Gedankenmodellen gespielt - neues Backend für GCC, "virtueller Prozessor" a la Tao und noch einige Dinge in diese Richtung, die GCC tief in die Eingeweide gegriffen hätten.

Allerdings ist das fast drei Jahre her, und das damals recht ambitioniert gestartete Projekt ist inzwischen zur One-Man-Show verkümmert (und selbst bei mir rangiert es nur noch auf Platz Drei). :shock2: I-)

[ - Answer - Quote - Direct link - ]
2004-07-22, 02:21 h

whose
Posts: 2156
User
Zitat:
Original von gni:
Zitat:
whose:
Der GCC erzeugt definitiv Assembler-Code. Man kann ihn aber in der Ausgabe des Assembler-Codes weitgehend frei konfigurieren.
Man kann nur zwischen MIT und Motorola Syntax wählen. MIT versteht auf dem Amiga nur GAS. Inwieweit die generierten Motorola Assmeblermnemonics kompatible zu nicht GAS Assembler sind, ist mir nicht bekannt.

Hm, korrigiere mich, wen ich da verkehrt liege, aber wenns einem pressiert, kann man ja auch eine modifizierte machine description verwenden, um diese Einschränkung zu umschiffen, oder? Dann sollte die Syntax nicht mehr die tragende Rolle spielen. Okay, ist ein Haufen Arbeit, aber wenns hilft?

Zitat:
Zitat:
Ich müßte jetzt also erstmal klären, welcher Assembler beim StormC im GCC-Modus zum Einsatz kommt. Ists der AS, habe ich schon wieder ein Problem, dann bräuchte ich Informationen über den AS-Pass, die auf den GCCint-Pages nicht zu finden sind (oder ich bin blind, kann ja auch sein ;) ).
Gute Frage ;) Jedoch was willst/mußt Du wissen?

Bessere Frage ;) Ich bin noch nicht dazu gekommen, mir die Sache GAS/StormASS näher zu betrachten, da ich im wahren Leben Schichtmalocher bin. Da bleibt nicht viel Zeit. Im Moment sowieso nicht, da ich in Spätschicht arbeite. Neben der StormC-Geschichte drückt mich auch noch die Artikelreihe für die AmigaInsider, da muß ich noch einiges schreiben, Bilder dafür zaubern und die Grafik-Engine dafür in einen ordentlichen Zustand bringen... ;)

Darf ich Dich einfach direkt fragen, sobald Fragen auftauchen?

Zitat:
Zitat:
Dann wäre es so, wie ich es vermute, nämlich daß der Output des GCC an den Rest des StormC angepaßt wurde (in diesem Fall StormASS) und die zwei Quelldateien, die den ARexx-Output besorgen, eine Entsprechung beim 3.4.1 haben müssen. Dann sollte es nicht so ein Riesen-Problem werden. Könnte zwar länger dauern bis da Ergebnisse kommen (ich kenn mich ;) ), aber unmöglich ists nicht.
Gehts Dir um m68k, PPC oder beides? Die m68k Patches von 2.95.x an 3.x anzupassen ist _nicht_einfach. Wenn Du versuchst der StormIDE einen neuen Compiler zu verpassen solltest Du die Stormänderungen sauber einpassen. H&P haben das nicht getan.

Ich hab gewußt, daß ich mir da wieder reichlich Arbeit antun will, aber ich sehe so langsam immer bessere Chancen, daß ich das auch hinkriege. Da will ich mein Bestes tun, daß das was wird. Ich werde wohl nicht um "beides" herum kommen, schließlich erzeugt der StormC-GCC auch die PPC-Objects.


Auch wenn ich dann anderer Leute Code entrümpeln muß ;) Wäre ja nicht das erste Mal... EliteTNK in einem begonnenen Amiga-Port war in Sachen Chaos eine Offenbarung (was chaotischeres habe ich nie zuvor gesehen ;) ), ich habs aber trotzdem soweit aufräumen können, daß es (zumindest im Ansatz) läuft. Müßte ich bei den GCC-Modifikationen des StormC eigentlich auch schaffen. Geduld ist eine meiner Stärken ;)

Aber erstmal muß ich verstehen, was da eigentlich gemacht wird, und hauptsächlich dazu bräuchte ich Hilfe, wenn ich mal nicht weiterkomme.

Grüße


[ - Answer - Quote - Direct link - ]
2004-07-22, 09:01 h

Solar
Posts: 3680
User 		OK, OK, ich weiß wieder, welche angestaubte Information mich hier verwirrt hat.

Aus den GCC Internals, http://gcc.gnu.org/onlinedocs/gccint/Reading-RTL.html#Reading-RTL:


Zitat:
People frequently have the idea of using RTL stored as text in a file as an interface between a language front end and the bulk of GCC. This idea is not feasible.

GCC was designed to use RTL internally only. Correct RTL for a given program is very dependent on the particular target machine. And the RTL does not contain all the information about the program.

The proper way to interface GCC to a new language front end is with the “tree” data structure, described in the files tree.h and tree.def. The documentation for this structure (see Trees) is incomplete.

Es ging bei mir also nicht um's Backend (neues Output-Format), sondern um's Frontend (neues Input-Format, sprich Sprache).

Sorry für das Chaos.

[ - Answer - Quote - Direct link - ]
2004-07-26, 17:15 h

gni
Posts: 1106
User
Zitat:
whose:
Darf ich Dich einfach direkt fragen, sobald Fragen auftauchen?
Ja. Ich kann aber nicht garantieren, das ich eine Antwort haben werde :-)

[ - Answer - Quote - Direct link - ]
2004-07-26, 20:50 h

whose
Posts: 2156
User
Zitat:
Original von gni:
Zitat:
whose:
Darf ich Dich einfach direkt fragen, sobald Fragen auftauchen?
Ja. Ich kann aber nicht garantieren, das ich eine Antwort haben werde :-)


Danke. Och, das macht nix. Für Tips bin ich ebenso dankbar, auch wenn eine konkrete Antwort sofort weiterhelfen würde. Wenn der richtige Tipp kommt, finde ich die Antwort auch selber, denke ich ;)

Grüße

[ - Answer - Quote - Direct link - ]

First 1 2 3 4 5 -6- [ - Post reply - ]


amiga-news.de Forum > Programmierung > Mono für Amiga [ - Search - New posts - Register - Login - ]


.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.
.