Sind Pentiums "echte" RISC-Prozessoren [Archiv] - Seite 2

Haarmann

2007-09-08, 13:03:54

Gast

So sehr der Ansatz zu begrüssen ist Plattformunabhängig zu werden, so sehr muss imho dieser Ansatz scheitern - gerade an den unterschiedlichen Plattformen und deren grundlegenden Fähigkeiten. Es braucht mehr, denn eine Hochsprache und damit landen wir meiner Ansicht nach bei einer KGV Problematik.

C Syntax ist mir zudem ein Gräuel und viele grundlegende Konzepte, die damit einhergingen find ich gauenhaft und erkenne Fehleranfälligkeiten, die ich vermieden hätte. Die Syntax zumindest ist allerdings sehr Subjektiv.
Und es ist keineswegs nur einfacher denn ASM, denn bei einer ansprechenden Plattform, womit sich Intel ausschliesst, holt man sich mit C auch das Problem des Optimierens auf die Plattform ins Haus - das ist ein Problem jeder Abstraktion - dies darf nun auch noch gelöst werden.
Und ein zusätzliches Level der Abstraktion ist nicht für jeden Menschen eine Vereinfachung, sondern nur für die, welche ohne dieses Level überfordert sind - für die Anderen, imho eine kleine Minderheit, ist dies keine Vereinfachung, sondern bewirkt das Gegenteil.

(del)

2007-09-08, 13:41:29

So siehts aus, Haarmann.

Nur, das wichtigste Problem' hast du aber auch schon angesprochen. Es ist einfacher einem Menschen vernünftig C beizubringen als Asm. Sonst wären die Asm-Progger nicht eine wesentlich kleinere Gruppe. Damals wie heute. Selbst auf dem Amiga war SAS/C eine Offenbarung.

Es ist für den Menschen auch einfacher bereits mittelgroße Projekte in C besser zu überblicken. Wäre jeder so drauf wie 'Data' von StarTrek, wäre das alles kein Problem.
Deswegen werden in allen anderen RL-Bereichen komplexe Probleme von Teams und Gruppen 'bearbeitet'. Irgendwannmal mit einer steigenden Komplexität wird es zuviel für nur ein Gehirn. Da fängt beim Programmieren der Tanz oft schon bei 10MB Asm-Kode an. Und das ist kompiliert nicht wirklich die Welt.
Ohne C & Co hätten viele gute Einmann-Projekte keine Chance haben.

Die Gruppe die etwas sehr gutes in Asm hinklatschen kann und konnte war eben immer wesentlich kleiner als der Rest. Im Umkehrschluß würde das bedeuten, daß die Softwarelandschaft ohne C & Co heute wesentlich ärmer wäre. Auch wenn es damit weniger Kode-Schrott geben würde (wirklich?)
Trotzdem hat sich C wegen "Preis/Leistung" doch gelohnt. Und nicht umsonst gibts ja noch den Inliner. Die Möglichkeiten sind also nach wie vor alle gegeben.
Und Frontends? Bei heutigen Umgebungen ist es selbst so eine GUI wie die von Winrar in Asm zu programmieren eine unnötig vergeudetet Lebenszeit.

Ich weiß nicht, ob der von mir vorher angesprochener Firefox in Asm schon bereits da wäre wo es heute ist und ob es weniger Bugs hätte. Bezweifle ich mal. Und auch, ob es flinker als zB. das hier wäre http://marilab.hp.infoseek.co.jp/buildfx/index_en.html (es gibt einige von solchen Projekten) Hier sind schon die relevanten Teile entweder in C nochmals und nochmals optimiert oder direkt in Asm. Um selbst diesen nicht allzugroßen Optimierungen die nötige Reife zu verpassen brauchte es aber paar Jährchen und eine internationale community. Und da sind echt nur x86 cracks bei.

Dazu kommt wiederum, daß Safari, so verbuggt es noch sein mag und für viele auch recht funktionsarm, trotzdem noch eine kleine Ecke schneller ist als so ein Firefox. Und da :rolleyes: ist imho nichts in Asm programmiert (?)

Grundsätzlich ist es also kein Problem der Ersatzlösung. Wenn man das ehrlich vertieft, ist nicht C die Seuche, sondern wie immer der Mensch ;)

