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

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

-1- 2 3 4 5 6 >> Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)
gni   Nutzer

08.01.2013, 10:18 Uhr

[ - Direktlink - ]
Thema: Gibt es ein Standard-#define für Amiga-Systeme?
Brett: Programmierung

Zitat:
jolo:
Nee, leider nicht, obschon unter GNU-C bei meiner Installation (gcc 3.4.0 mit dem SDK 3) es gesetzt ist.

Ich denke mal, das der AmigOS-Port des GCC immer ein eingebautes #define für AMIGA haben wird, alleine um SAS/C kompatibel zu sein bzw. zu bleiben. Ein weiteres Kompatibilitätsdefine ist MCH_AMIGA, das stammt noch von Aztec-C.
FWIW, die angesprochene GCC Portierung hat vor sehr langer Zeit ein anderes Symbol als neues Standardefine eingeführt: __amigaos__ - später wurde das dann für OS4 abgewandelt ;) Ach ja das #define __amiga__ gibt es beim GCC auch.

BTW, bitte die Unterstriche beachten! Die Symbole ohne Unterstriche sind nicht immer definiert!
Zitat:
Hier mal ein Beispiel wie ich es machen würde.
IMHO ist der vorgeschlangene Ansatz keine gute Idee, da AMIGA hier u.U. einfach überdefiniert wird (edit: beim GCC hast Du es vorher entfernt ;) . Sowas sollte immer unterbleiben. Also entweder vorher ein #undef oder vermutlich besser #ifndef AMIGA verwenden.
Zitat:
code:
#if defined (__amigaos4__) || defined(__MORPHOS__) || defined(__AROS__)


Hier würde ich defined (__amigaos__) ergänzen.
Zitat:
code:
#if defined(__VBCC__) && defined(__M68K__)
  #define AMIGA


Laut Doku und config hat VBCC wirklich kein OS #define.
Zitat:
code:
#if defined(__GNUC__) && (defined(_M68000) || defined(__M68000) || defined(__mc68000))
   #undef AMIGA
   #define AMIGA


Das kann komplett raus.
Im übrigen kennt der GCC "nur" mc68000 (mit doppelten Unterstrichen davor und dahinter bzw nur davor) und Varianten für mc680x0 mit x=2,3,4,6. Seit 4.3 gibt es auch x=1.
Die M68000 Symbole sind von SAS/C bzw von VBCC.
Zitat:
code:
#if  defined(__SASC) || defined(__MAXON__) || defined(__DCC)
    #define AMIGA
   #endif


Der SAS/C Test kann entfallen. Maxon und Dice kenn ich nicht (gut genug).
 
gni   Nutzer

10.02.2012, 08:36 Uhr

[ - Direktlink - ]
Thema: HTMLView, gcc und fread, komische Dinge passieren
Brett: Programmierung

Zitat:
ciVic:
Zitat:
gni:
Hast Du mal ein kleines (aber vollständiges!) Beispiel mit dem sich das Problem nachvollziehen läßt?

Ohne es jetzt selbst probiert zu haben würde ich das Beispiel empfehlen, dass man zusammen mit HTMLView aus dem Aminet laden kann. Die Header sollten mit gcc 3.3 bei dem Beispiel die gleichen Probleme machen wie in meinem Fall.
Das Beispiel aus den AmiNet-Archiven läßt sich ohne Anpassung an den GCC nicht übersetzen, da es für StormC geschrieben worden ist. Für C++ müßte es auch angepaßt werden. Von daher noch mal die Frage, ob Du ein kleines vollständiges Beispiel hast. Am besten wäre der Quellcode und das Präprozessorfile (.i für C bzw. .ii für C++, das erhält man mittels -save-temps). Damit könnte ich Dein Problem analysieren und mit verschiedensten GCC Versionen testen.

Benutzt Du -DNO_INLINE_STDARG?
 
gni   Nutzer

08.02.2012, 09:42 Uhr

[ - Direktlink - ]
Thema: HTMLView, gcc und fread, komische Dinge passieren
Brett: Programmierung

Zitat:
ciVic:
Zitat:
Warum nicht was neueres als 2.95?

Mit einem 3.x wollten die MUI-Header wegen einiger Assembler-Geschichten nicht kompilieren, und bevor ich die alle anpasse habe ich lieber einen älteren verwendet. Oder gibt es da was neueres?


