gcc >3.4.x __asm("fpx") problem - amiga-news.de Forum

amiga-news.de Forum > Programmierung > gcc >3.4.x __asm("fpx") problem

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

[ - Beitrag schreiben - ]

20.11.2009, 16:17 Uhr

wawa
Posts: 314
Nutzer

ich bin gerade dabei storm mesa source an gcc anzupassen. dabei stosse ich an ein problem. ich habe es schon auch woanders gefragt aber bisher keine direkte lösung bekommen. ein workaround über ein makro scheint zu funktionieren, aber ich wollte es einfach halten:

hier ein beispiel von ursprünglichen code aud glapi.c:

void APIENTRY smglAlphaFunc(register __d0 GLenum func,
register __fp0 GLclampf ref )
{
glAlphaFunc(func,ref);
}

hier von bernd_r vorgeschlagene modifikation mit dummy variablen:

void APIENTRY smglAlphaFunc( GLenum a,
GLclampf b )
{
register GLenum func __asm("d0");
register GLclampf ref __asm("fp0");
glAlphaFunc(func,ref);
}

alles was mit adress und data registers zu tun kat scheint klaglos durchzukommen aber bie fp registers bekomme ich nen kompiler error wie diesen:
C:CrossCompilerAmiDevCppprojectsStormMesaNewsrcAMIGAsrcglapi.c In function 'void smglAlphaFunc(GLenum, GLclampf)': 83 C:CrossCompilerAmiDevCppprojectsStormMesaNewsrcAMIGAsrcglapi.c register specified for 'ref' isn't suitable for data type 83 C:CrossCompilerAmiDevCppprojectsStormMesaNewsrcAMIGAsrcglapi.c register name given for non-register variable 'ref'

ich kompiliere grad mit cgg.3.4.0

kompiler optionen:

-m68060
oder
-m68040 -m68881

aber es ändert nichts.
hat jemand nen hinweis, aber bitte so damit ichs auch verstehe. ich bin nämlich jemand der mit rekompilieren von open source gerade so zurecht kommt. bitte nicht bashen, ich versuche somit den weg zu öffnen um den 68k mesa port zu fixen und upzudaten. tut mir leid dass ein noob das machen muss.

[ - Antworten - Zitieren - Direktlink - ]

20.11.2009, 16:46 Uhr

akl
Posts: 265
Nutzer

@wawa: Ist GLclampf bei Mesa als Float/Double definiert?

[ - Antworten - Zitieren - Direktlink - ]

20.11.2009, 17:52 Uhr

wawa
Posts: 314
Nutzer

@akl:
die definitionen sid die gleichen wie in original mesa 3.1. die definition stimmt auch überein mit gl.h.

übrigens das problem ist inzwischen gelöst.
bleibt nur noch korrekt library initialisation hoffe ich.

[ - Antworten - Zitieren - Direktlink - ]

21.11.2009, 12:18 Uhr

akl
Posts: 265
Nutzer

@wawa:
Du hättest zumindest ja mal schreiben können, *wie* sie definiert sind, warum das nicht das Problem war, und wie Du es dann schlußendlich gelöst hat - dann profitiert vielleicht irgendwann auch mal jemand anderes von diesem Forum hier...

[ - Antworten - Zitieren - Direktlink - ]

21.11.2009, 14:11 Uhr

wawa
Posts: 314
Nutzer

@akl:
meinst du typedefinition?

gl.h beinhaltet das hier:

/* C type GL type storage */
/*-------------------------------------------------------------------------*/
typedef void GLvoid;
typedef unsigned char GLboolean;
typedef signed char GLbyte; /* 1-byte signed */
typedef short GLshort; /* 2-byte signed */
typedef int GLint; /* 4-byte signed */
typedef unsigned char GLubyte; /* 1-byte unsigned */
typedef unsigned short GLushort; /* 2-byte unsigned */
typedef unsigned int GLuint; /* 4-byte unsigned */
typedef int GLsizei; /* 4-byte signed */
typedef float GLfloat; /* single precision float */
typedef float GLclampf; /* single precision float in [0,1] */
typedef double GLdouble; /* double precision float */
typedef double GLclampd; /* double precision float in [0,1] */

das problem war, dass devcpp ne blöde angewohnheit hat zu projekt zugeladene sourcefiles mit "compile file as c++" in seinen einstellungen zu belegen unabhängig davon das projekt als ein c projekt definiert ist. (project>project options>files). das hat mir schon immer wieder unendliches kopfzerbrechen bereitet.

