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
Welches Zielsystem? Nicht nur Prozessor, auch der Rest.
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.
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.
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.
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.
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
Angehängte Dateien:
-
8086.png
160 KB
Mein Simulationsprogramm bringt ein simulierbares und nachbaubares minimal-Beispiel mit. Siehe Anhang. Proteus 7.
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
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.
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?
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.
Ichbins schrieb: > Siehe Anhang. Da werden Erinnerungen wach: "ISIS" war das Betriebssystem auf dem "MDS" Entwicklungssystem (8085-Basiert). Gruß Anja
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.
Der Z80 ist dem 8086 recht ähnlich. Da gibt es dann noch die ez80 oder so ähnlich. Auf jedenfall sind das fertige z80-Mikrocontroller.
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/
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 :)
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?
Ein 80186 wäre schon näher dran, aber in DIP gibt's den auch nicht...
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.
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.
Ichbins schrieb: > Stefanuss muss mal wieder Murks beisteuern Es gibt tatsächlich einen 8086 Assembler in Linux. Das Paket heißt bin86.
Stefan ⛄ F. schrieb: > Den 8086 kann man ja gar nicht mehr kaufen. Außer vielleicht für > phantastische Preise aus einem Museum. Quatsch. https://de.aliexpress.com/item/33030111258.html?spm=a2g0o.productlist.0.0.79c2710ezX8EJt&algo_pvid=2ec25091-ea37-4ad4-901b-3bda391daa5a&algo_expid=2ec25091-ea37-4ad4-901b-3bda391daa5a-1&btsid=0b0a187916054539726272237eedef&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_ Kinaman hat soviel noch das er sie kleines Geld verkaufen muss. https://de.aliexpress.com/item/32862777671.html?spm=a2g0o.productlist.0.0.40155ea3bjfc5D&algo_pvid=635c41a8-9959-40e5-bf6e-dde97dc783f7&algo_expid=635c41a8-9959-40e5-bf6e-dde97dc783f7-4&btsid=0b0a187916054540783973143eedef&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_ Auch als 80C186.
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
Na dann ist ja gut, dass ich den passenden Assembler gefunden habe.
> 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.
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.
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.
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
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
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.
PS. Das mit dem SRAM war beim Atari Portfolio, ein 8088 er, als Speicherkarte mit Batterie realisiert. Dirk St
debug und edlin sind ja bei Windows10 nicht mehr dabei 😉 Dirk St
dirk schrieb: > debug und edlin sind ja bei Windows10 nicht mehr dabei Noch ein Grund den Mist nicht zu wollen.
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.
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...
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 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
>> 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.
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...
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.
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 :)
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
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. :-)
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.
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
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.
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
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.
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
Und wie immer bei solchen Beiträgen ist der TO wohl raus.
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.
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... ;-)
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....
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/
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
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.
Mann muss bei 32 Bit aber auch mehr Kabel zum RAM und ROM ziehen.
Der Vorteil beim Z80 gehts auch ohne Ram! Es gibt irgendwo nette PRogramme, die alleine mit dem Z80 auskommen
Sowas hatte ich seiner Zeits mit MASM programmiert. "Download" per Hex-Keyboard :O https://en.wikipedia.org/wiki/Intel_System_Development_Kit#SDK-86
> 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.
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.
> 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.
xyz schrieb: > 8086er zu programmieren ist weder spassig noch mit Lustgewinn verbunden. Wenn schon schön schräg, dann RCAs 1802. ;-)
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/
> 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.
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...
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.
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
@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.
> kein Stack
So viel wie RAM da ist, - Daten, - Programm.
Ein Z8002 hat immerhin schon ein eigenes Stacksegment (max. 64k).
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.
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.
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
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.
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
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.
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.
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.
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.
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.
> 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
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.
> 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.
> 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.
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.
Ben B. schrieb: > so das immer anderen Dinge verschieden wichtig sind. Was aber der Grund dafür ist, dass Teilregisteroperationen aus der Mode kamen.
> 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.
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
> 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.
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.
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.
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.
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. ;-)
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
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
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
(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.
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
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
> 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.
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.
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
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.
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
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.
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
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.
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.
Stefan ⛄ F. schrieb: > Es gibt tatsächlich einen 8086 Assembler in Linux. Das Paket heißt > bin86. Ist das ein Crossassembler?
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
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?
(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.
(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.
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.
@Joachim Versuch mal "MOV" beim x86 Assembler hinsichtlich seiner Flexibilität zu schlagen... viel Glück!
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
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.
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
uwe schrieb: > MC68332 war auch schön Ich liebe die TPU und ihren ganz eigenen Assemblercode noch heute... ;-)
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.
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.
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
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.
> 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.
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 :-)
>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...
>> 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.
> 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.
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)?
@MCUA: Zitate ohne Angabe des Urhebers sind nicht nur ganz schlechter Stil, sondern mindestens auch eine grobe Unverschämtheit, um es dezent zu formulieren.
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.
>> 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.
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
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
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:
1 | mov
|
2 | mov
|
3 | mov
|
4 | mov
|
wie öde, da liest sich das spannender
1 | 9300 LDI XH, 7Bh(123d) |
2 | 9302 LDI XL, B2h(178d) |
3 | 9304 LDI YH, 78h(120d) |
4 | 9306 LDI YL, 50h(80d) |
5 | 9308 LDI UL, 0Dh(13d) |
6 | 930A TIN |
7 | 930B LOP UL, 03h(3d) |
8 | 930D LDI A, 22h(34d) |
9 | 930F STA (785Eh) |
10 | 9312 LDI A, 0Dh(13d) |
11 | 9314 STA (785Fh) |
12 | 9317 LDI UH, 78h(120d) |
13 | 9319 LDI UL, 50h(80d) |
14 | 931B LDI A, 22h(34d) |
15 | 931D CPA, (7850h)(30800d) |
16 | 9320 BZS+, 3 (9325h) |
17 | 9322 LDI UH, 01h(1d) |
18 | 9324 RTN |
19 | 9325 LIN U |
20 | 9326 LIN U |
21 | 9327 CPI A, 22h(34d) |
22 | 9329 BZS-, 9 (9322h) |
23 | 932B CPI A, 0Dh(13d) |
24 | 932D BZS-, 13 (9322h) |
25 | 932F NOP |
26 | 9330 NOP |
27 | 9331 push A |
> Manche Controller haben den [Stack] aber im Core.
Das würde ich als internes RAM bezeichnen.
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. ;-)
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
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
> > 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."
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
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
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?
Mit einer Handvoll gleichartiger Register programmiert es sich wesentlich angenehmer, als mit einem einzigen Akkumulator als Nadelöhr.
:
Bearbeitet durch User
(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?
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.
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.
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/
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
(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.
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
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
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?
Vielleicht hat Opa davon geschwaermt, und jetz soll das mal angeschaut werden. Ich fand die 8086 sehr lehrreich.
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
(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 ...
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
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?
Ich merke schon, du willst nur streiten.
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.
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
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.
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
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)
(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?
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.
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.)
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
(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
Hallo, Was brauche ich um Apfelmus herzustellen ? Antwort: Nimm doch Birnen schmeckt mir besser
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
(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))?
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.
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.
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).
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.
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.
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.
> 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.
> 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.
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
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.
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
> 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!
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.
(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.
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.
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.
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)
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.
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
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.