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.
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!
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 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(inti=0;i<100;i++){
2
intbit=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...
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.
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. 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 :-)
