Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: mysticforce am 25. May 2005, 12:10
-
hi wollte mal fragen was ihr allgemein von dieser cpu architektur haltet. ich habe mal gelesen es soll eine "echte" 64 bit architektur sein. weiss jemand was das zu bedeuten hat (ausser das sie nicht abwärts kompatibel ist. wie z.b. die opterons). ich hab mich ausserdem mal nach einem solchen prozessor umgesehen und nur die sun server, workstations und die macs gefunden. kennt ihr sonst welche die erschwinglich sind?
die architektur selbst scheint genial und allen derzeitig aktuellen cpus überlegen zu sein.
also postet meinungen bitte.
edit:
hab hier noch nen netten link gefunden der die beiden prozessortypen anhand ihrer entwicklung im laufe der zeit erklärt.
http://www.bernd-leitenberger.de/cisc-risc.html
-
Da hast du ne ziemlich genaue erklärung was RISC-CPU's sind.
Athlon oder sonstige Prozessoren sind im Kern auch nur RISC-Prozessoren nur mit ein paar extras ^^
http://de.wikipedia.org/wiki/Reduced_Instruction_Set_Computing
http://en.wikipedia.org/wiki/RISC
-
Aber er hat Recht, die Riscs sind meistens schneller, haben dafür aber keine komplizierten Befehle (Stringoperationen z.B.), die RISC's sind auch energiesparender und in der Regel bissel schneller, z.B. 900MHZ RISC CPU von Apple ist ca. so schnell wie 2GHz von Intel. Und bei kleinen Aufgaben und Geräten, die keine komplizierten arithmetischen oder logischen Operationen ausführen sollen, sind RISC-CPU ein Muss.
-
danke aber die kenn ich schon. mich würden vorallem meinungen mit begründung interessieren. auch eine erklärung was es mit dem "echten" 64 bit aufsich hat.
heißt das das sie für komplizierte arithmetische oder logische Operationen schlechter geignet sind?
-
Eigentlich finde ich die Bezeichnung mehr als problematisch, weil schon einige das wohl verwechseln. ;)
Ich kann auch eine 16 Bit RISC CPU machen, in der Weise das diese CPU dann ein reduziertes Instruktionsset hat.
Vielleicht meinst du mehr HP's PA-RISC Architektur? http://www.computerbase.de/lexikon/PA-RISC
Und Apple verbaut ja generell CPUs der PowerPC Reihe, was eine RISC-CPU ist.
-
RISC = kennt wenig Befehle, ist schnell
CISC = kennt viele u./o. komplexe Befehle, ist langsamer
Sämtliche neueren CPUs sind im Kern RISC-Prozessoren, aber durch die Kompatiblität zur CISCigsten aller CPUs, dem 486er ^^, muessen die neueren CPUs auch den kompletten Befehlssatz des 486ers abbilden können. Das kostet ungemein viel Leistung... und sorgt dafuer, dass m68k oder die G's bei gleicher Taktfrequenz ziemlich schnell wegrennen.
RISC hat mit 64-Bit nichts zu tun. Wenn du sämtliche Daten- und Adressleitungen samt den Befehlen auf 64 Bit erweiterst, hast du echte 64 Bit. Machst du es nur mit 8 Bit breiten Leitungen/Befehlen, hast du ne echte 8-Bit-RISC-Architektur. Die Aussage "echte 64 Bit" ist irrefuehrend und nicht relevant.
64 Bit heisst, dass du enorm viel RAM verwalten kannst, 2^64 Bytes, und eben darum auch mit solchen Adressen arbeiten kannst. Ausserdem kannst du mit Zahlen bis zu dieser Grössenordnung (unsigned 2^64, signed -2^32 < x < 2^32-1) intern arbeiten, ohne grossartig umrechnen zu muessen; auch kannst du solche Zahlen ungeteilt in den Registern abspeichern. Gleitkommazahlen werden von den NPX'en schon seit jeher mit bis zu 80 Bit dargestellt...
Abwärtskompatiblität ist uebrigens durch RISC nicht abgeschafft; ich glaube auch ein neuer m68k'ler kann m6800er Code ausfuehren.
Die Architektur ist nicht den aktuellen CPUs ueberlegen, aber die x86-Architektur ist schon 1987 gegen die Wand gefahren, dadurch, dass sie so extrem aufgebläht ist (der 8086 kann ueber 110 Befehle, ein m6800 nur 35 oder so; PMode & Co fordern auch ihren Tribut an komplexen, microcodegesteuerten und langsamen Befehlen). Aber da alle an der Kompatiblität festhalten, muss eben sowas emuliert werden.
Reine RISC-CPUs arbeiten in der Regel in Servern, teilweise Workstations und Macs. Viel mehr Anwendungen fallen mir da auch nicht ein... Macs sind dafuer bekannt (=> Marktnische, wenn ich es mal so sagen darf) und bei riesigen Firmenservern ist es eigentlich ein Muss, auch wenn x86 dafuer verwendet wird.
Man kann nicht x86 mit CISC oder RISC vergleichen, da sie inzwischen Elemente beider Ideologien enthält (einen OnChip-Emulator auf ner RISC-CPU), die Architektur wurde nur mit der Zeit und der Kompatiblität wegen versaut. Ist aber leider Standard ;)
Eine gute RISC-Architektur läuft allem anderen davon, aber CISC ist schon lange tot. Oder?
Svenska
-
danke für die infos hab es jetzt verstanden.
trotzdem würden mich noch meinungen zur cpu interessieren.
-
Im grunde sind die neuen CPUs alle RISC. Pentium und Co haben aber sog. Mikroprogramm in sich drin. Diese erkennen die x86 Befehle und führen die nötigen RISC Befehle aus um den Effekt zu erreichen. Da dies nazürlich eine Art der Emulation ist geht da natürlich einiges an Speed verloren.
RISC selber hat den gewissen nachteil, das es nur sehr wenige Befehle gibt und es daher recht umständlich ist dafür Code zu erzeugen, erst recht wenn man in ASM programmieren möchte.
-
Wobei man bedenken muss das der PowerPC, welcher als RISC CPU gilt soweit ich weiss, auch hunderte von Befehlen kennt. In dieser Liste (http://pds.twi.tudelft.nl/vakken/in1200/labcourse/instruction-set/) wurde schon gespart und 107 sind noch übrig ...
Für optimales Tempo muss man wohl eine Balance finden, aber das sollte den OS Entwickler weniger kümmern - das ist eine Aufgabe die auch eine ganze Horde von Ingenieuren komplett auslasten kann.
-
RISC = kennt wenig Befehle, ist schnell
CISC = kennt viele u./o. komplexe Befehle, ist langsamer
So würde ich das aber nicht sagen, schließlich kommt es immer darauf an, was man macht.
Im Großen und Ganzen ist de Unterschied ja, das meine Logische Einheit mehr Rechenwerke vor den MUX gespannt hat, wie bereits gesagt. (-> Größerer Befehlssatz)
Allerdings sagt das nichts über die Geschwindigkeit aus:
Wenn ich jetzt z.B. zwei Prozessoren habe, und ich will eine beliebige Zahl mit 10 multiplizieren:
Der erste Prozessor hat ein komplettes Multiplizierwerk in der ALU integriert, und der zweite tut sein Werk über einen Addierer, und einen Shifter.
Wenn wir jetzt die beiden gegenüberstellen, dann ist höchstwahrscheinlich der zweite trotzdem schneller, als der erste, obwohl er etwas primitiver aufgebaut ist.
Wenn ich jetzt aber dieselbe Zahl mit z.B. 11 multipliziere, wird mein Addierwerk sicher schneller das Ergebnis ermittelt haben.
Was ich damit sagen will: Man kann niemals sagen, welcher Prozessortyp schneller ist, es kommt immer darauf an, mit welchen mathematischen Problemen ich diesen füttere. Sind es einfache Additionen, und die Grundrechnungsarten, rennt mir mein RISC sicher davon - wenn ich jetzt aber z.B. ein Integral berechnen will, und ich bereits eine Schaltung dafür in meiner logischen Einheit habe, dann wird mir ein RISC sicherlich ein paar Takte mehr brauchen, da er diese Rechnung erst mit den Grundrechnungsarten, die er kann simulieren muss.
\topic:
Der primitivste RISC ist mir sicher zu wenig.... da beherrscht die ALU ja gerade einmal das Addieren zweier Zahlen, log. UND, und log. Negation - da kann sich ja wohl jeder vorstellen, wie schnell der Prozessor getaktet sein muss, damit in diesem Jahrhundert noch ein Ergebnis zu Stande kommt. - Aber bei einem gängigen RISC ist das ja kein Problem, der hat ja schon einen ordentlichen Befehlssatz, und kann alles was man oft braucht schnell ... und somit bin ich auch zu frieden damit.
Wenn ich jetzt komplexere Sachen berechnen muss, dann bin ich sowieso meistens mit C dabei, und da nehmen mir die Bibliotheken die Arbeit ab, und somit habe ich nicht die Scherereien etwas Hochkompliziertes in Assembler zu coden. (Ich kann ohnehin nur ein bisschen PIC-Assembler, und das ist ja kein Vergleich zu x86)
Ich bin also eher ein RISC-Freund, als CISC, nicht das ich persönlich den Unterschied als Programmierer überhaupt merken würde. ^^;
-
Also ich würde schon sagen das RISC schneller als CISC ist, vielleicht nicht von der MHz Zahl, aber von der Leistung die eine RISC CPU einer CISC CPU bei gleicher Taktung voraus hat. ISt genauso wie wenn du zwei Autos hast und das eine hat doppelt so viel PS wie das andere und kommt trotzdem nicht schneller voran, welches ist dann wohl besser ;-)?
-
Bei gleicher MHz Zahl wäre eine RISC CPU einer CISC CPU wahrscheinlich sogar unterlegen. Wobei man dann beachten muss, welche Befehle wieviele Takte brauchen.
Ausser du meinst PA-RISC und x86 ...
-
Schau mal hier nach: http://www.spec.org/
Kleines Bsp von aus dem CFP2000:
FSC PRIMNEPOWER 900 (SPARC64 2160Mhhz) 1800-2150 Punkte
HP ProLiant DL360 G4p (XEON 3,6 GHz) 1800-1825 Punkte
CINT2000:
FSC PRIMNEPOWER 900 (SPARC64 2160Mhhz) 1456-1594 Punkte
HP ProLiant DL360 G4p (XEON 3,6 GHz) 1675-1712 Punkte
Liegen ganz schön nah bei einander dafür dass der XEON eine 1,5 GHz höhere Taktung hat.
-
Wenn ich jetzt komplexere Sachen berechnen muss, dann bin ich sowieso meistens mit C dabei, und da nehmen mir die Bibliotheken die Arbeit ab, und somit habe ich nicht die Scherereien etwas Hochkompliziertes in Assembler zu coden.
ist es so viel schwieriger assambler code für die riscs zu schreiben?
-
Na ja, es kommt immer darauf an, was man machen will ...
Es wird nicht wirklich komplizierter, nur laenger. Waerend du in CISC manche Sachen mit einem einzigen Befehl geschrieben hast, musst du bei RISC halt eine ganze Befehlskette schreiben, die das selbe, wie dieser Befehl macht - wenn man also weis was man tut, sollte es nicht wirklich schwieriger sein, sondern einfach kuerzer, und schneller zum programmieren.
(In meinen fall ist es halt komplizierter, weil ich erst vor einer Woche etwas mehr in x86-assembler hineingeschnuppert habe - der Satz war also eher auf mich bezogen, allgemein gemeint.)
-
Gleich getaktete RISC's sind um ein vielfaches schneller als CISC's, weil die Befehle fest verdrahtet werden und nicht durch einen Microcode aufgelöst werden müssen. Weiterhin sind beim RISC's mehr Register vorhanden 32-128 sind Standard, also letztlich weniger Speicherzugriff was die Geschwindigkeit auch arg erhöht.
Nachteile sind eben, dass der Code sehr viel länger wird, also mehr Befehle um den selben Effekt wie bei CISC's zu haben, was wiederum heisst mehr Speicherzugriffe die den Code laden müssen. SIMD (wie MMX/SSE/3Dnow!) gibt es defacto auch nicht, müssen auch durch längere Befehlsketter ersetzt werden.
Da aber fast jeder Befehl in einem Takt ausgeführt werden kann läuft ein echter RISC einem CISC trotzdem davon. Vergleicht bloss mal die Taktraten von PowerPC(Mac) und Intel CPU's und die Leistung. PPC weniger MHZ als Intel, aber die Leistung ist definitv ebenbürtig wenn nicht gar besser.
-
Das mit den mehr Registern, gehört eigentlich nicht zur RISC-Architektur dazu, es die RISC's sind nur neuer und haben deshalb mehr Register. ;-)
die x86er sind ja abwärtskompatibel und viele weitere Register passen da nicht so richtig mit den Opcodes zusammen.
MfG
DDR-RAM
-
Das RISC Architektur CPUs mehr Register haben ist schon Teil des RISC Designs, da man Speicherzugriffe ja minimieren will und alle Befehle nur mit Registern arbeiten. Nur wieviele das letztendlich sind, ist nicht definiert.
Zum Thema mehr Register bei x86 CPUs, es gibt jetzt mehr Register, seit dem Opteron/Athlon64 stehen dem Programmierer 16 statt nur 8 General Purpose Register und 16 statt 8 XMM (SSE1/2/3) Register zur Verfügung, und es ist trotzdem noch mit altem Code Kompatibel! Ich würde mal sagen dass sich x86 immer mehr Dinge von RISC abschaut um schneller und schneller zu werden. Und es klappt! :D
-
naja, nein, es nicht wirklich kompatibel, man ist ja in einem anderen Modus, 32-bit code funktioniert nicht mit 16 registern, weder legacy mode noch compatibility mode unterstützen die 8 neuen.
Nur der longmode eben.
Und das mit den, das es nicht zum eigentlichen RISC dazugehört, hab ich von wikipedia (http://de.wikipedia.org/wiki/Reduced_Instruction_Set_Computing) :oops:
MfG
DDR-RAM
-
Oh, stimmt, naja zumindest der neue Modus unterstützt es (wie du schon gesagt hast der LongMode eben). Jetzt müssen eigentlich nur noch Real und Protected Mode wegfallen und die CPU würde günstiger und schneller werden ;-). Und wenn man nen 64bit Modus hat braucht man den Rest ja auch nicht mehr :D
-
Ich würde mal sagen dass sich x86 immer mehr Dinge von RISC abschaut um schneller und schneller zu werden. Und es klappt! :D
Ein Pentium 4 ist ein RISC-Prozessor, welcher eine x86-kompatible Architektur emuliert.
Darum ist er - verglichen mit den MHzen - so extrem langsam.
Der Pentium4-M benutzt eine andere Technik, ebenso der Centrino.
Eigentlich kann man die gesamte x86-Architektur mit Wucht gegen die
Wand knallen, aber Kompatiblität ist ja das wichtigste...Intel wollte x86
schon vor Ewigkeiten abschaffen, ist aber nichts draus geworden.
Die AMD64-Technik ist schon ein Schritt in die richtige Richtung, aber
m.M. noch nicht weit genug.
Svenska
-
Ja schon seit dem AMD K5 bzw. dem Intel Pentium Pro baut das ganze auf einen RISC Kern auf, aber mit was du am Ende den Prozessor programmierst ist CISC, eben ein komplexer Befehlssatz, und selbst wenn es nicht emuliert werden würde wäre es immer noch langsamer! Diese Emulation benutzt man nur um Kosten zu sparen, da es einfacher ist ein Programm zu ändern als Millionen Transistoren auf einem Chip neu zu verdrahten.
Achja und Centrino ist keine CPU, sondern eine Plattform bestehend aus Pentium M und sonstigem Gedöns. Und dieser ist auch wieder nur ein aufgedonnerter P3 und demnach auch ein RISC mit Emulator um zum CISC zu werden.
-
Wenn man es schaffen würde (bzw. bezahlen könnte), sämtliche Befehle
festzuverdrahten... das wäre Top. Aber es ist nicht bezahlbar, wie du
schon schriebst.
Mit Amd64 habe ich mich nicht beschäftigt, aber gibt es da immernoch
diese ganzen komplexen Befehle, die emuliert werden muessen oder ist
das auch aus programmiertechnischer Sicht inzwischen ein RISC?
Mit dem Centrino - ups :-) Ich dachte, der Centrino wäre auch ein Prozessor. Falsch gedacht...
Svenska
-
Die AMD64 CPUs sind immernoch CISCs, leider wollte AMD seinen Prozessor nicht noch radikaler umstellen (bis jetzt nur Wegfall von Hardwaretaskswitching, Wegfall der Segmentierung, mehr Register). Schade eigentlich. :)
-
Abgesehen davon das die ganzen Transistoren dafür ja immer noch vorhanden sind wegen dem Legay Modus.
Aber 128 Register zu haben hat nicht nur Vorteile. Bei einem Taskswitch müssen die ja auch alle gesichert werden ...
-
Das kann man aber sehr einfach reduzieren. Bei jedem Register ein Statusbit einführen in dem vermekrt wird, ob das Register seit dem letzten Switch verändert wurde und bei einem Wechsel nur die veränderten speichern. Wenn das auf CPU-Ebene gemacht wird wäre das schnell genug um deinen Zweifel zu entkräften.^^ (Ich sollte CPU-Designer werden^^ wer gründet ne Firma mit mir?:P)
-
lässt sich diese cpu bremse (emulieren von x86) durch speziel dafür geschriebenen code aushebeln oder macht das die cpu immer so?
lässt sich der rom speicher der cpu irgendwie verändern? (ja ich weiss das rom read ONLY memory heisst aber irgendwie müssen die den ja auch beschreiben.)
-
1. Die CPU macht das immer so
2. Ja man kann es ändern, es gab für Intel CPU's mal sowas wie kleine Microcode-Updates, aber ob man damit grössere Ãnderungen durchführen kann weiss ich nicht, wäre aber ziemlich cool.
-
noch ein paar meinungen zur risc cpu wären ganz nett.
würdet ihr euch eine holen?
wenn ja, welche?
wenn nein, warum nicht?
was haltet ihr von dem powermac G5 mit 1,35GHz frontsidebus?
-
Also ich finde PPC ganz nett. Besonders schön finde ich dass man einfach mehr Register hat. Ganzzahl sowie Floating je 32 ist einfacher zu rechnen, da man nicht ständig Zwischenwerte sichern muss.
(MAC verwendet PPC's)
-
Holen und welche: nun ja ich habe schon eine, in meinem Sharp Zaurus ist ein Intel StrongArm mit 206 MHz verbaut, und ich bin damit zufrieden, mein darauf laufendes Linux auch :D.
was haltet ihr von dem powermac G5 mit 1,35GHz frontsidebus?
Klingt immerwieder erstaunlich wie hoch bei manchen der Frontside Bus geht, aber das Athlon64 FX-53 hat noch mehr (1600MHz HT-Bus).
Wer es unbedingt braucht sollte es sich holen. Ich tue es nicht weil ich kein MacUser bin ;-)
-
@ Roshl: AMD64 hat auch mehr Register! Lieber beim PC bleiben als zu den Maccies zu wechseln (meine Meinung)
-
ich würde ja nicht zu den macs wechseln weil sie mac heissen sondern wegen der (meiner meinung nach) besseren cpu.
ausserdem fange ich gerade erst damit an mich intensiv mit cpus und programmierung(kann ich nicht mal) zu beschäftigen und möchte deshalb eine solide grundlage haben.
sowohl vom wissen als auch von der hardware.
-
Naja auch mit Hard- und Software Unterstützung hängen Macs gut hinterher, bsp: Vor einiger Zeit bin ich an etwas Mac Hardware gekommen, einen PowerMac G3, nur ohne Tastatur, Maus, Bildschirm. Ich hab dann Wochenlang versucht irgendwo Adapter herzubekommen um mein normales Equipment anzuschließen, hat aber leider nich geklappt, jetzt habe ich nur noch die CPU bei mir an der Wand hängen :)
-
haben die für alles eigene (externe) schnittstellen? oder wie ist das zu verstehen?
software unterstützung wäre egal würde mac os höchstens zum zocken bzw multimedia verwenden. will linux drauf machen und dann meine eigenen programme schreiben bzw lernen wie man eigene programme darauf schreibt.
-
Das die Hardware untereinander nich kompatibel ist, ist doch wohl klar.
AMD64 hat auch nur 16 Allgemeine Register und 16 XMM Register.
Es sind ja nicht nur die Registeranzahl, auch die Architektur selbst ist viel besser und einfacher, nicht so verkorkst mit Abwärtskompatibilität wie bei Intel.
-
Von Intel gibts auch eine 64Bit Architektur die noch mehr richtung RISC geht als AMD64
http://en.wikipedia.org/wiki/IA-64
Allerdings will Windows diesen Prozessortyp nicht unterstützen deshalb wird er sich wohl kaum durchsetzen ....
-
IA-64 hat Intel schon vor einiger Zeit aufgegeben, weils nicht erfolgreich war. Lag unter anderem an der fehlenden Abwärtskompatibilität, die wir Entwickler doch schon lange verfluchen^^
-
Und es gab keine IA-64 CPU die ein "Normalsterblicher" sich einfach hätte leisten können - dafür sollte es ja weiter hin 32-Bit x86 geben.
-
Intel hat sich einfach mal von AMD überholen lassen im Desktop-PC-segment
Jetzt müssen sie sehen, wo sie bleiben :twisted:
MfG
DDR-RAM
-
Na ja, im Desktopsegment verdient man nicht direkt - aber könnte ne Architektur durchsetzen! ;)
-
Das mit der Abwärtskompatibilität ist beim PowerPC ja so eine Sache, der hat nunmal keine 30 jährige Geschichte hinter sich, dennoch wurde er so designt, das man 68k Code gut emulieren kann, damit die Software der ersten Macs auch darauf läuft, denn die hatten komplett andere CPUs.
Intel hat das bei der IA-64 auch versucht, war leider viel viel zu langsam. obwohl es eigentlich geht. Der Transmeta Crusoe / Efficeon ist genau wie der Itanium von Intel ein VLIW Processor, aber die Code Morphing Software setzt den Code so gut von x86 um, dass man die Dinger mit Software im ROM als x86 Prozessoren kaufen kann ;-)
-
Ich fände nen Prozessor geil, der x86 und PowerPC Code auf einmal emulieren kann ;D
-
Was haltet ihr von Transmeta? Das ist eine Firma die auch irgendwie CPUs herstellt. So weit ich mich erinnern kann arbeitet da Linus Torvalds, als Programmierer für x86-Emulationen etc.
-
ich hab gehört das er mal da gearbeitet hat und jetzt wo anderst arbeitet, kanns aber au net sicher sagen.
die chips von transmeta sind zu 3/4 software und zu 1/4 hardware. mit ihnen soll man jede beliebige architektur emulieren können.
-
Linus Torvalds arbeitet nimmer bei Transmeta sondern bei so ner Open-Source-Gruppe.
-
Linus Torvalds arbeitet nimmer bei Transmeta sondern bei so ner Open-Source-Gruppe.
Wieder was gelernt :wink: In meiner Just For Fun Ausgabe (3. Auflage, September 2003) schreibt er auf, dass er bei Transmeta arbeitet.
die chips von transmeta sind zu 3/4 software und zu 1/4 hardware. mit ihnen soll man jede beliebige architektur emulieren können.
Das hat doch ASC gemeint, also gibts wirklich sowas. Soweit ich weiß sind das auf jeden Fall RISC-CPUs, bei denen der Emulator die Befehle von nem x86 z.B. in die eigenen Befehle umwandelt.
-
in der 4. auflage dezember 2004 schreibt er au noch das er bei transmeta ist.
-
Em, der Crusoe und der Efficeon von Transmeta sind KEINE RISC CPUs, das sind VLIW CPUs, das ist leicht etwas anderes (genau wie die Itaniums von Intel) ;-)
-
Ich weiß, dass es mit den Transmeta-Teilen möglich wäre, aber ich glaube, dass es momentan nur welche gibt die x86 emulieren und keinen der x86 und PowerPC emuliert ;)
Unter anderem Wikipedia (http://de.wikipedia.org/wiki/Linus_Torvalds) schreibt:
Er arbeitete von Februar 1997 bis Juni 2003 bei Transmeta und ist jetzt beim Open Source Development Lab (OSDL) angestellt, um hauptberuflich an der Weiterentwicklung des Linux-Kernels zu arbeiten.
-
hmm will keiner mehr was zu der cpu oder den macs sagen?
ich hätte gerne soviele meinungen wie möglich bevor ich mich entscheide.
-
Mac's benutzen RISC CPU's, das ist alles, was dieser Faden hergibt.
Es gibt noch Dutzende anderer (veralteter) RISC-CPU-Typen, die keiner (mehr) kennt.
Einen Mac wuerde ich mir wahrscheinlich nur kaufen, wenn er preislich viel tiefer geht als Intel. Ich lege mich mit beiden (Mac und PC) auf einen Hersteller fest (entweder die Ãpfel oder die IntelMiniweicher) und fuer letzteres gibt es einfach mehr Software. Wenn du Spiele spielen willst, dann bist du mit Windows mindestens zehnmal besser bedient; zum reinen Arbeiten sind beide Plattformen etwa gleich gut. Wenn es um Rechenintensive Sachen wie Bildbearbeitung im Extremen, Videobearbeitung, 3d-Raytracing und solche Sachen geht, wuerde ich zum Mac raten. Ansonsten - nun ja, entscheiden musst du selbst - empfehle ich PCs-kompatible.
Es geht nicht nur um die CPU bei Macs, sondern auch um das Betriebssystem, die Anwendersoftware, die Treiber(-probleme) und das gesamte Arbeiten ueberhaupt. Die Anwendungen fuer Mac sind duenner gesäht; die Qualität ist bei Standardsoftware identisch (bzw. es gibt Ports). Bei exotischen Sachen sieht es anders aus.
Wegen der CPU alleine wuerde ich mir keinen Mac kaufen :-)
Ach ja @OffTopic-Thema hier:
Sun hat ja ne CPU entwickelt, welche Java ausfuehren kann. :-) Wäre das nicht mal was anderes? So eine CPU, welche Basic direkt ausfuerht oder sowas *g*.
Svenska
-
ich hab mir angesehn welche spiele es für den mac gibt und habe festgestellt das es alle spiele gibt die mir gefallen.
natürlich weiss ich das es noch andere risc cpus gibt. aber wie soll ich an die ran kommen (geld). der mac scheint mir ein gutes preisleistungsverhältniss zu haben. vorallem die technik finde ich gut.wie schon gesagt will ich eine solide grundlage, denn irgendwann müssen amd und intel ihre kompatibilitätspolitik aufgeben (irgendwann sind die transistoren so klein dass sie keinen strom mehr leiten) und dann wird die risc architektur ausgebaut werden. meiner meinung nach ist risc (seit 10 jahren) die zukunft.
-
ich hab mir angesehn welche spiele es für den mac gibt und habe festgestellt das es alle spiele gibt die mir gefallen.
Wenn der Rest auch stimmt, dann nimm ihn doch :-)
natürlich weiss ich das es noch andere risc cpus gibt.
Aber du beziehst dich ausschliesslich auf den Mac.
wie schon gesagt will ich eine solide grundlage, denn irgendwann müssen amd und intel ihre kompatibilitätspolitik aufgeben
Das wird wahrscheinlich noch ein paar Jahrzehnte auf sich warten lassen, wenn ueberhaupt. Der "Aufsatz" des PM '91/92 war ein Tribut an die schon damals 10 Jahre alte Technologie des 8086 (und damit auch den Vorgängern 8085/8080). IA64 hat sich eben wegen der fehlenden Kompatiblität nie durchgesetzt und AMD64 ist ebenfalls vollständig kompatibel zum x86. Mit dem rechten Assembler läuft auch 8080-Code unverändert. Das sollte ein bisschen zum Denken geben. IMHO muss, bevor Intel die x86-Architektur aufgibt, noch einiges geschehen. Und kurz gesagt; diese Konkurrenz ist der Mac nicht.
(irgendwann sind die transistoren so klein dass sie keinen strom mehr leiten) und dann wird die risc architektur ausgebaut werden. meiner meinung nach ist risc (seit 10 jahren) die zukunft.
RISC ist die Zukunft und auch schon eine Weile die Gegenwart. Ein PPro ist ein RISC-Prozessor, welcher nen x86 im gewissen Sinne emuliert. Reines CISC ist schon lange tot. Ob die Zukunft aber Mac ist, weiss keiner und ich bezweifle es. Solange wie Macs ausschliesslich von Apple kommen, wird es eine Nischengeneration sein - egal, wie viel schneller es ist.
Einen Mac wuerde ich mir als Arbeitstier anschaffen wenn spielen nur zweitrangig ist. Fuer alle anderen Sachen ist x86/win32 schon allein aufgrund der verfuegbaren Software besser. Es gibt halt fuer Macs nur Standardsoftware, alles was mehr ins Exotische geht, gibt's nicht oder nur enigeschränkt. Und ne Software-Emulation ist zu langsam und nicht zu 100% effektiv. Wenn es so wäre, könnte VMware ein OS/2 emulieren, Bochs hätte keine Bugs etc.pp.
Wenn du dir einen PC anschaffen willst und den ohne Unterbrechung die nächsten 10 Jahre benutzen willst... das glaube ich nicht. Auf die Entfernung kann man die Entwicklung nicht absehen. Vor 10 Jahren kam der Pentium, der hatte "läppische" 133 Mhz. Heute haben wir vielleicht das 35-fache und eine neue Architektur. Wenn man so weiterrechnet, haben wir in weiteren 10 Jahren eine Architektur, welche dem AMD64 Konkurrenz macht und Geschwindigkeiten... von vielleicht 100 Ghz (reine Spekulation). Und dann macht es erst Recht wieder Sinn, sich nen neuen Rechner anzuschaffen.
Rechner veralten heutzutage in 2 Jahren, wer muss (Geldfrage), kommt etwa 3-6 Jahre damit aus. Was dann kommt, kann keiner vorhersehen.
Svenska
-
ich beziehe mich ausschließlich auf den mac, weil er der einzige mir bekannte computer mit risc cpu ist der erschwinglich ist (für mich).
meiner meinung nach ist der risc die zukunft und wird intel und amd ablösen. vermutlich werden dann riscs mit pipes für jeden befehl kommen und danach (in einer weit weit entfernten galaxie) der quanten computer. das alles ist nur eine theorie.
noch mehr meinungen würde ich begrüssen.
-
ich bin da nicht so optimistisch. das ende von intels 8086 cpus wird seit 20 jahren vorhergesagt. die 8086 cpu war schon von anfang an scheisse designed, der 386er hat dann den ganzen dreck von dem 8086er übernommen und dann noch ein bisschen was 32bittiges dazu gepopelt. (wem erzähl ich das? das wisst ihr ja alles...) der sollte bloß eine zwischenlösung sein und durch eine bessere cpu ersetzt werden. (afaik i860)
bloß blöd wenn da firmen wie microsoft kommen und diese eine architektur quasi aus tradition pushen und dafür sorgen, dass diese sich durchsetzt. ich sehe keinen grund warum microsoft in den nächsten jahrzehnten aufhören sollte, auf die x86-(64-)architektur zu setzen und sein windows alle paar jahre in einer "verbesserten" version rauszubringen. und solange microsoft seine dominante marktposition beibehält wird auch die x86-(64-)architektur weiterhin nicht vom thron zu stoßen sein.
[edit] wobei linux nett am windows-thron nagt, der firefox den IE in zugzwang bringt und die EU den windows media player nicht mag. also bewegung wäre da möglich, aber ich glaube kaum, dass es besonders schnell gehen wird. und microsoft hat immer die möglichkeit nachzuziehen und die architektur zuwechseln. das know-how (windows NT für x86, alpha, MIPS, PowerPC, und was es nicht alles gibt) haben sie und das geld auch. microsoft wird man einfach nicht los ...
hm, ich komme vom thema ab. ich kürze mal ab: es gibt einen marktführer und der sagt, wo es technologisch langgeht und wir müssen ihm (meist) folgen, denn er gibt einerseits mit seinen investitionen die preise vor, anderseits muss man aufpassen, dass man bei seinem "alleingang" nicht auf der strecke bleibt...[/edit]
der mac scheint mir ein gutes preisleistungsverhältniss zu haben.
sicher? der günstigste powermac (1,8GHz PowerPC G5, 256MB RAM, 80GB HD, GeForce FX 5200 Ultra 64MB) kostet 1389 euro. die cpu kann ja meinetwegen in ordnung sein, aber ram, festplatte und grafikkarte können diesen preis nicht rechtfertigen... und die anderen macs sind kaum besser: der eMac ist veraltet, die iMacs sind fast genauso teuer, und mac mini ist schwul (und nicht gerade ein kraftprotz) ...
wenn du zu viel geld hast, kannst du gerne einen mac kaufen. gerade die neuesten dual-g5 macs sind hammergeil. mit einem solchen gerät erwirbst du eine mordsmaschine, die ordentlich abgeht. bloß die sind mit 1900 bis 2800 Euro auch dementsprechend teuer.
-
Um mal vom PowerPC weg zu kommen, klar gibt es andere erschwingliche RISC CPUs. Wie z.B. ARM (StrongARM,XScale,...) , die sind in fast jedem PDA verbaut, und Cracks können daruaf sogar Linux installieren und laufen lassen ;-). Kostenpunkt: ab 200â¬, wenn nicht gar billiger (soviel hat meiner gekostet).
-
Um mal vom PowerPC weg zu kommen, klar gibt es andere erschwingliche RISC CPUs. Wie z.B. ARM (StrongARM,XScale,...) , die sind in fast jedem PDA verbaut, und Cracks können daruaf sogar Linux installieren und laufen lassen ;-). Kostenpunkt: ab 200â¬, wenn nicht gar billiger (soviel hat meiner gekostet).
Dann gibt es auch noch die AVR-Reihe(n) von Atmel (die sind zwar langsam und 8bitter, aber trotzdem RISC)
und das Linux ist denke ich das ucLinux (ich hab jetzt keine Lust, das grieschiche Mikro-Zeichen zu suchen). Das gibts für viele CPUs ohne Speicherverwaltung.
-
@urx: probier mal alt gr + m. Da kommt ein µ raus ;-)
-
[8086]der sollte bloß eine zwischenlösung sein und durch eine bessere cpu ersetzt werden. (afaik i860)
Der 8086 sollte ne Kompatiblität zum 8085 und damit auch dem 8080 herstellen, beides niedliche schwarze Wolken in der duesteren Rechnervergangeheit :-)
In meinen Augen hat der Mac das Zeug, x86 & Win vom Thron zu klopfen. Aber unter der Bedingung, dass es offizielle und legale Nachbauten auch von anderen Herstellern gibt, der Mac somit offengelegt wird. Und das wird noch eine lange Weile - ich möchte nicht behaupten ewig - dauern. Denn Apple möchte sich ja die eigene gute Erfindung nicht aus den Fingern reissen lassen und Mac soll ein Synonym fuer "schickes Appleteil" sein... zu guten Preisen.
Wenn du Risc willst, hast du viele Möglichkeiten. Wenn du etwas zum Arbeiten und Surfen brauchst und unbedingt einen Mac willst, ok. Ansonsten rate ich dir zu x86. Aus bekannten Gruenden.
...und ein Athlon64 ist schon mehr Risc als manche vielleicht zugeben möchten.
Svenska
-
Nachdem sich Apple nun offiziell von dieser Architektur trennen wird gibt es ja nicht so viele im Desktop Bereich. Ich hab allerdings zu meiner grossen Überraschung erfahren, dass der gute alte Amiga einen offiziellen (AmigaOne/AmigaOS) und inoffiziellen (Pegasos/MorphOS) Nachfolger hat, wobei es sich um einen PowerPC handelt, was ja weniger überraschend ist. Leider sind sie nur abwärtskompatibel (im Kernel wird der m68k Code emuliert und ich glaub AmigaOS 3.9 läuft auf beiden nativ), jedoch nicht untereinander.
Der Pegasos würde allerdings als allgemeiner PowerPC designed, auf dem deshalb relativ viele Betriebssysteme nativ laufen. Er wird übrigens auch offiziell von Gentoo, einer sehr gute Linux Distribution, supported und mit einer eignen Workstation vertrieben.
Leider ist das beim AmigaOne ganz anders. Bei seinem Design wurde sich ausschliesslich auf AmigaOS konzentriert, und tatsächlich sollen auch wenige OSes auf der Maschine laufen, sogar mit Linux soll es Probleme geben.
Beide System haben allerdings doch noch etwas gemeinsam: sie bestehen mittlerweile wieder aus bereits veralteter Hardware (um 2002/03 erschienen) und sind keine Schnäppchen. Bei beiden System handelt es sich wahlweise um einen G3 oder G4 bis maximal 1,1 GHz (glaub ich).
Naja, gehört halt Herzblut dazu, sind beides keine Vernunftsysteme. Für einen Linux User könnte es aber interessant sein, wenn er einen PPC programmieren will. Und ganz nebenbei (oder gerade deswegen) hat man noch einen neuen Amiga.
Ich überlege tatsächlich mir so ein System zuzulegen. Allerdings kann man nicht voraussagen, ob sie sich weiterentwickeln werden. Würde Apple nicht wechseln, hätte ich mir zum programmieren ein billiges G3 IBook mit orangen Case besorgt (mach ich bestimmt noch), aber vorerst ist Apple/MacOS für mich uninteressant.
Auf dem Amiga 500 hab ich früher mit dem DevPac Assembler ein wenig programmiert, aber so gut wie alles verlernt. Den Wechsel zu x86/TASM fand ich interessant und Asm kam mir auch leichter vor, lag aber bestimmt an der Erfahrung. Je mehr ich allerdings über Codeoptimierung gelernt habe (was ich eigentlich am coolsten finde), desto weniger bin ich vom x86 begeistert. Ausserdem hab ich festgestellt, dass ich selten einen Befehl verwende, den es bei DevPac in ähnlicher Form nicht gab. Natürlich sind die zusätzlichen Befehle cool, produzieren aber oft mehr Opcode, was sie für innere Schleifen uninteressant macht, und deswegen entberlich. Auch das Little Endian ist bei mir immer wieder ein zuverlässiger Grund für Bugs.
Übrigens gibt es einen PPC Emulator für x86, den PearPC, über dem man man sogar MacOS benutzen kann (ist ja bald unnötig).
Für Assembler Freaks und Hardwarebastler ist es bestimmt ein Abenteuer, RISC kennenzulerenen. Für Desktop User nur ein etwas teuereres Hobby.
-
Aus der Sicht des Programmierers macht es wenig unterschied ob RISC oder CISC. Zumindest für gute(!) Programmierer dürfte es keine Schwierigkeit darstellen die etwas komplexeren CISC-Befehle in einige wenige RISC-Befehle zu zerstückeln.
Ob Little oder Big-Endian ist letztlich egal, man muss nur wissen was grade vorliegt.
Das die zusätzlichen Befehle wie du sie nennst mehr Opcode produzieren ist eigentlich nicht richtig, im Gegenteil sie reduzieren eher die Menge an Bytes weil nicht mehrere Befehle Codiert werden müssen, die z.b. die selben Register bearbeiten, so gibt man das Register nur einmal an, was letztlich Grössenreduzierend wirkt (wirken kann).
Allerdings ist bei Prozessores alles relativ und nur unter bestimmten Bedingungen richtig. Wer dämlich Programmiert produziert das 3-fache an Code wie ein guter Progger, das heisst aber nicht, dass kürzerer Code schneller ist, wenn der grössere für den Prozessor besser zu parallelisieren und zu verarbeiten ist.
x86 ist keine schlechte Architektur, ist allerdings Verbesserungswürdig, durch diese elende Abwärtskompatibilität die mitgeschleift werden musste (man hatte da eigentlich kaum eine Wahl) hat sich vieles Arg verkompliziert. Man könnte einiges an Transistoren und somit Kosten für Herstellung und Betrieb sparen, würde man den RealMode einfach wegtreten, der eh nicht mehr benutzt wird. Ãhnlich die Deskriptoren die wegen dem 286er-PM ziemlich verkorkst und zerstückelt sind, sollten aufgeräumt werden->Transistorenabnahme.
Da gibt es viele Dinge die man weglassen könnte und aus Sicht der Programmierer wäre das einfach nötig.
-
Du hast natürlich recht, dass ein spezieller Befehl in der Regel weniger Opcode produziert, als dafür eine alternative zu programmieren. Der von ihnen produzierte Opcode ist dennoch oft grösser, als die prozessoreigenen viel benutzten Befehlen (ich mein damit jetzt mov, add, xor und so, die es ja auch bei RISC gibt).
In einer inneren Schleife, den am stärksten zu optimierenden Codeteilen, sollte der Code leicht zu verarbeiten und kurz sein. Leider trifft beides auf einige (viele) dieser Befehle nicht zu, weshalb man versuchen sollte sie aus der inneren Schleife zu halten. Wenn es aber nicht besser geht, dann sollte man sie benutzen - (mal mehr oder weniger) oft geht es halt besser, und deshalb sind sie für mich entberlich und eigentlich nur Luxus (aber nett). Naja, Codeoptimierung ist ein eigenes Buch und will es mal dabei sein lassen, wollte nur noch etwas genauer formulieren was ich eigentlich meine.
Ich möchte die Architektur des x86 nicht schlecht reden, sie hat eben ihre eigene Philosophie mit eigenen Vorteilen, sowie RISC, aber für eine radikale Überholung nach deinen Vorschlägen ist es wirklich Zeit, solange bleibt RISC eleganter. Welchen Typ man lieber programmiert muss jeder selbst herausfinden.
RISC findet man ausserdem überall, wo man es nicht erwartet. Wer also mehr als nur seinen PC programmieren will, sollte deshalb diese CPU zu programmieren lernen.
btw.: mit Big Endian zu arbeiten finde ich effizienter, vor allem beim debuggen.
-
Big Endian ist bei der Netzwerkprogrammierung effizienter, da zumindestens einige Sachen dort Big Endian sind, da sie interoperabel sein wollen (und man sich dann nicht auf Little Endian festgelegt hat).
-
Bei RISC haben meistens OpCodes allerdings eine feste länge um das decoding zu erleichtern, meine ich mal irgendwo gelesen zu haben. und die muss so gross sein, um die maximale auslastung aufnehmen zu können, obwohl viele so viel nicht brauchen werden->Platzverschwendung
-
Die RISC-Decodierung überspringt damit den Schritt die Adresse des nächsten Befehls zu errechnen, und fäng sofort mit dem decoden an -> Geschwindigkeit.
-
Genau deswegen sind auch kleine opcodes nicht möglich, braucht einer 15 Byte muss auch einer der eigentlich nur 1 benötigt auch auf 15 erweitert werden
-
Nun, 15 Byte sind übertrieben und falsch, alle PowerPC befehle sind 4 Bytes gross. Es gibt 60 Stück, sie sind mit der CPU hardwired, weshalb die Dekodierung so schnell ist. RISC besitzt auch mehr Register, was weitere Geschwindigkeitsboni bringen kann.
Hier kommt halt die ursprüngliche Philosophie zum vorschein: schnell und gross, oder kompakt und langsam.
Ich hab mit Assembler angefangen, weil ich schnellen, optimierten, hardwarenahen Code programmieren wollte, Spiele und Demos eben. Die Opcodegrösse ist mir dabei nicht so wichtig, da der Assember generierter Code selbst schon um ein vielfaches kleiner als Compilierter ist.
Aber heutzutage sollte man diese radikale Aufteilung von Speicher oder Geschwindigkeit sowieso neu überdenken; beides ist seit der Einführung der CPUs absolut utopisch geworden. Die zentrale Frage ist heute eine des Geldes. CISC ist billiger als RISC (nur wegern der Marktlage), aber verbraucht mehr Strom, weshalb sich RISC langfristig auszahlen kann.
Mal nebenbei: wenn in China sich Home-Computer so etablieren wie in Deutschland, haben sie mit CISC ein Versorgerproblem.
-
4-Byte kann garnicht stimmen
mov R0,dword
da braucht das dword schon allein 4 byte dann 1 byte fürs register ein für den opcode.
Also es sind mit sicherheit mehr als 4 byte die ein befehl brauchen wird.
15 war nur ein Bsp, weil ich glaube auf x86 ist der längste Befehl 15 Byte gross ka welcher das war
(Zu einem Befehl zählt nicht nur der Opcode selbst, sondern auch die Ziel und Quelloperanden)
-
Jein,
... ein Befehl besteht immer aus 4 Byte, das ist beim PPC Fakt. Ist der eingelesen, werden zum PC (Program Counter) 4 (Byte) addiert, dann wird diese Adresse eingelesen, usw. Ein Befehl sagt dabei der CPU wie sie zu arbeiten hat. Ein Befehl wie add r2,r1,r0 ist hardwired (d.h. fest verlötet) und belegt demnach 4 Byte. Wird für die ordentliche Ausführung eines Befehls zusätzlich Daten benötigt wie bei li r0,666, dann sind die in den folgenden 4 Bytes des Datenbusses, und der PC wird nochmals um 4 erhöht.
-
Wenn ein Befehl nur Register betrifft mags ja stimmen. Braucht er aber noch weitere Werte und die zähle ich eben mit dazu...
-
Okay, mal was ganz anderes, hier ein kleiner Denkansatz (ist eigentlich doch ziemlich verblüffend):
Angenommen ihr habt eine CPU die genau nur eine einzige Instruktion beherrscht, nennen wir sie Substract And Branch On Less Then Zero.
Die nimmt dann 4 Parameter,
Wert A, Wert B, Ergebnisregister und Branchoffset.
Die Werte A oder B können aber immerhin noch Register oder feste Werte sein.
Wie weit denkt ihr würdet ihr kommen so was zu programmieren?
-
Okay, mal was ganz anderes, hier ein kleiner Denkansatz (ist eigentlich doch ziemlich verblüffend):
Angenommen ihr habt eine CPU die genau nur eine einzige Instruktion beherrscht, nennen wir sie Substract And Branch On Less Then Zero.
Die nimmt dann 4 Parameter,
Wert A, Wert B, Ergebnisregister und Branchoffset.
Die Werte A oder B können aber immerhin noch Register oder feste Werte sein.
Wie weit denkt ihr würdet ihr kommen so was zu programmieren?
hm, mit dem befehl kann man ja nicht soviele sachen machen -_-
man müsste immer darauf achten, das jetzt nicht irgendwo hinspringt, man muss den vorhergehenden wert des registers/speicherstelle kennen, um einen neuen wert zuzuweisen, hardware kommunikation nur über speicher (ok, eigentlich kein echtes problem ^^)
keine unterscheidung zwischen signed und unsigned, bzw. immer signed
ich hatte schon angefangen, mir den kopf zu zerbrechen, damit was anzufangen, habe es aber wieder aufgegeben :D
(zu spät, keine lust, etc. )
wenn du damit nen simplen algorithmus formulieren kannst, dann schonmal RESPEKT ;-)
MfG
DDR-RAM
-
int k = 0;
for (int i = 0;i < 200;i++) {
k += i*i;
}
Sollte sich damit z.B. schon machen lassen! ;)
Hier mal ein paar grobe Anmerkungen, falls jemand will kann ich auch mal probieren das in "Assembler" zu schreiben! ;)
Wenn er nicht springen soll, springt er im Zweifelsfall zum nächsten Befehl.
Man kann auch 0 abziehen, um zuzuweisen.
Genausogut kann man von 0 abziehen und das Ergebnis dann von etwas anderem abziehen, effektiv also addieren.
Die Schleifenbedingung kann ich ja als 199 - i schreiben, das springt dann wenn i = 200 ist.
Das Goto wenn i < 200 ist, kann ich ja als 0-1 schreiben, das ist immer negativ - das muss ich leider nur in ein unbenutztes Register schreiben! ;)
Und na ja, bei Integern kann ich ja statt "richtig" zu multiplizieren auch wiederholt in einer for schleife addieren! ;)
Wohl nicht sehr effizient, aber damit kann man schon ziemlich viel machen! ;)