Life is really simple, but we insist on making it complicated. Confucius

[JohnNichols]

The latest VS I loaded by mistake on a NUC.  I then found that it turns off codelens in the community version.   You cannot use it. 

Codelens for those that use it, is really neat.  

Blast Microsoft.  

I always think this the best place to ask all questions,  like why 42, but putting that aside, I asked a question on the Intel Graphics forum, which I should have known the answer to already, but had forgotten the solution. 

@AlHill answered the question in his usual fashion, I like you use of the flame thrower.  

JMN

[JohnNichols]

Jim:

I just struck this issue.  The only way to solve it that I can see is to create the actual arrays that l stands for in all the calls.  

How could they have used l(1) to represent large integer and real arrays in the olden days?  

It is mainly tedious.  

JMN

[jimdempseyatthecove]

Rules for Unformatted Sequential WRITE Statements (intel.com)

Jim Dempsey

[andrew_4619]

Well that is unformatted output so it will dump a 4 byte binary for each element ie chunk of lm*4 bytes to unit nf

[JohnNichols]

OK, one has to assume that people who were programming Fortran in the 1960s on UCB computers knew what they were doing by 1994.  

I shall continue, thank you.  

[jimdempseyatthecove]

If the code was written in the 1970's, it may have been on a PDP-11.

64KB address space

2.4MB-10MB hard disk

You wouldn't store much file data as Formatted. You would use unformatted files. You would print formatted records.

Jim Dempsey

[JohnNichols]

I have played with this group's code since the early 1980s, the first on a CDC Computer using a tape.

I am slowly getting the code to run, there are some interesting things in the code that I can see a modern compiler getting upset about, the interchange of scalars and arrays across Fortran units, is the challenge at the moment.  

Yes, they are making use of storing stuff on binary files,  it is a similar challenge to reading the binary output from an accelerometer, the only difference is Fortran does not lose data nor send crap you cannot understand.  

I am a little amazed it ran on Powerstation without error.  

It is just some fun. 

[AlHill]

I remember programming on CDC gear back when they had 36-bit words, 9-bit bytes, and fieldata (six 6-bit).  It was always a pain converting from a CDC financial program to a machine that had 32-bit words, as you lost some prcision on calculations. 

Doc (not an Intel employee or contractor)
[Maybe Windows 12 will be better]

[JohnNichols]

Dr Hill:

as you lost some prcision on calculations

This sentence fragment made me smile. 

If it was deliberate, it is brilliant - Shakespearean,

if it is random then it merely proves God exists and she has a sense of humour.  

[JohnNichols]

Example - iread in rstate creates a 2 element array kalpm, 

dampg.h was fixed to show the 2 element array so it would build, it merely held the common

then line 203 throws an error as it expects a scalar 

How would this have compiled on Powerstation or some linux compiler? 

[jimdempseyatthecove]

>>How would this have compiled on Powerstation or some linux compiler?

Don't know. Suspect it treated as kalpm(1)

.or. iif missing include "dampg.h" .and. using implicit variables, it would use an undefined integer variable kalpm.

Jim Dempsey

[JohnNichols]

I agree, it is strange, but old Fortran can be strange.  

They knew the undocumented features, we do not have them with modern compiler.  

[jimdempseyatthecove]

Fortran (olden days) did not do argument checking.

Passing an array to a procedure passed the array by reference (iow the address of the 1st element of the array)

Passing a scalar of an element in the array, for example l(1), passed the scalar by reference (iow the address of l(1)).

This is to say the two are indistinguishable by the called procedure.

Conversely, one could pass a non-array scalar to a procedure that expects an array (no interface checking done), and the called procedure could index the dummy of the actual argument as if it were an array.

Some of the old codes were written using this feature.

For example having a common block with numerous scalars, but performing READ/WRITE using the 1st scalar as if it were an array.

(a lazy way of doing an EQUIVILANCE of the common block to an array... without actually doing so).

If this "bugs you" then fix the code (but do it correctly).

Jim Dempsey

[JohnNichols]

It  does not bug me. 

The compiler throws an error. 

What do you suggest is the most correct fix?  

[JohnNichols]

c ------------------------------------------------BLANK COMMON ADDRESSES
      kndid = ksofar
      kcoord = NXTODD (kndid + 3*nnods)
      ksofar = kcoord + 3*nnods*iprec

For the l array, they made up offsets for the storage of the different arrays for the real they doubled the offsets. 

[jimdempseyatthecove]

I'd have to look at the caller and the called procedure to offer advise.

Making the error message go away, without consideration of what is required, often leads to errors.

The blind, and possibly error prone suggestion is to replace l(1) with l(1:) .or. alternatively replace l(1), with l .or. something completely different.

You will have to look at this.

Jim Dempsey

[JohnNichols]

No I am putting in the arrays into blank.h and naming the common block, so L will disappear with time.  

Really I will need to end with allocates, but thanks for the thoughts. 

[jimdempseyatthecove]

for named offsets into l, consider:

call foo(l(fi:fo-1), l(fo:fum-1), l(fum:fumEnd)) ! fo follows fi, fum follows fo

Or something like this.

Jim Dempsey

[JohnNichols]

Good idea.  I am just getting some write statements into the code and tracking through the running, then I will fix the logic.