Wie intuitiv der Syntax ist und wie man ihn vernünftig benutzt spielt keine Geige, wenn man das einmal vernünftig lernt und benutzt. Die Seuche ist nunmal der Mensch. Es gab und gibt genug Rumgehacke auch in Asm.

Gast

2007-09-08, 13:48:14

(del)

2007-09-08, 13:50:42

Sorry, aber das kaufe ich dir einfach nicht ab.Was gibts hier zu überlegen? Abstraktion kommt von abstrakt. Hast du noch nie behauptet, etwas kommt dir ziemlich abstrakt vor? :rolleyes:

Gast

2007-09-08, 14:04:26

Was gibts hier zu überlegen? Abstraktion kommt von abstrakt. Hast du noch nie behauptet, etwas kommt dir ziemlich abstrakt vor? :rolleyes:
Wenn man aber vor der Aufgabe steht einen Algorithmus zu implementieren dann kann diese leichte Abstraktion einfach nur vereinfachen. Warum sollte man sich mit low level zeug rumärgern, wenn man in C einfach nur mir for, if, while etc direkt formulieren kann was man eigentlich will?

Aquaschaf

2007-09-08, 14:09:10

C Syntax ist mir zudem ein Gräuel und viele grundlegende Konzepte, die damit einhergingen find ich gauenhaft und erkenne Fehleranfälligkeiten, die ich vermieden hätte.

Beispiele? Vor allem für Fehleranfälligkeiten die Assembler nicht genauso hat...

Und ein zusätzliches Level der Abstraktion ist nicht für jeden Menschen eine Vereinfachung, sondern nur für die, welche ohne dieses Level überfordert sind - für die Anderen, imho eine kleine Minderheit, ist dies keine Vereinfachung, sondern bewirkt das Gegenteil.

Das ist die zweitgewagteste Behauptung die ich seit langer Zeit gelesen habe. Es kommt doch auf den Umfang an. Egal für wie schlau sich jemand hält wird auch für ihn C ab irgendeiner Codemenge angenehmer weil es kompakter ist.

Gast

2007-09-08, 14:14:11

Assembler ist doch ganz klar sehr viel fehleranfälliger, darüber muss dann doch gar nicht diskutieren.

(del)

2007-09-08, 14:17:16

Nein. Der überforderte Mensch ist fehleranfälliger.

Gast

2007-09-08, 14:18:39

So sehr der Ansatz zu begrüssen ist Plattformunabhängig zu werden, so sehr muss imho dieser Ansatz scheitern

Er ist aber nicht gescheitert, da Betriebssysteme wie Unix oder Windows auf verschiedenen Plattformen laufen (im Falle von Windows eher liefen).

Gast

2007-09-08, 14:19:44

Nein. Der überforderte Mensch ist fehleranfälliger.
Aber deswegen schafft man ja Programmiersprachen (bzw Assembler, welches ja nur eine besser lesbare Abstraktion von "echter" Maschinensprache ist).
Oder soll jeder jetzt seine Programme in 0 und 1 schreiben?

Gast

2007-09-08, 14:20:21

Das ist die zweitgewagteste Behauptung die ich seit langer Zeit gelesen habe.

Das ist eben typisch Haarmann, hauptsache alles ganz anders sehen als jeder andere. Nur alleine des Oopportunismus Willen.

Gast

2007-09-08, 14:24:24

Und ein zusätzliches Level der Abstraktion ist nicht für jeden Menschen eine Vereinfachung, sondern nur für die, welche ohne dieses Level überfordert sind - für die Anderen, imho eine kleine Minderheit, ist dies keine Vereinfachung, sondern bewirkt das Gegenteil.

Aber na klar Haarmann, und du siehst dich mal wieder bei der kleinen aber feinen elitären Minderheit. Dir ist aber schon klar, dass alle relevanten OS Funktionen eine Abstraktion sind? Aber du würdest natürlich wieder ganz zurück, wo es noch kein präemptives Multitasking gab, Programme im priveligierten Mode laufen und anscheinend alle noch durch eigenen Programmcode auf die HW zugreifen, um die einfachsten Dinge wie Dateioperationen usw. zu machen?!

(del)

2007-09-08, 14:29:24

