From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by sourceware.org (Postfix) with ESMTPS id BBE6F386FC19 for ; Fri, 18 Jun 2021 14:12:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BBE6F386FC19 Received: by mail-pj1-x1031.google.com with SMTP id pf4-20020a17090b1d84b029016f6699c3f2so829000pjb.0 for ; Fri, 18 Jun 2021 07:12:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+MhWZrx1nH3pFNwPJwZfBQ9d8QenihAuBUh5VgwoAFo=; b=mM1OPXlhk5pOTNyXxeAkhLF3gqk0sCUkmYw/xmeXltxVodJdJN+pk+OQzCbHGbGbs3 RHxVn/oT6E5WOCXFmagriUnLAU16rbmaC1uqWU66URlcm6qHHkAURCE3jgJBykBi1aRQ KbIBuEDifE24KwxxFggXt7K8lpFIjL5vZnQCJ+cG4M+ZkIIv5QR3jC7x6305V0H+dKSL zFzdpEOBRHVjKUt/s5+ROg5K5kV4IYGA7xYbHW0Ny+LDpuuJOp6jvUsNlWpFVKL1bLNu 5DNLbNYeltTrE5x4LYXfSjIo63nZmrZtoagRxWwAN5mwkU2DlHbmQ8INJrW0czxiFeHZ 1Cig== X-Gm-Message-State: AOAM5332wg/qgPN6YAyn8/efVAgCZSO6/hPkioeYvqaFRaTd3JUyX1TZ EK8JgouJCe8XoLha32nBQWKFcy6skfTE25N0R6g= X-Google-Smtp-Source: ABdhPJz4jDDjDfDaLqveiT6GpzwPrfckoKbo+1TnpI6lyC4kj63iYEwDUK7XGylAFEGQLHoiOVlLTDyH6pVPufAtyUI= X-Received: by 2002:a17:902:b095:b029:118:cfad:c536 with SMTP id p21-20020a170902b095b0290118cfadc536mr4848540plr.79.1624025566906; Fri, 18 Jun 2021 07:12:46 -0700 (PDT) MIME-Version: 1.0 References: <0babbec4-06ae-f980-18a9-20608046891b@suse.com> <34a3a825-8c9f-d52b-9a1d-6cd45e051332@suse.com> <803f03a4-bb6d-5580-b2ff-b1df2d5152f3@suse.com> In-Reply-To: From: "H.J. Lu" Date: Fri, 18 Jun 2021 07:12:11 -0700 Message-ID: Subject: Re: [PATCH 3/6] x86: harmonize disp with imm handling To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3025.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 14:12:49 -0000 On Fri, Jun 18, 2021 at 2:03 AM Jan Beulich wrote: > > On 17.06.2021 18:12, H.J. Lu wrote: > > On Thu, Jun 17, 2021 at 9:05 AM Jan Beulich wrote: > >> > >> On 17.06.2021 18:00, H.J. Lu wrote: > >>> On Thu, Jun 17, 2021 at 7:57 AM Jan Beulich wrote: > >>>> > >>>> On 17.06.2021 16:46, H.J. Lu wrote: > >>>>> On Mon, Jun 14, 2021 at 3:25 AM Jan Beulich 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. DISP treatment should stay as is. -- H.J.