"Carlos Santander B." <carlos8294@msn.com> escribió en el mensaje
news:cfejqa$1g7i$1@digitaldaemon.com
| I have a copy of Salford FTN77 Compiler (4.03, Personal Edition. Used to be
| free, not anymore I think)

It's still free. And their FTN95 Personal Editional is also free. Just in case someone's interested...

-----------------------
Carlos Santander Bernal

In article <opsclc1kpg5a2sq9@digitalmars.com>, Regan Heath says...
>
>On Wed, 11 Aug 2004 16:19:13 +0300, Sampsa Lehtonen <snlehton@cc.hut.fi> wrote:
>> I understand that making the 'noalias' as a default for out and inout parameters sounds tempting, but because it is then impossible to quarantee  the correctness of the program, it shouldn't be done.
>
>Is it impossible? In a debug build couldn't the compiler insert checks to ensure the variables are not aliased?
>
>I understand that for pointers you cannot determine whether they are aliased or not, but D's arrays can be checked trivially, and pointers (so far) seem much less important in D than in C/C++.
>
>So perhaps 2 statements could be made:
>  - pointers are assumed to be aliased unless 'noalias' is used.
>  - other variables are assumed not to be aliased, unless 'alias' is used.
>
<snip>

Just curious..

If:
- D still aliases by default with pointers (and D uses ptrs. less anyhow)
- non-pointers are changed to noalias
- pointers could still be used to get the alias side-effects if desired
- and the debug runtime checks would presumably work like array bounds
checking..

Why would D need new keywords, compiler extensions, pragmas or compiler switches?

Thanks,

Dave

In article <cfek28$1gbg$1@digitaldaemon.com>, Carlos Santander B. says...
>
>"Carlos Santander B." <carlos8294@msn.com> escribió en el mensaje
>news:cfejqa$1g7i$1@digitaldaemon.com
>| I have a copy of Salford FTN77 Compiler (4.03, Personal Edition. Used to be
>| free, not anymore I think)
>
>It's still free. And their FTN95 Personal Editional is also free. Just in case someone's interested...
>

Might be! Thanks..

- Dave

>-----------------------
>Carlos Santander Bernal
>
>

On Wed, 11 Aug 2004 15:33:48 +0000 (UTC), Dave <Dave_member@pathlink.com> wrote:


> I'm way against non-spec. compiler extensions. This language is intended to be
> portable. And I don't want my CD full of code examples to break because I change
> compilers.

Well, my idea was that the compiler extensions (pragmas) would just be hints for the compiler how to optimize the code. If compiler doesn't support them, it would ignore them.

> Compiler flags like 'assume-noalias' to me cover the shortcomings of a language
> and are one of the biggest learning-curve challenges to beginners, and add a lot
> of time to optimizing/tuning code (i.e.: let see, if I code this and set this
> flag, it is this fast, hmmmm, what if I code this, and set this flag, or, oh
> yea, how about this...). Plus, and this is a very 'real-world' scenario, what if
> some code is changed that 'assume-noalias' breaks and the developer forgets to
> tell the build-master about it (or change the build him/herself)?

Been there, done that. I know it should be avoided. However, making compiler that produces optimal code automagically just isn't that easy. The other solution is to tell the aliasing info variable by variable.

> Finally, it is possible, given that some of the infrastructure/archtecture is
> already there for debug array bounds checking, that the 'noalias' debug runtime
> checks would both keep the compiler implementation simpler and be more
> consistent with what users expect, as well as warning them on potential aliasing
> issues when then are not intended.

I hope you understand what these runtime checks would be. They aren't done just in the header of the function, but they should be done all the time. For example:

MyClass a = x;
MyClass b = y;
if (random > 0.5)
  b = x;
// check for aliasing here or assume aliasing
a.i += b.i;
b.i += a.i;

In that example, it can't be detected compile-time whether aliasing will occur or not. The compiler cannot hold a.i in a register but it must flush it back to the memory if aliasing is assumed OR a check must be inserted to the code if we want to detect aliasing. This is just a simple example, with more complex one the amount of checks would be huge.

And the checks must be made against all variables that are live simultaneously, which would bloat the code even more.

> Referring to my post just ahead of this one, another pitfall to that idea as
> outlined there.. I realize that COM Interfaces may be a problem, as well as
> extern and export. An addition to that spec. proposal would be to exempt those
> from noalias. That again would be consistent with other parts of the language
> spec.

Well all external variables should be considered aliasing. But then again, if the programmer knew that certain variables wouldn't alias, how would he tell this to the compiler?...

>> unless it has been an order to do so. Of course it can take the
>> optimizations that it can be sure of. For example, if the variables that
>> are used at the same time are insulated in a certain scope, the compiler
>> can quite easily see if aliasing would occur. In my opinion, compilers
>
> Yes - in this case, the compiler should abort/report/warn and not leave it to
> the runtime debug checks, as is in the spec. for array bounds checking. But if
> that is difficult to do or makes things more confusing, I think runtime debug
> checks are good enough.

