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

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

Erste << 19 20 21 22 23 -24- 25 26 27 28 29 >> Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)
gni   Nutzer

26.08.2004, 08:10 Uhr

[ - Direktlink - ]
Thema: A4000D+PicassoIV+17"TFT
Brett: Amiga, AmigaOS 4

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

Welcher TFT benutzt diese Auflösung? ;-)
 
gni   Nutzer

25.08.2004, 15:05 Uhr

[ - Direktlink - ]
Thema: Daten DVD am Amiga lesen
Brett: Amiga, AmigaOS 4

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

Das er CacheCDFS ausprobiert hat, geht aus seinem Posting nicht hervor.
Zitat:
Mit Video-DVDs geht's ja auch
Was geht? Sie mit einem x-beliebigen CDROM-FS zu lesen?
Zitat:
aber hier geht es um eine Daten-DVD, vermutlich selbst gebrannt und entweder ohne oder mit einer fehlerhaften ISO-Brücke.
AFAIK, ist eine Video-DVD eine normale Daten-DVD. Sie muß zwar spezielle Ordner haben und die Dateigröße ist begrenzt, aber das spielt ja wohl keine Rolle für die Nutzung eines CDROM-FS. Das selbst-gebrannt hatte ich allerdings übersehen. Wenn die ISO-Bridge fehlt, dann hat er wohl Pech. Per Netzwerk wird er wohl auch keine Freude daran haben, 10MBit/s ist einfach zuwenig.
 
gni   Nutzer

25.08.2004, 09:26 Uhr

[ - Direktlink - ]
Thema: A4000D+PicassoIV+17"TFT
Brett: Amiga, AmigaOS 4

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

Mehr ist bei großen Auflösungen (>1024) auch nicht drin.
Zitat:
Ich frage mich ob es nicht möglich wäre die p4 overclocken um zu mehre Farbe verwenden zu können.
Laß es bleiben.

[ Dieser Beitrag wurde von gni am 25.08.2004 editiert. ]
 
gni   Nutzer

25.08.2004, 09:24 Uhr

[ - Direktlink - ]
Thema: Daten DVD am Amiga lesen
Brett: Amiga, AmigaOS 4

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.

Wenn er eine DVD_aufwerk am Amiga hat, kann er vermutlich jedes x-beliebiges CDROM-Filesystem nehmen weil die meisten DVDs eine UDF-ISO Bridge haben. Ich hatte testweise mal einen DVD-Brenner per USB angeschlossen und konnte mittels CacheCDFS auf eine Video-DVD zugreifen.
 
gni   Nutzer

06.08.2004, 10:20 Uhr

[ - Direktlink - ]
Thema: GCC 2.95.3 und float
Brett: Programmierung

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

So muß es auch sein. Vermutlich sind Deine libnix Bibliotheken durcheinander geraten. Am besten alle nochmal installieren (aus einem temp Verzeichnis drüber kopieren sollte reichen)
 
gni   Nutzer

06.08.2004, 10:18 Uhr

[ - Direktlink - ]
Thema: GCC 2.95.3 und float
Brett: Programmierung

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.

Um Himmelswillen, liesst denn niemand Dokumentation(en)? Lass bloss alle Bibliotheken wo sie sind. Das Frontend (gcc/g++) sagt dem Linker wo Bibliotheken gesucht werden sollen abhängig von den angegebenen Optionen -m680X0 und -m68881.
 
gni   Nutzer

06.08.2004, 10:15 Uhr

[ - Direktlink - ]
Thema: GCC 2.95.3 und float
Brett: Programmierung

Zitat:
thomas:
Ich denke mal, -lm ist falsch.

Nein, das ist richtig. Die Mathebliothek heisst immer libm.a
Zitat:
Du brauchst vermutlich ein -lmnofpu oder so ähnlich.
Wenn man -m68881 nicht benutzt, dann wird eine NOFPU libm.a verwendet.
Zitat:
Bei VBCC ist es z.B. -lmieee.
Er verwendet aber den GCC, der ganz anders ist als VBCC ;-)
 
gni   Nutzer

29.07.2004, 08:33 Uhr

[ - Direktlink - ]
Thema: AHI 5.13 für m68k - wie installieren?
Brett: Amiga, AmigaOS 4

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

Nur der Paula-Treiber ist (scheinbar?) nicht dabei. Zum Glück gibst die Quellen ;-)
 
gni   Nutzer

28.07.2004, 09:24 Uhr

[ - Direktlink - ]
Thema: system / noixemul
Brett: Programmierung

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

