svn commit: r317809 - head/share/man/man7

[Bruce Evans]

On Fri, 5 May 2017, Konstantin Belousov wrote:

> On Fri, May 05, 2017 at 11:39:23PM +1000, Bruce Evans wrote:
>> On Fri, 5 May 2017, Konstantin Belousov wrote:
>>
>>> On Fri, May 05, 2017 at 07:13:04PM +1000, Bruce Evans wrote:
>>> AFAIU, cheri is somewhat like Intel MPX, but more.  I do not know fine
>>> details.
>>>
>>> For MPX, pointers are no longer plain pointers, there is a data behind
>>> the raw value, providing e.g. the range of bytes which are valid to
>>> dereference through the authentic value of the pointer and arithmetic
>>> manipulations of it.
>>
>> So the address space isn't exactly flat.  Better de-emphasize that.
> It is still flat.  Example of not flat AS would be type-tagged or
> segmented machines.  MPX does not change address representation.

Elsewhere, arch.7 says that on some arches the kernel uses a separate
address space.  So the address space isn't flat for another reasons.
It is only sure to be flat (in FreeBSD) when doing local things.

arch.7 doesn't say whether it is for kernel or user programming.  It
gives a few details that are only relevant for user programming (floating
point), but is mostly about details that userland should never use
and rarely does.  Only the kernel and libraries have to worry about
exact sizes for the purpose of preserving ABIs.

>> I believe ia64 has fat function pointers, and uses handles so that some
>> things appear to work normally.  But comparison of function pointer
>> (handle) addresses is almost meaningless.  It isn't clear how gprof
>> can work.  It would needs something like mapping function addresses
>> to handled addresses linearly.  Similarly for conversion to uintptr_t.
> Both ia64 and powerpc64 use function descriptors, and function pointers
> point to the descriptors.  Function pointers are not fat, but require
> a level of indirection to find the call target instructions address.

I was being fuzzy to call handles fat pointers.  It is an implementation
detail whether the fatness is indirect.  When it is indirect, converting
to/from intptr_t isn't special but following the pointer is.

>>> So the phrase is correct, and the below reformulation really removes the
>>> content.
>>
>> "integrity" isn't correct since it has nothing to do with integers.
>> "mechanisms" doesn't make much sens either.  Use the standard term
>> "representation".
>>
>>>> Translation of the above: "... compatibility with changes in the size of
>>>> pointers in future implementations".
>>
>> Change "size" to "representation" if you want to allow for more than the
>> size changing.
> I suggest you to negotiate a formulation with brooks@, who provided the
> existing note.

See another reply.

>>>>> +Compilers define
>>>>> +.Dv _LP64
>>>>> +symbol when compiling for an
>>>>> +.Dv LP64
>>>>> +ABI.
>>>>
>>>> Further minor grammar problems here and elsewhere:
>>>> - missing "the" before _LP64
>>>> - "an" is confusing.  First, "a" might be correct depending on how you
>>>>    pronounce LP64.  I pronounce it as "el ...", so "an" is better than
>>>>    "a".  But there is only 1 LP64, so "the" is more correct.  "the LP64
>>>>    ABI" is confusing too.  LP64 isn't an ABI or a collection of ABIs.
>>>>    The collection is of arches, many using a single LP64 sub-ABI with
>>>>    variations in other parts of their ABI.
>>> Of course there are architectures which have more that one LP64 ABI,
>>> eg. PowerPC ELF v1 and v2.
>>
>> No, there is only 1 LP64 by definition.  It is not really an ABI, and only
>> gives the sizes.
> No, LP64 is the property of an ABI.

That is what I was trying to say.  There is 1 LP64 property, and it isn't
an ABI.

> So if several ABIs have this property,
> it is reasonable to say that there is more than one LP64 ABI.

This is hard to parse.  The reader must realize that "LP64" is an adjective,
which selects a class of ABIs, and that "an" applies to this class and not
to LP64.

>> _ALIGNBYTES only gives the smallest alignment that works for all types
>> (not even that for SSE accesses on x86).  It is pessimal for doubles
>> and long doubles on i386, and not best for int64_t either.  Does the
>> Linux ABI "fix" this?  The natural ABI is not easy to see.
> I do not quite understand the question.
> What is Linux ABI ?

You said that Linux changed the i386 ABI to require 16-byte stack
alignment.  This is unimportant and probably a pessimization.  If
it changed that, then it should have changed the alignment where
it actually matters -- for doubles, long doubles and possibly
int64_t.

> diff --git a/share/man/man7/arch.7 b/share/man/man7/arch.7
> index 2add6ea3d3e..dfc3527e01c 100644
> --- a/share/man/man7/arch.7
> +++ b/share/man/man7/arch.7
> @@ -38,15 +38,13 @@ Differences between CPU architectures and platforms supported by
> .Ss Introduction
> If not explicitly mentioned, sizes are in bytes.
> .Pp
> -FreeBSD uses flat address space for program execution, where
> -pointers have the same binary representation as
> -.Vt unsigned long
> -variables, and
> -.Vt uintptr_t
> +FreeBSD uses flat address space for program execution,
> +where variables of types
> +.Vt unsigned long ,
> +.Vt uintptr_t ,
> and
> .Vt size_t
> -types are synonyms for
> -.Vt unsigned long .
> +and the pointers all have the same representation.

Now some smaller grammar fixes:
- there should be an "a" before "flat"
- "for program execution" is redundant.
- the variable types are unrelated to the address space.  Don't use "where".
   Just start a new sentence.
- there should not be a "the" before "pointers"

> @@ -133,7 +131,7 @@ On all supported architectures:
> .El
> Integers are represented as two-complement.

- "as" should be "in"
- "two" should be "two's"
- the hyphen should be a space (old C99 and POSIX drafts use both, but
   Knuth uses a space).

Bruce