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

amiga-news.de Forum > Programmierung > SDI-Makros und vbcc-m68k [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

19.05.2010, 21:43 Uhr

jolo
Posts: 110
Nutzer
Dies ist nur eine Information für diejenigen unter uns, die SDI-Makros in Verbindung mit 'vbcc m68k' verwenden.

Wer mittels 'vbcc' für m68k MUI-Programme erstellt, oder Argumente in Registern übermittelt und dafür "SDI_hook.h" oder "SDI_compiler.h" benutzt, sollte sehr, sehr vorsichtig sein.
Mir ist heute aufgefallen, dass 'vbcc' anscheinend nicht mehr in der Lage ist, ein MUI-Programm fehlerfrei zu übersetzen.

Der Schuldige ist aber nicht 'vbcc', sondern "SDI_compiler.h" (v1.31, 29.03.2009) und "SDI_hook.h" (v1.20, 26.03.2009).
In "SDI_compiler.h" wird zwar das REG-Makro korrekt definiert, komischerweise wird aber im Programm selber das PPC-Makro verwendet, das bedeutet, dass die Argumente in den Register schlummern aber 'vbcc' aus Mangel an Information diese vom Stack zieht und nicht die Register benutzt. Demnach erfolgt u.U. ein Crash wegen illegalen Speicherzugriffes.
In "SDI_hook.h" wird nur auf eine MC68000 CPU für 'vbcc' geprüft, aber nicht die Prozessorfamilie ('vbcc' bietet hierfür __M68K__ an), was dazu führt, dass auch dort die Argumente vom Stack gezogen werden, demnach auch dort ein Crash auftritt (HOOKPROTOxx).

Ich weiß nicht, ob es neuere Versionen gibt. Falls doch, verwendet diese aber testet sie!
Ich selber habe beide Dateien abgeändert, so dass sich diese wie gewohnt verwenden lassen:
Am Ende (aber vor dem letzten #endif) in "SDI_compiler.h" dies einfügen:
c code:
#if  (defined(__VBCC__) && !defined(__PPC__))
#undef REG
#define REG(reg,arg) __reg(#reg) arg
#endif


und diese Zeile in SDI_hook.h von:
c code:
#if defined(_M68000) || defined(__M68000) || defined(__mc68000)


nach:
c code:
#if (defined(__VBCC__) && !defined(__PPC__)) || defined(_M68000) ||
    defined(__M68000) || defined(__mc68000)


ändern.

Das war's.


Wenn jemand aktuellere SDI-Makros hat als ich, möge er sich bitte bei mir melden. Danke.


Grüße

[ - Antworten - Zitieren - Direktlink - ]

19.05.2010, 22:17 Uhr

whose
Posts: 2156
Nutzer
@jolo:

Danke für den Tip. Ich habe noch die ältere Aminet-Version hier, damit gehts. Ich werde mir aber mal die aktuellere saugen und dann nach Deinen Angaben vergleichen/korrigieren, falls nötig.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

19.05.2010, 23:00 Uhr

damato
Posts: 5
Nutzer
@jolo:

Die neueste Version der SDI_compiler.h hat die verison 1.32. Die aktuellsten Versionen davon sind immer unter folgendem CVS repository frei verfügbar:

http://sditools.cvs.sourceforge.net/viewvc/sditools/sditools/headers/

Natürlich würden wir uns freuen wenn du deine Änderungen irgendwo als komplette Dateien veröffentlichen können sodass wir diese in einer neuen version der SDI headers mit aufnehmen können.

Gruss,
jens
--
--
Jens Langner
http://www.jens-langner.de

[ - Antworten - Zitieren - Direktlink - ]

20.05.2010, 01:20 Uhr

geit
Posts: 332
[Ex-Mitglied]

Also ich hatte mit den SDI Dateien und VBCC nie Probleme.

Ich nutze sie für alle meine Projekte ausgiebig. Installer, MMKeyboard, Meridian, IRCom, ...

Sowohl für 68K also auch für PPC und AROS_x86.

Geit




[ - Antworten - Zitieren - Direktlink - ]

20.05.2010, 08:40 Uhr

gni
Posts: 1106
Nutzer
Zitat:
jolo:
Der Schuldige ist aber nicht 'vbcc', sondern "SDI_compiler.h" (v1.31, 29.03.2009) und "SDI_hook.h" (v1.20, 26.03.2009). In "SDI_compiler.h" wird zwar das REG-Makro korrekt definiert, komischerweise wird aber im Programm selber das PPC-Makro verwendet, das bedeutet, dass die Argumente in den Register schlummern aber 'vbcc' aus Mangel an Information diese vom Stack zieht und nicht die Register benutzt. Demnach erfolgt u.U. ein Crash wegen illegalen Speicherzugriffes.

Das angegebene SDI_compiler.h sieht aber korrekt aus. Hast Du geprüft, ob VBCC wirklich durch den __VBCC__ Block geht?
Zitat:
c code:
#if  (defined(__VBCC__) && !defined(__PPC__))
#undef REG
#define REG(reg,arg) __reg(#reg) arg
#endif

c code:
#if (defined(__VBCC__) && !defined(__PPC__)) || defined(_M68000) ||
    defined(__M68000) || defined(__mc68000)



!__PPC__ kann nicht richtig sein. Wenn dann "&& defined(__M68k__)". Ich hätte jetzt allerdings auch erwartet, das __M68000 immer definiert ist, laut .pdf ist das aber anscheinend nicht der Fall, müßte man prüfen.

[ - Antworten - Zitieren - Direktlink - ]

20.05.2010, 11:22 Uhr

jolo
Posts: 110
Nutzer
@damato:

Zitat:
Die neueste Version der SDI_compiler.h hat die verison 1.32. Die aktuellsten Versionen davon sind immer unter folgendem CVS repository frei verfügbar:

http://sditools.cvs.sourceforge.net/viewvc/sditools/sditools/headers/


Danke! :)
Werde diese herunterladen und schauen ob sich etwas geändert hat beim Kompilieren mit 'vbcc'.


Zitat:
Natürlich würden wir uns freuen wenn du deine Änderungen irgendwo als komplette Dateien veröffentlichen können sodass wir diese in einer neuen version der SDI headers mit aufnehmen können.

Im Moment ist es ein unschönes Workaround - und ich will die betreffenden Dateien nicht verunstalten. Zudem muss ich jetzt erst einmal intensive Tests machen, weil Guido und Gunther der Meinung sind, es könnte gar nicht sein bzw. meine eingefügte Abfrage wäre falsch.

Vorausschicken muss ich aber, dass das betreffende Programm seit Oktober letzten Jahres nicht mehr fehlerfrei mit 'vbcc' erstellt werden konnte; ich bis dato aber immer von einem Fehler im Compiler ausgegangen bin. Nachdem jetzt diverse Fehler in 'vbcc' ausgemerzt wurden, war ich mir nicht mehr so sicher und habe das komplette Programm disassembliert. Dabei ist mir dann die Argumentübergabe über den Stack ins Auge gefallen, so dass ich "SDI_compiler.h" und "SDI_hook.h" als mögliche Ursache in Betracht gezogen habe. Nach einigen Tests und Änderung dieser lief das Programm wieder einwandfrei - ohne Änderungen am Programm selber.


@Geit:

Zitat:
Also ich hatte mit den SDI Dateien und VBCC nie Probleme.

Das streite ich auch nicht ab. Dass ich aber hin und wieder Probleme mit den SDI-Makros hatte, habe ich Dir ja auch in der Yahoo-Mailing-Liste mitgeteilt und Dich gebeten, diese zu beheben. Ist aber schon lange her (2007?).


Zitat:
Ich nutze sie für alle meine Projekte ausgiebig. Installer, MMKeyboard, Meridian, IRCom, ...

Sowohl für 68K also auch für PPC und AROS_x86.


Ich widerspreche dem auch nicht, nur funktionierten hier die SDITools nicht unter 'vbcc' v0.9a, und dabei war es egal ob es sich um die 'vbcc' Version von Oktober letzten Jahres handelt oder um die Version von Mitte April diesen Jahres.


@gni:

Zitat:
Das angegebene SDI_compiler.h sieht aber korrekt aus.

Ja, und komischerweise wird das REG-Makro ja auch definiert. Nur, im Programm selber wird dann wieder auf die PPC-Variante zurückgegriffen. Was da genau schief geht, kann ich nicht noch nicht sagen.
Habe demnach als Quick-Workaround (okay, Hack :) ) ein "#undef" und anschließendes "#define REG..." eingebaut.