Ups, gg:bin ist bei mir natürlich im Pfad. Hast Du ein bin: assign? Beides gehört zu einer "Standard"-Installation von GG. Wieso fehlte das Verzeichnis? AFAIK, müsstes es auch ohne bin: im AmigaDOS Pfad gehen, da die sh in /bin(=bin:) gesucht wird. In diesem Fall bin ich mir aber nicht ganz sicher, was die ixemul genau tut.
 
gni   Nutzer

26.07.2004, 17:15 Uhr

[ - Direktlink - ]
Thema: Mono für Amiga
Brett: Programmierung

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

Ja. Ich kann aber nicht garantieren, das ich eine Antwort haben werde :-)
 
gni   Nutzer

26.07.2004, 17:14 Uhr

[ - Direktlink - ]
Thema: system / noixemul
Brett: Programmierung

[quote]
Palgucker:
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.

Immerhin etwas ;-) Was ist wenn Du einer der beiden Zeilen ins Programm übernimmst? Wenns direkt in der sh geht, sollte es auch per programm gehen.
Zitat:
Ich gehe mal davon aus, das Editpad aus Deinem Programm heraus immer noch nicht startet. Liegt das Verzeichnis Work:CProj/ im AmigaDos Suchpfad?
Der AmigaDOS Pfad ist für ixemul _irrelavant_. Bei einem absoluten Pfad ist der AmigaDOS Pfad auch bedeutungslos.
 
gni   Nutzer

26.07.2004, 17:08 Uhr

[ - Direktlink - ]
Thema: system / noixemul
Brett: Programmierung

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

Ha, reingefallen! ixemul puffert env:, da das Auslesen eines Verzeichnisses langsam ist.
Zitat:
Benenne ich aber Editpad in sh um, bekomme ich zumindest den RC 5120 und die Fehlermeldung:
Falsche Anzahl an Argumenten

Was versuchst Du? Du kannst nicht ein beliebigen Programm sh nennen! ixemul ist eine _un*x Emulation_ und verhält sich entsprechend.
Zitat:
r = System("");
ändere, startet Editpad und öffnet die Datei -c.

Weil das Argument von system() an die sh per -c übergeben wird.
Zitat:
Also merkwürdig ist das schon, zumal man das aufzurufende Programm in sh umbenennen muss, ein alias reicht nicht.
Keine Ahnung was bei Euch das Problem ist. Hier funktioniert es wie es soll. Vermutlich ist es nur im Posting falsch, aber die Funktion heisst system (kleines s). Gibt es bei Dir ein env:PATH?

[ Dieser Beitrag wurde von gni am 26.07.2004 editiert. ]
 
gni   Nutzer

23.07.2004, 17:35 Uhr

[ - Direktlink - ]
Thema: PPCLibEmu - Kommt da noch was ???
Brett: Amiga, AmigaOS 4

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

AFAIK, nein. An der Emu wird von ihm nichts mehr gemacht. Aber es gibt doch die Quellen ;-)
Zitat:
Es gibt ja nach wie vor einige Proggis (Candy-Factory z.B.), die nicht
mit der Emu laufen (zumindest bei mir nicht).

Sushi oder Sashimni und die Debugversion der Emu sollten Dir sagen an welcher Funktion es hapert.


[ Dieser Beitrag wurde von gni am 23.07.2004 editiert. ]
 
gni   Nutzer

23.07.2004, 09:16 Uhr

[ - Direktlink - ]
Thema: system / noixemul
Brett: Programmierung

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

Das sieht nach den Satnadrdeinstellungen aus (also kein env:path)
Zitat:
Wie geht es weiter?
system("/sys/tools/editpad") oder halt system("sys:tools/editpad") sollte Editpad ausführen bei Verwendung der ixemul. Bei -noixemul gehts ohne Pfad oder mit dem Amigapfad, da indem Fall die Einstellung von c:path des Vaterprozesses deines Programmes (entweder eine Shell oder die WB) auschlaggebend ist.
 
gni   Nutzer

22.07.2004, 16:38 Uhr

[ - Direktlink - ]
Thema: DVD-Brenner & AOS4/MakeCD
Brett: Amiga, AmigaOS 4

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

Welche?
Zitat:
Dem AmigaOS 4.0 pre liegen außerdem Mountlisten bei, um CD-RW und DVD-RW mit SFS zu formatieren.
Was soll das sein, sowas wie Packet-Writing? Welche Software macht das unter OS4? Gibst UDF für OS4?
 
gni   Nutzer

22.07.2004, 12:51 Uhr

[ - Direktlink - ]
Thema: system / noixemul
Brett: Programmierung

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