Hast Du mal ein kleines (aber vollständiges!) Beispiel mit dem sich das Problem nachvollziehen läßt?

Ich baue zwar auch immer den C++ Compiler, nur verwende ich den so gut wie nie. Der Compiler wird meist nur benutzt um die libstdc++ des GCC zu bauen.
 
gni   Nutzer

06.02.2012, 09:21 Uhr

[ - Direktlink - ]
Thema: HTMLView, gcc und fread, komische Dinge passieren
Brett: Programmierung

Zitat:
ciVic:
ULONG HTMLviewer_LoadFunc()
{
register struct HTMLview_LoadMsg *_lmsg asm("a1"); struct HTMLview_LoadMsg *lmsg = _lmsg;
register Object *_obj asm("a2"); Object *obj = _obj;
register struct Hook *_h asm("a0"); struct Hook *h = _h;
...
}

Wenn das mit C++ übersetzt werden soll, dann ist "extended asm" eine Möglichkeit. Für C++ sollte man jedoch auch über die Verwendung von HookEntry() aus der amiga.lib nachdenken.

Zitat:
Den g++ 3.x zu verwenden habe ich auch schon aufgegeben. Nutze den 2.95.
Warum nicht was neueres als 2.95?

Zitat:
Dieses __saveds wird beim gcc per Makro, so wie ich das in den Beispielen gesehen habe, einfach wegdefiniert.
Die SAS/C-Schlüsselworte werden von GCC Versionen (die diese auch unterstützen) nicht wegdefiniert, sondern in die entsprechenden GCC-Attribute umgesetzt. So braucht man den Code halt nicht speziell an den GCC anpassen.

Zitat:
Ich hatte das auch mal damit probiert, aber keinen echten Effekt feststellen können. Wird das vom gcc wirklich verwendet?
Ja, wenn man mit den entsprechenden Optionen übersetzt, dann haben diese Schlüsselwörter auch einen Effekt. Die Option für small-data lautet -fbaserel. Das muß sowohl beim Übersetzen als auch beim Linken angegeben werden.

Zitat:
Das große Datenmodell habe ich noch nicht probiert. Wie macht man das beim gcc?
GCC verwendet standardmäßig das große Datenmodell. SAS/C verwendet standardmäßig "small-data".
 
gni   Nutzer

03.01.2011, 08:33 Uhr

[ - Direktlink - ]
Thema: OS4 SDK mit SDL: Undefined references
Brett: Programmierung

Zitat:
ZeroG:
@gni:
?( Ich glaube du solltest dir nochmal durchlesen was du da Zitiert hast.

Ups, Du hast recht - tut mir leid. Da war der Satzbau für mich zu kompliziert .-)
 
gni   Nutzer

30.12.2010, 14:17 Uhr

[ - Direktlink - ]
Thema: OS4 SDK mit SDL: Undefined references
Brett: Programmierung

Zitat:
ZeroG:
@Reth:
Natürlich klappt das so nicht, ist dir noch nie aufgefallen das du z.B. die libSDL.a mit dem Kommando -lSDL einbindest und nicht mit -llibSDL... :O


Und bei Dir funktioniert Deine angegebene -l<...> Option? Wenn ja müßte die Bibliothek bei Dir "liblibSDL.a" heissen (beachte das doppelte lib!). Wenn die Datei jedoch nur "libSDL.a" heißt, dann ist -lSDL vollkommen richtig!
 
gni   Nutzer

08.07.2010, 08:20 Uhr

[ - Direktlink - ]
Thema: Der Stack gehört mir! (?)
Brett: Programmierung

Zitat:
Der_Wanderer:
Ich darf kein Register benutzen um mir was zu merken.

Warum nicht?
 
gni   Nutzer

08.07.2010, 08:19 Uhr

[ - Direktlink - ]
Thema: Der Stack gehört mir! (?)
Brett: Programmierung

Zitat:
Thore:
lea.l #MySP, a1


Entweder "move.l #MySP,a1" oder den Gartenzaun weglassen.
 
gni   Nutzer

26.05.2010, 12:36 Uhr

[ - Direktlink - ]
Thema: Stormwizard GUI Editor mit BlitzBasic oder lieber C (Anfänger) !??
Brett: Programmierung

Zitat:
Der_Wanderer:
- BMP V3,V5

Kannst Du das bitte etwas genauer erläutern?
 
gni   Nutzer

24.05.2010, 11:01 Uhr

