amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > StormC 4 oder GoldED Studio AIX: C/C++ IDE [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 [ - Beitrag schreiben - ]

10.07.2005, 21:05 Uhr

Zettmaster
Posts: 720
Nutzer
Hallo...

Welches der beiden ist besser?

StormC 4 oder GoldED Studio AIX: C/C++ IDE?

Gibt es Freeware auf dem Bereich?

mfg
enrico
--
A1200 im restauriertem InfinitivI mit Topcase, 256MB Ram, BPPC 603e/266 060/66 SCSI,Mediator 4xPCI, Voodoo3 3000 16MB, Soundblaster, LAN (DSL3000+512 Upload),40GB,Samsung CDRW/DVD Combo + CD52x, OS3.9 Diverse geile Software...

[ - Antworten - Zitieren - Direktlink - ]

10.07.2005, 22:32 Uhr

_PAB_
Posts: 3016
Nutzer
GoldED AIX ist besser, vor allem hat es einen aktuellen GCC und die SDKs zu MorphOS und AmigaOS(4).
StromC wird nicht weiterentwickelt, denke ich.

[ - Antworten - Zitieren - Direktlink - ]

10.07.2005, 23:17 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von _PAB_:
GoldED AIX ist besser, vor allem hat es einen aktuellen GCC und die SDKs zu MorphOS und AmigaOS(4).
StromC wird nicht weiterentwickelt, denke ich.


Das "besser" ist eine Frage der jeweiligen Ansprüche. Für 68K/WOS ist StormC sehr gut geeignet und der GCC, der dort verwendet wird, auf jeden Fall gut genug. Die "Verbesserungen" des GCC 3.x sind für 68K wohl eher marginaler Natur (und für WOS halt nicht einsetzbar).

Was die Bedienbarkeit der IDE betrifft, ziehe ich StormC dem GoldEd alle Male vor. Da ist alles schön geordnet und übersichtlich, ein Klick genügt und man ist da, wo man hin will (ganz nebenbei ist die Oberfläche von Storm _wirklich_ StyleGuide-konform).

Für OS4/MOS ist GoldEd sicher die geeignetere Alternative, so lange StormC nicht für OS4 verfügbar ist.

Übrigens, den "aktuellen" GCC gibts auch ohne GoldED und die Installation ist inzwischen auch handhabbar.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

11.07.2005, 11:07 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Die "Verbesserungen" des GCC 3.x sind für 68K wohl eher marginaler Natur

IMO GCC 3.x ist auch für m68k besser als GCC2.
Zitat:
(und für WOS halt nicht einsetzbar).
Das muß ja nicht so bleiben ;-)
Zitat:
Für OS4/MOS ist GoldEd sicher die geeignetere Alternative, so lange StormC nicht für OS4 verfügbar ist.
Von StormC für OS4 habe ich noch nie gehört.

[ Dieser Beitrag wurde von gni am 11.07.2005 um 11:08 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

11.07.2005, 11:15 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
IMO GCC 3.x ist auch für m68k besser als GCC2.


Das ihr Compiler-Jungs Euch nicht einig werden könnt... vor nicht allzu langer Zeit war der 2.x noch das Optimum ;)

Zitat:
Zitat:
(und für WOS halt nicht einsetzbar).
Das muß ja nicht so bleiben ;-)

Wäre wünschenswert :D

Zitat:
Zitat:
Für OS4/MOS ist GoldEd sicher die geeignetere Alternative, so lange StormC nicht für OS4 verfügbar ist.
Von StormC für OS4 habe ich noch nie gehört.

Ist ja auch noch in Arbeit, daher "so lange StormC _nicht_ für OS4 verfügbar ist" I-)

Grüße



--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

11.07.2005, 12:43 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Zitat:
gni:
IMO GCC 3.x ist auch für m68k besser als GCC2.

Das ihr Compiler-Jungs Euch nicht einig werden könnt... vor nicht allzu langer Zeit war der 2.x noch das Optimum ;)
Seit ich 3.3 kenne/habe, ist bei GCC2 für m68k bei mir auf dem Altenteil ;-)
Zitat:
Zitat:
Zitat:
(und für WOS halt nicht einsetzbar).
Das muß ja nicht so bleiben ;-)
Wäre wünschenswert :D
Die Anpassung des GCC2 WOS-Compiler ist leider nicht so einfach möglich, wie die der PUP Variante (die gibts von GCC2 bis GCC4).
Zitat:
Zitat:
Von StormC für OS4 habe ich noch nie gehört.
Ist ja auch noch in Arbeit, daher "so lange StormC _nicht_ für OS4 verfügbar ist" I-)
Ich wollte eigentlich etwas mehr zu dem Thema hören ;-) Wer macht das, welche Compiler Version, welches ABI (StormGCC steht ja mehr für WOS als PPC). Für mich klingt das ganze nach OS4 GCC in der StormIDE :-)

[ Dieser Beitrag wurde von gni am 11.07.2005 um 12:44 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

11.07.2005, 13:02 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Die Anpassung des GCC2 WOS-Compiler ist leider nicht so einfach möglich, wie die der PUP Variante (die gibts von GCC2 bis GCC4).


Warum eigentlich nicht? Die Sourcen des Storm-GCC sind doch vorhanden. Mit ein bißchen Know-How... ;)

Zitat:
Zitat:
Ist ja auch noch in Arbeit, daher "so lange StormC _nicht_ für OS4 verfügbar ist" I-)
Ich wollte eigentlich etwas mehr zu dem Thema hören ;-) Wer macht das, welche Compiler Version, welches ABI (StormGCC steht ja mehr für WOS als PPC). Für mich klingt das ganze nach OS4 GCC in der StormIDE :-)