Bei ixemul ist es /leicht/ anders. Da ist nicht c:path entscheidend, sondern $PATH der /bin/sh. Das sollte man bei ixemul (der UN*X Emulation) beachten.
 
gni   Nutzer

22.07.2004, 08:14 Uhr

[ - Direktlink - ]
Thema: system / noixemul
Brett: Programmierung

Zitat:
Original von Mazze:
code:
#include <stdlib.h>
#include <stdio.h>
int main (void)
{
  int r;
  r = system("EditPad");
  printf("Rück %d\n", 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.
 
gni   Nutzer

21.07.2004, 13:03 Uhr

[ - Direktlink - ]
Thema: Mono für Amiga
Brett: Programmierung

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

21.07.2004, 13:02 Uhr

[ - Direktlink - ]
Thema: Mono für Amiga
Brett: Programmierung

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

Man kann nur zwischen MIT und Motorola Syntax wählen. MIT versteht auf dem Amiga nur GAS. Inwieweit die generierten Motorola Assmeblermnemonics kompatible zu nicht GAS Assembler sind, ist mir nicht bekannt.
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.
Gehts Dir um m68k, PPC oder beides? Die m68k Patches von 2.95.x an 3.x anzupassen ist _nicht_einfach. Wenn Du versuchst der StormIDE einen neuen Compiler zu verpassen solltest Du die Stormänderungen sauber einpassen. H&P haben das nicht getan.
 
gni   Nutzer

21.07.2004, 12:57 Uhr

[ - Direktlink - ]
Thema: Mono für Amiga
Brett: Programmierung

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.
Ich bin zwar kein GCC Experte, aber meine obige (vereinfachte ;-) Darstellung ist 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.
Zuerst werden TREEs erzeugt, dann RTL und zum Schluß generiert das Backend Assembler. Für whose wird wohl nur der Backendteil interessant sein. GAS ist _kein_ Code-Generator, es ist der separate GNU Assembler.
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 ;)
 
gni   Nutzer

20.07.2004, 16:13 Uhr

[ - Direktlink - ]
Thema: Mono für Amiga
Brett: Programmierung

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.
Ganz zum Schluss kommt dann der Linker. Storm verwendet einen eigenen (eventuell auch einen eigenen Assembler?)
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?
Kann ich nicht genau sagen. Dieser Teil war für mich uninteressant.
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.
Es ist schon ne Weile her, das ich mit die Storm-Quellen angesehen habe. Um welches File geht es Dir?
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 ;)
Es gab doch ein Update von Storm nauf 2.95.3 als Basis? Gut möglich, das 2.95.x nicht besonders gut für StrongARM geeignet war.
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.
Der Compiler ereugt Assembler Dateien.
Zitat:
Wo muß man einhaken, wenn man ein anderes Object-Format erhalten will, weil man einen GCC-fremden Linker verwenden möchte?
Das macht der Assembler. Der muß halt verstehen, was aus dem Compiler rauskommt.
 
gni   Nutzer

19.07.2004, 13:05 Uhr

[ - Direktlink - ]
Thema: Mono für Amiga
Brett: Programmierung

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.
So geht das nicht. Das kann man nicht erklären, wenn überhaupt kein grundlegendes Verständnis da ist. Bevor man sich die StormC Quellen antut, sollte man sich erst mit dem ursprünglichen GCC Port befassen. Erst danach macht es Sinn, die H&P Quellen sich anzuschauen und zwar so: Original 2.95.x Version holen und mittels diff mit den H&P Quellen vergleichen.
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.
Das hab ich doch gesagt: "für den Amiga" sollte "mit Amiga als Host" heissen.
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.
Wenn Du die H&P Quellen genommen hast, um den Cross-Compiler zu bauen, dann denke ich, das genau das nicht geht (ohne Änderung an den Quellen)
Zitat:
Hm, für die Bezahlung kann ich schlecht sorgen, schließlich bin ich nicht H&P.
So war das auch nicht gemeint ;-)
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 ;)
IMHO geht genau das nicht. Was für Tips sollten das sein?
 
gni   Nutzer

19.07.2004, 12:56 Uhr

[ - Direktlink - ]
Thema: Mono für Amiga
Brett: Programmierung

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

-O0
Zitat:
und bei den Anwendern derselben schnell laufen
Das liegt an Dir.
Zitat:
und nicht zu groß sind.
Das liegt auch an Dir.
Zitat:
Wenn aber das Executable, das zum Erzeugen Deines Executables verwendet wird, langsam ist, dauerts auch länger, bis Du etwas zum Anwenden bekommst.
Du mußt nicht die allerneueste Version zum Entwickeln nehmen. Oder man benutzt eben einen Cross-Compiler.
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? :)
Von einem Entwickler erwarte ich, das er mit seinen Werkzeugen umgehen kann.
 
