Forum: Mikrocontroller und Digitale Elektronik Was benötige ich um einen 8086 in Assembbler zu programmieren ?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Michael S. (misax)


Bewertung
-5 lesenswert
nicht lesenswert
hallo;
ich habe vor einiger Zeit damit begonnen ATTINYs uns ATMEGAs in 
Assembler zu programmieren und benutze dafür Arduinos als Programmer.
Jetzt möchte ich mich an 8086 Prozessoren heranwagen. Was benötige ich 
denn hierzu ? Welcher Assembler ist zu empfehlen und was für einen 
Programmer brauche ich ?
Danke

von (prx) A. K. (prx)


Bewertung
3 lesenswert
nicht lesenswert
Welches Zielsystem? Nicht nur Prozessor, auch der Rest.

von Michael S. (misax)


Bewertung
-3 lesenswert
nicht lesenswert
gar keins. ich möchte mir einen Prozessor für ein paar Euro kaufen, ihn 
auf ein Breadboard stecken und loslegen, so wie ich es ja auch mit den 
Attinys und Atmegas gemacht habe.

von MalleWal (Gast)


Bewertung
6 lesenswert
nicht lesenswert
Michael S. schrieb:
> ich möchte mir einen Prozessor für ein paar Euro kaufen

Die ist aber schon Bekannt welchen Unterschied es zwischen einen 
Microcontroller und einem Mikroprozessor gibt.

So wird das nichts.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
7 lesenswert
nicht lesenswert
Michael S. schrieb:
> ich möchte
Ja, haben wir denn schon Weihnachten?

> mir einen Prozessor für ein paar Euro kaufen, ihn auf ein
> Breadboard stecken und loslegen, so wie ich es ja auch mit den Attinys
> und Atmegas gemacht habe.
Du solltest dir zuerst mal ansehen, was du alles drumherum brauchst, um 
so einen Prozessor zum Laufen zu bekommen. Du solltest dich also ein 
klein wenig, wenigstens ein klitzekleines Stück in die Systemarchitektur 
einarbeiten.

"Ich möchte!" allein reicht da nicht aus.

