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

amiga-news.de Forum > Amiga, AmigaOS 4 > PPC Emulator für OS4 [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 2 3 -4- 5 [ - Beitrag schreiben - ]

16.12.2008, 00:04 Uhr

Gerry
Posts: 82
Nutzer
Ach ja, noch etwas:

- Microsoft an sich macht keinen echten Standard. Beispiel: Wer das WORD-Format gut kennt (ich meine jetzt nicht, wer gut in WORD ist, sondern wer den Aufbau einer WORD-Datei kennt), der weiss, dass das kein Standard sein kann, da es schwer kompatibel ist. Kompatible Formate (PDF, RTF ...) sind Standards und für Konvertierungen und Plattformunabhängikeit konzipiert. Nur weil viele Schreibprogramme WORD als Import besitzen (Jedoch unvollständig, da bei diesem "Standard" das Format NICHT FREI ist, sondern entziffert wurde), ist es langenoch kein Standard im eigentlichen Sinne. Es ist ein "Quasi-Standard".

- Das BE-LE-Problem existiert bei Konvertierungen tatsächlich. Es ist kein "Blech". Wer selbst programmiert, und schon Programme portiert hat, kennt das. Und als "Gegenargument" will ich jetzt nicht hören "Aber ein printf() unter AmigaOS ist doch auch unter Windows nur ein printf()". Man schaue sich an, wie printf programmiert wurde, vielleicht noch ein paar Header-Dateien,und erkennt, dass man u.U. auch diverse #ifdef BIG_ENDIAN oder etwas in der Art stosst.

- Wieso möchte Linux seit neuestem eher die Strategie von AmigaOS verfolgen? Vermutlich wollen die sich an AmigaOS annähern, weil PCs mit Windows besser sind. Ist doch logisch....oder???

- "Amiga ist tot". Das hat man schon vor 10 Jahren gesagt. Wie oft wird er denn noch sterben sollen? Angenommen, alle Leute sagen von heut auf morgen "Windows ist tot". Dann würde auch keiner mehr für Windows programmieren, und dann gäbe es auch nurnoch kleine Nischen die etwas Programmieren. Und mal Hand ans Herz: Wie gut sind denn die Microsoft-Programmierer wirklich? In Sicherheitslücken, Rechtschreibfehler und Bugs sind sie jedenfalls sehr gut.

- Und jetzt zu einem weiteren falschen Argument: Zuerst die Berechtigte Aussage "Verknüpfe mal unter Windows eine .exe-Datei mit einem anderen Programm". Als "Gegenargument" kam :"Ändere mal ein Programm-Icon in ein Projekt-Icon". Dazu folgende Bemerkungen:
* Das Verknüpfen von .exe oder .lnk hat eine komplette Neuinstallation von Windows zur Folge! Denn das System an sich ist
nicht mehr startbar, und somit kann der Fehler mit normalen Mitteln
nicht unbedingt mehr repariert werden. (Z.B. mit dem 7000-Euro-Programm ERD-Commander könnte es noch gehen)
* Das Ändern eines einzelnen Icons unter AmigaOS juckt das System nicht. Ein Programm ist ebensogut ohne Icon startbar. Das System erkennt ohnehin selbst, welcher Dateityp vorliegt, auch ohne Icons. Ausserdem ist es nicht so einfach möglich, den Typ zu verändern, nur mit Gewalt. Auf Windowssystemen ist allerdings die Verknüpfung schnell erledigt, u.U. auch versehentlich.
Vielleicht kann es ja auf dem Amiga sein, dass solange das "falsche" Icon (also mit falschem Typ) existiert, das Programm dann nicht ausgeführt wird. *Gähn* einfach Icon zurückstellen oder löschen. TOOOLLLES Argument.

Viele Grüße :)

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 00:13 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Thore:
Java ist doch nicht für PC entwickelt worden. Das ist als virtueller Prozessor entwickelt worden auf einer Sun Workstation. Dabei gibts die JavaVM, ein Prozessor-Emulator für den virtuellen Java-Prozessor.
Java ist demnach auch keine native Programmiersprache.
Eine JavaVM auf AmigaOS wurde schon mehrfach angegangen aber aufgrund der geringen Resonanz immer wieder eingestellt.

Völlig unverständlich eigentlich nach Deiner eigenen Logik, nicht wahr?
Schließlich ist Java Big-Endian und läuft problemlos auf einem x86 Little-Endian PC, während es auf dem Big-Endian Amiga nach zehn Jahren immer noch nicht möglich ist...
Zitat:
Original von amigagti:
Wie ich bereits sagte, du hast davon keine Ahnung. Daher kann ich mit dir nicht weiter übersowas diskutieren. Scheinbar ist dir daher auch der Unterschied zwischen einem IndustriePC und einem VerbraucherPC nicht bekannt.

Hmm, Industrie-PC ist ein Rechner, der ausschließlich Amiga-Usern angeboten wird, weil er nirgendwo sonst konkurrenzfähig wäre?

Warum sollte ein Amiga-User das grottige Preis/Leistungsverhältnis eines SAM akzeptieren, nur weil der Hersteller behauptet, es wäre ein Industrie-PC? Selbst wenn das stimmen würde--sind Amiga-User neuerdings Industrie?
Zitat:
Original von Thore:
Außerdem: Wenn eine Amiga-Routine die Hälfte an Mnemonics braucht wie ein PC-Programm, darf die MIPS Zahl ruhig niedriger sein (68060 ca 100 MIPS)

Ja, da spricht der Assembler-Fachmann. Je kürzer der Quellcode, desto schneller das Programm.
Und wenn ein Programm aus halb so vielen Instruktionen besteht, darf die CPU schon mal um Faktor 100 langsamer sein, das gleicht sich aus. Wenn die Software dann auch nur halb so viel Features wie das PC-Äquivalent hat, können wir alle glücklich sein. Leider hat sie gar keine, weil der Assembler-Meister immer noch nicht mit seiner Software fertig ist...
Zitat:
Original von Thore:
AROS ist doch auch in der x86 Version x86 only und Programme müssen explizit drauf geschrieben werden.

Sowohl Aros, als auch die Software dafür, muss lediglich mit einer anderen Compiler-Option übersetzt werden, um eine x86, ppc oder 68k Version zu erstellen.
Endianess ist in sauber geschriebener Software überhaupt kein Thema.

Und Assembler-Programme können so oder so nicht von einem dieser Prozessoren auf den anderen übertragen werden, womit auch da Endianess absolut nebensächlich ist.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 00:37 Uhr

Andreas_Wolf
Posts: 2980
Nutzer
> Das Sam Board selber wurde ca. 2003 entwickelt

"The development started in February 2006..."
http://amikit.amiga.sk/samantha.htm

...und ging bis 2007:

http://www.amiga-news.de/de/news/AN-2007-04-00001-DE.html
http://www.amiga-news.de/de/news/AN-2007-09-00077-DE.html
http://www.amiga-news.de/de/news/AN-2007-10-00016-DE.html

> Amiga OS4.1 wurde 2007 entwickelt

Nein, 2007 bis 2008:

http://www.amiga-news.de/de/news/AN-2008-08-00016-DE.html

> als Update für die Amiga One von 2001.

2001? Der AmigaOne-SE erschien 2002 (bis 2004), der AmigaOne-XE 2003 (bis 2004) und der Micro-A1 2004 (bis 2005). Also wurde das 2008 erschienene OS4.1 entwickelt als Update für die AmigaOnes von 2002 bis 2004 und für die A1s von 2004 bis 2005.

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 02:12 Uhr

Andreas_Wolf
Posts: 2980
Nutzer
> Der Apple basiert nur auf Intel, weil der PowerPC-Chip weniger
> angegebene GHz hatte.

Ich halte die These, dass IBM keinen für Notebooks geeigneten G5 liefern wollten oder konnten, für glaubhafter.

> Der Motorola-Chip (68xxx) [...] war zu den Anfängen (8008 etc) nur
> um 1$ teurer als die 80er-Prozessoren

Dass der 68000 teurer war als der 8086 (nicht "8008 etc", der 7 Jahre vor dem 68000 erschien), ist allgemein bekannt. Dass der Preisunterschied aber nur 1 USD betrug, hätte ich gern belegt.

> und wurde deshalb nicht für den PC verwendet.

...und weil es für den 68000 zu diesem Zeitpunkt noch kein CP/M gab, für den 8086 aber schon.

> ist es Intel nicht gelungen, den superprozessor mit weit mehr als
> 3 GHz zu bauen

Der Pentium 4 wurde bis auf 3,8 GHz getaktet, der Core 2 Duo bis auf 3,33 GHz und der Core i7 bisher bis auf 3,2 GHz.

> und musste die Geschwindigkeit sogar drosseln.

Ich glaube eher, die Geschwindigkeit wurde weiter erhöht. Was gedrosselt wurde (gegenüber dem P4), ist die Taktfrequenz.

> Darüber hinaus sollte sogar eine komplette Prozessorreihe
> (Entscheidung war zwischen Itanium und Pentium) eingestampft werden,
> wegen argen Problemen.

Weder die Pentium- noch die Itanium-Reihe wurde eingestampft.

> Übrigens versucht M$ mit C# eine Java-Antwort an SUN zu geben, jedoch
> sieht man hier, dass M$ hier auch immer nachhängt. Der Grund ist eben
> der, dass Java eben auf SUN entwickelt wurde und deshalb dort auch
> immer aktuell ist.

Weil Java "auf SUN" (Solaris? SPARC?) entwickelt wurde und deshalb "dort" (Solaris? SPARC?) immer aktuell ist, hängen Microsoft mit C# SUN mit Java nach? Das verstehe ich nicht. Klingt nach wirrem Gebrabbel.

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 08:47 Uhr

Thore
Posts: 2266
Nutzer
@Holger:
Zitat:
Völlig unverständlich eigentlich nach Deiner eigenen Logik, nicht wahr?
Schließlich ist Java Big-Endian und läuft problemlos auf einem x86 Little-Endian PC, während es auf dem Big-Endian Amiga nach zehn Jahren immer noch nicht möglich ist...

Du hast es anscheinend nicht verstanden oder willst es nicht verstehen. Java ist ein PROZESSOR-EMULATOR, mit EIGENEM BYTECODE der von einer VM interpretiert wird, das hat nichts mit x86 oder 680x0 zu tun.
Und auch hier muss die x86 VM Byteswap machen um seinem LE gerecht zu werden. Und es GIBT JavaVM auf dem Amiga, nur eben nicht vollständig.
http://www.jamiga.org/

Zitat:
Ja, da spricht der Assembler-Fachmann. Je kürzer der Quellcode, desto schneller das Programm.
Und wenn ein Programm aus halb so vielen Instruktionen besteht, darf die CPU schon mal um Faktor 100 langsamer sein, das gleicht sich aus. Wenn die Software dann auch nur halb so viel Features wie das PC-Äquivalent hat, können wir alle glücklich sein. Leider hat sie gar keine, weil der Assembler-Meister immer noch nicht mit seiner Software fertig ist...

Nein ein kürzerer Programmcode heißt noch lange nicht daß das Programm schneller ist, oft ist sogar das Gegenteil der Fall!
Es ging hier um MIPS, und daß 680x0 Code mit weniger Zeilen Code auskommt, um das gleiche zu berechnen. Ich hab nie gesagt daß es die Geschwindigkeit ausgleicht, sondern nur weniger haben darf. MIPS kann man sowieso nicht zwischen zwei Architekturen vergleichen, mir gings hier um die Anzahl der Befehle und wieviele ein Code braucht, und in welcher Zeit das bearbeitet werden kann, also um Effizienz, nicht um Geschwindigkeit.
Zitat:
Sowohl Aros, als auch die Software dafür, muss lediglich mit einer anderen Compiler-Option übersetzt werden, um eine x86, ppc oder 68k Version zu erstellen.
Endianess ist in sauber geschriebener Software überhaupt kein Thema.

Und Assembler-Programme können so oder so nicht von einem dieser Prozessoren auf den anderen übertragen werden, womit auch da Endianess absolut nebensächlich ist.

"Lediglich mit einer anderen Compiler-Option", und wenns um Bit-Operationen geht muss man aufpassen ob es denn überhaupt noch stimmt, was denkst du denn, warum es bei portablen Sourcecodes die Verzeichnisse für die verschiedenen Prozessorarchitekturen gibt. Einfach mal fürs Portieren compilieren ist eben nicht drin.
Endianess ist genau dann nicht nebensächlich, wenn man Assemblercode für eine andere Maschine übersetzen will.

Wer eben ein paar Shell-C Programme portieren will hat zu 99% keine Probleme, aber ich denk Du hast noch nie an großen Projekten programmiert.
Daß es Probleme gibt beweist unter anderem dieses Forum (es gibt tausende weitere stellen):
http://www.meinews.net/bin-t279504.html
Die Compiler-Option baut lediglich den Byteswap ein, bei Hochsprachen wird das meist dann richtig gemacht (Bei binär-Operationen muss man hingegen noch drauf achten).

Sogar Apples Wechsel zu Intel brachte Probleme wegen dem endianess, genau das wäre auch das Problem bei OS4 für x86.
http://en.wikipedia.org/wiki/Apple_Intel_transition



[ Dieser Beitrag wurde von Thore am 16.12.2008 um 09:11 Uhr geändert. ]