Aber deswegen schafft man ja Programmiersprachen (bzw Assembler, welches ja nur eine besser lesbare Abstraktion von "echter" Maschinensprache ist).
Oder soll jeder jetzt seine Programme in 0 und 1 schreiben?Hast du eigentlich nichts davon mitgekriegt was ich in #252 geschrieben habe?

Haarmann

2007-09-08, 14:31:55

BessereHälfte

Mir ist immer Unwohl bei der Aussage, das ASM grundlegend komplizierter sei denn C, weil dies imho extrem Plattformabhängig ist. Es war erstaundlich an der Uni zu sehen, dass die Leute immerhin in der Lage waren die trivialen Probleme in ASM zu lösen auf einem Palm Simulator. Handbücher bewirken offenbar Wunder bei überschaubaren Problemen.
Die gleiche Gruppe hat dann, ausser einer minimalen Teilmenge, die weigerte sich Java zu nutzen, ein Problem in Java zu lösen versucht - keine Chance brutal gesagt. Da halfen Handbücher, die gabs ja auch, offensichtlich nicht mehr. Java war an der Uni von Anfang an mit dabei und die Leute hätten es, im Gegensatz zum ASM, beherrschen müssen.

Manchmal denke ich, dass die Mehrzahl der Leute überfordert ist, wenn sie ein grosses Problem in Teile zerlegen müssen. Wer dies problemlos beherrscht, der kann meiner Meinung nach auch grosse Projekte noch in ASM durchführen - allerdings ist die Entwicklungsgeschwindigkeit eben geringer und man ist an eine Plattform weit stärker gebunden -> man wird auf eine höhere Ebene ausweichen.
Die Inlineebene bleibt wie gesagt erhalten und kann genutzt werden bei Bedarf. Das siehst Du ja ebenfalls so. So verbindet man die Vorteile des Einen mit denen des Anderen.

Natürlich ist das grösste Problem der Mensch an sich, aber gerade weil ich mir dessen bewusst bin, würde ich immer versuchen, diesen Faktor so klein wie möglich zu halten.

Gast

Das schöne an meiner Aussage ist, dass sich viele Leute drin wiederfinden können. Selbst wenn man nicht zu der klitzekleinen Minderheit der ASM Götter, ich nenn sie mal so, gehören würde, so gibts auch noch ne Menge weiterer Positionen, wo man sich einordnen kann.

Aquaschaf

Ich habe Abstrakionslevels nicht global ausgeschlossen. Ich sprach doch deutlich von einem beliebigen zusätzlichen Level und meiner Ansicht nach gibts in der Proggerwelt weit mehr denn ein Level.

Gast

2007-09-08, 14:52:27

Aquaschaf

Ich habe Abstrakionslevels nicht global ausgeschlossen. Ich sprach doch deutlich von einem beliebigen zusätzlichen Level und meiner Ansicht nach gibts in der Proggerwelt weit mehr denn ein Level.
Bei C ist die Abstaktion aber hauchdünn, gerade genug um den Code Portabel zu machen und sichtbare struktur rein zu bringen.

(del)

2007-09-08, 15:02:18

Bei C ist die Abstaktion aber hauchdünn, gerade genug um den Code Portabel zu machen und sichtbare struktur rein zu bringen.Nur wei lange? Alphatier scheint als Softwarearchitekt wohl viel von NET zu halten. Die Soft wird mit der Zeit immer besser :| Nur halt auf gleicher Hardware auch immer lahmer. Vista-Syndrom.

Octacores for all :ujump2:

Gast

2007-09-08, 15:10:15

Nur wei lange?
So lange bis ein Programmierer hingeht und noch ein paar abstaktionsebenen reinklatscht. Das könnte er aber bei ASM genau so machen, also keine Sache der Sprache C.

Gast

2007-09-08, 15:36:20

Vista-Syndrom.

Also mein Vista läuft deutlich schneller/smoother als mein XP auf der selben HW.

Octacores for all :ujump2:

Du kannst doch gerne deine vorhandene CPU behalten und auf die Zaubersoftware warten, die bei gleichbleibender HW mehr bzw. aufwendigere Funktionalität bietet.

Gast

2007-09-08, 21:12:30

Also mein Vista läuft deutlich schneller/smoother als mein XP auf der selben HWSchon einmal von sowas gehört. Noch nie gesehen.