[ - Direktlink - ]
Thema: SDI-Makros und vbcc-m68k
Brett: Programmierung

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.
 
gni   Nutzer

20.05.2010, 17:56 Uhr

[ - Direktlink - ]
Thema: SDI-Makros und vbcc-m68k
Brett: Programmierung

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).
 
gni   Nutzer

20.05.2010, 08:40 Uhr

[ - Direktlink - ]
Thema: SDI-Makros und vbcc-m68k
Brett: Programmierung

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.
 
gni   Nutzer

26.04.2010, 08:12 Uhr

[ - Direktlink - ]
Thema: MJPEG - AVIs unter OS3.9/WarpOS abspielen
Brett: Amiga, AmigaOS 4

Zitat:
wawa:
inzwischen gibt es für 68k auch das hier:
http://aminet.net/package/gfx/conv/ffmpeg-svnr22669-m68k


Wo ist der Quellecode dieser Version?
 
gni   Nutzer

22.11.2009, 19:27 Uhr

[ - Direktlink - ]
Thema: gcc >3.4.x __asm("fpx") problem
Brett: Programmierung

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.
 
gni   Nutzer

22.11.2009, 18:25 Uhr

[ - Direktlink - ]
Thema: gcc >3.4.x __asm("fpx") problem
Brett: Programmierung

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.
 
gni   Nutzer

22.11.2009, 14:19 Uhr

[ - Direktlink - ]
Thema: gcc >3.4.x __asm("fpx") problem
Brett: Programmierung

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.
 
gni   Nutzer

08.07.2009, 10:56 Uhr

[ - Direktlink - ]
Thema: debugging 68k app under os4?
Brett: Programmierung

Zitat:
AGSzabo:
aus frueheren versuchen weis ich dass resource und maxon schlecht bzw nicht mit grafikarte laufen weil sie eigene screens in den laschen modi aufmachen, teilweise sogar mit interlace und das britzelt mir alles weg!

AFAICT, Resource V6 soll auf Grafikkarten laufen. V5 braucht einen nativen Screen _und_ ChipMem für seine Menues. Mit Flickerfixer (wie zum Beispiel in der PIV) ist V5 absolut benutzbar. monam sollte mit Grafikarten funktionieren, zumindest mein Uralt V2 kommt mit einem CGFX-Screen klar.

Ansonsten versuchts mal mit BDebug aus dem Barfl-Paket.
 
gni   Nutzer

23.06.2009, 11:27 Uhr

[ - Direktlink - ]
Thema: OS3.x nativer GCC
Brett: Programmierung

Zitat:
inermis:
Zitat:
Diesen dort verfügbaren Versionen fehlen alle speziellen Amiga-Features wie baserel Modus, stackcheck bzw. stackextenion Modus, Registerargumente (nur C), etc.
Waren diese Features jemals im offiziellem GCC Tree enthalten, oder kamen die erst in der GG Version? Im vermute mal, nur bei GG?
Das sind alles in reine GG-Erweiterungen, dh. in den offiziellen Quellen von binutils und GCC ist das Target m68k-amigaos nicht bekannt und damit fehlen alle diese Feature. Diese Erweiterungen werden durch Patches "nachgerüstet".
Zitat:
Zitat:
Ich habe auch nie probiert, wie aufwändig es wäre 4.3/4.4 zum laufen zu bekommen. 4.2 sollte gehen, aber bis auf ein triviales C "Hello world" habe ich nichts weiter übersetzt.
Also ohne Amiga-Features.
Äh, nein. Neuere Ports als 3.4.0 mit allen Erweiterungen sind nur nicht verfügbar gemacht worden. Unter anderem deshalb weil ich mit GCC4 nicht zufrieden bin. In einem Punkt hat(te) Bernd allerdings recht: für "moderne" C++ Quellen braucht es einen aktuellen GCC, unabhängig davon wie gut der erzeugte Code ist. Ich verwende den C++ Compiler jedoch schlichtweg nicht.
Zitat:
Hat sich ab 4.2 irgendetwas prinzipielles geändert?
Schau auf der GCC Hompage ins Manual von neueren Versionen. Eine prinzipielle Änderung betrifft die Nutzung von gmp und mpfr. Die sind seit 4.3 zwingend zum Erstellen des GCC erforderlich. Zur Qualität dieser Versionen bezüglich Codegüte kann ich nichts konkretes sagen. Die vorigen GCC4 Versionen waren jedoch in meinen Tests nicht besser als GCC3, eher schlechter.
Zitat:
D.h. wenn ich mir eine eigene Crossumgebung erstellen möchte, könnte ich z.B. die Binutils aus den adtools nehmen und eben die letzten verfügbaren Sources aus GG? Ich nehme an, entsprechend hat das auch Zerohero [1] gemacht? Wäre dann also GCC 3.4.
Ja und ja. FWIW, die binutils in adtools sind das Aktuellste was für AmigaOS/68k verfügbar ist. Eine "bessere" Version gibt es nicht, da fast alle späteren Änderungen der GG Version 2.9.1 dort eingepflegt worden sind. Das "fast" bezieht sich darauf, das ich in meiner 2.9.1 Version Backports für GAS und den Demangler aus den Trunk-binutils eingepflegt habe.
Zitat:
(Oder eben einen aktuelleren Compiler, dann aber ohne Amiga-Features.)
Prinzipiell richtig. m68k-amigaos als Target geht aber nur, wenn Du entweder Bernds Quellen verwendest oder selber dem configure der GCC Versionen m68k-anigaos als Target bekannt machst.
 
