Erste 8051-Derivate mit mehreren dptr

[Philipp Klaus K. (pkk)]

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

[Philipp Klaus K. (pkk)]

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

[Dieter W. (dds5)]

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

[Lothar (Gast)]

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.

[Philipp Klaus K. (pkk)]

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

[Peter D. (peda)]

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.

[Jobst M. (jobstens-de)]

Der AD8051 / AD8052 ist ganz ohne dptr ...


:-)

Gruß

Jobst

[Philipp Klaus K. (pkk)]

__xdata long int *i, *j;

void f(void)
{
…
  *i += *j;
…
}

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

[Philipp Klaus K. (pkk)]

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

[Lothar (Gast)]

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

[Thomas (Gast)]

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

[Philipp Klaus K. (pkk)]

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

[Philipp Klaus K. (pkk)]

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

[Philipp Klaus K. (pkk)]

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.

[Peter D. (peda)]

Philipp Klaus K. schrieb:
> 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).

https://www.nxp.com/docs/en/user-guide/UM_P89C669.pdf

https://www.keil.com/dd/docs/datashts/intel/8xc251sx_um.pdf

[Thomas Z. (usbman)]

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.