DEC runtime library for Fortran in Visual studio 2022

[BvU]

trying to revive some stuff from 40 years ago.
Found I could download and install Intel Fortran which seems to be a descendant from an old DEC VMS friend. Even managed to get it 'integrated' into Visual Studio 2022 (somewhat; haven't got a decent help or debug facility running yet... and no idea how to hook up runtime libraries).

Overwhelming experience; and a far cry from DCL
$ For aap | $ Link aap | $ Run aap

But I'm sure there are good reasons for all this progress

My current issue:

Need help to resolve symbols like STR$... and LIB$... that were in the runtime library

(e.g. :
Severity Code Description File
error LNK2019: unresolved external symbol STR$UPCASE referenced in function STR$UPCASE.void CMR$DEFAULT.obj

For the debugging and help there are some clues, but I quickly find myself drowning in side issues in a world that seems to abhor the word fortran

$\$

 

[Baluncore]

... I quickly find myself drowning in side issues in a world that seems to abhor the word fortran

The name was FORTRAN, not fortran, because only upper case letters were used, up to and including F77.

You needed to know how many 6 bit characters you could pack into a double precision floating point variable on your machine. That will now cause side issues.

 

[BvU]

Great, thanks.
Now: what do I have to do to resolve these LNK2019 errors ?

I added /f77rtl in Project | Properties | Fortran as additional options - makes no difference

Adding /f77rtl to the linker command line gives
warning LNK4044: unrecognized option '/f77rtl'; ignored LINK
Makes sense, but I'm still stuck with unresolved externals


I installed w_ifort_runtime_p_2024.1.0.968.exe but can't find where it puts the stuff.

(anyone ?)

Had good fun and success with this setup in another thread (with no LIB$... etc) so the whole machinery seems to work OK....

Frustrating

 

[pbuk]

I quickly find myself drowning in side issues in a world that seems to abhor the word fortran

The world does not abhor Fortran, but the language has changed in the last 40 years (although not much in the last 35 years).

If you want to use strings see https://fortran-lang.org/en/learn/quickstart/arrays_strings/#character-strings

You also (I note from some of your other posts) need to understand IEEE 754 and its near universal implementation in everything from supercomputers to microcontrollers. Many of the things you used to have to worry about on DEC hardware are no longer relevant.

 

[BvU]

Thanks, and I know that underneath a whole lot of newfangled stuff some sturdy fortran is actually doing the work.

I also have done quite a lot of character stuff in fortran on VAX and Alpha. And their architecture handbooks (close enough to IEEE 754) are within reach right where I am sitting.

But at the moment I am interested in dealing with these:

Can't suppress the feeling there is a simple solution. If I get frustrated just a little more I will embark on simply writing them from scratch

 

[Vanadium 50]

Let's describe the problem in more accurate terms.

You have Fortran code from 40 years ago that used non-portable extensions (the "blue pages"). Now you have discovered this code is, exactly as promised, non-portable.

I understand why you don't like this situation, but it shouldn't be a surprise.

I see three options:

1. Keep trying other compilers, hoping they have implemented these functions. Your best bet will be with commercial compilers, like PGI or IBM.
2. Figure out what these functions do, and write code that does the same thing with the same name and link it in.
3. Figure out what these functions do and re-write the application code to do this some other way so as to use only portable code.

I know none of these are appealing, but unfortunately, it is unlikely to find a switch "--compile-old-incompatible-code-correctly".

 

[Vanadium 50]

Of course, once I wrote down the three solutions, I cam up with a fourth: use SIMH to emulate a 40 year old VAX amd run your code on that.

 

[pbuk]

Of course, once I wrote down the three solutions, I cam up with a fourth: use SIMH to emulate a 40 year old VAX amd run your code on that.

https://www.openvmshobby.com/

Probably 10x the performance of the prototype.

 

[Vanadium 50]

I prefer the other direction: http://toyvax.glendale.ca.us/~vance/vaxbar.html

 

[Vanadium 50]

By the way, I don't want to sound unsympathetic. I have found myself in exactly the same situation. But the outcome was not unexpected and the options are rather limited.

 

[jedishrfu]

one could consider porting it to a more modern language like Julia, Java, Python or Go.

 

[Vanadium 50]

Or a more modern language like BASIC or Pascal.