gni   Nutzer

22.06.2009, 18:28 Uhr

[ - Direktlink - ]
Thema: OS3.x nativer GCC
Brett: Programmierung

Zitat:
inermis:
welchen Compiler (GCC) nutzt Ihr für die native (Kein Crosscompiler) Entwicklung unter OS3.x?

Direkt unter 68k übersetze ich mittlerweile sehr selten. Dauert mir einfach zu lange :)
Zitat:
- Die GCC Umgebung aus CubicIDE
Dort wird eine der Versionen aus dem Alpha-Zweig verwendet.
Zitat:
- adtools (ist nur OS4?! und AROS?)
OS4 wird komplett unterstützt. Die dortigen binutils haben auch vollständige m68k-Unterstützung, dh. alles was man für m68k-amigaos als Target braucht ist vorhanden.
Zitat:
- Amiga_OS_68k_devtools (von Bernd, ist aber für Cross?!)
Diesen Versionen fehlen alle speziellen Amiga-Features. Laut Bernd braucht man diese Dinge aber auch nicht. Darüber gibt es jedoch unterschiedliche Auffassungen ;) Unproblematisch sind diese neuen GCC Versionen auch nicht [1,2].
FWIW, ich denke GCC 4.3/4.4 als Cross-Compiler ist gut "genug". Native willst Du nicht wirklich: unter FreeBSD (x86) sind die Compiler um die 5MB groß (gmp und mpfr sind statisch eingelinkt, so wie es bei einem nativen GCC für AmigaOS/68k auch sein würde). Ich habe auch nie probiert, wie aufwändig es wäre 4.3/4.4 zum laufen zu bekommen. 4.2 sollte gehen, aber bis auf ein triviales C "Hello world" habe ich nichts weiter übersetzt.
Zitat:
- GG mit GCC 2.96.x
Gab es nie für GG.
Zitat:
- GG mit GCC 3.3.x / 3.4.x aus dem Alpha-Zweig
Das diese Versionen im Alpha-Zweig zu finden sind, liegt nur daran, das es keine neueren GG-Snapshots gegeben hat. IMHO sind diese beiden Versionen ohne Probleme benutzbar, auch wenn sie mittlerweile ein Paar Jahre auf dem Buckel haben.
Zitat:
Ich hatte mal mit dem GCC 3.3 aus GG gespielt und der Compiler hat teilweise willkürliche Ergebnisse geliefert. Identisches Programm, compilliert und gelinkt funktionierte entweder korrekt, machte "merkwürdige" Dinge, oder brachte das System zum Abschmieren. Das ganze war ziemlich lästig.
Ich habe nicht den blaßesten Schimmer wie so ein Verhalten entstehen könnte.
Zitat:
Nutzt Dietmar bei Cubic eigentlich die GG Umgebung, bzw. was hat er anders gemacht?
Der Compiler benötigt eine gewisse Umgebung, dh. Assigns und Verzeichnise + Dateien unterhalb dieser Assigns. Die braucht es immer, egal ob reines GG oder Cubic.
Zitat:
Nur so als Hintergrund, um zu zeigen, warum ich die ganze Zeit auf dem Thema rumreite. Deswegen interessiert mich auch, wo noch irgendjemand was mit nativen GCC Umgebungen macht
Mir reicht (meist) ein Cross-Compiler. Für neue(r)e GCC-Versionen sind echte m68ks schlicht nicht leistungsfähig genug. Und mit 128MB/256MB kommt man vermutlich auch nicht weit, vor allem bei C++.
Zitat:
bzw. was genau eben adtools und Amiga_OS_68k_devtools für Projekte sind
adtools war/ist der Versuch Entwicklungswerkzeuge für verschiedene Spielarten von AmigaOS in einen Projekt zu bündeln. Nur die OS4 Unterstützung ist (halbwegs) vollständig, dh. binutils und GCC. Für m68k gibt es nur binutils. Die binutils enthalten auch Code für MorphOS, aber ob der funktioniert, weis ich nicht. Zu AROS kann ich gar nix sagen.
devtools ist eines der vielen Projekte von Bernd Roesch. Es ist sein Versuch neuere GCC Versionen als 3.4 für AmigaOS/68k nutzbar zu machen. Diesen dort verfügbaren Versionen fehlen alle speziellen Amiga-Features wie baserel Modus, stackcheck bzw. stackextenion Modus, Registerargumente (nur C), etc. Bernd vertritt die Auffassung das das alles nur unnötiger Ballast ist, den niemand braucht. Für mich definiert sich ein Amiga-Compiler aber genau dadurch, das er diese Feature hat.
Zitat:
und letzlich, warum die Entwicklungen nicht im offiziellen GCC Sourcetree stattfinden..
Weil es sehr schwierig ist, die Anpassungen von OS4 bzw AmigaOS/68k in die offiziellen Quellen zu bekommen. Zum einem muß jemand den Code später auch pflegen oder er wird wieder entfernt. Zum anderen erfordern die Amiga-Feature Änderungen an generischen Quellen und das ist ein echtes Hindernis.
 