Zitat:
Hast Du geprüft, ob VBCC wirklich durch den __VBCC__ Block geht?

Ja, mittels "#error" Ausgabe veranlasst, um zu sehen, ob der für 'vbcc' vorgesehene Block angesprungen wird.


Zitat:
!__PPC__ kann nicht richtig sein. Wenn dann "&& defined(__M68k__)". Ich hätte jetzt allerdings auch erwartet, das __M68000 immer definiert ist, laut .pdf ist das aber anscheinend nicht der Fall, müßte man prüfen.

Ich spezifiziere immer eine 68020 als Zielversion. Demnach testet "(defined (__VBCC__) && !defined(__PPC__))" korrekt auf 'vbcc' ungleich PPC-Backend, was dann hier bedeutet, dass es sich um m68k handelt. "__M68000" ist wirklich nur dann unter 'vbcc' gesetzt, falls das Zielmodell eine 68000 ist.
Und ja, in der finalen Version von "SDI_hook.h" sollte man "__M68K__" verwenden. Da aber SDI viele Compiler unterstützt, bin ich mir nicht sicher, ob nicht irgendein Compiler auch "__M68K__" verwenden könnte, und zwar zur Identifizierung des Host-Modells, was dann Probleme mit sich bringt. Demnach denke ich, dass man momentan unter Verwendung von "(defined (__VBCC__) && !defined(__PPC__))" auf der sichereren Seite ist. Wie gesagt, wenn kein Compiler außer 'vbcc' von "__M68K__" Gebrauch macht oder diese Compiler "__M68k__" nur für das Target-Modell spezifizieren, kann man "__M68K__" verwenden. Ich bin hier aber schlichtweg überfragt.
Vielleicht kannst Du schon sagen, ob SAS/C und 'gcc' "__M68K__" nicht verwenden?
Und eine Abfrage wie "(defined (__VBCC__) && defined(__M68K__)) sieht in den jetzt sehr aufgeräumten SDI-Makros einfach unschön aus.


