Hallo! Habe folgendes heute gelesen:
http://www.pro-linux.de/news/2008/13458.html
Es handelt sich um Netbooks auf ARM-Basis, welche von Canonical (Firma hinter Ubuntu) unterstützt werden soll.
Hem, also im Prinzip könnte man da doch auch RISC OS drauf anpassen und z.B. von Platte booten, oder? Kauft man halt so einen Ubuntu-Netbook, haut Ubuntu weg, und RISC OS drauf. Und das sicherlich zu einem Preis, der mit x86-Netbooks mithalten kann.
Netbook mit ARM-CPU
Moderator: Patrick
[quote="Artchi"]Hallo! Habe folgendes heute gelesen:
http://www.pro-linux.de/news/2008/13458.html
Es handelt sich um Netbooks auf ARM-Basis, welche von Canonical (Firma hinter Ubuntu) unterstützt werden soll.
Hem, also im Prinzip könnte man da doch auch RISC OS drauf anpassen und z.B. von Platte booten, oder? Kauft man halt so einen Ubuntu-Netbook, haut Ubuntu weg, und RISC OS drauf. Und das sicherlich zu einem Preis, der mit x86-Netbooks mithalten kann.
[/quote]
Tja, leider ARMv7. Wie man hört, ist das ganz und gar nicht kompatibel auf Binär/Assembler-Ebene mit unserem gewohnten ARMv4/ARMv5. Da darfst Du erst mal das komplette RISC OS umschreiben.
Ich habs nicht im Detail überprüft, aber das war zumindest der Konsens in csa.programmer.
Dann vielleicht doch lieber die Arbeit in einen supereffizienten ARM-JIT für x86 stecken und auf Emulation setzen, da ist die Hardwareauswahl größer, die Prozessoren schneller und man muss keine blöden Treiber selbst schreiben.
Steffen
http://www.pro-linux.de/news/2008/13458.html
Es handelt sich um Netbooks auf ARM-Basis, welche von Canonical (Firma hinter Ubuntu) unterstützt werden soll.
Hem, also im Prinzip könnte man da doch auch RISC OS drauf anpassen und z.B. von Platte booten, oder? Kauft man halt so einen Ubuntu-Netbook, haut Ubuntu weg, und RISC OS drauf. Und das sicherlich zu einem Preis, der mit x86-Netbooks mithalten kann.
[/quote]
Tja, leider ARMv7. Wie man hört, ist das ganz und gar nicht kompatibel auf Binär/Assembler-Ebene mit unserem gewohnten ARMv4/ARMv5. Da darfst Du erst mal das komplette RISC OS umschreiben.
Ich habs nicht im Detail überprüft, aber das war zumindest der Konsens in csa.programmer.
Dann vielleicht doch lieber die Arbeit in einen supereffizienten ARM-JIT für x86 stecken und auf Emulation setzen, da ist die Hardwareauswahl größer, die Prozessoren schneller und man muss keine blöden Treiber selbst schreiben.
Steffen
[quote="hubersn"]Tja, leider ARMv7. Wie man hört, ist das ganz und gar nicht kompatibel auf Binär/Assembler-Ebene mit unserem gewohnten ARMv4/ARMv5.[/quote]
Hmm, nicht das ich alzu große Hoffnung auf native Hardware für den Desktop hatte, aber wenn ich das richtig verstehe ist mit dem ARM9 und XScale für RISC OS in der jetzigen Form Schluß? Wenn ich es richtig ersurft habe, ist der ARM10 ARMv6 und alles spätere bis heute ARMv7. Das macht Emulation immer weniger zur Alternative,sondern zum Muß, wenns dann nicht Windows darunter heißt.
Hmm, nicht das ich alzu große Hoffnung auf native Hardware für den Desktop hatte, aber wenn ich das richtig verstehe ist mit dem ARM9 und XScale für RISC OS in der jetzigen Form Schluß? Wenn ich es richtig ersurft habe, ist der ARM10 ARMv6 und alles spätere bis heute ARMv7. Das macht Emulation immer weniger zur Alternative,sondern zum Muß, wenns dann nicht Windows darunter heißt.
[quote="hubersn"]
Tja, leider ARMv7. Wie man hört, ist das ganz und gar nicht kompatibel auf Binär/Assembler-Ebene mit unserem gewohnten ARMv4/ARMv5. Da darfst Du erst mal das komplette RISC OS umschreiben.
Ich habs nicht im Detail überprüft, aber das war zumindest der Konsens in csa.programmer.[/quote]
Habe leider die ARMs seit langem nicht mehr verfolgt. Das ARMv7 so inkompatibel zu den vorherigen sein soll, habe ich nicht gewusst. Das ist ja echt mal dumm gelaufen. :-(
[quote="hubersn"]
Dann vielleicht doch lieber die Arbeit in einen supereffizienten ARM-JIT für x86 stecken und auf Emulation setzen, da ist die Hardwareauswahl größer, die Prozessoren schneller und man muss keine blöden Treiber selbst schreiben.
[/quote]
Ja, das wird dann wohl wirklich so sein. Das es so extrem ist, hätte ich nicht gedacht. Habe mich zwar immer gefragt, warum Castle & Co keinen ARM11 verbauen, aber damit dürfte wohl alles klar sein.
Tja, RISC OS ist halt wirtschaftlich so unwichtig geworden, das man die Inkompatibilität über Board werfen konnte. Das macht die Sach noch deutlicher.
Hem... aber eine Emulation ist ja nun auch nicht das Ziel, zumindest das nervige Vorbooten eines anderen Systems (egal ob Windows, Linux u.a.). ARM-CPUs selbst sind für mich heute auch kein Muß, aber ein RISC OS nativ wäre das Ziel (notfalls x86).
Schade...
Tja, leider ARMv7. Wie man hört, ist das ganz und gar nicht kompatibel auf Binär/Assembler-Ebene mit unserem gewohnten ARMv4/ARMv5. Da darfst Du erst mal das komplette RISC OS umschreiben.
Ich habs nicht im Detail überprüft, aber das war zumindest der Konsens in csa.programmer.[/quote]
Habe leider die ARMs seit langem nicht mehr verfolgt. Das ARMv7 so inkompatibel zu den vorherigen sein soll, habe ich nicht gewusst. Das ist ja echt mal dumm gelaufen. :-(
[quote="hubersn"]
Dann vielleicht doch lieber die Arbeit in einen supereffizienten ARM-JIT für x86 stecken und auf Emulation setzen, da ist die Hardwareauswahl größer, die Prozessoren schneller und man muss keine blöden Treiber selbst schreiben.
[/quote]
Ja, das wird dann wohl wirklich so sein. Das es so extrem ist, hätte ich nicht gedacht. Habe mich zwar immer gefragt, warum Castle & Co keinen ARM11 verbauen, aber damit dürfte wohl alles klar sein.
Tja, RISC OS ist halt wirtschaftlich so unwichtig geworden, das man die Inkompatibilität über Board werfen konnte. Das macht die Sach noch deutlicher.
Hem... aber eine Emulation ist ja nun auch nicht das Ziel, zumindest das nervige Vorbooten eines anderen Systems (egal ob Windows, Linux u.a.). ARM-CPUs selbst sind für mich heute auch kein Muß, aber ein RISC OS nativ wäre das Ziel (notfalls x86).
Schade...
[quote="cms"]
Gähn, da sind wir schon wieder. Wer meint eine Portierung auf eine andere Architektur ist realistisch, ist ein [b]Träumer[/b]!
[/quote]
Habe ich was von Portierung geschrieben? Ich habe geschrieben [b]ein[/b] RISC OS nativ auf x86! Das man das RISC OS, wegen viel Assembler, nicht portieren kann, ist mir bewusst. Trotzdem kann man ein RISC OS auf einer anderen Plattform anstreben, so wie es Apple mit seinem MacOS gemacht hat. Die haben das alte MacOS auch nicht portiert, haben aber trotzdem ein MacOS X auf anderer Plattform rausgebracht (zumindest auf anderer Plattform portierbar, siehe Switch von PPC auf x86). AmigaOS 4 ist meines Wissens auch kein Port, sondern neu entwickelt. Und sowohl MacOS X als auch AmigaOS 4 haben das "Problem" mit alten Anwendungen durch eine transparente Emulation oder JIT gelöst. Halte ich für besser, als ewig mit dem alten RISC OS unter Windows oder Linux rumzugurken.
Gähn, da sind wir schon wieder. Wer meint eine Portierung auf eine andere Architektur ist realistisch, ist ein [b]Träumer[/b]!
[/quote]
Habe ich was von Portierung geschrieben? Ich habe geschrieben [b]ein[/b] RISC OS nativ auf x86! Das man das RISC OS, wegen viel Assembler, nicht portieren kann, ist mir bewusst. Trotzdem kann man ein RISC OS auf einer anderen Plattform anstreben, so wie es Apple mit seinem MacOS gemacht hat. Die haben das alte MacOS auch nicht portiert, haben aber trotzdem ein MacOS X auf anderer Plattform rausgebracht (zumindest auf anderer Plattform portierbar, siehe Switch von PPC auf x86). AmigaOS 4 ist meines Wissens auch kein Port, sondern neu entwickelt. Und sowohl MacOS X als auch AmigaOS 4 haben das "Problem" mit alten Anwendungen durch eine transparente Emulation oder JIT gelöst. Halte ich für besser, als ewig mit dem alten RISC OS unter Windows oder Linux rumzugurken.
[quote="cms"]Portieren oder neuschreiben ist ein Unterschied. Bei RISC OS macht es aber keinen Unterschied. Natürlich kann man das anstreben, ist aber reine Träumerei und nichts weiter.
[/quote]
Warum sollte ein Neuschreiben nicht möglich sein? Auch zeitlich wäre es meiner Meinung nach möglich. Denn das orig. RISC OS ist nun nicht sooo groß. Es geht ja nicht darum Windows Vista oder MacOS X neu zuschreiben. Sondern ein RISC OS-ähnliches OS. Es muß auch nicht in Assembler sein, bis auf ein paar unumgängliche Dinge. Mit einer Hochsprache a la C++ oder Ada ist man auch recht fix im Implementieren eines GUI. (ja, die GUI ist nicht alles)
Ich habe hier die PRM 3 stehen... rein von der API-Größe ist das ein Witz ggü. den großen OSen a la WinNT oder MacOS X. Natürlich müsste man sich auf bestimmte Hardware beschränken. Man könnte z.B. nicht sagen "Es soll soviel HW-Konfigs wie möglich supported werden.". Man müsste es so anstellen wie Apple: nur bestimmte HW-Komponenten unterstützten und man ist fein raus.
Intels Grafikchips sind z.B. offen dokumentiert. Dann sagt man halt: das OS läuft nur auf nem Mainbord mit dem und dem Chipsatz von Intel. Punkt! Das ist immer noch billiger als ein Iyonix - schlechter kann die HW-Auswahl jedenfalls nicht werden. Und man hätte RISC OS-feeling nativ. Auch wenn es nicht das originale RISC OS ist... klar.
Ntürlich sind das hier alles nur Vorstellungen. Und? Wenn das hier nicht erlaubt ist, sollte der Thread geschlossen werden...
[/quote]
Warum sollte ein Neuschreiben nicht möglich sein? Auch zeitlich wäre es meiner Meinung nach möglich. Denn das orig. RISC OS ist nun nicht sooo groß. Es geht ja nicht darum Windows Vista oder MacOS X neu zuschreiben. Sondern ein RISC OS-ähnliches OS. Es muß auch nicht in Assembler sein, bis auf ein paar unumgängliche Dinge. Mit einer Hochsprache a la C++ oder Ada ist man auch recht fix im Implementieren eines GUI. (ja, die GUI ist nicht alles)
Ich habe hier die PRM 3 stehen... rein von der API-Größe ist das ein Witz ggü. den großen OSen a la WinNT oder MacOS X. Natürlich müsste man sich auf bestimmte Hardware beschränken. Man könnte z.B. nicht sagen "Es soll soviel HW-Konfigs wie möglich supported werden.". Man müsste es so anstellen wie Apple: nur bestimmte HW-Komponenten unterstützten und man ist fein raus.
Intels Grafikchips sind z.B. offen dokumentiert. Dann sagt man halt: das OS läuft nur auf nem Mainbord mit dem und dem Chipsatz von Intel. Punkt! Das ist immer noch billiger als ein Iyonix - schlechter kann die HW-Auswahl jedenfalls nicht werden. Und man hätte RISC OS-feeling nativ. Auch wenn es nicht das originale RISC OS ist... klar.
Ntürlich sind das hier alles nur Vorstellungen. Und? Wenn das hier nicht erlaubt ist, sollte der Thread geschlossen werden...
[quote="Artchi"][quote="hubersn"]
Dann vielleicht doch lieber die Arbeit in einen supereffizienten ARM-JIT für x86 stecken und auf Emulation setzen, da ist die Hardwareauswahl größer, die Prozessoren schneller und man muss keine blöden Treiber selbst schreiben.
[/quote]
Ja, das wird dann wohl wirklich so sein. Das es so extrem ist, hätte ich nicht gedacht. Habe mich zwar immer gefragt, warum Castle & Co keinen ARM11 verbauen, aber damit dürfte wohl alles klar sein.
[/quote]
Naja, das hat aber einen anderen Hintergrund: es gab schlicht keine verfügbare ARM10- oder ARM11-Implementierung, die für einen IYONIX-Nachfolger Sinn gemacht hätten (sprich: anständig schnelles RAM unterstützen, möglichst auch noch PCI-Express und hohe Taktraten).
Der IOP342 wäre der einzig sinnvolle Kandidat gewesen, und in der Tat hatte Castle den auch im Auge - aber bei den Micker-Stückzahlen ist das schlicht nicht rentabel.
Steffen
Dann vielleicht doch lieber die Arbeit in einen supereffizienten ARM-JIT für x86 stecken und auf Emulation setzen, da ist die Hardwareauswahl größer, die Prozessoren schneller und man muss keine blöden Treiber selbst schreiben.
[/quote]
Ja, das wird dann wohl wirklich so sein. Das es so extrem ist, hätte ich nicht gedacht. Habe mich zwar immer gefragt, warum Castle & Co keinen ARM11 verbauen, aber damit dürfte wohl alles klar sein.
[/quote]
Naja, das hat aber einen anderen Hintergrund: es gab schlicht keine verfügbare ARM10- oder ARM11-Implementierung, die für einen IYONIX-Nachfolger Sinn gemacht hätten (sprich: anständig schnelles RAM unterstützen, möglichst auch noch PCI-Express und hohe Taktraten).
Der IOP342 wäre der einzig sinnvolle Kandidat gewesen, und in der Tat hatte Castle den auch im Auge - aber bei den Micker-Stückzahlen ist das schlicht nicht rentabel.
Steffen
[quote="Artchi"]Warum sollte ein Neuschreiben nicht möglich sein?[/quote]
Natürlich ist es nicht unmöglich. Ich würde mal sagen, dann leg mal los und hau in die Tasten. Würd mich freuen wenn es klapt. Das ist ernst gemeint und bin auch ein potenzieller Käufer! Aber Achtung mit der Hardwareunterstützung. Die Hardware muß es noch geben wenn Du/Ihr fertig bist/seit.
Natürlich ist es nicht unmöglich. Ich würde mal sagen, dann leg mal los und hau in die Tasten. Würd mich freuen wenn es klapt. Das ist ernst gemeint und bin auch ein potenzieller Käufer! Aber Achtung mit der Hardwareunterstützung. Die Hardware muß es noch geben wenn Du/Ihr fertig bist/seit.