Du kannst doch gerne deine vorhandene CPU behalten und auf die Zaubersoftware warten, die bei gleichbleibender HW mehr bzw. aufwendigere Funktionalität bietet.Vista ist im Vergleich zu XP alles andere als Zaubersoftware. Ich geh' kaputt :lol:

(del)

2007-09-08, 21:20:03

Du kannst doch gerne deine vorhandene CPU behalten und auf die Zaubersoftware warten, die bei gleichbleibender HW mehr bzw. aufwendigere Funktionalität bietet.Läuft Bioshock etwa schlecht auf einer Hardware auf der Doom3 auch nur gut läuft?
Läuft Office2003 schlecht auf einer Hardware auf der Office2000 gut läuft?
Sorry aber du wilst jetzt in diesem Thread mit so einem rethorischen Quark großartig dazwischen quatschen? :|

Haarmann

2007-09-08, 23:23:50

Gast

Ich empfand es anders und Struktur ist etwas, dass Leute selbst reinbringen. Als Zeckensack mal ASM Code brachte, dand ich dessen Struktur auch hervorragend. Das ist keine Frage der Sprache, sondern des Autors imho.

In diesem Bereich sind aber sicher viele Empfindungen auch eben subjektiv, was ich durch meine Aussagen angedeuten haben wollte.

Gast

2007-09-09, 00:15:16

Gast

Ich empfand es anders und Struktur ist etwas, dass Leute selbst reinbringen. Als Zeckensack mal ASM Code brachte, dand ich dessen Struktur auch hervorragend. Das ist keine Frage der Sprache, sondern des Autors imho.
Keine lust diesen ASM Code jetzt zu suchen, aber ich bezweifle einfach das man in ASM strukturen wie fallunterscheidungen, schleifen etc so gut (und schnell) erkennen kann wie in Programmiersprachen.

In diesem Bereich sind aber sicher viele Empfindungen auch eben subjektiv, was ich durch meine Aussagen angedeuten haben wollte.
Das stimmt wohl.

Coda

2007-09-09, 00:49:17

Also meiner Meinung nach ist zumindest x86-Assembler eine Write-Only-Sprache, und das ist ja sogar CISC.

Meinen alten Assembler-Code könnte ich ohne Kommentare ja fast schon selber nicht mehr lesen.

del_4901

2007-09-09, 00:52:58

Also meiner Meinung nach ist zumindest x86-Assembler eine Write-Once-Sprache, und das ist ja sogar CISC.

Meinen alten Assembler-Code könnte ich ohne Kommentare ja fast schon selber nicht mehr lesen.
Du meintest das doch sicherlich so, oder?

Coda

2007-09-09, 00:53:34

Nein, so wie es dasteht.

http://en.wikipedia.org/wiki/Write-only_language

del_4901

2007-09-09, 00:56:52

Nein, so wie es dasteht.

http://en.wikipedia.org/wiki/Write-only_language
Fu, das gibs ja wirklich, meins ist trotzdem besser. (und hat die gleiche Bedeutung)

Coda

2007-09-09, 01:00:29

Ich glaube du vertust dich gerade mit WORM (Write-Once-Read-Many), kann das sein?

Write Once hat auf jeden Fall einen andere Bedeutung, die ich nicht gemeint habe.

del_4901

2007-09-09, 01:05:22

Ich glaube du vertust dich gerade mit WORM (Write-Once-Read-Many), kann das sein?

Write Once hat auf jeden Fall einen andere Bedeutung, die ich nicht gemeint habe.
Ne ich hab das jetzt im englischen Kontext gesehen ... einmal schreiben und nie wieder ansehen/anfassen. Da passt once besser als only

Coda

2007-09-09, 01:24:12

Write-Only bezieht sich darauf, dass man es eben fast nicht lesen kann, das hat nichts mit einmal schreiben und nie wieder ansehen zu tun.

Gast

2007-09-09, 13:02:00

Das ist kein RISC mehr, weil der Befehlssatz nicht mehr wirklich reduced ist. Da gibt's doch schon für jeden Mist auch Spezialinstructions. Das ist nicht mehr die ursprüngliche Idee davon.
du raffst es echt nicht und du weisst echt nicht, was RISC eigentlich ist.
Was erhalten geblieben ist sind die vielen Register und die fixed length encoding der Instructions, aber kein reduzierter Befehlssatz mehr._das_ ist RISC. das ist ein reduzierter befehlssatz.

