sizes

[muta...@gmail.com]

I vaguely recall someone saying that
old thinking, from 70s or 60s I think,
was that data registers and address
registers would all be the same size.

Or something like that.

With the exception of the circumstance
where segmentation is required, it's
true, isn't it? Everything is or can be
the same size, simplifying things.

The subc author said that subc is a sane
subset of c.

Maybe he is close to being right?

He only supports int and I defined short
and long to be int.

[Joe Monk]

On Friday, November 25, 2022 at 7:44:46 PM UTC-6, muta...@gmail.com wrote:
> I vaguely recall someone saying that
> old thinking, from 70s or 60s I think,
> was that data registers and address
> registers would all be the same size.
>

Thats why they're called general purpose registers instead of address or data registers.

But note that floating point registers are 128-bit on z/Arch.

Joe

[Alexei A. Frounze]

On Friday, November 25, 2022 at 5:44:46 PM UTC-8, muta...@gmail.com wrote:
> I vaguely recall someone saying that
> old thinking, from 70s or 60s I think,
> was that data registers and address
> registers would all be the same size.
>
> Or something like that.
>
> With the exception of the circumstance
> where segmentation is required, it's
> true, isn't it? Everything is or can be
> the same size, simplifying things.

...

Things get simplified in the compiler when the CPU
registers are uniform.
But it's not necessarily segmentation.
Just separating code from data and supporting
different sizes of the two spaces asks for differently
sized pointers, one of the two of which is inevitably
going to differ from the data register size.
On top of that, the data registers may be sized
for specific tasks. For example, if I remember it correctly,
TI's TMS320C54xx has 2 40-bit accumulators, a bunch of
16-bit data address registers (which support some ALU
operations as well, not just memory addressing) and a
segmented program counter (16+16 bits). Oh, and the byte/char,
short and int are all 16-bit.
40-bit accumulators let one multiply-accumulate 256 or 512
pairs of 16-bit integers (to perform the basic DSP operation of
signal filtering/convolution).
You don't need to use all 40 bits all the time, you can just
use the 16-bit or 32-bit parts of each accumulator.
Just an example of a contemporary non-uniform arch.

Alex

[muta...@gmail.com]

On Sunday, November 27, 2022 at 3:23:58 PM UTC+8, Alexei A. Frounze wrote:

> Just an example of a contemporary non-uniform arch.

So would you say that people erroneously thought the
address registers and data registers would all be
uniform, but they were wrong, there were reasons to
make them different, but now we're back to the
original being right - generally things are uniform
these days?

And thus the conclusion would be that we may as well
have a simplified set of tools assuming uniformity,
and it is only if someone has something non-standard
that they will need to go to the effort of accommodating
that?

Basically this ties into standardizing on a.out. I've seen
the internals of that and see no reason why we can't
let that naturally expand with theoretical future
technology that has consistent data and address
sizes.

BFN. Paul.