Date: Wed, 9 Oct 2013 23:21:20 -0700
On 8/26/13, Chandler Carruth <chandlerc_at_[hidden]> wrote:
> On Mon, Aug 26, 2013 at 9:27 AM, Gabriel Dos Reis <gdr_at_[hidden]>wrote:
>> Nevin Liber <nevin_at_[hidden]> writes:
>>> It comes from C. I believe it comes from the days of segmented
>>> architectures.
>
> The interesting thing is that it remains possible (and unsurprisingly
> possible) to implement a total ordering for all addresses. It just means
> that this ordering may be marginally more complex than a single integer
> comparison on some architectures. I think this is a fine requirement to
> place on them. In all cases where the segment is known to be the same
> (the overwhelming majority), any reasonable implementation will produce
> the same code as today.
The total ordering can be significantly more complex than today whenever
two segments can refer to the same memory. In general, it may require
an OS query to the virtual table to provide the ordering, which is likely to
be way more expensive than anyone would like.
> On Mon, Aug 26, 2013 at 9:27 AM, Gabriel Dos Reis <gdr_at_[hidden]>wrote:
>> Nevin Liber <nevin_at_[hidden]> writes:
>>> It comes from C. I believe it comes from the days of segmented
>>> architectures.
>
> The interesting thing is that it remains possible (and unsurprisingly
> possible) to implement a total ordering for all addresses. It just means
> that this ordering may be marginally more complex than a single integer
> comparison on some architectures. I think this is a fine requirement to
> place on them. In all cases where the segment is known to be the same
> (the overwhelming majority), any reasonable implementation will produce
> the same code as today.
The total ordering can be significantly more complex than today whenever
two segments can refer to the same memory. In general, it may require
an OS query to the virtual table to provide the ordering, which is likely to
be way more expensive than anyone would like.
-- Lawrence Crowl
Received on 2013-10-10 08:21:22