ENTRY statement
in [Fortran]
|
From: glen herrmannsfeldt on 5 Oct 2009 23:26 Richard Maine <nospam(a)see.signature> wrote: (snip) < That makes sense to me. (Besides which, I'd trust your memory of it a < lot better than I would trust my own user-based reconstruction of how it < acted, or for that matter someone else's deduction of how they think it < must have been.) < And note that an implementation like this would *NOT* result in the kind < of effective equivalencing that David appears to think would have < happened. Yes. I believe that he is remembering the equivalencing of function return values and confusing that with dummy arguments. I don't know if all compilers actually equivalence return variables, even if they have different types. That is an easy way to allow assignment to any return variable of the right type to work, though. -- glen
From: nmm1 on 6 Oct 2009 05:07 In article <7ivhllF3135fiU1(a)mid.individual.net>, Steve Lionel <steve.lionel(a)intel.invalid> wrote: > >When we developed the DEC Fortran 90 compiler, from a different code >base, a different method was used which did not have any sort of >"memory" of past arguments, and a lot of customers found that their >broken code was now really broken. Yup :-) We had a lot of customers who switched between IBM and DEC, and a FAQ was "Why doesn't my program work on the other?" This one wasn't one of the main causes, but wasn't rare - and it could cause failure in both directions, depending on the type of brokenness in the code. Regards, Nick Maclaren.
From: Steve Lionel on 6 Oct 2009 11:37 glen herrmannsfeldt wrote: > I always thought that DEC was in competition with IBM, and would > try to include IBM extensions. Well, ENTRY itself was an IBM > extension to Fortran 66, but I would expect them to follow the > IBM extension. I should look to see what IBM did in VS Fortran. That was certainly true for the first few VAX years, though VAX-11 FORTRAN-IV-PLUS 1.0 (the official name of the first version, released in 1978) was "nearly" a Fortran 77 compiler, so ENTRY was part of the standard by then. 1980's Version 2 (then renamed VAX-11 FORTRAN) was a full F77 compiler, with support for INQUIRE and the few things that were missing from version 1. We did copy NAMELIST from IBM in version 2 (I had the pleasure of designing and implementing the run-time library support for that) and also looked to CDC, UNIVAC and others for extensions our customers (and prospective customers) wanted to use. -- Steve Lionel Developer Products Division Intel Corporation Nashua, NH For email address, replace "invalid" with "com" User communities for Intel Software Development Products http://software.intel.com/en-us/forums/ Intel Software Development Products Support http://software.intel.com/sites/support/ My Fortran blog http://www.intel.com/software/drfortran
From: David Weatherall on 10 Oct 2009 02:15
Richard Maine wrote: > Steve Lionel <steve.lionel(a)intel.invalid> wrote: > > > Richard Maine wrote: > > > David Weatherall <nospam(a)nowheren.no.how> wrote: > > > > >> That I'd accepted that x and n would be the same location was > > >> premised on my knowledge of some calling conventions and > > particularly >> how the RSX-11M and VAX/VMS compilers do it. > > > > > > Then I suspect you misunderstand either the code or the calling > > > conventions. Perhaps it might have been the case in some > > > nonstandard pre-f77 implementation of entry, but I simply do not > > > believe that the VAX/VMS f77 compilers would work that way. I > > > can't see how they could do that and reasonably conform to the > > > standard, which I'm very sure they do. > > > > Here's what I remember from how the VAX/VMS compiler handled ENTRY > > (I was a developer on that for more than ten years). The compiler > > created an array of pointers for all the dummy arguments in all the > > entry points to a procedure (including the subroutine or function). > > When the code was entered through one of the entry points, it > > stored the address of each actual argument in the corresponding > > array location and then referenced through that array whenever it > > wanted to access a dummy. That way it did not have to keep track > > of which entry point was used. > > That makes sense to me. (Besides which, I'd trust your memory of it a > lot better than I would trust my own user-based reconstruction of how > it acted, or for that matter someone else's deduction of how they > think it must have been.) > > And note that an implementation like this would NOT result in the kind > of effective equivalencing that David appears to think would have > happened. The example in question does not illustrate the phenomenon > of "remembering" the same actual argument. I would not surprise me to > find that David was confusing it with that case, but it is not the > same thing. This was an example with two different arguments, n and > x, and expecting them to be effectively equivalenced, apparently > because they were both argument number 1 in their respective entries. > (See the code in the original post). with the above-described > implementation, those two arguments would correspond to different > locations in the array of pointers; thus setting one of them would > have no effect on the other. Another long week gone during which I had intended to do an experiment or two. Unfortunately, I was too busy using Steve's fine VAX and AXP Fortran compilers to do some real work :) Over the week I've added about 10 ENTRY points to various routines. It would have been a good opportunity but I had enough to do working out how the thing I'm trying to improve works. Steve's comment above explains some of why the compiler often uses local copies indexed from R11 instead of AP or a local register. I'd often wondered but then went back to the job in hand. I do remember that the behaviour of VAX-DEC-HP-Fortran ENTRY 'improved' over time. I fell foul of it in he mid-80's and took greater care using it thereafter. I anyway still avold Richards example of :- ENTRY (x,y) ... ENTRY (y,x) just in case. If they'd got F90 onto VAX I probably wouldn't be using them anyway :) My real-time code still runs on VAX/ELN and I prefer to debug on VAX/VMS. These modern CPU's with all their registers and code re-ordering.... No further comment until I've got my feet on firmer ground and can put the correct words around it. A mit of mixed metaphor... Cheers Dave -- |