Re: OR_AND semantics (was: GNU property saga)

[Cary Coutant <ccoutant at gmail dot com>]

> > Was there ever consensus on the OR_AND thingy?  It strikes me as not
> > really implementing what is wanted, especially in relation to future
> > extensibility (I'll write a mail about this).
> ...
> So, it's clear that the individual bits of the uint32 are independend of
> each other and hence can represent separate features/properties.  This
> means that the phrase "and this property is present in all relocatable
> input files" in not well defined: example situation:
>
> * producer A knows about bits 4 and 5 of FEATURE_X (assumed to be in the
>   OR_AND range), it will set the FEATURE_X property in a.o (and bit 4
>   and 5 therein to whatever is correct/requested)
> * producer B is older and happens to know only bit 4 of FEATURE_X, so it
>   will set FEATURE_X in b.o, and bit 4 to whatever value is correct, but
>   bit 5 will be zero.
>
> 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).

I'm guessing that HJ is operating under the premise that if the older
producer B was unaware of bit 5 of FEATURE_X, then the object must
not, in fact, use that feature. His design is all-or-nothing: If the
FEATURE_X property is there, then we have accurate yes/no information
for each feature described by that property. That would work if he's
careful to move a new feature to a completely new FEATURE_Y property
whenever it's possible that an older consumer might have used that
feature before the means of recording it was defined.

Jim and I each suggested an improvement where each feature is
described by two bits: one bit from FEATURE_X_KNOWN and a
corresponding bit from FEATURE_X_USED*. The bits in FEATURE_X_KNOWN
would be ANDed, while the bits in FEATURE_X_USED would be ORed. This
would give us the following four cases:

(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.

Using the OR_AND scheme, case (a) is represented by a missing
property, and case (b) is folded into (a): If not all objects provide
the property, we discard the property, and all features revert to case
(a).

The OR_AND scheme would be equivalent to an OR scheme where missing
properties are treated as all ones -- in that case, we'd end up with
all ones rather than a missing property. For each feature, 0 means we
know the feature is not used, while 1 means we aren't necessarily
sure.

Alternatively, it would be equivalent to an AND scheme where the
meaning of each feature is inverted and missing properties are treated
as all zeroes: 1 means the feature is NOT used, and any object with a
missing property would result in all zeroes. For each feature, 1 means
we know the feature is NOT used, while 0 means we aren't necessarily
sure.

I was trying to understand why HJ didn't care about case (b) -- if a
feature is used by at least one object, what difference does it make
whether we have some objects that didn't say whether they used the
feature? I believe his answer is that the use case for these
properties is to allow the OS to decide whether it can allocate a
program to a downgraded processor, based on whether we know for sure
that the program does *not* use a particular feature. Thus, case (c)
is the important one where the downgrade is feasible, and all other
cases mean that it is not (either because we know the feature is used,
or because we do not know it's not used).

But it seems to me that there's an equally useful purpose for these
properties, if we can distinguish between cases (a) and (b). If we
want to allow the OS to refuse to execute a program that it knows
requires unsupported features, case (b) tells us that we do know the
program uses the feature, and the OS could provide a graceful error
message in that case, as it could for case (d). In case (a), we still
wouldn't know for sure whether the program will run successfully, but
we're no worse off than today.

-cary


* I originally wrote in terms of FEATURE_X_NEEDED, based on a
misstatement in an early email from HJ that led me to believe the
psABI had USED and NEEDED reversed. This scheme works for both USED
and NEEDED, and it's even feasible to use one set of KNOWN bits that
pairs with both a set of USED bits and a set of NEEDED bits.


>
> So there's still the confusion between absense and zero-is-unknown and
> zero-is-known, which the OR_AND range was designed to make clear (at least
> as far as I understood it from various mails trying to explain situations
> in which it would help).
>
> So, either I misunderstood the reason of existence for OR_AND, or there's
> some unspelled assumption in the usage of OR_AND (e.g. that there must
> never be producers knowing a different set of bits per FEATURE_xxx uint32
> set), or the language above doesn't capture the intent.
>
> What is it?
>
>
> Ciao,
> Michael.
>
> --
> You received this message because you are subscribed to the Google Groups "X86-64 System V Application Binary Interface" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to x86-64-abi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.