Wer? Gute Frage, ich hab den Namen gleich wieder vergessen, nachdem ich den auf dem OS4-Event in Essen gehört habe. Einzelheiten sind mir auch nicht bekannt, weil ich damit wenig zu tun habe. Ich denke aber, daß Du mit Deiner Vermutung ins Schwarze triffst: StormC-IDE für den OS4-GCC. Das wäre so ziemlich das, was man bräuchte und was relativ einfach machbar wäre. StormC-WOS ginge zwar jetzt theoretisch auch, aber der alte Storm-Debugger funkt dazwischen.

Und dann vielleicht noch nen schönen Debugger mit GUI statt des Krampf-Kommandozeilen-GDB dazu... I-)

Grüße

P.S.: Ich hatte vor einiger Zeit in nem anderen Thread schon gefragt: Hast Du die WOS-Version der mpega-LibMad aus den entrümpelten Sourcen bekommen?

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 11.07.2005 um 13:03 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

11.07.2005, 13:58 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Zitat:
Original von gni:
Die Anpassung des GCC2 WOS-Compiler ist leider nicht so einfach möglich, wie die der PUP Variante (die gibts von GCC2 bis GCC4).

Warum eigentlich nicht?
Weil die Änderungen für WOS umfangreicher sind. Da muß an mehreren Stellen in den Quellcode des GCC eingegriffen werden. Diese Änderungen sind problematisch, weil sich diese Stellen bei neueren GCC-Versionen geändert haben. Für PowerUp erledigt man das meiste über den Port-Header und die anderen Änderungen waren an weniger problematischen Stellen. PowerUp verwendet halt ein Standard-ABI ;-)
Zitat:
Die Sourcen des Storm-GCC sind doch vorhanden. Mit ein bißchen Know-How... ;)
Vieleicht habe ich ja mal irgendwann das Know-How ;-)
Zitat:
Ich denke aber, daß Du mit Deiner Vermutung ins Schwarze triffst: StormC-IDE für den OS4-GCC. Das wäre so ziemlich das, was man bräuchte und was relativ einfach machbar wäre.
Was anderes hätte mich jetzt auch überrascht.
Zitat:
StormC-WOS ginge zwar jetzt theoretisch auch
Findest Du das nicht selber grotesk, daß OS4 das PowerUp-ABI verwendet und jetzt eine Emulation für WOS (das ein anderes ABI benutzt) braucht?
Zitat:
Hast Du die WOS-Version der mpega-LibMad aus den entrümpelten Sourcen bekommen?
Habe ich. Die funktioniert auch, aber ich bin bei "meinen" Versionen geblieben ;-)

[ - Antworten - Zitieren - Direktlink - ]

11.07.2005, 15:08 Uhr

whose
Posts: 2156
Nutzer
[quote]
Original von gni:
Findest Du das nicht selber grotesk, daß OS4 das PowerUp-ABI verwendet und jetzt eine Emulation für WOS (das ein anderes ABI benutzt) braucht?
[quote]

*hüstel* ich glaube, das ABI hat nen völlig anderen Namen ;) Ich denke, das ABI wurde hauptsächlich darum gewählt, um relativ problemlos an den GCC nebst Tools und Debugger zu kommen.

Für die Unix-gestählten Entwickler sicher die richtige Entscheidung, für alle anderen ein Hemmschuh erster Ordnung...

Zitat:
Zitat:
Hast Du die WOS-Version der mpega-LibMad aus den entrümpelten Sourcen bekommen?
Habe ich. Die funktioniert auch, aber ich bin bei "meinen" Versionen geblieben ;-)

Kein Thema, wollt nur wissen, ob die auch angekommen ist :D

Grüße


--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

11.07.2005, 16:09 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Zitat:
gni:
Findest Du das nicht selber grotesk, daß OS4 das PowerUp-ABI verwendet und jetzt eine Emulation für WOS (das ein anderes ABI benutzt) braucht?

*hüstel* ich glaube, das ABI hat nen völlig anderen Namen ;)
Es ging mir auch nicht um den Namen des ABI ;-) PowerUp/ELF wurden immer niedergemacht und dann geht OS4 diesen Weg...
Zitat:
Ich denke, das ABI wurde hauptsächlich darum gewählt, um relativ problemlos an den GCC nebst Tools und Debugger zu kommen.

Für die Unix-gestählten Entwickler sicher die richtige Entscheidung, für alle anderen ein Hemmschuh erster Ordnung...

Warum war/ist es für einen Teil ein Hemmschuh? Ich finde es zeigt auf jeden Fall das die Wahl von P5 begründet war. Seinen eigenen Compiler zu pflegen ist ein sehr aufwändige Sache. Da fällt mir ein: 64bit LinuxPPC benutzt das PowerOpen-ABI ;-)

[ - Antworten - Zitieren - Direktlink - ]

11.07.2005, 21:26 Uhr

Ralf27
Posts: 2779
Nutzer
Ich will ja auch in Zukunft auf C umsteigen und ich denke mir mal das StormC für mich vermutlich am besten wäre. Mit GoldED und C konnte ich mich leider nicht richtig anfreunden.

Allerdings sollte ich auch in die weitere Zukunft planen bzw. meine Programme in Zukunft auch einfach portierbar machen. Ich dachte da z.b. an die SDL-Lib, die es ja auch für mehrere Systeme gibt. Halt um nicht Systemfunktionen zu nutzen sondern total Hardwareunabhängig zu sein. Welche Libs gibt es da noch? OpenGL denk ich mir da mal.

Ich muß mich wirklich irgendwann mal (in den nächsten 10 Jahren :P ) auf C -"Kurs" bringen und das dann auch noch Plattformunabhängig. Steinigt mich, aber ich denke das man auch etwas über den Amigahorizont sehen sollte. 8o :lach:


