Zitat:

---

Maverik:
Also ich hab noch 1152x900 in 24 bit ohne interlace mit meiner PicassoIV.

---

Zitat:

---

thomas:
Du solltest oben anfangen zu lesen. Das hat er doch alles schon ausprobiert.

---

Zitat:

---

Mit Video-DVDs geht's ja auch

---

Zitat:

---

aber hier geht es um eine Daten-DVD, vermutlich selbst gebrannt und entweder ohne oder mit einer fehlerhaften ISO-Brücke.

---

Zitat:

---

Original von Lolof:
Meine dektop os3.9 seiht sehr gute aus sogar in 256 Farben.

---

Zitat:

---

Ich frage mich ob es nicht möglich wäre die p4 overclocken um zu mehre Farbe verwenden zu können.

---

Zitat:

---

thomas:
Das einfachste dürfte sein, die DVD im PC einzulegen und das DVD-Laufwerk im Netzwerk freizugeben, sodaß der Amiga darauf zugreifen kann.

---

Zitat:

---

Robinausdemwald:
Ich hab mal mehrere libs aus dem libnix-Ordner ausprobiert, ergab alles aber keine Änderung (naja, mit den 68881-libs kam gleich beim Programmstart ein "Benötige FPU"-Requester).

---

Zitat:

---

DariusBrewka:
@thomas
Habe bei mir auch -lm und wenn ich hier bei WinUAE auf 020 noFPU stelle schmiert das nicht ab. Soweit ich sehe heissen alle Libs libm in dem lib Verzeichnis befinden sich aber Unterverzeichnise für FPU etc. d.h. man mus die wohl eher rüberkopieren.

---

Zitat:

---

thomas:
Ich denke mal, -lm ist falsch.

---

Zitat:

---

Du brauchst vermutlich ein -lmnofpu oder so ähnlich.

---

Zitat:

---

Bei VBCC ist es z.B. -lmieee.

---

Zitat:

---

thomas:
Treiber für deine Soundkarte jeweils nach Devs:Audiomodes bzw. Devs:AHI.

---

Zitat:

---

Mazze:
Jetzt gehts. Ich musste mit dem AmigaDos-Kommando "path" das Verzeichnis, in dem "sh" steht, einbinden.

---

Zitat:

---

whose:
Darf ich Dich einfach direkt fragen, sobald Fragen auftauchen?

---

Zitat:

---

Wenn ich folgendes in eine Shell eingebe:

code:

---

5.Work:CProj> sh
    # /sys/tools/editpad
    # sys:tools/editpad

---

dann startet der Editor in beiden Fällen.

---

Zitat:

---

Ich gehe mal davon aus, das Editpad aus Deinem Programm heraus immer noch nicht startet. Liegt das Verzeichnis Work:CProj/ im AmigaDos Suchpfad?

---

Zitat:

---

Palgucker:
An ENV-Variablen scheint es nicht zu liegen, denn die werden (laut SnoopDos) garnicht erst abgefragt.

---

Zitat:

---

Benenne ich aber Editpad in sh um, bekomme ich zumindest den RC 5120 und die Fehlermeldung:
Falsche Anzahl an Argumenten

---

Zitat:

---

r = System("");
ändere, startet Editpad und öffnet die Datei -c.

---

Zitat:

---

Also merkwürdig ist das schon, zumal man das aufzurufende Programm in sh umbenennen muss, ein alias reicht nicht.

---

Zitat:

---

Falcon:
Da kam mir die Frage in den Sinn. Wied der PPCLibEmu fon frank Wille eigentlich noch weiterentwickelt, bzw. ist das noch "heiß" ?

---

Zitat:

---

Es gibt ja nach wie vor einige Proggis (Candy-Factory z.B.), die nicht
mit der Emu laufen (zumindest bei mir nicht).

---

Zitat:

---

Mazze:
7.Workbench:> dir env:path
Could not get information for env:path
Objekt nicht gefunden

---

