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

amiga-news.de Forum > Programmierung > SASC [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 [ - Beitrag schreiben - ]

13.08.2005, 18:47 Uhr

MaikG
Posts: 5172
Nutzer
Wo bekommt man SASC her? Mein Lieblings Filemanager hat ein paar
Bugs ist nun aber OpenSource. Nun wollte ich versuchen die Fehler
zu korregieren. Bin aber mit vbcc schon am Compiliern gescheitert.
Er scheint in SASC geschrieben zu sein, finde den Compiler jedoch
nicht im Internet.

[ - Antworten - Zitieren - Direktlink - ]

13.08.2005, 19:12 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
AFAIK garnicht mehr, aber so schwer ist das "Portieren" auf einen anderen Compiler doch auch nicht, dass man es unbedingt mit SASC machen muss.

Andererseits werden die OpenSource Dinger (Opus4,....) sowieso von anderen gepflegt und da wäre es eher anzuraten sich einfach mit denen in Verbindung zu setzen.

[ - Antworten - Zitieren - Direktlink - ]

13.08.2005, 23:38 Uhr

MaikG
Posts: 5172
Nutzer
>AFAIK garnicht mehr, aber so schwer ist das "Portieren"
>auf einen anderen Compiler doch auch nicht, dass man es
>unbedingt mit SASC machen muss.

Doch wenn man C sogut wie nicht kann...

>Andererseits werden die OpenSource Dinger (Opus4,....)
>sowieso von anderen gepflegt und da wäre es eher
>anzuraten sich einfach mit denen in Verbindung zu setzen.

"Filemaster"-Aminet wird soweit ich weiss von niemand mehr gepflegt,
verbesserungen sind kaum nötig. Wichtig sind eher die Enforcerhits,
diese können durchaus mal zum absturz führen.

[ - Antworten - Zitieren - Direktlink - ]

14.08.2005, 03:34 Uhr

whose
Posts: 2156
Nutzer
@MaikG:

Ich könnte mir das mal ansehen, aber versprechen kann ich nichts. Geht nur, wenn ich die Zeit dafür übrig hab.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

14.08.2005, 10:51 Uhr

MaikG
Posts: 5172
Nutzer
Das währe nicht schlecht den Sourcecode gibt es hier:
http://main.aminet.net/dev/src/FM2000.lha

[ - Antworten - Zitieren - Direktlink - ]

15.08.2005, 14:48 Uhr

whose
Posts: 2156
Nutzer
@MaikG:

So, ich habs mir nun mal angesehen. Das kann etwas dauern, weil da
die BGUI.library verwendet wird, da muß ich mir jetzt mal fix die
Includes für besorgen und ein paar Einfügungen in die FM-Sourcen machen.

Gott sei Dank hat der mit dem phxass gearbeitet bei den Assembler-Teilen,
sonst wärs aufwändig geworden.

Also, wird noch ein paar Tage dauern, bevor man das mit dem GCC übersetzen
kann.

Grüße


Nachtrag: Da bekommt man richtig Spaß mit, habe ich gerade bemerkt. Zirkelbezüge in den Includes, Parameterübergabe in Registern, ohne Rücksicht auf fremde Compiler... spaßiges Ding :D Geh mal ruhig von mindestens einer Woche aus, weil ich zusätzlich die Includes etwas umzimmern muß, um die Zirkelbezüge da raus zu kriegen.

--
---

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


[ Dieser Beitrag wurde von whose am 15.08.2005 um 15:29 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

15.08.2005, 16:00 Uhr

MaikG
Posts: 5172
Nutzer
>Also, wird noch ein paar Tage dauern, bevor man das mit
>dem GCC übersetzen kann.


und GCC bekommt man aber im Internet?


>Nachtrag: Da bekommt man richtig Spaß mit, habe ich gerade
>bemerkt. Zirkelbezüge in den Includes, Parameterübergabe
>in Registern, ohne Rücksicht auf fremde Compiler...
>spaßiges Ding :D Geh mal ruhig von mindestens einer Woche
>aus, weil ich zusätzlich die Includes etwas umzimmern muß,
>um die Zirkelbezüge da raus zu kriegen.

Ist nicht sauber programmiert, aber von der Geschwindigkeit
und Funktionalität sehr gut.
Ich hab Zeit, das ist kein problem.

[ - Antworten - Zitieren - Direktlink - ]

15.08.2005, 17:17 Uhr

gni
Posts: 1106
Nutzer
Zitat:
MaikG:
und GCC bekommt man aber im Internet?

Ja.

[ - Antworten - Zitieren - Direktlink - ]

15.08.2005, 17:19 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Also, wird noch ein paar Tage dauern, bevor man das mit dem GCC übersetzen.

Es wäre nett, wenn man die Quellen danach immernoch mit SAS/C übersetzen kann.

[ - Antworten - Zitieren - Direktlink - ]

15.08.2005, 18:03 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Zitat:
whose:
Also, wird noch ein paar Tage dauern, bevor man das mit dem GCC übersetzen.

Es wäre nett, wenn man die Quellen danach immernoch mit SAS/C übersetzen kann.

Ich gebe mir alle erdenkliche Mühe :D

Leider kann ich das nicht direkt überprüfen, weil ich den SAS selbst nicht habe. Könntest Du das dann erledigen? Normalerweise sollte es da keinen Streß geben, die register __...-Klamotten erschlage ich korrekt mit #defines bzw. überlege noch, ob ich da nicht besser sdi für einsetze.

Alles andere ist nur Fleißarbeit, dutzendfache #include rausschmeißen, unsinnige Vorwärtsdeklarationen, fehlende void etc. pp...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

15.08.2005, 19:22 Uhr

geit
Posts: 332
[Ex-Mitglied]
@whose:

Nimm SDI damit wird es sauber und übersichtlich.

Wenn Du alles selber machst, ist das nur unnütze Arbeit und mit SDI bist Du OS und Compiler unabhängig.

Sie es mal so, wenn man nach dem Umsetzen automatisch ein neues OS nativ beglücken kann, ist das doch eine feine Sache! :)

Geit

[ - Antworten - Zitieren - Direktlink - ]

15.08.2005, 19:31 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von geit:
@whose:

Nimm SDI damit wird es sauber und übersichtlich.


So dachte ich mir das jedenfalls :D

Zitat:
Sie es mal so, wenn man nach dem Umsetzen automatisch ein neues OS nativ beglücken kann, ist das doch eine feine Sache! :)