Das was mich bis jetzt vorallem von C fernhält sind halt die Thread über "richtiges" und "falsches" C-Programmieren, wie man es richtig macht oder auch nicht, etc. Bzw. vorallem auch die Komplexität und die unglaubliche Auswahl und Möglichkeiten.

Irgendwann sollte ich doch mal denn Umstieg schaffen, das kann ja wohl net so schwer sein... :rolleyes: :lach:
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

11.07.2005, 22:01 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:

Warum war/ist es für einen Teil ein Hemmschuh? Ich finde es zeigt auf jeden Fall das die Wahl von P5 begründet war. Seinen eigenen Compiler zu pflegen ist ein sehr aufwändige Sache. Da fällt mir ein: 64bit LinuxPPC benutzt das PowerOpen-ABI ;-)


Zu dieser Zeit war die Wahl am Markt vorbei, denn da gab es noch Compiler, die weiterentwickelt wurden.

Der Hemmschuh ist schlicht und ergreifend die fürchterlich Unix-orientierte Installation & Bedienung des GCC. Frag doch mal nen Anfänger, ob der mit dem Compiler gut klarkommt und sich damit wohlfühlt. Jede Wette, die Antwort wird lauten "Der Compiler ist viel zu kompliziert, damit machts nicht wirklich Spaß zu arbeiten". Oder schau Dir die Anzahl der Fragen hier im Forum an, wie man dieses Monstrum korrekt installiert I-)

Oder was meinst Du, warum viele Profi-Entwickler auf den MS-Compiler und dessen IDE schwören? Nur weils so schön bunt ist? Oder könnte etwas dran sein, daß ne IDE den Arbeitsfluß verbessert? Apropos: mpega LibMad war mit dem Storm in <30 Sekunden zusammengeklickt. Wäre das #ifdef-Wirrwarr nicht gewesen, wäre die in einer Minute fertig compiliert. Und ich habe dabei kein vorgetippertes Makefile benutzt :D

Übrigens, FLDev auf OS4 ist derzeit noch keine Alternative, da kann man von Glück reden, wenn man mal ein Projekt ohne Absturz zusammengestellt, getippt und compiliert kriegt. Da ist noch ne Menge zu tun, finde ich. Wenn, dann schon eher GoldED. Nicht so schöne Bedienung, aber funktioniert wenigstens (aber ich benutze den (noch) nicht) I-)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

12.07.2005, 11:43 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Zitat:
gni:
Ich finde es zeigt auf jeden Fall das die Wahl von P5 begründet war.

Zu dieser Zeit war die Wahl am Markt vorbei, denn da gab es noch Compiler, die weiterentwickelt wurden.
Wenn die Wahl falsch gewesen wäre, dann würde heute niemand dieses Modell benutzen. Es ist aber weit verbreitet!? Und welche Wahl soll es denn gegeben haben? Damals gab es nix. Mit hypothetischen Weiterentwicklungen kann man nix anfangen.
Zitat:
Der Hemmschuh ist schlicht und ergreifend die fürchterlich Unix-orientierte Installation & Bedienung des GCC.
Die einen lieben es, die anderen nicht.
Zitat:
Frag doch mal nen Anfänger, ob der mit dem Compiler gut klarkommt und sich damit wohlfühlt. Jede Wette, die Antwort wird lauten "Der Compiler ist viel zu kompliziert, damit machts nicht wirklich Spaß zu arbeiten".
Das Thema ist bereits durchgekaut.
Zitat:
Oder was meinst Du, warum viele Profi-Entwickler auf den MS-Compiler und dessen IDE schwören? Nur weils so schön bunt ist? Oder könnte etwas dran sein, daß ne IDE den Arbeitsfluß verbessert?
Welchen Umkehrschluß soll ich jetzt ziehen? Kein MS-Compiler+IDE == kein Profi?
Zitat:
Apropos: mpega LibMad war mit dem Storm in <30 Sekunden zusammengeklickt.
Nur komisch das es mit den Originalquellen trotzdem nicht lief. Und es haben ja mehrfach Leute versucht, eine WOS Version mit StormC zu erstellen, ohne Erfolg .-)
Zitat:
Wäre das #ifdef-Wirrwarr nicht gewesen, wäre die in einer Minute fertig compiliert.
Wie macht man es besser? Die Bibliothek ist für mehrere Systeme gedacht und so muß man irgendwie kappseln.

[ - Antworten - Zitieren - Direktlink - ]

12.07.2005, 13:22 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Wenn die Wahl falsch gewesen wäre, dann würde heute niemand dieses Modell benutzen. Es ist aber weit verbreitet!? Und welche Wahl soll es denn gegeben haben? Damals gab es nix. Mit hypothetischen Weiterentwicklungen kann man nix anfangen.


Zu der Zeit war der GCC keinen Deut besser als Maxon/Storm/Hisoft. Die Compiler gabs damals schon und der StormC unterstützte halt WOS. Weil die Unterstützung auf dem Linker basiert, wäre es auch für die anderen Compiler kein großes Thema gewesen, daß einzubauen.

Zitat:
Zitat:
Der Hemmschuh ist schlicht und ergreifend die fürchterlich Unix-orientierte Installation & Bedienung des GCC.
Die einen lieben es, die anderen nicht.

Jep. Aber denen, die es nicht lieben, wirds aufgezwungen und mögliche andere Optionen erstickt. So geschehen beim Storm. Mag sein, daß der StormC3 nicht besonders gut ist, aber dafür comiliert er um den Faktor 6-10 schneller. Mit ein bißchen Zeit und Geld zur Weiterentwicklung... ;)

