Has there been any new studies about constant data sizes?
A Microprocessor for the Revolution: The 6809; Terry Ritter & Joel Boney (co-designers of 6809); BYTE magazine; Jan-Feb 1979.
Gives indexing off X for the 6800 as 0 40% 1-31 50% 32-63 1% 64-255 6%.
Since this is a 8 bit cpu, I would scale the sizes x4 for 32 bit data.
For the cpu's I have been designing, I use B00.. to B10.. for + numbers and B11... for - numbers in constants.
Ben.

Hi Ben
I'm not sure what you're asking, but it didn't look like it related to the thread you posted in ("74xx based CPU (yet another)"), so I've made your post a new thread. Please feel free to edit the subject line - I've guessed.

What I am thinking is the constants for typical programs.
How large typical structure or variable name offsets or local variables?
struct ... char name[16],short inode of the 1970's could be
struct ... char path[1024],long long inode of 2020's.

Having a idea the ranges could improve code density. Risc came out just as
the world was moving from 16 bit to 32 bit unix, and away from the 8086.
Having large segments now seemed the way to go. But is larger better?
Algol promoted local variables and data, keeping the idea of local varables.
Fortran promoted global variables every where, like common varables.
RISC tried to keep all varables in registers and hope array access was rare.

What are the real size of programs data segement. Are programs slowed down
by huge data areas like screen buffers or floating point random access of arrays?

One needs to match the hardware to the data used.
But with out knowing how todays programs address data or arrange data, one has no clue
how build better ways to access dynamic memory, or give a clue of how fast we can go.

Ben.

I read recently that ARM's 64 bit instruction set does support larger embedded offsets and constants. I think the hope is that when inline data is sufficient, you save a clock cycle or two, or a cache entry, or give the databus something better to do. In other words, it's a performance win. Whenever the embedded offsets and constants are too big to be inline, there has to be a fetch from memory - in other words, nothing is impossible, it just costs a little performance and a little complexity in the tools.

I've certainly heard the idea that ARM's changes to create their 64 bit instruction set are a big bundle of complexity and detail - it's an even less simple machine to understand and program than the original, and there's a case to be made that the original ARM is not as simple as one might have expected from the RISC label. (But ARM was built at a particular time with a particular technology, and arguably makes reasonable tradeoffs for its implementation. It was never minimal, it was reduced.)