Da ich mir endlich vorgenommen habe mich mit uC zu beschäftigen bevor wir es in der Schule durchführen , tauchen schon die ersten Probleme auf z.B die einfache zuweisung eines Pins als Ein bzw Ausgang. Da wir heute in der Schule die Grundzüge von uC und uProz gelernt haben und unser Lehrer meinte wir Programmieren (den 8051) in ASM. Nun gut ich habe in Informatik 3 Jahre Lang ANSI C Programmiert und auch gelernt also dachte ich machste es doch auch bei uC. Da ich aber gehört habe dass man mit C irgendwann an die Grenzen vom Compiler stoßt wäre es doch besser gleich mit ASM anzufangen. Was würdet ihr mir vorschlagen zum "Anfangen"? (Ich will hier keinen Glaubenskrieg von wegen ASM vs. C anzetteln sondern nur von ein paar erfahrenen User ein paar Ratschläge zu bekommen) Gruß Daniel
Wenn du C kannst, dann fang erstmal mit C an, so dass du nur noch den µC kennen lernen musst. An die Grenzen kommt man eigentlich nur, wenn etwas wirklich extrem Zeitkritisch ist. Assembler ist aber generell nie verkehrt, denn dann versteht man den µC besser.
Wie gesagt ansich ist C ein schöne strukturierte Sprache jedoch über Ports definieren ist im GCC Tutorial recht wenig zu finden(oder bin ich blind) da haben die ASM Leute einen Vorteil :) (Frauen sind ja fast einfacher zu verstehen als uC ^^) Gruß
Ich habe zwar noch nie einen 8051 programmiert (arbeite mit PICs in Assembler), denke daher dass Assembler das sinnvollste ist, da es die "angeborene" Sprache des µC ist und man den µC viel besser unter Kontrolle hat als mit C. In der Schule hab ich etwas Java gelernt, ich fühlte mich bei "kompizierteren" Algorithmen immer etwas eingeengt was die Vorgehensweise betrifft. Wirklich zeitkritische Sachen kann man auch eigentlich nur mit Assembler machen. Allerdings kann es dann sehr elegant sein, das Hauptprogramm in C zu schreiben und zeitkritische Sachen oder ähnliches in Assembler zu implementieren.
Ich würde erstmal mit C anfangen. Wenn du das einigermaßen beherrschst, dann kannst du den Compiler so einstellen, daß er als Ausgabe eine Assemblerdatei erzeugt. Damit und mit der Beschreibung des Maschinenmodells deines µC kannst du nachvollziehen, was der Compiler aus deinem Quelltext gemacht hat und lernst dabei den Assembler. Wenn du dann die Tricks kennst, die auf deinem Controller-Typ angewandt werden, dann kannst du selbst kleine ASM-Programme schreiben. Das Problem bei ASM ist salopp gesagt, daß man leicht vor lauter Bäumen den Wald nicht mehr sieht... C hat übrigens alle Mittel, mit denen man Ports ansprechen kann - sieh dir einfach die entsprechenden .h-Files an, in denen sowas definiert ist.
C ist von Vorteil, wenn du Software erstellst, die andere auch verstehen sollen. Bei Assembler dauert das immer nen bisschen länger.
Ja das man PORTS ansprechen kann hab ich schon rausgelesen nur wie nicht wirklich aber das mit den Headerfiles ist ein heisser Tip ! Ty! Ich werd mal ne Nacht drüber schlafen :) Gruß
Im professionellen Bereich wird immer weniger Assembler eingesetzt, teilweise überhauptnicht mehr. Dort sind C, C++, Ada, Java angesagt. Je nach Sparte und Anforderungen. In der Schule kann es aber durchaus sinnvoll sein, was in Assembler zu machen. Das bringt ein besseres Verständnis der Maschine als C zu nehmen. Mit C sehen die Programme dann im Prinzip so aus, wie auf dem PC auch. Das ist zwar der Sinn einer höheren Sprache, aber ein kleiner µC ist eben ein anderes Geschäft als ein PC ... da geht nicht mal eben ein malloc(1E6) ;-) Johann
C ist gut und schön, trotzdem empfehle ich dir ganz furchtbar dringend, irgendwann mal Assembler zu lernen. Weniger, um damit große Programme zu entwickeln, sondern vielmehr, um zu verstehen, WIE deine Architektur funktioniert. Dadurch erschließen sich z.T. nämlich Dinge, die sonst einfach nicht verständlich sind, etwa: - Warum ist '(1 << i)' in C langsam?
hab früher auch noch asm gelernt, ich meiner ganzen Arbeitszeit habe ich es aber nie benötigt - dort wo ich arbeite wird alles in c bzw. c++ geschrieben. auch in c kann man zeitkritische dinge programmieren ohne dass der µc abhebt! Versteh' mich nicht falsch, für das verständniss eines µc und dessen arbeitsweise ist asm nahezu unumgänglich, als praktizierte programmiersprache wird es aber meiner meinung nach nicht mehr verwendet!
Klar kann man in C effizient programmieren, soger in vielerlei Hinsicht. Aber warum halt z.B. dashier:
1 | int bit; |
2 | for (int i = 0; i < 8; i++) { |
3 | bit = 1 << i; |
4 | /* machwas */
|
5 | }
|
auf einem AVR Scheiße ist, eben solche Sachen zeigt einem C einfach net :-)
Taser schrieb: > Wie gesagt ansich ist C ein schöne strukturierte Sprache jedoch über > Ports definieren ist im GCC Tutorial recht wenig zu finden(oder bin ich > blind) da haben die ASM Leute einen Vorteil :) Soweit ich weiß, gibt es den GCC nicht für 8051. Die üblichen C51 Compiler (Keil, SDCC, Wickenhäuser) kennen Bitvariablen und SFR-Bits, einfach mal in die Doku schauen. Aber auch dem AVR-GCC kann man diese über ein Macro beibringen. Ich benutze beim C51 und auch beim AVR immer nur Bitvariablen für die Portpins. Das macht den Code schön lesbar. > (Frauen sind ja fast einfacher zu verstehen als uC ^^) Man(n) sollte erst garnicht versuchen, Frauen zu verstehen. Das ist noch deutlich schwieriger als die Erfindung des Perpetuum Mobile. Peter
Ich habe Pics in Asm programiert und AVRs nur in C. Der Umstieg auf ARM wäre in Asm wahrscheinlich viel schwieriger gewesen. Großer Vorteil von C ist, dass man unabhängiger vom Zielsystem ist. Ich will nicht mit einem oder zwei MCs verheiratet sein. Ein Projekt lässt sich nunmal in kürzerer Zeit in C programmieren und portieren als in Asm. Ob man damit das Maximum an Geschwindigkeit rausholt: Bestimmt nicht. Nur viel langsamer wird es auch nicht sein, von Spezialfällen mal abgesehen. Aber wenn das bei den meisten Projekten zählen würde: Warum will man dann auf fast allem Java laufen haben?
Es geht hier darum, die Grundzüge eines µC zu lernen. Es geht nicht darum, möglichst schnell ein Projekt hochzuziehen oder portierbar zu halten. Da finde ich Assembler besser geeignet, denn es geht darum zu begreifen, wie so ein Ding tickt, und da sind Abstraktionsebenen eher hinderlich als erhellend. Johann
Assembler ist IMHO noch für zwei Dinge gut: - Zum lernen: Man sieht step by step, was der Prozessor macht. Einerseits lernt man so die Maschine sehr gut kennen, andererseits bekommt man ein gutes Gefühl dafür, wie beispielsweise ein C-Programm schlussendlich auf der Maschine abläuft. - Wenn es wirklich zeitkritisch wird. Also dann, wenn man kontrollieren will, in welcher Nanosekunde der Prozessor was tun soll. Wenn ein Programm hingegen einfach "möglichst schnell" sein soll, ist man mit C auch gut beraten, da C sowieso schon recht maschinennah ist und der Compiler sehr gut optimiert. Was du lernst, ist deine Entscheidung: Bist du bereit, den etwas mühsameren Weg über Assembler zu nehmen und dafür einiges an Wissen zu gewinnen oder willst du eher möglichst schnell und sicher programmieren mit C?
mr.chip schrieb:
> Assembler ist IMHO noch für zwei Dinge gut:
und
- Compilerbau: Moderne Compiler werden zwar nicht in Assembler
programmiert, aber trotzdem soll hinten Assembler oder
Maschinencode rauskommen.
Johann
und - wenn man in Maschinencode hinein debuggen muß, zu dem man keinen Quelltext hat.
und - wenn man zwar den Quelltext hat, aber bei einem nicht funktionierenden C Statement die Tomaten erst im Einzelschrittablauf auf Assembler- Ebene von den Augen fallen.
>Es geht hier darum, die Grundzüge eines µC zu lernen. 1. Was Flags wie Carry, zero, usw. sind, warum es Register gibt und das die ALU kein Block aus Metall ist kann man auch ohne Asm lernen. Bei Asm spielen immer Eigenheiten der Controller mit rein, die man in C nicht sieht, und das ist oft gut so. Die AVRs z.B. haben zwar 32 Register, davon können jedoch alle Befehle nur mit den oberen 16 ausgeführt werden. 2. Die "Grundzüge" sind für fast jeden Prozessor anders. Die Architekturen weisen dafür oft zu wenige Gemeinsamkeiten auf. Das fängt bei Von-Neumann und Harvard an, geht weiter über die Register (die alten Pics mussten jeden Befehl über die eine ALU ausführen), geht über die Ports (Ansteuern eines Ports bei einem AVR und ARM7 ist sehr unterschiedlich) zu den Interrupts (k.K.). 3. Auch in C kann man hardwarenah programmieren. Wenn externe Hardware angesprochen wird oder Registereinstellungen vorgenommen werden ist man da sehr schnell. 4. C ist für mich ein erweiterter Assembler. Aber ein gut portierbarer und leistungsfähiger.
Bastl schrieb: > 2. Die "Grundzüge" sind für fast jeden Prozessor anders. Die > Architekturen weisen dafür oft zu wenige Gemeinsamkeiten auf. Für den Lerneffekt ist das nicht allzu relevant. Also dafür, später ggf. das Assembler-Handbuch eines noch nicht vertrauten Controllers einigermassen verstehen zu können. An einer Uni hatte in den 80ern ein Prof mal die Sprache seines frisch erworbenen programmierbaren TI Taschenrechners dafür auserkoren. Das war zwar ein bischen arg schräg, aber im Vergleich mit Assembler von High-End Rechnern der 60er/70er auch nicht völlig daneben.
Es soll an einer mir bekannten Uni einen Professor geben, der die Programmieraufgaben in einer von ihm erfundenen und nach ihm benannten Sprache ableisten lässt, eben um Abstraktion zu trainieren. Aber ums konkret zu wiederholen, warum Assemblerkenntnisse manchmal hilfreich sind: Aufgabe: Erkläre ohne Assembler, warum folgender Quelltextauszug uneffizient ist:
1 | for (int i = 0; i < 100; i++) { |
2 | int bit = 1 << i; |
3 | /* machwas */
|
4 | }
|
Da sieht mans recht schön. Trotzdem bitte die zwei goldenen Regeln des Optimierens nicht vergessen: 1. Don't do it. 2. Don't do it yet.
Sven P. schrieb: > Es soll an einer mir bekannten Uni einen Professor geben, der die > Programmieraufgaben in einer von ihm erfundenen und nach ihm benannten > Sprache ableisten lässt, eben um Abstraktion zu trainieren. Das mit der selbstdefinierten ASM-Maschine habe ich selbst erlebt. Hatte aber weniger mit Abstraktionstraining zu tun, als mit Vereinfachung. Das Maschinchen war so simpel strukturiert, daß man es sehr schnell intus hatte. Es hat völlig ausgereicht, um die Grundprinzipien klar zu machen - das war auch der Zweck der Übung...
Der offizielle Weg an besagter Uni war MIX. Aber noch nicht die neumodische Version MMIX, sondern dieses Kuriosum: http://de.wikipedia.org/wiki/MIX, besser aber http://en.wikipedia.org/wiki/MIX.
Aber dafür ausgerechnet mit einem 8051 anzufangen ? Der ist doch erstens besonders bescheiden zu programmieren und hat zweitens besonders wenig mit den Speicheraufbau modernerer Prozessoren zu tun. Ob man dann Assembler oder C macht, ist fast egal. Entweder man lernt programmieren oder lernt es eben nicht. Die Sprache spielt keine Rolle. Gruss Axel, der auf einem 8051 mit Assembler angefangen hat
Axel schrieb: > Der ist doch erstens besonders bescheiden zu programmieren In Assembler? Finde ich nicht. Wenn man sich auf 128-256 Bytes Datenadressraum beschränkt, dann ist der 8051 in Assembler ziemlich übersichtlich zu programmieren. Für einen 8-Bitter. > zweitens besonders wenig mit den Speicheraufbau modernerer Prozessoren > zu tun. Passt schon. Ein einheitlicher Adressraum für Data,Code,IO ist in der Controller-Branche unterhalb der 32bitter eher selten anzutreffen. MSP430, Freescale bis 64KB, aber sonst?
A. K. schrieb: > Ein einheitlicher Adressraum für Data,Code,IO ist in der > Controller-Branche unterhalb der 32bitter eher selten anzutreffen. > MSP430, Freescale bis 64KB, aber sonst? 8080, 8085, Z80 - 64 KB
Die sind alle mausetot. Ich bezog das auf Mikrocontroller. Immerhin heisst die hiesige Site so. Ausserhalb dieser Fachrichtung werden 8/16-Bitter nur noch von ein paar Nostalgikern verwendet. Zudem ist es auch noch falsch. Die haben 2 Adressräume, Code/Data der eine, I/O der andere.
A. K. schrieb: > Die sind alle mausetot. Den Z80 gibts immernoch. > Zudem ist es auch noch falsch. Die haben 2 Adressräume, Code/Data der > eine, I/O der andere. Es hindert dich niemand daran, Memory mapped IO zu implementieren. Allerdings ist der zusammenhängende 64 KB Adreßraum für Code und Daten in der Praxis das, was die Handhabung der Maschine bequem macht gegenüber den "richtigen" Harvardmaschinen. Ich habe die Dinger lange genug programmiert... Die 80x86-Linie hat ebenfalls diesen IO-Adreßraum. Als Harvardmaschinen werden sie dewegen wohl nicht bezeichnet...
Von Harvard habe ich zwar nichts gesagt, aber wo du es schon ansprichst: Seit dem ersten Pentium werden alle Intel x86 sehr wohl als Harvard-Maschinen bezeichnet. Ich mag diese Kategorisierung über die Busse zwar auch nicht, sie ist aber unausrottbar.
Ich persönlich finde, die Harvard-Fritzen haben damals schlicht aus der Not "kleiner Adreßraum" eine Tugend gemacht mit der physikalischen Trennung von Code und Daten. Das dann als Feature zu verkaufen, ist schon dreist, aber auf 8-Bittern mag es vielleicht grade noch angehen. Bei den heutigen x86ern könnte man jedenfalls ohne Probleme auf den IO-Adreßraum verzichten und sehr viel Peripherie ist auf heutigen Mainboards memory mapped.
Ich hatte den Begriff Harvard absichtlich nicht verwendet. Die Begriffe Von-Neumann bzw. Harvard werden meistens über die Busse definiert. Und zwar die internen, die ausser dem Chipdesigner nicht wirklich interessieren. Der Einfachheit halber wird das an den Caches festgemacht. Und so ist ein 486er in diesem Sinn ein Von Neumann Design, weil er mit einem einzigen Cache ausgestattet ist, ein Pentium aber Harvard, weil er zwischen I-Cache und D-Cache unterscheidet. Genau das ist der Grund, warum ich diese Begriffe ungern verwende. Weil sie in dieser Form sinnlos sind. Zumal der 486, wenn man noch genauer hinschaut, wieder zum Havard wird, denn er mag zwar einen Cache haben, der wird aber von zwei Bussen angefahren.
War die (angebliche) Grundidee der Harvard-Architektur nicht, Code und Daten physikalisch zu trennen?
Das fundierte Wiki-Halbwissen dieses Uhu-Vogels hier im Forum lässt einem die Fußnägel hochkräußeln! Der will ja wohl über Alles bescheid wissen. Furchtbarer Dummschwätzer!
Aber zurück zum Thema: Natürlich geht es nicht wirklich um den I/O-Adressraum. Nur hatte ich ausdrückliche alle 3 in Frage kommenden Adressräume erwähnt und du (Uhu) wolltest mir dabei den 8080 unterschieben. Und der hat nun einmal seitens der Prozessorarchitektur einen getrennten I/O-Adressraum, egal ob du ihn verwendest oder nicht. Bei 8-Bit Controllern aus der Anfangszeit ergab eine Trennung von Code und Daten durchaus Sinn, denn mehr als 256 Bytes konnte sich Ende der 70er kaum einer für solche Anwendungen vorstellen und langfristige Planung war damals kein Thema. Dass man sich heute mit 8051ern mit 1MB Code rumärgern kann hatte Intel nicht auf der Rechnung - auch die x86 waren ja nur als Übergangslösung gedacht ;-). Ich ärgere mich auch darüber, dass Atmel nicht spätestens bei den Xmegas ein Flash-Dataspace Mapping ähnlich PIC24/30/33 implementiert hat. Aber das hätte entweder ein deutlich anderes internes Design in der Adressierung der Speicherstrukturen bedeutet, oder ein paar Befehlszyklen von der Adresse abhängig gemacht.
Uhu Uhuhu schrieb: > War die (angebliche) Grundidee der Harvard-Architektur nicht, Code und > Daten physikalisch zu trennen? War es. Und in den ersten Jahrzehnten lief das in der Praxis auch aufs Gleiche raus. Daher hat man sich leider daran gewöhnt, es an den Bussen und nicht an den Adressräumen festzunageln. Für die Busse reicht es, Strukturbildchen gucken zu können. Für Adressräume muss man die Befehlssatzarchitektur kennen, und das ist deutlich mehr Arbeit. Das Kind ist jetzt im Brunnen und ich kann nur jedem raten, diese Begriffe zu vermeiden oder stets klar zu machen, was genau man damit meint.
A. K. schrieb: > Bei 8-Bit Controllern aus der Anfangszeit ergab eine Trennung von Code > und Daten durchaus Sinn, denn mehr als 256 Bytes konnte sich Ende der > 70er kaum einer für solche Anwendungen vorstellen und langfristige > Planung war damals kein Thema. Aua, aua. Wo hast du denn das her? Mitte der 70er habe ich 8080-Kisten mit 64KB RAM programmiert und die hatten wir durchaus als eine problematische Grenze gesehen. > Ich ärgere mich auch darüber, dass Atmel nicht spätestens bei den Xmegas > ein Flash-Dataspace Mapping ähnlich PIC24/30/33 implementiert hat. Was bei solchen Aufwärtskompatibilitäten rauskommt, kann man prima an der x86-Lini beobachten... Ich halte diese Rangehensweise heute nicht mehr für gerechtfertigt. Die Softwaretechnologie kann mittlerweile mit sehr unterschiedlichen Architekturen der Hardware zurecht kommen - damals war das noch nicht so.
Uhu Uhuhu schrieb: > Aua, aua. Wo hast du denn das her? Mitte der 70er habe ich 8080-Kisten > mit 64KB RAM programmiert und die hatten wir durchaus als eine > problematische Grenze gesehen. Ich hatte damit integrierte Mikrocontroller gemeint, wie auch F8, 8048, PIC, Z8. Einzig die ebenfalls in diesem Sektor aufkommenden 68xx und 65xx Varianten hatte einen einzigen Adressraum. Der 8051 ist ein Mikrocontroller, war nie etwas anderes und war nur dafür konzipiert. Und da spielte der Aufwand auf dem Chip eine wesentliche Rolle. Langfristige Planung war sowieso nicht Intels starke Seite, weiter als bis zum nächsten Laternenpfahl hat es damals nie gereicht. Dass man mit 8080ern auch Controller implementiert hat ist klar, aber nicht als vollintegrierte Lösung. Vom Z80 mag es mittlerweile welche geben, die Rabbits basieren ja darauf, aber das ist eine winzige Nische und IMHO Masochismus. > Was bei solchen Aufwärtskompatibilitäten rauskommt, kann man prima an > der x86-Lini beobachten... Xmega-Programme auf ältere Megas und Tinys zu portieren wird auch so schon hart, weil beispielsweise der ganze Bereich der Port-I/O komplett auf den Kopf gestellt wurde. Und andersrum wäre nichts angebrannt, denn was in undefinierten Datenadressen drinsteckt war bei AVR noch nie definiert.
A. K. schrieb: > Ich hatte damit integrierte Mikrocontroller gemeint, wie auch F8, 8048, > PIC, Z8. Einzig die ebenfalls in diesem Sektor aufkommenden 68xx und > 65xx Varianten hatte einen einzigen Adressraum. Den 6809 habe ich auch mal mit ASM traktiert - das ist ein sehr schönes Maschinchen, das sich vor heutigen µC-CPUs wahrlich nicht verstecken muß. > Der 8051 ist ein Mikrocontroller, war nie etwas anderes und war nur > dafür konzipiert. Und da spielte der Aufwand auf dem Chip eine > wesentliche Rolle. Langfristige Planung war sowieso nicht Intels starke > Seite, weiter als bis zum nächsten Laternenpfahl hat es damals nie > gereicht. Da hast du wohl Recht. Es ging denen um den schnellen Buck und vor allem, die Konkurrenz nieder zu halten. > Dass man mit 8080ern auch Controller implementiert hat ist klar, aber > nicht als vollintegrierte Lösung. Vom Z80 mag es mittlerweile welche > geben, die Rabbits basieren ja darauf, aber das ist eine winzige Nische > und IMHO Masochismus. Masochismus? Der Z80 ist mit ASM deutlich angenehmer zu programmieren, als die AVR-Dinger. Die vielen 8-Bit-Register der AVRs reißens wirklich nicht raus.
Uhu Uhuhu schrieb: > Masochismus? Der Z80 ist mit ASM deutlich angenehmer zu programmieren, > als die AVR-Dinger. Ansichtssache. Ich hatte u.A. auch mit Z80 zu tun und mir geht es exakt andersrum, wenn man von der Adressraumthematik mal absieht. Seit ich registerorientierte Architekturen verwendet habe (fing mit 68000 an, davor 6502 und auch mal 6809) besitze ich eine gewisse Abneigung gegen Akkumulatoren. Wobei das in überschaubarer Assembler-Programmierung auf 8-Bit-µC noch leidlich akzeptabel wäre. Aber auch hier ist mir AVR lieber als 8051. Mein Favorit damals war Z8, als sehr sauber konstriertem registerorientiertem 8-Bitter. Aber den hat es mit seiner Beschränkung auf 256 Bytes Daten später bös erwischt und der Z8e ist zwar ähnlich, verletzt aber mein ästhetisches Empfinden ob des Hybrids aus 8bit und 12bit Datenadressierung. > Die vielen 8-Bit-Register der AVRs reißens wirklich > nicht raus. Für Assembler hätten es auch 16 getan, der Rest ist ein Tribut an C. Was auch noch mitspielt: Seit der Implementierung von C Compilern betrachte ich ISAs aus alter Gewohnheit immer auch in Hinblick auf entsprechende Umsetzbarkeit, und da ist AVR bis auf die Adressraumproblematik der Z80 weit überlegen. Die Adressraumthematik betrifft hauptsächlich C-Programme und Assembler-Programme auf beispielsweise 8051 bei mehr als 256 Bytes Daten. Letzteres muss man sich heute m.E. nicht mehr antun. Eine Trennung in lineare Code- und Datenadressräume wie bei den AVRs ist in Assembler-Programmierung vergleichsweise unproblematisch. Gebankte ISAs wie die PICs (12,14,16) habe ich hier höflicherweise nicht mit angesprochen. Die sind m.E. sowohl für Asm als auch für C ein Graus.
PS: Das mit dem Masochismus war insbesondere auf die Rabbit-Module bezogen, die mit ihren externen Speicherkapazitäten direkt mit 32-Bittern konkurrieren. Und fällt mir wirklich kein einziger Grund ein, der für so etwas spricht. Dass Zilog mit ZNEO noch einen draufgesetzt hat, indem sie die Z80 auf 32 Bits erweitert haben, macht es auch nicht besser. Aber da jeder andere Versuch Zilogs mit 16- und 32-Bittern kläglich absoff, blieb wohl nichts anderes übrig.
Uhu Uhuhu schrieb: > Da hast du wohl Recht. Es ging denen um den schnellen Buck und vor > allem, die Konkurrenz nieder zu halten. Sorry dass ich jetzt etwas persönlicher werde: Hast du die Fähigkeit völlig verloren, dich neutraler auszudrücken? Klar wollte Intel damit Geld verdienen (worin ich keinen Makel erkennen kann), aber die Wertung "niederhalten" ist hier erstens ziemlich unangebracht und zweitens absurd. Als Intels µC-Schiene rauskam, erst 8048, dann 8051, war Intel nur einer unter vielen Herstellern ähnlicher Grössenordnung. Den IBM-PC gab es ja noch nicht. Den Sektor integrierter Mikrocontroller dominierte mit respektablem Abstand zum Rest Fairchilds 3850/F8. Intels 8048 wurde unübersehbar davon inspiriert. Intels 8051 war auch später nicht die dominierende µC Architektur. In Stückzahlen betrachtet. Das war eher Motorola/Freescale 6805. Der 8096 als designierter Nachfolger der 8048/51 soff recht bald wieder ab. Intel hat ohnehin erstaunlich viel versemmelt, selbst bei dem lange Zeit grossen Erfolg i960 haben sie das letztlich auch noch geschafft.
> Dass Zilog mit ZNEO noch einen draufgesetzt hat, indem sie die Z80 auf > 32 Bits erweitert haben, macht es auch nicht besser. Korrektur: ZNEO ist frisch und sauber, wie schon der Name sagt. Gemeint war Z380.
A. K. schrieb: > Uhu Uhuhu schrieb: > >> Da hast du wohl Recht. Es ging denen um den schnellen Buck und vor >> allem, die Konkurrenz nieder zu halten. > > Sorry dass ich jetzt etwas persönlicher werde: Hast du die Fähigkeit > völlig verloren, dich neutraler auszudrücken? Hä? Was gibts da neutraler auszudrücken? > Klar wollte Intel damit > Geld verdienen (worin ich keinen Makel erkennen kann), aber die Wertung > "niederhalten" ist hier erstens ziemlich unangebracht und zweitens > absurd. Jetzt komm mal wieder auf den Teppich. Was glaubst du wohl, warum die deutlich bessere Architektur des 68000 dem Intel-Scheißdreck unterlag? Ersterer erschien sogar etwas früher am Markt. Da ist geschoben worden und zwar kräftig... > Als Intels µC-Schiene rauskam, erst 8048, dann 8051, war Intel nur einer > unter vielen Herstellern ähnlicher Grössenordnung. Das ökonomische Zugpferd war der 8086. Das zeichnete sich bereits Ende der 70er ab. Im Übrigen kam der erste Mikroprozessor überhaupt - der 4-Bit-Typ 4004 - von Intel. Sie hatten gegenüber der Konkurrenz einen technologischen Vorsprung und je mehr der schrumpfte, um so mehr bemühte man "kaufmännische" Tricks. Dieser "Tradition" sind sie bis heute treu geblieben - oder was meinst du, warum die EU denen kürzlich eine Strafe von schlappen 1,06 Milliarden Euro aufgebrummt hat? > Den IBM-PC gab es ja > noch nicht. Den Sektor integrierter Mikrocontroller dominierte mit > respektablem Abstand zum Rest Fairchilds 3850/F8. Intels 8048 wurde > unübersehbar davon inspiriert. Das Kleinzeug war nicht das, was die Riesenumsätze versprach.
Uhu Uhuhu schrieb: > Jetzt komm mal wieder auf den Teppich. Was glaubst du wohl, warum die > deutlich bessere Architektur des 68000 dem Intel-Scheißdreck unterlag? > Ersterer erschien sogar etwas früher am Markt. Da ist geschoben worden > und zwar kräftig... Und wer hätte da wen schieben sollen? Willst du damit sagen, Intel hätte IBM bestochen, den künftigen Milliardenumsatz voraussehend? IBM hatte sich für 8088 entschieden, die Gründe sind bekannt. Dass 68000 die klar besser Architektur war ebenfalls bekannt, IBM auch. Sowas ist aber nicht immer das einzige Kriterium. Schon garnicht für eine Firma wie IBM, deren Entscheidungen in den 70ern hautsächlich von der Sorge geprägt waren, das höchst lukrative Geschäft mit den Mainframes nicht zu gefährden. Auch aus dieser Sicht war 8088 für IBM sinnvoller als 68000. Aus diesem Grund hatte IBM schon die RISC-Entwicklung zwar erfolgreich betrieben aber im Haus letzlich dann unterdrückt. Nur um das klar zu stellen: Ich rede von damals, nicht von heute. Dass Intel später massiv Druck ausgeübt hat um aufkommende Konkurrenz zu bekämpfen ist mir bekannt. "Niederhalten" kannst du aber nur von oben, und "oben" ist Intel im ursprünglich betrachteten µC-Sektor nie gewesen. > Das ökonomische Zugpferd war der 8086. Noch nicht. Zum Zeitpunkt des 8048 war der 8086 nicht existent, mit dem 8051 kommerziell eine von vielen Architekturen und ohne jegliche Dominanz. Das änderte sich erst in den 80ern. > der 70er ab. Im Übrigen kam der erste Mikroprozessor überhaupt - der > 4-Bit-Typ 4004 - von Intel. Sie hatten gegenüber der Konkurrenz einen > technologischen Vorsprung Sie waren schneller da, aber ein dauerhafter technologischer Vorsprung war das keineswegs. So war beispielsweise der erste Mikroprozessor mit einer einzigen Spannungsversorgung nicht von Intel. Ende der 70er bis Anfang der 80er waren Z80 und 6502 die dominanten 8-Bit Produkte (z.B. Apple, Commodore, CP/M-Rechner), beide nicht von Intel. > Das Kleinzeug war nicht das, was die Riesenumsätze versprach. Niemand hatte damals den durchschlagenden Erfolg des IBM-PC vorausgesehen. Ohnehin waren und sind, wie schon erwähnt, Intels strategische und prophetische Fähigkeiten aktenkundig miserabel (auch noch anno Itanium vs AMD64) und davon hätte es viel bedurft, um mit einer Bestechung von IBM die Zukunft des x86-Geschäfts vorauszusehen. Musst du wirklich alles ins Denkmuster einer Verschwörung pressen, ob es passt oder nicht? In allen geschichtlichen Ereignissen im Nachhinein stets und immer gezielte Planung zu sehen, ist für mich ein Denkmuster von eher religiösem Charakter. Die Realität kennt beides. Mal geplant und erfolgreich, mal geplant und versemmelt, oft jedoch geschehen Dinge einfach ohne viel Plan und Strategie.
Apropos Strategie: Diese vermutete Weitsicht lässt schon deshalb ausschliessen, weil Intel die 8086 Architektur ursprünglich nur als kurzlebiges Zwischenspiel zur strategisch entscheidenden 32bit Architektur iAPX432 vorgesehen hatte. In der Intel ziemlich viel Geld versenkt hat.
A. K. schrieb: > Uhu Uhuhu schrieb: > >> Jetzt komm mal wieder auf den Teppich. Was glaubst du wohl, warum die >> deutlich bessere Architektur des 68000 dem Intel-Scheißdreck unterlag? >> Ersterer erschien sogar etwas früher am Markt. Da ist geschoben worden >> und zwar kräftig... > > Und wer hätte da wen schieben sollen? Ich kann nur sagen, daß damals ein Prof. meinte, der 68000 sei zweifellos das bessere Teil, Intel würde aber das Rennen machen, weil sie bessere Connections hätten. Und so kam es... > IBM hatte sich für 8088 entschieden, die Gründe sind bekannt. Dass 68000 > die klar besser Architektur war ebenfalls bekannt, IBM auch. Tja, da gibt es einen gewissen Parallelfall... Digital Research Inc. war davon ausgegangen, mit seinem MP/M locker das Rennen zu machen. Dann kam ein gewisser Bill Gates, der ein Betriebssystem MSDOS "erfunden" hatte - das in Wirklichkeit ein schlecht zusammengestoppelter CP/M-Klon war, den er irgendwelchen Hackern abgekauft hatte. > Sowas ist > aber nicht immer das einzige Kriterium. Schon garnicht für eine Firma > wie IBM, deren Entscheidungen in den 70ern hautsächlich von der Sorge > geprägt waren, das höchst lukrative Geschäft mit den Mainframes nicht zu > gefährden. Auch aus dieser Sicht war 8088 für IBM sinnvoller als 68000. > Aus diesem Grund hatte IBM schon die RISC-Entwicklung zwar erfolgreich > betrieben aber im Haus letzlich dann unterdrückt. Der 68000 war nicht viel leistungsfähiger, als der 8086, das Mainframeargument ist nicht sehr stichhaltig. Den Ausschlag gaben die Geldgeber, die in Intel investiert hatten und im Hintergrund schoben... > Nur um das klar zu stellen: Ich rede von damals, nicht von heute. Dass > Intel später massiv Druck ausgeübt hat um aufkommende Konkurrenz zu > bekämpfen ist mir bekannt. "Niederhalten" kannst du aber nur von oben, > und "oben" ist Intel im ursprünglich betrachteten µC-Sektor nie gewesen. Du läßt den finanziellen Aspekt außer Acht - der war der ausschlaggebende Punkt, nicht die Technik. >> Das ökonomische Zugpferd war der 8086. > > Noch nicht. Zum Zeitpunkt des 8048 war der 8086 nicht existent, mit dem > 8051 kommerziell eine von vielen Architekturen und ohne jegliche > Dominanz. Das änderte sich erst in den 80ern. S.o. >> der 70er ab. Im Übrigen kam der erste Mikroprozessor überhaupt - der >> 4-Bit-Typ 4004 - von Intel. Sie hatten gegenüber der Konkurrenz einen >> technologischen Vorsprung > > Sie waren schneller da, aber ein dauerhafter technologischer Vorsprung > war das keineswegs. Das hatte ich oben geschrieben... Du hättest auch vollständig zitieren können. > So war beispielsweise der erste Mikroprozessor mit > einer einzigen Spannungsversorgung nicht von Intel. Ende der 70er bis > Anfang der 80er waren Z80 und 6502 die dominanten 8-Bit Produkte (z.B. > Apple, Commodore, CP/M-Rechner), beide nicht von Intel. Ja eben. Und warum haben sie sich fast immer gegen bessere Produkte durchgesetzt? >> Das Kleinzeug war nicht das, was die Riesenumsätze versprach. > > Niemand hatte damals den durchschlagenden Erfolg des IBM-PC > vorausgesehen. Ohnehin waren und sind, wie schon erwähnt, Intels > strategische und prophetische Fähigkeiten aktenkundig miserabel (auch > noch anno Itanium vs AMD64) und davon hätte es viel bedurft, um mit > einer Bestechung von IBM die Zukunft des x86-Geschäfts vorauszusehen. Daß da was kommen mußte, was die 8080 in Büromaschinen u.Ä. in ganz absehbarer Zeit ersetzt, war 1975 völlig klar. Die Dinger waren hinten und vorne zu klein. > Musst du wirklich alles ins Denkmuster einer Verschwörung pressen, ob es > passt oder nicht? Verschwörung? Hast du schonmal kapitalistische Wirtschaft irgendwo ohne Verschwörung gesehen - außer im Schulbuch? > In allen geschichtlichen Ereignissen im Nachhinein > stets und immer gezielte Planung zu sehen, ist für mich ein Denkmuster > von eher religiösem Charakter. Wenn du keine Argumente hast, wirst du ausfällig... > Die Realität kennt beides. Mal geplant > und erfolgreich, mal geplant und versemmelt, oft jedoch geschehen Dinge > einfach ohne viel Plan und Strategie. Nätürlich hätte es anders kommen können. Es kam aber so, wie 1975 Leute mit etwas Einblick offenbar schon ganz gut voraussehen konnten, Teufel aber auch...
Intel hatte 1975 tatsächlich vorausgesehen, dass ihr 8080 nicht ewig das Flaggschiff sein kann. Und hat ein grosses Projekt gestartet, um den Rechnermarkt der 80er zu dominieren. Mit dem schon erwähnten iAPX 432.
@ A.K. @ Uhu, bekommt Ihr noch die Kurve zum Thema? Michael
War da noch was offen? Aber keine Sorge, für mich ist Schluss. Denn was 8051-Programmierung mit Intel x86 zu tun hat erschliesst sich mir auch nicht.
A. K. schrieb: > Aber keine Sorge, für mich ist Schluss. Denn was 8051-Programmierung mit > Intel x86 zu tun hat erschliesst sich mir auch nicht. Soll ich dir auf die Sprünge helfen? Beide haben eine Maschinensprache, die man in ASM programmieren kann :-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.