[ Dieser Beitrag wurde von Thore am 16.12.2008 um 09:11 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 09:47 Uhr

Gerry
Posts: 82
Nutzer
@Andreas_Wolf
Ja, richig, die Taktfrequenz. Sorry. Die Geschwindigkeit ist natürlich gestiegen.
Und ja, der Motorola war nur geringfügig teurer, etwa 1 $. Aber bei
Massenverwendung fiele dies ins Gewicht. Die Genaue Quelle ist mir nicht bekannt, jedoch ist die Aussage von Leuten, die das sehr genau wissen. Im Prinzip ist hier aber, wie Du auch sagst, das entscheidende, dass er billiger war.

mit "weitaus mehr als 3 GHz" meinte ich u.a. den versprochenen 10 GHz.

@Holger
Die Argumente von Dir haben keine Grundlage.
Natürlich brauchte ich für das Studium fachkundige Dr. Dipl-Ings etc. Denn wer studiert ohne Professoren...Mal darüber nachdenken!!
Viele von denen sind DIREKT in der Entwicklung, oder meinst du, die Entwickler haben keine Ahnung wie das geht? Dann gebe ich denen mal deine E-Mail, damit Du denen das beibringen kannst!!

Dann: Das Marketing von Apple wurde öffentlich bekannt gegeben, so viel zum dem Thema. Mal sich erkundigen wäre hier angebracht.

Und der Motorola ist von der Architektur überlegen. Schonmal ne CPU von innen gesehen (Nein, ich meine jetzt nicht mit dem Mikroskop)

Mir kommen die Argumente von Dir eher so vor, als würdest Du es nicht wahrhaben wollen. Wenn ich sagen würde "in Raum der Natürlichen Zahlen ist 1+1=2", dann würdest Du sagen "Was hast du nur studiert um so ein Schwachsinn zu erzählen".

Es liegt nur daran, dass Du auf Deiner Meinung beharrst.
Und keine tiefgehende Ahnung hast. Die Pipes sind tatsächlich mit eingerechnet. Fertig aus Schluss.

Es wird viel nach außen vom Marketing getragen, was technisch gesehen etwas anders ist. So einfach ist das.

Und das mit dem MediaMarkt hast Du nicht verstanden. Vielleicht war das aber auch zu kompliziert...

Dann noch etwas entwirrendes: Java wird ja heute noch weiterentwickelt. Da C# erst reagieren kann, wenn die Entwicklung released ist, hängt es nach. Das ist kausal und nicht verwirrend.

Und hab ich erwähnt, dass eine der CPU-Reihen eingestampft wurde? Mit keinem Wort!! Ich habe geschrieben (es darf nachgelesen werden), dass man sich mit dem Gedanken befasste. Ob noch etwas in der Art passiert, weiss ich nicht. Vielleicht kann ich da noch was in Erfahrung bringen.


[ Dieser Beitrag wurde von Gerry am 16.12.2008 um 09:50 Uhr geändert. ]

[ Dieser Beitrag wurde von Gerry am 16.12.2008 um 09:53 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 10:30 Uhr

Gerry
Posts: 82
Nutzer
*** Wegen Verstoß gegen die Netiquette gelöscht (cg)
http://www.amiga-news.de/netiquette.shtml ***

Ach ja, der eigentliche Sinn des Themas:

- Ich sage: Ja, es ist bestimmt möglich, OS4 zu emulieren, da im Prinzip jedes System emulierbar ist, mal besser, mal schlechter.

- Nein, ich glaube nicht, dass bisher ein Emulator existiert oder in Entwicklung ist. Jedenfalls ist mir keiner bekannt.

[ Dieser Beitrag wurde von cgutjahr am 16.12.2008 um 15:36 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 10:58 Uhr

Thore
Posts: 2266
Nutzer
Es ist kein OS4 Emu für x86 geplant, die einzige OS4Emu ist eine Sammlung von Libs und Patch für MorphOS, wobei auch nicht jedes Programm läuft.
Ein Emu ist natürlich prinzipiell möglich (QEmu emuliert ja auch PPC auf x86). OS4 könnte wenn dann nur auf einem modifizierten QEmu laufen (wie auch MorphOS)
OS4 für x86 zu portieren ist ebenfalls nicht geplant und wird auch nicht stattfinden. Hyperion leht AmigaOS auf x86 auch entschieden ab:
http://www.amigahistory.co.uk/emulators/hyperionblast.html

Anmerkung zur Beendigung der sich im Kreis drehenden Diskussion:
Ich werd nicht mehr auf BE/LE-Probleme und sonstige Prozessorarchitekturische Dinge eingehen, sondern in diesem Thread nur noch das Thema OS4-Emulation weiterverfolgen.
Wer mehr Infos zu Prozessoren will kann sich selber schlau machen, und mit der Zeit feststellen, daß es eben Fakten sind.
Übrigens ist der Prozessor den ich und ein Kollege in der Uni in einem Hardware-Praktikum entworfen haben für jeden downloadbar im Internet, bei Interesse bitte melden.


[ Dieser Beitrag wurde von Thore am 16.12.2008 um 11:16 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 11:18 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Andreas_Wolf:
Ich halte die These, dass IBM keinen für Notebooks geeigneten G5 liefern wollten oder konnten, für glaubhafter.

Und nicht zu vergessen, dass IBM gerade ein paar Deals gemacht hat:
- mit Microsoft bezügl. des XBox-Prozessors
- mit Nintendo bezügl. des Wii-Prozessors
- mit Sony bezügl. des Playstation Prozessors
und Steve Jobs irgendwie das Gefühl bekam, dass Apple als PPC-Kunde nicht ganz so wichtig genommen wurde.
Zitat:
Original von Thore:
@Holger:
Zitat:
Völlig unverständlich eigentlich nach Deiner eigenen Logik, nicht wahr?
Schließlich ist Java Big-Endian und läuft problemlos auf einem x86 Little-Endian PC, während es auf dem Big-Endian Amiga nach zehn Jahren immer noch nicht möglich ist...

Du hast es anscheinend nicht verstanden oder willst es nicht verstehen. Java ist ein PROZESSOR-EMULATOR, mit EIGENEM BYTECODE der von einer VM interpretiert wird, das hat nichts mit x86 oder 680x0 zu tun.
Ja, und nun erklär mir bitte, was einen Java-Bytecode JIT auf x86 von einem 68k-Emulator JIT auf x86 unterscheidet, warum also ein AOS4-x86 so große Probleme haben soll, 68k-Programme auszuführen.
Zitat:
Nein ein kürzerer Programmcode heißt noch lange nicht daß das Programm schneller ist, oft ist sogar das Gegenteil der Fall!
Es ging hier um MIPS, und daß 680x0 Code mit weniger Zeilen Code auskommt, um das gleiche zu berechnen.

Schön, nur dass AmigaOS4 nicht auf 68k, sondern auf ppc läuft, welches im Vergleich mit dem x86-Befehlssatz eher mehr Befehle benötigt, was nach Deiner Logik bedeuten würde, dass ein x86 ruhig ein paar MIPS weniger haben dürfte. Nur hat er aber gar nicht weniger, und wenn man nicht irgendwelche Server-Prozessoren vergleicht, sondern ausschließlich die Hardware, für die AOS4 real existiert, dann bietet ein Wald-und-Wiesen-PC nicht nur ein Vielfaches der reinen Ausführungsgeschwindigkeit, sondern auch noch mehr Kerne.

Wie soll Dein Gebrabbel über die 68000-Architektur jetzt genau begründen, warum AOS4 auf dem ppc besser aufgehoben ist, als auf einem x86?
Zitat:
"Lediglich mit einer anderen Compiler-Option", und wenns um Bit-Operationen geht muss man aufpassen ob es denn überhaupt noch stimmt, was denkst du denn, warum es bei portablen Sourcecodes die Verzeichnisse für die verschiedenen Prozessorarchitekturen gibt.
Es ist ausschließlich die Entscheidung der Entwickler, ob sie sich bezüglich Endianess selbst ins Knie schießen wollen, oder ob sie ihren Code von Anfang an vernünftig schreiben.
Zitat:
Wer eben ein paar Shell-C Programme portieren will hat zu 99% keine Probleme, aber ich denk Du hast noch nie an großen Projekten programmiert.
Da spricht der richtige...
Zitat:
Sogar Apples Wechsel zu Intel brachte Probleme wegen dem endianess, genau das wäre auch das Problem bei OS4 für x86.
http://en.wikipedia.org/wiki/Apple_Intel_transition

Wo stehen da ernsthafte Problem?
Zitat:
Original von Gerry:
- Das BE-LE-Problem existiert bei Konvertierungen tatsächlich. Es ist kein "Blech". Wer selbst programmiert, und schon Programme portiert hat, kennt das. Und als "Gegenargument" will ich jetzt nicht hören "Aber ein printf() unter AmigaOS ist doch auch unter Windows nur ein printf()". Man schaue sich an, wie printf programmiert wurde, vielleicht noch ein paar Header-Dateien,und erkennt, dass man u.U. auch diverse #ifdef BIG_ENDIAN oder etwas in der Art stosst.

Ja, das sind die Argumente, auf die wir gewartet haben. Wie viele Anwendungsprogrammierer programmieren sich ihren eigenen printf()-Befehl?
Zitat:
- Wieso möchte Linux seit neuestem eher die Strategie von AmigaOS verfolgen? Vermutlich wollen die sich an AmigaOS annähern, weil PCs mit Windows besser sind. Ist doch logisch....oder???
Vielleicht solltest Du mal lernen, mit Informationen richtig umzugehen, statt Dir Halbwahrheiten zusammenzureimen. Eine Person hat in einem Interview gesagt, dass es toll wäre, wenn sich Linux vom AmigaOS inspirieren lassen wurde. Das heißt, noch lange nicht, dass "Linux seit neuestem eher die Strategie von AmigaOS verfolgen" will.
Zitat:
Original von Gerry:
@Holger
Die Argumente von Dir haben keine Grundlage.
Natürlich brauchte ich für das Studium fachkundige Dr. Dipl-Ings etc. Denn wer studiert ohne Professoren...Mal darüber nachdenken!!
Viele von denen sind DIREKT in der Entwicklung, oder meinst du, die Entwickler haben keine Ahnung wie das geht? Dann gebe ich denen mal deine E-Mail, damit Du denen das beibringen kannst!!

Junge, Du willst Dipl.-Informatiker sein, und bist nicht ein mal in der Lage, die Sachverhalte richtig wiederzugeben und von Halbwahrheiten zu trennen.

Du bist übrigen nicht der einzige Dipl. Informatiker in diesem Forum. Du bist nur der erste, der es nötig hatte, sein Post mit einer Einleitung zu beginnen, die darauf zielt, dass sein Posting wahr wäre, weil er ein Diplom hätte. So ein Armutszeugnis hat bislang noch kein Teilnehmer dieses Forums abgelegt.

Insbesondere, wenn man sich dann die "fachlichen Begründungen" ansieht, die dieser Einleitung folgen.
Zitat:
Es liegt nur daran, dass Du auf Deiner Meinung beharrst.
Und keine tiefgehende Ahnung hast. Die Pipes sind tatsächlich mit eingerechnet. Fertig aus Schluss.

Was für eine sachliche Begründung.
Jetzt müsstest Du nur noch erklären, wie man Pipes in eine Taktfrequenz oder Geschwindigkeit einrechnet, bzw. umgekehrt wieder herausrechnet.
Oder wo der Unterschied zwischen den Pipelines einer PPC-Architektur und denen einer x86-Architektur liegen...
Zitat:
Ja, aber auch, wenn man Zeigeroperationen auf Words etc macht, da staunt der Fachmann nicht, aber der Laie wundert sich.
Ja total.
Bei einer Leseoperation erhält man den gleichen Wert, der vorher in der Schreiboperation in die Speicherzelle geschrieben wurde.
Es sei denn, man greift mit Zeigern unterschiedlichen Typs auf die Speicherstelle zu, was ja auch so vernünftig und natürlich alle Nase lang notwendig ist.
Zitat:
Vor allem auf dem Stack siehts dann schön witzig aus, wenn der Holger... ähh der PC-User den Stack abfrägt und sich wundert, wo den seine schönen Werte geblieben sind.
Ja, der allgemeine PC-User ist ja bekannt dafür, dass er alle Nase lang "den Stack abfrägt"...
Zitat:
Ich denke, es hat keinen weiteren Sinn, diese Leute zu belehren.
Ja, dieser Satz spricht für sich.
Und jetzt geh woanders "Leute belehren". Am besten da, wo man Dummschwätzer, die sich für den Nabel der Welt halten, weil sie ein Diplom haben, ehrfurchtsvoll anstaunt.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 11:57 Uhr

Thore
Posts: 2266
Nutzer
Ich werde wie gesagt nur auf die Themenspezifischen Dinge antworten.
Und ich bitte euch auch etwas sachlicher ranzugehen und nicht immer gleich irgendwelche Beleidigungen oder etwas in die Richtung zu posten, das will doch keiner lesen.

Zitat:
Ja, und nun erklär mir bitte, was einen Java-Bytecode JIT auf x86 von einem 68k-Emulator JIT auf x86 unterscheidet, warum also ein AOS4-x86 so große Probleme haben soll, 68k-Programme auszuführen.
Java ist immer BE, wenn Du OS4 auf x68 portieren würdest, gäbe es sowohl BE als auch LE Daten, gerade wenn man z.B. 68k Libs, ppc Datatypes und x68 Programm gleichzeitig verwenden würde, käme es eben zu Problemen. Die JIT Emu müsste immer entscheiden ob Bytes gedreht werden müssen oder nicht, das ist z.B. bei Pointer-Zuweisungen an eine Lib-Funktion nicht möglich (Pointer als Übergabeparameter). Würde OS4 vollständig mitsamt seinen Komponenten, Daten etc auf x68 (LE) portiert, würde es problemlos klappen, aber es ging um Kompatibilität zu bestehender Software.

Zitat:
Wie soll Dein Gebrabbel über die 68000-Architektur jetzt genau begründen, warum AOS4 auf dem ppc besser aufgehoben ist, als auf einem x86?
Die Argumente für 68000 waren off topic und bezogen sich auf vorangegangene Beiträge zum Thema Amiga im allgemeinen, was Prozessoreffizienz anging. Die Argumentation seitens Hyperion (es ging hier um AmigaOS auf x86 allgemein, z.B. per Emulation) kannst Du im Link nachlesen den ich im letzten Beitrag gepostet hab.

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 12:46 Uhr

bruZard
Posts: 307
Nutzer
Bild: http://24punkt.de/wp-content/uploads/2008/02/sack-reis.jpg
nu isser umgefallen.
--
Methusalem Kino - Das Blog über Nichts und Alles. ---- tm~mw :: die zeit läuft!

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 13:11 Uhr

Thore
Posts: 2266
Nutzer
@bruZard:
Um deinen wissenschaftlichen Beitrag zu vervollständigen, welche Sauce empfiehlst du für diese Reissorte?
Oder ist es Dir nur so wichtig als wenn in 中国一个包米跌倒吗?

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 13:20 Uhr

Gerry
Posts: 82
Nutzer
@bruZard:

Wenn Dich manche Fakten nicht interessieren, dann poste doch in nen anderen Thread, anstatt zu denken, das Bild sei besondern witzig.
Schliesslich sind die Argumente nicht von Thore bzw. mir erfunden.

@Thore:

Hat vorher einer was gesagt "Das sagt der Richtige" bezüglich großer Projekte. LOOOOL!!! Ich kenn die Projekte, an denen ich auch gearbeitet habe, und kann nur sagen:
Der Satz kann nur von Leuten kommen, die sofort Argumentieren, ohne
sich vorher informiert zu haben. Aber was sind schon so lausige Projekte wie...

...Compilerbau
...Warenwirtschaftssysteme
...EMail/Terminverwaltungsprogramme á la Outlook
...Wordprocessing
...Simulatoren
...Routing/Trackingtools für Flugzeuge
...Programmiersprachen
...Konverter
...Automobilsteuerungseinheiten
...Komplette Prozessoren
...und so weiter
...und so weiter

...welche alle wohl trivial sind...O.O

---
CP/M 68k war da... aber ist vielen wohl nicht bekannt. Es lag nur am Preis wie ich gerade nochmal gelsen hab. Genaue Werte hab ich jetzt nicht, ich meine, der 8088 war bei $150 damals. Motorola...hmm kein Plan. Würd mich aber selbst interessieren :-)




[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 13:49 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Thore:
Java ist immer BE, wenn Du OS4 auf x68 portieren würdest, gäbe es sowohl BE als auch LE Daten, gerade wenn man z.B. 68k Libs, ppc Datatypes und x68 Programm gleichzeitig verwenden würde, käme es eben zu Problemen.

Lass mich mal kurz zusammenfassen:
Java unter Windows: BE-Daten in der VM, LE Daten in den verwendeten DLLs, wie auch im gesamten restlichen Betriebssystem
68k-Programm unter einem hypothetischen x86-AmigaOS4: BE-Daten im 68k-Emulator, LE-Daten in den native Bibliotheken, wie auch im gesamten restlichen Betriebssystem.

Tut mir leid, nirgendwo auch nur der geringste Unterschied.
Zitat:
Die Argumente für 68000 waren off topic und bezogen sich auf vorangegangene Beiträge zum Thema Amiga im allgemeinen, was Prozessoreffizienz anging.
"Amiga im allgemeinen, was Prozessoreffizienz angeht" war nie das Thema. Außer für Dich und den anderen, der mit Dir, was die Relevanz von lowlevel-CPU-Details einer Meinung ist.

mfg

Zitat:
Original von Gerry:
Ich kenn die Projekte, an denen ich auch gearbeitet habe, ...

Was für eine Satzanfang. Den sollte man unbedingt mehrmals lesen und über die philosophische Tiefe nachdenken.
Zitat:
und kann nur sagen:
Der Satz kann nur von Leuten kommen, die sofort Argumentieren, ohne
sich vorher informiert zu haben.

informiert? über Dein Ego?
Zitat:
Aber was sind schon so lausige Projekte wie...

...Compilerbau
...Warenwirtschaftssysteme
...EMail/Terminverwaltungsprogramme á la Outlook
...Wordprocessing
...Simulatoren
...Routing/Trackingtools für Flugzeuge
...Programmiersprachen
...Konverter
...Automobilsteuerungseinheiten
...Komplette Prozessoren
...und so weiter
...und so weiter

...welche alle wohl trivial sind...O.O

Du hast vergessen:
...Betriebssysteme
...Erfindung des Computers
...Kernforschung
...Krebsheilung
...Erschaffung der Welt

und jetzt nimm bitte wieder die Pillen, die die Männer in den weißen Kitteln Dir geben, ja?

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 13:54 Uhr

bruZard
Posts: 307
Nutzer
Nur für die beiden Hardcore-Dipl.Inf.Ing.med.xyz

Bild: http://bruzard.colorflow.de/wp-content/gallery/bbp-gallery/bcc06.jpg
--
methusalem | tm~mw | basic

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 14:17 Uhr

Gerry
Posts: 82
Nutzer
@bruZard:

Falsch! Die Projekte sind Realität. Bitte keine Voreiligen Schlüsse!!
Ausserdem sind das keine Privatprojekte, sondern für Firmen. Und weisst Du was, es ist mir total egal wer's glaubt und wer nicht. Es gibt immerhin viele Kunden, welche diese Projekte nutzen. Dein Argument ist wieder zu schnell gekommen.

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 14:20 Uhr

Thore
Posts: 2266
Nutzer
Zitat:
Lass mich mal kurz zusammenfassen:
Java unter Windows: BE-Daten in der VM, LE Daten in den verwendeten DLLs, wie auch im gesamten restlichen Betriebssystem
68k-Programm unter einem hypothetischen x86-AmigaOS4: BE-Daten im 68k-Emulator, LE-Daten in den native Bibliotheken, wie auch im gesamten restlichen Betriebssystem.

Tut mir leid, nirgendwo auch nur der geringste Unterschied.

Kleine Lektüre:
http://entwickler-forum.de/showthread.php?t=32934

Die DLLs werden ja nativ ausgeführt, mich würd nur interessieren was mit den Daten passiert, bei denen nur der Pointer übergeben wird.
Kannst gerne ein Beispielprogramm posten mit Ausgabe.


Btw: Ich bin Programmierer und arbeite an Großprojekten wie einem umfangreichen EMail-Client-Server-System, WWS/PPS, WordProcessor, Tabellenkalkulation und diversen Zusatztools.

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 15:28 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Thore:
Kleine Lektüre:
http://entwickler-forum.de/showthread.php?t=32934

Was interessieren hier Anfängerfehler?
Zitat:
Die DLLs werden ja nativ ausgeführt, mich würd nur interessieren was mit den Daten passiert, bei denen nur der Pointer übergeben wird.
Kannst gerne ein Beispielprogramm posten mit Ausgabe.

*** Wegen Verstoß gegen die Netiquette gelöscht (cg)
http://www.amiga-news.de/netiquette.shtml ***

Jede Kommunikation erfordert eindeutige Schnittstellen, sowohl zwischen Java und dem Betriebssystem, als auch zwischen einer emulierten 68k-CPU und dem darunterliegenden System. So wie die gängigen Netzwerkprotokolle immer BE verwenden, RIFF-basierte Dateiformate wie AVI und WAV immer LE verwenden und IFF-Formate immer BE verwenden. Wenn Du Daten austauscht, gilt die byte-order der Schnittstellenspezifikation, bzw. des Dateiformats. Wo ist da das Problem?
Genauso, wie auch PPC oder 68k Software Pixel als BGRA statt ARGB verwenden müssen, wenn die Grafikkarte das so will. Wer mit der Außenwelt kommunizieren will, lernt das irgendwann oder fällt auf die Fresse.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von cgutjahr am 16.12.2008 um 15:52 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 15:46 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Gerry:
@bruZard:
Falsch! Die Projekte sind Realität. Bitte keine Voreiligen Schlüsse!!
Ausserdem sind das keine Privatprojekte, sondern für Firmen.

Das bezweifelt keiner. Es geht nur darum, was Dein Beitrag zu diesen Projekten war. Und warum Du es nötig hast, mit Deinen angeblichen Fähigkeiten hausieren zu gehen, aber keine überzeugende fachliche Argumentation zustande bringst.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 16:05 Uhr

Thore
Posts: 2266
Nutzer
@Holger:
Die Datentypen, TCP und PixelFormate die Du ansprichst sind wohldefiniert, da gibts natürlich keine Probleme, doch wenn Du selbst einen Datenstrom vorliegen hast, und übergibst den Pointer darauf an eine Routine, die eine andere ByteOrder annimmt, dann hast Du das Problem. Was genau ist da nicht zu verstehen?

Gegen die Netiquette verstoßen, wenn Du nicht sachlich argumentieren kannst, ist es besser wir beenden die Diskussion.
Mich hätte ein Beispielprogramm durchaus interessiert, wo es klappt einer DLL einen Pointer aus einem Java-Programm zu übergeben, und die ByteOrder richtig bleibt,

*** Wegen Verstoß gegen die Netiquette gelöscht (cg)
http://www.amiga-news.de/netiquette.shtml ***

[ Dieser Beitrag wurde von cgutjahr am 16.12.2008 um 16:06 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 16:07 Uhr

cgutjahr
Posts: 2779
[Administrator]
@all:

Leute, bleibt sachlich. Wenn weiterhin nur noch die vermeintliche oder fehlende Kompetenz, Intelligenz oder Höflichkeit des Gegenübers diskutiert wird, mache ich den Thread zu.
--
Gutjahrs Amiga Seiten

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 16:08 Uhr

bruZard
Posts: 307
Nutzer
So ein Beispielprogramm würde mich auch interessieren. Aber nur wegen der Tatsache das Java überhaupt nicht in der Lage ist einen Pointer an eine DLL zu übergeben.

--
methusalem | tm~mw | basic

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 16:24 Uhr

Thore
Posts: 2266
Nutzer
Ich habe zwar keine Beleidigung oder ähnliches gepostet, dennoch möchte ich mich bei den Lesern des AmigaForums für die Entgleisung des Themas entschuldigen.

Zum Thema zurück (OS4Emu und dazugehöriges)
Ja gibt es denn allgemein ein funktionierendes Beispiel von LE nach BE Code oder andersrum, was die ByteOrder richtig umsetzt per Pointer-Referenzierung?

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 16:35 Uhr

bruZard
Posts: 307
Nutzer
Du liest garnicht was so geschrieben wird, oder?

Java hat keine Pointer, es kann auch keine Pointer verarbeiten die von irgendeinem DAU als Parameter übergeben werden. Für Java wäre der Pointer einfach nur irgendein LONG. Java nutzt (wenn überhaupt) externe Bibliotheken zur Laufzeit exakt so wie es immer vorgesehen war: Über dedizierte Interfaces und nicht per wildem Pointergehacke mit der Hoffnung schon den korrekten Offset zu treffen. Auch sonst ist es heute nicht mehr notwendig per Pointer an seine Daten zu kommen. Sollte eine Lib das verlangen kann man sich immer noch nach einer besser organisierten Lösung umschauen.

Es ist keine Frage dass man als Programmierer hin und wieder ein Byteswap vornehmen muss (Beispiel: Mittels LittleEndian StreamLib ein PNG File auslesen), es ist aber keineswegs so dass das eine wahnsinnige Hürde ist. Auf einem Amiga liegt das PNG in der selben Form vor wie auf dem PC, nur muss ich auf dem PC halt erst die Integer umdrehen bevor sie Sinn ergeben.
Portiere ich nun meine Applikation vom PC auf den Amiga lasse ich das Byteswap einfach weg. Oder ich bin vorher clever und baue die App so dass ich den Byteswap per Compilerdirektive ausschliessen kann, dann muss ich (theoretisch) nur das Target ändern und das Kompilat macht keinen Swap.

Mich ja mal wahnsinnig interessieren welcher Depp erfunden hat dass die Endian Problematik direkt hinter der Welthungersituation anzusiedeln ist, dass das jetzt soviele Laien nachplappern.

--
methusalem | tm~mw | basic

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 16:56 Uhr

Thore
Posts: 2266
Nutzer
@bruZard:
(Bleib bitte auch sachlich)
Es geht um eine Möglichkeit eines x86 nativem OS4, welches bestehende BE Routinen weiter verwenden kann.
Es ging auch nicht generell um Java sondern um die Übergebe eines Parameters an eine Unterroutine die einen anderen ByteOrder annimmt.
Ich versteh nicht was du mit Offsets meinst, es ging doch nur um die Übergabe einer Adresse von einem Datenstrom, das ist ein ganz normaler Vorgang, hat nichts mit Rumgehacke zu tun. Java habe ich nicht ins Spiel gebracht, ich habe es nur aufgegriffen und gefragt ob es hier ein Beispiel dafür gibt.
Es geht auch nicht um Datentypen und wie der Loader in LE oder BE aussieht und wie das portierbar ist. Es geht um die Schnittstelle von einem LE Programm zu einem BE Programm oder andersrum.

Nochmal als Beispiel:
Programm(LE) will externe Lib(BE) verwenden und hat viele Daten (z.B. eine lange Zeichenkette) und übergibt sie daher als Pointer.

Nun die Frage hinterher: Könnte es mit einem intelligenten JIT funktionieren, der beim Umsetzen der BE Befehle die Bytes tauscht?

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 17:31 Uhr

bruZard
Posts: 307
Nutzer
Klar kann das funktionieren. Ein natives x86 OS4 muss bei einer Emulation eines 68k Programmes generell davon ausgehen dass eine Endian-Konvertierung vorgenommen werden muss. Das passiert aber bevor die Emu mit dem Host kommuniziert. Der JIT haut das ja nicht per-instruction raus, sondern baut intern erstmal was ausführbares. Nichts anderes macht WinUAE.

Generell kann man sagen: Ein natives x86 OS4 müsste "nur" ein WinUAE Kernel beinhalten. Eine Emulation die OS4 auf x86 laufen lassen will macht einfach das was Emulatoren schon immer machten: Sie liefern einen Softwareprozessor der das ausführt was der Host nicht kapiert.

--
methusalem | tm~mw | basic

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 17:49 Uhr

fisch08
Posts: 692
Nutzer
Ohje, was habe ich angerichtet?

Also:
- Meine Eingangsfrage wurde beantwortet.
- Ich persönlich finde es bedauerlich, dass Amiga OS 4.0 nicht auf x86 Maschinen zum Laufen gebracht werden kann.
- OS4.0 Hardware ist mir zu teuer
- Es gibt keine Amiga USer in meiner Gegend

Und nun sehe ich, dass hier der Admin schon eingreifen muss.

BITTE THEMA SCHLIESSEN!
--
Um den Spamfilter zu umgehen: Bei direkter Antwort per Mail bitte "[Amiga]" ins Subject: Nur so 100%ige Garantie, dass man nicht im Filter landet!

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 18:45 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Thore:
@Holger:
Die Datentypen, TCP und PixelFormate die Du ansprichst sind wohldefiniert, da gibts natürlich keine Probleme, doch wenn Du selbst einen Datenstrom vorliegen hast, und übergibst den Pointer darauf an eine Routine, die eine andere ByteOrder annimmt, dann hast Du das Problem. Was genau ist da nicht zu verstehen?

Die Frage, wie eine 68k-Anwendung einen Pointer an ein x86-Betriebssystem übergeben sollte, der nicht auf eine wohldefinierte Datenstruktur zeigt.
Zitat:
Original von Thore:
Mich hätte ein Beispielprogramm durchaus interessiert, wo es klappt einer DLL einen Pointer aus einem Java-Programm zu übergeben, und die ByteOrder richtig bleibt,

Die Kommunikation zwischen Java und einer DLL erfolgt genauso, wie die zwischen Anwendungen und dem Betriebssystem: ausschließlich über wohldefinierte Datenstrukturen. Da es in Java so etwas wie Pointer ohne definierten Datentyp sowieso nicht gibt, gibt es da keine Probleme. Wer es wirklich nicht lassen kann und unbedingt undefinierte Folgen von bytes übergeben will, kann das via ByteBuffer machen:
Java code:
import java.nio.*;

//...

ByteBuffer b=ByteBuffer.allocateDirect(12).order(ByteOrder.nativeOrder());
b.putDouble(0.815).putInt(42).rewind();

someNativeMethod(b);

Aber das hat mit dem Thema nicht viel zu tun, denn das ergibt ja auch nur dann Sinn, wenn es eine DLL gibt, die diese Struktur erwartet.

Bestehende 68k-Software kann aber mit einem noch gar nicht existierenden x86-AOS4 gar nicht über unbekannte Datenstrukturen kommunizieren, oder gar irgendwelche noch nicht existierenden native libraries benutzen wollen.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 16.12.2008 um 19:14 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 18:55 Uhr

Andreas_Wolf
Posts: 2980
Nutzer
> Und ja, der Motorola war nur geringfügig teurer, etwa 1 $.

Das schriebst du bereits. Und ich bat um Belege dieser Behauptung. Eine Wiederholung ist kein Beleg.

> Die Genaue Quelle ist mir nicht bekannt

Es geht nicht um "die genaue Quelle" (was immer das sein soll), sondern um irgendeine für diese Frage *allgemein respektable* Quelle, z. B. Aussagen damaliger IBM-Ingenieure oder -Manager etc. Privatgespräche zwischen dir und Leuten, die du kennst, gehören da nicht dazu.

> jedoch ist die Aussage von Leuten, die das sehr genau wissen.

Du meinst Leute, die *behaupten*, das sehr genau zu wissen? Oder Leute, von denen du *glaubst*, dass sie das sehr genau wissen?
Für mich hört sich diese "Nur-1-USD-Preisdifferenz"-Geschichte wie eine Urban Legend an. Und wie es Urban Legends nun mal so an sich haben, werden sie besonders gern als wahre Geschichten weitererzählt. Nur das macht sie eben noch lange nicht wahr.

> mit "weitaus mehr als 3 GHz" meinte ich u.a. den versprochenen
> 10 GHz.

Wann und wo versprochen?

> Das Marketing von Apple wurde öffentlich bekannt gegeben, so viel
> zum dem Thema.

Laut Apple-Marketing wurde der Wechsel zu Intel vollzogen, "weil der PowerPC-Chip weniger angegebene GHz hatte"? Und was sollen Marketing-Aussagen überhaupt für eine Relevanz für die *wahren* Gründe haben, die wir hier diskutieren?

> Es wird viel nach außen vom Marketing getragen, was technisch
> gesehen etwas anders ist. So einfach ist das.

Ach, ganz plötzlich. Gerade eben noch hast du (angeblich gemachte) Marketing-Aussagen als Quelle für deine Behauptung benutzt. So dreht man sich in Sekundenschnelle alles, wie man es braucht.

> Java wird ja heute noch weiterentwickelt. Da C# erst reagieren
> kann, wenn die Entwicklung released ist, hängt es nach. Das ist
> kausal und nicht verwirrend.

Verwirrend ist folgende Begründung, die du jetzt klammheimlich unter den Tisch fallen lässt:
"Der Grund ist eben der, dass Java eben auf SUN entwickelt wurde und deshalb dort auch immer aktuell ist."
Was hat das mit der Entwicklung "auf SUN" (Solaris? SPARC?) und der Aktualität "dort" (Solaris? SPARC?) zu tun?

> Und hab ich erwähnt, dass eine der CPU-Reihen eingestampft wurde?
> Mit keinem Wort!! Ich habe geschrieben (es darf nachgelesen
> werden), dass man sich mit dem Gedanken befasste.

Quelle? Und wieso hat man sich dann dagegen entschieden, eine davon einzustampfen? Und wo ist die Relevanz, wenn man sich nur "mit dem Gedanken befasste", es aber nicht tat?

> Ob noch etwas in der Art passiert, weiss ich nicht. Vielleicht kann
> ich da noch was in Erfahrung bringen.

Von deinen Bekannten, die anscheinend nicht nur bei Apple und IBM in hohen Positionen sitzen und saßen, sondern auch bei Intel? Oder wer sonst außer Intel soll wissen, was Intel vorhat?
Zur Info: Der aktuelle Pentium (Pentium Dual-Core E5300) wurde vor 16 Tagen veröffentlicht, der aktuelle Itanium (Itanium 2 Montvale) im Oktober 2007; sein Nachfolger ist noch für dieses Jahr angekündigt.

> CP/M 68k war da... aber ist vielen wohl nicht bekannt.

Offenbar ist das nur dir (und deinen Bekannten?) bekannt. Zu dem Zeitpunkt, als sich IBM für Intel und gegen Motorola entschieden, gab es definitiv noch *kein* CP/M-68k. Wie ich gerade noch mal nachlas (und damit meine Aussage von vorhin korrigiere), gab es zu diesem Zeitpunkt noch nicht mal das vor CP/M-68k erschienene CP/M-86 (für Intel 8086 und den im IBM-PC eingesetzten Intel 8088). Allerdings war es angekündigt, und das reichte IBM wohl (neben dem Preisargument) aus, auf Intel zu setzen.

> Es lag nur am Preis wie ich gerade nochmal gelsen hab.

Wo hast du das gelesen, dass es *nur* am Preis und *nicht auch* an der (Nicht-)Verfügbarkeit von CP/M lag?

> ich meine, der 8088 war bei $150 damals. Motorola...hmm kein Plan.
> Würd mich aber selbst interessieren :-)

Nach deiner zweifelhaften These wäre der 68000 bei 151 USD gewesen. Oder bist du nun plötzlich doch nicht mehr so sicher?


> OS4 könnte wenn dann nur auf einem modifizierten QEmu laufen

Ja, siehe cgutjahrs und meinen Beitrag zu ACK und OS4 auf QEMU.

> Hyperion leht AmigaOS auf x86 auch entschieden ab: [...]

Das stimmt seit einem halben Jahr nicht mehr:

http://www.amiga-news.de/de/news/comments/227227.html


> Eine Person hat in einem Interview gesagt, dass es toll wäre, wenn
> sich Linux vom AmigaOS inspirieren lassen wurde. Das heißt, noch
> lange nicht, dass "Linux seit neuestem eher die Strategie von
> AmigaOS verfolgen" will.

Full Ack. Nur kleine Korrektur: Es war kein Interview.

[ - Antworten - Zitieren - Direktlink - ]

16.12.2008, 19:13 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Thore:
Es geht um eine Möglichkeit eines x86 nativem OS4, welches bestehende BE Routinen weiter verwenden kann.

Was meinst Du mit bestehenden BE-Routinen?
AmigaOS4 ist C-Code, und hoffentlich halbwegs sauber programmierter, ohne wildes Pointergehacke.
Das heißt, x86-Amiga-Software sollte mit einem x86-AmigaOS, wie auch die Module untereinander keine Probleme haben, oder?

Ich mein, das sollten wir jetzt mal klären: reden wir eigentlich über generelle Problem, die ein AmigaOS4-x86 haben sollte, oder nur über die Feinheiten, 68k-Programme in einer möglichst transparenten CPU-Emulation laufen zu lassen?
Zitat:
Ich versteh nicht was du mit Offsets meinst, es ging doch nur um die Übergabe einer Adresse von einem Datenstrom, das ist ein ganz normaler Vorgang, hat nichts mit Rumgehacke zu tun.
Wo ist das ein normaler Vorgang?
Jede OS-Routine erwartet präzise definierte Strukturen als Argument. So etwas wie einen Datenstrom gibt es dabei nicht.

Die einzigen Datenströme, die das AmigaOS kennt, sind Dateien. Und die sind eine Abfolge von bytes. Wer aus einer Datei liest, muss wissen in welcher Reihenfolge sie vorliegen.
Zitat:
Java habe ich nicht ins Spiel gebracht, ...
Java ist nur ein Beispiel dafür, wie problemlos sauber geschriebene Software laufen kann, da pointer-Spielereien dort nicht möglich sind. Es ist zwar per Definition BE, Du merkst aber gar nicht, dass auf x86-Systemen die Daten in Wahrheit LE gespeichert sind, weil Du gar keine Möglichkeit hast, auf eine Variable anders zuzugreifen, als über ihren definierten Datentyp. Es ist keineswegs so, dass bei Speicherzugriffen die Daten jedes mal zwischen Java(BE) und Intel(LE) konvertiert werden würden. Die definierte ByteOrder wird lediglich dann relevant, wenn Du einen Wert in eine Abfolge von bytes umwandelst.
Aber eben nicht, wenn Du eine Routine aufrufst, die genau den Datentyp erwartet, in dem die Werte schon vorliegen.
Zitat:
Es geht um die Schnittstelle von einem LE Programm zu einem BE Programm oder andersrum.

Nochmal als Beispiel:
Programm(LE) will externe Lib(BE) verwenden und hat viele Daten (z.B. eine lange Zeichenkette) und übergibt sie daher als Pointer.

Nun die Frage hinterher: Könnte es mit einem intelligenten JIT funktionieren, der beim Umsetzen der BE Befehle die Bytes tauscht?

Mal abgesehen davon, dass das Beispiel hinkt, weil bislang kein 68k (AOS3)-Programm Zeichenketten mit multi-byte Zeichen kennt:
Das ist für alle bekannten Schnittstellen des Betriebssystems möglich. Und dass man so keine neuen native Bibliotheken aus einem 68k-Programm heraus aufrufen kann, ist verschmerzlich: das kann man mit dem jetzigen ppc-AOS4 nämlich auch nicht.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]


1 2 3 -4- 5 [ - Beitrag schreiben - ]


amiga-news.de Forum > Amiga, AmigaOS 4 > PPC Emulator für OS4 [ - Suche - Neue Beiträge - Registrieren - Login - ]


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