Das siehst du aber nicht am Binary, weil auch Padding usw. relevant ist. Eine Executable steigt immer um z.B. 32 KiB in der Größe wenn man es kompiliert, nicht um kleine Schritte. Wenn man da wirklich was rauslesen will muss man disassemblieren.
kannst du nicht lesen? das habe ich gemacht. ich _habe_ disassembliert.
ausserdem ist die binary keine 32 kb größer, sondern nur 4 kb.
die disassebmler ausgabe hat 1000 zielen mehr code.

Und das ist verdammt wenig wenn man es auf die Logik umlegt, die heute für Ausführung, OOOE, Caches, usw. aufgewendet wird. Es spielt einfach keine Rolle mehr.
mal eben 10 oder 20 millionen transistoren. das zählt nicht. nee is klar.

fazit

du biegst die definition von RISC solange zurecht, um behaupten zu können, es gibt kein RISC mehr.
du ignorierst echten code, um behaupten zu können, x86 wäre eine effektive code kompression.
du ignorierst den unterschied zwischen komplizierter code tranlsation und einfachem decode (oder weisst gar nicht was das ist) um behaupten zu können, ein G5 und ein x86 machen das gleiche.
du übersiehst millionen transistoren, um behaupten zu können, x86 würde nix mehr kosten.

du verdrehst tatsachen, um falsche behauptungen zu belegen.
anstatt einfach mal aus den tatsachen zu lernen.

Gast

2007-09-09, 13:19:47

_das_ ist RISC. das ist ein reduzierter befehlssatzViele Register und fixed lenght bedeuten reduced instruction set computing?

Eine simple Definition von RISC:
* Reduzierung des Befehlssatzes
* die wichtigsten Befehlsfolgen sind fest verdrahtet
* mehrere getrennte interne Bussysteme
* voneinander unabhängige Verarbeitungseinheiten
* Pipelining (Parallelverarbeitung bestimmter Befehle)
* einfache Schaltungen, dadurch schnellere Ausführung

Kann sein daß es noch paar CPUs gibt die (noch) mehr dieser Punkten erfüllen als ein x86. Reduzierung des Befehlssatzes, das frühere A&O einer RISC-Architektur, kannst du dir aber mittlerweile in die Haare schmieren.

fazitUnd sowas erst recht.

StefanV

2007-09-09, 13:30:00

fazit
RISC ist tot, x86 ist nicht so schlecht, wie von vielen behauptet wird, am Ende ists sogar eins der besseren ISAs.

(del)

2007-09-09, 13:34:11

Mal wieder völlig OT, Stefan? :|

Und richtig. Es heißt immernoch RISC, also Reduced Instruction Set Computing und nicht RILC, also Reduced Instruction Lenght Computing (bzw. Computer).

No.3

2007-09-09, 13:40:40

RISC ist tot, x86 ist nicht so schlecht, wie von vielen behauptet wird, am Ende ists sogar eins der besseren ISAs.

genau, so schlecht ist das A20 Gate wirklich nicht ;) es ist sogar so gut, dass ein nagelneues System wie die X-Box eine hat und nun auch Apple das Tor implementiert hat ;)

SavageX

2007-09-09, 13:51:17

genau, so schlecht ist das A20 Gate wirklich nicht ;) es ist sogar so gut, dass ein nagelneues System wie die X-Box eine hat und nun auch Apple das Tor implementiert hat ;)

Ich behaupte, dass das A20 Gate nichts mit der x86 ISA zu tun hat. Dass jede x86-Implementation diesen "hey, wir haben ja noch einen Pin am Tastaturcontroller frei, um den 1MB wraparound zu kontrollieren"-Hack heute mit sich rumschleppt hat nichts damit zu tun, dass es in x86 einen Befehl für diesen Anachronismus gibt.

Gast

2007-09-09, 14:00:03

und nun auch Apple das Tor implementiert hat ;)

Beim Intel-Mac liegt es aber scheinbar brach. Man kann AFAIK kein Dos booten.

(del)

2007-09-09, 14:02:41