Ganz so trivial ist das im Fall von Filemaster leider nicht, mir sind jetzt schon ein paar Stellen im Source begegnet, wo übelst getrickst wird und die unter OS4/MOS mit Sicherheit Ärger machen. Aber das kann man ja später noch bereinigen, wenn gewünscht.

Vorerst gehts darum, daß Teil "halbwegs sauber" durch den GCC und alle anderen Compiler zu bekommen, dann kommen die Hits an die Reihe.

Irgendwann vielleicht dann auch Ports/Anpassungen auf OS4/MOS, wenn jemand Lust dazu hat... I-)

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 15.08.2005 um 19:34 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

15.08.2005, 23:10 Uhr

MaikG
Posts: 5172
Nutzer
>Ganz so trivial ist das im Fall von Filemaster leider
>nicht, mir sind jetzt schon ein paar Stellen im Source
>begegnet, wo übelst getrickst wird und die unter OS4/MOS
>mit Sicherheit Ärger machen. Aber das kann man ja später
>noch bereinigen, wenn gewünscht.

>Vorerst gehts darum, daß Teil "halbwegs sauber" durch den
>GCC und alle anderen Compiler zu bekommen, dann kommen
>die Hits an die Reihe.

Willst du die Hits auch gleich mit weck machen?
Cool.
Beim Bildanzeiger wird z.B. "getrickst" da wird die
ModeID von der Datei geöffnet, nur wenn das ein Grafikkarten
Screen ist wird kein Bild gezeichnet. FM macht das nur
mit Amiga-Screens.