von fritz (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Nicht so einfach! Der 8086 hat im Gegensatz zum AVR weder Peripherie, 
noch RAM noch (Flash-)ROM auf dem Chip. Es gab zwar 8086 mit Peripherie 
(V50, 80186), dann fehlt aber immer noch RAM und ROM.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael S. schrieb:
> gar keins. ich möchte mir einen Prozessor für ein paar Euro
> kaufen, ihn auf ein Breadboard stecken und loslegen, so wie ich es ja
> auch mit den Attinys und Atmegas gemacht habe.

Na dann, Hauptsache du weisst, wie du das dann assemblierte Programm in 
den Speicher bekommst, den du an den 8086 dranhängen musst.

Du hast einen Windows-PC unter dem du deinen Assembler ausführen kannst? 
Nimm MASM von Microsoft, Version praktisch egal, alle konnten den 8086. 
Der ist wenigstens umfangreich getestet.

https://www.microsoft.com/en-us/download/details.aspx%3Fid%3D12654

von Ichbins (Gast)


Angehängte Dateien:

Bewertung
6 lesenswert
nicht lesenswert
Mein Simulationsprogramm bringt ein simulierbares und nachbaubares 
minimal-Beispiel mit.
Siehe Anhang.

Proteus 7.

von Anja (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael S. schrieb:
> Welcher Assembler ist zu empfehlen und was für einen
> Programmer brauche ich ?

Der 8086 hat keinen internen Speicher -> du brauchst extern 2 Stück 
8-Bit EProms die Du mit einem EProm Programmer programmierst. (z.B. 
Galep-5).

Assembler habe ich früher (TM) von Intel direkt gehabt.
Aber meistens habe ich mit PL/M-86 (Intel) programmiert.
Später hatte ich dann den Borland TASM. (zusammen mit Turbo-Pascal).

Gruß Anja

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Michael S. schrieb:
> Jetzt möchte ich mich an 8086 Prozessoren heranwagen.

Schlechte Entscheidung.

> Was benötige ich denn hierzu ?

Du benötigst einen Computer mit einem 8086-Prozessor drin. Ein 8088 
dürfte auch funktionieren. Die gibt es auch als Emulatoren.

> Welcher Assembler ist zu empfehlen und was für einen
> Programmer brauche ich ?

Als Assembler brauchst du einen, der 8086-Code ausgeben kann. Die gibt's 
wie Sand am Meer. Der Programmer hängt vom Computer ab; der 8086 enthält 
kein programmierbares ROM.

von Crazy H. (crazy_h)


Bewertung
0 lesenswert
nicht lesenswert
Ichbins schrieb:
> Mein Simulationsprogramm bringt ein simulierbares und nachbaubares
> minimal-Beispiel mit.
> Siehe Anhang.
>
> Proteus 7.

Und wo ist der RAM? Wie bekommst du dein Prog da rein?

von fritz (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Hier http://www.mattmillman.com/projects/8od/ siehst du ungefähr, 
welchen Aufwand du treiben musst. Wahrscheinlich wäre ein ARM Cortex-M3, 
der einen 8086 emuliert, einfacher, billiger und schneller.

von Anja (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Ichbins schrieb:
> Siehe Anhang.

Da werden Erinnerungen wach:
"ISIS" war das Betriebssystem auf dem "MDS" Entwicklungssystem 
(8085-Basiert).

Gruß Anja

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Meinst du wirklich den 8086 oder deinen PC?

Für deinen PC würde ich mal gucken, was Linux da so an Board hat. Mit 
fällt da spontan der GNU Assembler "as" ein. Siehe 
https://www.gnu.org/software/binutils/

Aber um Assembler-Programme auf dem PC starten zu können, musst du sie 
in ein ausführbares Format verpacken, also elf unter Linux bzw. exe 
unter Windows. Dazu könntest du das Hauptprogramm main() in C schreiben 
und nur die gewünschten Teile in Assembler programmieren.

von Ichbins (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Der Z80 ist dem 8086 recht ähnlich. Da gibt es dann noch die ez80 oder 
so ähnlich. Auf jedenfall sind das fertige z80-Mikrocontroller.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Na dann, Hauptsache du weisst, wie du das dann assemblierte Programm in
> den Speicher bekommst, den du an den 8086 dranhängen musst.
Und dann die nächste logische Frage:
"Wo schließe ich da jetzt einen Taster und eine LED an?"

Das hier war ein Versuch von Intel, einen "kleinen" x86 Rechner an den 
Mann zu bekommen:
https://de.wikipedia.org/wiki/Intel_Quark
Wie zu lesen war das Ergbnis wenig erfreulich.

Und dann gibts noch sowas:
https://www.giga.de/zubehoer/raspberry-pi/specials/lattepanda-udoo-x86-up-board-die-x86-boards-im-vergleich/

von Ichbins (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Für deinen PC würde ich mal gucken, was Linux da so an Board hat

Linux hat mit dem 8086 ungefähr soviel zu tun, wie du mit dem 1. 
Weltkrieg.

Beispiele gabs genug und Stefanuss muss mal wieder Murks beisteuern :)

von Stefan ⛄ F. (stefanus)


Bewertung
-2 lesenswert
nicht lesenswert
Michael S. schrieb:
> ich möchte mir einen Prozessor für ein paar Euro kaufen, ihn
> auf ein Breadboard stecken und loslegen, so wie ich es ja auch mit den
> Attinys und Atmegas gemacht habe.

Ja aber doch keinen 8086! Kann man den überhaupt noch kaufen?

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Ein 80186 wäre schon näher dran, aber in DIP gibt's den auch nicht...

von S. Haber (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ichbins schrieb:

> Der Z80 ist dem 8086 recht ähnlich. Da gibt es dann noch die ez80 oder
> so ähnlich. Auf jedenfall sind das fertige z80-Mikrocontroller.

Käfer & Audi-Quattro sind sich auch recht ähnlich.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Ichbins schrieb:
> Linux hat mit dem 8086 ungefähr soviel zu tun, wie du mit dem 1.
> Weltkrieg.

Deswegen habe ich ja geschrieben:
> Meinst du wirklich den 8086 oder deinen PC?
> Für deinen PC würde ich mal gucken, was Linux da so an Board hat.

Sein PC hat sicher einen Prozessor, den der GNU Assembler unterstützt.

Den 8086 kann man ja gar nicht mehr kaufen. Außer vielleicht für 
phantastische Preise aus einem Museum.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Ichbins schrieb:
> Stefanuss muss mal wieder Murks beisteuern

Es gibt tatsächlich einen 8086 Assembler in Linux. Das Paket heißt 
bin86.

: Bearbeitet durch User
von Helmut L. (helmi1)


Bewertung
0 lesenswert
nicht lesenswert

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Ja aber doch keinen 8086! Kann man den überhaupt noch kaufen?

Stefan ⛄ F. schrieb:
> Den 8086 kann man ja gar nicht mehr kaufen.

https://www.ebay.de/b/Intel-8086/bn_7005685329

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Na dann ist ja gut, dass ich den passenden Assembler gefunden habe.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
> und was für einen Programmer brauche ich ?

Jemand hat dazu EPROMs und Galep empfohlen. Statt EPROMs kann man auch 
Statische RAMs (z.B. 6264) mit Pufferbatterie verwenden.

Oder EEPROMs, wie den 28C64.

: Bearbeitet durch User
von Helmut L. (helmi1)


Bewertung
0 lesenswert
nicht lesenswert
Wenn man einen PC Assembler + Linker verwendet der Programme fuer den PC 
assembliert gibt es noch eine weiters Problem.
Das EXE File laesst sich nicht direkt in ein EPROM brennen.
Dazu braucht man noch einen Locater der das Ladeformat des EXE-Files 
fuer das Eprom aufbereitet. Das muss die Teile fuer das CSeg DataSeg und 
Stacksegment trennen.  Ein PC Assembler/ Linker geht naemlich davon aus 
das ueberall nur RAM ist. Eprom kennt der erstmal nicht.

von dirk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gruss zum Sonntag

Ein (zwei) statische RAM mit Batterie
ginge auch, etwas getüftelt
ginge die Programmierung auch mit einem Arduino. s. Schiftregister. Das 
wäre weniger Aufwand als mit EPRoms.
Ich habe mal mitbekommen, dass der 8086 Mangelware wäre!

Noch einen schönen Sonntag.
Dirk St.

von Magnus M. (magnetus) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Anja schrieb:
> du brauchst extern 2 Stück
> 8-Bit EProms die Du mit einem EProm Programmer programmierst.

Bei 2 Byte Programmspeicher wird das aber ein sehr überschaubares 
Progrämmchen :D

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Michael S. schrieb:
> Welcher Assembler ist zu empfehlen und was für einen
> Programmer brauche ich ?

Als Assembler ist sicherlich der Flatassembler geeignet.
Als Host benötigt der min ein 32Bit System, Code kann er auch für die 
16Bit x86 erzeugen.
Als Programmer: Ein (historischer?) EPROM Programmer.

Auch evtl. für Hardcorebastler interessant:
https://de.wikipedia.org/wiki/MenuetOS

von bingo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe meine ASM-Programme früher (zu meinen Windows-Zeiten :( ) immer 
mit A86 und D86 :) gemacht (16-bit), die gibt es auch in einer 
32-bit-Version.

von dirk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
PS. Das mit dem SRAM war beim Atari Portfolio, ein 8088 er, als 
Speicherkarte mit Batterie realisiert.
Dirk St

von dirk (Gast)


Bewertung
2 lesenswert
nicht lesenswert
debug und edlin sind ja bei Windows10 nicht mehr dabei
😉
Dirk St

von Einer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
dirk schrieb:
> debug und edlin sind ja bei Windows10 nicht mehr dabei

Noch ein Grund den Mist nicht zu wollen.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Den 8086 kann man ja gar nicht mehr kaufen. Außer vielleicht für
> phantastische Preise aus einem Museum.

Auf ebay kriegst du die fast für lau. Notfalls russisch.
Es sei denn, du suchst einen i7-8086K.

von c-hater (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Michael S. schrieb:

> ich habe vor einiger Zeit damit begonnen ATTINYs uns ATMEGAs in
> Assembler zu programmieren und benutze dafür Arduinos als Programmer.

Was du als Programmer benutzt, ist für x86 (auch amd64) völlig 
irrelevant.

Das sind halt typisch keine µC mit eingebautem Flash, sondern CPUs, die 
auf einen externen Speicher zugreifen möchten/müssen.

Dein Programm musst du also irgendwie auf den Speicher bekommen, auf den 
die Dinger anfänglich zugreifen. Das ist in erster Näherung das 
BIOS/UEFI-ROM. Dieser ist allerdings bei typischen Maschinen Flash, kann 
also programmiert werden.

Das wirst du aber nicht wirklich wollen...

Denn damit läßt du die Maschine alles vergessen, was sie mal konnte. 
Dann hast du erstmal nix außer der nackten CPU und eine wenig ROM, in 
dem dein Programm steht. Du kannst erstmal auf rein garnix weiter 
zugreifen, nichtmal auf den RAM, geschweige denn IO.

Nur dann, wenn du wirklich ganz unten anfangen willst, dann bist du an 
dieser Stelle richtig, vermutlich nichtmal dann, denn dein erstes 
Programm muß schon soweit funktionieren, dass du darüber zumindest noch 
eine geänderte Version desselben in das BIOS/UEFI flashen könntest. Es 
ist sehr, sehr unwahrscheinlich, dass dir ein solches Programm im ersten 
Anlauf gelingt...
Und wenn nicht, hast du einen völlig unbrauchbaren Ziegel produziert. 
Der einzige Ausweg ist dann: Auslöten des Flash und Programmieren an 
einer externen Station.

Du solltest also viele Ebenen höher beginnen...

In einem BIOS- oder UEFI-Bootloader auf einem Massenspeicher. Hier 
kannst du fast beliebige Scheiße programmieren, es läßt sich so ziemlich 
alles OHNE Lötmaßnahmen auch wieder fixen. Aber nicht wirklich alles: 
auch hier gibt es durchaus noch Chancen, einen PC zu bricken. Das sind 
dann die allseits beliebten Bugs im Bootsystem. Der Größte ist natürlich 
UEFI secure boot. Das solltest du also als erstes deaktivieren, bevor du 
dem UEFI eigene Bootloader (als einzige Auswahl) anbietest...

> Welcher Assembler ist zu empfehlen

Egal, jeder, der funktioniert, ist gut genug.

> und was für einen Programmer brauche ich ?

DU brauchst erstmal keinen. Erst in ferner Zukunft, wenn du ganz unten 
angekommen bist, könnte ein generischer Flash-Programmer u.U. hilfreich 
sein...

von 8086 fan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael S. schrieb:
> Jetzt möchte ich mich an 8086 Prozessoren heranwagen. Was benötige ich
> denn hierzu ?

Um die Basis-Hardware nicht neu erfinden zu müssen, wäre das schon mal 
eine Basis:
http://www.mattmillman.com/projects/8od/

Wie schon mehrfach bemerkt, läuft darauf kein Betriebsystem. Um auf 
unterster Assembler-Ebene damit zu spielen, ist das aber auch nicht 
nötig.

Die Hinweise auf BIOS usw. sind nur im Zusammenhang mit einer 
DOS/Windows/Linux/was weiss ich von Interesse.

SSV hat wohl einige DIL/NetPC im Sortiment, die aber keinen klassischen 
8086 sondern mehr oder weniger rückwärts kompatible SoC auf 8086 Basis 
benutzen.

Beck hatte vor vielen Jahren auch mal ein 8086 Modul mit angepasstem DOS 
im Angebot. Da lässt sich evtl. bei ebay noch was finden.

Auch wenn der Sinn deines Vorhabens von vielen angezweifelt wird, wenn 
Du dich dafür interssierst: Viel Spass damit!

von dirk (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Von mir auch viel Spaß damit.
Bevor man die umfangreiche Arbeit mit Bios, Xbios, Dos anfängt, würde 
ich ein
einfaches Forth System, aus meiner Erfahrung heraus, empfehlen, das ist 
Assembler und Hardware nah.
Bei mir lief das eForth auf dem 8088 er recht gut.

Dirk St

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-2 lesenswert
nicht lesenswert
>> Jetzt möchte ich mich an 8086 Prozessoren heranwagen.
> Schlechte Entscheidung.
Was bist Du denn schon wieder für ein Prolet, daß Du das behaupten 
kannst... wenn er mit dem 8086 spielen will, dann lass ihn doch.

Übrigens, ein bißchen RAM hat er, in Form von Registern. Das reicht aber 
natürlich nicht aus, um ein Programm darauf zum Laufen zu bekommen.

Allerdings würde ich dafür einen 80386/80486 empfehlen, bekommt man auch 
noch recht problemlos mit kompletten Mainboards und Entwicklungsumgebung 
unter DOS... auf dem Steckbrett ist sowas schwer zum Laufen zu bekommen.

Der Vorteil bei so alten Systemen ist, daß du noch keine Probleme mit 
irgendwelchen Rechteverwaltungen etc. hast - nach dem Start des 
Programms gehört die Hardware komplett dir und macht jeden Scheiß, den 
man möchte. Man könnte sich also irgendwelche ISA-Hardware-Interfaces 
zusammenbauen wie man möchte und kann sowas in dem Ding betreiben. Oder 
den Parallel- bzw. Serial-Port nutzen, ohne daß einem irgendwelche 
M$-Software dazwischenfunkt.

Nachteil, man muß sich ein wenig an die Konventionen von DOS und seine 
Dateiformate (COM oder EXE) halten, wenn man nicht gleich ein komplettes 
Betriebssystem mit Assembler usw. selbst entwickeln möchte.

Ich hab vor etlichen Jahren ein 8086-System auf Lochraster 
zusammengebastelt. Würde ich heute dank weit verbreiteter µCs nicht mehr 
machen - so ein AVR ist da wesentlich unkomplizierter und insofern man 
nicht massig RAM oder so braucht auch um ein vielfaches schneller.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
4 lesenswert
nicht lesenswert
Ben B. schrieb:
> vor etlichen Jahren
Das trifft es ganz gut. Wer alte Technik tiefgehend kennenlernen will, 
ohne daraus jemals großartigen Nutzen ziehen zu können, der ist mit 
dieser 40 Jahre alten Steinzeitplattform gut bedient.

Denn es bringt eben für das tägliche Leben so gut wie nichts, wenn man 
zwar den uralten 8086 Assembler mit dem einen Akku und den anderen paar 
Registern kennt(**), aber eben nicht die "neuen" und erweiterten 
CISC-Befehle, die erst auf den nachfolgenden Generationen 
286/386/486/usw/usf implementiert wurden.
Und wenn mir dann wieder das vermurkste Segment:Offset Zeugs in den Kopf 
kommt, dann freue ich mich nachträglich nochmal über die Zeit mit dem 
68k-Prozessor (in Form des 68332) mit dem hübschen orthogonalen 
Befehlssatz und dem linearen Adressraum.

(**) ich musste Bibliotheken für Fließkommaarithmetik auf einem 80386 in 
Assembler programmieren. Das hat mich geprägt. Ich sehe seither Rechner 
mit nur 1 Rechenregister als einen Irrweg der Geschichte an. Der 8051 
zählt auch dazu, genauso wie der 8048. Und auch der PIC.

Wer für die Zukunft was lernen will, der sollte sich in der selben Zeit 
(die man ja nur 1x zu durchleben hat) besser bei aktuellen ARM-µC 
umsehen. Denn die gibts für kleines Geld mit Flash und RAM an jeder 
Ecke. Zudem kommt man da auf kürzestem Weg direkt an die Pins und die 
Register und kann umfangreich mit der Umwelt interagieren.


>>> Jetzt möchte ich mich an 8086 Prozessoren heranwagen.
>> Schlechte Entscheidung.
> Was bist Du denn schon wieder für ein Prolet, daß Du das behaupten
> kannst...
Sogar du selbst sagst doch, dass du die dafür nötige Zeit besser mit 
anderen Rechnerarchitekturen verbringen würdest.

> wenn er mit dem 8086 spielen will, dann lass ihn doch.
Anhand der Fragestellung ist zumindest mir vollkommen klar, dass Michael 
S. (misax) nicht weiß, worauf er sich einlässt. Sonst würde er nicht 
nach einem "Programmer für einen 8086" fragen...

von S. R. (svenska)


Bewertung
3 lesenswert
nicht lesenswert
Ben B. schrieb:
>>> Jetzt möchte ich mich an 8086 Prozessoren heranwagen.
>> Schlechte Entscheidung.
> Was bist Du denn schon wieder für ein Prolet, daß Du das behaupten
> kannst... wenn er mit dem 8086 spielen will, dann lass ihn doch.

Ich habe nicht gesagt "du Idiot, lass das bloß sein, du depperter 
Vogel", sondern ich habe zum Ausdruck gebracht, dass bei dem gegebenen 
Kenntnisstand des TO der 8086 eine schlechte Wahl ist.

Es gibt bessere Alternativen, z.B. der von mir genannte 80186. Oder die 
ganze 8-Bit-Welt mit 6502, 6809 oder Z80, wo das ganze Youtube voll ist 
mit Anleitungen und Erklärungen.

Aber nein, es muss der 8086 sein. Schlecht anzusteuern, ohne viel 
zusätzliche Hardware erstaunlich nutzlos und trotzdem sehr komplex.

> Allerdings würde ich dafür einen 80386/80486 empfehlen, bekommt man auch
> noch recht problemlos mit kompletten Mainboards und Entwicklungsumgebung
> unter DOS... auf dem Steckbrett ist sowas schwer zum Laufen zu bekommen.

Eben: Kein 8086, sondern irgendwas "PC-artiges", wenn es denn ein 
fertiges Gerät sein soll. Und PCs mit 8086 sind ... schwierig. Auch 
davon ist Youtube voll. Vielleicht will der TO ja auch ein altes Modem 
als Basis nehmen, wer weiß...

Der 8086 bleibt eine schlechte Entscheidung.
Kann man machen, geht aber deutlich besser.

von Andy D. (rackandboneman)


Bewertung
0 lesenswert
nicht lesenswert
Ben Eater hat tolle Videotutorials mit einem 6502 auf einem Breadboard 
veröffentlicht. Das ist auch kein Mikrocontroller. Warum soll das nicht 
auch mit dem 8086 oder 8088 gehen? Haben Leute auch schon mit dem 68000 
hinbekommen.

Von "eher nicht möglich bzw wird keinen Spass machen" würde ich erst bei 
den x86 Prozessoren der Post-5-Volt-Ära sprechen, wo langsam AGTL+, 
schräge Speicherbusse und ätzende Anforderungen bzgl Stromversorgung und 
Entkopplung ins Spiel kommen.

Wenn man einen 8088/8086-Computer ausschlachtet, sollte man darauf 
achten den i8284 ebenfalls zu behalten. Und evtl den UART usw.

Elektor hatte mal einen Schachcomputer auf 8086 Basis, so furchtbar 
komplex war der auch nicht.

Den 80188 findet man übrigens nicht selten im Druckerschrott. Ist halt 
PLCC, muss man halt einen Adapter machen.

Wenn ich so ein Projekt vorhätte ... naja, da würde ich als erstes nach 
einem gangbaren Monitorprogramm und einem bare-metal-tauglichen 
C-Compiler Ausschau halten.

Die Tatsache dass hier der Unterschied Minimum und Maximum mode beim 
8086/8088 noch nicht erwähnt wurde gibt mir erst recht das Gefühl hier 
wissen die meisten noch weniger als Ich wovon sie schreiben :)

von dirk (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Gruss

z.B.: https://www.eeeguide.com/minimum-mode-configuration-of-8086/

Ja das "war" ein besonderer Aspekt. Wohl aus der Historie
 - 8080/8085 und den Konditionen.
Die gegenüber Stellung der 16/32
Bitter von Elektor fand ich damals gut.
Bei Schachcomputern gabs vorher den RCA1802, und den gibts immer noch. 
Aber nein Danke bei dem ist
der Programmierer der Assembler.

Dirk St

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

muss es unbedingt ein 8086 sein?
Motorola 68000 geht auch?
Dann könntest du einen Amiga 500 organisieren, hättest alles beisammen 
und könntest sofort loslegen. Am Ende räumst du bei allen Grafikdemos 
ab. :-)

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert

von PittyJ (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Was braucht man für 8086 Assembler?
Geduld, Leidensfähigkeit, Geduld, Kaffee, einen Anflug an Masochismmus, 
Geduld ...

Ich habe damals diverse Architekturen auch in Assembler programmiert. 
Aber der 8086 war der schlechteste. Der hat überhaupt keinen Spass 
gemacht.
Für Geld kann man das tun. Aber als Hobby in der Freizeit? Nein.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Andy D. schrieb:
> Wenn man einen 8088/8086-Computer ausschlachtet, sollte man darauf
> achten den i8284 ebenfalls zu behalten. Und evtl den UART usw.

Und RAM, und ROM, und Netzteil....

also eigentlich den ganzen PC am Stück

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
Wenn man einen klassischen Mikroprozessor kennen lernen will, würde ich 
mal eher einen 8 Bitter wie den Z80 oder den 6502 in den Raum werfen. 
Damit ist der Schaltungsaufwand viel geringer.

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Bewertung
0 lesenswert
nicht lesenswert
Also für den 8085 kann ich das Intel Development Kit empfehlen...
http://www.wolfgangrobel.de/museum/mcs85.htm

Etwas Vergleichbares gab es auch als SDK-86, kann man googeln, hab ich 
leider nicht... (wer's abgeben will... ;-) )

An den Development Kits kann man gut erkennen, welchen Aufwand man 
hardwaretechnisch treiben muss, um ein halbwegs sinnvolles 
Entwicklungssystem hinzubekommen.

Einem Anfänger, der sich partout mit alten Prozessoren auseinandersetzen 
möchte, würde ich eher ein Z80-System oder ein 6502-System empfehlen.

http://www.wolfgangrobel.de/sbc/junior2.htm
http://www.wolfgangrobel.de/sbc/mpf1.htm

...so, wie Stefanus bereits schrieb.

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
Michael S. schrieb:
> Jetzt möchte ich mich an 8086 Prozessoren heranwagen.

Was soll das bringen, außer der Erkenntnis, daß man in Assembler bei 
jeder Architektur komplett von vorne anfangen muß?
Und warum ausgerechnet eine, wo Flash und RAM nicht intern sind?

Sinnvoll wäre dagegen, den Schritt von Assembler zu C/C++ zu wagen.
Denn damit kann man auch größere Projekte realisieren, statt beim "Hello 
World" stehen bleiben zu müssen.
Und dann ist auch ein Wechsel auf eine andere Architektur leichter.

von dirk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gruss am Morgen
Der 65sc/c02 ist spez. empfehlenswert. Als CMos Version des 6502:
quasistaischer Betrieb und damit
bz. Speicher DMA( direct memory access) fähig (war mal eine Applikation 
von Rockwell in der mc). In der Einfachheit und Übersichtlichkeit würde 
der Spass machen. Nahe an den Mikrocontrollern dran. Halt alles seperat 
diskret.

Dirk St

von Martin (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Und wie immer bei solchen Beiträgen ist der TO wohl raus.

von dirk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lässt sich aber gut gliedern, das was hier erwähnt wurde.
Das hat Anschluss an Grundfähigkeiten und einfachen Ideen.
Wie sich der TO darauf
zu seiner Nachfrage entscheidet ?
Halt Grundlagen anwendungsfähiger weise
orientiert organisieren.
Von diskreter CPU bis zu im Array
programmierte CPU oder ein grösserer
Cortex ist so einiges möglich.
Einfach und Aufwand
merke ich hier noch an.

Wünsche Euch eine gute Woche.
Dirk St.

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Bewertung
2 lesenswert
nicht lesenswert
Martin schrieb:
> Und wie immer bei solchen Beiträgen ist der TO wohl raus.

Dabei haben wir noch nicht mal angefangen, den Fragesteller unflätig zu 
beschimpfen... ;-)

von Cyblord -. (cyblord)


Bewertung
1 lesenswert
nicht lesenswert
Wolfgang R. schrieb:
> Martin schrieb:
>> Und wie immer bei solchen Beiträgen ist der TO wohl raus.
>
> Dabei haben wir noch nicht mal angefangen, den Fragesteller unflätig zu
> beschimpfen... ;-)

Hold my beer....

von Soul E. (souleye) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael S. schrieb:

> ich habe vor einiger Zeit damit begonnen ATTINYs uns ATMEGAs in
> Assembler zu programmieren und benutze dafür Arduinos als Programmer.
> Jetzt möchte ich mich an 8086 Prozessoren heranwagen. Was benötige ich
> denn hierzu ? Welcher Assembler ist zu empfehlen und was für einen
> Programmer brauche ich ?

as unterstützt auch 8086: http://john.ccac.rwth-aachen.de:8000/as/

von Sebastian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn die Basis ein DOS-PC sein soll, wurde letztens auf der Seite von 
FreeDOS der besonders einfach gehaltene A72 Assembler vorgestellt: 
https://github.com/swanlizard/a72

von Anarchist (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich würde dann aber mindestens mit einem 386 anfangen. Der kostet heute 
in etwa gleich viel wie ein 8086. Und hat dann noch 32 Bit und Protected 
Mode und so.

von Martin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mann muss bei 32 Bit aber auch mehr Kabel zum RAM und ROM ziehen.

von Laberhannes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der Vorteil beim Z80 gehts auch ohne Ram!
Es gibt irgendwo nette PRogramme, die alleine mit dem Z80 auskommen

von NichtWichtig (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Sowas hatte ich seiner Zeits mit MASM programmiert.

"Download" per Hex-Keyboard :O

https://en.wikipedia.org/wiki/Intel_System_Development_Kit#SDK-86

von xyz (Gast)


Bewertung
2 lesenswert
nicht lesenswert
> muss es unbedingt ein 8086 sein?
> Motorola 68000 geht auch?

8086er zu programmieren ist weder spassig noch mit Lustgewinn verbunden.
Wenn man einen in einer Muelltonne sieht, sollte man ihn tunlichst
dort belassen. Derivate und nachfolgende CPUs wie 286, 386 haben
das auch nicht verbessert.

Statt des 68000er koennte ich einen Z8002 von Zilog empfehlen.
Genauso alt, aber nicht ganz so strunzdumm wie ein 8086 designt.

von Hugo H. (hugohurtig1)


Bewertung
1 lesenswert
nicht lesenswert
Martin schrieb:
> Und wie immer bei solchen Beiträgen

... initiiert der TO den, holt sich eine Tüte Popcorn und wartet ab :-) 
wer sich da wie bekriegt.

von xyz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> ATTINYs uns ATMEGAs in Assembler ... und benutze Arduinos

> ... initiiert der TO den
> bekriegt

Nur geistig Arme verzichten voellig auf ISP und benutzen Bootlader.
Vermutlich kennt er auch das heisse Ende des Loetkolbens nicht.

Da moechte man fast sein Beileid aussprechen.

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
xyz schrieb:
> 8086er zu programmieren ist weder spassig noch mit Lustgewinn verbunden.

Wenn schon schön schräg, dann RCAs 1802. ;-)

von Stupendemys geographicus (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
http://www.mattmillman.com/projects/8od/

Persönlich würde ich ein FPGA board nehmen und auf dem FPGA alles 
implementieren.

https://www.jamieiles.com/80186/

von xyz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> dann RCAs 1802

Ja schon. Nur ist mir der zu Lebzeiten nie ueber den Weg gesprungen.
Der wird ja heute noch aktiv verbaut. Wegen seiner fliegenbeingrossen
Strukturen die ihn wohl recht unempfindlich gegen phoese Raumstralung
machen.

von c-hater (Gast)


Bewertung
-9 lesenswert
nicht lesenswert
Peter D. schrieb:

> Was soll das bringen, außer der Erkenntnis, daß man in Assembler bei
> jeder Architektur komplett von vorne anfangen muß?

Nein, das ist schon wieder so eine unsäglich verlogene 
C-Apologisten-Lüge. Und das gleich in doppelter Hinsicht:

1) Natürlich findet man viele Grundkonzepte und -Operationen binärer 
Datenverarbeitung auf jedem Target. Wenn man das drauf hat, braucht 
man also definitiv nicht bei jedem Target vollkommen neu anfangen. Es 
läuft deutlich anders: Man schaut: was kann das Ding, was kostet das 
jeweils?

Als Profi ist man dann bei fast jedem Target sehr schnell in dem 
Bereich, den der Beste dafür verfügbare C-Compiler zu erreichen in der 
Lage ist. Die einzige Ausnahme von dieser Regel sind sehr gut 
durchoptimierte Codegeneratoren für bestimmte Achitekturen. Das sind 
aber sehr, sehr wenige. Der Mainstream halt.
Und selbst hier kann man immer mal wieder leicht punkten: wenn der 
verschissene Compiler die neuesten Gimmicks der Targetfamilie noch 
garnicht kennt, oder noch zu feige/zu doof ist, sie zu offensiv zu 
nutzen und das Problem halt passend ist...

2) Man muß auch bei einem Compiler immer wieder neu anfangen. Schon die 
Wahl der Optimierungsoption ist oft kritisch, umso kritischer ist 
natürlich die Wahl des Compilers, selbst, wenn die Sprache selber 
"standardisiert" ist...

> Sinnvoll wäre dagegen, den Schritt von Assembler zu C/C++ zu wagen.

Kann man später immer noch machen. Man hat dann immerhin die Kompetenz, 
den Code zu bewerten, der aus diesen Tools rausfällt...

> Denn damit kann man auch größere Projekte realisieren

Man kann mit Assembler ebenfalls "größere Projekte" realisieren, die 
sehr, sehr weit über ein "hello world" hinausgehen. Nur du kannst es 
wohl nicht...

von G. O. (aminox86)


Bewertung
0 lesenswert
nicht lesenswert
Michael S. schrieb:
> Jetzt möchte ich mich an 8086 Prozessoren heranwagen.

Solch ein Vorhaben und alles, was sonst noch so bisher erwähnt wurde, 
sind Projekte für Weicheier und Warmduscher ;-) Echte Kerle bauen ihren 
Prozessor und  die Peripherie in Relaistechnik auf. Im Netz kann man 
einige Beispiele zu dieser Methode finden.

von fritz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Auch evtl. für Hardcorebastler interessant:
> https://de.wikipedia.org/wiki/MenuetOS

Naja, das läuft nur ab 80386 aufwärts (32 Bit), entwickelt wird gar nur 
noch mit 64 Bit Prozessoren (AMD64).

Für 8086 könnte das alte Minix (1.x) taugen oder ELKS: 
https://de.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset

von Andy D. (rackandboneman)


Bewertung
0 lesenswert
nicht lesenswert
@Laberhannes mit dem Z80 kenn ich mich wieder nicht so - hat man bei dem 
nicht das selber "arghh, kein Stack, daher keine Subroutinen" Problem 
wie zB beim 6502?

...

Ein "Zwischenschritt" der zu empfehlen ist wenn man denkt dass einem so 
etwas Spass macht: klassischer 8032/8052 in "externer" Beschaltung, mit 
entweder einem einfach Monitorprogramm (zB dem von Herrn Stoffregen) 
oder Basic52.

von xyz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> kein Stack

So viel wie RAM da ist, - Daten, - Programm.
Ein Z8002 hat immerhin schon ein eigenes Stacksegment (max. 64k).

von GPL-Nazi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ichbins schrieb:
> Stefan ⛄ F. schrieb:
>> Für deinen PC würde ich mal gucken, was Linux da so an Board hat
>
> Linux hat mit dem 8086 ungefähr soviel zu tun, wie du mit dem 1.
> Weltkrieg.

Schau mal in die Sourcen der diversen Bootloader, da ist 8085 Assembler 
drin der unter Linux gebaut wird.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Martin schrieb:
> Mann muss bei 32 Bit aber auch mehr Kabel zum RAM und ROM ziehen.

Im Gegensatz zum 386er kann man einen 486er mit einem 8-Bit-Bus 
betreiben. Ist zwar nicht besonders performant, aber von der Verdrahtung 
nicht wesentlich aufwändiger als ein 8086.

Andy D. schrieb:
> mit dem Z80 kenn ich mich wieder nicht so - hat man bei dem
> nicht das selber "arghh, kein Stack, daher keine Subroutinen"
> Problem wie zB beim 6502?

Nein, mit dem Z80 kann man auch richtige Betriebssysteme (also 
präemptives Multitasking und so) bauen: 
https://en.wikipedia.org/wiki/SymbOS

Anarchist schrieb:
> Ich würde dann aber mindestens mit einem 386 anfangen.
> Der kostet heute in etwa gleich viel wie ein 8086. Und hat dann
> noch 32 Bit und Protected Mode und so.

Das macht's jetzt nicht wirklich einfacher... zumal man sich bis dahin 
trotzdem mit dem 16-bittigen Real Mode rumschlagen muss.

von Soul E. (souleye) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:

> Im Gegensatz zum 386er kann man einen 486er mit einem 8-Bit-Bus
> betreiben. Ist zwar nicht besonders performant, aber von der Verdrahtung
> nicht wesentlich aufwändiger als ein 8086.

Da gab es doch mal jemanden, der sich das Ding auf eine S100-Karte 
gesetzt und damit seinen Altair 8080 aufgerüstet hat?

http://www.s100computers.com/My%20System%20Pages/80486%20Board/80486%20CPU%20Board.htm

von Pandur S. (jetztnicht)


Bewertung
-2 lesenswert
nicht lesenswert
Ein 8086 .. hust. Der ist schon derart schwierig zu verstehen, dass man 
einiges geben muss bis man  ihn vernuenftig anwenden kann. Das ASM 
Instruction Manual ist schon ein eher dickes Buch.

Ich wuerd was einfacheres zum Einsteigen empfehlen.

Der naechste Schritt nach diesem 8086 waere dann der 80386, welche noch 
den protected mode mit der MMU bereit haelt. Diesen Schritt hat 
Microsoft schon verbockt.

von dirk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nichts für Ungut
Die SCO 3 1/2 Diskettte mit 386 ger Treibern
und Blattgold hab ich noch, für ein 486 Board
mit nem fünver drauf.
Ach so Microsoft.

Dirk St

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-2 lesenswert
nicht lesenswert
Warum schreibt ihr alle solchen Bullshit, daß der 8086 bzw. x86 
Assembler allgemein so kompliziert sei? Ihr wollt doch keinen Assembler 
oder Optimierer dafür selbst programmieren - dann wird es kompliziert.

Ich habe auf dem 80486 mit x86 Assembler angefangen. Da freut man sich 
wirklich über ein vollständiges 32bit Register-Set (Achtung: beim 8086 
muß man dann wieder mit 16bit auskommen) und viel, viel Speicher. 
Register kann man niemals genug haben, FPU und später MMX bringen noch 
einmal Geschwindigkeit und Flexibilität. Man kann natürlich auch alles 
auf der Basis-CPU alleine rechnen wenn die Geschwindigkeit nicht wichtig 
ist oder wenn einem die FPU zu kompliziert ist.

Die Adressierung beim 8086 mit seinen Segmenten bzw. die Wertigkeit der 
Segmentregister von nur 10h anstatt der logisch besseren 10000h ist 
etwas gewöhnungsbedürftig, das stimmt. Wenn man heute mit x86 Assembler 
anfängt, hat man dieses Problem nicht mehr, weil heute alles im 
Protected Mode läuft, sprich man braucht die Segmentregister nicht mehr 
weil man den ganzen Speicher als einen linearen Block geliefert bekommt. 
Man kann alles mit einem einzelnen 64bit-Register adressieren wenn man 
möchte und bis die Speichergröße diese Grenze reißt, dauert's noch ein 
paar Jahre. Wer weiß, ob es den x86 dann überhaut noch gibt oder ob die 
Architektur ansich bis dahin durch neue Technologien ersetzt wurde.

Beim 8086 braucht man die Segmentierung erst, wenn man mehr als 64kbyte 
RAM braucht. Mach das erstmal mit einem Assembler-Programm voll. Erst 
danach wirds lustig und man muß sich mit sowas wie far jumps oder far 
calls beschäftigen. Der Code ansich ist sehr selten größer als ein 
Segment und die Daten lassen sich einfacher über mehrere Segmente 
adressieren... wenn man  bei einem Selbstbauprojekt überhaupt so viel 
RAM bestückt. Mein Aufbau damals hatte nur 64k RAM und das hat locker 
gereicht.

Was die vielseitigen indirekten Adressierungen angeht - das ist doch 
eines der schönsten Features am x86. Das macht die Programmierung 
flexibel, man ist nicht auf eine vorgeschriebene Methode angewiesen. 
Gewissermaßen ist das eines der Dinge, die ich bei anderen Prozessoren 
vermisse.

Was ich auch vermisse - der x86 ist beim addieren und subtrahieren 
zwischen Registern extrem flexibel, die Register(teile) lassen sich mit 
8, 16 oder (ab dem 80386) mit 32 Bit ansprechbar, ganz wie man es gerade 
braucht. Das können die µCs, die ich bislang so gesehen habe, auch nicht 
so gut. Da wurde mir etwas zuviel gespart, der AVR z.B. kann nicht mal 
ein "ADDI r16,88" - da muß man sich mit SUBI r16,(256-88) behelfen, was 
das carry-Flag ebenfalls invertiert. Sowas finde ich nerviger als die 
Segmentierung beim x86.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
> Ihr wollt doch keinen Assembler
> oder Optimierer dafür selbst programmieren - dann wird es kompliziert.

Ein Assembler für 8086 ist eigentlich nicht kompliziert.

von Carl D. (jcw2)


Bewertung
0 lesenswert
nicht lesenswert
xyz schrieb:
>> kein Stack
>
> So viel wie RAM da ist, - Daten, - Programm.
> Ein Z8002 hat immerhin schon ein eigenes Stacksegment (max. 64k).

Z8002 ist das "Segment-freie" Pinout. Der kann nur 64k insgesamt. Für 
mehr braucht es den Z8001 mit längerem Gehäuse. Und in 
"Außenbeschaltung" kann er gut mit dem 8086 mithalten.

von Blumpf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ohne die Beiträge gelesen zu haben:
Es ist möglich, auch für Bastler.

Schau dir den 80386EX an. Das ist ein intel Microcontroller, der hat den 
gleichen Kern wie ein 80386, und den kann man in X86-Assembler 
programmieren. Ich musste das tun, ich habe es gehasst.

Da gibts eventuell noch Evalboards bei ebay, aber nachdem es ein µC ist, 
wäre ein eigenes Board machbar. Gibt es wahrscheinlich nur als SMD, aber 
LQFP ist dabei, das ist handlötbar.

Der ist schon vor längerer Zeit eingestampft worden, aber man bekommt 
noch Chips bei ebay.

Mein Rat wäre:
Wenn du es nicht aus akademischen oder sportlichen Gründen tust: Lass 
es.
Wenn du einen Assembler lernen willst, such dir ein sinnvolleres Ziel: 
Mit ARM oder MIPS kann man sogar was anfangen.

X86-Assembler mag seine Daseinsberechtigung haben, aber sicher nicht im 
Embedded-Bereich.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
> die Register(teile) lassen sich mit
> 8, 16 oder (ab dem 80386) mit 32 Bit ansprechbar, ganz wie man
> es gerade braucht

Mal gehts, mal nicht, je nach Registerteil, Modus und Breite.

Für eine effiziente Implementierung ist es bereits circa seit der Ära 
des Pentium Pro von Vorteil, wenn Register nicht in Teilen 
angesprochen werden können.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-2 lesenswert
nicht lesenswert
> Ein Assembler für 8086 ist eigentlich nicht kompliziert.
Finde ich auch nicht, aber wenn man sowas vor hat, vor allem das Thema 
Optimizer, dann muß man den Prozessor wirklich kennen. Vorher reichts, 
wenn man ihn bedienen kann. Dürfte beim ARM z.B. ähnlich sein.

> Ein Z8002 hat immerhin schon ein eigenes Stacksegment (max. 64k).
Passt doch zum 8086, der kann das genau so - und Du kannst Dir das 
Stacksegment mittels SS-Register sogar im RAM hinpacken wo Du möchtest.

Edit bzw. Nachtrag:
> Für eine effiziente Implementierung ist es bereits circa
> seit der Ära des Pentium Pro von Vorteil, wenn Register
> nicht in Teilen angesprochen werden können.
Ich meinte das mit Hinblick auf die Flexibilität bei der (Assembler-) 
Programmierung des Prozessors. Was Optimierungen angeht oder Steigerung 
der Effizienz auf anderen (speziell jüngeren) Prozessoren angeht - das 
steht auf einem anderen Blatt. Diese Prozessoren verwenden intern andere 
Architekturen, große Caches, bringen weit höhere 
Speichertransferraten... so das immer anderen Dinge verschieden wichtig 
sind.

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
>> Ein Z8002 hat immerhin schon ein eigenes Stacksegment (max. 64k).
> Passt doch zum 8086, der kann das genau so - und Du kannst Dir das
> Stacksegment mittels SS-Register sogar im RAM hinpacken wo Du möchtest.

Der wesentliche Unterschied lag in der Wahl des Segments. Beim Z8000 war 
das Segment Teil einer dadurch längeren Adresse, egal ob im Befehl oder 
Register. Bei 8086 war das nur bei Codeadressen frei wählbar, bei 
Datenadressen nicht. Viel Code und wenig Daten, das war bei 8086 recht 
elegant machbar.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-2 lesenswert
nicht lesenswert
> Viel Code und wenig Daten, das war bei 8086 recht elegant machbar.
Ich finde das passt eher auf andere Prozessoren, wie bspw. dem 6502 mit 
seiner Zero-Page. Dem 8086 ist das im Bereich bis 1Mbyte RAM eigentlich 
völlig egal. Code is data and data is code.

von xyz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Z8002 ist das "Segment-freie" Pinout. Der kann nur 64k insgesamt.

Der Z8002 hat Statussignale fuer System/User und Code, Daten und Stack.
Die kann man, wenn man will, mit ausdekodieren.
Was dann eben mehr als die reinen 64k sind.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
> Dem 8086 ist das im Bereich bis 1Mbyte RAM eigentlich
> völlig egal. Code is data and data is code.

Mit mehr als einem Daten- und einem Stack-Segment zu hantieren, war bei 
8086 weit umständlicher als bei Z8000.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
> so das immer anderen Dinge verschieden wichtig sind.

Was aber der Grund dafür ist, dass Teilregisteroperationen aus der Mode 
kamen.

von xyz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Die Adressierung beim 8086 mit seinen Segmenten bzw. die Wertigkeit der
> Segmentregister von nur 10h anstatt der logisch besseren 10000h ist
> etwas gewöhnungsbedürftig

Dieser Murks war auch die Quelle fuer die diversen Speichermodelle
bei Compilern und Assemblern: Tiny, Small, Medium und Large.
Fuer embedded 8086-Code durfte man gerne noch einen speziellen
Linker, z.B. Locate von Paradigm bemuehen.
Beim 8086 ist man eigentlich nur staendig damit beschaeftigt,
irgendwelche Register wieder aus dem RAM zu laden, weil zu
wenige davon da sind.
Deswegen: 8086 Programmierung egal ob in Assembler oder etwas
besserem ist weder spassig noch in irgendeiner Form lustig.

Daher auch meine Empfehlung, wenn man mit solchen Alteisen
seine Bildung aufbessern will, den Z8002 in die engere Wahl
zu ziehen. Der hat solche Macken naemlich nicht.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
xyz schrieb:
> den Z8002 in die engere Wahl
> zu ziehen. Der hat solche Macken naemlich nicht.

Das ist nur halb gesprungen. Denn wer es mit CPUs dieser Ära einfach 
haben will, der spart sich die Segmentiererei und nimmt 68008. 8086 
nimmt man heute nur, wenn man die Macken bewusst erleben will.

: Bearbeitet durch User
von xyz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Das ist nur halb gesprungen. ... und nimmt 68008

Ich wuerde mal einfach behaupten, dass ein Minimalsystem
mit z.B. 512 k SRAM mit einem Z8002 schneller und einfacher
zusammengebaut sind.
Und bei Studienzwecken reicht halb gesprungen vielleicht ja auch.

von Pandur S. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
Zum 8086 Sollte man sich auch noch den 8259 goennen, das ist der 
Interrupt controller. Er ist sogar kaskadierbar. Waehrend ein 8259 8 
Interrupts kann, koennen 8 weitere an jedem seiner Eingaenge zusammen 64 
Interrupts. Dann laeuft immer alles noch in Hardware. Nach der 
Programmierung des 8259 versteht sich. Dieser Chip hatte auch ein etwas 
weniger dickes Manual, da er viele geniale Modi enthielt. Microsoft hat 
diesen leider voellig falsch eingesetzt, was nachher Generationen von 
Treiberprogrammierern schlaflose Naechte bereitete.
Und zwar hat der 8259, ein abgestuftes Prioritaets System. Interrupts 
konnten per Hardware Interrupts unterbrechen. Microsoft hat nun aber die 
Pins der Peripherie falsch angeschlossen und musste das dann in software 
korrigieren.

Irgend wann gabs glaub auch eine Version des 8086 welche den Interrupt 
controller gleich enthielt, allenfalls der 80186.

Und wenn man sich nicht alles mit statischem RAM verbauen will gabs auch 
noch den 82.., den Dynamischen Memory controller. der konnte dann 1MByte 
Dynamisches RAM ansteuern und refreshen. Auch der funtionierte erst nach 
seiner Programmierung.

Alles sehr lehrreich.

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
xyz schrieb:
> Dieser Murks war auch die Quelle fuer die diversen Speichermodelle
> bei Compilern und Assemblern: Tiny, Small, Medium und Large.

Es gab beim TC auch noch Huge, wo Pointer bei jedem Zugriff normalisiert 
wurden. Nur solche Pointer konnten verglichen werden, machten aber das 
Programm grottenlahm.
Wer sich diese krude Segmentierung mit mehrfach den selben Adressen 
ausgedacht hat, der gehört geteert und gefedert.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
xyz schrieb:
> Ich wuerde mal einfach behaupten, dass ein Minimalsystem
> mit z.B. 512 k SRAM mit einem Z8002 schneller und einfacher
> zusammengebaut sind.

Du kannst zwar problemlos 512 kB RAM einbauen, aber davon mehr als 64 kB 
RAM anzusprechen ist ein übles Gewürge, weit übler als bei 8088 und 
68008.

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Pandur S. schrieb:
> Zum 8086 Sollte man sich auch noch den 8259 goennen, das ist der
> Interrupt controller.

Also wenn wir schon dabei sind, dann bitte auch den 8089 DMA-Controller 
aus der Serie. Der war nämlich ein recht eigenständiges I/O-Subsystem 
mit völlig inkompatibler Assembler-Programmierung. ;-)

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Wer sich diese krude Segmentierung mit mehrfach den selben Adressen
> ausgedacht hat, der gehört geteert und gefedert.

=> https://en.wikipedia.org/wiki/Stephen_P._Morse

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Pandur S. schrieb:
> Microsoft hat nun aber die
> Pins der Peripherie falsch angeschlossen und musste das dann in software
> korrigieren.

Microsoft hat also den IBM kompatiblen PC verdratet? Und das auch noch 
falsch? Sachen gibts!

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Zu Stephens Ehrenrettung: “was intended to be short-lived and not have 
any successors”. Da sieht man mal, wie falsch kann man liegen kann. Aber 
das hat bei Intel schon Tradition, denn 8051 hatte das gleiche kurz 
angelegte Ziel und ein ähnliches Ergebnis - zum Leidwesen vieler 
heutiger Embedded-Entwickler, die mit 8096 und 80960 Cores sicherlich 
besser dran wären.

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
(prx) A. K. schrieb:
> Aber
> das hat bei Intel schon Tradition, denn 8051 hatte das gleiche kurz
> angelegte Ziel und ein ähnliches Ergebnis

Beim Befehlssatz hat man sich schon sehr viel Gedanken gemacht und ihn 
exzellent auf Steuerungen optimiert, das war definitv kein Schnellschuß.
Und der EA-Pin, durch den man jeden PROM/OTP 8051 als 8031 mit externem 
EPROM verwenden konnte, war schon genial.
PROM/OTP war schon sehr hinderlich für eine schnelle Entwicklung und an 
Flash war lange nicht zu denken. Und Emulatoren waren extrem teuer und 
empfindlich.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-1 lesenswert
nicht lesenswert
Vielleicht kann ich das nicht beurteilen, da ich den Z8000 nicht kenne - 
aber das war doch beim 8086 total simpel.

Gerade bei kleinen Anwendungen braucht man sich um Code- und 
Stacksegment überhaupt nicht zu kümmern (bei DOS-Anwendungen z.B. wird 
das durch DOS gesetzt und man muß da nie was dran ändern). Ich habe 
soooo viele kleine Tools geschrieben, wo CS=DS=SS war, weil alles in 
64kByte reinpasst.

Bei großen Datenmengen (über 64k) stellt sich halt die Frage, wie Du sie 
adressieren möchtest. Beim 8086 musst Du Dir halt die Datensegmente 
(DS/ES) passend berechnen, das finde ich aber nun wirklich nicht 
kompliziert.

Bei meinem kleinen Lochraster-86 gabs sowieso nur 64k RAM. Sprich man 
kann sich CS=DS=SS=0 erlauben und braucht die Segmentregister niemals 
anzufassen.

Dazu vielleicht als Erläuterung:
Die Startadresse des 8086 ist FFFF:0000 (CS:IP), da muß man sich 
zwingend etwas ROM hinlegen. Ich hatte da oben 4kByte (wenn ich mich 
richtig erinnere) ROM mit einem Bootloader, der beim Start die 
Interrupttabelle initialisiert hat und anschließend eine .COM-Datei über 
RS-232 von einem PC direkt an 0:100h ins RAM geladen hat. Dadurch konnte 
das Ding .COM-Programme direkt ausführen, da unterhalb genug Platz für 
die Interrupttabelle war.

Was das Ding im Vergleich zu µCs unattraktiv macht:
Damit das Teil sowas wie RS-232 oder auch nur eine einzelne LED blinken 
lassen kann, muß man sich ein paar Ports adressmäßig "auf den Datenbus 
decodieren", genau wie RAM und ROM. Ansonsten kann der nackte Prozessor 
alleine nichts lesen und auch auf nichts schreiben. Für den Prozessor 
sind das alles nur Adressen, ob da nun RAM oder ein Latch (für einen 
8Bit-Ausgangsport z.B.) dranhängt, kann er nicht unterscheiden.

Edit:
> Deswegen: 8086 Programmierung egal ob in Assembler oder etwas
> besserem ist weder spassig noch in irgendeiner Form lustig.
Klares Contra. Ich hatte sehr viel Spaß damit und meine das auch nicht 
ironisch. Das lasse ich mir nicht nehmen, auch wenns mein dummer -1 
Troll mit zuviel Freizeit schon wieder probiert.

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Peter D. schrieb:
> das war definitv kein Schnellschuß

Beim Befehlssatz hatte man vom 8048 gelernt, der wiederum vom Fairchild 
F8 gelernt hatte. Der Befehlssatz war effizient, die Hardware für 
damalige Verhältnisse auch. Auch die Datenkapazität passt perfekt in die 
Zeit - die war aber schon wenige Jahre später veraltet, und ab da wirds 
ungemütlich.

Deshalb: Kein Schnellschuss, aber nur auf eine kurze Zeitspanne 
angelegt.

: Bearbeitet durch User
von xyz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Huge

Ich wusste doch das ich einen vergessen hatte :-).

> aber davon mehr als 64 kB RAM anzusprechen ist ein übles Gewürge

Naja, auch nicht schlimmer als eine Bankinglogik beim 8051.

128 kB Code schafft man schon mit User/System und 128 kB Daten
mit Daten/Stack. Siehe meine Bemerkung zu den Statuspins.

Wem das zuviel Gebastel ist, soll halt den Z8001 und die Z8010
MMU nehmen.

von uwe (Gast)


Bewertung
1 lesenswert
nicht lesenswert
MC68332 war auch schön

von Pandur S. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
Diese Segemnt Adressiererei waren schon sinnvoll. Man haette eben nur 
die Segmente nicht einfach aufeinander legen sollen. Die Erweiterung 
dieses Segment Konzeptes war im 80386 das Protected Mode Page System. 
Dort gab es beliebig viel solcher Segmente, alle mit Lese/Schreib und 
Execute Rechten, welche ein Ueberschreiben einer Codepage verhinderten. 
Auch konnten System Programme nicht von User Programmen gelesen, oder 
geschrieben werden. Auch das hat Microsoft dann aber falsch neu 
implementiert.
Alle folgenden PC Generationen basierten also dann auch falsch 
implmentierten Basics. Schade, weil die Prozessor Infrastruktur haette 
mehr hergegeben.

Leider wurde auch auf den 8089, den IO Controller, verzichtet, das war 
ein ausserordentlich maechtiger IO Controller. Der hatte Hardware 
Busarbitrierung mit dem 8086. Bedeutet, die beiden haetten sich per 
Hardware abgesprochen welcher den Bus wann belegt. Der haette eine 
Floppy oder Harddisk von selbst angesteuert, und die Daten per DMA in 
die Passenden Memory location geschrieben. Ja, der Befehlssatz war vom 
8086 verschieden, die Funktionalitaet auch. Das war schon gerechtferigt.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Pandur S. schrieb:
> Leider wurde auch auf den 8089, den IO Controller, verzichtet, das war
> ein ausserordentlich maechtiger IO Controller.

Mehr an I/O-Subsysteme von Mainframes erinnernd, als an 
Mikroprozessor-Tradition. Statt dessen kam im PC ein völlig unpassender 
und deshalb übel angefrickelter DMA-Controller von AMD aus der 8080-Ära.

: Bearbeitet durch User
von PittyJ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Warum schreibt ihr alle solchen Bullshit, daß der 8086 bzw. x86
> Assembler allgemein so kompliziert sei? Ihr wollt doch keinen Assembler
> oder Optimierer dafür selbst programmieren - dann wird es kompliziert.
>
> Ich habe auf dem 80486 mit x86 Assembler angefangen. Da freut man sich
> wirklich über ein vollständiges 32bit Register-Set

Der TE sprach von 8086 und nicht von 80468. Und beim 8086 ist nichts von 
32bit, sondern da ist nur die Krüppelei mit Segment-Registern.

von S. R. (svenska)


Bewertung
3 lesenswert
nicht lesenswert
Pandur S. schrieb:
> Microsoft hat diesen leider voellig falsch eingesetzt, was nachher
> Generationen von Treiberprogrammierern schlaflose Naechte bereitete.

Das hat IBM verbockt, nicht Microsoft. Die mussten nur damit leben, was 
in der Anfangszeit des Systems nicht weiter störte.

> Irgend wann gabs glaub auch eine Version des 8086 welche den Interrupt
> controller gleich enthielt, allenfalls der 80186.

Nicht nur den, sondern auch Timer und DMA-Controller. Dummerweise waren 
die nicht kompatibel zu dem Misthaufen, den IBM da zusammengestöpselt 
hatte, daher kann man mit dem Chip kein(*) PC-kompatibles Gerät bauen.

(*) Kann man schon, wenn man die ganzen unnötigen Zusatzchips trotzdem 
einbaut, wie z.B. Siemens das gemacht hat.

> Alles sehr lehrreich.

Und heutzutage noch viel dööferer zum Basteln. An einen Z80 kannst du 
relativ direkt RAM, ROM und vielleicht noch ein paralleles Display 
anknoten, an einen 8086 nicht. Dafür brauchst du die ganzen Zusatzchips 
von Intel, oder du baust das irgendwie nach.

Es gibt einen Grund, dass Sergey's XT-Nachbau auf fertige Chipsätze der 
späten PC/XT-Ära aufsetzt. Bei den Z80-Varianten (z.B. RC2014) ist das 
nicht nötig.

Pandur S. schrieb:
> Auch das hat Microsoft dann aber falsch neu implementiert.

Nun, Microsoft hatte ein Interesse daran, dass die Systeme einigermaßen 
schnell funktionieren. Und der 386er war eben vieles, aber eben nicht 
schnell, wenn man seine Funktionen wirklich nutzen wollte.

Die ganze Protected Mode-Theorie in allen Ehren, aber real legte man 
schon damals einfach Code-, Daten- und Stacksegment aufeinander und 
adressiert linear, wenn man Performance wollte. Das galt für 
DOS-Extender wie auch für Windows oder die Unixoide.

Ben B. schrieb:
> das war doch beim 8086 total simpel

Wenn du den 8086 kennst und da ein paar Jahre deines Lebens drin 
versenkt hast, dann ist der 8086 vollkommen offensichtlich - wie auch 
Quantenphysik oder Bauingeneurswesen. Gehst du da mit einem offenen Auge 
ran und vergleichst mit anderen Architekturen, stellst du eigentlich 
recht schnell fest, dass x86 eigentlich überall die Ausnahme ist.

Davon abgesehen redest du viel von 386ern und 486ern, wenn der TO doch 
unbedingt einen 8086 haben will. Die 32-Bitter waren immerhin recht 
einfach einzusetzen, wenn man den ganzen Mist ignoriert hat. :-)

Ich kann da das Blog "oldnewthings" empfehlen, insbesondere dessen 
Architekturreihe, wo Raymond sich tiefer mit den 
(Userspace-)Befehlssätzen befasst, die Windows mal unterstützt hat 
(i386, MIPS, PPC, Alpha, SuperH).

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
3 lesenswert
nicht lesenswert
S. R. schrieb:
> Die ganze Protected Mode-Theorie in allen Ehren, aber real legte man
> schon damals einfach Code-, Daten- und Stacksegment aufeinander und
> adressiert linear, wenn man Performance wollte.

Wer Sinn für Frickelei hat, der wird die Speicherververwaltung von 
32-Bit OS/2 mögen, mit ihrem 16/32-Bit Mix aus linear adressierenden 
32-Bit Programmen mit 16-Bit Segmenten für alte Libs und 
Betriebssystemteile. ;-)

Schon OS/2 1.x war ein Meisterstück bizarrer Konstruktion. Ein 
Betriebssystem, dass sowohl im protected mode als auch im real mode (wie 
DOS) arbeitete. Also eigentlich hatte Intel ja keinen Weg definiert, wie 
man aus dem protected mode wieder in den real mode zurück kam. Ausser 
über Reset und genau so lief es dann ab. Device driver schrieb man so, 
dass es egal war, in welchem Modus sie liefen. Mit Hilfs-Segmenten, die 
ad hoc zurechtgefrickelt wurden und nur sehr temporär nutzbar waren.

von (prx) A. K. (prx)


Bewertung
3 lesenswert
nicht lesenswert
S. R. schrieb:
> Das hat IBM verbockt, nicht Microsoft. Die mussten nur damit leben, was
> in der Anfangszeit des Systems nicht weiter störte.

Yep. Ganz am Anfang noch nicht. So hatte IBM sich in weiser Vorraussicht 
dafür entschieden, gerade jene Interrupts als BIOS-Schnittstellen zu 
verwenden, die Intel von einer solchen Verwendung ausgeschlossen 
hatte. Da hatten später alle was davon, auch Intel und Microsoft. Intel 
musste alle späteren Prozessoren um IBMs Entscheidung herumdefinieren.

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
0 lesenswert
nicht lesenswert
Ich kann halt nur aus meinen Erfahrungen berichten, die ich mit x86 und 
dem Assembler hatte.

Der 486er war der erste PC, den ich hatte. Für mich gabs also als 
Einstieg gleich 32 Bit Assembler und daher rede ich natürlich auch recht 
viel von 32 Bit.

Später kam dann der Lochraster-86 als Spaßprojekt mit dem 8086 und ich 
kann dazu nur sagen, daß die Adressdekodierung auch ohne 
Intel-Spezial-ICs machbar ist. Es ist ein wenig nervig, daß Adress- und 
Datenbus gemultiplext sind, aber es lässt sich alles mit ein paar 
Logikschaltkreisen verwursten. Man kann auch den 8088 verwenden - der 
hat nur einen 8-Bit-Datenbus wenn man das einfacher findet.

Was die Programmierung angeht hatte ich keine Probleme vom 80486 runter 
zum 8086. Die Segmentierung hat man beim 80486 auch schon - DOS läuft 
nicht im Protected Mode - und wie gesagt, wenn man einmal im Kopf hat, 
daß ein Segment 16 Byte oder 10h sind, finde ich es wirklich nicht 
schwer. Gewissermaßen kannst Du damit ja auch mit 64kByte großen 
Segmenten arbeiten, dann interessieren Dich halt nur die oberen 4 Bit 
der Segmentregister und Du hast nur 16 Segmente anstatt 64K Segmente... 
wenn Du das besser findest wäre auch das problemlos möglich.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
> daß die Adressdekodierung auch ohne
> Intel-Spezial-ICs machbar ist

Der Aufwand für ein einfaches System auf Basis des Minimum-Mode ist 
durchaus überschaubar.

von Robert K. (Firma: Zombieland) (rko)


Bewertung
-1 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Es gibt tatsächlich einen 8086 Assembler in Linux. Das Paket heißt
> bin86.
Ist das ein Crossassembler?

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Robert K. schrieb:
> Stefan ⛄ F. schrieb:
>> Es gibt tatsächlich einen 8086 Assembler in Linux. Das Paket heißt
>> bin86.
> Ist das ein Crossassembler?

Nö, der ist nur für Linuxe auf Original-8086 einsetzbar. ;-)

Im Ernst: Sowas braucht man, wenn man Teile des Boot-Mechanismus nicht 
unter DOS oder Windows entwickeln will, sondern auch unter Linux. Auf 
ARM wird er deshalb nur seltenst benötigt.

: Bearbeitet durch User
von Robert K. (Firma: Zombieland) (rko)


Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:
> Schlechte Entscheidung.
warum? Für den Anfang okay.

>> Was benötige ich denn hierzu ?
>
> Du benötigst einen Computer mit einem 8086-Prozessor drin. Ein 8088
> dürfte auch funktionieren. Die gibt es auch als Emulatoren.
Man kann auch auch abwärtskompatible CPUs verwenden, 80286, 80386, 
80486, etc. sollte auch gehen.

>> Welcher Assembler ist zu empfehlen und was für einen
>> Programmer brauche ich ?
Unter Windows wäre das masn oder tasm, bei Linux nasm.
Vielleicht geht auch fasm,
https://flatassembler.net/index.php
Programmer? Für Eprom?

von Robert K. (Firma: Zombieland) (rko)


Bewertung
-1 lesenswert
nicht lesenswert
(prx) A. K. schrieb:
> Nö, der ist nur für Linuxe auf Original-8086 einsetzbar. ;-)

