- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Experts,
I purchased IVF recently and use it to replace HP Fortran 77. What an improvement !
However, I can't find one output that I use to have : A listing of all the variables used in my routine and on which line they have been used.
Is there an option to get that listing from IVF ?
Many thanks,
Vincent
I purchased IVF recently and use it to replace HP Fortran 77. What an improvement !
However, I can't find one output that I use to have : A listing of all the variables used in my routine and on which line they have been used.
Is there an option to get that listing from IVF ?
Many thanks,
Vincent
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not yet. Coming later this year. Here's an example from one of my sources:
[plain]SYMBOL CROSS REFERENCE Name Object Declared Type Bytes Dimen Elements Attributes References 101 Label 60 66,89 102 Label 61 67,90 103 Label 62 68,91 104 Label 63 69,92 105 Label 64 70,93 106 Label 94 107 107 Label 100 127 109 Label 101 137 11 Label 38 45,48,50,73,77,80,82,84,86 12 Label 39 46 13 Label 40 49,81,83,85 14 Label 41 51 15 Label 42 74,87 999 Label 144 46,49,51,74,81,83,85 AMORT Prog 1 DAYS_IN_MONTH Local 28 I(4) 4 scalar 124 DAYTEMP Local 25 I(4) 4 scalar 124,126,127 DAY_NUMBER Local 25 I(4) 4 scalar 85,124,126 DNINT Func 56 scalar 56,116 DONE Local 26 L(4) 4 scalar 105,113,121 DP Param 15 I(4) 4 scalar 16,18,19,20,21,22,23,24 FILESPEC Local 35 CHAR 200 scalar 87,88 MAINLOOP Label 44 scalar 76,143 MIN Func 124 scalar 124,126 MOD Func 125 scalar 125 MONTHLY_INTEREST Local 21 R(8) 8 scalar 116,117,123,130,132 MONTHLY_PAYMENT Local 19 R(8) 8 scalar 123,130 MONTHLY_PRINCIPAL Local 20 R(8) 8 scalar 117,120,123,129,131,133 MONTHNAME Local 29 CHAR 3 scalar 128 MONTHS Param 31 RECORD 8 1 12 124,128 MONTH_NUMBER Local 25 I(4) 4 scalar 83,107,113,115,124,125,128,140 NUMBER_OF_PAYMENTS Local 17 I(4) 4 scalar 49,53,57,68,91,106,119 PAYMENT_NUMBER Local 25 I(4) 4 scalar 106,114,119,127,137 PRINCIPAL_FACTOR Local 22 R(8) 8 scalar 53,54,56 RATE Local 16 R(8) 8 scalar 46,47,67,90 RATE_PER_PAYMENT Local 16 R(8) 8 scalar 47,53,54,116 REMAINING_PRINCIPAL Local 18 R(8) 8 scalar 51,56,58,66,89,116,120,129,131,138 SCHEDULED_PAYMENT Local 19 R(8) 8 scalar 56,57,69,92,117 SELECTED_REAL_KIND Func 15 scalar 15 TOTAL_INTEREST Local 24 R(8) 8 scalar 57,70,93 T_M Type 27 8 scalar 30,31,32,33 YEAR_NUMBER Local 25 I(4) 4 scalar 81,107,125,128,139 YN Local 36 CHAR 1 scalar 74,75,76 YTD_INTEREST Local 23 R(8) 8 scalar 109,132,137 [/plain]
Link Copied
20 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not yet. Coming later this year. Here's an example from one of my sources:
[plain]SYMBOL CROSS REFERENCE Name Object Declared Type Bytes Dimen Elements Attributes References 101 Label 60 66,89 102 Label 61 67,90 103 Label 62 68,91 104 Label 63 69,92 105 Label 64 70,93 106 Label 94 107 107 Label 100 127 109 Label 101 137 11 Label 38 45,48,50,73,77,80,82,84,86 12 Label 39 46 13 Label 40 49,81,83,85 14 Label 41 51 15 Label 42 74,87 999 Label 144 46,49,51,74,81,83,85 AMORT Prog 1 DAYS_IN_MONTH Local 28 I(4) 4 scalar 124 DAYTEMP Local 25 I(4) 4 scalar 124,126,127 DAY_NUMBER Local 25 I(4) 4 scalar 85,124,126 DNINT Func 56 scalar 56,116 DONE Local 26 L(4) 4 scalar 105,113,121 DP Param 15 I(4) 4 scalar 16,18,19,20,21,22,23,24 FILESPEC Local 35 CHAR 200 scalar 87,88 MAINLOOP Label 44 scalar 76,143 MIN Func 124 scalar 124,126 MOD Func 125 scalar 125 MONTHLY_INTEREST Local 21 R(8) 8 scalar 116,117,123,130,132 MONTHLY_PAYMENT Local 19 R(8) 8 scalar 123,130 MONTHLY_PRINCIPAL Local 20 R(8) 8 scalar 117,120,123,129,131,133 MONTHNAME Local 29 CHAR 3 scalar 128 MONTHS Param 31 RECORD 8 1 12 124,128 MONTH_NUMBER Local 25 I(4) 4 scalar 83,107,113,115,124,125,128,140 NUMBER_OF_PAYMENTS Local 17 I(4) 4 scalar 49,53,57,68,91,106,119 PAYMENT_NUMBER Local 25 I(4) 4 scalar 106,114,119,127,137 PRINCIPAL_FACTOR Local 22 R(8) 8 scalar 53,54,56 RATE Local 16 R(8) 8 scalar 46,47,67,90 RATE_PER_PAYMENT Local 16 R(8) 8 scalar 47,53,54,116 REMAINING_PRINCIPAL Local 18 R(8) 8 scalar 51,56,58,66,89,116,120,129,131,138 SCHEDULED_PAYMENT Local 19 R(8) 8 scalar 56,57,69,92,117 SELECTED_REAL_KIND Func 15 scalar 15 TOTAL_INTEREST Local 24 R(8) 8 scalar 57,70,93 T_M Type 27 8 scalar 30,31,32,33 YEAR_NUMBER Local 25 I(4) 4 scalar 81,107,125,128,139 YN Local 36 CHAR 1 scalar 74,75,76 YTD_INTEREST Local 23 R(8) 8 scalar 109,132,137 [/plain]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Great to hear that we will have a cross reference listing finally! What about the source browser?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Source browser is still under development - I can't make any promises about that. Not this year, but we haven't forgotten it. If we do it, it will probably require VS2010 (or later), since MS changed the underlying implementation (again).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
What version(s) of VS should we be looking to upgrade to? I'm still using VS2005 Standard, and if we need to move to VS2010, need to look at adding this to our budget planning.
Thanks,
David
What version(s) of VS should we be looking to upgrade to? I'm still using VS2005 Standard, and if we need to move to VS2010, need to look at adding this to our budget planning.
Thanks,
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't recommend upgrading in the next year, unless you have other reasons to do so. Feel free to keep using VS2005 for now. Consider VS2010 for the 2011-2012 timeframe. Note that we won't support VS2010 until late this year.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve,
will the cross-reference listing be also available in a more machine readable form, e.g. in XML?
This would be a great starting point for a variable renaming refactoring tool. Ithink, the hardest part is to find out where a variable is identical. If we get this from the compiler, building the rest of a refactoring tool would be much more realistic.
regards,
Thomas
will the cross-reference listing be also available in a more machine readable form, e.g. in XML?
This would be a great starting point for a variable renaming refactoring tool. Ithink, the hardest part is to find out where a variable is identical. If we get this from the compiler, building the rest of a refactoring tool would be much more realistic.
regards,
Thomas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nice map. In my mainframe programming days I used to use these a lot so here's my two penneth.
In the References column you should distinguish between lines that meerly use a variable, and those that define it. This could be done in a number of ways.
Eg. append a 'd' to the line numbers that define the variable, so you might see "335d,338,414,415d,419".
Alternatively, put the definitions first, and use a semicolon to separate them from the references, as in "335,415;338,414,419". The column could then be headed "Defined; Referenced".
This concept could be extended to distinguish further reference types, eg. when a variable is used as an agrument in a subroutine call, append a 'x' or whatever; when its used as an array subscript append 's'; do loop usage; etc...
You should also explicitly flag variables that are defined but never referenced, and vice versa.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No XML for now - but that is an idea we're kicking around. Thanks for the suggested improvements.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some stuff I forgot in my XREF/map suggestions:
State the variable's location: is it local (saved? initialized?), or in a common block (name it), or in a module (name it), or an argument to this procedure (state its intent).Is it a target? or a pointer? is it used in an ASSOCIATE statement?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ah the good old days of "big iron" :-) Like you I think a cross-reference map will be really useful.
Ilike your suggestions forextra information but I think your original suggestion of appending a code to a line number would end up being confusing. Better to have multiple lines of information :
Name Type Kind Rank Declared
MYVarray Local I 8 (2,7) 9
Assigned 17, 22 (ie LHS of statement)
Accessed 43,120,127 (ie RHS of assignment)
Actual Argument 52 (ie used in a subroutine/function call)
MyVarg Dummy Argument R 8 - - Intent INOUT
Assigned etc
ComVar Common (common name)
ModVar Module Variable (modulename)
BUT only if they are used in the code in question.
etc
How practical it would be to do itthis way is another matter.
I'm not bothered about it being in xml format I'd prefer straight forward text - but then I am an oldie.
Les
Ilike your suggestions forextra information but I think your original suggestion of appending a code to a line number would end up being confusing. Better to have multiple lines of information :
Name Type Kind Rank Declared
MYVarray Local I 8 (2,7) 9
Assigned 17, 22 (ie LHS of statement)
Accessed 43,120,127 (ie RHS of assignment)
Actual Argument 52 (ie used in a subroutine/function call)
MyVarg Dummy Argument R 8 - - Intent INOUT
Assigned etc
ComVar Common (common name)
ModVar Module Variable (modulename)
BUT only if they are used in the code in question.
etc
How practical it would be to do itthis way is another matter.
I'm not bothered about it being in xml format I'd prefer straight forward text - but then I am an oldie.
Les
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I assume that generating a cross reference listing is an option which can be selected or deselected. It would be nice to have a nonverbose and a verbose form (suggestion of Neilson), the first for a quick look and the second for an intensive analysis to find (apparently) hard problems.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
At this time, we don't have separate control of the cross-reference. If you ask for a listing, you get the cross-reference. We could add a second switch for that if there is sufficient demand for it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve
I hope writing here would be counted as one yes vote on demand for it....
Abhi
I hope writing here would be counted as one yes vote on demand for it....
Abhi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your vote has been duly noted. Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Les,
Yes the first time you see the line numbers with one-character appended codes, it would be confusing. But (a) a one-line key in the map header will quickly clarify this; and (b) users, espeically programmers, catch on quickly, and after a few minutes use they will (IMNSHO) prefer its size-to-information-ratio over your suggested multi-line version.
My favourite big iron map was from CDC's F77 compiler, circa 1982. When I moved to an HP Unix box 2 years later I was appauled at the meagre map it offered; not only was the information limited, it was awfully bloated, with blank lines every other line and enormously wide columns. I was so disgusted that I wrote a post-processor to reformat it down to a sensable size.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Gets my vote. The switch could even have 6 levels of verbosity... ;-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Qolin,
I noted the smiley. You are probably right though, I do tend to be too verbose.
It's one of those situations of whendoes information become too much information so maybe levels of verbosity would be useful - thoughperhaps 2would be sufficient -vQolin and -vLes :-).
Les
I noted the smiley. You are probably right though, I do tend to be too verbose.
It's one of those situations of whendoes information become too much information so maybe levels of verbosity would be useful - thoughperhaps 2would be sufficient -vQolin and -vLes :-).
Les
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would prefer a single line format with a single/dual character flag following the line number. i.e. reduce the number of lines of the report to minimal. Also, a single line format makes it easy to GREP.
Adda flag to indicate the variable was modified (Les's Assigned/LHS)
Back in the 60's/70's the assembler I used had a fairly decent CREF.
The IDE Find in Files is very fast so the use of a CREF is marginal for me now. However, when you get dumped into your lap a new conversion project of an old application, having a CREF might be a useful tool in planning your changes.
You might want to consider a way to disambiguate (collect) symbols within name space. e.g. local variable I in subroutine fee is different from local variable I in subroutine foo. Similar as to module variables and common. Possibly the way to do this is to CREF the Debug symbol file which already has the name space differentiation as well as the line numbers (it doesn't have the variablemodified information though).
Additional tools of this feather to consider would be a call tree (down as well as up).
Jim
Adda flag to indicate the variable was modified (Les's Assigned/LHS)
Back in the 60's/70's the assembler I used had a fairly decent CREF.
The IDE Find in Files is very fast so the use of a CREF is marginal for me now. However, when you get dumped into your lap a new conversion project of an old application, having a CREF might be a useful tool in planning your changes.
You might want to consider a way to disambiguate (collect) symbols within name space. e.g. local variable I in subroutine fee is different from local variable I in subroutine foo. Similar as to module variables and common. Possibly the way to do this is to CREF the Debug symbol file which already has the name space differentiation as well as the line numbers (it doesn't have the variablemodified information though).
Additional tools of this feather to consider would be a call tree (down as well as up).
Jim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A cross-reference like this will be a HUGE improvement. If the final format has not been fixed yet, may I suggest a format. I have always like the cross-reference format that HP Fortran for OpenVMS uses. It is very easy to read and contains all of the pertinent information.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The format we use is modeled on the DEC compiler, though it doesn't have all of the same information. We may well enhance it in the future.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page