[ - Antworten - Zitieren - Direktlink - ]

15.08.2005, 23:44 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
Willst du die Hits auch gleich mit weck machen?
Cool.


Zumindest in so weit, wie es der Code überhaupt zuläßt. So tief bin ich noch nicht drin, um definitiv sagen zu können, daß alle Hits relativ einfach zu kriegen sind (soll heißen: Ohne massiven Umbau der Quellen).

Zitat:
Beim Bildanzeiger wird z.B. "getrickst" da wird die
ModeID von der Datei geöffnet, nur wenn das ein Grafikkarten
Screen ist wird kein Bild gezeichnet. FM macht das nur
mit Amiga-Screens.


Ja, das isn "toller" Trick, den habe ich auch schon gesehen :D

Ich denke, die Funktion kann man dann noch, wenn die Grundlagen "erschlagen" sind, in Angriff nehmen. Die hängt nämlich nicht mit gar so vielen Modulen zusammen wie der Rest des Quellcodes.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

16.08.2005, 10:31 Uhr

MaikG
Posts: 5172
Nutzer
>Zumindest in so weit, wie es der Code überhaupt zuläßt.
>So tief bin ich noch nicht drin, um definitiv sagen zu
>können, daß alle Hits relativ einfach zu kriegen sind
>(soll heißen: Ohne massiven Umbau der Quellen).


Ein Hit weniger ist schon besser als nichts.

Cyberguard hat öfters etwas mit ReadLong 0000008
angezeigt.

Also in Basic vielleicht der Fehler:
inbuf&=Allocmem...

.
.
.


a&=Peekl ibuf&+8

[ - Antworten - Zitieren - Direktlink - ]

19.08.2005, 09:43 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
>Zumindest in so weit, wie es der Code überhaupt zuläßt.
>So tief bin ich noch nicht drin, um definitiv sagen zu
>können, daß alle Hits relativ einfach zu kriegen sind
>(soll heißen: Ohne massiven Umbau der Quellen).


Ein Hit weniger ist schon besser als nichts.

Cyberguard hat öfters etwas mit ReadLong 0000008
angezeigt.

Also in Basic vielleicht der Fehler:
inbuf&=Allocmem...

.
.
.


a&=Peekl ibuf&+8


Ja, sowas taucht da im Quellcode auch dann und wann mal auf, sollte aber keinen Hit erzeugen (obwohl... "Sag niemals nie" I-) ).

Wird aber noch etwas dauern, die programmeigenen Includes sind schon ne Lustbarkeit für sich... aber nimmer lang, und das Ganze ist entrümpelt und halbwegs sauber organisiert. Dann kommt der erste Compilerlauf. Und damit evtl. das böse Erwachen :D

Scherz :D Das Ganze ist allerdings alles andere als sauber implementiert, kann also noch unvorhergesehene Probleme mit sich bringen. Da gibts z.B. so lustige Zeilen, in denen eine Funktion, die einen Zeiger auf UBYTE zurückgibt, gezwungen wird, den Zeiger in ein ULONG zu schmeißen...

Kann mir mal jemand verraten, wozu das gut sein sollte? Ich frage, weil ich den Verdacht habe, daß der Originalautor auch an anderen Stellen "Tricks" eingebaut hat, die evtl. dazu dienen, auf 68000er Maschinen "besser" zu laufen. Trotzdem verstehe ich den Sinn dabei nicht, einen Zeiger explizit in einem ULONG unterzubringen, statt getrennt Versionen für 68000 und 020+ zu compilieren...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

19.08.2005, 10:18 Uhr

Solar
Posts: 3680
Nutzer
Eine ziemlich dösige Angewohnheit mancher Progger, Zeiger und Integers lustig hin- und herzuwandeln. Ich wäre auch dran interessiert zu erfahren, was die Leute da reitet...

[ - Antworten - Zitieren - Direktlink - ]