schlecht, weil die meisten uralten 8086 Systeme aufgrund des 
Hauptspeichers gar kein Linux zulassen.

von Joachim B. (jar)


Bewertung
2 lesenswert
nicht lesenswert
(prx) A. K. schrieb:
> Ein Assembler für 8086 ist eigentlich nicht kompliziert.

ist Assembler überhaupt kompliziert?

IMHO nein,
ich lade doch immer was in den Akku, entweder aus Register oder aus dem 
Speicher und mache dann meine Dinge die ich machen will,
was berechnen (Steuer, Regelung)
was kopieren oder verschieben was suchen (Daten)

Ich springe entweder relativ, absolut oder bedingt irgendwo hin,
bedingt bei Vergleichen wenn Flags gesetzt sind überlauf, zero, größer 
oder kleiner.

Schwierig werden doch nur die unterschiedlichen Bezeichnungen
LD A,x (r1 usw.) ldi  (ist klar load)
LDA, x
ADD (addiere was auch immer)
MUL
JMP, JS, BNE und wie sie alle verschieden genannt werden.

Was welcher Prozessor kann oder nicht steht im Datenblatt, wie die 
Mnemonics bei jedem Prozessor heissen muss man halt lesen.
https://de.wikipedia.org/wiki/Assemblersprache#Mnemonic

