Welches waren die ersten 8051-Derivate mit mehreren dptr? Siemens hatte soweit ich weiß, mit dem 80C517 das erste Derivat mit 8 dptr. Aber es soll wohl auch frühe Varianten mit 2 dptr von AMD gegeben haben. Weiß jemand mehr zu denen? Welche waren die ersten mit: DPL1 auf 0x84, DPH1 auf 0x85, DPS auf 0x86.0? Philipp
Habe nun den AMD 80C521 gefunden. Das scheint ein guter Kandiat für die erste dual-dptr-Variante zu sein. Oder kennt jemand einen noch älteren? Philipp
Da könnte durchaus auch ein Derivat von Philips/NXP oder Dallas in Frage kommen aber das heraus zu Suchen wird eine echte Fleißarbeit...
Gast
#4631015
Philipp Klaus K. schrieb: > Welches waren die ersten 8051-Derivate mit mehreren dptr Ist das eine Prüfungsaufgabe? Aktuelle 8051 z.B. EFM8 haben wieder nur ein DPTR da Zugriff aufs externe RAM ohnehin mit DMA gemacht wird.
Lothar schrieb: > Philipp Klaus K. schrieb: >> Welches waren die ersten 8051-Derivate mit mehreren dptr > > Ist das eine Prüfungsaufgabe? Eigentlich wollte ich nur http://sdcc.sourceforge.net/mediawiki/index.php/8051_variants ergänzen. > Aktuelle 8051 z.B. EFM8 haben wieder nur > ein DPTR da Zugriff aufs externe RAM ohnehin mit DMA gemacht wird. SiLabs hatte auch schon beim älteren C8051 nur einen dptr, und es dann beim neuen EFM8 auch wieder so gemacht. Zilog dagegen ist ja erst vor wenigen Jahren mit dem Z8051 eingestiegen, mit 8 dptr. Philipp
Wobei die mehreren Datenpointer nicht wirklich was bringen, weil z.B. beim Kopieren ständig umgeschaltet werden muß. Schneller geht das Kopieren daher mit DPTR als ein Pointer und P2/R0 als der andere. Manche 8051 können diesen Trick auch auf dem internen XRAM, z.B. der C505 hat das XPAGE-Register als High-Adresse.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Braucht bei nur einem dptr viele Register, die der Compiler möglicherweise für anderes gut gebrauchen könnte. Und von der Hardware her ist ein zweiter dptr billig. Philipp
Wobei es mit der Compilerunterstützung für mehrere dptr wohl bisher noch nicht so gut aussieht: Weder SDCC noch Keil können Code, der die zusätzlichen dptr nutzt generieren. Philipp
Gast
#4632033
Philipp Klaus K. schrieb: > Weder SDCC noch Keil können Code, der die > zusätzlichen dptr nutzt generieren Habe hier einen älteren LPC935 und Keil zeigt unter Options: use multiple DPTR registers Aber durch den Umstieg auf EFM8 spielt das ohnehin keine Rolle mehr
Gast
#4632038
Das ist zumindest für den Keil Compiler so nicht richtig. Die C Bibliotheken benutzen auf Wunsch die multible DPTR. das ist seit V5 eingebaut. Das geht allerdings nur im PK51. Der Nutzen ist allerdings wie Peter schon gesagt hat zweifelhaft. Thomas
Lothar schrieb: > Philipp Klaus K. schrieb: >> Weder SDCC noch Keil können Code, der die >> zusätzlichen dptr nutzt generieren > > Habe hier einen älteren LPC935 und Keil zeigt unter Options: > > use multiple DPTR registers > > Aber durch den Umstieg auf EFM8 spielt das ohnehin keine Rolle mehr Aber das hat nur Einfluß auf die verwendeten Bibliotheken (also ein paar von Hand geschriebene Assemblerroutinen für memcpy(), memmove(), etc). Der aus C-Code generierte Assemblercode verwendet nur einen dptr. Philipp
Beim den Varianten mit 24-bit-Zeigern, DS390 und DS400 sieht es etwas besser aus: Zumindest SDCC erzeugt dort Code für die beiden dptr. Philipp
Soweit ich sehe, gibt es zur Zeit 3 weit verbreitete Ansätze für zwei dptr:
- 2 dptr, via DPS at 0x86.0, DPL1 at 0x84, DPH1 at 0x85 (erstmals beim AMD C521).
- 2 dptr, via DPS at 0xa2.0 (erstmals beim Philips P89C51R).
- 2 dptr, via EO at 0xd0 (erstmals beim Infineon XC866).
MDU/Cordic haben sich anscheinend nicht durchgesetzt. Während SiLabs bei einem dptr bleibt, verwenden anscheinend die meisten Hersteller von 8051-kompatiblen µC nun zwei dptr, und wählen dabei einen der drei oben genannten Ansätze.
MDU/Cordic haben sich anscheinend nicht durchgesetzt.
Die Versuche, den 8051 auf 16 Bit zu pimpen, sind ja auch alle im Sande verlaufen (Intel 80C251, Philips 51MX).
SDCC benutzt den DPTR zur Parameter Übergabe. Keil R0..R7. Das ist der Hauptgrund warum der Keil C Compiler die DPTR Register nicht anfasst. Dieser stehen somit komplett der Lib zur Verfügung. Der C-Compiler kennt aber die Verwendung des DPTR in den Libs. ($reguse) Meiner Meinung nach der Hauptgrund warum der SDCC nie so efektiven Code wie der Keil erzeugen kann.