19.08.2005, 10:19 Uhr

MaikG
Posts: 5172
Nutzer
Es gab ja 2 Versionen für 000 und für 020 kann auch
sein das es nur mit Compiler Optionen gemacht wurde.

[ - Antworten - Zitieren - Direktlink - ]

19.08.2005, 10:23 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Solar:
Eine ziemlich dösige Angewohnheit mancher Progger, Zeiger und Integers lustig hin- und herzuwandeln. Ich wäre auch dran interessiert zu erfahren, was die Leute da reitet...


Hm, vielleicht sollte ich mir mal Informationen zu den SAS-C-Optionen besorgen... ich habe das dumpfe Gefühl, daß diese Casterei im Zusammenhang mit dem kleinen Code-/Daten-Modell steht. Vor allem taucht dieser Cast nicht überall dort auf, wo die angesprochene Funktion verwendet wird (Projektsuche in StormC ist wirklich eine feine Sache :D ). Das muß einen Grund haben...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

19.08.2005, 10:24 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
Es gab ja 2 Versionen für 000 und für 020 kann auch
sein das es nur mit Compiler Optionen gemacht wurde.


Das sowieso. Naja, ich werd schon noch herausfinden, was sich der Autor bei allem gedacht hat I-)

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

19.08.2005, 11:22 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
ich habe das dumpfe Gefühl, daß diese Casterei im Zusammenhang mit dem kleinen Code-/Daten-Modell steht.

Das ist kein MS-DOS.

[ - Antworten - Zitieren - Direktlink - ]

19.08.2005, 11:46 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Zitat:
whose:
ich habe das dumpfe Gefühl, daß diese Casterei im Zusammenhang mit dem kleinen Code-/Daten-Modell steht.

Das ist kein MS-DOS.

Hmpf!

Man möge mir diese Schludrigkeit nachsehen, hier nochmal die korrekten Ausdrücke:

...daß diese Casterei im Zusammenhang mit dem "Near Code"/"Small Data a4/a6 relative" Modell steht.

Ist das jetzt immer noch zu ungenau? Falls ja, bitte das Compilerhandbuch bzgl. der entsprechenden Benennungen der jeweiligen Compileroptionen konsultieren und statt meines Textes einsetzen. Danke. :D


So kann's gehen, wenn man's eilig hat, grummel... I-)

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 19.08.2005 um 11:55 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

19.08.2005, 12:27 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Zirkelbezüge in den Includes

Das ist doch einfach: den Headern fehlt "#ifndefn#define...#endif".
Strukturen vor Prototypes + Forwards und gut.

[ - Antworten - Zitieren - Direktlink - ]

19.08.2005, 12:32 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Da gibts z.B. so lustige Zeilen, in denen eine Funktion, die einen Zeiger auf UBYTE zurückgibt, gezwungen wird, den Zeiger in ein ULONG zu schmeißen...

Kann mir mal jemand verraten, wozu das gut sein sollte?

IMHO, der Autor konnte weder C noch mit seinem Compiler umgehen...
Zitat:
Ich frage, weil ich den Verdacht habe, daß der Originalautor auch an anderen Stellen "Tricks" eingebaut hat, die evtl. dazu dienen, auf 68000er Maschinen "besser" zu laufen.
Das hat mit dem 68000 eher weniger zu tun. Eher mehr mit Nichtwissen.

[ - Antworten - Zitieren - Direktlink - ]

19.08.2005, 12:38 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
...daß diese Casterei im Zusammenhang mit dem "Near Code"/"Small Data a4/a6 relative" Modell steht.

Near Code bedeutet nur, das sich jeder Funktionsaufruf in 32k Reichweite befindet. Smalldata heisst maximal 64k Data über A4 adressiert. Beides hat *nichts* mit eventuellen Cast in den Quellen zu tun. Wer mit [U]WORD in den eigenen Quellen arbeitet, macht sich das leben nur selber schwer.
BTW1, 'FORM' und Freunde erzeugt man korrekterweise mit MAKE_ID.
BTW2, laß besser die Finger von diesen schrottigen Quellen.

