Forum: Offtopic Stoßt man mit C an Grenzen?ASM von Vorteil?


von Taser (Gast)


Lesenswert?

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

von Benedikt K. (benedikt)


Lesenswert?

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.

von Taser (Gast)


Lesenswert?

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ß

von Sascha (Gast)


Lesenswert?

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.

von Uhu U. (uhu)


Lesenswert?

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.

von Phil J. (sunflower_seed)


Lesenswert?

C ist von Vorteil, wenn du Software erstellst, die andere auch verstehen 
sollen.
Bei Assembler dauert das immer nen bisschen länger.

von Taser (Gast)


Lesenswert?

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ß

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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

von Sven P. (Gast)


Lesenswert?

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?

von gast (Gast)


Lesenswert?

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!

von Sven P. (Gast)


Lesenswert?

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 
:-)

von Peter D. (peda)


Lesenswert?

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

von Bastl (Gast)


Lesenswert?

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?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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

von mr.chip (Gast)


Lesenswert?

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?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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

von Uhu U. (uhu)


Lesenswert?

und

- wenn man in Maschinencode hinein debuggen muß, zu dem man keinen
  Quelltext hat.

von (prx) A. K. (prx)


Lesenswert?

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.

von Bastl (Gast)


Lesenswert?

>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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Sven P. (Gast)


Lesenswert?

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.

von Uhu U. (uhu)


Lesenswert?

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...

von (prx) A. K. (prx)


Lesenswert?

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.

von Axel (Gast)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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?

von Uhu U. (uhu)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

von Uhu U. (uhu)


Lesenswert?

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 (prx) A. K. (prx)


Lesenswert?

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.

von Uhu U. (uhu)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Uhu U. (uhu)


Lesenswert?

War die (angebliche) Grundidee der Harvard-Architektur nicht, Code und 
Daten physikalisch zu trennen?

von Wissender (Gast)


Lesenswert?

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!

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Uhu U. (uhu)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Uhu U. (uhu)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

> 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.

von Uhu U. (uhu)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Uhu U. (uhu)


Lesenswert?

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...

von (prx) A. K. (prx)


Lesenswert?

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.

von Michael W. (retikulum)


Lesenswert?

@ A.K.
@ Uhu,

bekommt Ihr noch die Kurve zum Thema?

Michael

von (prx) A. K. (prx)


Lesenswert?

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.

von Uhu U. (uhu)


Lesenswert?

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
Noch kein Account? Hier anmelden.