Compiler might not be sure whether aliasing will occur and unnecessary warnings would be printed.

The aliasing problem isn't as simple as you might think. As I said, it isn't just a matter of function parameters, it's everything that has something to do with pointers. By pointers I mean _actual_ pointers to memory locations, not just * pointers in D or C/C++. Objects in D and Java are pointers as well.

There is no magic bullet to this matter. Compiler cannot do everything for the programmer.

-texmex/sampsa lehtonen
-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

In article <opscl6lhin35qbu1@macray>, Sampsa Lehtonen says...
>
>I hope you understand what these runtime checks would be. They aren't done just in the header of the function, but they should be done all the time. For example:
>
>MyClass a = x;
>MyClass b = y;
>if (random > 0.5)
>   b = x;
>// check for aliasing here or assume aliasing
>a.i += b.i;
>b.i += a.i;

_All_ this thread has been talking about is aliasing of _function parameters_.

Not necessarily all of them either. For example, the spec. could be written to /just/ check aliasing on /value types and value type arrays/, not reference types, not array members (the spec. disallows overlapping already), not arrays of reference types, maybe leave structs out as well, and _not_ pointers.

extern (C) or extern (Windows) would be left as-is in any case.

void foo(inout int[] a, inout int[] b)
{
// runtime check here for &a != &b, if so, warn

// Code following is compiled as it is now
>MyClass a = x;
>MyClass b = y;
>if (random > 0.5)
>   b = x;
>// check for aliasing here or assume aliasing
>a.i += b.i;
>b.i += a.i;
}

>And the checks must be made against all variables that are live simultaneously, which would bloat the code even more.

The run time checks would be debug only, like they are now for array bounds. No release bloat, just smaller and faster release code ;)

See above for when the checks would be inserted. This is consistent with array bounds checking.

>Well all external variables should be considered aliasing. But then again, if the programmer knew that certain variables wouldn't alias, how would he tell this to the compiler?...

If the spec. is limited to just function params., externs would be checked, i.e.
(C++ for clarity):

extern int i;
extern int *j;

void foo(int &ri)
{

ri++;

if(random > 5) {
// i is declared outside function scope and is accessed in this function and
//  the function has int ref. param.
// Compiler inserts ri != i check here - consistent with array bounds
i++;
}

if(random > 10) {
// pointer involved
// Code generated here would be the same as now - assume aliasing with j
*j = ++ri;
}
}

Ok - so *j = ++ri; might complicate the job of the compiler a bit. If that's the case, switch back to assume aliasing for the whole function if it contains pointers declared outside it's scope. With D that probably won't effect nearly as many functions as in C/C++.

>Compiler might not be sure whether aliasing will occur and unnecessary warnings would be printed.

Fine - debug runtime checks only.. However, I would think that in some cases the compile-time check would be pretty much foolproof, i.e.:

int i;
foo(i,i); // Warning during type checking of func. params

>The aliasing problem isn't as simple as you might think. As I said, it isn't just a matter of function parameters, it's everything that has

I think you're making it harder than it has to be ;) I'm /not/talking about global aliasing or even operations on pointers, just with value type variables and array function params.

Doing this for just function params. for value types (_as explained above_) would probably provide a big bang for the buck and keep 'noalias' manageable and reasonably safe.

Hi there,

sorry I did not comment on this before - I just returned home after two weeks of traveling.

Just a short statement about my current view on aliasing. ("current", because this view is still evolving...)

First, the problem of aliasing in C was not something that came up because of some design fault, but because of the existance of references. Fortran has no references. The only possible cause for different names refering to the same object in memory would be function arguments. There, aliasing is prohibited, so Fortran has no aliasing at all, allowing very aggressive optimizations. In C, function arguments are only one of many possible causes for aliasing, so the "restrict" does not solve the problem but only softens it a bit.

As I see it, there are only two ways to rival the performance of Fortran: either step back into stone-age and create a language without references or step forward into the future and introduce high-level abstractions that allow the compiler to know more about the semantics of the code.

Vectorized expressions, as they have been discussed before, will hopefully solve the problem of aliasing in the most common cases (by allowing the compiler to freely choose an order of execution). For other cases, we can only wait for the problems to arise and solve them then (maybe even by introducing something like the dreaded "restrict") I strongly doubt, that anyone will have success in finding "the solution" for the problem as a whole.

Ciao,
Norbert


Dave wrote:

> 
> I'm very new to D (literally as of yesterday), but am very impressed with
> what I'm seeing so far.
> 
> Being that I want this language to succeed and an important part of that will be performance potential over C, I'm curious - how does/will D deal with the pointer 'aliasing problem' that plagues C and C++ compiler developers?
> 
> From what little I've seen so far, it seems that this same problem has been 'forced' on D by it's backward compatability with C libraries and C/C++ -like support for pointers.
> 
> IMHO, any language that seeks to replace C/C++ should do it's best to avoid this problem, or at least discourage code that introduces it.