[ - Antworten - Zitieren - Direktlink - ]

19.08.2005, 12:39 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Zitat:
whose:
Zirkelbezüge in den Includes

Das ist doch einfach: den Headern fehlt "#ifndefn#define...#endif".
Strukturen vor Prototypes + Forwards und gut.


Ich weiß... das habe ich inzwischen schon erledigt. Bei der Gelegenheit, dachte ich mir, könnte man ja auch gleich diverse Mehrfach-Deklarationen und Vorwärtsdeklarationen einiger Strukturen (die sich fast ausschließlich in den .c-Dateien finden) beseitigen und da einzeln unterbringen, wo sie (zumindest meiner Ansicht nach) hingehören (in ggf. zusätzlichen Headern, brav in #ifndef...#define...#endif verpackt).

Dann sehen die .c-Dateien gleich viel aufgeräumter aus, finde ich.

Über die eigentliche Struktur des Projektes kann man sich ja später immer noch Gedanken machen und eine Änderung fällt dann doch um einiges leichter, wenn man nicht ständig das gesamte Projekt nach diversen Forwards durchsuchen muß. Oder?

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

19.08.2005, 12:47 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Zitat:
whose:
...daß diese Casterei im Zusammenhang mit dem "Near Code"/"Small Data a4/a6 relative" Modell steht.

Near Code bedeutet nur, das sich jeder Funktionsaufruf in 32k Reichweite befindet. Smalldata heisst maximal 64k Data über A4 adressiert. Beides hat *nichts* mit eventuellen Cast in den Quellen zu tun.

Nicht? Auch nicht, wenn Du versuchst, 16Bit relative und 32Bit absolut-Adressierung im selben Quellcode unterzubringen, weil Du zu faul bist, die Struktur des Programms entsprechend auszulegen bzw. besonders "trickreich" sein willst? Ist nicht besonders sinnvoll, ich weiß, aber der wäre nicht der erste, der das gemacht hat...

Zitat:
Wer mit [U]WORD in den eigenen Quellen arbeitet, macht sich das leben nur selber schwer.
BTW1, 'FORM' und Freunde erzeugt man korrekterweise mit MAKE_ID.
BTW2, laß besser die Finger von diesen schrottigen Quellen.


Ich weiß, daß die eigentlich Schrott sind. Zum Glück ist relativ leicht zu durchschauen, nach welchem Schema der Autor da gearbeitet hat. Schema Faulpelz vor allem.

Wie ich schon sagte: Reine Fleißarbeit.

Und ich lerne dadurch mit Sicherheit einiges dazu. Vor allem, was man nicht machen sollte...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

19.08.2005, 13:58 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Auch nicht, wenn Du versuchst, 16Bit relative und 32Bit absolut-Adressierung im selben Quellcode unterzubringen

Reden wir hier von C? Da kommst Du damit in keinster Weise in Berührung. Der Compiler nimmt die passenden Adressierung und gut. Das hat mit Casts wirklich nichts zu tun. Auf dem Amiga gibt es keine Cast wegen Near-Code bzw. Near-Data. Wirklich nicht. Es gibt Fälle bei denen man __far verwenden muß, zb. wenn man bei Near-Data auf die CIAs bzw. Custom-Chips per extern Deklaration des Basissymbols draufzugreifen will. Sowas geht nicht mit den GCC. Da muß die "Basis" als #define haben.
Die Casts, über die sich der GCC beschwert hat, waren Zeiger <-> (U)WORD wegen der unterschiedlichen Größen.

[ - Antworten - Zitieren - Direktlink - ]

20.08.2005, 16:19 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Zitat:
whose:
Auch nicht, wenn Du versuchst, 16Bit relative und 32Bit absolut-Adressierung im selben Quellcode unterzubringen

Reden wir hier von C? Da kommst Du damit in keinster Weise in Berührung. Der Compiler nimmt die passenden Adressierung und gut. Das hat mit Casts wirklich nichts zu tun. Auf dem Amiga gibt es keine Cast wegen Near-Code bzw. Near-Data. Wirklich nicht.

Ich glaube Dir das schon, daß das der Normalfall ist, keine Angst. Es war nur eine theoretische Überlegung, weil es mich stutzig machte, daß der Autor von FM2000 Zeiger auf UBYTE in ein ULONG "hineincastete" (worüber sich der GCC übrigens nicht wirklich beschwert hat, er schmiß nur die (verständliche) Warnung, daß man versucht, aus einem Zeiger einen Integerwert zu machen).

Bei solchen Geschichten beginne ich mich immer zu fragen, welchen Sinn das haben soll, weil ich halt keineswegs der Meinung bin, daß jemand solche Casts aus reiner Unwissenheit macht.

Zitat:
Es gibt Fälle bei denen man __far verwenden muß, zb. wenn man bei Near-Data auf die CIAs bzw. Custom-Chips per extern Deklaration des Basissymbols draufzugreifen will. Sowas geht nicht mit den GCC. Da muß die "Basis" als #define haben.

Wie ist der letzte Satz hier genau zu verstehen? Oder meinst Du damit, daß die Resource-Base als #define vorliegen muß statt als "extern" Deklaration?

Zitat:
Die Casts, über die sich der GCC beschwert hat, waren Zeiger <-> (U)WORD wegen der unterschiedlichen Größen.

Die sind mir in den Quellen noch gar nicht aufgefallen. Bisher waren's nur die Warnungen Zeiger<->Integer ( (ULONG) statt (UBYTE *) )und "Different width due to prototype" aufgrund des festen "-traditional" des StormC-GCC (implizite Erweiterung von short auf int), welche dann zum größten Teil beim "normalen" GCC wegfallen dürften.

Die von Dir erwähnten kommen dann wohl noch, habe bisher noch nicht alle .c-Dateien probecompilieren lassen... I-)

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