gni   Nutzer

15.05.2009, 09:00 Uhr

[ - Direktlink - ]
Thema: GCC compiler error on new field creation
Brett: Programmierung

Zitat:
Reth:
C++ code:
void Image::scale(float sx,float sy) {
 ...
 unsigned char *new_data = new unsigned char[sx * w * sy * h * bytesperpixel];


Da die beiden Werte sx und sy allerdings als float übergeben werden könnte es damit zusammenhängen, oder?

Genau daran liegt es. Zumindest GCC 4(.3.2) mag das nicht.

Zitat:
Könnte es Probleme geben, wenn man dem GCC C++ Sourcen gibt und diese mit:

gcc c source.cpp ...

compiliert anstelle von:

g++ ...

? Oder spielt das keine Rolle?


Zum Übersetzen kann auch "gcc" verwendet werden, da das Frontend den passenden Compiler anhand des Suffixes der Quelldatei auswählt. Zum Linken sollte man aber besser "g++" benutzen, da dann automatisch an der richtigen Position gegen die libstdc++ (und eventuell libm) gelinkt wird. Das kann wichtig sein.


[ Dieser Beitrag wurde von gni am 15.05.2009 um 09:01 Uhr geändert. ]
 
gni   Nutzer

25.03.2009, 08:36 Uhr

[ - Direktlink - ]
Thema: GoldED Studio AIX und SDL-Installation
Brett: Programmierung

Zitat:
Reth:
Wie stellt das OS4-SDK bitte seine Include-Pfade für den GCC bereit? Konnte weder in den Assigns noch im Path was finden!


Der GCC hat "eingebaute" Pfade zu Includes und Libraries. Teilweise kommen solche Angaben auch aus dem "specs", zb. für newlib, clib2, etc.

Zitat:
Woher findet GCC denn die Inlucdes unterhalb von local/...?

Wenn es ein fest eingebauter Pfad ist, dann sucht der GCC dort von sich aus. Benutze beim Übersetzen die Option -v, dann zeigt Dir der GCC an welchen Stellen Includes gesucht werden.
 
gni   Nutzer

01.03.2009, 12:44 Uhr

[ - Direktlink - ]
Thema: S: beste Grafiklösung zum Anschluss eines Amiga 4000 D am TFT
Brett: Kleinanzeigen (keine Auktionen!)

Zitat:
AmigaHarry:
Auf der PIV ist in 16/24Bit die max. Res 1280x720ni bzw. 1120x832ni


Mit einem passenden TFT geht bei der PIV auch 1280x1024 in 16Bit ohne die Karte zu "überfahren".
 
gni   Nutzer

19.02.2009, 13:10 Uhr

[ - Direktlink - ]
Thema: spezielles JPEG-Anzeigeprogramm gesucht
Brett: Amiga, AmigaOS 4

Zitat:
Ralf27:
Gibt es ein Bildanzeigeprogramm das so ein Feature hat? Also ein JPEG gleich "kleiner in den Speicher läd" und gleich anzeigt?


Manche JFIF-Datatypes können das.
 
gni   Nutzer

08.12.2008, 09:12 Uhr

[ - Direktlink - ]
Thema: localtime() gmtime() sas/c
Brett: Programmierung

Zitat:
selco:
Ich bracuhe aber GMT, also verwende ich statt localtime() die Funktion gmtime()

Das bringt die Ausschrift "1:17:39", liegt also ein paar Stunden danben. Ich hätte 18:17 erwartet, also eine Stunde weniger, statt dessen bekomme ich 5 Stunden mehr???

Mache ich etwas falsch? Hat SAS/C da einen Fehler? Wenn ja, gibt es einen workaround oder patch? Gibt es einen offiziellen Weg, das richtig zumachen?


Du hast keine globale Umgebungsvariable TZ gesetzt, deshalb bekommst Du den SAS/C Defaultwert für _TZ. Das steht alles im Guide unter Zeitfunktionen/tzset.
 
gni   Nutzer

02.10.2008, 21:13 Uhr

[ - Direktlink - ]
Thema: AmiBlitz will nicht, welche alternative ist die Beste ?
Brett: Programmierung

Ich würde Dir vorschlagen, Du machst einen neuen Thread auf. Das Thema GCC ist hier off-topic. Ich weis, ich habe diese Abweichung angezettelt. Mea culpa. Meine letzte Antwort dazu hier. Mhm, warum nutzt niemand mehr usenet!?

Zitat:
bernd_roesch:
> Es gibt aber meines Wissens niemanden der aktiv an m68k entwickelt.

doch bei 68k ist einer dabei und ist als maintainer für 68k angegeben.

Das hat nichts zu sagen.

Zitat:
hier ist der trunk der 4.4.0 Version.da siehst du vor 3 wochen wurde etwas geändert bei 68k.Ich nehm mal an, wenn der was ändert, nutzt er das auch.ansonsten steht der als maintainer der 68k Version drin.nen grossen unterschied von coldfire zu 68k gibts da auch nicht.
Der Unterschied 68k/Coldfire ist gewaltig. Und nur weil eine Änderung vor 3 Wochen(!) gemacht wurde, bedeutet das nicht, das aktiv am m68k Port gearbeitet wird. Und wieviele Änderungen sind bei anderen Architekturen in den letzten drei Wochen vorgenommen worden?

Zitat:
im gcc 4.x source finde ich im file gcc/gcc/c-decl.c

finish_decl (tree decl, tree init, tree asmspec_tree)
{

sowas ähnliches

/* In conjunction with an ASMSPEC, the 'register'
keyword indicates that we should place the variable
in a particular register. */
if (asmspec && C_DECL_REGISTER (decl))
{
DECL_HARD_REGISTER (decl) = 1;
/* This cannot be done for a structure with volatile
fields, on which DECL_REGISTER will have been
reset. */
if (!DECL_REGISTER (decl))
error ("cannot put object with volatile field into register");
}

Das hat nichts mit Parameterübergabe in Registern zu tun. Das müßte für globale Registervariablen sein.

Zitat:
wie kann man denn einfach ohne optimizer usw kompilieren ohne das makefile zu ändern ?
Beim Konfigurieren CFLAGS angeben: CFLAGS= .../configure <args> und beim Bauen auch: make CFLAGS= bzw make CFLAGS="-O". Beim Konfigurieren kann man es vermutlich weglassen, aber ich geb es immer an. Redundanz hat noch nie geschadet ;)

Zitat:
Ausserdem würde ich gerne ne debugversion erstellen, die ich mit dem ddd source level debuggen kann.
Wenn Du nicht an den CFLAGS rumgespielt hast, dann wird doch mit -g gebaut und dann kannst Du doch debuggen?

Zitat:
>Ein GCC ohne die Amiga-spezifischen Erweiterungen ist unbrauchbar >und das oben genannte Feature ist eine reine Amiga-Erweiterung.

allerdings braucht das jeder gcc egal ob MOS oder OS4 und es muss von Hand eingebaut werden.

Da hast Du augenscheinlich ein Verständnisproblem. Weder MOS noch OS4 brauchen das. Auch bei AmigaOS/68k braucht man es nicht wirklich, da dort OS-Aufrufe mit einer existierenden GCC Erweiterung gemacht werden. Da jedoch SAS/C das unterstützt(e), mußte der Amiga-GCC Port das auch können ;-) Und ich benutze es gelegentlich auch, ist aber nur mit Obacht benutzbar.

