Newsgroups: comp.lang.scheme,comp.software-eng
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!fas-news.harvard.edu!newspump.wustl.edu!nntp.coast.net!news.sprintlink.net!mv!usenet
From: ENGR@GSSI.MV.COM (Michael Furman)
Subject: Re: Style: multiple returns and relatives
Message-ID: <DJ2KoK.y5@mv.mv.com>
Mime-Version: 1.0
Organization: GSSI
Date: Mon, 4 Dec 1995 16:05:07 GMT
References: <RMARTIN.95Nov10210926@oma.com> <DIEFEK.7py@mv.mv.com> <1995Nov2119.02.10.16041@silverton.berkeley.edu> <DIEto8.FC3@mv.mv.com> <1995Nov2220.33.12.16907@silverton.berkeley.edu> <DIpMMp.AyE@mv.mv.com> <49led0$c2e@news4.digex.net>
X-Newsreader: WinVN 0.93.10
X-Nntp-Posting-Host: gssi.mv.com
Lines: 101
Xref: glinda.oz.cs.cmu.edu comp.lang.scheme:14485 comp.software-eng:39868

In article <49led0$c2e@news4.digex.net>, jethomas@cpcug.org says...
>
>Michael Furman (ENGR@GSSI.MV.COM) wrote:
>
>>In article <1995Nov2220.33.12.16907@silverton.berkeley.edu>,
>>djb@silverton.berkeley.edu says...
> 
>>>In article <DIEto8.FC3@mv.mv.com>, Michael Furman <ENGR@GSSI.MV.COM> 
wrote:
>>>>     calculating index1 and index2 - it can be a very complicated 
algoritm
>>>>     some_function(memory + index1, memory + index2);
> 
>>>My understanding is that such constructs are incorrect in Fortran. No
>>>aliasing really does mean no aliasing.
> 
>>   It is incorrect only if there is an aliasing. If not - it is correct. 
And
>>this example can be modified to remove pointers at all - just pass integer
>>indexes and use big common array. If you know that such code generated from
>>Fortran (let's say by F2C) - you can optimize it. If you don't - you can 
>>not.  And it is a contraexample for opinion that there is no problems of 
"code
>>efficiency" for languages but just for compilers.
> 
>??  Is this a Shroedinger's Cat thing?  It becomes optimisable when you
>find out it came from Fortran? ??  I don't understand at all.

  Knowledge of some information that is not expressed in the algorithm may
help to optimize program. Funny example: if you know result (by solving 
math problem analitically) yo can just replace whole program by just one
"print" statement (in real case you usually do not need a program at all).
  If you know that program came from Fortran - you may do not care about
possible aliasing (because Fortran forbid aliasing) and use more powerfull
optimization.


> 
>>   There are two (I know of) source of "code efficiency" issue for 
>>languages.  First is what this example about: for some language compiler 
>>can know at compilation time some information that can be uset for 
>>optimization.  And for another language this information can be only 
>>calculated at run time.
> 
>OK!  That's one of the things I'm having trouble with.  You start out
>with specifications that say what your program should do.  In one
>language, those specifications translate into information at compile
>time, but in another language the same specifications include
>information that's lost until runtime.  How come?

   It depends on what is "specification" exactly. In ideal case I would say 
that specification should contain a lot of extra information besides 
algorithm really needed for computing: at least 1. Domain definition and 2. 
Proof of correctness. Of couse it is not possible literally and we are trying 
to add to program only some elements of that. Some of that elements may
be exepressed in some language but not in another (at least directly). And 
sometimes can be used by compiler. Theese may be:
1. aliasing / non aliasing information
2. pre / post coditions
3. constaints for some values.
e.t.c.

> 
>>For C/C++ this problem (I do not mean it in general, but alissing and
>>optimization problem) is known and some compiler vendors use some 
extentions
>>that let programmer (using #pragma or run time compiler switch) declare 
that
>>there is no aliasing in whole program or part of it.
> 
>That makes good sense.
> 
>>Second issue - special hardware facilities (special instructions, 
>>interrupts, registers e.t.c).  It related more to real time and OS 
>>programming, but often it is very important.  Unfortunately there is no 
>>good enough solutions in high level languages - almost always we neeed 
>>some assembler.
> 
>Of course.  So we figure out what we need and build it in assembler and
>add it to the compiler, and it's settled until next time, right?  No
>big deal there, except for the portability issue.
> 
>Unless for some reason you want to use a language that isn't
>extensible, and why would anybody do that?  All serious languages are
>extensible, and I expect you can do anything in one extensible language
>that you can do in any other extensible language that includes an
>assembler.

I am not sure that I understand what exactly you mean "extensable language". 
But anyway some things - for example - memory mapped I/O may be well 
expressed by some languages (for example C, C++) abd not so well by others 
(Fortran, I guess - Lisp).

-- 
---------------------------------------------------------------
Michael Furman,                       (603)893-1109
Geophysical Survey Systems, Inc.  fax:(603)889-3984
13 Klein Drive - P.O. Box 97          engr@gssi.mv.com 
North Salem, NH 03073-0097            71543.1334@compuserve.com
---------------------------------------------------------------