22.08.2005, 09:51 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Zeiger auf UBYTE in ein ULONG "hineincastete" (worüber sich der GCC übrigens nicht wirklich beschwert hat, er schmiß nur die (verständliche) Warnung, daß man versucht, aus einem Zeiger einen Integerwert zu machen).

Wenn das per Cast geschieht, sollte der Compiler doch nicht meckern. Diese Warnung ist mir jedenfalls nicht untergekommen.
Zitat:
Zitat:
Es gibt Fälle bei denen man __far verwenden muß, zb. wenn man bei Near-Data auf die CIAs bzw. Custom-Chips per extern Deklaration des Basissymbols draufzugreifen will. Sowas geht nicht mit den GCC. Da muß die "Basis" als #define haben.
Wie ist der letzte Satz hier genau zu verstehen? Oder meinst Du damit, daß die Resource-Base als #define vorliegen muß statt als "extern" Deklaration?
Genau das. Mit SAS/C kannst Du mit extern arbeiten. Bei GCC mußt Du ein #define nehmen, wenn Du mit -fbaserel arbeiten willst. Ansonsten wäre die Basis für den GCC eine normale Variable, die in der Datensektion liegt und die würde dann per Indexregister adressiert werden.
Zitat:
Zitat:
Die Casts, über die sich der GCC beschwert hat, waren Zeiger <-> (U)WORD wegen der unterschiedlichen Größen.
Die sind mir in den Quellen noch gar nicht aufgefallen. Bisher waren's nur die Warnungen Zeiger<->Integer ( (ULONG) statt (UBYTE *) )und "Different width due to prototype" aufgrund des festen "-traditional" des StormC-GCC (implizite Erweiterung von short auf int), welche dann zum größten Teil beim "normalen" GCC wegfallen dürften.
Ich werde Storm nie verstehen :-(

[ - Antworten - Zitieren - Direktlink - ]


-1- 2 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > SASC [ - Suche - Neue Beiträge - Registrieren - Login - ]


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