Re: Optimization techniques and runtime checks

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.




> 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.




>> 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.




>> 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.




> 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.




> 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).




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.


DoDi

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