The meaning is not there are one wont remove the other. Some task would be better realized by the 8051 and some by the AVR. And this page want to make easier the decision which of both looks better to solve your task.
Both are fully pincompatible. this means, the AT89C2051 can be replaced by
the AT90S1200 and the AT89C51 or 52 by the AT90S8515.
The one exception is the polarity of the reset input. But this is not a problem.
Many reset circuits are available with both polarities or you remove the
reset circuit completely and use the internal power on reset (POR) of the
AVR.
Both are available as FLASH and so the software development is easy and cheap.
I must use in some applications Phillips EPROM-devices and then you need
10 ore more special high cost windowed device to reduce the erase time. Some
of my applications floated on 5000 volts. So I can't use a simulator.
There are some peripherals added:
- Both changing of the input level can generate an interrupt.
- There is added an EEPROM to store data over a power off time.
- An internal oscillator and an internal power on reset make the AVR
working without any other components.
- A watchdog to handle hanging software states is added. This is not usable
for electrical influence, since it must enabled after reset and can be
disabled.
For this task it must be enable by programming a fuse and not be disable.
The divider between XTAL and cycle time is reduced from 12 to one.
So the instruction time is many times faster than the 8051.
E.g. you can realise an I2C-interface fully in software without reduced
clock speed (at fully 100kHz).
The instruction set is completely different to the well known 8051. The AVR
is a RISC-architecture. And so you need in general more program memory than
for the 8051. This means, if you have an assembler source with near then
1500 byte on the 89C2051 you can't translate it in a 90S2313 (On both are
2kByte program memory available).
The instruction set related to the internal RAM and peripherals are very
strong reduced.
This means, if you need only 32 bytes RAM you can hold all in registers and
so you need a program space near the 8051. In case you need more you must
move some variables to register, but only move-instructions can execute from
RAM. The same case occurs if you want extensively use port pins.
One example: often you must invert an i/o-pin (generate a clock, flashing
a LED, sounding a speaker). There are 2 bytes need on 8051 but 8 on the AVR
(12 if you must remove influence of interrupts).
Conclusion: You need in general more program space.
Only one interrupt priority is available. More need additional instructions to rebuild it in software. But you need often 2 priorities: 1 high for short timer interrupts or serial receive, 1 slow for all others.
There is not a practical use of the very small amount of instructions without
influence to the status register on interrupts. But the status register is
not saved on interrupts. So you need 8 additional bytes to save and restore
it on every interrupt (first load it in a register (in-instruction) then
push this register if use nested interrupts and reverse execution of it on
leaving the interrupt = 4 instructions = 8 byte ).
On 8051 the instructions INC, DJNZ, JB, JBC, SETB, ANL, ORL, ... can make
many interrupts executable without saving the status register.
Only 3 pointers are available (X, Y, Z). The 8051 allowed up to 9 data pointers
(DPTR and R0 or R1 on every of 4 register sets) and 2 for look-up-tables
(DPTR or PC versus one in the AVR).
E.g. if you want to receive and transmit data on the UART-interrupt and
copy data in the main program at the same time there are 4 pointers needed).
The internal UART prescaler is dramatically reduced (2^8), so only baud rates
of 9600 or higher can realized (at 20MHz, 4800Baud only at 19.7MHz or lower).
The 8051 has a 2^17prescaler which can be expand by software on very low
baud rates. The upper limit of the 8051: 24MHz / 12 / 16 = 125kbaud is high
enough, I think.
In cases of variable baud rate you need both: software for slow and using
the hardware UART for high baud rates. This doubles unfortunately your
needed software space and testing time.
The timer prescaler is not resetable or readable. So if you must use it,
you can't detect is it advantaged or not, if the interrupt is executed. In
some cases you can't build a really XTAL counting timer (you get the timer
value, add, the desired shorting value and write it back. But you know not
wether or not the prescaler has advataged during these instructions and so
you can lost a full prescaler period). The only way: use not the prescaler
and build the timer only by software cascading (causes a high count interrupt
usage).
The 8051 has 2 powerful instructions to exchange data with interrupts without disabling (JBC for bit and XCH for byte). The AVR need general to disable the interrupt.
There is no division or multiplication for easy ASCII to binary conversation and vice versa available today (hardware multiplication is planed but software division is many more time consuming).
The AVR is optimized for C-programming.
E.g. the bank switching on the 8051 for high speed interrupt tasks
is not right usable on most 8051-C-compilers.
General the optimization of C-code on 8051 is tough.
So you can get on some compilers a lower needed program space on the AVR
in comparison to the 8051.
In assembler be valid: CISC is smaller then RISC.
There are a lot of points to use the 8051 in future too.
And there are also some points to look at the new AVR.
The higher needed program space and instruction count of the AVR is faced
by the very lower XTAL count on every instruction. I think you need about
20% to 50% more program space and get up to 5 - 10 times higher execution
speed, except the not available DIV and MUL instruction.
The interrupt handling on the 8051 is more powerful (2 priorities, bank
switching, XCH-instruction) as on the AVR.
Most of the disadvantages of the AVR can be correct by additional software.
So it is suggest that the program space of the AVR is doubled or even higher
designed in future to compensate the today disadvantages (especially with
respect to C-programming).