Nachtrag:
Habe die von Jens gepostete URL benutzt um die neuste Version von SDITools herunterzuladen.
Nachdem ich ausschließlich "SDI_hook.h" um eine "__M68K__" Abfrage erweitert habe, funktioniert es jetzt einwandfrei.
Aber wie oben schon beschrieben, habe ich Bedenken bezüglich "__M68K__". Es muss sichergestellt sein, dass kein Compiler dies benutzt um den Nutzer zu informieren, welche HOST-CPU-Familie benutzt wird, falls überhaupt ein Compiler existiert, der so etwas unterstützt...


Grüße

[ - Antworten - Zitieren - Direktlink - ]

20.05.2010, 17:56 Uhr

gni
Posts: 1106
Nutzer
Zitat:
jolo:
Nur, im Programm selber wird dann wieder auf die PPC-Variante zurückgegriffen. Was da genau schief geht, kann ich nicht noch nicht sagen.

Mysteriös. Werde ich bei Gelegenheit mal testen.
Zitat:
Zitat:
Hast Du geprüft, ob VBCC wirklich durch den __VBCC__ Block geht?
Ja, mittels "#error" Ausgabe veranlasst, um zu sehen, ob der für 'vbcc' vorgesehene Block angesprungen wird.
Und dann wird auch in den richtigen REG-Block gegangen?
Zitat:
Ich spezifiziere immer eine 68020 als Zielversion. Demnach testet "(defined (__VBCC__) && !defined(__PPC__))" korrekt auf 'vbcc' ungleich PPC-Backend, was dann hier bedeutet, dass es sich um m68k handelt.
Nein. Dann weißt Du nur, das es _nicht_ PPC ist. Du willst aber wissen ob es m68k ist und das testet Du bei VBCC mit __M68K__ (bei GCC wäre es __mc68000 und bei SAS/C ist es _M68000).
Zitat:
Da aber SDI viele Compiler unterstützt, bin ich mir nicht sicher, ob nicht irgendein Compiler auch "__M68K__" verwenden könnte, und zwar zur Identifizierung des Host-Modells, was dann Probleme mit sich bringt.
Wieso? Wenn ein Compiler das definiert, dann wird er schon für m68k Code erzeugen und genau das soll ja geprüft werden.
Zitat:
Demnach denke ich, dass man momentan unter Verwendung von "(defined (__VBCC__) && !defined(__PPC__))" auf der sichereren Seite ist.
Du implizierst, das es 68k ist und diese Schlußfolgerung ist nicht zwangsläufig richtig.
Zitat:
Vielleicht kannst Du schon sagen, ob SAS/C und 'gcc' "__M68K__" nicht verwenden?
SAS/C und GCC verwenden andere #defines (siehe oben).