Schwierig wurde es ab 68k und neuere mit MMU und geschützten 
Speicherbereichen wo man eben nicht mehr den vollen Zugriff hat.

Damals mit 64k war man ja noch mit jedem Byte per DU heute mag ich das 
auch nicht mehr, es ist einfach nicht mehr zu überblicken.

von Genau (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Die Entwicklung der Mikroprozessor-Technologie muss damals ein sehr 
stressiges Rennen gewesen sein ... man musste ja die Technologie und die 
Patente für das eigene Land sichern, damit der 
Trillionen-Dollar-Wirtschaftszweig mit seiner Marktdominanz anlaufen 
kann.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-1 lesenswert
nicht lesenswert
@Joachim

Versuch mal "MOV" beim x86 Assembler hinsichtlich seiner Flexibilität zu 
schlagen... viel Glück!

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Joachim B. schrieb:
> ich lade doch immer was in den Akku, entweder aus Register oder aus dem
> Speicher und mache dann meine Dinge die ich machen will,

Hat man keinerlei irgendwie geartete direkte Datenadressierung, sondern 
ausschliesslich rein indirekte Adressierung über Adressregister, kann 
aber mit denen ausser +1/-1 nicht rechnen, wird die übliche 
Programmiertechnik etwas umständlich (1802). Da sind Makros gefragt, 
oder man geht zu sowas wie FORTH über.

Hat man bedingte Sprünge nur innerhalb einer 256-Byte Seite (1802, 
8048), können kleine Verschiebungen des Programms grosse Folgen haben. 
Kann man generell nur innerhalb +/-128 Bytes direkt springen, ob bedingt 
oder nicht, kann sich ein Programm durch lustige Sprungkaskaden 
auszeichnen (SC/MP).

Auch Befehle für Unterprogrammaufrufe sollte man nicht für 
selbstverständlich halten, denn die gibts nicht überall (1802, SC/MP). 
Dafür kann man sich auch mal ad hoc aussuchen, welches Adressregister 
von nun an als Program Counter genutzt wird (1802).

> Ich springe entweder relativ, absolut oder bedingt irgendwo hin,
> bedingt bei Vergleichen wenn Flags gesetzt sind überlauf, zero, größer
> oder kleiner.

Wobei es sein kann, dass es überhaupt nur das Carry-Flag gibt (1802).

> Schwierig werden doch nur die unterschiedlichen Bezeichnungen

Das hingegen kann der einfachere Teil sein.

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Versuch mal "MOV" beim x86 Assembler hinsichtlich seiner Flexibilität zu
> schlagen... viel Glück!

was soll mir das sagen?
Die x86 mochte ich nie mit ihren Segmenten, ich glaube das letzte 
Programm habe ich um 1999 geschrieben aber in QBasic, die Segmetiererei 
fand ich schon nervig.
Ich davor noch mal was mit QC für windows um AtariST Bilder, Stad, P?1 
bis P?3 uvam. zu BMP zu wandeln.
Danach verlor ich die Lust ASM, ich brauchte ASM schlicht nicht mehr, 
konnte alles seit 1985 in C machen, von Atari über PC bis Raspi & µC.

Es ist doch fein für Leute die es brauchen das der x86 viele moves 
beherrscht!
Bis dahin sind mir aber auch etliche Einschränkungen begegnet z.B. das 
der LH5801/03 den PC nicht lesen konnte! (mit einem Trick kam man 
trotzdem ran um den Stack zu manipulieren für relokatible Programme)

Hingeprungen in SUBs bin ich halt immer relativ +- und zurück mit RET, 
dazu musste aber die Rücksprungadresse vorher passend auf dem Stack 
abgelegt werden.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Joachim B. schrieb:
> ich lade doch immer was in den Akku, entweder aus Register oder aus dem
> Speicher und mache dann meine Dinge die ich machen will,

Es kann auch sein, dass man zu den Datenregistern auch bei intensiver 
Suche keinerlei Lade- und Speicherbefehle im Befehlssatz findet. Weil 
der Schreibvorgang in ein Adressregister den Inhalt des damit gepaarten 
Datenregisters liest oder schreibt (CDC 6600). Inkrementiert man also 
das Adressregister, läd (bei 5 davon) oder schreibt (bei 2 davon) man 
das entsprechende Datenregister.

Mit der Mnemotechnik war das auch so eine Sache. Ein Buchstabe für die 
Operation musste vielleicht reichen, sprechendes wie ADD war Platz- und 
Zeitverschwendung. Und wenn sich kein naheliegender Buchstabe fand, nahm 
man halt einen beliebig anderen.

: Bearbeitet durch User
von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
uwe schrieb:
> MC68332 war auch schön
Ich liebe die TPU und ihren ganz eigenen Assemblercode noch heute... ;-)

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-1 lesenswert
nicht lesenswert
MOV kann beim x86 Assembler so ziemlich alles. Sowas wie