Zitat:
Zitat:
Oder was meinst Du, warum viele Profi-Entwickler auf den MS-Compiler und dessen IDE schwören? Nur weils so schön bunt ist? Oder könnte etwas dran sein, daß ne IDE den Arbeitsfluß verbessert?
Welchen Umkehrschluß soll ich jetzt ziehen? Kein MS-Compiler+IDE == kein Profi?

Nein. Profi != Zwang zur Kommandozeilen-Bedienung.

Zitat:
Zitat:
Apropos: mpega LibMad war mit dem Storm in <30 Sekunden zusammengeklickt.
Nur komisch das es mit den Originalquellen trotzdem nicht lief. Und es haben ja mehrfach Leute versucht, eine WOS Version mit StormC zu erstellen, ohne Erfolg .-)

Weil die Originalquellen eigentlich gar nicht darauf ausgelegt waren, eine WOS-Version zu erzeugen. Daß das trotzdem (auch mit den Originalquellen!) funktionierte, war ein ganz besonders finsterer Trick. Erinnerst Du Dich? Die "24Bit-Reloc"-Warnungen einfach überlesen und nochmal compilieren ;)

Zitat:
Zitat:
Wäre das #ifdef-Wirrwarr nicht gewesen, wäre die in einer Minute fertig compiliert.
Wie macht man es besser? Die Bibliothek ist für mehrere Systeme gedacht und so muß man irgendwie kappseln.

Meiner Meinung nach wäre es schlauer gewesen, die libmad-Teile komplett vom Library-Gerüst zu trennen. Auf dem Weg kann man dann (wie es der Storm-WOS für mixed binaries/Libraries erwartet) einen 68K-Teil und einen PPC-Teil getrennt compilieren. Da brauchts das #ifdef-Chaos höchstens im Library-Teil, wobei die WOS-Version dem Compiler als gewöhnliche 68K-Library (mit eingebetteten PPC-Funktionen) erscheint.

Der große Nachteil von PUP war halt, daß man bei Libraries ziemlich aufwendig mit Gate-Funktionen arbeiten muß. Das kannst Du Dir unter WOS sparen, denn das erledigt da der Linker :D

Wenn ich mal etwas Zeit finde, kümmere ich mich nochmal darum, die Trennung zu erledigen. Dank Deiner Aufräumarbeit kann man die Sourcen jetzt wenigstens gut lesen :)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

12.07.2005, 13:51 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Zu der Zeit war der GCC keinen Deut besser als Maxon/Storm/Hisoft. Die Compiler gabs damals schon und der StormC unterstützte halt WOS. Weil die Unterstützung auf dem Linker basiert, wäre es auch für die anderen Compiler kein großes Thema gewesen, daß einzubauen.

Blödsinn, zu diesem Zeitpunkt war StormC der einzige noch existierende kommerzielle C-Compiler und deren Anbieter Hack&Patch wurde ja auch deshalb nicht müde, gcc und ELF als Böse hinzustellen und alle User aufzurufen, brennende Kreuze vor die Türen von powerup-Entwicklern zu stellen.
Bis halt zu dem Zeitpunkt, ab dem sie selber gcc benutzten, weil die Entwicklung eines eigenen C-Compilers doch zuviel Arbeit war, von einem wirklich funktionierendem C++-Compiler wollen wir gar nicht erst reden. Und noch etwas später wurde StormC komplett eingestellt. An die Neuauflage für OS4 glaube ich erst, wenn ich eine funktionsfähige Version sehe.
StormC als IDE-Frontend für gcc hätten sie nebenbei gesagt, auch schon von Anfang machen können, statt erstmal eine öffentliche Schlammschlacht gegen phase5 zu beginnen.
Das Ergebnis kann man ja sehen, WOS ist tot, StormC ist tot und wo das ABI von WOS dem Programmierer mehr Komfort gibt als das von powerup, kannst Du ja gerne belegen. Für einen normalen C-Programmer ist das *ABI* etwas, das er überhaupt nicht wahrnimmt. Außer dann, wenn er unnötige Arbeit aufgehalst bekommt, weil ein Compileranbieter unbedingt ein nicht-standardkonformes verwenden mußte.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.07.2005, 15:07 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:

Das Ergebnis kann man ja sehen, WOS ist tot, StormC ist tot und wo das ABI von WOS dem Programmierer mehr Komfort gibt als das von powerup, kannst Du ja gerne belegen. Für einen normalen C-Programmer ist das *ABI* etwas, das er überhaupt nicht wahrnimmt. Außer dann, wenn er unnötige Arbeit aufgehalst bekommt, weil ein Compileranbieter unbedingt ein nicht-standardkonformes verwenden mußte.


Du meinst unnötige Arbeit wie die Rücksichtnahme auf Gate-Funktionen bei 68K-Libraries mit PUP Unterstützung? Oder das üble Rumgetrickse mit CallHook()? Das braucht man bei WOS z.B. nicht.

Das Ergebnis, daß WOS tot und Storm auf Eis gelegt ist, ist wohl weniger auf den PUP/WOS-Krieg zurückzuführen, als mehr auf den allgemeinen Niedergang des Marktes. Unter anderem aufgrund zwar interessanter, aber eben nutzloser Grabenkriege, nicht nur zwischen WOS/PUP-Verfechtern.

Eben sowas ähnliches wie das, was Du hier gerade betreibst (GCC rulez, alles andere suckt).

Reichts Dir denn nicht, daß man inzwischen mangels Alternativen nicht mehr am GCC vorbeikommt? Und ob man nun den StormC-GCC benutzt oder den blanken CLI-GCC, das ist doch wohl nun wirklich eine Frage der persönlichen Vorlieben und Möglichkeiten.