[ - Antworten - Zitieren - Direktlink - ]

20.05.2010, 22:21 Uhr

whose
Posts: 2156
Nutzer
@gni:

So, wie sich das für mich liest, ist sein Problem das, daß es möglicherweise Compiler geben könnte, die blöd genug gebaut wurden, um Host und Target nicht eindeutig trennbar anzugeben.

Z.B. folgender (wenn auch sehr unwahrscheinlicher) Fall, daß ein Compiler auf __M68K__ läuft und dies als Host so angibt und für das Target z.B. __PPC__ angibt. Würde er dann nur auf __M68K__ testen, gäbs Bruchlandung, weil das Target halt __PPC__ ist.

Mir ist allerdings kein Compiler bekannt, der so dusslige Infos von sich gibt. vbcc gibt meines Wissens nach den Host auch gar nicht explizit an, nur das Target. Wie das bei z.B. gcc gehandhabt wird, weiß ich gar nicht, habe mich nie groß darum gekümmert ;)

Ich glaube allerdings, daß keine Compiler-Truppe so dusslig arbeiten würde, Host und Target nicht eindeutig trennbar als Symbol anzugeben. Ok, sicher sein kann man sich da nie, aber das würde doch ziemlich schnell auffallen, oder?
--
---

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

[ - Antworten - Zitieren - Direktlink - ]

21.05.2010, 00:33 Uhr

jolo
Posts: 110
Nutzer
@gni:

Zitat:
Nur, im Programm selber wird dann wieder auf die PPC-Variante zurückgegriffen. Was da genau schief geht, kann ich nicht noch nicht sagen.
Zitat:
Mysteriös. Werde ich bei Gelegenheit mal testen.


Des Rätsels Lösung liegt in "SDI_hook.h", welches einmal einen "generischen" Abschnitt, zum anderen aber einen reinen m68k Abschnitt definiert. Jetzt, nachdem ich mit den "alten" Dateien herum experimentiert habe, kann ich sagen, dass "SDI_compiler.h" fehlerfrei war und demnach auch die neue Version ist.
Nur "SDI_hook.h" ist in Verbindung mit 'vbcc', wobei der Ziel-Prozessor höher als 68000 gewählt wurde, fehlerhaft.


Zitat:
Ich spezifiziere immer eine 68020 als Zielversion. Demnach testet "(defined (__VBCC__) && !defined(__PPC__))" korrekt auf 'vbcc' ungleich PPC-Backend, was dann hier bedeutet, dass es sich um m68k handelt.
Zitat:
Nein. Dann weißt Du nur, das es _nicht_ PPC ist. Du willst aber wissen ob es m68k ist und das testet Du bei VBCC mit __M68K__ (bei GCC wäre es __mc68000 und bei SAS/C ist es _M68000).


Richtig. Ich habe aber geschrieben, dass es *hier* bedeutet, dass es sich um m68k handelt. Ich habe ausschließlich PPC und m68k Backends für 'vbcc' installiert.


Zitat:
Du implizierst, das es 68k ist und diese Schlußfolgerung ist nicht zwangsläufig richtig.

Ich weiß. Allerdings gibt es kein offizielles i686 Backend von 'vbcc', welches AROS unterstützt. Käme es jemals zustande, müsste "SDI_compiler.h" auch modifiziert werden.
Da die SDITools aber ausschließlich für AmigaOS (m68k), AROS (i686, x86_64, PPC), MorphOS und AmigaOS4 (PPC) gedacht sind, ist dies aber eher hypothetischer Natur, obschon Du natürlich Recht hast und es besser wäre, von Anfang an so etwas zu berücksichtigen. Jedoch müsste man dann aber schon bei "SDI_compiler.h" ansetzen und nicht erst bei "SDI_hook.h"...


@whose:

Zitat:
So, wie sich das für mich liest, ist sein Problem das, daß es möglicherweise Compiler geben könnte, die blöd genug gebaut wurden, um Host und Target nicht eindeutig trennbar anzugeben.