MOV  r16,r17
MOVW r30,r28
LDI  r16,88
LDS  r16,addr
LDD  r16,addr+x
STS  addr,r16
STD  addr+x,r16

ist beim x86 alles MOV.

MOV al,88h
MOV ax,8086h
MOV al,bl
MOV ax,bx
MOV eax,ebx
MOV ah,bl
MOV al,ds:[bx]
MOV ax,ds:[bx]
MOV ax,ds:[bx+88h]
MOV ds:[bx],ax
MOV ds:[bx+88h],ax

Könnte man ewig Beispiele für schreiben und ich mag diese Einfachheit. 
Gibt ein paar Einschränkungen bei der Speicheradressierung (da gehen 
nicht alle Register) und Segmentregister können nicht direkt beschrieben 
werden, aber sonst erledigt MOV alleine wirklich alles.

von Christoph db1uq K. (christoph_kessler)


Bewertung
0 lesenswert
nicht lesenswert
Bekommt man die alten x86 noch irgendwo neu? Ich vermute, noch am 
ehesten als PC-104-Karte, z.B.
https://www.systerra.de/pc104_x86_label.htm
https://www.adlinktech.com/Products/PC104SBCs/PC104_SBCs/CM1-86DX3?lang=en
da ist ein ISA-Bus schon enthalten.

Es soll also kein DOS oder ähnliches laufen, kein Betriebssystem? Auch 
unter DOS war Multitasking noch unbekannt, abgesehen vom "TSR" 
"terminate and stay resident".
Meine einzige Erfahrung mit x86-Assembler war die Disassemblierung eines 
2k kurzen Packet-Radio-Programms das als TSR lief.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
> MOV kann beim x86 Assembler so ziemlich alles.

Der MaxQ2000 könnte dir gefallen, denn der hat das nicht nur so 
ziemlich, sondern wirklich. Weil es auf Binärebene überhaupt nur 2 
Befehle gibt:
  move constant to register
  move register to register
Auf Assembler-Ebene haben sie es dann leider unnötig aufgeblasen. Aber 
mit dem richtigen Assembler liest sich das dann
      mov ...
      mov ...
loop: mov ...
      mov ...
      mov ...
      mov ...
      mov ...
      mov ...
      mov ...

: Bearbeitet durch User
von Arduino Fanboy D. (ufuf)


Bewertung
-1 lesenswert
nicht lesenswert
Christoph db1uq K. schrieb:
> Meine einzige Erfahrung mit x86-Assembler war die Disassemblierung eines
> 2k kurzen Packet-Radio-Programms das als TSR lief.