Macht es Sinn sichmit c:dir ein datei anzuzeigen? Versuchs mal c:list env:path (oder nur env: aber dann geht auch dir

Zitat:

---

7.Workbench:> sh
# echo $PATH
/bin:/usr/bin:/usr/ucb

---

Zitat:

---

Wie geht es weiter?

---

Zitat:

---

thomas:
Für DVD-R und DVD-RW brauchst du andere Software.

---

Zitat:

---

Dem AmigaOS 4.0 pre liegen außerdem Mountlisten bei, um CD-RW und DVD-RW mit SFS zu formatieren.

---

Zitat:

---

whose:
Ich bin viel zu verwöhnt von der Möglichkeit, den Suchpfad vorzugeben, merke ich gerade.

---

Zitat:

---

Original von Mazze:

code:

---

#include <stdlib.h>
#include <stdio.h>
int main (void)
{
  int r;
  r = system("EditPad");
  printf("Rück %dn", r);
  return 0;
}

---

Dieses Beispiel funktioniert, wenn ich mit "-noixemul" kompiliere. Ohne diese Option wird der Editor nicht gestartet und r den Wert 32512.
Ich habe schon versucht, den Linux-Pfad anzugeben (/sys/tools/editpad). Klappt aber nicht. Wie geht es?

---

Gennau so Ich habe das Beispiel (ohne printf) ausprobiert und es ging, wenn editpad im Suchpfad war. Bei Angabe des Pfades (entweder sys:tools/ oder /sys/tools/) hat es wie erwartet funktioniert. Gibt es auf Deinem System in env: eine PATH Variable? Wenn nicht dann prüf in der sh (ausführen und dann echo $PATH) welchen Wert die Variable hat.

Zitat:

---

Solar:

Zitat:

---

whose:
Der GCC erzeugt definitiv Assembler-Code. Man kann ihn aber in der Ausgabe des Assembler-Codes weitgehend frei konfigurieren.

---

Ich bin baff. Das eröffnet evtl. für mein OS-Projekt ganz neue Möglichkeiten...

---

Zitat:

---

whose:
Der GCC erzeugt definitiv Assembler-Code. Man kann ihn aber in der Ausgabe des Assembler-Codes weitgehend frei konfigurieren.

---

Zitat:

---

Ich müßte jetzt also erstmal klären, welcher Assembler beim StormC im GCC-Modus zum Einsatz kommt. Ists der AS, habe ich schon wieder ein Problem, dann bräuchte ich Informationen über den AS-Pass, die auf den GCCint-Pages nicht zu finden sind (oder ich bin blind, kann ja auch sein ).

---

Gute Frage Jedoch was willst/mußt Du wissen?

Zitat:

---

Dann wäre es so, wie ich es vermute, nämlich daß der Output des GCC an den Rest des StormC angepaßt wurde (in diesem Fall StormASS) und die zwei Quelldateien, die den ARexx-Output besorgen, eine Entsprechung beim 3.4.1 haben müssen. Dann sollte es nicht so ein Riesen-Problem werden. Könnte zwar länger dauern bis da Ergebnisse kommen (ich kenn mich ), aber unmöglich ists nicht.

---

Zitat:

---

Solar:

Zitat:

---

von gni:
Der GCC (genauer der Compiler) erzeugt Assemblerbefehle, die dann von einem Assembler (meist (G)nu (AS)sembler) zu einem Objektfile gemacht werden.

---

Das ist meines Wissens nicht korrekt.

---

Zitat:

---

Ich habe mich vor Zeiten mal mit den Internas von GCC auseinandergesetzt, insbesondere dem Backend-Interface - allerdings nur oberflächlich. Aus der Zeit meine ich mich erinnern zu können, daß der ASM-Code, zu dem man seinen C/C++-Code wandeln kann, quasi eine Rückübersetzung aus einem schon tiefer gehenden internen Format sei; GCC würde nicht den Umweg über ASM-Code machen, sondern direkt die interne Repräsentation (Trees?) an den Code-Generator von GAS übergeben.

---

Zitat:

---

Zunächst einmal sollte man prüfen, ob nicht schon eine Neukonfiguration / Neukompilierung der Toolchain das gewünschte Format abwirft.

---

Im Falle von StormC ist das wohl nicht der Fall

Zitat:

---

whose:
Also, wenn ich das Prinzip von GCC richtig verstanden habe, erzeugt selbiger aus dem C-Code Code, der in der Struktur bereits dem gewünschten Ausgabeformat (object-format) in Sachen Linker gleicht, richtig?

---

Aeh, nein Der GCC (genauer der Compiler) erzeugt Assemblerbefehle, die dann von einem Assembler (meist (G)nu (AS)sembler) zu einem Objektfile gemacht werden. Der AmigaOS Port verwendet _nicht_ Hunk-Objekte (wie zb. SAS/C) sondern a.out (ein altes UN*X Format).

Zitat:

---

Normalerweise wäre das der GCC-eigene Linker. Bei StormC ist es halt StormLink. Da liegt, soweit ich das durchblicken konnte, der einzige Haken.

---

Zitat:

---

Alle weiteren Modifikationen betreffen die Ausgabe der GCC-Meldungen während des Compiler-Laufs, die ja normalerweise auf stdout gehen, für die Storm IDE aber auf ARexx umgestrickt werden. Oder gibts da noch mehr?

---

Zitat:

---

Ich konnte nämlich nur insgesamt 3 Dateien finden, die vom Original abweichen. 2 davon sind eindeutig die Umlenkung der GCC-Meldungen auf einen ARexx-Port. Eine GCC-eigen, eine Storm-eigen (die Storm-eigene gehört nicht ursprünglich zum Sourcetree des GCC). Die eine, die ich kaum durchblicke, muß mit dem Object-Format zu tun haben. Jetzt müßte ich vor allem wissen, wie diese "Umwandlung" normalerweise vonstatten geht, dann wäre ich schon erheblich weiter.

---

Zitat:

---

Ich hab vor allem ein wüstes Mischmasch veranstaltet, weil der 2.95.x fehlerhafte (unbrauchbar für meine Zwecke) ARM-Unterstützung hat. Der Prozessor, um den es ging (StrongARM), wurde erst ab dem 2.95.3 halbwegs ordentlich unterstützt. Im Grunde lief der Compiler was die StormC-Spezialitäten betrifft ja auch. Und es kam (manchmal) sogar Code für den StrongARM heraus, leider nur nicht immer und schon gar nicht funktionierend. Es war ein Experiment. Ich hatte halt nicht gedacht, daß der 2.95.2 und der 2.95.3 doch so unterschiedlich ausfallen. Nenn es Naivität

---

Zitat:

---

Zitat:

---

IMHO geht genau das nicht. Was für Tips sollten das sein?

---

Z.B. einen groben Überblick, wie der GCC den Code normalerweise erzeugt.

---

Zitat:

---

Wo muß man einhaken, wenn man ein anderes Object-Format erhalten will, weil man einen GCC-fremden Linker verwenden möchte?

---

Zitat:

---

whose:

Zitat:

---

gni:
Ja übernommen wurden da die GG Modifikationen. Aber anstatt die Dinge zu lassen wie sie sind, wurden sie für StormC grausamst reingehackt. Vermutlich ist das im PPC Teil genau so.

---

Hm, wenn mir wer sagt, was da alles krumm ist und wie das richtig sein sollte, bin ich bereit, mir die Arbeit auch noch aufzuhalsen.

---

Zitat:

---

Zitat:

---

Ach so, Du hast versucht den Cross-Compiler auf dem Amiga für den Amiga zu bauen. [...]

---

Nein, noch komplizierter: Ich wollte nen ARM-Cross-Compiler mit 68K-AmigaOS-Host bauen.

---

Zitat:

---

Hat im Prinzip (es ergab ein funktionstüchtiges Executable) auch funktioniert. Leider war da noch ein bißchen mehr im Argen als die Anpassungen an StormC. Aber da ich bei diesem Monster (GCC)nicht so den Durchblick und daher mehr geraten als Sinnvolles gemacht habe, wundert mich das weniger. Wäre halt nur schön gewesen, wenn ich den nötigen Durchblick gehabt hätte, ums zum Laufen zu kriegen. Prinzipiell steht dem jedenfalls nichts im Wege.

---

Zitat:

---

Hm, für die Bezahlung kann ich schlecht sorgen, schließlich bin ich nicht H&P.

---

Zitat:

---

Aber die Arbeit würde ich mir schon zumuten, wenn mir jemand ein paar Tips geben könnte, wo und wie. Ist ja nicht so, daß ich dadurch keine Vorteile hätte

---

Zitat:

---

whose:
Für mich als "Anwender" des GCC-Compilers ist es wichig, daß die Executables, die herauskommen, möglichst schnell herauskommen

---

Zitat:

---

und bei den Anwendern derselben schnell laufen

---

Zitat:

---

und nicht zu groß sind.

---

Zitat:

---

Wenn aber das Executable, das zum Erzeugen Deines Executables verwendet wird, langsam ist, dauerts auch länger, bis Du etwas zum Anwenden bekommst.

---

Zitat:

---

Wenn es schwer beherrschbar ist, dann auch. Was ist Dir als Anwender lieber? Dein Executable möglichst schnell zu bekommen oder lieber drauf zu warten, weil der Entwickler Probleme mit dem Executable zum Erzeugen Deines Executables hat?

---

Zitat:

---

thomas:
Die Partition kann erst angemeldet werden, wenn das dazugehörige Dateisystem geladen ist. Also muß das Dateisystem irgendwo außerhalb der Partitionen gespeichert werden. Nämlich in den ersten beiden Zylindern der Festplatte, die nicht partitioniert werden können. Dort liegt der RDB. Er besteht aus der Partitionstabelle und den Dateisystemen.

---

Zitat:

---

Solar:
2) Weil auf Windows Free- und Shareware generell weniger bekannt ist, und Linuxer i.d.R. auf vi und Emacs schwören, statt auf einen Editor mit vernünftiger GUI.