On Thu, 12 Aug 2004 04:57:24 +0000 (UTC), Dave <Dave_member@pathlink.com> wrote:

> In article <opsclc1kpg5a2sq9@digitalmars.com>, Regan Heath says...
>>
>> On Wed, 11 Aug 2004 16:19:13 +0300, Sampsa Lehtonen <snlehton@cc.hut.fi>
>> wrote:
>>> I understand that making the 'noalias' as a default for out and inout
>>> parameters sounds tempting, but because it is then impossible to
>>> quarantee  the correctness of the program, it shouldn't be done.
>>
>> Is it impossible? In a debug build couldn't the compiler insert checks to
>> ensure the variables are not aliased?
>>
>> I understand that for pointers you cannot determine whether they are
>> aliased or not, but D's arrays can be checked trivially, and pointers (so
>> far) seem much less important in D than in C/C++.
>>
>> So perhaps 2 statements could be made:
>>  - pointers are assumed to be aliased unless 'noalias' is used.
>>  - other variables are assumed not to be aliased, unless 'alias' is used.
>>
> <snip>
>
> Just curious..
>
> If:
> - D still aliases by default with pointers (and D uses ptrs. less anyhow)
> - non-pointers are changed to noalias
> - pointers could still be used to get the alias side-effects if desired
> - and the debug runtime checks would presumably work like array bounds
> checking..
>
> Why would D need new keywords, compiler extensions, pragmas or compiler
> switches?

Perhaps not. :)

Unless you're forced to use a pointer, know it's not aliased and want to have it optimise.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Regan Heath wrote:

> On Thu, 12 Aug 2004 04:57:24 +0000 (UTC), Dave <Dave_member@pathlink.com>
> wrote:
> 
>> Just curious..
>>
>> If:
>> - D still aliases by default with pointers (and D uses ptrs. less anyhow)
>> - non-pointers are changed to noalias
>> - pointeimplicitstill be used to get the alias side-effects if desired
>> - and the debug runtime checks would presumably work like array bounds
>> checking..
>>
>> Why would D need new keywords, compiler extensions, pragmas or compiler switches?
> 
> Perhaps not. :)
> 
> Unless you're forced to use a pointer, know it's not aliased and want to have it optimise.
> 

I was thinking along the lines of not adding complexity (from the user standpoint) to the language or tools if it could be avoided and still cover most cases.

I figure being 'forced' to use pointers in D would almost always happen when calling libs. from other languages and in that case the rules for the other language inside the lib. function would apply anyhow.

From my understanding of D so far, even things that would ideally run really fast like iterators will be implicit references and not explicit pointers, but I'm sure there are other cases.

This and the better code/data visibility of the D compiler through import are two of the reasons I'm so eager to try and fix part of the aliasing overhead with D - I think it can be done w/o complicated kludges like "link-time code generation" as C/++ compilers are forced to use.

The implications of import on inlining and finalizing along with other things in D like foreach(...) and first-class arrays to simplify optimization are pretty large I think, even if aliasing is not directly addressed.

This really is a very, very cool language design, IMHO.

BTW - In an earlier rant, I mentioned I thought D would not succeed if the aliasing issue is not addressed. I certainly /do not/ think that way anymore.

Thanks,

- Dave

Dave wrote:

[big snip]
> community sees it that way. If D takes off (and I'm convinced it won't unless some basic issues like 'the aliasing problem' are taken care of)
[another]

For the record, after a bit more experience with D and a lot more thought, I hereby officially "retract" the above statement ;).

On the contrary and FWIW, I'm starting to become more and more convinced D will be a hit. I think in many ways it is already given its maturity relative to other languages.

It just offers too many other advantages (in terms of optimization opportunities and other major areas) to 'fail' because of this issue.

Thanks,

- Dave

In article <cf0qis$tlh$1@digitaldaemon.com>, Sean Kelly says...
>
>I don't know.  I would consider it a very bad idea to pass the same variable as multiple parameters of a function with side effects.  This is a case where I don't think it's necessary for the compiler to protect the programmer from himself.  Besides, I may not always want to pay for the extra instructions and such that this would require.

Potential pointer aliasing crops on in all sorts of mundane situations. Anywhere the compiler cannot maintain a strict bounds on a pointer's domain, it has to assume it could be pointing anywhere--your current loop termination variable, for example.

Imagine you've got a performance-critical "for" loop over "0" to "n" that calls a function, which calls a function, which calls a function, which writes to a pointer. Now imaging that the compiler, for whatever reason, cannot maintain a strict bounds on the address range of that pointer, which could possibly be pointing at the stack. What should have been a very tight "for" loop has just become much less optimizable, because "n" might have been altered by a three-deep nested function that happens to write to a pointer for which strict bounds cannot be determined.

It's a scary situation, and some compilers have an option to ignore pointer aliasing during optimization, which I always enable (if I remember to).

I agree it is a serious problem and sure would be nice to address somehow, if possible.