gni   Nutzer

19.07.2004, 10:51 Uhr

[ - Direktlink - ]
Thema: FFS versus SFS
Brett: Amiga, AmigaOS 4

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.

Schon mal was vom ROM Filesystem gehört?

SCNR,
Gunther
 
gni   Nutzer

16.07.2004, 13:54 Uhr

[ - Direktlink - ]
Thema: Mono für Amiga
Brett: Programmierung

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.

Definiere vernünftig... Ich denke Du kennst Den Spruch: "UNIX ist ein benutzerfreundliches Betriebssystem. Es ist in der Wahl seiner Freunde jedoch sehr wählerisch".
Wenn Du über Editoren reden möchtest, dann geh ins Usenet.
Zitat:
Sicherlich kennst Du WinZIP für Windows. Kennst Du auch FreeZip?
Ich kenne ZipStar.
 
gni   Nutzer

16.07.2004, 11:45 Uhr

[ - Direktlink - ]
Thema: Mono für Amiga
Brett: Programmierung

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.

Den Teil habe ich nur überflogen.
Zitat:
68K Obj sah mir eher so aus, als wären die (mit wenigen Modifikationen) vom GG-GCC genommen worden.
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.
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 :D

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) :D )

Ach so, Du hast versucht den Cross-Compiler auf dem Amiga für den Amiga zu bauen. Wie ich bereits sagte, die H&P Patches sind grausamst reingehackt. Da wurde kein Wert auf Cross-Compiler gelegt. Da ist nichts zu machen. (Andererseits auch die GG Patches hätten Probleme einen Cross-Compiler auf AmigaOS zu bauen. Die AmigaOS spezifischen Host-Teile verwenden die Annahme, das wenn der Host AmigaOS ist, auch das Target AmigaOS ist.)
Selbst wenn ich wollte, könnte ich neuere GCC Versionen nicht an die StormIDE anpassen. Mir fehlt schlicht StormC4. Wenn H&P so einen Port bezahlt, dann würde ich darüber nachdenken ;-)

[ Dieser Beitrag wurde von gni am 16.07.2004 editiert. ]
 
gni   Nutzer

15.07.2004, 11:53 Uhr

[ - Direktlink - ]
Thema: Mono für Amiga
Brett: Programmierung

[zapped]

[ Dieser Beitrag wurde von gni am 15.07.2004 editiert. ]
 
gni   Nutzer

15.07.2004, 11:52 Uhr

[ - Direktlink - ]
Thema: Mono für Amiga
Brett: Programmierung

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.

Hast Du Dir die Storm-Quellen des GCC mal angesehen? Nachdem ich die AmigaOS/68k Modifikationen besser vertstand, habe ich mir die Storm Quellen nochmal angesehen: Schlimm! Dort wurde alles getan um die Nachnutzung so schwer wie möglich zu machen. Obs Absicht oder Unvermögen war, kann ich nicht sagen. Selbst deren eigener Versuch auf eine neuere GCC Version wurde dort unnötig erschwert.
Ich bin mit dem "normalen" GCC ganz zufrieden ;-)
Zitat:
Hätt ich den Durchblick beim GCC hätte ich das schon längst getan.
Man muß nur wollen :-)
Zitat:
Aber mein Ausflug in Sachen ARM-GCC (Crosscompiler) hat mir gereicht...:lach:
Die AmigaOS/68k Binaries wurden per Cross-Compiler gebaut (und entwickelt). Kann man sehr schön mit -v sehen ;-)

[ Dieser Beitrag wurde von gni am 15.07.2004 editiert. ]
 
gni   Nutzer

15.07.2004, 11:44 Uhr

[ - Direktlink - ]
Thema: Mono für Amiga
Brett: Programmierung

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

14.07.2004, 13:03 Uhr

[ - Direktlink - ]
Thema: CreateNewProcTags & MOS
Brett: Programmierung

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

Muß der neue Prozess eine größere Priorität als Main haben?
Zitat:
Bitte nicht fragen, warum 16 Signale nicht reichen, aber es ist so
Das sich Intuition-Fenster einen MsgPort teilen können, weißt Du? Eventuell kann Dir auch SIGB_SINGLE helfen.
 
 
Erste << 19 20 21 22 23 -24- 25 26 27 28 29 >> 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 © 1998-2022 by amiga-news.de - alle Rechte vorbehalten.
.