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

amiga-news.de Forum > Programmierung > SAS-C und GST [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

27.12.2006, 17:05 Uhr

ZeroG
Posts: 1486
Nutzer
Hallo,

mache gerade erste versuche mit dem uralt Compiler SAS-C (6.58) und wollte ihm gerne die benutzung von .gst-files abgewöhen. Leider habe ich im Handbuch nichts darüber gefunden wie oder ob das geht.

Kennt sich hier vielleicht noch jemand von den üblichen Verdächtigen ( ;) ) damit aus?

[ - Antworten - Zitieren - Direktlink - ]

27.12.2006, 19:26 Uhr

Holger
Posts: 8090
Nutzer
Warum setzen sich nur immer alle in den Kopf, unbedingt Versuche mit Uralt-Compilern machen zu müssen?

Wie wär's mit COBOL? :O

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

[ - Antworten - Zitieren - Direktlink - ]

27.12.2006, 22:03 Uhr

geit
Posts: 332
[Ex-Mitglied]

Also ich muß mich leider meinem Vorredner anschließen. Der SASC ist nun wirklich sehr veraltet und wird nicht weiter entwickelt.

Wenn du einen einfach zu installierenden und zu benutzenden Kompiler suchst, dann installier VBCC.

Als Bonbon kannst du Deine Programme gleich auch nativ für andere Platformen übersetzen.

Geit

[ - Antworten - Zitieren - Direktlink - ]

27.12.2006, 22:46 Uhr

ZeroG
Posts: 1486
Nutzer
:D War mir irgendwie klar das sowas kommt.

Ich versuch mich eigendlich an einer OS4 portierung von FlashPlayer 1.3.
Das ganze wurde/wird vom eigendlichen Autor mit genau der SAS-C Version entwickelt und GCC mäckelt (völlig zu recht, ist echt grusselig wieviel Fehler und Warnungen GCC ausspuckt) richtig viel an den Quelltexten rum.
Da hab ich mir gedacht:
Wenn ich schon den Quelltext so umfangreich änder, soll der Gute auch was davon haben und am besten gleich mit den "bereinigten" Quelltexten weiterarbeiten.
Davon hätten alle was, der Autor (wahrscheinlich) stabileren Code und ich (und mögliche andere) weniger arbeit mit dem Port der nächsten Version.

Da ich SAS-C besitze (aber noch nie wirklich was mit gemacht habe) wollte ich mir mal ansehen wie sich meine Änderungen auswirken.
Wenn alles problemlos mit SAS-C compiliert wird der Autor meine Änderungen williger annehmen (hoffe ich).

[ - Antworten - Zitieren - Direktlink - ]

28.12.2006, 01:11 Uhr

platon42
Posts: 400
[Ex-Mitglied]
@ZeroG:
Wenn Du die "scopts" aufrufst, gibt es unter "Compiler Options" ein GST-Stringgadget. Einfach leermachen. In der Datei SCOPTIONS lautet die Zeile GLOBALSYMBOLTABLE=<file>.

Und warum man sich mit SAS/C statt GCC herumschlägt ist recht einfach: GCC erzeugt nicht immer besseren Code und SAS/C ist auf einem 68060@50MHz schneller beim Kompilieren von Poseidon mit vollen Optimierungen als auf einem 1 GHz PPC mit GCC.

Solche sinnvollen Dinge wie Caching und precompiled Headers gibts beim GCC ja nicht, der fängt bei jeder Datei bei Null an.

Ich bin nicht mehr so jung, ich kann nicht warten :)
--
--
Best Regards

Chris Hodges

[ - Antworten - Zitieren - Direktlink - ]

28.12.2006, 01:41 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von platon42:
Solche sinnvollen Dinge wie Caching und precompiled Headers gibts beim GCC ja nicht, der fängt bei jeder Datei bei Null an.


Hmm, als UAE-Nutzer, dem Caching quasi vom Host-OS geschenkt wird, habe ich mich schon lange nicht mehr damit beschäftigt. Deshalb meine Frage: gibt es (k)ein freies Tool, das so wie anno dazumal DynamiCache funktioniert?

Das würde gcc wahrscheinlich drastisch beschleunigen, was ich aber nicht weiß, weil ich damals noch keinen gcc verwendet habe. Aber wenn ich mich an den Nutzen des tools zurückerinnere, wäre das vermutlich eine große Lücke, und interessante Aufgabe, für jemanden, der nicht weiß, was er programmieren soll, falls es kein solches tool (mehr) gibt.

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

[ - Antworten - Zitieren - Direktlink - ]

28.12.2006, 17:47 Uhr

ZeroG
Posts: 1486
Nutzer
@platon42:
Hat funktioniert, Danke.

[ - Antworten - Zitieren - Direktlink - ]

29.12.2006, 15:00 Uhr

