Integer arithmetic in hardware descriptions

[bearophileHUGS at lycos.com]

John Nagle:
>I gave up on this when C came in; the C crowd was so casual about integer overflow that nobody cared about this level of correctness. Today, of course, "buffer overflows" are a way of life.<

Experience shows that integer overflows are a very common bug. One of
the huge advantages of Python is that it frees the programmer to keep
a constant eye on the size of the numbers (so multi-precision numbers
aren't just for cryptography as I often hear people say, they are
wrong). This helps me avoid a class of bugs and program faster and in
a more relaxed way.

Some C# designers come from Pascal (where overflow is considered an
important thing), and they have added to dotnet ways to find when an
overflow occurs, globally in a program, locally in a piece of code, or
even in a single part of an expression. This is much better than
nothing.

Languages like Lisp (and some other, like some modern forths, etc)
avoid most of the trouble with tagged integers, they are a bit slower
but have the advantages of letting you forget the finite nature of
integers (and in Lisp you can often ask for a fixnum where you need
max performance anyway).

Later some people has even seen that a sufficiently smart compiler can
even remove part of the controls to find the overflows (for example
where you use a variable that you can infer will never overflow).

I'm fighting against the C/C++ crowd to add C#-like integer overflows
to the D2 language, but with not much luck so far, all they (Walter,
mostly) see is the "lower performance" it may lead.

Bye,
bearophile