Durfte/musste dunnemals Geräte Treiber schreiben. Waren als ROM 
Erweiterung angelegt.
Hat sich dann aber mit erscheinen des 286 und darauf laufendem SCO Xenix 
schlagartig erledigt.


Eine alte ISA Karte um die eingeblendeten ROM Bereiche in statischem RAM 
zu simulieren, habe ich noch liegen.
Wenn Bedarf besteht, gebe ich die auch ab.

von xyz (Gast)


Bewertung
3 lesenswert
nicht lesenswert
> ROM Bereiche in statischem RAM zu simulieren

Fuer sowas hab ich mir einen EPROM-Emulator gebaut.
Der konnte zwar nur 8 kB EPROMs (2764) emulieren, aber
mehr brauchte man damals eigentlich nicht.
Geladen wurde er seriell, mit einem Format wie bei den
Audiotapes ueblich. Und richtig, mit einem Taperecorder
konnte man ihn auch laden. Die dazu noetige Adress- und
Dekodierlogik ist recht einfach und uebersichtlich.

Mittlerweile haette ich auch einen Dataman S4 fuer sowas.
Der kann so ziemlich alle EPROM/Flashtypen die er
programmieren kann, auch emulieren.
Spasseshalber habe ich damit sogar mal ein altes
Pentiummainbord gebootet.

von Soul E. (souleye) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
xyz schrieb:

> Fuer sowas hab ich mir einen EPROM-Emulator gebaut.
> Der konnte zwar nur 8 kB EPROMs (2764) emulieren, aber
> mehr brauchte man damals eigentlich nicht.
> Geladen wurde er seriell, mit einem Format wie bei den
> Audiotapes ueblich.

Meiner hing am Druckerport, man konnte die Daten mit "copy /b ROM.bin 
lpt1:" quasi dorthin ausdrucken. Das Ding hatte ein Studienkollege 
entwickelt, er hat die Schaltung 1991 auch in der Elektor 
veröffentlicht. Funktioniert heute noch, wird auch immer wieder mal 
genutzt.

> Mittlerweile haette ich auch einen Dataman S4 fuer sowas.

Den habe ich auch. Ein geniales Teil für unterwegs. Und die Idee, die 
Bilbliotheken mit den Programmieralgorithmen in EPROMs abzuspeichern ist 
auch schräg. Britische Computertechnik war schon immer etwas anders :-)

: Bearbeitet durch User
von MCUA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
>Microsoft hat also den IBM kompatiblen PC verdratet? Und das auch noch
>falsch? Sachen gibts!
Aber Microsoft hat anfangs versucht den 8085 ans Laufen zu bekommen, es 
nicht hingekriegt, ist danach zu MITS (mit dem Altair) gegangen...

von MCUA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
>> das hat bei Intel schon Tradition, denn 8051 hatte das gleiche kurz
>> angelegte Ziel und ein ähnliches Ergebnis
> Beim Befehlssatz hat man sich schon sehr viel Gedanken gemacht und ihn
> exzellent auf Steuerungen optimiert, das war definitv kein Schnellschuß.
Was bringen 'gute' Befehle auf einen viel zu kleinen Adressbereich ???
Dann viel lieber (aus der Zeit) ein HC11.

>Das können die µCs, die ich bislang so gesehen habe, auch nicht so gut.
Natürlich nicht.
Man kann doch nicht einen kleinen uC, oder AVR, mit nem 486 vergleichen.

von MCUA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
> Da gab es doch mal jemanden, der sich das Ding auf eine S100-Karte
> gesetzt und damit seinen Altair 8080 aufgerüstet hat?
Jetzt auch noch ein S100-Bus ???
Das Ding hat 2 (!) 8-Bit-Daten-Busse, die niemals zusammen benutzt 
werden.

von Andy D. (rackandboneman)


Bewertung
0 lesenswert
nicht lesenswert
Verglichen mit dem 8048 oder den "originalen" PICs sind die 8051 doch 
extrem orthogonal und elegant....

....

> > kein Stack

> So viel wie RAM da ist, - Daten, - Programm.
> Ein Z8002 hat immerhin schon ein eigenes Stacksegment (max. 64k).

Eben kein RAM. zB in Herrn Eaters Videos stellt man fest dass ein 6502 
ohne RAM keine Subroutinen kann, weil man eben den Stack braucht. Gibt 
es beim Z80 da irgendeinen Weg drumherum (evtl in dem man die 
Rücksprungaddressen vorberechnet, den vorberechneten Stack ins ROM 
stopft und den SP geschickt anpasst oder sowas)?

von Percy N. (vox_bovi)


Bewertung
0 lesenswert
nicht lesenswert
@MCUA:
Zitate ohne Angabe des Urhebers sind nicht nur ganz schlechter Stil, 
sondern mindestens auch eine grobe Unverschämtheit, um es dezent zu 
formulieren.

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
MCUA schrieb:
> Das Ding hat 2 (!) 8-Bit-Daten-Busse, die niemals zusammen benutzt
> werden.

Da siehst du mal, wie modern man damals war. Erst mit PCI-Express ist 
man nach jahrzehntelanger bidirektionaler Abirrung wieder zu 
unidirektionalen Verbindungen zurück.

von MCUA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
>> Das Ding hat 2 (!) 8-Bit-Daten-Busse, die niemals zusammen benutzt
>> werden.
> Da siehst du mal, wie modern man damals war.
Das "modern" bitte in Anführungszeichen.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-1 lesenswert
nicht lesenswert
Ohne RAM funktioniert nunmal kein Stack, sehr schade für den 
Programmierer, denn der kann mehr als Rücksprungadressen speichern.

Folglich müsste man Subroutinen mit festen Rücksprungadressen basteln, 
hart anspringen und der Routine mitteilen, welche Rücksprungadresse sie 
zum return benutzen soll. Also nur mit festen JMPs arbeiten, jedes RET 
wird das Ding zur Hölle schicken. Die Adresse der Rücksprungadresse im 
ROM vielleicht auf SS:SP laden, dann würde ein RET funktionieren - ist 
aber nichts anderes als feste Rücksprungadressen.

Aber wozu soll so ein recht leistungsfähiger Prozessor wie ein 8086 oder 
Z80 ganz ohne RAM gut sein?

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
> Ohne RAM funktioniert nunmal kein Stack

Zumindest keiner im RAM. Manche Controller haben den aber im Core.

> Folglich müsste man Subroutinen mit festen Rücksprungadressen basteln,
> hart anspringen und der Routine mitteilen, welche Rücksprungadresse sie
> zum return benutzen soll.

Diese Version hab ich schon irgendwo gesehen: Die Rücksprungadresse 
steht im ROM und ihre Adresse landet in SP. Die Routine endet mit ganz 
gewöhnlichem RET. Geht natürlich nur, wenn SP aufs ROM zeigen kann, was 
bei AVR oder 6502 nicht funktioniert.

Aber man kann sich natürlich auch auf ein Register für die Returnadresse 
einigen. Siehe ARM und andere RISCs, bei denen ein Stack reine 
Konvention ist, seitens der ISA nicht festgelegt.

Auf solche oder ähnliche Art fing ein archaischer PC im BIOS zu arbeiten 
an. Da wusste er nämlich noch nicht, ob er überhaupt funktionsfähiges 
RAM hat. Und sollte es immerhin bis zum kläglichen Piepsen schaffen.

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> @Joachim
> Versuch mal "MOV" beim x86 Assembler

Ben B. schrieb:
> MOV al,88h
> MOV ax,8086h

ach das meintest du
nur weil der Akku mit mov geladen wird statt LDA oder LD A,x

und Register mit mov direkt geladen werden können ist die Bezeichnung 
mov einfallslos.

Der Code ist halt schwerer zu überblicken und evtl. leichter mit Fehler 
zu machen, nur noch mov:
mov
mov
mov
mov

wie öde, da liest sich das spannender
9300 LDI XH, 7Bh(123d)
9302 LDI XL, B2h(178d)
9304 LDI YH, 78h(120d)
9306 LDI YL, 50h(80d)
9308 LDI UL, 0Dh(13d)
930A TIN
930B LOP UL, 03h(3d)
930D LDI A, 22h(34d)
930F STA (785Eh)
9312 LDI A, 0Dh(13d)
9314 STA (785Fh)
9317 LDI UH, 78h(120d)
9319 LDI UL, 50h(80d)
931B LDI A, 22h(34d)
931D CPA, (7850h)(30800d)
9320 BZS+, 3 (9325h)
9322 LDI UH, 01h(1d)
9324 RTN
9325 LIN U
9326 LIN U
9327 CPI A, 22h(34d)
9329 BZS-, 9 (9322h)
932B CPI A, 0Dh(13d)
932D BZS-, 13 (9322h)
932F NOP
9330 NOP
9331 push A

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-2 lesenswert
nicht lesenswert
> Manche Controller haben den [Stack] aber im Core.
Das würde ich als internes RAM bezeichnen.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
>> Manche Controller haben den [Stack] aber im Core.
> Das würde ich als internes RAM bezeichnen.

Ich nicht. RAM heisst Random Access Memory, und genau das musst du bei 
einem reinen Return-Stack nicht können. Du musst stets nur an eine 
einzige Speicherzelle ran.

Obendrein musst du bei dieser Denkweise aufpassen, dass ein Registerfile 
nicht auch zum RAM wird, und eine RAM-lose CPU dann auch keine variablen 
Register haben kann. Mit einem fest auf 0 verdrahteten Akku programmiert 
es sich schlecht. ;-)

von dirk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gruss

486 er Boards fingen damals mit
10 tausend DM an, nachher Richtung Pentium wurden die günstiger, die 
Sparc Stations mit
mit Software auch. Das waren noch Zeiten. Ein DIN plotter äquivalent zu 
einen Mercedes 190.
Der kleine AVR hat das Zeug zu einem Transputer, bei aller 
Bereitstellung mit Occam und RTOS
, geht aber nicht(so).

Dirk St

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
dirk schrieb:
> 486 er Boards fingen damals mit 10 tausend DM an

Der erste IBM PC/AT lag m.W. auch in der Region.

: Bearbeitet durch User
von xyz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> > So viel wie RAM da ist, - Daten, - Programm.
> > Ein Z8002 hat immerhin schon ein eigenes Stacksegment (max. 64k).

> Eben kein RAM. zB in Herrn Eaters Videos stellt man fest dass ein 6502
> ohne RAM keine Subroutinen kann

Dann schliess halt welchen an.

Dazu brauche ich nicht mal das Video ansehen um die Aussage
ebenfalls bestaetigen: "Ein 6502 kann ohne angeschlossenes RAM
keine Subroutinen."
Aber Pech, ich habe hier auch einen aufgebohrten 6502 im
64. pol Zigzaggehaeuse der internes RAM besitzt.
Der braucht nur ein 2 kB EPROM extern...

Manche Controller sind einfach nicht dafuer gedacht ohne
RAM zu funktionieren. Warum sollte man das hier nun
zum Extrathema auswalzen?

Begnueg dich halt mit einem 8008. Wenn dir so viel daran liegt.

Pfiffige Compiler umgehen das Stacklimit mancher Architekturen
durch eine "eigene" Verwaltung. Z.B. der XC8 wenn es denn eng wird.



Kaufhaus Patzig: "Beehren sie uns bald wieder. Aber bitte nicht
so schnell."

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
dirk schrieb:
> 486 er Boards fingen damals mit
> 10 tausend DM an

Computerei war nie billig, jedenfalls damals nicht
Jeder Speicherchip den ich selbst verlötete x8 oder x14 oder x16 -> 
50,-DM
Floppy Nachbau apple2 600,-DM
Festplatte Atari 40MB + 44MV SyqQuest 4000,-DM
Mein erstes 486er/66 ISA/localBUS Board 2000,-DM

Die erste 486er Ausrüstung im Dienst 20000,-DM mit 19" Monitor bekam 
unser Werkstudent (der Chef war erstaunt warum der Studi?)

Unser Werkstudent räumte unseren Mistcode auf und kam so auf mehr 
Compilerläufe in weniger Zeit, die "wir" nur vor blinkenden Cursor 
vertrödelten durch grübeln.

: Bearbeitet durch User
von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Bewertung
0 lesenswert
nicht lesenswert
Michael S. schrieb:
> Jetzt möchte ich mich an 8086 Prozessoren heranwagen. Was benötige ich
> denn hierzu ?

Einen adäquaten Datenspeicher: 
https://www.youtube.com/watch?v=vkFoLgC6WV0

von Armin K. (-donald-) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Ich sehe seither Rechner
> mit nur 1 Rechenregister als einen Irrweg der Geschichte an. Der 8051
> zählt auch dazu, genauso wie der 8048. Und auch der PIC.

Lothar, was meinst du mit 1 Rechenregister? Die ALU?
Worauf ich hinaus will, wie unterscheidet sich der PIC vom AVR 
diesbezüglich?

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Mit einer Handvoll gleichartiger Register programmiert es sich 
wesentlich angenehmer, als mit einem einzigen Akkumulator als Nadelöhr.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
(prx) A. K. schrieb:
> Mit einer Handvoll gleichartiger Register programmiert es sich
> wesentlich angenehmer, als mit einem einzigen Akkumulator als Nadelöhr.

Ich bin die umständliche Situation gewohnt. Jeden Befehl auf jedes 
Register Anwendung zu können fände ich schon Mega praktisch.

Heißt die ALU dann noch ALU, oder gibt es dafür einen speziellen 
Fachbegriff?

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Heißt die ALU dann noch ALU,
> oder gibt es dafür einen speziellen Fachbegriff?

Die ALU verändert sich ja nicht. Sie kann nur von unterschiedlichen 
Registern gespeist werden - es fällt also das magische 
Akkumulator-Register weg.

