If you read my previous article on DOS memory models, you may have dismissed everything I wrote as “legacy cruft from the 1990s that nobody cares about any longer”. It's time to see how any of that carried over through the 16-bit to 64-bit evolution.
As you note, it's important to distinguish between code size and data size. In 2003 I posted an article to comp.arch (now contained in https://jlforrest.wordpress.com/2017/03/06/the-forrest-conjecture/) that attempts to point out that even 32 bits is plenty now for code, while something larger than 32 bits is required for data. It wouldn't make sense to have a processor with different data and code sizes, so today's 64 bit code and data processors are a very good workaround.
As I mention in my paper, it's hard to imagine how long this will remain true, as long as programs are written by humans. I have no idea how long it will take for programs to be written by some kind of AI, and what the necessary processor model will have to be then.
As you note, it's important to distinguish between code size and data size. In 2003 I posted an article to comp.arch (now contained in https://jlforrest.wordpress.com/2017/03/06/the-forrest-conjecture/) that attempts to point out that even 32 bits is plenty now for code, while something larger than 32 bits is required for data. It wouldn't make sense to have a processor with different data and code sizes, so today's 64 bit code and data processors are a very good workaround.
As I mention in my paper, it's hard to imagine how long this will remain true, as long as programs are written by humans. I have no idea how long it will take for programs to be written by some kind of AI, and what the necessary processor model will have to be then.