---

Zitat:

---

Sicherlich kennst Du WinZIP für Windows. Kennst Du auch FreeZip?

---

Zitat:

---

whose:
Soweit ich die Sourcen verstanden habe, war das einzig problematische die Unterstützung in den Obj für EHF (PPC) des StormLink, die hab ich auch nicht so ganz geblickt.

---

Zitat:

---

68K Obj sah mir eher so aus, als wären die (mit wenigen Modifikationen) vom GG-GCC genommen worden.

---

Zitat:

---

Zitat:

---

Die AmigaOS/68k Binaries wurden per Cross-Compiler gebaut (und entwickelt). Kann man sehr schön mit -v sehen ;-)

---

Glaube ich Dir ja, aber mein Versuch, nen Cross-Compiler zu bauen schlug halt ein bißchen fehl

Schade eigentlich, denn sonst wäre der auch mit der StormC-IDE einsetzbar gewesen (ich hab versucht, den aus den StormC-Quellen zu bauen. Die Fehlermeldungen hat er sogar in der IDE ausgegeben, aber was hilfts, wenn er schon unter simpelsten Umständen keinen ordentlichen Code erzeugt? (Unknown Identifier) )

---

Zitat:

---

whose:
Okay, den GCC 3.3 statt den 2.95.2, aber das wäre kein so großer Akt denke ich, wenn sich gni mal dransetzen würde, um die StormC-Targets für den 3.3 zu implementieren. Source ist ja vorhanden.

---

Zitat:

---

Hätt ich den Durchblick beim GCC hätte ich das schon längst getan.

---

Zitat:

---

Aber mein Ausflug in Sachen ARM-GCC (Crosscompiler) hat mir gereicht...:lach:

---

Zitat:

---

Inferno:
int jitTest(int innerLoop, int outerLoop) {
** rest wie oben, ersetze 1000000 mit outerLoop und 1000 mit innerLoop **
}

---

Auch das _könnte_ der Compiler als konstant erkennen, wenn der Aufruf der Funktion in der selben Übersetzungeinheit (meist die Quelle) erfolgt. Die Parameter beim Aufruf sind ja konstanten

Zitat:

---

DariusBrewka:
Habe mich verschrieben, CreateNewProcTags() kehrt nicht zurück

---

Zitat:

---

Bitte nicht fragen, warum 16 Signale nicht reichen, aber es ist so

---