von Duke Nukem (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> mit nur 1 Rechenregister ... Und auch der PIC.

Dann hast du die Architektur des PIC nur noch nicht verstanden.
Der PIC hat fast so viele Akkus wie er Register hat.

Das "Operandenhilfsregister" aka W ist kein Akkumulator.

von (prx) A. K. (prx)


Bewertung
3 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Heißt die ALU dann noch ALU, oder gibt es dafür einen speziellen
> Fachbegriff?

Verwechselst du vielleicht Akku mit ALU?
=> https://studfile.net/preview/4050257/page:66/

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Duke Nukem schrieb:
> Das "Operandenhilfsregister" aka W ist kein Akkumulator.

Ein klassischer Akku aus der Lehre zu Rechnerarchitekturen ist stets das 
Zielregister von Rechenoperationen. Das W Register kann in der 
Basisarchitektur der PICs alternativ die Rolle des Operandenregister 
haben, mit Ziel im RAM. Das ändert nichts am Problem, dass es der 
Flaschenhals ist, durch den man oft durch muss.

Dass PICs auch Rechenoperationen zum Speicher hin durchführen können, 
unter Umgehung des W-Registers, ist kein Alleinstellungsmerkmal. Das 
kann z.B. die 6502 mitunter auch. Man muss auch nicht unbedingt streng 
der Nomenklatur von Microchip folgen, in der manches ein wenig anders 
heisst. Deren Bytes im RAM als Register zu bezeichnen ist wie Raider und 
Twix.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
(prx) A. K. schrieb:
> Verwechselst du vielleicht Akku mit ALU?

Nein, ich wollte darauf hinaus, ob eine ALU ohne Akku noch so heißt oder 
ob das Konstrukt einen speziellen Namen hat.

von dirk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gruss in die Runde

ALU
Arithmetisch logische Einheit(Unit). Ich hab hier noch ein(e)74LS181 ( 
es gab noch weitere)liegen, das war auch mal interessant mit der zu 
arbeiten.
Die Register kommen erst im Umfeld dazu.
In der Chip war mal eine Artikel Serie die beschrieb wie man
eine CPU zusammenbekommt, 74LS193 usw. nah ja heute hab ich noch eine 
HP, die wurde mal als Kleiderschrank bezeichnet, in Erinnerung.

Dirk St

von Percy N. (vox_bovi)


Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:
> Die ALU verändert sich ja nicht. Sie kann nur von unterschiedlichen
> Registern gespeist werden - es fällt also das magische
> Akkumulator-Register weg.

Auch die ALU des z80 kann aus verschiedenen Registern gespeist werden; 
und als Zielregister ist nicht zwingend der Akku vorgegeben.
So lassen sich Rwgisterpaare unmittelbar in- und dekrementieren sowie zu 
den Indexregistern HL, IY und IY addieren bzw davon subtrahieren.

Bequemer geht es natürlich universeller. Im Disassemblat alter 
CP/M-Programne findet man  Hilfskonstruktionen, die es ermöglichen, zB 
DE anstelle von HL einzusetzen bzw ein virtuelles "CALL (DE)" oder 
"Ccond (DE)" oder Ähnliches ermöglichen. Warum die seinerzeit 
verwendeten Compiler par tout DE für berechnete Sprungziele verwenden 
wollten, ist mir nicht bekannt.

: Bearbeitet durch User
von soso... (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Michael S. schrieb:
> Jetzt möchte ich mich an 8086 Prozessoren heranwagen

Was erwartest Du dabei?
Die ollen 8086 sind arschlangsam und jedem stm32 hoffnungslos 
unterlegen.
Welchen Erkenntnissgewinn erhoffst Du Dir bei 8086 ASM im Vergleich zu 
AVR ASM?
Das beim 8086 einfach alles noch viel furchtbarer ist?

von Purzel H. (hacky)


Bewertung
1 lesenswert
nicht lesenswert
Vielleicht hat Opa davon geschwaermt, und jetz soll das mal angeschaut 
werden. Ich fand die 8086 sehr lehrreich.

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Nein, ich wollte darauf hinaus, ob eine ALU ohne Akku noch so heißt oder
> ob das Konstrukt einen speziellen Namen hat.

Diese beiden Begriffe haben nichts miteinander zu tun. Eine ALU enthält 
keinen Akkumulator, kann lediglich mit einem kombiniert werden.

: Bearbeitet durch User
von Percy N. (vox_bovi)


Bewertung
-1 lesenswert
nicht lesenswert
(prx) A. K. schrieb:
> Diese beiden Begriffe haben nichts miteinander zu tun. Eine ALU enthält
> keinen Akkumulator, kann lediglich mit einem kombiniert werden.

Zu ergänzen: ... muss es aber nicht.

Andererseits kannst Du zB im ATMega auch nicht mit sämtlichen RAM-Zellen 
rechnen, sondern hast ein Registerfile, mit teilweise recht speziellen 
Eigenschaften ...

von S. R. (svenska)


Bewertung
3 lesenswert
nicht lesenswert
Percy N. schrieb:
> [vieles]

Beim 8080 zählt A als 8-Bit-Akkumulator und HL als 16-Bit-Akkumulator.

Gibt halt zwei davon (und beim Z80, der HL durch IX/IY ersetzen kann, 
noch zwei weitere, plus umschaltbaren Registersatz). Ändert nix daran, 
dass es eine Akkumulatorarchitektur ist und die meisten Operationen 
trotzdem durch A laufen.

: Bearbeitet durch User
von Percy N. (vox_bovi)


Bewertung
-2 lesenswert
nicht lesenswert
S. R. schrieb:
> Gibt halt zwei davon (und beim Z80, der HL durch IX/IY ersetzen kann,
> noch zwei weitere, plus umschaltbaren Registersatz). Ändert nix daran,
> dass es eine Akkumulatorarchitektur ist und die meisten Operationen
> trotzdem durch A laufen.

Ähnliches, lediglich mit größeren jeweigen Zahlen, dürfte dann aber auch 
zB für AVR gelten.
Oder kann man da von/in beliebige RAM-Zelken rechnen?

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
Ich merke schon, du willst nur streiten.

von Percy N. (vox_bovi)


Bewertung
-3 lesenswert
nicht lesenswert
S. R. schrieb:
> Ich merke schon, du willst nur streiten.

Nee, das stimmt so nicht.
Mir ist bekannt und geläufig, dass bei AVR bestimmte Funktionen nur in 
bestimmten Registern zur Verfügung stehen.
Daneben erinnere ich mich ganz, ganz dunkel des durch Herrn Wang 
entwickelten RMW-Zyklus, der wohl im gesamten RAM funktionierte, winre. 
Demnach wäre also die olle IBM eher akkufrei als AVR. Stimmt das soweit?
Ja, die Frage ist ernst gemeint.

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Percy N. schrieb:
> Mir ist bekannt und geläufig, dass bei AVR bestimmte Funktionen nur in
> bestimmten Registern zur Verfügung stehen.

Klar. Die Multiplikation und r0/r1. Und? Das macht keine Akkus draus.

: Bearbeitet durch User
von MCUA (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
ALU ist rein combinatorisch.

Akku-Archi.. hat (meist) den Flaschenhals, das Operationen durch den 
Akku müssen.
(Bei PIC12/14/16/18 ist das auch der Fall, obwohl hier als Ziel auch das 
MEM sein kann)
Register-Archi.. hat (meist) den Flaschenhals, dass Operanden sehr oft 
mit sep. Befehl aus'm MEMory geholt werden müssen.

Also was benutzen?
Eine Archi.., die alle Vorteile vebindet.

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
MCUA schrieb:
> Eine Archi.., die alle Vorteile vebindet.

Also x86 statt ARM, weils bei x86 mem=>reg Operationen gibt, während der 
Code bei ARM durch den Flaschenhals muss? Wie das ausgehen kann, wird 
dieser Tage von Apple eindrucksvoll demonstriert.

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Percy N. schrieb:
> Demnach wäre also die olle IBM eher akkufrei als AVR. Stimmt das soweit?

Nein.

von Percy N. (vox_bovi)


Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:
> Nein.

Es könnte meinem Erkenntnisgewinn durchaus förderlich sein, wenn sich 
dieses "Nein" doch noch etwas elaborieren ließe.
Oder legst Du es darauf an, gerade diesen möglichst zu vermeiden?
(Dass RMW eng mit der Kernspeichertechnologie zusamnenhängt, ist mir 
bewusst)

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Percy N. schrieb:
> Demnach wäre also die olle IBM eher akkufrei als AVR.

AVR hat keinen Akku.

von Percy N. (vox_bovi)


Bewertung
-1 lesenswert
nicht lesenswert
(prx) A. K. schrieb:
> Percy N. schrieb:
>> Demnach wäre also die olle IBM eher akkufrei als AVR.
>
> AVR hat keinen Akku.

Das ist mir durchaus klar. Es geht darum, das Svenska meinte, der z80 
habe mehrere Akkus, getrennt für 8bit und 16 bit ops. Dazu dann loch der 
zweite Registersatz ...
AVR hat 32 privilegierte Register, die man möglicherweise als Akkus 
ansprechen könnte.

Bei den alten IBMs bin ich mir nicht sicher, ob es erforderlich war, in 
einen Akku zu rechnen, wenn der gelesene Operand ohnehin wieder 
geschrieben werden musste, im nicht verloren zu gehen. Da hier slso 
ohnehin ein Schreibvorgang  erforderlich war, stand der ALU also 
entweder kein Akku uur Verfügung oder derer so viele, wie die Maschine 
RAM-Worte.hatte.
Das war mein Ansatz.
Oder hatte IBM damals einen separaten Registersatz?

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Percy N. schrieb:
> AVR hat 32 privilegierte Register, die man möglicherweise als Akkus
> ansprechen könnte.

Worauf willst du raus? Ein wasserdichtes Kriterium dafür, ab wann ein 
Akku ein Register oder umgekehrt? 6800 hatte 2 Akkus, da gabs keinen 
Streit drum. Data Generals Nova hatte 4 Register, die AC0..AC3 hiessen, 
AC für Accumulator, die aber auch Adressregister waren. Renesas 
R8C..R32C haben 4 Datenregister, diesmal Adressregister extra, die nicht 
Akku heissen. Die 8-Bit PICs andererseits haben einen Akku, aber manchen 
schwillt der Kamm, wenn man den so nennt.

Ein mögliches Kriterium ist die Frage, wo der zweite Operand liegt. 
Architekturen mit einem oder wenigen Registern, bei denen der andere 
Operand i.d.R. im Speicher liegt, kann man dann unter "Akku" abbuchen. 
Finden die Rechenoperationen oft oder ausschliesslich zwischen den 
Registern statt, dann eher nicht.

Die beiden Akkus der 6800 waren in diesem Sinn eindeutig welche, denn 
die konnten nicht miteinander, sondern nur jeder für sich gegen den 
Speicher. Bei AVR, generell allen Architekturen, die klar zwischen 
Load/Store- und Register/Register-Operationen unterscheiden, redet man 
nicht von Akkus. Bei der Nova waren die 4 sogenannten Akkus eigentlich 
keine, denn es sind zwar wenige, aber die meisten Rechenoperationen 
fanden nur zwischen denen statt.

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
Percy N. schrieb:
> Oder legst Du es darauf an, gerade diesen möglichst zu vermeiden?

Nein. Aber du willst jede meiner Aussage durch den Dreck ziehen und 
darauf habe ich keine Lust. (Eine ausführlichere Antwort habe ich 
entfernt.)

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Percy N. schrieb:
> Bei den alten IBMs bin ich mir nicht sicher, ob es erforderlich war, in
> einen Akku zu rechnen,

Wovon ist bei "den alten IBMs" eigentlich die Rede? Da ist mir der 
Kontext entgangen. Die 650 hatte nur Speicher, die alten 7er Mainframes 
waren m.W. mit Akku, ab 360 waren etliche gleichberechtigte Register 
angesagt.

Akkus waren früher populär, weil Register in der Implementierung 
sauteuer waren. RCA hatte bei der 1802 für die 16 Register insgesamt 256 
Bits verbraten (grad wie AVR). Bei 6 Transistoren pro Bit und 5000 
insgesamt... Bei der 6502 waren die Transistoren anderweitig investiert, 
und zwar weit nützlicher.

https://en.wikipedia.org/wiki/Transistor_count

: Bearbeitet durch User
von Percy N. (vox_bovi)


Bewertung
-1 lesenswert
nicht lesenswert
(prx) A. K. schrieb:
> Ein mögliches Kriterium ist die Frage, wo der zweite Operand liegt.
> Architekturen mit einem oder wenigen Registern, bei denen der andere
> Operand i.d.R. im Speicher liegt, kann man dann unter "Akku" abbuchen.
> Finden die Rechenoperationen oft oder ausschliesslich zwischen den
> Registern statt, dann eher nicht.

Interessant.
Ich hatte die Vorstellung entwickelt, ein Akku sei ein Register, das 
sich vor den meisten anderen Speicherelementen dadurch auszeichnet, dass 
die ALU unmittelbar darauf Berechnungen ausführen kann. Das,wäre beim 
8080 etwa A, aber auch HL. Weiterhin kann BC als Akku wirken, etwa bei 
DJNZ, aber eben leider nur für diese Operation.
Ich hoffe, es ist klar, was ich meine.

Edit: Sofern das Ergebnis in diesem Speicherort abgelegt wird, ohne 
gesonderten MOV-Befehl, sei es ein Akku.

Demgegenüber stelle ich mir eine Maschine vor, die "im Speicher rechnen" 
kann, wo also theoretisch wie auch praktisch jedes adressierbare 
Speicherwort auf beliebige Weise mit jedem anderen Speicherwort 
arithmetisch oder logisch verknüpft werden kann.

Ich hege die Vorstellung, dass das bei den alten Mainframes mit 
Kernspeicher so gewesen sein könnte, weil ohnehin der Speicher bereits 
zum Datenerhalt nach jeder Operation hinsichtlich der beteiligten 
Speicherworte beschrieben werden musste (ich hatte das oben schon 
angedeutet). Das sollte auch Deine Frage nachcser Generation 
beantworten.

S. R. schrieb:
> Aber du willst jede meiner Aussage durch den Dreck ziehen und darauf
> habe ich keine Lust.
Es ist schade, dass Du mich so erlebst; ich vermute, für uns beide.
> (Eine ausführlichere Antwort habe ich entfernt.)
Das ist, je nach Art der Antwort,  entweder besser so oder aber 
bedauerlich.

: Bearbeitet durch User
von Matthias W. (matthias_w552)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Was brauche ich um Apfelmus herzustellen ?

Antwort: Nimm doch Birnen schmeckt mir besser

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Percy N. schrieb:
> Ich hoffe, es ist klar, way ich meine.

Ungefähr, aber das bringts nicht wirklich. Zumal man eigentlich zwischen 
der inneren Struktur und der Rolle in Befehlen unterscheiden muss.

Im Lehrbuch: Am linken Eingang der ALU hängt ein einzelnen Register, 
Akku genannt, am rechten das Speicherdatenregister, und das Ergebnis 
geht wieder in den Akku. So weit die schematisierende Theorie für die 
Lehre.

In der Praxis ist es weniger einfach, wenn man an den Eingängen und am 
Ausgang der ALU diverse Register zur Wahl hat. Bei 8080 immerhin 7 
benannte. Aus der Verdrahtung ergibt sich keine Bevorzugung von A 
gegenüber B. Der Unterschied zwischen einer Rolle als Akku, oder der 
eines Universalregisters, ergibt sich dann aus den Befehlen, nicht aus 
der Struktur des Kerns.

Konzentrieren sich die Rechenbefehle auf ein einzelnes Register, kann 
man dem die Rolle als Akku zusprechen. Sind etliche Register 
gleichberechtigt (AVR), wird man das kaum tun.

> Weiterhin kann BC als Akku wirken

Nö. Du solltest wirklich dein Verständnis des Begriffs neu kalibrieren. 
Dass es einem Befehl gibt, der C zählend nutzt, hat mit "Akku" absolut 
nichts zu tun. Nicht in der Struktur, und nicht in der Rolle.

> Sofern das Ergebnis in diesem Speicherort abgelegt wird, ohne
> gesonderten MOV-Befehl, sei es ein Akku.

Die 8080 hat ein Registerfile, bestehend mindestens aus A,B,C,D,E,H,L 
(evtl noch Temps), strukturell sind die alle gleich.

: Bearbeitet durch User
von Percy N. (vox_bovi)


Bewertung
-1 lesenswert
nicht lesenswert
(prx) A. K. schrieb:
> Die 8080 hat ein Registerfile, bestehend mindestens aus A,B,C,D,E,H,L
> (evtl noch Temps), strukturell sind die alle gleich.

Ja, das kommt einem Punkt nahe, een ich meinte. Diese Register sind 
sicherlich vor dem externem RAM ausgezeichnet. Innerhalb dieser Register 
sindxaber wiederum A und HL ausgezeichnet. Welche Rolle spielt hierbei M 
(aka (HL))?

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Percy N. schrieb:
> Ich hege die Vorstellung, dass das bei den alten Mainframes mit
> Kernspeicher so gewesen sein könnte,

Also indem der Kernspeicher zerstörend gelesen wurde, die Daten durch 
die CPU gingen, und erst dann die gleiche Speicherstelle durch die CPU 
wiederhergestellt wurde?

Ich will nicht ausschliessen, dass jemand mal diese Idee hatte, aber 
üblicherweise waren Speichermodule wie heute eigenständige Einheiten, 
die selbst dafür sorgten, dass der Inhalt bei Lesen wiederhergestellt 
wird. DRAM wird ja auch zerstörend gelesen, aber auch da sorgt das DRAM 
selbst für Wiederherstellung.

Das ist schon von der Länge des Datenpfades her unwahrscheinlich. 
Kernspeicher grosser Maschinen umfasste ggf mehrere Schränke, ebenso die 
CPU. Die Daten in jedem Zyklus durch diese ganze Schrankbatterie vor und 
zurück durchreichen? Vergiss es.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Percy N. schrieb:
> Welche Rolle spielt hierbei M (aka (HL))?

Innerhalb des Befehlssatzes beschreibt M, bzw. in Z80-Mnemonics einen 
indirekten Speicherzugriff, wobei im Registerpaar HL die Adresse steht.

Und weil man Adressen öfter mal incrementieren und decrementieren muss, 
hat Intel dem Befehlssatz dafür spezielle Befehle spendiert.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Percy N. schrieb:
> Innerhalb dieser Register
> sindxaber wiederum A und HL ausgezeichnet.

Intels Befehlsdefinition bevorzugt bestimmte Register für bestimmte 
Rollen. Die innere Struktur hätte 2- oder 3-Adress-Befehle in diesen 
Registern zugelassen (reg1 = reg2 + reg3), der 8-Bit Opcode-Space aber 
nicht. 25% davon Opcode-Space ging ja schon für MOV drauf.

> Welche Rolle spielt hierbei M (aka (HL))?

Historisch zu sehen. Der Vorgänger 8008 hatte m.E. nur diese eine Form 
der Adressierung des Datnspeichers. Keine absolute Adressierung, nur 
(HL).

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Percy N. schrieb:
> Ich hatte die Vorstellung entwickelt, ein Akku sei ein Register, das
> sich vor den meisten anderen Speicherelementen dadurch auszeichnet, dass
> die ALU unmittelbar darauf Berechnungen ausführen kann.

Richtig. Ob das nun durch die Struktur oder "nur" den Befehlssatz 
erfolgt, ist dabei nebensächlich - denn für den Programmierer macht es 
keinen Unterschied.

> Das,wäre beim 8080 etwa A, aber auch HL.

Rein technisch handelt es sich ausschließlich um A, siehe 
https://en.wikipedia.org/wiki/Intel_8080#/media/File:Intel_8080_arch.svg

Der Befehlssatz erlaubt geringfügige Berechnungen auf HL, aber wie die 
CPU das intern löst, hat für den Programmierer nur wenig Bedeutung.

> Weiterhin kann BC als Akku wirken, etwa bei
> DJNZ, aber eben leider nur für diese Operation.

Nicht alles, was hinkt, ist ein Vergleich.
Und nicht alles, was eine ALU füttert, ist ein Akku.

> Ich hoffe, es ist klar, was ich meine.

Ja. Und es widerspricht dem allgemeinen Verständnis. :-)

>> Aber du willst jede meiner Aussage durch den Dreck ziehen und darauf
>> habe ich keine Lust.
> Es ist schade, dass Du mich so erlebst; ich vermute, für uns beide.

Das war etwas harsch ausgedrückt, aber deine Vorstellung ist extrem weit 
weg von meiner Vorstellung, dass deine Fragen auf mich eher lächerlich 
wirkten als fragend. Entschuldigung.

>> (Eine ausführlichere Antwort habe ich entfernt.)
> Das ist, je nach Art der Antwort,  entweder besser so oder aber
> bedauerlich.

Du hast das meiste später inhaltlich selbst wiedergegeben.
Nur die Schlussfolgerung ist eine andere.

Nur, weil es Befehle gibt, der HL oder BC fest verdrahtet nutzt, werden 
diese Register nicht zu Akkumulatoren. Denn sonst wären ja sämtliche 
Register eines AVR solche, und dort benutzt man diesen Begriff 
offensichtlich nicht.

Der Akkumulator ist ein besonderes Register, durch welches die meisten 
Rechenoperationen durch müssen. Beim AVR ist fast jedes Register dazu 
geeignet, also entfällt die Besonderheit - es ist keine akkuzentrische 
Architektur. Beim 8086 oder 8080 gibt es genau ein Register (AX, bzw. 
A), welches offensichtlich diese Sonderstellung genießt. Daher ist die 
Architektur eine akkuzentrische Architektur. Dass es zusätzlich noch 
Hilfs- oder Nebenakkumulatoren gibt, ändert nichts an dieser 
Besonderheit.

HL beim 8080 ist deswegen ein Hilfsakku, weil man damit direkt 
16-Bit-Operationen durchführen kann. Der Operand würde nicht in A 
passen, also haben sich die Entwickler dazu entschieden, das 
Registerpaar HL zu benutzen.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:
> Beim 8086 oder 8080 gibt es genau ein Register (AX, bzw.
> A), welches offensichtlich diese Sonderstellung genießt.

Bei 8086 ist die Bevorzugung von AX nur relativ schwach ausgeprägt. Es 
gibt zwar einige Operationen, die es nur damit gibt, aber die meisten 
Befehle sind auch mit den übrigen Registern möglich. Manches lässt sich 
damit kürzer codieren, aber das ist nebensächlich. Daher würde ich 8086 
nicht als ausgeprägte Akku-Architektur bezeichnen.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:
> Ob das nun durch die Struktur oder "nur" den Befehlssatz
> erfolgt, ist dabei nebensächlich

Da es hier um Begriffsdefinitionen geht und auch der Begriff ALU 
mitschwimmt, ist der Blick ausschliesslich aus Sicht des 
Asm-Programmierers auf die ISA zu kurz gegriffen. Dem ist nämlich auch 
egal, ob es eine einzige ALU gibt, oder ein halbes Dutzend getrennte 
Einheiten.

Wenn wir aber schon runter auf jene Struktur gehen, in der man von einer 
ALU redet, ist die Doppelbedeutung des Begriffs "Akku" nicht 
nebensächlich.

Beitrag #6482157 wurde von einem Moderator gelöscht.
von soso (Gast)


Bewertung
1 lesenswert
nicht lesenswert
> dreistfrech und feige
> hinterhältig?

Sagt der, der beständig anonym diesen Kack postet.

Welchen tieferen Sinn entdeckst Du denn hier noch?
Hausaufgabenhilfen, Soziale Totalausfälle, Beleidigungen und agressives
Verhalten wird toleriert, beliebige Themen auch, solange bis irgendwer
einen Koller bekommt und 'aufräumt' was immer man auch darunter
verstehen mag.

Geh doch einfach.
Hast ja nicht unrecht, aber warum dann dieses Festhalten an dem
abgewirtschafteten Forum?

Beitrag #6482177 wurde von einem Moderator gelöscht.
Beitrag #6482180 wurde von einem Moderator gelöscht.
Beitrag #6482182 wurde von einem Moderator gelöscht.
von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Renesas R8C..R32C haben 4 Datenregister, diesmal Adressregister extra,
> die nicht Akku heissen.
R8C..M16C..M32C haben 4 Datenregister, 2 nrm. Adressregister, 2 spez. 
Adressregister.
R32C haben 8 Datenregister, 4 nrm. Adressregister, 2 spez. 
Adressregister
RX haben 16 GP-Register (CISC).
Diese Datenregister oder GP-Register kann man auch als Akku(s) oder 
AkkuRegister(s) bezeichnen.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
MCUA schrieb:
>> Renesas R8C..R32C haben 4 Datenregister, diesmal Adressregister extra,
>> die nicht Akku heissen.
> R8C..M16C..M32C haben 4 Datenregister, 2 nrm. Adressregister, 2 spez.
> Adressregister.

Danke, die waren gemeint.

: Bearbeitet durch User
von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Duke Nukem schrieb:
>> mit nur 1 Rechenregister ... Und auch der PIC.
> Dann hast du die Architektur des PIC nur noch nicht verstanden.
Ich habe sie verdrängt und/oder gnädigerweise vergessen.

> Der PIC hat fast so viele Akkus wie er Register hat.
> Das "Operandenhilfsregister" aka W ist kein Akkumulator.
Stimmt, das war ja noch kruder: da ist ein Register, das zur ALU gehört, 
auf der Eingangsseite immer fix.
Im Gegensatz dazu ist bei "üblichen" Akku-Architekturen halt immer das 
Ausgangsregister der ALU fix.
An der Unflexibilität ändert das in der Summe also nichts. Beim PIC ist 
dann halt der "Flaschenhals" auf der Eingangsseite...

soso schrieb:
> Sagt der, der beständig anonym diesen Kack postet.
Das ist Moby, ein bis zum Fanatismus ausgeprägter Assembler-Liebhaber. 
Er hat seine Liebe zum Assembler hier im Forum damit ausgelebt, dass er 
Hass und Beschimpfungen über andere User ausgeschüttet hat.
Seit seinem Rauswurf aus dem Forum hat er es immerhin geschafft, diesen 
allgemeinen Hass auf einen kleinen Personenkreis aka. Moderatoren zu 
konzentrieren. Ich betrachte das durchaus als Fortschritt in seiner 
Persönlichkeitsentwicklung.

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Alle möglichen Befehle mit MOV zu kodieren hilft nicht mal Programmieren 
mit löcherigem Gedächtnis, da sie ja dann doch die Parameter wissen 
müssen. Getrennte Mnemonics für getrennte Funktionen sind da 
übersichtlicher. Sonst könnte man ja einen Assembler mit dem einzigen 
Befehl "EXEC" entwerfen und alles weitere wird über die Parameter 
unterschieden. Das mag ja Geschmackssache sein, aber ich finde das nicht 
besonders gut lesbar.

Ist ja vielleicht auch Geschmackssache, aber meiner Meinung nach sollte 
auch ein Assembler-Programm lesbar sein, kein Write-Only-Code. Die 
Zeiten zu denen Programmierer absichtlich unlesbare Programme schrieben, 
um unkündbar zu sein sind lange vorbei.

Georg

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-1 lesenswert
nicht lesenswert
> Sonst könnte man ja einen Assembler mit dem einzigen
> Befehl "EXEC" entwerfen
Contra.

EXEC AX,BX
EXEC CX,BX
EXEC AX,AX

Schon verloren!

von MCUA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Das (8bit)PIC W-Register kann fungieren wie ein herkömmlicher Akku (ist 
also nicht schlechter), zudem kann das Ergebnis der Berechnung (aus W 
und MEM) auch in MEM reingeschrieben werden.
..das ist quasi ein erweiterer Akku.

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
(prx) A. K. schrieb:
> Dem ist nämlich auch egal, ob es eine einzige ALU gibt,
> oder ein halbes Dutzend getrennte Einheiten.

Wenn man damit anfängt, müsste man aber auch anfangen, den Z80 mit 
seiner 4-Bit-ALU als 4-Bit-Architektur bezeichnen, und damit will ich 
nun wirklich nicht anfangen.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Georg schrieb:
> Sonst könnte man ja einen Assembler mit dem einzigen
> Befehl "EXEC" entwerfen und alles weitere wird über die Parameter
> unterschieden.

Wobei TI 9900 tatsächlich einen Befehl hatte, der seinen Operand als 
Opcode ansah und diesen ausführte.

von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Stimmt, das war ja noch kruder: da ist ein Register, das zur ALU gehört,
> auf der Eingangsseite immer fix.
> Im Gegensatz dazu ist bei "üblichen" Akku-Architekturen halt immer das
> Ausgangsregister der ALU fix.
> An der Unflexibilität ändert das in der Summe also nichts. Beim PIC ist
> dann halt der "Flaschenhals" auf der Eingangsseite...

Lothar, es mag ja sein, daß du eine abgrundtiefe Aversion gegen die 
Architektur der PIC hast, aber das ändert nichts daran, daß du selbige 
ganz offensichtlich falsch siehst.

Den Flaschenhals gibt es nicht, denn eine gehörige Portion von 
Maschinenbefehlen arbeitet eben direkt in den RAM-Zellen und in den 
Hardwareregistern - ohne Beteiligung von W.

Du hingegen denkst immerzu nur an eine Load-Modify-Store-Architektur. 
Das paßt nicht auf die PIC's. Rotationen, Bitmanipulationen, bedingte 
Sprünge, Inkrement+Dekrement, Schleifenzählungen (DECFSZ) usw. gehören 
dazu.

Es ist nicht so, daß man genau diese Architektur lieben muß, aber sie 
ist bei genauerem Hinschauen ausgesprochen pfiffig aufgebaut und 
effektiv - solange man in Assembler programmiert und kein Brett vor dem 
Kopfe hat. Für maschinenunabhängige Hochsprachen hingegen ist diese 
Architektur schlichtweg nicht wirklich gut geeignet. Man muß so etwas 
beim Entwurf eines Projektes eben berücksichtigen - und auch wenn man 
eine Einschätzung oder auch nur abschätzige Bemerkungen von sich geben 
will.

Wahrscheinlich ist das genau so wie mit Austern: Diese teilen die 
Menschheit in exakt 2 Gruppen: solche, die Austern mögen und solche, die 
Austern verabscheuen. Dazwischen gibt es nichts.

W.S.

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Doch, 8bit-PICs haben auch einen Flaschenhals.
Es können (bei 2-Adr-Befehlen, bsp ADD, SUB) nicht 2 unabhäng. 
MEM-zellen (also auch nicht bsp. R5, R8) verrechnet werden.
Der Akku/W ist da immer mit dabei.
(Und 3-Adr-Befehle hat der schon gar nicht)
Index.Adress. können die auch, ist aber je nach Typ mehr oder weniger 
eingeschränkt.
(wenn schon PIC, dann wenigstens PIC24 oder höher)

von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
MCUA schrieb:
> Es können (bei 2-Adr-Befehlen, bsp ADD, SUB) nicht 2 unabhäng.
> MEM-zellen (also auch nicht bsp. R5, R8) verrechnet werden.

Ja erwartest du denn bei einem PIC16 sowas wie eine MIPS mit 32 Bit 
breitem Befehlswort?

W.S.

von Spess53 (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Hi

Was diskutiert ihr hier eigentlich noch? Der TO hat sich seit 5 Tagen 
nicht mehr gemeldet. Hat aber anscheinend niemand bemerkt oder bemerken 
wollen.

MfG Spess

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.