Daß es ein A20 im System gibt, ist für das System in den ersten 2s nach dem Betätigen des Startknopfs relevant. Danach spielt das auf NTs&Co überhaupt keine Geige. Verlangsamt nichts und erschwert ebenfalls nichts.

No.3 freu dich mal über den A20. Und darüber, daß sie ihn noch nicht anrühren wollen. Kann sein, daß du in paar Jahren auch PC-Boards NUR mit "secret roms" oder TPM oder welchen Mist auch immer bekommst Dagegen scheint A20 beim Einschalten gut zu wirken... Wer weiß, auf was alles wir uns in paar Jahren noch gefasst machen müßen.

Vielleicht wird uns der A20 eines Tages erlauben wieder die Kontrolle über unsere Systeme zu erlangen? ;) Ich denke bis es soweit ist wird er aber abgeschafft. Wenn es soweit ist, wißt ihr warum...

Thowe

2007-09-09, 14:02:41

...

Kann sein daß es noch paar CPUs gibt die (noch) mehr dieser Punkten erfüllen als ein x86. Reduzierung des Befehlssatzes, das frühere A&O einer RISC-Architektur, kannst du dir aber mittlerweile in die Haare schmieren.

Und sowas erst recht.

Streng genommen dürfte der ARM2 der letzte echte, "glorreiche" Vertreter der RISC CPUs gewesen sein. Wenn man RISC als Leistung gleichsetzt. Heute spielt es freilich keine Rolle mehr, denn die Relation um die es geht dürfte folgende sein: Leistung, Herstellungskosten, Entwicklungskosten, Marktbedürfnisse. Damals passte der RCA1802 gut ins Bild, heute spielt das Design und die Gegebenheiten dahinter eben kaum noch eine Rolle. Der K5 war sicherlich der erste CISC/RISC mit gewisser Bedeutung, die hat der Nx586 sicherlich nie erlangt. Der Pentium Pro, nun, ich mochte damals mein DUAL-Board.

Vor allem ist RISC nun alles andere als moderner oder besser denn CISC, für solches idiologischen Denken geben sich Ingenieure nun nicht her, im Grunde gilt für die nur: Modern ist, was Sinn macht. Die Kombination aller Welten macht eben Sinn und wenn ein Teil des Prozessors als RISC arbeitet, ist dieser Teil eben genau das, was man heute unter RISC versteht. Alle anderen dürfen gerne auf Ebay versuchen noch einen Cosmac ELF / ELF2 / SuperELF zu ersteigern, wenn dann mal wieder einer auftaucht. ^^

Thowe

2007-09-09, 14:04:24

Beim Intel-Mac liegt es aber scheinbar brach. Man kann AFAIK kein Dos booten.

Lag, soweit ich es mitbekommen habe, wurde es fürs Bootcamp aktiviert.

Gast

2007-09-09, 14:08:52

Der Intel-Mac - Ein normaler PC?
http://www.mcnix.de/?q=node/22#comment-10

No.3

2007-09-09, 14:40:10

Ich behaupte, dass das A20 Gate nichts mit der x86 ISA zu tun hat. Dass jede x86-Implementation diesen "hey, wir haben ja noch einen Pin am Tastaturcontroller frei, um den 1MB wraparound zu kontrollieren"-Hack heute mit sich rumschleppt hat nichts damit zu tun, dass es in x86 einen Befehl für diesen Anachronismus gibt.

die CPU kennt doch gewiss einige Befehle um das A20 Gate zu verändern, oder sind die Befehle entfernt worden?

Daß es ein A20 im System gibt, ist für das System in den ersten 2s nach dem Betätigen des Startknopfs relevant. Danach spielt das auf NTs&Co überhaupt keine Geige. Verlangsamt nichts und erschwert ebenfalls nichts.

schon klar - historisch ist das Ding in die CPU reingewachsen um inkompatible Software per Hardware wieder kompatibel zu machen, normalerweise macht man so was (zumindest heutzutage) umgekehrt ;)

Vielleicht wird uns der A20 eines Tages erlauben wieder die Kontrolle über unsere Systeme zu erlangen? ;) Ich denke bis es soweit ist wird er aber abgeschafft. Wenn es soweit ist, wißt ihr warum...

wie die x-box ;) und ja, A20 kommt frühestens dann weg

