From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44446 invoked by alias); 11 Mar 2019 07:34:48 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 44433 invoked by uid 89); 11 Mar 2019 07:34:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*r:sk:binutil, ISA, H*Ad:D*googlegroups.com X-HELO: mail-ot1-f43.google.com Received: from mail-ot1-f43.google.com (HELO mail-ot1-f43.google.com) (209.85.210.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 Mar 2019 07:34:46 +0000 Received: by mail-ot1-f43.google.com with SMTP id c18so3051106otl.13 for ; Mon, 11 Mar 2019 00:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XecJc9YXKcp6njSgrK1OVNo0Ndilc+RalWkFrKP5rME=; b=smErgFE+vJZd4ezomPhK87lyXGVawLGnR5tlmz+Xt+X8hH4D1FBbiNTuTGSTOW8UAe x3yYcO1dVTgxe9WnN/G/4sI5uyIw+8y0cPQ1a5WSggMa6hcrybHdsZPKF+vg+9XVsBGk ot9MZ7FsW80/B6sKAj0P2j515eoZsDWUgr5CBGm6pObkF7zL1dS9MPEkslIq8WyAK1oO 25Z9fQXzDNovBwg774Th/JrKgjC4JEdII0GpXWvF2++Ev+B6P7zNgt0l5ZBmeWKio52K 5IbVV67ZDS7Zte+fJ45CwdSvKOD4fZMDicsLyToQ3gpLn+omj5BIf/kaY1aZDIsm6bwh ihww== MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Mon, 11 Mar 2019 07:34:00 -0000 Message-ID: Subject: Re: OR_AND semantics (was: GNU property saga) To: Jim Dehnert Cc: Cary Coutant , Michael Matz , x86-64-abi , Binutils Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00063.txt.bz2 On Fri, Mar 8, 2019 at 2:25 PM Jim Dehnert wrote: > > > > On Thu, Mar 7, 2019 at 10:06 PM Cary Coutant wrote: >> >> > > Now the above language would include FEATURE_X in the output, but bit 4 >> > > would be reliable (set a.bit4 && b.bit4) while bit 5 would be unreliable >> > > (it is zero, even if it is one in a.o and _would_ be one in b.o had we >> > > used a newer producer). >> > >> > We can't add a bit to FEATURE_X in such a way that FEATURE_X generated >> > by older producers become invalid. We must add the bit to FEATURE_Y which is >> > unsupported to all prior producers. Am I missing something obvious? >> >> Yes, I think so. This is the point Michael (and I) were making. By >> using KNOWN bits, you can add new feature bits without having to start >> a whole new word of bits. So is this the only difference? We don't always need to add a new set of feature bits for a new feature if the new new feature will never be valid for older producers like a new ISA bit. But a new bit for the old ISA needs a new set of bits. This way, we only need to lookup one property for the feature X instead of 2. BTW, OR covers (b) in (a) KNOWN = 0, USED = 0: The feature is not known to be used, but not all objects provided a value. (b) KNOWN = 0, USED = 1: The feature is used by at least one object, but not all objects provided a value. (c) KNOWN = 1, USED = 0: The feature is not used in any object, and all objects provided a value. (d) KNOWN = 1, USED = 1: The feature is used by at least one object, and all objects provided a value. since there is no functional difference for the feature X in output object between 1. The feature is used by at least one object, but not all objects provided a value. 2. The feature is used by at least one object, and all objects provided a value. We only need to know if the feature X is used. We do need "all objects provided a value" info for USED == 0 case. > > You also don't need to assume that a producer that has implemented support for the tenth feature bit is also generating valid values for the previously-defined nine, just because the words containing them are present. > -- H.J.