32-bit archs, want64=true, and gas integers

[Jan Beulich]

On 06.05.2022 12:01, Pedro Alves wrote:
> On 2022-05-06 10:55, Jan Beulich wrote:
>> On 06.05.2022 11:00, Pedro Alves wrote:
>>> Looking at the "Numbers" chapter in the manual:
>>>
>>>  https://sourceware.org/binutils/docs/as/Numbers.html
>>>
>>> we have:
>>>
>>>  "Integers are numbers that would fit into an int in the C language. Bignums are integers, but they are stored in more than 32 bits."
>>>
>>> I note it says "more than 32 bits", not "32 bits or more".
>>>
>>> By my reading of the "Integers" and "Bignums" subsections, these integers are always signed.  Maybe
>>> that should be explicitly said in the manual, instead of introducing signed vs unsigned numbers?
>>>
>>> And then, couldn't we make gas use int32_t for integers, and int64_t for Bignums (and clarify in the manual
>>> that "more than 32 bits" is exactly "64 bits"?  IOW, use int64_t instead of bfd_vma in the
>>> expression evaluation stuff.  
>>
>> Bignums are quite a bit wider than 64 bits, and on 64-bit architectures
>> using just int32_t for integers is definitely insufficient (there are
>> pretty limited operations one can do on bignums). I'm afraid the doc is
>> simply outdated in talking about "int in C language"; it's more like
>> "long", and even then only in Unix-like environments, so it would likely
>> be even better to talk about {,u}intptr_t.
> 
> But why {,u}intptr_t?

Because it's used for address calculations.

>  Why does it have to be the size of a pointer, which 
> raises the question of -- which pointer, host or target?

Target.

>  And if you support
> multiple targets, which target?

That of the biggest target. But that's no an issue in e.g. gas (and
hence with expression evaluation), which only supports a single target
(but perhaps multiple sub-targets) at a time. Sub-targets with more
narrow address size indeed aren't always properly handled.

> Couldn't gas always use int64_t for integers instead?

This might be possible. Once a 128-bit arch appears it'll end up
outdated again, though.

Jan