Enter your search terms Submit search form
	Web pdp-10.trailing-edge.com

This is the sail Beware file.  It should list all known unfixed bugs.

-----------
Arrays with virual origin < 0 cannot be handled.  We think the error 
message is correct here, so this may not be a real bug, but this 
seems the best place to record the results of my investigations, in 
case someone else wants to look at it.  The following program 
illustrates one aspect of the problem.  It generates code with the 
instruction MOVEI 2,XX(2) missing, where XX is the virtual array 
origin + 1.  (It is +1 because 1 has already been added by the 
partial array calculations.)  The problem turns out to be that in 
ARRAY, at SUBSCR, $VAL is loaded with the vir. ar. origin plus any 
partial offsets that can be done at compile time.  The virt. origin 
is -1 and the partial offset is +1, leaving 0.  The code in TOTAL at 
SBSCHK (part of GET, called from LOCN, the exec for LOCATION) checks 
to see if $VAL is 0, and if so does not emit the instruction.  
Essentially what is going on here is that GET is confusing relocatable 
and absolute 0.

BEGIN "foo"
COMMENT INTEGER ARRAY BELCH[1:100];
INTEGER ARRAY A[1:4,1:11];
INTEGER I, ANSWER;
COMMENT BELCH[1]_1;
I _ 1; 
ANSWER _ LOCATION(A[I,1]);
END "foo"

For a different faillure, try changing the array bounds to 1000:1004 
by 1000:1004, and do I _ 1002; location(a[i,1002]).  This will result 
in a garbage address.  In that case the value in $VAL is negative. 
The loader thus thinks it is part of the high seg and relocates it by
.HIGH. instead of .LOW.  

Note that these problems seem to be worse (and maybe only occur) for 
LOCATION and presumably passing arrays by reference.  For refering to 
an array element, things seem to work.  We don't know why.  The loader
should relocate by .HIGH. here, too.

Currently there is a test in ARRAY (near NWORRY) that gives an error
if the virt. array origin is less than 0.  The hope is that this is
sufficient to keep you out of trouble.  As mentioned above, there are
some cases where you will get runnable code even in this case, but
no one is confident of being able to give messages only in the bad
cases.  The original Stanford code for this test added AC's B and D.
The theory was that one was the base and the other the displacement,
and the sum was the virtual origin.  They then give an error if it
is negative, for low-seg own arrays.  Alas, it turns out that the
"displacement" AC sometimes has displacement and sometimes the actual
virtual origin.  In the case of the above test program, it turned out
to have the virtual origin, so U. of Rochester removed the addition.
We don't know any case relevant to this test where it has a displacement,
but if there is such a case, no one test will work all the time.  Also,
the test is disabled if the compilation is /-H (no hiseg code), but
we suspect the confusion between relocatable and absolute 0 may also
happen in that case (the confusion between segments obviously won't).
------------------