ow Integers Should Work

bcs bcs at example.com
Tue Dec 6 20:11:54 PST 2011


On 12/05/2011 11:20 PM, Don wrote:
> On 06.12.2011 05:21, bcs wrote:
>> On 12/05/2011 08:37 AM, Don wrote:
>>> On 05.12.2011 14:31, bearophile wrote:
>>>> Found through Reddit, two blog posts about how integers should behave
>>>> in system languages (with hardware support):
>>>>
>>>> http://blog.regehr.org/archives/641
>>>> http://blog.regehr.org/archives/642
>>>>
>>>> Bye,
>>>> bearophile
>>>
>>> Not very convincing, since he proposes a change to existing
>>> architectures, and seems completely unaware of the overflow flag.
>>
>> I think he's looking at it form the language theory standpoint. As such,
>> architectures has nothing to do with it (the architectures to be
>> targeted has yet to be defined at that point)and getting access to the
>> overflow flag would require exposing it natively in the language.
>
> It's not that he hasn't specified an architecture. It's a proposal which
> does not work on _any_ existing architectures!
> It's pure fantasy.

Well you can do it on x86. The fact the it doesn't provied hardware 
traps is irrelevant. You might need to add a lot of branches but you can 
get the semantics he is asking for.

That said, there is another interesting (but independent) question of 
can it be done efficiently? You might have a very good question there, 
but that isn't the question regehr is considering.

>
> And he talks about NaN, when he means infinity. Floating point overflow
> never results in a NaN.

You have a point there.

> He doesn't seem to know anything about
> saturating integer arithmetic, which exists in hardware (even x86
> machines have supported a couple of operations since 1996).
>
> Useless.

Again, he's not interested in the hardware implementation, he's only 
interested in the defined semantics of the language, the things you can 
count on regardless of that instruction set you are using. The fact the 
x86 has saturating integer operations is moot because C doesn't have a 
type the end up using them.


More information about the Digitalmars-d mailing list