Re: [PATCH 3/6] x86: harmonize disp with imm handling

[Jan Beulich <jbeulich@suse.com>]

On 18.06.2021 16:12, H.J. Lu wrote:
> On Fri, Jun 18, 2021 at 2:03 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 17.06.2021 18:12, H.J. Lu wrote:
>>> On Thu, Jun 17, 2021 at 9:05 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 17.06.2021 18:00, H.J. Lu wrote:
>>>>> On Thu, Jun 17, 2021 at 7:57 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 17.06.2021 16:46, H.J. Lu wrote:
>>>>>>> On Mon, Jun 14, 2021 at 3:25 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/gas/testsuite/gas/i386/disp-imm-32.s
>>>>>>>> @@ -0,0 +1,17 @@
>>>>>>>> +       .text
>>>>>>>> +disp_imm:
>>>>>>>> +       mov     -0xffffffff(%eax), %eax
>>>>>>>
>>>>>>> I don't think we should treat  -0xffffffff(%eax) as 1(%eax).
>>>>>>> We allow addresses to wraparound. I don't see a need for
>>>>>>> displacements to wraparound.
>>>>>>
>>>>>> This then is entirely unexpected to the programmer. In fact the
>>>>>> same (abstracted away behind some defines or equates) constant
>>>>>> could be used for both purposes (and should be usable both ways,
>>>>>> imo).
>>>>>
>>>>> Since hardware wraparound on DISP + BASE + INDEX * SCALE, not
>>>>> on DISP, it is wrong to change DISP + BASE + INDEX * SCALE to
>>>>> wraparound (DISP) + BASE + INDEX * SCALE.
>>>>
>>>> But this is true regardless of how small (or big) the displacement.
>>>> Without knowing the register values, you can't know at what
>>>> displacement values wraparound occurs. Also, unless I'm mistaken,
>>>> wrapround(a + b) == wrapround(wrapround(a) + wrapround(b)).
>>>
>>> Hardware does wraparound (DISP + BASE + INDEX * SCALE).
>>> Assembler and linker should only wraparound on the final address.
>>
>> I'm afraid this last sentence makes no sense to me: The assembler
>> (or linker) can't know the final address. Instead, both immediates
>> and displacements should allow for anything the programmer might
>> sensibly use. If 0xffffffff as a displacement is fine (meaning
>> -1 really), -0xffffffff (meaning 1) ought to be, too. Or else
>> where do you draw the boundary of which displacements are
>> "legitimate" and which are not?
> 
> If the program wants 1, use 1.

You realize that for the purpose of the test case the -0xffffffff is
an over-simplification of what might appear in "real" code, don't
you? It also feels as if you didn't really read my earlier remark:

"In fact the same (abstracted away behind some defines or equates)
 constant could be used for both purposes (and should be usable
 both ways, imo)."

If what you say were true for disp, why would it not also apply to
imm? In the end, an imm loaded into a register may very well be
used to access memory, i.e. possibly fulfills the purpose of a disp.
We shouldn't force people to write quirky code just because gas
accepts certain things for imm which it doesn't accept for disp.

Jan