Haarmann

2007-09-09, 14:59:11

Gast

Das ist auch immer eine Frage des Autors vom Code...

Wenn ich das Exempel "Hallo Welt" für Amiga und 68k bei Wikipedia in ASM sehe, wird mir auch schlecht. Nutzt man stattdessen für Bilbliofunktionen LVO_Funktionsname und deklariert diese zuvor am Anfang, wobei man dafür einfach nen File einfügt, dann sieht das ganz anders aus.

Auch ein simples einfügen von Leerzeilen hilft ungemein.

Es gibt mehr Zeilen, aber die einzelnen Zeilen sind dafür massiv kürzer.

Wie sich jeder seinen Quelltext gestalten will ist jedoch eben subjektiv - an der Uni fluchte ich jedesmal wie ein Rohrspatz, dass ich jeden Quelltext erstmal formatieren durfte... Code einsetzen, sprich Aufgabe lösen, kostete 5min... Quelltext lesbar machen eine Stunde...

Coda

Das liegt aber ganz klar am x86 und dessen oft hanebüchernen Konstrukten. Eine der bekanntesten Folgen ist ja auch das schöne Gate A20. Die Zukunftsblindheit seitens Intel ist legendär... und endet nicht beim 8086.

Coda

2007-09-09, 15:02:32

genau, so schlecht ist das A20 Gate wirklich nicht ;) es ist sogar so gut, dass ein nagelneues System wie die X-Box eine hat und nun auch Apple das Tor implementiert hat ;)
Sowohl die XBox als auch die Apple-Systeme haben A20 am Prozessorpin einfach auf High-Pegel und sind damit unwirksam.

Das liegt aber ganz klar am x86 und dessen oft hanebüchernen Konstrukten. Eine der bekanntesten Folgen ist ja auch das schöne Gate A20. Die Zukunftsblindheit seitens Intel ist legendär... und endet nicht beim 8086.
A20 wurde von IBM verbrochen. Intel kannst du den Vorwurf nicht machen, es gab ab dem 286er einen Protected-Mode.

Lag, soweit ich es mitbekommen habe, wurde es fürs Bootcamp aktiviert.
Windows braucht kein A20.

No.3

2007-09-09, 15:05:42

Wenn ich das Exempel "Hallo Welt" für Amiga und 68k bei Wikipedia in ASM sehe, wird mir auch schlecht. Nutzt man stattdessen für Bilbliofunktionen LVO_Funktionsname und deklariert diese zuvor am Anfang, wobei man dafür einfach nen File einfügt, dann sieht das ganz anders aus.

o O, das Beispiel ist nicht nur schlecht sondern auch "illegal" d.h. ein Beispiel dafür wie man auf dem Amiga eben gerade nicht programmieren darf

Coda

2007-09-09, 15:08:24

die CPU kennt doch gewiss einige Befehle um das A20 Gate zu verändern, oder sind die Befehle entfernt worden?
Es gab nie Befehle. Das A20-Gate war ein externes AND-Gatter dass die 20. Adressleitung des Prozessors und ein noch unbelegtes Signal am Tastaturcontroller verbund. Der Effekt ist, dass man A20 über den Tastaturcontroller einschalten muss um die 20. Adressleitung benützen zu können. Das gilt auch im 32- und 64-Bit-Modus.

Wie gesagt ist das aber keine Abart von x86, sondern eine Abart vom IBM-PC. Große Logikmengen zur Emulation sind auch nicht vonnöten.

(del)

2007-09-09, 15:20:05

Also... nachdem der Gast der dauernd Coda anzumachen versucht nun endgütig in seine Ecke zurückgedrückt wurde und Coda loblicherweise auf den Mumpitz auch nicht mehr angeht, könnte einer der Member zwischendurch vielleicht ein kurzes Resumee, in Bezug auf den Threadnamen, versuchen? =)

Zwischen den Kilos an Informationen und Tonen vom belanglosen oder einfach schwachsinnigen Zeug ist es für mich schwer sich das wichtigste von den 15 Seiten rauszupicken ;)

Coda

2007-09-09, 15:29:04

Mein Resumee ist: Die Diskussion ist völlig belanglos.

(del)

2007-09-09, 15:29:50

:usad: Das wäre nur das Fazit zum Resumee ;)

