Yes, I said it. But you failed to pick up on it.

The 8086/8088 is a 16-bit processor. It is not a 8-bit processor with a hard time to just about produce a 16-bit address. It has full 16-bit adressing with base pointer, index and offset at the same time.

An 8051 isn't even close. While it may be able to walk through a 16-bit address space, it has to bend its back until it cracks to compute real 16-bit effective addresses.

What I said was that the "slightly" corny way to go from 16 to 20 bits in the 8088 was complained about a lot. And in this case we are instead talking about a processor that don't even have instructins to perform even 16-bit address calculations.

External data? I never talked about external data. It does not matter if you have the RAM externally or internally. The problem is that the 8051 architecture - while having lived quite well for many years - are not suited for addressing large amounts of data. It is a question of instruction set, not electrical connections.

If the RAM is not intended to store "variables", then the RAM is probably the wrong memory architecture in the first place. If storing configuration data or a logg or similar, then EEPROM, FRAM or similar is probably way better suited. The big thing with RAM as memory architecture is an almost constant-time (depending on processor architecture etc) access to any address and no wear for read or write. A serial EEPROM works perfectly for implementing a "database" on a 8051 or similar and will at the same time keep the data after a reboot or power loss. It works so well that a competent developer would most probably not ask what type of controller that has most amount of RAM in such a case.


Yes, but very seldom reasons for attaching big storage in the form of RAM to a 8051 processor.

Remember that it was you who claimed that it is trivial to access large memory on the 8051 (despite loosing the compiler support for it) and basically classified the original PC as an 8-bitter.