akl
Posts: 265
Nutzer
@platon42:
Sehe ich auch so. Übrigens ist SAS/C ohne GST teilweise deutlich langsamer, von daher empfiehlt sich ggf. doch das Erzeugen eines neuen, zumindest für die reinen OS-Includes.

[ - Antworten - Zitieren - Direktlink - ]

29.12.2006, 15:04 Uhr

akl
Posts: 265
Nutzer
@geit:
vbcc in allen Ehren (ich lerne ihn auch gerade zu schätzen), aber man muss den SAS/C ja nicht schlechter machen, als er ist - der 68060 ist schliesslich auch nicht mehr weiterentwickelt worden. So gesehen reicht SAS/C für jede existierende 68k-Emulation vollkommen aus. Spannend wird es erst mit diversen angekündigten Coldfire-Karten, für die man vielleicht anders optimieren könnte.

[ - Antworten - Zitieren - Direktlink - ]

02.01.2007, 12:38 Uhr

Solar
Posts: 3674
Nutzer
Zitat:
Original von platon42:

Solche sinnvollen Dinge wie Caching und precompiled Headers gibts beim GCC ja nicht, der fängt bei jeder Datei bei Null an.


Du meinst Caching und precompiled Headers?

[ - Antworten - Zitieren - Direktlink - ]

03.01.2007, 12:37 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Solar:
Du meinst Caching

Ich wußte gar nicht, das das ein GCC Feature ist...
Zitat:
precompiled Headers?
Unbrauchbar.

[ - Antworten - Zitieren - Direktlink - ]

03.01.2007, 12:51 Uhr

gni
Posts: 1106
Nutzer
Zitat:
platon42:
Und warum man sich mit SAS/C statt GCC herumschlägt ist recht einfach: GCC erzeugt nicht immer besseren Code

Das glauben Dir die hier versammelten GCC Experten doch eh nicht ;)
Zitat:
und SAS/C ist auf einem 68060@50MHz schneller beim Kompilieren von Poseidon mit vollen Optimierungen als auf einem 1 GHz PPC mit GCC.
Benutzt Du für Poseidon eine GST?
Zitat:
precompiled Headers gibts beim GCC ja nicht
Ab 3.4 (?) gibt sowas schon, obs brauchbar ist, sei dahingestellt. Der AmigaOS Port unterstützt dieses Feature jedoch nicht, weil die derzeitige Implementierung im GCC nicht unter AmigaOS funktioniert.

[ - Antworten - Zitieren - Direktlink - ]

03.01.2007, 12:59 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Holger:
gibt es (k)ein freies Tool, das so wie anno dazumal DynamiCache funktioniert?

Warum nicht gleich DynamiCache verwenden? Das konnte man direkt vom P5-Ftp Server bekommen.
Zitat:
Das würde gcc wahrscheinlich drastisch beschleunigen, was ich aber nicht weiß, weil ich damals noch keinen gcc verwendet habe.
Sollte man denken, aber so richtig groß ist der Effekt nicht. Es wird zwar nichts mehr von Platte geladen, aber es wird trotzdem nicht viel schneller. Da würde es mehr bringen wenn, der Compiler residentfähig wäre, da fielen Laden+Relokation weg. Noch besser wäre es, wenn der GCC in Libraries aufgeteilt wäre wie der SAS/C.


[ - Antworten - Zitieren - Direktlink - ]

03.01.2007, 13:25 Uhr

Solar
Posts: 3674
Nutzer
Zitat:
Original von gni:
Zitat:
Solar:
Du meinst Caching

Ich wußte gar nicht, das das ein GCC Feature ist...

IMHO spielt es keine große Rolle, ob ein Feature "eingebaut" ist oder über ein zusätzliches Tool erreicht wird, es sei denn, dieses Tool wäre sehr schwer zum Laufen zu bringen.

OS 3.1 kann out-of-the-box keine WAV-Files abspielen, dafür gibt's einen Datatype. Heißt das, daß OS 3.1 keine WAVs "kann"? Wohl nicht.

[ - Antworten - Zitieren - Direktlink - ]

04.01.2007, 00:22 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von gni:
Warum nicht gleich DynamiCache verwenden? Das konnte man direkt vom P5-Ftp Server bekommen.

Kann ja verwenden, wer es hat. Meine Frage zielte darauf ab, ob es ein Tool gibt, das man jemanden, der es nicht hat, empfehlen könnte. Also für das man auch heute eine legale Bezugsquelle angeben kann.
Zitat:
Sollte man denken, aber so richtig groß ist der Effekt nicht. Es wird zwar nichts mehr von Platte geladen, aber es wird trotzdem nicht viel schneller. Da würde es mehr bringen wenn, der Compiler residentfähig wäre, da fielen Laden+Relokation weg. Noch besser wäre es, wenn der GCC in Libraries aufgeteilt wäre wie der SAS/C.
Na ja, aus dem Bauch heraus eine Ursache für ein Performance-Problem zu nennen, ist nie ein guter Weg. Und der gcc ist nunmal so, wie er ist. Wesentliche Änderungen, die von den main-Entwicklern nicht übernommen werden würden, bringen nur mehr Aufwand als Nutzen. Das hat man bei StormC4/WarpOS gesehen.