Zitat:
da ich keine Lust habe um nen aktuellen Compiler zu erhalten immer viel von Hand einbauen zu müssen, suche ich ne Lösung die einfach einzubauen geht.wäre also in aller Interesse egal ob MOS oder OS4 AROS 68k.
Ohne Adaption der Patches an neue GCC Versionen geht es nicht. Punkt.

Zitat:
der aos code macht das in der func

push_parm_decl

allerdings fehlt der parameter asmspec tree.

Um an den Parameter zu kommen, muss man vieles ändern.

Nö muß man nicht. Zumindest nicht bei 4.2.x. Bei 4.3 mag das bereits anders aussehen.

Zitat:
diff -rupN gcc-3.4.0/gcc/c-decl.c gcc-3.4.0-gg/gcc/c-decl.c
--- gcc-3.4.0/gcc/c-decl.c Mon Mar 22 18:58:18 2004
+++ gcc-3.4.0-gg/gcc/c-decl.c Tue Apr 27 11:12:30 2004
@@ -2943,7 +2943,7 @@ finish_decl (tree decl, tree init, tree
and push that on the current scope. */

void
-push_parm_decl (tree parm)
+push_parm_decl (tree parm, tree asmspec)
{
tree decl;

Hast Du Dir mal überlegt wo bei 3.4.x der Parameter asmspec herkommt?
 
gni   Nutzer

02.10.2008, 15:58 Uhr

[ - Direktlink - ]
Thema: AmiBlitz will nicht, welche alternative ist die Beste ?
Brett: Programmierung

Zitat:
bernd_roesch:
es war der 4.3.2.unter cygwin habe ich die 68k version erstellt.zum vergleich sollte man schon diesselbe gcc Version nehmen.

Das Du 4.3.2 verwendet hast, hatte ich übersehen. FWIW, ich würde nicht mit 4.3 anfangen, auch wenn das die aktuelle GCC Version ist. Der Unterschied zu 3.4.0 ist einfach zu groß, zb. wurde in der Zwischenzeit der C-Parser ersetzt, Prologue und Epilogue werden jetzt per RTL gemacht, die Kommandozeilenparameter für m68k wurden geändert (IMO zum schlechteren), etc.

Zitat:
Hast du in 9 Minuten den ganzen gcc inkl libcpp, libdecnumber, libiberty, fixincludes (das wird sogar in 2 dirs erstellt)?
Wie geschrieben: 9min für configure+build bei 4.2.0. Das beinhaltet alles was gebraucht wird.

Zitat:
Hast du auch mal mit cygwin versucht, vielleicht geht es mit linux doch schneller. ?
Zu cygwin und Linux kann ich nichts sagen, da ich beides nicht benutze. Ich arbeite mit FreeBSD.

Zitat:
wenn ich den 4.3.2 kompiliere kommt ein cc1.exe file raus mit sagenhaften 17 Megabyte an size.und ein cc1plus.exe file von 18 megabyte. das kostet halt schon Zeit. erst wenn ich make install mache, bekommt es den üblichen Namen, und grösse(450 kb).
Ich verwende nicht die standardmäßigen CFLAGS. Soviel Plattenplatz habe ich nicht zur Verfügung. Ich baue ohne -g.

Zitat:
der gcc läuft einwandfrei, die testfiles gehen, nur kann man den in der Praxis derzeit nicht nutzen, da das feature um variablen in ein bestimmtes Register laden der standard gcc nicht kennt.kommt immer meldung error expectet ; , before asm.
Ein GCC ohne die Amiga-spezifischen Erweiterungen ist unbrauchbar und das oben genannte Feature ist eine reine Amiga-Erweiterung.

Zitat:
versteh ich echt nicht, warum das bei der amiga version extra gecodet wurde und nicht im gcc source ist. muss man doch in jedem OS das Parameter über Register übergibt können.
Da es nicht im GCC enthalten ist, scheint es wohl doch nicht notwendig zu sein?

Zitat:
ich habe auch mal den 4.4.0 aktuellen source kompiliert, der braucht sogar noch einiges länger. [...]
auf jedenfall zeigt es mal eins, dass auch 68k in neueren gcc geht, man hört ja öfters, dass 68k support in gcc nicht mehr weiter unterstützt wird.und im gcc history sieht man auch wie änderungen vorkurzer Zeit im 68k Code Generator gemacht wurden

m68k scheint ein Spezialfall zu sein. Auch nach größeren Änderungen am GCC-Kern hat der Port danach weiterhin funktioniert. Es gibt aber meines Wissens niemanden der aktiv an m68k entwickelt. Die letzten größeren Änderungen am m68k-Port sind durch ColdFire-Änderungen motiviert gewesen.


 
gni   Nutzer

02.10.2008, 15:10 Uhr

[ - Direktlink - ]
Thema: AmiBlitz will nicht, welche alternative ist die Beste ?
Brett: Programmierung

Zitat:
whose:
Jetzt ist die Frage, was sonst noch an Deinem System anders ist als an meinem oder z.B. Blackbirds.

Also für mich sieht es jetzt doch so aus, als ob sein System einen Fehler in AB3 zum Vorschein bringt. Eventuell wird ja bei ihm ein wichtiger Bereich des System "beschädigt", so das es zum Absturz kommt. Solche Fehler sind die schlimmsten, weil 99% ;-) sagen funktioniert und 1% hat Probleme...
 
gni   Nutzer

28.09.2008, 20:28 Uhr

[ - Direktlink - ]
Thema: AmiBlitz will nicht, welche alternative ist die Beste ?
Brett: Programmierung

Zitat:
bernd_roesch:
Wie quälend langsam das [make?] ist, sehe ich jetzt weil ich den gcc Kompiler nicht mit amidev kompilieren kann.

Das exe ist gerade mal 3 MB gross, ändere ich ein kleines file, braucht es 20 sec zum linken, (natürlich rufeich make im gcc verzeichnis auf, mache ich das über das gnaze dir, braucht es noch länger um rauszufinden, was nicht kompiliert werden muss.ändere ich ein header file, kompiliert der etwas über 5 Min.ein gesamt build braucht etwas über 22 minuten.

Ich nehme mal an es geht um den GCC 4.2.x? Unter welchem System wird übersetzt? Welche Sprachen werden gebaut? Bei mir dauert das Konfigurieren und einfaches Bauen von 4.2.0 mit C und C++ Compilern 9 Minuten auf einem "alten" Pentium-M 1.5GHz Laptop und langsamer Platte. Das ist zwar auch nicht wirklich schnell, aber erträglich. AFAIR wird GCC 2.95.x (C und C++) in ca. 3 Minuten gebaut.
 
gni   Nutzer

24.09.2008, 13:14 Uhr

[ - Direktlink - ]
Thema: AmiBlitz will nicht, welche alternative ist die Beste ?
Brett: Programmierung

Zitat:
Der_Wanderer:
Da ist also irgendwas faul bei dir. [...]

Ohne Ihm jetzt zu nahe treten zu wollen, aber es ist schon des öfteren vorgekommen das Patches oder Systemersatz-Software für unerklärliche Fehler gesorgt hat. Du erinnerst Dich bestimmt an Dein picture.datatype Debakel...
 
gni   Nutzer

09.09.2008, 08:15 Uhr

[ - Direktlink - ]
Thema: Partitionen auf USB-Stick
Brett: Amiga, AmigaOS 4

Zitat:
thomas:
Außerdem brauchst du bei der Deneb keine Rücksicht auf die 4GB-Grenze zu nehmen. Entweder die Deneb kann mehr als 4GB, dann kann sie das auch beim Booten, oder sie kann es nicht, dann geht es überhaupt nicht.

Warum soll die 4GB Beschränkung keine Bedeutung beim Booten von an der Deneb angeschlossenen Massenspeichern haben?
 
 
-1- 2 3 4 5 6 >> Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter      Benutzername
Suchoptionen
Nur in diesen Foren suchen
   nur ganze Wörter
Nur Titel anzeigen
alle Treffer anzeigen

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