Clay language

Walter Bright newshound2 at digitalmars.com
Mon Dec 27 13:14:40 PST 2010


bearophile wrote:
> This is something that I want for D too, it's important:
> 
>> Jonathan Shapiro (of BitC) makes an excellent argument that, in a systems
>> language, it is often undesirable to depend on the whims of an
>> ill-specified optimizer to convert abstract code into efficient machine
>> code. The BitC specification thus includes the idea of guaranteed
>> optimizations, to allow code to be written in a high-level style with
>> predictably low or nonexistent runtime cost (link). [...] Because Clay
>> seeks to support systems programming with high-level abstraction, certain
>> patterns should be guaranteed to be optimized in a certain way, instead of
>> being left to the whims of LLVM or a C compiler. 
 >> [...]
 >> It should be possible to specify
>> that one or more of these optimizations is required, and have the compiler
>> raise an error when they cannot be applied for some reason.<

Frankly, this is meaningless. For example, while C does not specify what 
optimizations will be done, in practice you'd be very hard pressed to find one 
that didn't do:

1. replacing a*4 with a<<2
2. doing decent register allocation, obviating the role of the "register" keyword
3. dead assignment elimination
4. named return value optimization
5. etc.


>> Additional optimizations should not be prevented, however.

I.e. the same situation as today.


More information about the Digitalmars-d mailing list