Programme, die laufen, kommen aus beiden heraus. Für meine Zwecke ist der StormC-GCC besser, weil schneller und komfortabler zu bedienen. Für andere ist der CLI-GCC mit make und dem ganzen Drumherum besser.

So einfach ist das.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

12.07.2005, 15:07 Uhr

Solar
Posts: 3680
Nutzer
Die ganze Diskussion um StormC / gcc2 / gcc3 können sich doch wirklich nur reine C-Programmierer antun!

Soweit ich mich erinnere, kann StormC nicht einmal die STL fehlerfrei compilieren (die immerhin seit mehr als sieben Jahren zum C++-Standard gehört!).

Und in Astyle habe ich immer noch ein #ifdef drin, weil die mit dem gcc2 ausgelieferte C++-Lib die Parameter zu einer so "esoterischen" Funktion wie string::compare() wohl gerne in einer anderen Reihenfolge hätte als der Standard.

Ob das immer noch der Fall ist? Keine Ahnung, gcc 2.95 benutzen heute wohl nur noch wirklich verzweifelte Menschen.

Und was das Installieren angeht... meine letzten beiden Installationen einer GCC-Umgebung sahen so aus:

emerge gcc (Gentoo Linux)
iexplore http://www.cygwin.com/setup.exe (Windows)

Wer da auf GCC schimpft, schimpft auf den falschen.

@ Ralf27:

Wenn Du jetzt erst einsteigst, vergiß C und nimm C++. Mit dem GCC 3.x geht's endlich halbwegs Standardkonform (auch wenn sie "export" immer noch nicht können... :-( ), und Du sparst Dir eine Menge Gefummel z.B. mit C-Strings und Arrays... <string> und <vector> sei Dank.

[ Dieser Beitrag wurde von Solar am 12.07.2005 um 15:09 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.07.2005, 15:13 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Solar:
Soweit ich mich erinnere, kann StormC nicht einmal die STL fehlerfrei compilieren (die immerhin seit mehr als sieben Jahren zum C++-Standard gehört!).


Er kanns, da StormC4 den GCC 2.95.2 einsetzt.

Zitat:
Und in Astyle habe ich immer noch ein #ifdef drin, weil die mit dem gcc2 ausgelieferte C++-Lib die Parameter zu einer so "esoterischen" Funktion wie string::compare() wohl gerne in einer anderen Reihenfolge hätte als der Standard.

Was hat die C++Lib mit dem Compiler an sich zu tun? Beschwer Dich bei denen, die die Lib verbockt haben.

Zitat:
Ob das immer noch der Fall ist? Keine Ahnung, gcc 2.95 benutzen heute wohl nur noch wirklich verzweifelte Menschen.

Wieso müssen die verzweifelt sein? Das erklär mal näher...

Zitat:
Und was das Installieren angeht... meine letzten beiden Installationen einer GCC-Umgebung sahen so aus:

emerge gcc (Gentoo Linux)
iexplore http://www.cygwin.com/setup.exe (Windows)

Wer da auf GCC schimpft, schimpft auf den falschen.


Wer in einem Amiga-Forum mit Installation eines Unix-Paketes nach Linux-Manier als Beispiel kommt, schimpft im falschen Forum I-)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

12.07.2005, 15:29 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Zu der Zeit war der GCC keinen Deut besser als Maxon/Storm/Hisoft.

IMHO war er besser. Heutige Versionen sind halt besser als die damaligen.
Zitat:
Die Compiler gabs damals schon und der StormC unterstützte halt WOS. Weil die Unterstützung auf dem Linker basiert, wäre es auch für die anderen Compiler kein großes Thema gewesen, daß einzubauen.
Als P5 mit PPC anfing, gab es keine PPC Version von Storm. Die kam erst später. Den Hinweis auf den Linker kann ich jetzt nicht nachvollziehen.
Zitat:
Weil die Originalquellen eigentlich gar nicht darauf ausgelegt waren, eine WOS-Version zu erzeugen.
Doch waren sie, nur das es anscheinend nur für Jarmo Lakkonen (sp?) funktioniert hat.
Zitat:
Daß das trotzdem (auch mit den Originalquellen!) funktionierte, war ein ganz besonders finsterer Trick. Erinnerst Du Dich? Die "24Bit-Reloc"-Warnungen einfach überlesen und nochmal compilieren ;)
Oder den Linker korrigieren? Ich hätte kein Vertrauen in ein Programm, das so erstellt worden ist. Das es ohne Warnungen geht, zeigt vlink.
Zitat:
Meiner Meinung nach wäre es schlauer gewesen, die libmad-Teile komplett vom Library-Gerüst zu trennen.
Sind sie doch. Oder meinst Du jetzt wrap_mpega.c?
Zitat:
Auf dem Weg kann man dann (wie es der Storm-WOS für mixed binaries/Libraries erwartet) einen 68K-Teil und einen PPC-Teil getrennt compilieren. Da brauchts das #ifdef-Chaos höchstens im Library-Teil, wobei die WOS-Version dem Compiler als gewöhnliche 68K-Library (mit eingebetteten PPC-Funktionen) erscheint.
Das ist doch genau so gelöst. Der Unterschied ist, das Storm sich noch Stubfunktionen generiert. Warum eine Lösung die nur mit einem System funktioniert? Es geht auch ohne solche Stubfuktionen und man kann __saveds auf der PPC Seite sogar weglassen.
Zitat:
Der große Nachteil von PUP war halt, daß man bei Libraries ziemlich aufwendig mit Gate-Funktionen arbeiten muß. Das kannst Du Dir unter WOS sparen, denn das erledigt da der Linker :D
Auch WOS braucht Gates, um von 68k zum PPC zu kommen. Der Unterschied ist, das PUP mit Nachrichten arbeitet und WOS direkt den PPC-Code ausführen läßt.