Exakt das meinte ich. :)
Ich kenne/benutze nur StormC v3; 'gcc' für AmigaOS, AROS und Linux; MaxonC++ sowie vbcc für AmigaOS, MorphOS und AmigaOS4 - und Anleitungen lese ich nur bei Bedarf.
Demnach traue ich mir nicht zu, zu sagen, was andere Compiler so an vordefinierten Symbolen bereitstellen.


Grüße

[ - Antworten - Zitieren - Direktlink - ]

24.05.2010, 11:01 Uhr

gni
Posts: 1106
Nutzer
Zitat:
jolo:
Jetzt, nachdem ich mit den "alten" Dateien herum experimentiert habe, kann ich sagen, dass "SDI_compiler.h" fehlerfrei war und demnach auch die neue Version ist.
Nur "SDI_hook.h" ist in Verbindung mit 'vbcc', wobei der Ziel-Prozessor höher als 68000 gewählt wurde, fehlerhaft.

Schön das Du das Problem identifizieren konntest!
Zitat:
Ich habe aber geschrieben, dass es *hier* bedeutet, dass es sich um m68k handelt.
Stimmt, das "hier" hatte ich übersehen.
Zitat:
Ich habe ausschließlich PPC und m68k Backends für 'vbcc' installiert.
Dito. Dennoch solltest Du Dein (oder eben mein :) System nicht als repräsentativ ansehen.
Zitat:
Zitat:
Du implizierst, das es 68k ist und diese Schlußfolgerung ist nicht zwangsläufig richtig.
Ich weiß. Allerdings gibt es kein offizielles i686 Backend von 'vbcc', welches AROS unterstützt.
Wenn es eine korrekten Weg gibt und man den auch kennt, dann sollte der auch benutzt werden. Alles andere fällt einem früher oder später (meist früher :) immer auf die Füße...
Zitat:
Jedoch müsste man dann aber schon bei "SDI_compiler.h" ansetzen und nicht erst bei "SDI_hook.h"...
Da sich jetzt gezeigt hat, das die SDI-Header VBCC nicht korrekt unterstützen, sollte das nun behoben werden.
Es wäre interessant zu wisse, ob __M68K__ schon immer das Architektur #define von VBCC war. Mein eigenes compiler.h testet auch __M68000 und ich glaube das das mal korrekt war, aber 100% sicher bin ich mir da auch nicht.
Zitat:
Zitat:
So, wie sich das für mich liest, ist sein Problem das, daß es möglicherweise Compiler geben könnte, die blöd genug gebaut wurden, um Host und Target nicht eindeutig trennbar anzugeben.
Exakt das meinte ich. :)
Kein Compiler erzählt irgendwas über sein Host-System, denn welchen Sinn sollte das haben? Alle #defines beziehen sich ausschließlich auf das Zielsystem.

[ - Antworten - Zitieren - Direktlink - ]

24.05.2010, 18:46 Uhr

jolo
Posts: 110
Nutzer
@gni:

Zitat:
Dito. Dennoch solltest Du Dein (oder eben mein :) System nicht als repräsentativ ansehen.

Mache ich bestimmt nicht. Ich hab' ja geschrieben dass es ein unschönes Workaround ist. :-}

Zitat:
Es wäre interessant zu wissen, ob __M68K__ schon immer das Architektur #define von VBCC war.

Frank kann dies definitiv beantworten. :)


Zitat:
Wenn es eine korrekten Weg gibt und man den auch kennt, dann sollte der auch benutzt werden. Alles andere fällt einem früher oder später (meist früher :) immer auf die Füße...

LOL, stimmt, aber siehe unten...


Zitat:
Kein Compiler erzählt irgendwas über sein Host-System, denn welchen Sinn sollte das haben? Alle #defines beziehen sich ausschließlich auf das Zielsystem.

Das ist der Unterschied zwischen Dir und mir: Du weißt sowas, ich kann nur Vermutungen anstellen. Dementsprechend will ich auch nicht Hand an SDITools legen, sondern das sollen Programmierer mit Deiner Erfahrung tun. Ich würde es höchsten verschlimmbessern. :)
Ich bleib' lieber auf der sicheren Seite und melde Fehler die dann andere beheben können.


Grüße

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > SDI-Makros und vbcc-m68k [ - Suche - Neue Beiträge - Registrieren - Login - ]


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