Coda

2007-09-09, 15:34:26

Ich schreib dazu nix mehr, sonst geht die Streiterei wieder los.

(del)

2007-09-09, 15:39:06

Auch wieder Wahr... (!) Ok.

Thowe

2007-09-09, 15:42:16

Resümee? Pentiums sind echte RISC Prozessoren, genau wie die meisten anderen auch, die sich RISC auf die Fahne schreiben und im Grunde nicht mehr sind. <- Wäre meins, war meins, wird meines bleiben.

StefanV

2007-09-09, 17:04:18

Resümee: die Einteilung in RISC und/oder CISC ist absurd geworden und stamt aus grauer Vorzeit, als Computer noch schwarz/weiß (oder gelb/schwarz bzw grün/schwarz) Schirme befeuert haben.

Von daher ist diese Diskussion wirklich belanglos, da es weder noch aktuell gibt oder jemals wieder geben wird...

Wir sollten uns also wirklich mal von RISC/CISC verabschieden und die
Dinger einfach generell GP-PU (General Purpose Processing Unit) nennen...

Zentrale Recheneinheit ist bei (einem 4 Sockel System mit je) 4 Cores etwas unpassend :ugly:

No.3

2007-09-09, 17:21:41

Zentrale Recheneinheit ist bei (einem 4 Sockel System mit je) 4 Cores etwas unpassend :ugly:

sollte man vielleicht von CPU zu DPU - Distributed Processing Unit - wechseln? :usweet:

BlackBirdSR

2007-09-09, 22:57:42

sollte man vielleicht von CPU zu DPU - Distributed Processing Unit - wechseln? :usweet:

Man könnte auch bei dem bleiben was es schon gibt.
MPU - Main Processing Unit. Ist zwar das Gegenteil von DBU, aber das trifft es IMO auch ganz und gar nicht.

No.3

2007-09-09, 23:30:29

MPU

Idiotentest? :biggrin:

Main Processing Unit.

jup, fügt sich gut zusammen mit der Graphics Processing Unit, Physics Processing Unit, Audio Processing Unit, etc

BlackBirdSR

2007-09-09, 23:35:14

Idiotentest? :biggrin:

jup, fügt sich gut zusammen mit der Graphics Processing Unit, Physics Processing Unit, Audio Processing Unit, etc

Ich verstehe nicht was das jetzt soll?
MPU war als Begriff schon vergeben, da habe ich noch fast in die Windeln gemacht, und von einer GPU hat noch niemand geredet.
Meinetwegen sagen wir auch korrekt Microprocessor Unit, oder Manycore Processing Unit dazu. Verdeutlicht zwar nicht so schön das Gegenteil von DBU, aber ist immernoch die richtige Bezeichung ;)

No.3

2007-09-09, 23:39:03

Ich verstehe nicht was das jetzt soll?

Du meine Güte, was ist denn zur Zeit nur mit dem Forum los...

Edit

Meinetwegen sagen wir auch korrekt Microprocessor Unit

auch ne Variante, aber eine GPU, APU, etc wären jeweils auch Microprocessor Units, odr?

Manycore Processing Unit

Multicore würde IMHO besser klingen

nebenbei, waren MPUs nicht auch die Midi Teile von Roland d.h. Midi Processing Units oder so ähnlich?

BlackBirdSR

2007-09-09, 23:54:27

Du meine Güte, was ist denn zur Zeit nur mit dem Forum los...

Ist etwas laggy, finde ich auch ;)

auch ne Variante, aber eine GPU, APU, etc wären jeweils auch Microprocessor Units, odr?

Manche Begriffe sind einfach zu alt für heute ;). Man müsste eben etwas neues Einführen. CPU ist allerdings nicht wirklich ungünstig oder so etwas. Es handelt sich ja immernoch um die zentrale Steuereinheit im ganzen PC. Zumindest bis die ehemaligen TCPA-Chips etc übernehmen :tongue:

nebenbei, waren MPUs nicht auch die Midi Teile von Roland d.h. Midi Processing Units oder so ähnlich?
Irgendsowas.. aber Verwechselungsgefahr besteht ja jetzt kaum noch. Mal sehen ob wir in 20 Jahren auch vom CPU Begriff als solches so darüber redden.