[ - Antworten - Zitieren - Direktlink - ]

12.07.2005, 15:35 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Solar:
emerge gcc (Gentoo Linux)
iexplore http://www.cygwin.com/setup.exe (Windows)

Es geht auch mit einem stink-normalen make.
Zitat:
Wer da auf GCC schimpft, schimpft auf den falschen.
Hast Du schon mal versucht ältere GCC Versionen mit einem aktuellen GCC zu übersetzen?

[ - Antworten - Zitieren - Direktlink - ]

12.07.2005, 15:42 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Du meinst unnötige Arbeit wie die Rücksichtnahme auf Gate-Funktionen bei 68K-Libraries mit PUP Unterstützung?

Gates haben auch WOS-Bibliotheken, die m68k-Applikationen transparent Zugriff auf den PPC gewähren.
Zitat:
Oder das üble Rumgetrickse mit CallHook()? Das braucht man bei WOS z.B. nicht.
-v bitte.
Zitat:
Unter anderem aufgrund zwar interessanter, aber eben nutzloser Grabenkriege, nicht nur zwischen WOS/PUP-Verfechtern.
Dieser Grabenkrieg wäre vermeidbar gewesen. Das Problem war nicht der Compiler.

[ - Antworten - Zitieren - Direktlink - ]

12.07.2005, 15:54 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von gni:

Es geht auch mit einem stink-normalen make.


Ja, nur nehmen Dir oben genannte Beispiele sogar den Download der Sourcen ab. Bei Cygwin (oder z.B. einem apt-get unter Debian) brauchst Du nicht einmal selbst compilieren.

Und mit "emerge eclipse-sdk" hat man sogar eine taugliche IDE dazu... aber ups, das ist ja Java... :-D

Zitat:
Hast Du schon mal versucht ältere GCC Versionen mit einem aktuellen GCC zu übersetzen?

Nö. Ich habe keinen Bedarf für ältere GCC-Versionen. ;)

[ - Antworten - Zitieren - Direktlink - ]

12.07.2005, 16:32 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Solar:
Zitat:
gni:
Es geht auch mit einem stink-normalen make.

Ja, nur nehmen Dir oben genannte Beispiele sogar den Download der Sourcen ab.
Mein make macht das auch, oops :-P
Zitat:
Zitat:
Hast Du schon mal versucht ältere GCC Versionen mit einem aktuellen GCC zu übersetzen?
Nö. Ich habe keinen Bedarf für ältere GCC-Versionen. ;)
Es soll ja auch noch Rechner geben ohne mehrere GB Hauptspeicher und "langsamer" CPU. Da möchte man schlicht keine aktuellen GCC.

[ - Antworten - Zitieren - Direktlink - ]

12.07.2005, 16:37 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von gni:

Mein make macht das auch, oops :-P


:lach:

OK, ich gebe mich geschlagen...

8)

Zitat:
Es soll ja auch noch Rechner geben ohne mehrere GB Hauptspeicher und "langsamer" CPU. Da möchte man schlicht keine aktuellen GCC.

Meine "Entwicklungsmaschine" ist immer noch derselbe 500 MHz Pentium III Laptop von 1999. Inzwischen allerdings mit 288 MB Hauptspeicher. Ich gebe zu, Linux aus Sourcen installieren hat eine Weile gedauert, und Eclipse könnte auch schneller sein. Aber ich bin vom Amiga ja einiges gewöhnt.

:lach:

[ - Antworten - Zitieren - Direktlink - ]

12.07.2005, 16:46 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Solar:
Zitat:
gni:
Mein make macht das auch, oops :-P

:lach:
OK, ich gebe mich geschlagen...
8)

Ok, ich habe das "cd /usr/ports/lang/gcc[234][0-9]" vergessen ;-)

[ - Antworten - Zitieren - Direktlink - ]

12.07.2005, 19:27 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Du meinst unnötige Arbeit wie die Rücksichtnahme auf Gate-Funktionen bei 68K-Libraries mit PUP Unterstützung? Oder das üble Rumgetrickse mit CallHook()? Das braucht man bei WOS z.B. nicht.

Wen interessiert das in Zeiten von reinen ppc-Betriebssystemen? Es geht doch wohl darum, daß man den in StormC enthaltenen gcc nicht durch eine aktuelle Version ersetzen kann, und daß es sogar noch Leute gibt, die deshalb aktuelle gcc-Versionen schlechtreden und versuchen einen künstlichen Bedarf an veralteten gcc-Versionen herbeizureden.
Absolut durchschaubar diese Verhaltensweise, allerdings hat man manchmal wirklich den Eindruck, daß diese Leute selber glauben, was sie da reden.
Zitat:
Eben sowas ähnliches wie das, was Du hier gerade betreibst (GCC rulez, alles andere suckt).
So etwas betreibe ich hier überhaupt nicht. Fakt ist, daß phase5 damals auf den Compiler gesetzt haben, der heute noch weiterentwickelt wird und auf das ABI, das auch in heutigen, noch weiterentwickelten Betriebssystemen verwendet wird.
Während die Firma, die von neuen ppc-Erweiterungskarten bis hin zu einer ppc-Softwareflut alles versprochen hat, nichts geleistet hat, außer einem halbgaren Betriebssystemupdate und einem zügigen Verlassen des Marktes, inkl. Davonstehlen vom Support gegenüber den Kunden, die die Software bezahlt haben.
Zitat:
Reichts Dir denn nicht, daß man inzwischen mangels Alternativen nicht mehr am GCC vorbeikommt? Und ob man nun den StormC-GCC benutzt oder den blanken CLI-GCC, das ist doch wohl nun wirklich eine Frage der persönlichen Vorlieben und Möglichkeiten.
Was soll der Blödsinn? Kannst Du mal aufhören, mir zu unterstellen, daß ich mich über die fehlenden Wahlmöglichkeiten freue?
Fakt ist, daß ich keine Wahl habe. Es gibt heute nur gcc und ich würde ihn gerne mit einer komfortablen IDE benutzen. Und es war H&Ps Entscheidung, ihn so zu patchen, daß es heute unmöglich ist, ihn zu benutzen.
Benutzen heißt, ihn auch in einer aktuellen Version benutzen zu können, in der man in Entwicklerforen auch Hilfestellung bekommen kann. Und eben nicht raten zu müssen, ob das Problem am Compiler oder an der eigenen Software liegt. Oder gar zu wissen, daß es am Compiler liegt.
Zitat:
Programme, die laufen, kommen aus beiden heraus.
Für Software aus dem Amiga-Hobbybereich vielleicht. Für Software, die auch mal Code von anderen Plattformen benutzen muß oder einfach nur die typische Größe eines Amiga-Hobbyprogramms überschreitet, eben nicht.
Zitat:
Für meine Zwecke ist der StormC-GCC besser, weil schneller und komfortabler zu bedienen. Für andere ist der CLI-GCC mit make und dem ganzen Drumherum besser.