Mich interessieren nur Ansatzpunkte, die auf stabilen Schnittstellen, wie bei DynamiCache das Dateisystem, basieren...

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

[ - Antworten - Zitieren - Direktlink - ]

04.01.2007, 00:39 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von gni:
Zitat:
platon42:
Und warum man sich mit SAS/C statt GCC herumschlägt ist recht einfach: GCC erzeugt nicht immer besseren Code

Das glauben Dir die hier versammelten GCC Experten doch eh nicht ;)

Falls Du "Leute" wie mich damit meinst: ich glaube, dass sich viel zu viele Leute mit der Frage "welcher compiler erzeugt den besseren code" herumschlagen, die mit dem compiler ihrer Wahl letztendlich nicht mal ein lauffähiges Programm gebacken bekommen, die Qualität ihres codes ganz außen vor gelassen.

Der Ausgangspunkt dieses Threads war auch die Anfrage wie man das caching-feature abschalten kann.

Wenn jemand meint, mit Uralt-compilern etc. die besten Ergebnisse erzielen zu können, soll er damit glücklich werden. Er muss sich halt nur darüber im Klaren sein, dass er von der Außenwelt kaum Hilfestellungen dazu erwarten kann. Die Welt dreht sich nämlich währenddessen weiter.

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

[ - Antworten - Zitieren - Direktlink - ]

04.01.2007, 11:03 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Holger:
Meine Frage zielte darauf ab, ob es ein [Caching-]Tool gibt, das man jemanden, der es nicht hat, empfehlen könnte.

Es gibt zwar im AmiNet Programme dieser Art, aber zu den meisten davon kann ich nicht sagen. FDA wurde von seinem Autor immer als Ersatz von DynamiCache dargestellt. Die im AmiNet verfügbare Version ist jedoch längst von einem TimeOut betroffen.
Zitat:
Und der gcc ist nunmal so, wie er ist. Wesentliche Änderungen, die von den main-Entwicklern nicht übernommen werden würden, bringen nur mehr Aufwand als Nutzen.
Das ist seit langem bekannt ;)
Zitat:
Das hat man bei StormC4/WarpOS gesehen.
Dieser "Port" wurde auch völlig falsch gemacht, aber vermutlich war das auch Absicht.

[ - Antworten - Zitieren - Direktlink - ]

04.01.2007, 11:15 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Holger:
Wenn jemand meint, mit Uralt-compilern etc. die besten Ergebnisse erzielen zu können, soll er damit glücklich werden.

Mich _stört_ diese pauschale Beurteilung des SAS/C als unbrauchbar u.a. weil veraltet. Das ist pure Ignoranz oder einfach nur Dummheit.

[ - Antworten - Zitieren - Direktlink - ]

04.01.2007, 12:04 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von gni:
Mich _stört_ diese pauschale Beurteilung des SAS/C als unbrauchbar u.a. weil veraltet.

Steht da das Wort >unbrauchbar<?
Ich habe in dem nicht von Dir zitierten Satz eindeutig gesagt, worum es geht. Alte compiler werden nicht mehr weiterentwickelt, für nicht mehr weiterentwickelte compiler findest Du kaum Hilfe, Tendenz grundsätzlich immer weiter sinkend.

Und dass Nutzer alter compiler dazu tendieren, ihre Programme an den compiler anzupassen, braucht man nicht weiter zu erwähnen, oder?

Warum benutzt der Eröffner des Threads diesen Uralt-compiler? Weil jemand anderes diesen compiler benutzt, dessen source code mit einem anderen (aktuelleren) compiler nicht übersetzt werden kann und die (berechtigte) Befürchtung besteht, dass eine Verbesserung des codes nicht mehr mit dem Uralt-compiler funktioniert.

ZeroGs Bemühungen sind echt beeindruckend, normalerweise macht sich keiner solche Mühe, anders gesagt, normalerweise wäre jemand wie der FlashPlayer-Autor dazu verdammt, allein an seinem Projekt rumzuwerkeln, weil eben keiner bereit ist, dafür einen uralt-compiler zu entstauben.

Wen das nicht stört, oder wer eh nicht open source entwickelt, und wer niemals Hilfe von dritten benötigt, für den mag das ja eine Option sein. Aber das sagte ich ja schon.

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

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > SAS-C und GST [ - Suche - Neue Beiträge - Registrieren - Login - ]


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