|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Mono für Amiga | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| 1 -2- 3 4 5 6 | [ - Beitrag schreiben - ] |
|
13.07.2004, 14:58 Uhr Solar Posts: 3680 Nutzer |
Zitat: Nein, nein, in Assembler, der einzigen "wahren Programmiersprache". Alles andere ist ja für Weicheier...  [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 15:26 Uhr ylf Posts: 4112 Nutzer |
Assembler ist was für Microcontroller, nichts für Desktop-CPUs. Aber der 68k ist aus heutiger Sicht eigentlich mehr ein Microcontroller, als eine CPU. Ach verdammt! Es gibt ja auch schon C-Compiler für die kleinsten Microcontroller. ::D: bye, ylf [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 16:08 Uhr whose Posts: 2156 Nutzer |
Gibt sogar einen Cross-C-Compiler für die 6502-CPU aus den seligen 8-Bit-Tagen. Und man lese und staune: den gibts sogar für unseren Amiga. Mono, .NET, Java etc. sind zwar im Big Business sicher angesagte Sachen und ich verstehe sehr gut, daß die Leutz, die davon leben müssen, sich um den Amiga keine Gedanken mehr machen. Wenn allerdings jemand behauptet, ohne entsprechende Plattformen oder "Technologien" wäre kein Geld zu machen, der weiß schlicht und ergreifend nicht, wie Märkte funktionieren. Man _kann_ mit dem Amiga Geld verdienen, wenn man nicht ständig auf die "andere" Seite schielt. Hat man allerdings das Verlangen, Millionen zu scheffeln ist man beim Amiga sicher an der falschen Adresse. So viel zu diesem Thema. Sicher ist es grundfalsch und spricht von Ahnungslosigkeit, wenn einer wie unser CHKamiga ständig was von Assembler als dem einzig Wahren faselt. Andererseits darf man den "Profis" hier auch vorhalten, daß sie nicht alle Facetten des Geschäfts kennen, wenn sie meinen, man bräuchte Assembler nie mehr oder es wäre Unsinn, damit noch etwas zu entwickeln. Manchmal seit ihr auf einem Auge (dem Nicht-POSIX-Auge) blind. Standards sind kein Allheilmittel und der Vielfalt sicher auch nicht förderlich. Denkt einfach mal an das Thema "Software-Patente". Anstatt sinnlos über Für und Wieder von Assembler zu diskutieren solltet ihr lieber dem JAmiga-Team helfen. Dann ist Java für den Amiga nicht mehr weit. In den Grundzügen ist es ja bereits da. Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 16:23 Uhr Solar Posts: 3680 Nutzer |
Zitat: Kurz vorher hattest Du noch von "Zeilen" gesprochen. Entscheide Dich mal. Zitat: Das nennt man "Standardbibliothek". Netterweise ist eine solche sprachspezifisch und steht somit auf jeder Plattform zur Verfügung, weshalb ich mir keine Gedanken darüber machen muß, wie der Schmorenz auf den Bildschirm kommt. Wie sieht denn Dein ASM-"Hello World" aus? Du wirst doch nicht etwa irgendwelche Library-Calls machen, und schön direkt in den Grafikspeicher schreiben, oder? :;): Wahlweise kann ich auch auf die Standardlib verzichten und genauso im Speicher herumprokeln, wie Du das unter ASM machen würdest. Aber dann könnte ich ja auch gleich ASM schreiben... Zitat: Ich könnte Dir sogar einen kompletten Kernel schicken, der "Hallo Welt!" auf dem Bildschirm ausgibt, bis auf ein paar Byte ASM in C++ (!) geschrieben und auch nicht länger als eine ASM-Lösung. (Nimm's einfach als Tatsache; Du wärst wahrscheinlich eh nicht in der Lage, ihn zu testen.) Aber wir sind hier nicht bei "meiner ist kleiner als Deiner". Zitat: Nein, Du redest von Geschwindigkeit... Zitat: Nein, verkehrt. Perl ist eine interpretierte Sprache. Was Du da siehst, ist die "fertige" Form des Programms. Natürlich wird das vor der Ausführung noch übersetzt, aber das wird Java auch. Deswegen würdest Du einer .class-Datei auch nicht in Abrede stellen, ein Programm zu sein. Ein weiterer Punkt, der zeigt, wie weit Du noch davon entfernt bist, ein "Programmierer" zu sein, oder über die Tauglichkeit von Java und .NET qualifizierte Aussagen zu machen. Zitat: Komisch dann, daß nicht einmal das OS selbst in ASM, sondern in C geschrieben ist. Komisch dann, daß ich selbst auf meinem 206 MHz StrongARM-PDA mit gutem Erfolg C++- und Perl-Programme verwende. Außerdem ging es in diesem Thread um zukünftige Entwicklungen, und in diesem Rahmen setzen AmigaOne und Pegasos die Maßstäbe. Der Classic interessiert nur noch als Nostalgieobjekt, Punktum. Zitat: Genau andersherum wird ein Schuh daraus: Eine Entwicklung nur für den Amiga macht wirtschaftlich überhaupt keinen und Freeware/Shareware/OpenSource-mäßig nur noch wenig Sinn. Somit ist der ausschlaggebende Faktor die Portierbarkeit zum Amiga, nicht vom Amiga... Zitat: Woz hat u.a. die ROMs für den Apple II in Maschinencode programmiert. Nix Assembler, rohes Hex! Dem Faulheit vorzuwerfen ist mal wieder ein typischer chkamiga... Nein, das Problem war, daß niemand außer Woz durch den Code durchblickte, und Woz alleine die notwendigen Änderungen nicht schnell genug fertigstellen konnte. Und die wenigsten schaffen es, wie Woz etwas von der Größe eines BASIC-Interpreters zu assemblieren, ohne dabei einen einzigen Fehler zu machen... Zitat: Somit brauchen wir gar nicht erst gegeneinander anzutreten. Ich habe nämlich keine Lust, Wochen lang darauf zu warten, daß Du zu einem nicht-trivialen Stück C++ das ASM-Pendant zusammenstoppelst. Einer der Vorteile einer Hochsprache ist nämlich, das man sich nicht mit dem Maschinencode einer Plattform auseinandersetzen muß. Falls Du darauf bestehst, schreib' doch mal ein Stück ASM, daß beliebige Datenstrukturen anhand beliebiger Kriterien sortieren kann, und das dann auch noch um mindestens Faktor 5 schneller als der qsort() aus der C-Standardbibliothek. Selbst wenn Du eine solche Funktion entwickeln solltest, ist es mir x-mal lieber, auf jeder beliebigen Plattform mit #include <algorithms> die Standardfunktion einzubinden und sort() zu benutzen. Das kostet mich um Größenordnungen weniger Zeit, ich kenne die Syntax der Funktionen, mein Kollege kennt sie, und hunderttausende Programmierer rund um den Globus haben diese Funktion unter allen möglichen Bedingungen getestet. Dein Code wäre plattformspezifisch und zu 100% nicht fehlerfrei. Zitat: ...die heute zum alltäglichen Brot eines Computers gehören. Bei mir dauert das MP3-Encoden einer CD 20 Minuten. Und bei Dir? Zitat: Nur semantisch leider nicht dasselbe. Zitat: (Mann, überprüf' mal Deine Grammatik, bevor Du postest!) Du hast es immer noch nicht begriffen, richtig? Die brauchen keinen JIT für Amiga schreiben, denn der ist vom OS unabhängig, und ich bin mir ziemlich sicher, daß man von Motorola, IBM oder Apple einen Java-JIT-Compiler für PowerPC auf Lager hat. (68k geht mir aufgrund seines Status als Nostalgieplattform ziemlich am A... vorbei.) Zitat: 68k ist out. Zitat: Nicht mal genug Ahnung, um zu wissen, was Java Bytecode ist, aber über JIT und Java als Sprache lästern. AAAAAAHHHHHHHH! Zitat: Wo findest Du denn solche Antiquitäten? Auf dem Sondermüll von vor drei Jahren? Zitat: Zitat: Bestimmt nicht dadurch, das übermäßig Assembler-Code zum Einsatz käme; eher durch das durch wir-haben-keinen-Speicherschutz begünstigte Messaging / Scheduling, sowie das Fehlen jeglicher höheren Funktionen. Aber was red' ich, Schaf bleibt Schaf... [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 16:36 Uhr Solar Posts: 3680 Nutzer |
Zitat: Ach Menno... wieso mußt Du uns mit sowas profanem wie sachlichen Argumenten stören? ;-) Nein, ich halte es tatsächlich für ausgeschlossen, das man mit Amiga-spezifischen Entwicklungen noch Geld verdienen kann. Vielleicht kann man die eine oder andere Lizenz verkaufen, aber ich glaube einfach nicht, daß sich geleisteter Entwicklungsaufwand noch rentiert. Zitat: Habe ich nie behauptet. Assembler macht durchaus Sinn - bei identifizierten zentralen Flaschenhälsen, oder im Custom-Embedded-Bereich. Wogegen ich argumentiere ist der Tenor, "wozu Java und .NET (und Perl und Ruby und Python und...), MaxxonBasic und ASMPro (und vielleicht noch GCC) sind alles, was wir brauchen". Zitat: Ich hasse POSIX... aber wie kommst Du jetzt darauf? Nichts von dem, was ich geschrieben habe, hat irgendwie mit POSIX zu tun... Zitat: Nein, natürlich nicht, dafür sind sie ja da: Damit sich nicht eine Vielfalt von C-"Standards" breit macht, sondern ein C-Programm mit jedem C-Compiler übersetzt werden kann. Gleiches für andere Sprachen. Beachte bitte, daß ich nicht von Java oder irgendeiner anderen Sprache als allein seligmachend rede. Aber eine Sprache ohne Standard - POSIX, ISO, ANSI, ECMA, proprietär, oder sonstwas - ist so gut wie wertlos. Erst ein Standard in irgendeiner Form gibt mir die Sicherheit, daß meine Arbeit auch mit der nächsten Compilerversion noch läuft, und mein angeeignetes Know-How nicht mit dem nächsten Plattformwechsel zum Teufel geht. Zitat: Das hat mit Sprachstandards nicht das Geringste zu tun. (Und nebenbei engagiere ich mich aktiv gegen SW-Patente.) Zitat: Fragt mal chkamiga, ob er mit seinen heeren ASM-Kenntnissen nicht einen JIT für die Jungs zusammenstrickt... Ich für meinen Teil habe schon genug andere Projekte zu laufen. Schöner, portierbarer C/C++-Code, läuft (dank Standardbibliothek) auf jeder Plattform...  [ Dieser Beitrag wurde von Solar am 13.07.2004 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 17:24 Uhr whose Posts: 2156 Nutzer |
Zitat: Sry  Hm, da gibts ein paar sehr innovative Produkte, die verkauft und weiterentwickelt werden. Ich rede da bspw. von USB. Rentiert im Sinne von "unterm Strich ist was übriggeblieben" hat sichs bestimmt. Das man davon nicht gerade prall leben kann, habe ich ja bereits angedeutet. Im übrigen: Mein Posting ging nicht speziell an Deine Adresse Gibt ja noch ein paar Profis mehr hier.Zitat: Wie gesagt, es ging nicht speziell an Dich. Und was das Thema "ASMPro etc. pp. ist alles was wir brauchen" betrifft, hab ich doch auch etwas entsprechendes gesagt, oder? Zitat: Soweit so gut, da sind wir ja (mehr oder weniger) einer Meinung. Mit Standards meinte ich vorwiegend POSIX und den damit einhergehenden Krampf mit sagenhafter Resourcenverschwendung. Schönstes Beispiel dafür: fork() Ich habe kein Problem damit, daß C-Compiler in irgendeiner Form standardisiert werden (ANSI bspw.). Ist praktisch, wenn unterschiedliche Compiler den gleichen Code schlucken, ohne zu meckern. Dagegen habe ich rein _gar_ nichts. Allerdings sollte an diesem Punkt der Standardisierungswahn dann auch mal ein Ende finden. Es ist doch (simpel gesprochen) so: Einen Standard gibts bereits, der uns allen reichlich Kopfschmerzen bereitet. Windows. Ich frage mich immer wieder, warum Standardisierungsfanatiker (gerade aus dem Linux-Bereich) nicht gleich alle nur noch mit Windows arbeiten. Ist doch ein weltweit anerkannter Standard. Könnte es sein, daß da die Vielfalt eine Rolle spielt bei den Wünschen der Anwender/Entwickler? Zitat:Zitat:Das hat mit Sprachstandards nicht das Geringste zu tun. (Und nebenbei engagiere ich mich aktiv gegen SW-Patente.) Da denkst Du wohl ein wenig zu kurz, würde ich sagen. Patente haben gerade in dem Bereich viel weitreichendere Folgen als man zuerst meint. Was wäre wohl, würde .NET als weltweit gültiges Patent angemeldet (sehr vereinfacht gesprochen), sobald 98% aller Entwickler damit arbeiten? Obs da wohl noch die gewohnte Vielfalt gäbe? Zitat: Ich hoffe, da sind keine POSIX-abhängigkeiten drin? Und das mit chk isn guter Witz Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 17:29 Uhr Maja Posts: 15429 Nutzer |
Zitat: Bill?  Uuuh, nicht böse sein Solar! Ich schätze, du weißt wie ich das meine.  BTW: Hast völlig Recht. Ich warte immer noch auf chkamigs "Hello World" in reinem ASM. Das kann doch nicht so lange dauern, bei so einem Fachmann..... [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 18:32 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ich verstehe, Du hast also ein bissel Assembler-Kenntnisse, nur bei kritischen Anwendungen, also da, wo Geschwindigkeitsoptimierungen tatsächlich Sinn machen würde, da hörts dann auf. Zitat:Aus Sicht eines JIT-Compilers ist ein native Befehl z.B. opcode|zielregister<<offset|sourceregister<<offset oder primary opcode|secondary opcode<<offset|parameter<<offset Das hat mit Assembler nicht die geringste Ähnlichkeit. Zitat:Selten so gelacht. Dann brauche ich also 7 JIT-Versionen, was natürlich wesentlich schlimmer ist, als 7 komplett andere Assembler-Versionen einer Anwendung. Zeige mir auch nur eine in Assembler geschriebene sinnvolle Anwendung, für die alle 7 Versionen verfübar sind. Da Du das nicht kannst, hier eine einfachere Aufgabe: schreibe Dein hello-world Programm in der jeweils für 68000, 68020/30 und 68040/60 optimalen Variante. Wir werden sehen, wieviele Optimierungs-Regeln Du für die jeweiligen Prozessoren kennst. Und wehe, Du vergißt eine! Zitat:Wow, eine ganze Anwendung? Da lohnt sich natürlich der ganze Aufwand einer in Assembler optimierten Bibliothek. Man hätte natürlich auch einfach mal diese Anwendung mit eingeschalteter FPU-Unterstützung übersetzen können, aber egal. Zitat:Weil sein User an Wahrnehmungsstörungen leidet. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ Dieser Beitrag wurde von Holger am 13.07.2004 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 18:42 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das hat auch niemand behauptet. Es ist nur wesentlich einfacher, Software unter Verwendung bestimmter Technologien zu entwickeln. Und ein solcher Vorteil würde auch dem Amiga gut tun. Zitat:Auch das hat niemand behauptet. Zitat:Ich habe mit POSIX nicht das geringste zu schaffen. Sehe auch keinen Zusammenhang zum bisherigen Thema. Zitat:In Grundzügen bereits da und nicht mehr weit sind zwei verschiedene Dinge und zudem noch äußerst dehnbare Begriffe. Abgesehen davon, ist es ja nicht so, daß ich mir das Projekt nicht schon angesehen hätte, leider ist es weder in Assembler, noch in Java, es ist in _C_. Und das ist nicht so meine Welt. Außerdem, wenn man täglich mehrere Stunden programmieren muß, hat man nicht so viel Bedürfnis, in der Freizeit auch noch dasselbe zu tun. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ Dieser Beitrag wurde von Holger am 13.07.2004 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 18:54 Uhr Solar Posts: 3680 Nutzer |
Zitat: In einer Umgebung mit MMU und virtuellem Speicherdesign (und somit der Möglichkeit zum copy-on-write) ist fork() im Gegenteil sogar ressourcenschonend... :;): Zitat: Mein Kollege sitzt im C++-Standardkommittee. Zwar ist der C++-ISO-Standard schon seit sechs Jahren "fertig", trotzdem treffen die Jungs sich zwei Mal im Jahr, um Fehler und Probleme zu adressieren, sowie mögliche Erweiterungen zu erörtern. (Vor allem in Hinblick auf die Standardbibliothek.) Und ganz nebenbei wird im Hinterstübchen am Nachfolger von C++ gebastelt... Soooo schlecht ist das mit den Standards also nicht. Zitat: Nein, ganz im Gegenteil. Windows ist ein herrliches Beispiel für eine nicht standardisierte Umgebung. Hier wird mit voler Absicht immer neues "erfunden", an- und umgebaut - um der Konkurrenz damit zu beschäftigt zu halten, sich an die neueste Überarbeitung der API, der Datenbankschnittstellen, des Dateisystems etc. anzupassen. Zitat:Zitat:Da denkst Du wohl ein wenig zu kurz, würde ich sagen. Patente haben gerade in dem Bereich viel weitreichendere Folgen als man zuerst meint. Was wäre wohl, würde .NET als weltweit gültiges Patent angemeldet (sehr vereinfacht gesprochen), sobald 98% aller Entwickler damit arbeiten? Obs da wohl noch die gewohnte Vielfalt gäbe?Zitat:Das hat mit Sprachstandards nicht das Geringste zu tun. (Und nebenbei engagiere ich mich aktiv gegen SW-Patente.) Da .NET bereits der Öffentlichkeit vorgestellt und durch ECMA standartisiert wurde, kann nachträglich kein Patent mehr darauf angemeldet werden. Ein Patent kannst Du nur auf eine nicht veröffentlichte Technik anmelden - im Moment der Veröffentlichung wird die neue Technik "prior art", mithin nicht mehr patentierbar. Zitat:Zitat:Ich hoffe, da sind keine POSIX-abhängigkeiten drin? Ein #ifdef damit's auch mit der nicht-konformen Bibliothek vom GCC 2.95 funktioniert, und ein #pragma um überflüssige Warnungen unter VisualStudio auszuschalten - der Rest ist bestes ISO-C++. Ich bin bei sowas Purist. ;-) [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 19:14 Uhr chkamiga Posts: [Ex-Mitglied] |
>Kurz vorher hattest Du noch von "Zeilen" gesprochen. Entscheide Dich mal. Ja eine Zeile sind ca. 8 Byte je nach Anweisung. >Das nennt man "Standardbibliothek". Netterweise ist eine >solche sprachspezifisch und steht somit auf jeder >Plattform zur Verfügung, weshalb ich mir keine >Gedanken darüber machen muß, wie der Schmorenz auf >den Bildschirm kommt. Ich weiss was das ist, einerzeit habe ich auch unter C Programmiert, da aber kein Geschwindigkeits oder Anweisungsvorteil gegenüber MBasic gab hab ich relativ schnell wieder aufgehört. >Wie sieht denn Dein ASM-"Hello World" aus? Du wirst doch >nicht etwa irgendwelche Library-Calls machen, und schön >direkt in den Grafikspeicher schreiben, oder? :;): : Library Calls machst du genauso unter C. Nein, ist Grafikkarten Kompatibel. >Wahlweise kann ich auch auf die Standardlib verzichte >und genauso im Speicher herumprokeln, wie Du das unter >ASM machen würdest. Aber dann könnte ich ja auch gleich >ASM schreiben... Mach ich aber nicht so. quote: Compilere es und schick es mir. >Ich könnte Dir sogar einen kompletten Kernel schicken, >der "Hallo Welt!" auf dem Bildschirm ausgibt, bis auf ein >paar Byte ASM in C++ (!) geschrieben und auch nicht >länger als eine ASM-Lösung. (Nimm's einfach als Tatsache; >Du wärst wahrscheinlich eh nicht in der Lage, ihn zu >testen.) Auf Assembler-Parts sowie ASM Optimierungen solltest du verzichten. Das man Maschienencode in C oder Basic einbinden kann weiss ich selber. Das ist aber nicht sinn des vergleichs. >Nein, Du redest von Geschwindigkeit... Ja, von Geschwindigkeit und Größe darum streitest du dich grade. C ist zweifelsfrei besser zu Portieren, was aber auch nicht leicht ist. >Nein, verkehrt. Perl ist eine interpretierte Sprache. >Was Du da siehst, ist die "fertige" Form des Programms. >Natürlich wird das vor der Ausführung noch übersetzt, >aber das wird Java auch. Deswegen würdest Du einer >.class-Datei auch nicht in Abrede stellen, ein >Programm zu sein. Perl? Ich rede immernoch von C aber macht ja nix. >Ein weiterer Punkt, der zeigt, wie weit Du noch davon >entfernt bist, ein "Programmierer" zu sein, oder über >die Tauglichkeit von Java und .NET qualifizierte >Aussagen zu machen. Ich sag nicht das es nichts taugt sondern wenn man es unter C Portiert ist es lahm. Was .NET ist weiss ich nicht. >Komisch dann, daß nicht einmal das OS selbst in ASM, >sondern in C geschrieben ist. Teilweise, kommt drauf an was du nutzt. Aber das OS selbst ist stark Assembler Optimiert. Das heisst es wird in C geschrieben und Nachträglich in ASM Optimiert. Nicht alles aber Zeitkritische sachen. >Komisch dann, daß ich selbst auf meinem 206 MHz >StrongARM-PDA mit gutem Erfolg C++- und Perl-Programme >verwende. Schön ich rede davon das Java lahm auf einem PC mit 400 MHZ läuft und du kommst jetzt mit C und Perl. Geschwindigkeit liegt auch im Auge des Betrachters. Ein 266 MHZ PC ist grottenlahm. >...die heute zum alltäglichen Brot eines Computers >gehören. Bei mir dauert das MP3-Encoden einer CD 20 >Minuten. Und bei Dir? 60 Min dauern etwa 20 Minuten unter 060@60MHZ, also 3,x fache Geschwindigkeit. Was für ein Rechner hast du denn? >Du hast es immer noch nicht begriffen, >richtig? Die brauchen keinen JIT für Amiga >schreiben, denn der ist vom OS unabhängig, und >ich bin mir ziemlich sicher, daß man von Motorola, >IBM oder Apple einen Java-JIT-Compiler für >PowerPC auf Lager hat. (68k geht mir aufgrund >seines Status als Nostalgieplattform ziemlich am >A... vorbei.) Dir vielleicht aber anderen nicht. Dann frag doch Motorola, aber es muss 603e und 604e sein, ansonsten hast du kein Optimalen Code. Weil 603e/4e gegenüber anderen PPC Prozessoren auch geringfügige abweichungen haben. >Wo findest Du denn solche Antiquitäten? Auf dem >Sondermüll von vor drei Jahren? Meine Mutter hat einen 266 MHZ, meine Schwester einen 300 MHZ, ein Kumpel hat einen 400 MHZ. Im Internetcafe Pritzerbe sind 2x 200 MHZ Rechner und einer mit 800 MHZ. Bist ein ganz schöner großkotz wenn du denkst das alle soviel Geld haben sich jedes Jahr ein neuen Computer zu kaufen. Wie auch immer es geht darum das der schnellste Amiga 240 MHZ hat und daher etwa mit einem Pentium mit 400 MHZ gleichzusetzen ist. @Solar ich warte immernoch auf dein Programm [ Dieser Beitrag wurde von chkamiga am 13.07.2004 editiert. ] [ - Ändern - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 19:21 Uhr Gary7 Posts: 571 Nutzer |
Zitat: Yo. Und wir warten auf deinen ASM Quellcode. -- --- Der Weltraum, unendliche Weiten. Dies sind die Abenteuer... [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 19:32 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ach so, Geschwindigkeit liegt auch im Auge des Betrachters, dann brauchen wir bei diesem Betrachter in der Tat nicht weiter zu reden. Zitat:Bevor wir hier weiterreden, mp3 encodieren bedeutet aus einer audio-CD mp3's erzeugen und für ernstzunehmende Resultate reden wir von VBR 32-320kBit, Qualitätsstufe 6 oder besser. Hast Du jetzt immer noch dieses Resultat? Zitat:Wie kommst Du auf diesen Quatsch? Selbstverständlich gibt es auch JIT-Compiler für G3 und G4, was glaubst Du wohl, für welche Prozessoren Apple's Java für MacOSX optimiert? Zitat:Bei 266-300Mhz reden wir ja wohl kaum von "jedes Jahr", sondern eher von sechs Jahren und älter. Und für eine Internet-Cafe, das also für die gebotene Leistung Geld verlangt, sind 200MHz Rechner ein Witz. Wobei, er kann ja kein Geld verdienen, wenn alle aus dem Ort immer zu chkamiga gehen, um an seinem schnellen Amiga zu surfen... mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 19:35 Uhr whose Posts: 2156 Nutzer |
Zitat: Sei mir bitte nicht böse, aber ich merk gerade Daß Du Dich zu sehr auf Java und/oder IDEs bestimmter Machart versteifst. "Bestimmte" Technologien, wie bspw. C++ stehen dem Amiga zur Verfügung. Macht einer was daraus? Eher weniger. Und die wenigen, die etwas daraus machen, werden ausgelacht, weils ja nicht mehr "zeitgemäß" ist, damit zu entwickeln. Noch schlimmer siehts für die aus, die sich erdreisten, in C zu entwickeln. Das Problem des Amiga ist, daß die Entwickler, die ihr Fach eigentlich gelernt haben sollten, nichts aus ihrem Wissen machen, was für den Amiga wirklich verwendbar ist (die wenigen Ausnahmen bestätigen die Regel). Da kommen ein, zwei gute Ansätze, die dann nicht mehr weiter verfolgt werden, weils ja nicht mehr "zeitgemäß" ist und vor allem, weil im "professionellen" Bereich gerade ganz andere Dinge "in" sind. Siehe Envoy. Funktioniert, bietet rudimentäre Dienste, alles wirklich Interessante ist "nicht lohnend" in der Entwicklung, also wirds auch nicht gemacht. Und überhaupt gibts ja viel bessere Software im Linux-Bereich und die ist dazu noch frei und Open Source. Leider ist diese Software dann wieder so gigantisch und so allgemein gefaßt, daß man damit nur in geringem Maße auf die Eigenheiten des Amiga (oder irgendwelcher anderen Systeme) eingehen kann. Geschweige denn daß es genug Leute gibt, die durch diese Source-Giganten überhaupt durchblicken. Zitat: Wenn man sich das Projekt JAmiga anschaut, ist an diesen Begriffen in diesem Zusammenhang gar nichts dehnbar oder so verschieden. Simples Java ist bereits am Laufen, ein (wenn auch grottenlahmer) JIT bereits vorhanden. Also ists in den Grundzügen vorhanden. Und von diesem Stand ist es bis zur vollständigen Implementierung nicht mehr weit. Vorausgesetzt, es wird nicht wieder im Ansatz von gewissen Leuten "totgelabert". Noch eins der vielen Probleme des Amiga. Viele, viele Leute schwafeln drum herum aber machen will kaum einer was. Im Zweifelsfall wird der Beruf vorgeschoben, der einem die Lust an Freizeitarbeit nimmt. Seltsamerweise gilt das nur für den Amiga, weniger für Linux-Projekte. Könnte es sein, daß die meisten von Euch einfach Angst haben, von den Kollegen ausgelacht zu werden, wenn ihr Euch mit "nicht mehr zeitgemäßen" Dingen wie C/C++ und Amiga beschäftigt? Naja, Rückgrat haben ja heute die wenigsten Leute. Zitat: Wovon redest Du jetzt? Mono oder JAmiga? Ich sprach von JAmiga, und _natürlich_ ist das in einer anderen Sprache als Java gefaßt (was den Hauptteil betrifft). Wie sollten die auch sonst Interpreter, JIT und JVM coden? C/C++ oder (sehr eingeschränkt) Assembler ist da die erste Wahl, aber Java? An den eigenen Schnürsenkeln aus dem Sumpf ziehen, oder was? Das ist eben das Dumme an "neuen" Programmiersprachen, daß man erst mal den Compiler und/oder Interpreter in einer ganz anderen Sprache implementieren muß. Oder glaubst Du, BlitzBasic wurde ursprünglich in BlitzBasic gecodet? Zum Thema Programmieren im Beruf und Programmieren in der Freizeit siehe weiter oben. Ums nochmal zu sagen: Leute wie unser CHK sind nicht ernst zu nehmen. Deswegen gehe ich auch kaum auf ihn ein. Aber die Leute, die Ahnung vom Thema haben, sollten sich meiner Meinung nach nicht gar so arg nach dem Mainstream richten, wenn sie Amiga meinen. Sonst hat alles Diskutieren genauso wenig Sinn wie CHKs Beiträge. Dann ist es nämlich schlicht und ergreifend inhaltsloses Gerede über anderer Leute Arbeit, die dem Amiga wenig bis gar nichts nützt. Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 20:17 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ich versteife mich überhaupt nicht auf irgendetwas. Es ist nur so, daß ich persönlich mittels Java eine Software ca. zehnmal schneller entwickeln kann, als in C++. Zitat:Stabiles C++ mit standardkonformen Features gibt es noch nicht sehr lange für den Amiga. Und von einem C++-Compiler hat man noch lange nicht die Bibliotheken, die den Gewinn an Produktivität bringen. Wenn man die erstmal selbst portieren muß, macht das Entwickeln keinen Spaß. Zitat:Interessante These. Hier geht es aber nicht um Dinge, die "in" sind, oder einem unerreichbaren "professionellen" Bereich, sondern darum, das Rad nicht jedesmal neu erfinden zu wollen, und daß auch Hobbyprogrammierer mit einem größeren Nutzen/Aufwand Verhältniss entwickeln können, wenn sie nicht jedes mal gleich beleidigt sind, wenn man sie darauf hinweist. Zitat:Interessantes Beispiel. Was soll ich mit einer Software, mit der ich nur Amiga's miteinander vernetzen kann? Ist es leichter, envoy auf andere Systeme zu portieren, als andere Netzwerktechnologien auf den Amiga? Besseres Beispiel: EvenMore, oder so ähnlich, ein Textanzeiger, der noch weiterentwickelt wird und import-filter für diverse Textformate wie z.B. Word bietet. Leider komplett am Amiga-Datatypes System vorbei programmiert, nur als Standalone-Programm konzipiert. Dabei wären die Vorteile eines modularen Systems für jemanden, der eine Textverarbeitung schreiben und eine Import-Funktion bieten will, offensichtlich. Ist meine Kritik jetzt also ein Totreden? Bin ich jetzt gemein, weil ich den "professionellen" Maßstab einer Aufwand/Nutzen-Analyse einem Hobbyprojekt überstülpe? Oder könnte es vielleicht doch den Amiga voranbringen? Zitat:Ich will jetzt gar nicht über die Details reden, stell Dir einfach vor, die Entwickler selbst wüßten ganz genau, warum sie die aktuelle Versionsnummer auf 0.0.3 gesetzt haben. Zitat:Die Quote ist bei keinem System besser, es gibt einfach nur tausend mal mehr User auf anderen Systemen, womit selbst bei zehnmal schlechterer Quote hundertmal mehr aktive Entwickler übrig bleiben. Zitat:Das ist totaler Schwachsinn, aber typische Amiga-Paranoia. Zitat:Das ist überhaupt nicht natürlich. C-Compiler sind auch oft in C programmiert. Zitat:Java ist nicht neu. Abgesehen davon ist es mir egal, in welcher Sprache jAmiga geschrieben wird, ich habe lediglich erklärt, warum es unwahrscheinlich ist, daß ich mich an jAmiga beteilige. Was keine absolute Aussage ist, denn jAmiga wird noch lange genug brauchen, um auch unwahrscheinliche Dinge vielleicht doch möglich zu machen. mfg PS: Sollte es Dir hin und wieder so vorkommen, daß in diesem Diskussionsforum nur rumgelabert aber nichts gemacht wird, denk mal darüber nach, ob das nicht vielleicht in der Natur der Sache liegen könnte. -- Good coders do not comment. What was hard to write should be hard to read too. [ Dieser Beitrag wurde von Holger am 13.07.2004 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2004, 23:04 Uhr chkamiga Posts: [Ex-Mitglied] |
>Yo. Und wir warten auf deinen ASM Quellcode. Nicht Quellcode, wir reden von einer ausführbaren Datei. Bevor wir hier weiterreden, mp3 encodieren bedeutet aus einer audio-CD mp3's erzeugen und für ernstzunehmende Resultate reden wir von VBR 32-320kBit, Qualitätsstufe 6 oder besser. Hast Du jetzt immer noch dieses Resultat? Achso, nein das dauert 15 Min pro Lied. Na und hast auch keinen Amiga, rede ich mit Nicht Amiga user? NEIN! >Wie kommst Du auf diesen Quatsch? >Selbstverständlich gibt es auch JIT-Compiler für G3 und >G4, was glaubst Du wohl, für welche Prozessoren Apple's >Java für MacOSX optimiert? Schön, dann frag bei Motorolla doch an. >Bei 266-300Mhz reden wir ja wohl kaum von "jedes Jahr", >sondern eher von sechs Jahren und älter. Und für eine >Internet-Cafe, das also für die gebotene Leistung Geld >verlangt, sind 200MHz Rechner ein Witz. Wobei, er kann ja >kein Geld verdienen, wenn alle aus dem Ort immer zu >chkamiga gehen, um an seinem schnellen Amiga zu surfen... Tja, manche haben auch kein Geld sich alle 5 Jahre ein neuen Computer zu kaufen. Manche müssen zusehen das sie genug zu essen haben. Das Internetcafe gehört zu einem Gemeinnützigen Verein und da jeder Internet hat kannst du dir Vorstellen das es nicht so besucht ist das mal schnell davon ein neuer Rechner gekauft werden kann. >"Bestimmte" Technologien, wie bspw. C++ stehen dem Amiga >zur Verfügung. Macht einer was daraus? Eher weniger. >Und die wenigen, die etwas daraus machen, werden >ausgelacht, weils ja nicht mehr "zeitgemäß" ist, >damit zu entwickeln. Noch schlimmer siehts >für die aus, die sich erdreisten, in C zu entwickeln. C ist Okay, nur bitte dann keine Anwendungen die in Zeitlupe laufen, das muss nicht sein. -- http://people.freenet.de/CHRAmiga.de CHRKUM(at)web(punkt)de [ - Ändern - Antworten - Zitieren - Direktlink - ] |
|
14.07.2004, 00:15 Uhr dante Posts: 111 Nutzer |
chkamiga, nu komm doch mal wieder runter! Wenn 68060 dein Maßstab ist, hab ich ein Beispiel für dich: einen Chunky2Planar-Konverter. Der braucht auf 68050@50Mhz für 320x200 in optimierten Assembler 15 ms, in C 20 ms. Hör also bitte endlich auf, vom "grottenlahmen" C zu fabulieren. Je moderner die CPU, desto schwieriger wird es, in ASM überhaupt gleich schnellen Code zu erzeugen wie mit einen halbwegs guten C-Compiler!Zitat: Na, als ich von "sinnvollen" Anwendungen sprach, waren mehrheitsfähige Sachen gemeint. Die von dir erwähnten Beispiele sind für Normalsterbliche irrelevant, P2P lass ich mal als Ausnahme gelten. Und Java und/oder mono portieren, und darauf dann Entwicklungsumgebungen oder einen Texteditor laufen zu lassen, klingt irgendwie nach Inzucht Zitat: Ich bezog mich auf das, was so in Kommentaren und Forenbeiträgen geäussert wurde. Ich selbst war auch verwundert - wenn jemand unbedingt z.B. OpenOffice will, dann soll er/sie um Gotteswillen einen billigen Pc auf dem Flohmarkt ergattern. Wir hatten in der Vergangenheit auf Amiga durchaus gute alltagstaugliche Amiga-Spezifische Software in fast (Browser waren allerdings immer ein Unglück) all diesen Bereichen, auf Portierungen aus dem Windows/Linux-Umfeld wären wir "eigentlich" nicht angewiesen... Zitat: Erde an Holger? Mir ist es Wurst, ob eine IDE langsam ist, weil die darunterliegende Sprache suckt oder die zu dieser Sprache gehörenden GUI-Bibliotheken fürn Eimer sind oder (was ich eigentlich nicht glaube, können ja nicht ALLE Mist machen) die Entwickler Mist gebaut haben. Was bleibt, ist der Eindruck, der dann auf Java an sich zurück schlägt: VisualC - flink. JBuilder - träge. Overnet - flink. Limewire - träge. Jesses, selbst die Beispiele, die dabei sind, wenn man sich das J2RE unter Windows installiert, sind träge! Aber egal, zeig mir einfach ein komplexeres Java-Programm mit dicker GUI, das deiner Meinung nach nicht träge ist, ich gucks mir gerne an. Am besten mit Source, vielleicht lernt man ja was... und wenns nur ausreicht, um Borland mal ne besserwisserische Wutmail zu schicken. Meine persönlichen Programmiererfahrungen mit Java sind alt und gering (ein bißchen Applet - Gefrickel und paar Spielereien), aktuell spiel ich in meiner Freizeit mit J2ME rum (DAS ist erstmal Sch*****, wenn das chkamiga wüsste, ogottogott ), aber auch Java hütet nicht vor Verkrampfungen, um JAVA-Programme portabel zu machen. Wenn z.B. eine bestimmte VM nur max. 32 Images gleichzeitig geladen haben kann und solch Mist...@Holger und Solar: und an euch beide, mit wilden Projektzahlen von Sourcefourge rumzufuchteln ist irgendwie albern, wir wissen doch alle, das Sourceforge - alle sonstigen vorhandenen Vorteile unbenommen!!! - eben auch der grösste öffentliche Friedhof unbeendeter Projekte ist... [ Dieser Beitrag wurde von dante am 14.07.2004 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2004, 00:49 Uhr Maja Posts: 15429 Nutzer |
@ dante > , auf Portierungen aus dem Windows/Linux-Umfeld wären > wir "eigentlich" nicht angewiesen... Du hast zwar schon nicht ohne Grund eigentlich in Anführungszeichen gestellt, aber trotzdem .... *dazwischenfrag* Was wäre denn einfacher bzw. weniger Aufwändig? Zum Beispiel TurboCalc in Sachen Funktionsumfang auf die Höhe von OpenOffice zu bringen oder OpenOffice auf AmigaOS(4) zu portieren? Ich habe null Ahnung von Programmierung, vermute aber mal Letzteres wäre der schnellere Weg zu einem aktuellen Office-Paket zu kommen. Deshalb wurde wohl auch Papyrus in Angriff genommen. Und die möglichst hohe Kompatiblität zum Mainstream ist schon für die Akzeptanz des AOS ausserhalb der "Gemeinde" wichtig. Als so absolute Nische mit Windows oder MacOS in Konkurrenz treten zu wollen, ist ohnehin Makulatur, wenn es an signifikanten Anwendungen von aktuellem Anspruch mangelt. Es bringt doch niemand was, dem hätte-sein-können-wenn nachzutrauern oder Projetke anzufangen, die jetzt einfach zu viel Zeit in Anspruch nehmen würden, nur damits Amiga-only ist. [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2004, 09:31 Uhr gni Posts: 1106 Nutzer |
Zitat:Soweit ich weiss sind Teile des AmigaOS sehr wohl in Assembler geschrieben worden. Man hat sogar von C nach Assembler umgestellt... [ Dieser Beitrag wurde von gni am 14.07.2004 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2004, 09:33 Uhr gni Posts: 1106 Nutzer |
Zitat:Portabler Code hat auch Probleme: implizite Annahmen. Solls wirklich geben. [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2004, 10:05 Uhr Solar Posts: 3680 Nutzer |
Zitat: Es gibt den Vorteil, daß man eine breitere Ausfahl fertigem Code und Bibliotheken nutzen kann. Es gibt den Vorteil, daß man C-Know-How besser brauchen kann als MBasic-Know-How. Es gibt den Vorteil, daß man mehr Leute fragen kann. Es gibt den Vorteil, daß man (entsprechendes Design vorausgesetzt) den C-Code auch auf anderen Plattformen einsetzen kann, damit sich die Investition in die Erstellung auch "lohnt". Aber diese Dinge ignorierst Du ja geflissentlich, denn - Amiga ist eine Insel. Zitat: Aha. Also reden wir nicht von C-Programm gegen ASM-Programm, sondern von einem Lib-Aufruf in C gegen einen in ASM. Wir würden nicht die Sprachen vergleichen, sondern die Link-Systeme. Weshalb ich Dir immer noch kein Binary geschickt habe? Weil Du Äpfel mit Birnen vergleichen willst. Zitat: Genau dort liegt der Schwachsinn Deiner Aussage. Zitat: Und weiter dreht sich die tibetanische Gebetsmühle... war nicht vor Zeiten eines der Argumente der PPC-besser-als-x86 Fraktion, daß man bei einem PPC nicht bei jeder Generation den Code anpassen muß, weil's ein so viel reiferes CPU-Design ist? Zitat: Mein Rechner - ein Athlon 1200 - ist zwei Jahre alt, und war schon damals nicht "High-End". Nebenbei kann ich - von einigen performancekritischen Anwendungen wie eben der MP3-Codierung - keinen Unterschied zu meinem deutlich älteren 500 MHz-Laptop feststellen. Und selbst der codiert MP3's mit Faktor 1,2. Zitat: Zum einen ist "ein Amiga" eine Kombination von Hardware und Betriebssystem. "Ein Pentium" ist erst einmal nur eine Hardware. Ich vermute aber mal, das Du Windows meinst. Nun gibt es keinen "Pentium mit 400 MHz", sondern höchstens einen Pentium II oder Pentium III - der schnellste Pentium hat 233 MHz. Und ein flinker Blick auf die RC5-Stats - die nebenbei keine guten Benchmarks sind und die Motorola-CPUs bevorteilen - führen u.a. Pentium II 400 MHz mit 1130 kkeys/sec., und Amiga 1200 50/240 MHz mit ~980 kkeys/sec. Mit dem Unterschied, daß laut Deiner Aussage die 50/240 immer noch das höchste der Amiga-Gefühle darstellen (andere sehen da die 600-800 MHz eines AmigaOne/Pegasos), aber ein PII 400 MHz heute gar nicht mehr erhältlich (weil veraltet) ist... Komm mal raus aus Deiner Realitätsblase... Zitat: Nochmal, ich werde nicht dabei mitspielen, hier Äpfel und Birnen zu vergleichen. Das kleinste lauffähige ELF-Executable ist 45 Bytes groß. Das ist ein Achtel dessen, was auch der beste Assembler hinbekommen würde, und ein Fünfzehntel des kleinstmöglichen C-Programms. Aber all das spielt keine Rolle, denn es geht nicht um das kleinste Executable, und auch nicht (immer) um das schnellste Executable. In den allermeisten Fällen sind diese beiden Punkte die unwichtigsten überhaupt. Das Du das nicht akzeptierst, zeigt nur, daß für Dich der Computer immer ein Spielzeug bleiben wird. Also halte Dich aus Diskussionen zu Java oder .NET heraus, denn da geht es nicht um Spielzeug, sondern um Software. Zitat: Ich meine nicht Klicki-Bunti-IDEs. Ich bin nicht einmal ein großer Freund von Java. Was ich meine, ist z.B. die Verwendung der Komponenten von Drittanbietern ohne Rücksicht auf die verwendete Programmiersprache. Fertige Bibliotheken zur XML-Unterstützung, und SOAP-Schnittstellen. Einen TCP/IP-Socket öffnen mit nur fünf Zeilen Code... Zitat: Seit wann stehen sie zur Verfügung? Was heißt "zur Verfügung"? Einen C-Compiler kann man sich aus dem Aminet ziehen. Einen C++-Compiler gibt's für teuer Geld bei Haage zu kaufen, oder man muß sich durch die Installation eines GCC quälen, oder wissen daß GoldEd eine GCC-Installation mitbringt, wenn ich das richtig mitbekommen habe.) Während alte Magazine und neue Webseiten voll mit Amiga-C-Tutorials sind, kann man Amiga-C++-Tutorials mit der Lupe suchen. Und dann gibt's die, die selbst C für zu lahm und ASM bzw. MaxxonBasic für die einzig wahre Sprache halten. Zitat: Eben diese Entwickler sind schon lange gegangen, setzen das Gelernte auf anderen Plattformen um, wo die Stimmung besser und der Erfolg - ob nun in Verkaufszahlen, E-Mails oder Anerkennung gemessen - größer ist. Was übrig geblieben ist, sind zu wenige, und selbst die haben das ewige Gemecker langsam satt. Zitat: Eben. Amiga hat die "kritische Masse", oberhalb derer sich (Anwender-)Nachfrage und (Entwickler-)Angebot gegenseitig beleben, schon seit etwa zehn Jahren unterschritten. Spezielle Amiga-Entwicklungen lohnen sich nicht mehr. Frag nur mal Hyperion zu deren Portierungen - würden sich diese nicht auch an Mac und LinuxPPC-User verkaufen lassen... Sich abzuschotten und auf mirakulöse Weise erscheinende Amiga-Software zu warten ist Unsinn. Willst Du auf dem Amiga fortgeschrittene, neue Software haben, dann sieh' dich bei den portablen Sachen um - POSIX / ixemul, Java, vielleicht sogar .NET. Das, und ein paar Hobbyentwicklungen von verbliebenen "Fans", mehr wird es nicht mehr geben. Die Zeiten von Digita, Westwood, Maxxon usw. sind vorbei. Zitat: Wenn Du die Wahl hättest, eine Software zu schreiben, die von tausenden Usern benutzt wird und für die Du jede Menge positives Feedback und konstruktive Kritik bekommst - oder eine für ein paar Dutzend User, von denen höchstens ein "funktioniert nicht, Sch***-Software" kommt - was würdest Du tun? Zitat: Ich habe keinen Bock, mich mit einer zehn Jahre alten API zu beschäftigen, die sich gerade im Umbruch befindet und bestenfalls zehntausend User repräsentiert. Darum werden meine Projekte höchstens auch auf dem Amiga funktionieren. Diese Rücksicht nehme ich, wo es mir möglich ist. Wenn ich mehr User erreichen könnte - z.B. wie es ursprünglich mit dem AmigaDE geplant war, oder durch die Möglichkeit, AmigaOS4 auf dem x86 benutzen zu können - dann sähe die Sache anders aus. Zitat: Du kennst mich nicht, sonst hättest Du die Andeutung nicht gemacht. :8): Das hat nichts mit Rückgrat zu tun. Nur ist man irgendwann aus dem "Sandkasten" Kinderzimmer / Studentenbutze heraus; so gut wie alle Hobby-Projekte werden gestartet, weil der Entwickler die Software selber braucht; alle anderen Projekte, weil man in irgendeiner Form "Erfolg" haben möchte. Irgendwann gehen dabei die Illusionen flöten. Zitat: Das Problem, das Amiga hat, ist folgendes: Als "krankende" Plattform, die sie nun einmal ist, kann man es sich einfach nicht leisten, sich zu weit vom Mainstream zu entfernen. Nur dort sind die User, die Entwickler, all die Menschen, die man braucht, um sich wieder zu erholen. Weit abseits des Mainstream überlebt man nur, wenn man gut ist, auf die eine oder andere Weise. Weil man die schnellsten Rechner überhaupt hat, oder weil man das sicherste OS überhaupt hat. Selbst der Mac ist viel näher am Mainstream als jeder AmigaOne oder Pegasos. Es ist kalt da draußen, und wenn wir hier eine Annäherung an den Mainstream predigen, dann, weil wir ansonsten hilflos zusehen, wie Amiga immer weiter dorthin abdriftet, wo es nur ein kaltes, einsames Ende geben kann. Zitat: Macht "Amiga" die 15 Minuten in irgendeiner Form besser? Nein... Und nebenbei, mein Amiga (OS 3.5) ist nur einen Doppelklick (auf "WinUAE") weit entfernt, und wenn ich eine Webseite nicht anzeigen oder ein Tool nicht nutzen kann, bin ich mit Alt-Tab auch fluggs wieder in der "Comfort Zone"... Zitat: Öhm... Moment, zurückspulen bitte. E-Mail, IRC, DVD-Authoring-GUIs, Spiele, all das hältst Du für irrelevant? Sag mal, was machst Du mit Deinem Rechner den ganzen Tag? Zitat: hatten war richtig, und aus dem wären machst Du besser ein waren. Es gab eine Zeit, da gab es auch Amiga-spezifische C++-Compiler inklusive IDE. Auch dort ist man inzwischen beim GCC-Port, weil die Manpower zur Pflege von Eigenentwicklungen einfach nicht mehr da ist. Also kann man weiter versuchen, Dinge einzeln zu portieren, oder noch schlimmer, nachzuprogrammieren... oder eine "Meta-Lösung" wie Java nehmen: Eine Runtime portiert, tausende Anwendungen gewonnen, Zeit frei für Eigenentwicklungen, wo die Java-Anwendungen nicht taugen... Zitat: Richtig. Aber wenn 80% der Projekte aus SourceForge Karteileichen sind, stimmt es immer noch, daß es genausoviele Java- wie C-Projekte gibt. Und die Beispielanwendungen, die ich gestern genannt habe, stammen alle aus den Top 100 der aktivsten Projekte... Zitat: Letzteres, zumal man Weiterentwicklungen für den "Preis" der Portpflege bekommen würde. [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2004, 10:05 Uhr whose Posts: 2156 Nutzer |
Zitat: Wie die jüngere Geschichte gezeigt hat, wäre eine Amiga-only-Neuentwicklung wohl doch schneller zu bekommen. Seid mir nicht böse, daß ich schon wieder eine festgefahrene Meinung "angreife", aber mal die Fakten betrachte: Papyrus schreitet _enorm_ langsam voran. Obs an fehlender Manpower (wegen niedrigster Priorität) liegt oder an sonstwas, kann ich nicht sagen. Einfach umzusetzen dürfte es wohl trotz allem nicht sein. OpenOffice ist der wohl absolut dickste Brocken, den man überhaupt angehen kann. Mit der Portierung von OO allein ist es ja nicht getan. Das GUI-Toolkit (ists GTk? Oder GIMP? Keinen Schimmer) muß in diesem Fall ja auch erstmal portiert werden, was für sich schon eine Riesenaufgabe darstellt. Nehmen wir mal nur das GT für sich: Wer soll das machen? Wie lange wird das dauern? Und dann gibts ja noch ein paar Kleinigkeiten, die für OO nötig sind und portiert werden müssen. Dann ist erst OO an der Reihe. Wer soll das machen? Wie lange soll das dauern? Schauen wir uns Mozilla an: Da sollen wohl ein paar Teams dran arbeiten. Ist jetzt auch gut ein halbes Jahr her, daß diese Arbeiten begonnen haben sollen. Stand bisher unbekannt. Wie lange soll das wohl noch dauert, bis da erste Ergebnisse kommen? Ein Jahr? Zwei? Gar nicht? Wenn ich mir dann anschaue, daß da ein Hobbyprogrammierer innerhalb von zwei Wochen nen Minimalbrowser (Fastpath) zaubert, kann ich nur zu dem Schluß kommen, daß ein Team fähiger Amiga-Entwickler in kürzerer Zeit mehr zustande bringt, was brauchbar ist, als ein noch größeres Team nicht ganz so fähiger Portierer. Nur müßte man sich da mal einig werden und vor allem sollte der Wille dazu da sein resp. entwickelt werden, etwas in der Richtung zu unternehmen. Daran haperts aber scheinbar. Meine 2 Cent... Grüße [ Dieser Beitrag wurde von whose am 14.07.2004 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2004, 10:12 Uhr chkamiga Posts: [Ex-Mitglied] |
>chkamiga, nu komm doch mal wieder runter! Wenn 68060 >dein Maßstab ist, hab ich ein Beispiel für dich: >einen Chunky2Planar-Konverter. Der braucht auf >68050@50Mhz für 320x200 in optimierten Assembler 15 ms, >in C 20 ms. Hör also bitte endlich auf, vom >"grottenlahmen" C zu fabulieren. Ähm ein schlechtes ASM mit einem guten C Programm zu vergleichen sagt nichts aus. >Je moderner die >CPU, desto schwieriger wird es, in ASM überhaupt >gleich schnellen Code zu erzeugen wie mit einen >halbwegs guten C-Compiler! Ich sag nicht das es einfach ist. >Was wäre denn einfacher bzw. weniger Aufwändig? >Zum Beispiel TurboCalc in Sachen Funktionsumfang >auf die Höhe von OpenOffice zu bringen oder >OpenOffice auf AmigaOS(4) zu portieren? TC auf OpenOffice, was auch immer das ist. Mir fehlt nix an Turbocalc aber naja. >Portabler Code hat auch Probleme: implizite Annahmen. >Solls wirklich geben. Eine Menge Probleme wenns über "Hello World" hinaus geht. Warum sonst würde Mozilla so lange dauern. Wenn man z.B. unter Windows eine Library aufmacht und Funktionen dieser benutzt ists schon nix mit einfachen Portieren. Oder umgekehrt eine Lib auf dem Amiga auf. Du musst gucken was für Funktionen die Library hat und ob das andere System ggf. ein Equvalent hat. Allerdings ist schon die ansprechweise eines Befehls aus der Lib meist ganz anders. Bei OpenOffice siehts auch so aus, weiss jetzt nicht wieviel Librarys von Windows benutzt werden, aber mehr als eine... -- http://people.freenet.de/CHRAmiga.de CHRKUM(at)web(punkt)de [ - Ändern - Antworten - Zitieren - Direktlink - ] |
|
14.07.2004, 10:17 Uhr whose Posts: 2156 Nutzer |
@Solar: Du weißt nicht, was in meiner Facharbeiterbude (aus dem Kinderzimmer bin ich schon bißchen länger raus) entsteht :8): Mir ist es dabei scheißegal, ob gewisse notorische Nörgler dann später sagen "So ein Mist, das taugt nix, das funktioniert nicht, das unterstützt meine Lieblings-GFX-Soft nicht ordentlich" etc. pp. Die Nörgler interessieren mich nicht die Bohne. So lange es _einen_ User gibt, der meine Software benutzt, sehe ich noch Sinn darin, weiterzumachen. Keinen Sinn sehe ich erst, wenn es _keinen_ User mehr gibt, der irgendwelche Soft von mir benutzt. Bis dahin ists aber noch lang... Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2004, 11:25 Uhr gni Posts: 1106 Nutzer |
Zitat:Was soll das sein? [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2004, 11:31 Uhr gni Posts: 1106 Nutzer |
Zitat:Also C++ Compiler sind schon lange auf dem Amiga verfügbar. Was genau ist "stabiles C++ mit standardkonformen Features"? Zitat:Wenn Bibliotheken Plattformabhägikeiten haben, ist das richtig. Meinst Du irgendwelche speziellen Bibliotheken? [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2004, 11:37 Uhr gni Posts: 1106 Nutzer |
Zitat:Wenn nicht mittels Assembler, wie ist das Programm dann enstanden? Dieses erwähnte ELF-Programm basiert ausgiebig auf dem Verhalten des Linux-Loaders. Ein Spec-konformes ELF Program ist größer. Allerdings worum gehts dabei eigentlich? ;-) [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2004, 12:21 Uhr Solar Posts: 3680 Nutzer |
Zitat: Ist noch etwas diffus, aber schon deutlich über ein "machen wir einen C++-Nachfolger!" hinaus. Das Objektmodell von C++ is so eigentlich ganz in Ordnung, aber zum einen ist die Syntax ziemlich FUBAR (two-face name lookup, argument-dependent lookup), zum anderen will man andere Konzepte stärken (statische Polymorphie z.B.). Frag' mich jetzt bitte nicht im einzelnen aus; ich bin kein Sprachtheoretiker, und gebe nur weiter, was Kollege Dietmar hier in den Raum wirft. Zitat: Das Problem am Amiga-GCC ist, daß er für viele Amiganer zu "Unixoid" war und evtl. immer noch ist. Ich erinnere mich, daß ich schon deutliche Schwierigkeiten hatte, den GCC von der damaligen GeekGadgets vernünftig installiert zu bekommen. Als Amiga-User ist man anderes "gewöhnt". SAS/C habe ich nie in den Fingern gehabt, aber MaxxonC++ und StormC "fühlten" sich deutlich besser an als eine "nackte" GCC-Installation... mit dem Unterschied, daß der enthaltene Compiler nun eben nur einen Teil der Sprache beherrschte. Zitat: Naja, vielleicht nicht ganz richtig ausgedrückt. Natürlich wird das Executable in einem Assembler zusammengebaut; allerdings erzeugt man keine Objektdatei, die anschließend durch einen Linker geht, sondern "hackt" das Executable direkt zusammen. Zitat: Ich wollte chkamiga verdeutlichen, daß ein "schick' mir Dein Executable, und ich zeige dann, daß es kleiner geht" Unsinn ist. Natürlich wird in ein C-Compilat per default mehr hineingelinkt als in ein Assembly. Startup, stdout, stdin, exit - und nicht immer braucht man diese Funktionalität auch, schon gar nicht bei primitiven Programmen wie "Hallo Welt". Das macht Assembly aber nicht "besser". Und wenn ich in der C-Runtime herumstochern und meine eigene C-Lib verwenden dürfte, könnte ich auch ein besonders winziges C-Programm erstellen. Auch das macht C nicht "besser". [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2004, 13:00 Uhr whose Posts: 2156 Nutzer |
Zitat: StormC4 noch nicht angesehen, wie? Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2004, 16:35 Uhr Maja Posts: 15429 Nutzer |
Zitat: Womit du jetzt genau was meinst? Zitat: Wenn das tatsächlich bezogen auf Apps für AOS4 niedrigste Priorität hat, dann läuft da etwas völlig verkehrt. Zitat: Die Frage war nicht, was einfach ist, sondern was von zwei Möglichkeiten einfacher ist. [ - Antworten - Zitieren - Direktlink - ] |
| 1 -2- 3 4 5 6 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Mono für Amiga | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|