So einfach ist das.


Nicht der CLI-Aufruf macht den aktuellen gcc besser, sondern die noch vorhandene Weiterentwicklung und das Mithalten mit dem Standard der Programmiersprache.
IDEs auf allen anderen Plattformen machen es vor. Man kann einen C/C++ Compiler benutzen, ohne ihn patchen zu müssen. Und das hätten wir auch haben können, wenn nicht eine gewissen Firma diesen Grabenkrieg begonnen hätte, um sich selbst zu profilieren. Immerhin haben sie es damit geschafft, sich von einer unbedeutenden Softwarefirma zum OS-Entwickler aufzuschwingen. Um jetzt, wo es nichts mehr abzuzocken gibt, wieder eine unbedeutende Softwarefirma zu sein.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 12.07.2005 um 19:31 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

13.07.2005, 09:13 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Holger:
Es geht doch wohl darum, daß man den in StormC enthaltenen gcc nicht durch eine aktuelle Version ersetzen kann

Sagen wir es mal so: Theoretisch gehts es. In der Praxis ist es aufwändiger als nötig, weil der Amiga-spezifische Storm-Code nicht sauber vom Rest des Compilers getrennt worden ist.
Zitat:
und daß es sogar noch Leute gibt, die deshalb aktuelle gcc-Versionen schlechtreden und versuchen einen künstlichen Bedarf an veralteten gcc-Versionen herbeizureden.
Ich habe aus den Quellen des StormGCC einen "normalen" Port gemacht. Bis jetzt ist es nur ein GCC 2.95.4, da zum einen noch immer nicht alles so läuft, wie ich es gern hätte und zum anderen weil ich keine Zeit habe, auf GCC3 umzustellen.
Zitat:
Fakt ist, daß phase5 damals auf den Compiler gesetzt haben, der heute noch weiterentwickelt wird und auf das ABI, das auch in heutigen, noch weiterentwickelten Betriebssystemen verwendet wird.
Ich würde ja gerne mal hören, was einer damaligen glühensten Verfechter von WarpOS/StormC dazu zu sagen hat.
Zitat:
Während die Firma, die von neuen ppc-Erweiterungskarten bis hin zu einer ppc-Softwareflut alles versprochen hat,
An das Escena-G3 Board erinnert sich doch niemand mehr ;-)
Zitat:
Fakt ist, daß ich keine Wahl habe. Es gibt heute nur gcc und ich würde ihn gerne mit einer komfortablen IDE benutzen.
Er meinte, das es ein kommerzielle Compiler schwer hat, wenn gleichzeitig ein gleichwertiges kostenloses Produkt auf dem Markt ist.
Zitat:
Und es war H&Ps Entscheidung, ihn so zu patchen, daß es heute unmöglich ist, ihn zu benutzen. Benutzen heißt, ihn auch in einer aktuellen Version benutzen zu können, in der man in Entwicklerforen auch Hilfestellung bekommen kann.
Mit etwas gutem Willen könnte man das ARexx-Interface aus den StormGCC Quellen extrahieren und dann aktuellere Versionen benutzen, allerdings eben nicht für WarpOS.
Zitat:
IDEs auf allen anderen Plattformen machen es vor. Man kann einen C/C++ Compiler benutzen, ohne ihn patchen zu müssen. Und das hätten wir auch haben können, wenn nicht eine gewissen Firma diesen Grabenkrieg begonnen hätte, um sich selbst zu profilieren.
H&P hat einen IPC-Mechanismus eingebaut. Obs ohne gegangen wäre, kann ich nicht sagen.