[ Dieser Beitrag wurde von wawa am 21.11.2009 um 14:11 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

22.11.2009, 14:19 Uhr

gni
Posts: 1106
Nutzer

Zitat:
wawa:
das problem war, dass devcpp ne blöde angewohnheit hat zu projekt zugeladene sourcefiles mit "compile file as c++" in seinen einstellungen zu belegen unabhängig davon das projekt als ein c projekt definiert ist.

Nein, das kann es _nicht_ gewesen sein. Ich kann Deinen Schnipsel mit dem angegebenen gl.h nach Definition von APIENTRY und GLenum ohne weiteres auch mit dem C++ Compiler übersetzen. Der entscheidende Faktor ist die FPU-Einstellung: man braucht entweder -m68881 oder -m68040/-m68060 damit der Compiler auch die FPU-Register kennt.

[ - Antworten - Zitieren - Direktlink - ]

22.11.2009, 14:56 Uhr

wawa
Posts: 314
Nutzer

@gni:
diese einstellungen (entweder -m68060 oder m68040 mit -m68881) sind bei mir sowieso von vorne drin. ich kann es auch reproduzieren. wenn ich bei der datei in amidevcpp in "datei als c++ kompilieren" wieder häckchen setze kommen die fehler wieder. lösche ich es es ist wieder okay.

[ Dieser Beitrag wurde von wawa am 22.11.2009 um 14:57 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

22.11.2009, 18:25 Uhr

gni
Posts: 1106
Nutzer

Zitat:
wawa:
ich kann es auch reproduzieren. wenn ich bei der datei in amidevcpp in "datei als c++ kompilieren" wieder häckchen setze kommen die fehler wieder. lösche ich es es ist wieder okay.

Nimm Dein Beispiel, das gl.h Include, und laß die IDE weg. Compiliere das ganze auf der Kommandozeile: gcc -v -c foo.c bzw. g++ -v -c foo.c. Danach zusätzlich -m68881 bzw -m68040/-m68060 angeben. Die Ausgaben die dann kommen hier zeigen.
Dein Beispiel funktioniert definitiv mit allen GCC <= 3.4. Neuere habe ich nicht getestet, aber da wird es keinen Unterschied geben.

[ - Antworten - Zitieren - Direktlink - ]

22.11.2009, 18:58 Uhr

wawa
Posts: 314
Nutzer

@gni:

ich arbeite mit dem gcc 3.4.0 andere 68k crosskompiler habe ich hier unter maidevcpp/cygwin nicht installiert.

habe jetzt also meine beispieldatei genommen, glapi.c.
der output sieht bei gcc so aus:

code:

$ m68k-amigaos-gcc.exe -v -c -m68060 -m68881 glapi.c
Reading specs from /usr/bin/../lib/gcc/m68k-amigaos/3.4.0/specs
Configured with: ../gcc-3.4.0/configure --prefix=/usr/local/amiga --target=m68k-amigaos --enable-languages=c,c++,objc --
enable-haifa --enable-sjlj-exceptions --disable-shared --disable-libstdcxx-pch
Thread model: single
gcc version 3.4.0
 /usr/local/amiga/libexec/gcc/m68k-amigaos/3.4.0/cc1.exe -quiet -v -iprefix /usr/bin/../lib/gcc/m68k-amigaos/3.4.0/ -D__
HAVE_68881__ -Dixemul -D__ixemul -D__ixemul__ glapi.c -quiet -dumpbase glapi.c -m68060 -m68881 -auxbase glapi -version -
o /cygdrive/c/DOKUME~1/ja/LOKALE~1/Temp/ccjn6lpn.s
ignoring nonexistent directory "/usr/bin/../lib/gcc/m68k-amigaos/3.4.0/../../../../m68k-amigaos/sys-include"
ignoring nonexistent directory "/usr/bin/../lib/gcc/m68k-amigaos/3.4.0/../../../../m68k-amigaos/include"
ignoring duplicate directory "/usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/bin/../lib/gcc/m68k-amigaos/3.4.0/include
 /usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/../../../../m68k-amigaos/sys-include
 /usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/../../../../m68k-amigaos/include
End of search list.
GNU C version 3.4.0 (m68k-amigaos)
        compiled by GNU C version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 /usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/../../../../m68k-amigaos/bin/as.exe -m68060 -o glapi.o /cygdrive/c/DOKUME~1
/ja/LOKALE~1/Temp/ccjn6lpn.s

und mit g++ so aus:

code:

$ m68k-amigaos-g++.exe -v -c -m68060 -m68881 glapi.c
Reading specs from /usr/bin/../lib/gcc/m68k-amigaos/3.4.0/specs
Configured with: ../gcc-3.4.0/configure --prefix=/usr/local/amiga --target=m68k-amigaos --enable-languages=c,c++,objc --
enable-haifa --enable-sjlj-exceptions --disable-shared --disable-libstdcxx-pch
Thread model: single
gcc version 3.4.0
 /usr/local/amiga/libexec/gcc/m68k-amigaos/3.4.0/cc1plus.exe -quiet -v -iprefix /usr/bin/../lib/gcc/m68k-amigaos/3.4.0/
-D__HAVE_68881__ -Dixemul -D__ixemul -D__ixemul__ glapi.c -quiet -dumpbase glapi.c -m68060 -m68881 -auxbase glapi -versi
on -o /cygdrive/c/DOKUME~1/ja/LOKALE~1/Temp/ccf3SREf.s
ignoring nonexistent directory "/usr/bin/../lib/gcc/m68k-amigaos/3.4.0/../../../../include/c++/3.4.0"
ignoring nonexistent directory "/usr/bin/../lib/gcc/m68k-amigaos/3.4.0/../../../../include/c++/3.4.0/m68k-amigaos"
ignoring nonexistent directory "/usr/bin/../lib/gcc/m68k-amigaos/3.4.0/../../../../include/c++/3.4.0/backward"
ignoring nonexistent directory "/usr/bin/../lib/gcc/m68k-amigaos/3.4.0/../../../../m68k-amigaos/sys-include"
ignoring nonexistent directory "/usr/bin/../lib/gcc/m68k-amigaos/3.4.0/../../../../m68k-amigaos/include"
ignoring duplicate directory "/usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/bin/../lib/gcc/m68k-amigaos/3.4.0/include
 /usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/../../../../include/c++/3.4.0
 /usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/../../../../include/c++/3.4.0/m68k-amigaos
 /usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/../../../../include/c++/3.4.0/backward
 /usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/../../../../m68k-amigaos/sys-include
 /usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/../../../../m68k-amigaos/include
End of search list.
GNU C++ version 3.4.0 (m68k-amigaos)
        compiled by GNU C version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 /usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/../../../../m68k-amigaos/bin/as.exe -m68060 -o glapi.o /cygdrive/c/DOKUME~1
/ja/LOKALE~1/Temp/ccf3SREf.s

ohne prozessoroptionen werfen beide die besagten fehler raus was eigentlich deine aussage bestätigt.

vielleicht ist etwas mit meinen pfaden nicht in ordnung.

[ Dieser Beitrag wurde von wawa am 22.11.2009 um 18:59 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

22.11.2009, 19:27 Uhr

gni
Posts: 1106
Nutzer

Zitat:

wawa:

code:

$ m68k-amigaos-gcc.exe -v -c -m68060 -m68881 glapi.c

Bis einschließlich 4.2 genügt -m68040/-m68060 um FPU-Befehle zu generieren. -m68881 hat die unangenehme Nebenwirkung, daß math.h das math-68881.h include einbindet. Das kann gewollt sein oder eben nicht. Der Compiler selber erzeugt auch mit -m68881 nur FPU-Befehle die der Prozessor in HW hat.

Zitat:
ohne prozessoroptionen werfen beide die besagten fehler raus was eigentlich deine aussage bestätigt.

Danke, dann wäre das also geklärt. Ich hatte zuerst in den Ausgaben die Fehlermeldung vermißt :-)

Zitat:
vielleicht ist etwas mit meinen pfaden nicht in ordnung.

An den Pfaden liegt es nicht, was nicht heißt, das die IDE mit den Pfaden korrekt umgeht - das tut sie definitiv nicht. Standardincludepfade müßen _nie_ per -I angegeben werden, alles unter dem Installationsort des Compilers findet der Compiler selber. Wenn nicht ist die Installation fehlerhaft.

[ - Antworten - Zitieren - Direktlink - ]

23.11.2009, 00:56 Uhr

wawa
Posts: 314
Nutzer

@gni:

Zitat:
Wenn nicht ist die Installation fehlerhaft.

könnte durchaus sein. ich bin in meiner kurzen amidevcpp karriere schon einigen ungereimheiten begegnet, die ich aber zuerst als meine eigenen fehler empfunden habe. ich überlasse es anderen zu den ich in kontakt stehe es zu reporten, wenn sie es bestätigen können. ich bin selbst eigentlich illiterate. jedenfalls ist schwierig die installation jedesmal wieder zu erneuern. 4 mich ist es der hinweis, wenn das meiste kompiliert, dass es mehr oder weniger richtig ist.
übrigens meine compilerexecutanles liegen unter usr/local/amiga/bin glaube ich (bin jetzt nicht zuhause) uugh. ich hasse linux. vielleicht sogar noch mehr als windows.

[ Dieser Beitrag wurde von wawa am 23.11.2009 um 00:56 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

23.11.2009, 17:42 Uhr

wawa
Posts: 314
Nutzer

@gni:
ah, habe jetzt ein hinweis, natürlich geht es darum das devcpp separate optionen für c und c++ kompiler hat. wenn -m68060 -m68881 nur in c feld definiert ist geht es sobald datei als c++ kompiliert wird offensichtlich nicht.

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > gcc >3.4.x __asm("fpx") problem

[ - Suche - Neue Beiträge - Registrieren - Login - ]