Erste 8051-Derivate mit mehreren dptr

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

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.

Der AD8051 / AD8052 ist ganz ohne dptr ...


:-)

Gruß

Jobst

1

__xdata long int *i, *j;

2

3

void f(void)

4

{

5

…

6

  *i += *j;

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

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.

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

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.