[ Dieser Beitrag wurde von gni am 13.07.2005 um 09:14 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

14.07.2005, 00:56 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von gni:
Sagen wir es mal so: Theoretisch gehts es. In der Praxis ist es aufwändiger als nötig, weil der Amiga-spezifische Storm-Code nicht sauber vom Rest des Compilers getrennt worden ist.

Das meinte ich auch. Letztendlich ist bei Software nahezu alles möglich und nur eine Frage des Aufwands.
Zitat:
Mit etwas gutem Willen könnte man das ARexx-Interface aus den StormGCC Quellen extrahieren und dann aktuellere Versionen benutzen, allerdings eben nicht für WarpOS.
Soll heißen, mit WarpOS als target? Inwieweit braucht man eigentlich tatsächlich aktiven support dafür?
Letztendlich gibt's ja auch ne pup-emu. Also prinzipiell kann man auch konventionellen ppc-code ausführen und alles, worum es Programmierern geht, ist doch ppc-code und 68k-code in einem executable zu verpacken, dem man von außen nicht ansieht, was da alles kompliziertes passiert, oder?
So etwas könnte man doch mit einem amiga-spezifischen tool machen, das man in der build-chain ganz ans Ende stellt, ohne den gcc überhaupt anzufassen.
Oder geht's noch um irgendetwas anderes?

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 14.07.2005 um 00:58 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

14.07.2005, 01:24 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Soll heißen, mit WarpOS als target? Inwieweit braucht man eigentlich tatsächlich aktiven support dafür?
Letztendlich gibt's ja auch ne pup-emu. Also prinzipiell kann man auch konventionellen ppc-code ausführen und alles, worum es Programmierern geht, ist doch ppc-code und 68k-code in einem executable zu verpacken, dem man von außen nicht ansieht, was da alles kompliziertes passiert, oder?
So etwas könnte man doch mit einem amiga-spezifischen tool machen, das man in der build-chain ganz ans Ende stellt, ohne den gcc überhaupt anzufassen.
Oder geht's noch um irgendetwas anderes?


Ja, da gehts um einiges anderes ;) Nein, streng genommen ist das einzige Problem, den PPC-Code ins Hunk-Format zu kriegen und dann einen passenden Linker zu haben, der daraus (ggf. zusammen mit 68K-Code) ein funktionsfähiges Executable macht. Ich entsinne mich noch dunkel an die "Krücke" aout2hunk für die ersten AOS68K-GCCs...

Ich denke allerdings nicht, daß sich der ganze Aufwand wirklich lohnt. Für die wenigen WOS-Programme, die heute noch gepflegt werden, kann man (immer noch) den StormC3/4 nehmen, OS4/MOS/AROS etc. pp. kommen mit dem einfacher anzupassenden Standard-GCC ja bereits prima klar.

Um StormC4 (bzw. dessen IDE) an OS4 anzupassen ists vor allem notwendig (soweit ich es verstanden habe), den Debugger aus der ganzen IDE auszuklammern (der würde unter OS4 eh nicht mehr tun und hatte in der 68K-Fassung so seine Probleme mit dem GCC-Code) und den GCC mit einem ARexx-Port zu versehen, damit die Storm Shell an die Fehlermeldungen herankommt.

Um ehrlich zu sein: Mir persönlich wäre es lieber, wenn man die adtools-Initiative nutzt, den GCC immer fein aktuell hält in allen Geschmacksrichtungen und dazu passend eine schöne, leicht bedienbare und komfortable IDE zimmert (vielleicht mit Hilfe der Leute, die die Werkzeuge in deep kennen? I-) ). Die könnte man wahlweise auch in 68K halten, da dieses ja auf allen Systemen (Ausnahme AROS, aber das sollte kein großes Problem sein) läuft. Dann leidet die Geschwindigkeit gerade auf echten 68K-Systemen zwar spürbar, aber wozu gibts WinUAE/Amithlon? I-)

Einziges Sorgenkind wäre dann nur noch der GDB, dem bessere Bedienbarkeit durchaus gut zu Gesicht stünde.

Oder man baut ein Amiga-spezifischer Debugger, der sich einfach in eine solche IDE einbinden läßt.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 14.07.2005 um 01:25 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

14.07.2005, 01:43 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Nein, streng genommen ist das einzige Problem, den PPC-Code ins Hunk-Format zu kriegen und dann einen passenden Linker zu haben, der daraus (ggf. zusammen mit 68K-Code) ein funktionsfähiges Executable macht. Ich entsinne mich noch dunkel an die "Krücke" aout2hunk für die ersten AOS68K-GCCs...

Hmm, ich kann mich erinnern, daß ich damals für powerup eine ziemlich einfache Lösung hatte, bei der das ELF binary, so wie es war, in das 68k Programm eingebettet wurde. Ganz so, wie mancher größere textpassagen oder Bilddaten included hat.
Die powerup-lib hatte eine Funktion, die das ELF-file auch direkt aus dem RAM laden konnte.
Zitat:
Ich denke allerdings nicht, daß sich der ganze Aufwand wirklich lohnt.
Das ist eine andere Frage 8)
Zitat:
Um ehrlich zu sein: Mir persönlich wäre es lieber, wenn man die adtools-Initiative nutzt, den GCC immer fein aktuell hält in allen Geschmacksrichtungen und dazu passend eine schöne, leicht bedienbare und komfortable IDE zimmert.
Klingt nach einer guten Sache. Ist wie immer eine Frage nach Aufwand und Resourcen.
Zitat:
Die könnte man wahlweise auch in 68K halten, da dieses ja auf allen Systemen (Ausnahme AROS, aber das sollte kein großes Problem sein) läuft. Dann leidet die Geschwindigkeit gerade auf echten 68K-Systemen zwar spürbar, aber wozu gibts WinUAE/Amithlon? I-)
Leidet die Geschwindigkeit auf echten 68K-Systemen, weil es die Software dann überhaupt für solche Systeme gibt? Oder meinst Du, weil alle Entwickler nur an 68k-emu Systemen arbeiten und keiner mal auf "classic" testet?
Zitat:
Oder man baut ein Amiga-spezifischer Debugger, der sich einfach in eine solche IDE einbinden läßt.
Ja wenn wir alle mehr Zeit hätten... Auf Schlaf, Freizeit und Job kann man ja verzichten...aber selbst dann sind's nur 24h/d.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]


-1- 2 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > StormC 4 oder GoldED Studio AIX: C/C++ IDE [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.