Re: Optimization techniques and runtime checks

On 29/04/2019 22:36, Hans-Peter Diettrich wrote:
> Am 28.04.2019 um 23:49 schrieb David Brown:
>> On 26/04/2019 02:18, Kaz Kylheku wrote:
>
>> Instead of the compiler generated faster code for valid use,
>> and debug tools being able to spot your error, you have slower code with
>> a guaranteed error and no way for tools to help you.
>
> The Delphi compiler can do both, create fast or checked code, from the
> same source. Automated checks for simple errors like overflows and range
> errors can be turned on or off, and range errors can be checked for
> strings and all array types. It's a matter of data types that allow for
> such automated checks. Data types also allow to perform many checks at
> compile time, which can be made in other languages only at runtime and
> possibly only if the user adds the checker code.
>


Yes. I haven't used Delphi for a fair number of years, but that has
been a feature of Borland's compilers since I first used Turbo Pascal.


gcc and clang have similar features for C. It is helpful to use such
run-time checks during testing and debugging, and to be able to omit
unnecessary inefficiencies when speed or size is more important.


>
>> My preference is to write code in a clear and sensible manner, and have
>> the compiler generate as efficient object code as it can from that
>> source.
>
> I construct my Delphi data types in a way that the compiler can create
> the most possible checks, in case they are required later.
>
>
>> Assembly is intended to be a low-level language.  Some assemblers do a
>> little bit of optimisation, but mostly it is a language designed to give
>> the programmer precise control - and full responsibility - over their
>> code.  C is a high level language - it is not an assembler.  It is
>> defined in terms of its semantics, not the implementation.
>
> To me C looks like a macro assembler, with only a few weak types and rules.
>


C does not have the range of type creation facilities that Pascal (and
Object Pascal) has. C++ provides a good deal more, but still lacks
several of Pascal's capabilities here.


>
>>> In the C language, the translated units of a program that are to be
>>> linked to form the program have undergone semantic analysis.
>>>
>>> So no further optimization is permissible; it constitutes semantic
>>> analysis.  Translation unit boundaries should be regarded as inviolable
>>> optimization barriers.
>>>
>>
>> Nonsense.  There is no basis for that at all - excluding unwarranted
>> assumptions by many programmers.
>
> A better compiler could have a look at multiple (dependent) modules, so
> that it can apply some more global optimizations during compilation
> already.


Indeed. And better compilers do that - it is known as "link time
optimisation", "whole program optimisation", "omniscient optimisation",
"inter-module optimisation", etc.


>
>
>>> Well-defined conditions can be wrong in the given program.
>>> E.g. "I'd like to trap when a value greater than 42 is written into the
>>> variable x, even though it's well-defined to do so."
>
> Again that's a matter of data types, where Delphi allows for integral
> subrange types with defined upper and lower bounds. This allows for
> compile time tests with known values, and for runtime tests otherwise.
>


Yes - Pascal has these, C does not. (And if you want them in C++, you
need to make them.)


>
>> This is exactly the same as mathematics.  The "square root" function,
>> for real numbers, is defined for non-negative numbers.  If someone asks
>> you for "sqrt(-4)", then the question is meaningless.  Any answer given
>> can be considered incorrect - equally, any answer given can be
>> considered correct.
>
> That's a cheap excuse for poor language design, aimed at sloppy compiler
> implementation.
>


You are saying that mathematics is a poor language design?


>
>> Incorrect inputs to code are as wrong as incorrect code.  In C, the
>> behaviour of signed integer addition is defined for all inputs that
>> don't overflow - giving it inputs that /do/ overflow is as wrong as
>> writing multiplication when you meant addition, or passing a negative
>> number to a square root function.
>
> For such cases many languages have assertions or can raise exceptions,
> which can be handled by the user as appropriate (SEH).
>


Many languages have that, and it can be a very useful feature for many
kinds of program. Other languages don't have it (as an automatic
feature), because such features are not free.


>
> To me the C and most C-ish languages are poorly designed and not a good
> base for discussing valid optimization techniques. Bart said essentially
> the same without a Delphi reference. That's why I did not contribute to
> that C language specific optimization, but added my $0.02 on how
> thoughtful language design can allow for better optimizations.
>


Different languages have different purposes and trade-offs. This is
important to accept when discussing them.


C is useful to /me/, for the programming /I/ do. It is useful for quite
a lot of other programming. But it is only useful if you understand the
language - if people insist on pretending it is something that it is
not, they will have trouble. If you want run-time checks on buffer
accesses, signed integer arithmetic, etc., that's fine - find a language
that suits your needs, or at least is the best compromise of your needs.


Every language has its oddities, and there are always things that some
people thing are terrible design. For example, it is truly weird that
"const x : int = 10;" is one of Delphi's way of making "x" a variable
with an initialised value. (In older Delphi, it was the only way!)

Return to the comp.compilers page.
Search the comp.compilers archives again.