Trailing-Edge
-
PDP-10 Archives
-
BB-L014E-BM
-
autopatch/ftn206.d05
There are no other files named ftn206.d05 in the archive.
EDIT DESCRIPTIONS FOR FORTRAN-20
EDIT 155 FOR FORDDT
[SYMPTOM]
A TYPE command requesting a dummy parameter be displayed
will result in the error message:
?FDTIER Internal FORDDT error - 5
if the passed parameter is an array which the user
referenced in a DIMENSION command.
[DIAGNOSIS]
When looking for the passed parameter in the symbol table,
the only valid data known is its address which was passed to
the subroutine. The field used to contain the RADIX 50
value of the name of the field being sought still contains
the name of the dummy parameter. Since these two values
which the LOKSYM routine uses to find a symbol describe two
different data items, no match is found and an internal
error results.
[CURE]
Edit 155 to FORDDT will store the RADIX 50 value of the
dummy parameter in another location and pass a null field
name to LOKSYM, allowing a match to be found on the basis of
the address of the passed parameter only.
********************************************************************************
EDIT 156 FOR FORDDT
[SYMPTOM]
An incorrect module name will be displayed as containing the
data field referenced in a TYPE command. The module will
contain the field, but is not the module that is currently
being executed, or the one currently opened.
[DIAGNOSIS]
If a field is defined as being in a common data block, each
module that INCLUDEs that block has the block's symbols
defined within its own local area in the symbol table. When
searching the table to find the requested data field to then
find the module name, the table is searched starting at the
end and working backwards. The first match on the field
named is assumed to be the correct one. If a field is
defined in several subroutines, only the first location will
be used.
[CURE]
The search for a symbol should be started at the area in the
symbol table which is dealing with the currently opened
module. If the specified symbol is not the found there, the
the entire table should then be searched. If a field is in
the current module, no name should be specified. If it is
declared within a common block, 'in COMMON' should be
displayed. If it is in any other module, that name should
be displayed. Edit 156 to FORDDT will turn on a flag if a
TYPE command has been issued so the LOKSYM routine will
start the search at the address held in OPENLS. If no match
is found, the search will be restarted at .JBSYM to look
through the entire table.
********************************************************************************
EDIT 2034 FOR FOROTS
[SYMPTOM]
If symbols are generated for a FORTRAN overlaid program, it will not
execute with FORTRAN V6. The runtime message "%OVLSTS ..." will be
generated.
[DIAGNOSOS]
When the FORTRAN system is initialized, the memory manager attempts to
reserve the symbol table as "used memory" so that it will not be
allocated. This causes problems for overlaid programs because OVRLAY
wants to re-use that memory to bring the overlays in.
[CURE]
Code implementation in FORMEM allowing overlaid programs to access
symbol table.
********************************************************************************
EDIT 2035 FOR FOROTS
[SYMPTOM]
In FORTRAN V6, if an exponent is too small for Real**Real, the
resulting error message states that an overflow occurred, when in
fact, an underflow occurred.
[DIAGNOSIS]
In DEXP2., tests for negative exponent. If negative, gives underflow
error message, if not negative, gives the overflow error message.
[CURE]
Additional code in D20VUN routine to check if the exponent is positive
but too small.
********************************************************************************
EDIT 2036 FOR FOROTS
[SYMPTOM]
On TOPS-20, if a user runs a FORTRAN V6 program on a TTY, detaches,
then attaches to a TTY having a number less than the original TTY, and
attempts to run the program, the result will be an "?Impossible JSYS
error" message.
[DIAGNOSIS]
Code to create ASCIZ string assumed that the data area was initially
zero.
[CURE]
Code added to the INIT% routine which deposits a null byte at the end
of the existing data.
********************************************************************************
EDIT 2037 FOR FOROTS
[SYMPTOM]
FORTRAN V6 NAMELIST input runs too slowly if a large array is being
read in one element at a time.
[DIAGNOSIS]
Code goes through a loop unnecessarily a large number of times for
each input done.
[CURE]
Code change in SETNL1 routine which terminates the loop and sets the
data flag and data repeat count to zero.
********************************************************************************
EDIT 2040 FOR FOROTS
[SYMPTOM]
FOROTS V6 gives Integer Divide Checks when computing elapsed time for
TOPS-10. This occurs when the program exits and the system has been
up a long time.
[DIAGNOSIS]
The result of the calculation of uptime is placed into incorrect
accumulator.
[CURE]
Make corrections in FORXIT and FOROTS to store uptime calculations in
T2 instead of T1.
********************************************************************************
EDIT 2041 FOR FOROTS
[SYMPTOM]
FOROTS, TOPS-20 logical names definition can cause "?File not found"
error when an OPEN statement is followed by a READ statement.
[DIAGNOSIS]
Logical name expansion is done too soon (before FOROTS knows if a user
is going to WRITE or READ the file.) This causes the first physical
device in the list to be bound to the file.
[CURE]
Insertion of code in Dialog Scanner routine REPARSE which postpones
the expansion of logical names.
This edit is dependent on Edit No. 1982 to TOPS-20 V4 Monitor. Both
edits must be installed in order to correct the problem.
********************************************************************************
EDIT 2042 FOR FOROTS
[SYMPTOM]
END FILE causes a subsequent WRITE to drop data from the beginning of
the output record and incorrectly updates the record count.
[DIAGNOSIS]
FORIO and FOROPN end-of-file routines increment/decrement the record
count using an NREC offset into the DDB when they should use NREC as
an offset into the UDB. The result is that the virtual output record
position byte counter ORPOS(D) gets inappropriately updated when an
update of NREC(U) was intended, causing a subsequent output operation
to miscalculate the start of the output record, and causing a failure
to update the record counter.
[CURE]
Change NREC(D) to NREC(U) in end-of-file routines in FORIO and FOROPN.
********************************************************************************
EDIT 2043 FOR FOROTS
[SYMPTOM]
V6 FOROTS on TOPS-10 does not ignore leading spaces in file name.
This results in a file which has the default file name instead of the
specified file name.
[DIAGNOSIS]
Routine DPRFN1 causes the DPRCHS routine to be executed. This routine
gets a character and returns to DPRFN1. If the character is a space,
it is incorrectly interpreted as the end of the file name.
[CURE]
Code change in DPRFN1, causing routine DPRCHR to be executed instead
of DPRCHS. DPRCHR transfers control to DPRCHS to get a character,
returns to DPRCHR, tests to see if the character is a space. If that
is the case, program loops through DPRCHS to get another character.
********************************************************************************
EDIT 2044 FOR FOROTS
[SYMPTOM]
F format output values, following T format editing are sometimes
incorrect.
[DIAGNOSIS]
SIPOS, the T format record positioning routine, fails to clear the
D%EOR bit in the flag word. When the T format causes the record to be
read a second time, the record is processed with the end-of-record bit
set.
[CURE]
Addition to SIPOS, clearing the D%EOR bit in the flag word.
********************************************************************************
EDIT 2045 FOR FOROTS
[SYMPTOM]
Ambiguities in a FORMAT statement, such as (A5A)
produces the fatal diagnostic '?Ambiguous repeat count', and
terminate program execution. This did not occur in previous
versions of FORTRAN.
[DIAGNOSIS]
Ambiguities were never reported, although they should
have been. The code changes to upgrade the product to the
ANSI-78 standard have introduced this diagnostic, but it
should not be fatal.
[CURE]
Reduce the severity to a warning, and proceed with
execution, associating the constant with the descriptor on
the left.
********************************************************************************
EDIT 2047 FOR FOROTS
[SYMPTOM]
Very large I/O lists in a single WRITE statement within a subroutine
that contain I/O list elements from outside the subroutine, can cause
bad data to be output for the I/O list elements not defined within the
subroutine.
[DIAGNOSIS]
The I/O list arguments in the statement are more than the maximum
amount allocated, causing the TOOMNY routine to be executed. A PUSHJ
to %GTBLK is done to allocate a block of memory. Upon the return from
this %GTBLK, T2, which had contained the address of an argument to be
accessed indirectly from T0, no longer contains the correct value.
[CURE]
Save T2 before the PUSHJ to %GTBLK and restore T2 upon the return from
the routine.
********************************************************************************
EDIT 2050 FOR FOROTS
[SYMPTOM]
Opening a file on magtape, for output in DUMP mode, will
generate a fatal "Illegal address in UUO error" on TOPS-10.
[DIAGNOSIS]
Error in code in %LSTBF, allowing DUMP mode to attempt a
buffered output, resulting in a fatal error.
[CURE]
Additional code in %LSTBF which tests for DUMP mode. If
mode is DUMP, the program pops out of the routine without
executing the output.
********************************************************************************
EDIT 2051 FOR FOROTS
[SYMPTOM]
Field widths allocated during FORMAT processing are too small and no
warning is given when fields which exceed the maximums are truncated.
Repeat counts so truncated cause premature termination of iterative
loops. In addition, positive P format scale factors greater than or
equal to 9 bits, which have bit 9 set, are interpreted as negative
scale factors.
Core for format encoding is allocated on a worst-case basis and excess
core is never deallocated when saving encoded formats.
[DIAGNOSIS]
Because FORFMT allocates only one encoding word per format descriptor,
field widths which exceed 8 bits for total width of descriptor, 12
bits for repeat counts, 6 bits for decimal width or 3 bits for
exponent width are truncated of their high-order bits without warning,
causing unpredictable results. The sign-extension routine for P scale
factors was never updated to reflect an expansion of the field from 9
to 12 bits.
Core for encoding is requested based on the total size (in characters)
of the format statement; if the encoded format is of a type to be
saved, the total core originally requested is saved, not the amount
actually used, so unused core is never freed up.
[CURE]
Implement expanded field-width capability in FORFMT by adopting a
double encoding word scheme. Institute a range-checking mechanism to
return a fatal error ("?Illegal field width" or "?Illegal repeat
count") when fields overflow.
Implement an expandable encoding work area which expands only when
format encoding requires it. When saving encoded formats, save only
the encoded data, not the total work area.
********************************************************************************
EDIT 2052 FOR FOROTS
[SYMPTOM]
There are several problems with the memory manager that
affect TOPS-10 users adversely. These are:
1. The cut back core function does not reduce the size of
the paged (OTS) memory area. This affects SORT and
overlay users on both TOPS-10 and TOPS-20.
2. The routine to free memory pages does not eliminate the
pages being deallocated. This affects users of RANDOM
files.
3. If a request to create pages fails, any pages that may
have been created by the request are not marked in the
page table, causing problems when an attempt is made to
allocate the same pages for a later request. This can
affect all users.
4. The routine to create pages does so one at a time,
regardless of the number of pages being requested. This
affects all users.
[DIAGNOSIS]
1. There is no code to reduce the size of the paged memory
that is managed as a block structure. Therefore, the
cut back core function has no effect after a SORT call.
The size of the block structure will never diminish,
therby making fewer pages available to the low seg and
page memory managers.
2. The routine to free memory pages has no code to remove
the pages being freed. The TOPS-10 case was never
considered.
3. The code for creating pages on TOPS-10 is not written
such that pages can be easily marked as in use after
they are created. Instead they are all marked upon a
successful attempt to get all the pages requested.
4. The argument block for the PAGE. UUO was setup to handle
only one page at a time due to problems with previous
monitor versions.
[CURE]
Eliminate all these problems at once, improving memory
usage/allocation dramatically in many cases.
1. Add a routine to trim the OTS block structure back. This
routine purposely only trims the list back from the
beginning to avoid block fragmentation which defeats
coalescing.
2. Eliminate pages being freed for TOPS-10. Make sure that
the routine that removes the pages does so completely,
regardless of whether or not all the pages in the
request actually do exist (as can happen when a create
request fails).
3. If a create page request fails, merely delete all the
pages in the request. A partially successful request is
generally of little use.
4. Increase the size of the PAGE. argument block to allow
creation of up to 16 pages at once. This reduces the
number of UUOs for small requests to one, and for large
requests (SORT and overlay) to a much more reasonable
number.
The amount of code introduced by this edit may be sufficient
to require repositioning the start of the code PSECT for
FOROTS. This can be done by reducing the value in the LINK
command file F10OTS.CCL (TOPS-10) or F20OTS.CCL (TOPS-20)
for value F.CODE by 1000 (octal).
********************************************************************************
EDIT 2053 FOR FOROTS
[SYMPTOM]
The paged (OTS) memory manager frequently allocates
more pages than it really needs. This can cause an
undeserved fatal error indicating no more memory is
available. For example, if there are 30 pages of free core
left, and 20 pages are allocated and deallocated, then a
subsequent request for 25 pages will fail.
[DIAGNOSIS]
When the block memory manager determines that the
current request will not fit in any existing free block, it
calculates the number of pages required to contain the new
block (plus overhead) and creates them. No attempt is made
to consider any free space that might be available in the
block structure list. For the example above, the 20 page
free chunk in the block list is not considered when trying
to find room for the 25 page request.
[CURE]
Using the cut back core function (edit 2052) or
reducing the block structure everytime a block is freed
induce yet additional problems. Instead, when attempting to
get more memory for the block list, consider any initial
free block size when determining the number of additional
pages needed, and try to get the new pages contiguous with
the start of the list. This consideration corresponds to
the usual way in which core is requested in a program, tends
to increase coalescing over time, and reduces the time
needed to find free pages for allocation.
Also preserve the saved PC when linking in a new free block.
This makes debugging easier.
********************************************************************************
EDIT 2055 FOR FOROTS
[SYMPTOM]
?Illegal memory reference doing complex exponentiation.
[DIAGNOSIS]
Routine STOR in CDLOG fails to return properly due to a typo (POP
instead of POPJ), and the stack gets trashed.
[CURE]
Fix the typo via attached Edit 2055.
********************************************************************************
EDIT 2056 FOR FOROTS
[SYMPTOM]
Input of records in image files, opened for random access, in which
the record numbers are larger than the largest record numbers
previously written, do not take error path.
Input of data from a non-existent image file, opened for random
access, does not result in an error.
With TOPS-10, files opened for random access, then closed and reopened
for sequential I/O with END= included in the input statement, may
result in an error message upon end of file.
[DIAGNOSIS]
No code implementation for input of random access, image mode files to
take the error branch if the input attempts to access records beyond
the end of a file.
For TOPS-10, random access files are padded to blocksize when closed,
therefore, there is no way of knowing where the end of the file occurs
within the block.
[CURE]
Additions to FORIO causing error path to be taken if the record number
being read is larger than the largest record number previously
written.
In TOPS-10 code, changes which cause the size of random access files
be the number of actual words written to the file, instead of padding
the file to the current block boundary. Please note that although
this edit causes random files to be the exact number of words actually
written, random files written with V6, previous to this edit, will
remain padded to block boundary.
********************************************************************************
EDIT 2057 FOR FOROTS
[SYMPTOM]
List-directed output of real numbers following Formatted IO can output
incorrect values.
[DIAGNOSIS]
Edit 2051 to the FORMAT encoder neglected to zero out the second
encoding word in the code which processes list-directed or unformatted
output. As a result, trash from a preceding FORMAT statement can be
picked up by the floating-point output routines which check this
encoding word for element width.
[CURE]
If and only if Edit 2051 has been installed, install the following
Edit 2057 to clear the second encoding word before list-directed
output.
********************************************************************************
EDIT 2060 FOR FOROTS
[SYMPTOM]
Random I/O to a file which has been opened for sequential access
results in "Can't do sequential I/O to direct file" error message.
Unformatted I/O to a file opened for formatted data transfer results
in "Can't do formatted I/O to unformatted file" error message.
[DIAGNOSIS]
The error message that is output is the same message, regardless of
the OPEN specifiers or type of data transfer.
[CURE]
Change the words in the error message so that the following are
output:
"Can't mix sequential and direct I/O"
"Can't mix formatted and unformatted I/O".
********************************************************************************
EDIT 2061 FOR FOROTS
[SYMPTOM]
Non-FORTRAN program which use the TIME subroutine from FORLIB fail
when using version 6.
[DIAGNOSIS]
When the FORLIB routine TIME is called, registers T2 and T3 are stored
on the stack. Upon exit from the routine they are restored in the
wrong order.
[CURE]
Reverse the two POP instructions at label OUT1.
********************************************************************************
EDIT 2062 FOR FOROTS
[SYMPTOM]
Files with extension of "DAT" sent to the printer via DISPOSE = 'LIST'
or 'PRINT' do not have the first character in each record used as
carriage control.
[DIAGNOSIS]
FOROTS version 6 does not test for files with extension of "DAT" and
set up the appropriate argument block for "/FILE:FORTRAN" in the queue
request.
[CURE]
Add code in module FOROPN to test for an extension of "DAT". If found
then add argument "/FILE:FORTRAN" in the queue request otherwise print
as "/FILE:ASCII".
********************************************************************************
EDIT 2063 FOR FOROTS
[SYMPTOM]
On TOPS-10, the error message "?Incompatible attributes /" outputs
garbage instead of the specifiers and specifier arguments.
[DIAGNOSIS]
Error message IOERR ISW,30,506 causes code to be executed that creates
a SIXBIT byte pointer and then attempts to convert the characters to
be output from SIXBIT to ASCII, when, in fact, the characters are
already stored as ASCII.
[CURE]
Change IOERR ISW,30,506 to execute code that expects to find the
characters to be output stored as ASCII characters.
********************************************************************************
EDIT 2064 FOR FOROTS
[SYMPTOM]
Files created by FOROTS using STATUS='SCRATCH' do not conform to the
standard naming convention for TOPS-10 temporary files.
[DIAGNOSIS]
File names used for STATUS='SCRATCH' were randomly chosen with
extension of "TMP". The first three characters of the file name
should be the current job number.
[CURE]
Add code to use the current job number as the first three characters
of the scratch file.
********************************************************************************
EDIT 2065 FOR FOROTS
[SYMPTOM]
A FORTRAN program with the appropriate values in accumulators will
enter the integer overflow trap routine recursively until an illegal
instruction is encountered.
[DIAGNOSIS]
When the routine which types the error message on the terminal is
called, it expects that register U will contain the address of a valid
unit descriptor block (UDB) and that register D will contain the
address of a valid device descriptor block (DDB). Unfortunately, only
the DDB was available and it does not contain a pointer to a UDB.
[CURE]
Keep a UDB for the controlling terminal instead of a DDB. The UDB has
in it the address of the associated DDB for the TTY.
********************************************************************************
EDIT 2066 FOR FOROTS
[SYMPTOM]
Files opened ACCESS='RANDOM' cannot READ/WRITE records with record
numbers greater than (2**18)-1.
[DIAGNOSIS]
In calculating the file-position of the current random record being
accessed, RMAPW in FORIO performs a half-word calculation of the
record size in bytes times the desired record number, thus truncating
the result.
[CURE]
Ensure the calculation is performed with whole-word quantities.
********************************************************************************
EDIT 2067 FOR FOROTS
[SYMPTOM]
Reading NAMELIST variables beginning with T or F can result in
?Illegal character in data.
[DIAGNOSIS]
NAMELIST variables beginning with T or F are tested to determine
whether they are actual variables or of type logical. If the former,
flags are never set to allow left parenthesis or equal sign as legal
delimiters.
[CURE]
Add flags in %NLI (NAMELIST input) to allow these characters as legal
delimiters.
********************************************************************************
EDIT 2070 FOR FOROTS
[SYMPTOM]
A negative exponent and a real base whose absolute value is
less than one will produce an underflow warning message
instead of an overflow warning if a warning is necessary.
[DIAGNOSIS]
The code at D2OVUN with edit installed 2035 takes the size
of the absolute value of the base into account when
determining which warning to produce, but then performs a
second test on the sign of the exponent alone which
overrides the effect of the first test.
[CURE]
By deleting the second test on the exponent the correct
warning will appear. Edit 2070 to FORDBL will accomplish
this.
********************************************************************************
EDIT 2071 FOR FOROTS
[SYMPTOM]
External and internal changes made to CCOC words cause various
problems, such as, output displayed after performing terminal input is
different than when done before the input. Also, when a program is
executed a second time by a START command, characters are echoed
differently in the second run than in the first run.
[DIAGNOSIS]
When a terminal is opened in FOROPN, the CCOC words are saved. A
masking operation is then performed to set the CCOC words to the
standard FOROTS setting. In FORIO, when terminal input is to be
executed, the saved CCOC words are restored for the TEXTI. After the
TEXTI, the masking is performed again, causing the CCOC words to be
reset to the standard FOROTS setting.
The above procedure causes several different problems depending
on the scenario of the program. First, if the program makes a call to
a subroutine which changes the CCOC words before the terminal is
opened, then the saved CCOC words will be the ones set up by the
subroutine and not by the monitor. When terminal input is performed,
the subroutine's set of CCOC words will be used for the terminal, not
the terminal's CCOC words.
The second problem occurs whenever a call is made in a program to
change the CCOC words. Since after the TEXTI is executed the CCOC
words are masked again to the standard FOROTS setting, the changes
made by a call to a subroutine are now lost.
The third problem arises when a program is exited then reentered
with a START. The CCOC words are always changed either by the masking
operations or by a call to a subroutine. However, the original CCOC
words are not restored before the program exits. Since a START uses
what is currently in memory, when the terminal is opened again the
CCOC words that are saved reflect the changes that had been made to
them when the program was previously run.
[CURE]
Save the primary terminal's CCOC words in FOROTS when .PRIIN is
being set up. Also, set up the standard FOROTS CCOC words at that
time. These steps will allow a call to be made at any point in the
program to a subroutine which changes the CCOC words.
At TTYSET in FORIO, when the primary terminal is opened, put its
saved CCOC words into its DDB. If another terminal is opened save
that terminal's CCOC words in its DDB and perform the masking
operations for that terminal.
When terminal input is to be executed, at TIREC in FORIO, save
the current CCOC words and restore them after the TEXTI has been
performed. These steps will eliminate changed CCOC words from being
lost after terminal input.
When terminals, other than the primary terminal, are being
closed, reset the CCOC words to their original state. The primary
terminal's CCOC words are reset during execution of an EXIT .
Edit 2071 to FOROTS, FOROPN and FORIO accomplish all these
changes.
********************************************************************************
EDIT 2072 FOR FOROTS
[SYMPTOM]
When the DEVICE option is used in the OPEN statement and is set
to a literal of blanks, the error message 'no such device' is
returned.
[DIAGNOSIS]
In the OPNDEV routine, the name given in the DEVICE option is
loaded into the DDB for the device. If a name is encoutered which
contains all blanks, a null is loaded into the DDB for the device
name. The null replaces the default device name which had been
previously stored in the DDB. When the null is examined later in the
processing the error 'no such device' occurs.
[CURE]
Before storing the device name in the DDB, check to see if it has
been set to null. If it is null, do not store it in order that the
default device name can be used. Edit 2072 to FOROPN accomplishes
this.
********************************************************************************
EDIT 2073 FOR FOROTS
[SYMPTOM]
The following error occurs when trying to BACKSPACE through
a binary file:
"? ILLEGAL INSTRUCTION
? page table does not exist and file not open for write"
[DIAGNOSIS]
When BACKSPACEing thru a file and an attempt is made to go
before the file window one of two things will happen, if the
record we are BACKSPACEing over is split across a page
boundry the window will slip one page (map the previous page
into the file window), or if the record is not split (across
page boundry) then an FOROTS will map the previous window
into core.
However in the case where the window slips one page then
tries to map in the previous window, it may attempt to map
into core page -1.
[CURE]
When BACKSPACEing in a binary files never allow FOROTS to
attempt to map in the previous window. When a BACKSPACE
operation determines that the record to backspace over is
NOT in the file window then always slip the window one page.
********************************************************************************
EDIT 2075 FOR FOROTS
[SYMPTOM]
FOROPN does not compile when building FOROTS with version 4.1 of
GALAXY.
[DIAGNOSIS]
FOROPN searches the module QSRMAC.UNV to define some of its
symbols. However, the QSRMAC supplied with version 4.1 of GALAXY does
not define all the symbols FOROPN is expecting the module to define.
FOROPN is designed to handle both version 2 and version 4.1 of GALAXY,
however, certain symbols are used with version 2 that are not used
with version 4.1. Since the decision as to which version of GALAXY is
to be executed is not determined until runtime, all symbols for both
versions must be defined in order to successfully assemble FOROPN.
[CURE]
Before loading version 4.1 of GALAXY onto the system, copy the
version 2 GALAXY's QSRMAC.UNV to a file named QSRMC2.UNV. Secondly,
apply edit 2075 to FOROPN which changes the search list to search for
QSRMC2.UNV to resolve symbol definitions. These two actions must be
taken in order to build FOROTS no matter which of the GALAXY versions
will be used at runtime.
********************************************************************************
EDIT 2076 FOR FOROTS
[SYMPTOM]
The FUNCT. functions 17 and 20 do not return a -1 (function not
implemented) status code when executed on TOPS-10.
[DIAGNOSIS]
Functions 17 and 20 deal with TOPS-20 PSI channels. When these
functions are executed in a FUNCT. call, a zero status is issued
signifying a successful return. The code for these functions has not
been made conditional for the TOPS-10 and TOPS-20 systems. Since PSI
channels are not implemented in FOROTS on TOPS-10, it is meaningless
to execute the code for these two functions on TOPS-10.
[CURE]
Designate by a conditional that the code for functions 17 and 20
be executed for TOPS-20 only. Set up a second conditional for
execution of these two functions under TOPS-10. In the TOPS-10 code,
set F.GPSI (function 17) and F.RPSI (function 20) to F.ILL. The F.ILL
wil cause a -1 status to be returned.
********************************************************************************
EDIT 2077 FOR FOROTS
[SYMPTOM]
If the OVERFL subroutine encounters an overflow, underflow or
divide check and returns a 1 in IANS, subsequent calls to the routine
will also return a 1 in IANS regardless of whether an overflow,
underflow or divide check has occured since the last call.
[DIAGNOSIS]
In the OVERFL subroutine two tables are used to determine the
value to be returned to IANS. One table contains the current APR
counts. A second table contains the previous counts for the different
types of overflow, underflow or divide check conditions. By comparing
the corresponding values in each table, it can be determined if the
count has increased for any of the conditions since the last call to
OVERFL. However, the table containing the previous counts, OLDCT, was
not being indexed. As a result, all the current APR counts were being
compared with the first value in the OLDCT table. The result of the
incorrect comparisons lead to an incorrect value being returned in
IANS.
[CURE]
Use an index with OLDCT in the comparison loop in order that
corresponding values in each table are compared. Edit 2077 to FORMSC
establishes the index and does the necessary initialization and
incrementing of the index.
********************************************************************************
EDIT 2101 FOR FOROTS
[SYMPTOM]
impossible JSYS errors can occur when memory full.
[DIAGNOSIS]
FOROTS is trying to handle the "?Memory full" error.
The memory full error occurs while in the process of opening
the file and maping the file pages into core memory, however
not enough memory exists. This is where the error handler
takes over its job is to "clean-up" when a fatal error
occurs. One of the things the error handler tries to do is
to close all the files and release the JFNS. Because the
error occured while FOROTS was opening the file, FOROTS does
not recognize the file as being open, but the TOPS-20
monitor does, This is the source of the confusion. The
error handler tries to release the JFN of the file (because
FOROTS thinks it hasn't been open yet) But, the monitor says
the the file is open and takes the error return from the
RLJFN JSYS call. Now FOROTS gets all upset here because it
was never expecting and error here and dies with an
"Impossible JSYS error".
[CURE]
When in routine SETJFN (FOROPN) and the RLJFN fails
check the error code to see it was a "file is not closed"
error (RJFNX1). If it was then do a CLOSF on that JFN and
continue processing.
********************************************************************************
EDIT 2102 FOR FOROTS
[SYMPTOM]
When a program reads a file, repositions the pointer to the
beginning of the file and then attempts a WRITE or ENDFILE, it fails
if the protection on the file does not allow for deletion.
[DIAGNOSIS]
The ANSI standard specifies that the last WRITE or ENDFILE
designate the end of the file. In order to accomplish this, when the
mode is changed from READ to WRITE or ENDFILE, the file is truncated
to the position at which the WRITE or ENDFILE is to be executed.
However, a problem occurs when the pointer has been positioned at the
beginning of the file. On TOPS-10 running version 7.01 there is
currently no way to truncate a file to zero blocks since setting
.RBALC of the LOOKUP, ENTER or RENAME monitor call to zero does not
change the allocation of the file. Therefore, in OSWTCH, to
accomplish the truncation of the file when the pointer is at the
beginning of the file, the original file is deleted and a new, empty
file is created. However, the deletion may fail depending on the
protection code of the file.
[CURE]
Rather than trying to delete the current file, do a .FOWRT FILOP.
to create an empty file. This FILOP. causes any existing file to be
superseded. Edit 2102 accomplishes this.
********************************************************************************
EDIT 2103 FOR FOROTS
[SYMPTOM]
Subroutine time does not return the correct time of day for
european systems (negative time zones).
[DIAGNOSIS]
The code to adjust the internal time for negative time zones
does not work properly.
[CURE]
re-write code to use the TOPS-20 ODTIM JSYS which will
correctly adjust for negative time zones.
********************************************************************************
EDIT 2104 FOR FOROTS
[SYMPTOM]
A bare plus or minus sign, or a string of plus or minus signs, if the
only character(s) passed as input to FORMAT(I), FORMAT(O) or FORMAT(Z)
and immediately followed by a carriage return, will cause an infinite
loop.
[DIAGNOSIS]
At %INTI, %OCTI, and %HEXI respectively for integer, octal or
hexadecimal input, a check is made for valid radix and legal
characters on formatted input. A flag is set if a valid digit is
seen, but a plus or minus sign alone, or string of plus or minus signs
never followed by a digit and followed by a carriage return, sets only
the sign flag; the routines then indefinitely loop expecting a
following series of digits.
[CURE]
Treat sign characters as digits by setting the DGSEEN flag when they
are encountered.
********************************************************************************
EDIT 2105 FOR FOROTS
[SYMPTOM]
When building FOROTS with a KI-MACRO, an EXTEND instruction in
FORTRP causes the build to fail.
[DIAGNOSIS]
In FORTRP an EXTEND instruction is used in SPINST. This area is
not reached when running on a KI-10. However, the area is accessible
during the assembling of FORTRP. Since the KI-MACRO does not include
EXTEND instructions, FORTRP fails to assemble.
[CURE]
Define EXTEND in FORPRM if it has not already been defined. Edit
2105 accomplishes this.
********************************************************************************
EDIT 2106 FOR FOROTS
[SYMPTOM]
No ERR= branch is taken when disk quota is exceeded or the disk is
full. Instead FOROTS traps to the monitor.
[DIAGNOSIS]
Code was not included in the error handler for these conditions.
[CURE]
In choosing an implementation for this capability, the synchronous
method of placing ERJMPs after instructions likely to cause the error
was rejected as imposing an unacceptable performance degradation on
I/O operations, particularly in the main disk output loop, which does
byte I/O to the output buffer. Instead, a user-assignable PSI channel
has been activated (and can be overriden by the user) with an
associated service routine. This routine checks whether an ERR branch
has been supplied by the user and whether the job is interactive or
batch. If an ERR= has been specified, control is passed to the error
branch specified. If no ERR= is specified, a fatal diagnostic is
issued (if batch) together (if interactive) with an "EXPUNGE and
CONTINUE" message.
********************************************************************************
EDIT 2107 FOR FOROTS
[SYMPTOM]
FOROTS will leave unused pages in a disk file after the EOF
mark.
[DIAGNOSIS]
This can occur when writing to a file, rewinding the file
and then re-writing to the file. If when re-writing the
file less than the previous number of records are written,
the file can have extraenous pages at the end of the file.
[CURE]
When closing the disk file change the code to pass the
correct JFN to the loop which un-maps unused disk pages.
********************************************************************************
EDIT 2110 FOR FOROTS
[SYMPTOM]
When and operation performed on a COMPLEX number traps, an
ILLEGAL MEMORY REFERENCE error results.
[DIAGNOSIS]
When an operation on a COMPLEX number traps, FORERR is called.
The GETPCN routine in FORERR checks through the stack to find where
the error occured. Several tests are made on the stack contents and
the addresses pointed to by the contents. One check invloves looking
at the argument list. However, when a COMPLEX number is used a call
is made to a subroutine to handle COMPLEX numbers. This call has all
the characteristics of other subroutine calls except it does not use
accumulator 16 to contain an address of an argument. As a result,
when the argument lis check is made, an instruction expecting an
address fails with an Illegal Memory Reference.
[CURE]
Before executing the check on the argument list, check to see if
the call was made to one of the COMPLEX number subroutines. If a
COMPLEX number was used, skip the additional checks. This is
accomplished by Edit 2110.
********************************************************************************
EDIT 2111 FOR FOROTS
[SYMPTOM]
Edit 2034 appears to contain errors.
[DIAGNOSIS]
Edit 2034 (as published in the 15-Mar-82 dispatch) does a
comparison (bounds check) using the wrong accumulator and
there is a call to routine LSFREE doesn't have an error
return.
[CURE]
Change code to compare to the propper accumulator and add an
error return after call to LSFREE.
********************************************************************************
EDIT 2112 FOR FOROTS
[SYMPTOM]
CLOSE with DISPOSE='RENAME' will not rename a file to a different
directory or SFD on TOPS10.
[DIAGNOSIS]
When a file is to be renamed before being closed, CLREN in FOROPN sets
up a RENAME block in the new DDB for the renamed file and executes a
rename FILOP. call. It never sets up the path pointer block,
however, so files cannot be renamed across SFDs, directories.
[CURE]
Set up the path pointer block in the new DDB via edit 2112.
********************************************************************************
EDIT 2113 FOR FOROTS
[SYMPTOM]
Edit 2063 corrects one case of junk being output on TOPS-10 with
"Incompatible attributes" error message, but broke many other cases.
[DIAGNOSIS]
Edit 2063 incorrectly assumes all calls to error message IOERR
ISW,30,506 will pass ASCIZ strings, whereas most pass SIXBIT.
[CURE]
Remove edit 2063.
********************************************************************************
EDIT 2114 FOR FOROTS
[SYMPTOM]
Unnecessary instruction in Edit 2034.
[DIAGNOSIS]
T1 is being setup twice with .JBSYM, unnecessarily.
[CURE]
Remove the extra instruction.
********************************************************************************
EDIT 2115 FOR FOROTS
[SYMPTOM]
When the DEVICE option is used in the OPEN statement and is set
to a literal of blanks, the error message 'no such device' is
returned.
[DIAGNOSIS]
In the OPNDEV routine, the name given in the DEVICE option is
loaded into the DDB for the device. If a name is encoutered which
contains all blanks, a null is loaded into the DDB for the device
name. The null replaces the default device name which had been
previously stored in the DDB. When the null is examined later in the
processing the error 'no such device' occurs.
Also, on TOPS-20, the ATMBUF where the device name is temporarily
stored is not cleared before entering the loop which loads in the
device name. If a previous OPEN statement stated a device name, then
a subsequent OPEN statement with a blank device name will produce the
'no such device' error message.
[CURE]
First, clear the ATMBUF before getting the device name.
Secondly, before storing the device name in the DDB, check to see if
it has been set to null. If it is null, do not store it in order that
the default device name can be used. Finally remove one occurrence of
the duplicated instruction, TXO F,F%DSS. Edit 2115 to FOROPN
accomplishes these steps. Also, edit 2115 supersedes edit 2072. If
edit 2072 has already been installed it should be removed before
installing edit 2115.
********************************************************************************
EDIT 2116 FOR FOROTS
[SYMPTOM]
Certain very long I/O lists will cause a "?Forots internal error in
memory management" error when executed.
[DIAGNOSIS]
Some I/O lists with many elements, at least one of which is repeated,
may cause the compiler to generate two separate calls to IOLST. in
FOROTS to process the same I/O list. IOLST then calls the argument
copier by means of %ISAVE; if the first of the two calls passes an
argument count in excess of 200 (octal), TOOMNY is called to allocate
a larger block for the arglist transfer. Upon completion of the
arglist processing, the larger block is deallocated, but the CPYBLK
pointer to that block is not cleared, which causes the next call to
IOLST to attempt to deallocate a non-existent block.
[CURE]
Ensure that the CPYBLK pointer is always cleared when the argument
copier is called by means of %ISAVE.
********************************************************************************
EDIT 2117 FOR FOROTS
[SYMPTOM]
The FORLIB function EXP will loop when repeatedly called
with an argument of 0.0.
[DIAGNOSIS]
This problem is reproducible only on a KS10 processor
running under the TOPS-10 monitor. The loop occurs in the
FOROTS internal trapping routine while trapping for
arithmetic overflows. The actual problem is that if the
trapping is using the UTRP. monitor call somehow the wrong
address of the the instruction causing the trap is stored
into the trap routine thus, it will not return to the proper
location in the EXP function but will loop in the trap
routine.
[CURE]
Check to see if the processor is a KS10 processor. If it is
then use APR trapping instead of UTRP.. This will avoid the
problems in UTRP.
********************************************************************************
EDIT 2120 FOR FOROTS
[SYMPTOM]
With Edit 2056 installed, newly-created RANDOM files on TOPS10 can
contain garbaged records (missing LSCWs) with RECORDSIZE larger than a
block, but most noticeably with RECORDSIZE larger than approximately
1950 (decimal).
[DIAGNOSIS]
Edit 2056 was designed (among other things) to ensure that the last
block of a TOPS10 RANDOM file is not padded to the block boundary, as
was happening previous to that edit. In order to detect when the last
block (page) of the file is about to be written, EOFN(D) is relied
upon in WRTPG to provide the last byte/word number actually written in
the file; it is then compared with the total words written as
calculated by block number and, if smaller, the last block is
truncated at actual data termination upon output. Unfortunately,
EOFN(D) was being updated only at the end of each record; for records
spanning many pages, this caused a timing-skew in the truncation
calculation which, given the right size of the record with respect to
window size, could result in garbage being output. Output performed
to an already-existing file was successful because in such a case
EOFN(D) is initially derived from the file LOOKUP and thus represents
an initially true end-of-file marker.
[CURE]
If performing output, update EOFN(D) both at end-of-record time and
when a page is written to the file, at which time BYTN(D) can be used
to update EOFN(D).
********************************************************************************
EDIT 2121 FOR FOROTS
[SYMPTOM]
When a program calls SORT and also requires memory above 600000,
SORT is overwritten and execution of the program results in an
'?Illegal Instruction' error. Secondly, on TOPS-20, if a program
which calls SORT is restarted with a START command an '?Illegal
Instruction' error results.
[DIAGNOSIS]
On TOPS-20, SORT.EXE is brought into memory by a GET instruction
and on TOPS-10 by a MERGE instruction. On both systems SORT.EXE is
loaded between 600000 and 677000. However, on neither system is the
FOROTS memory management table updated to reflect that the pages are
now in use. As a result, when memory is no longer available in the
low segment and FOROTS starts allocating space above 600000, the pages
being used by SORT are overwritten and the error results.
The second problem which involves the program being reentered
with a START command happens only on TOPS-20. On TOPS-20, once SORT
is loaded into memory it remains there until the end of the program.
The address of SORT is loaded into a location which is used when
additional calls are made to SORT. However, before the program exits,
SORT is released but the location containing the address is not
cleared. As a result, when the program is reentered and a call to
SORT is made, it checks the location, finds an address in it, jumps to
that address and the error message results. This problem does not
occur on TOPS-10 as SORT is released after each call and MERGEd in
again if additional calls are made to SORT.
[CURE]
The first problem is corrected by marking and (on TOPS-10 only)
unmarking the pages in the FOROTS memory management table when SORT is
loaded and released. The marking of pages is done by a FUNCT. call
which checks to see if all the pages being requested are free and if
so marks them as in use. The unmarking is done by a second FUNCT.
call which checks to see if all the requested pages have been marked
and if so marks them as free.
The second problem is solved by clearing SRTADR+1, the location
containing the address where SORT is loaded. The clearing is done at
RESET., which required moving the definition of SRTADR from FORSRT to
FORINI.
********************************************************************************
EDIT 2122 FOR FOROTS
[SYMPTOM]
An ESCAPE, typed while FOROTS is accepting input from the TTY on
TOPS10, functions as a break character but cannot be deleted by DELETE
or ^U, must be followed by CRLF to terminate the line, yet
nevertheless is passed through to the input record buffer, where it
may cause "?FRSILC Illegal character in data."
[DIAGNOSIS]
In checking for end-of-line and end-of-file characters on input, FORIO
does not distinguish between ESCAPE and other non-special characters,
despite the fact that SCNSER has already treated the ESCAPE as a break
character. Instead, ESCAPE is passed without special action into the
input record buffer.
[CURE]
Add TOPS10 conditional code to check for ESCAPE if the device is a
TTY. If so, simulate a carriage-return/linefeed on the terminal and
discard the ESCAPE on input.
********************************************************************************
EDIT 2123 FOR FOROTS
[SYMPTOM]
When a file whose mode is implied to be binary is appended to,
the following error results:
?Address check for device , UUO at user PC
[DIAGNOSIS]
If the mode and form are not stated in the OPEN statement, they
are determined when the first data transfer occurs. Until they are
determined, the default form is formatted. When appending to a file
the ICNT and OCNT values are used to determine where the next data
should be written and how much space is left in the buffer. However,
since the default form is formatted, the ICNT and OCNT values reflect
character counts rather than word counts. As a result, using these
values caused the data to be written beyond the buffer and an address
check to result.
[CURE]
If determination of the form is done at the time of the first
data transfer and needs to be changed to unformatted, also, change the
ICNT and OCNT values to reflect word counts. Edit 2123 accomplishes
this.
********************************************************************************
EDIT 2124 FOR FOROTS
[SYMPTOM]
FRSISW (Incompatible attributes) errors on TOPS10 can output garbage
for keyword strings and values. If Edit 2063 is installed, some ISW
calls are fixed, but others are broken.
[DIAGNOSIS]
ISW calls to the error handler are setup to expect pointers to SIXBIT
strings (mainly derived from the keyword table) as arguments. In some
instances, TOPS10 processing incorrectly passes a pointer to an ASCIZ
string, which is then "converted" by a 6-to-7 bit translation routine
into garbage and output as part of the error message. Edit 2063
addressed the class of cases comprising STATUS=SCRATCH/STATUS=KEEP
incompatibilities by changing the error macro to expect ASCIZ strings
always; this broke other cases.
[CURE]
Make sure that all ISW calls to the error handler pass SIXBIT strings
on TOPS10. This edit supersedes edit 2063.
********************************************************************************
EDIT 2125 FOR FOROTS
[SYMPTOM]
Edit 2102 does not include an instruction for the error return of
the FILOP. call in OSWCRE.
[DIAGNOSIS]
When the FILOP. in OSWCRE, for closing the file, returns
successfully, the instruction to set the .RBALC to zero is skipped.
Since .RBALC is not zeroed, the blocks are not deallocated when the
next FILOP., which supersedes the file, is executed.
[CURE]
Include an instruction for the error return of the FILOP. call.
Edit 2125 accomplishes this. Edit 2125 and edit 2102 should be
applied together.
********************************************************************************
EDIT 2126 FOR FOROTS
[SYMPTOM]
FOROTS version 6 magtape processing incompatible with
version 5 and current documentation.
[DIAGNOSIS]
FOROTS, when reading an industry mode or ansi-ascii mode
magtape will use a byte size of 36.
[CURE]
Change the byte size depending on the mode of the tape
(either ansi-ascii, system default or industry compatible).
********************************************************************************
EDIT 2127 FOR FOROTS
[SYMPTOM]
FORTRAN dies with an illegal memory reference error when
using an error handling subroutine. If the user program
traps for I/O errors (using the ERRSET function) and in its
error handling subroutine it attempts to do more I/O the
program will get an "ill mem ref" error.
[DIAGNOSIS]
When the interrupt routine (HELP) executes an I/O statement,
IOLST gets called which smashes all the temporary variables
from the original I/O statement. When the error handling
returns to the originating I/O statement to continue the I/O
all of its temporary variables are wrong finally causing the
Ill Mem Ref.
[CURE]
When performing an interupt of an I/O operation any
subsequent I/O operation of the same type will make it
impossible to return to the I/O in progress. This is a
RESTRICTION in FORTRAN-10/20.
The following patch (2127) will cause a fatal error message
when a user program attempts this.
********************************************************************************
EDIT 2130 FOR FOROTS
[SYMPTOM]
Large TOPS10 random files written with Edits 2056 and 2120 installed
may contain intermediate truncated records; a subsequent READ of the
same file produces errors.
[DIAGNOSIS]
Edit 2120 unconditionally updated EOFN(D) with BYTN(D) when doing
Random output.
[CURE]
Check that BYTN(D) is in fact larger than EOFN(D) before updating.
********************************************************************************
EDIT 1145 FOR FORTRA
[SYMPTOM]
In certain circumstances, the compiler will generate
bad code for a complex arithmetic statement that contains
some number of function calls. This will happen most
frequently when the predominent mode of the statement is
double precision or complex.
[DIAGNOSIS]
During register usage complexity analysis, the
existence of the various function calls causes the function
return registers (0 and 1) to be selected as the primary
computation registers for numerous nodes in the statement.
However, when time comes to actually allocate the registers,
the allocator may determine that some computations will have
to be made to memory instead of ACs. When this decision is
made, the flag for memory computation is turned on, but
flags indicating that the value will be returned in a
register are not turned off. Also, if the node that had to
be computed to memory is the one that is usually loaded into
an AC for a later computation, the node doing that later
computation may still believe the result is in an AC. In
both cases, the code generator will incorrectly treat the
result as if it still lives in some AC.
[CURE]
When a value must be computed to memory, guarantee that
any previous decisions made to return it in an AC are
negated. Also, make sure that the parent does not still
believe that the result is in an AC.
********************************************************************************
EDIT 1146 FOR FORTRA
[SYMPTOM]
The following program segment:
DIMENSION B(3)
EQUIVALENCE (D,B(3))
EQUIVALENCE (A,B(2))
EQUIVALENCE (A,B(1))
reports an inconsistent equivalence declaration for line 2,
when it should report it for line 4.
[DIAGNOSIS]
The error is detected when scanning the equivalence
group defined at line 2, in conjunction with all the other
equivalence groups, in order to determine disjoint sets of
variables 'defined' to be the same. Since array B appears
in all three groups, all of them are scanned, and the
conflicting assignment is found when variable A is declared
as equivalent two two different elements of array B.
[CURE]
Report the actaul equivalence group in which the error
occured, not just the first group used in the scan.
********************************************************************************
EDIT 1147 FOR FORTRA
[SYMPTOM]
Ending a FORTRAN program unit with an end-of-file
instead of an END statement (for instance RETURN^Z) can
produce an internal compiler error.
[DIAGNOSIS]
Edit 1066 removed the LINE:nnnnn prefix from certain
error messages, for which it is not pertinent. It did this
by passing a zero as the line number value, so that the
print routines would recognize the situation. However it
did not take into account the error message buffering that
occurs during the lexical analysis phase, whenever the
lexical line number and the error line number are the same.
In this case, this was no longer true, causing the error to
print before the 'offending' statement, and also causing the
internal error, when the statement print routines went
searching into non-existent memory for a line terminator
that is required to terminate text sequences when an error
has occured.
[CURE]
Make the lexical line number and the error line number
agree, so that normal error message buffering will occur,
the error statement will appear first, and the error
message(s) last.
********************************************************************************
EDIT 1150 FOR FORTRA
[SYMPTOM]
Incorrect error message "Illegal transfer into DO loop"
when optimizing a program containing ASSIGN statements.
[DIAGNOSIS]
Work was done during the version 6 development to
attempt to detect some of the cases where the user has
erroneously jumped into a DO loop from outside the loop.
Due to the implementation which involves the comparison of
local and global label counts, as ASSIGN statement can cause
problems; it is treated as if it could have been a jump to
the label being ASSIGNed to. Therefore, legitimate programs
which have ASSIGN statements outside of DO loops with actual
GO TO statements inside the loop to labels within the loop
may generate incorrect error messages of the form "Illegal
transfer into DO loop". Unfortunately, this case is very
difficult to handle using the current algorithm.
[CURE]
Whenever an ASSIGN statement occurs, mark the label as
having been ASSIGNed to in the label table. If we are about
to report the fatal error, check to see if the label has
been ASSIGNed to, and if so, do not consider this case an
error. This has a side effect of not detecting jumps into
DO loops if the particular label has been used in an ASSIGN
statement - unfortunately, this cannot be corrected without
substantial changes to the algorithm. This is similar to
the cases where the DO loop has a transfer out, when
"incorrect" transfers into the loop cannot be detected
either (extended range possibilities).
********************************************************************************
EDIT 1151 FOR FORTRA
[SYMPTOM]
The compiler does not detect the fact that the COMMON
area has exceed 512P.
[DIAGNOSIS]
The calculated size of each COMMON block is stored in a
halfword, resulting in a size always less that 2**18. There
is no code to check for any particular COMMON block, or
COMMON in general exceeding the current maximum core image
size of 512P.
[CURE]
When making the first pass over the COMMON blocks to
assign offset addresses and calculate size, check the size
of all the COMMON areas. If it is 512P or over, produce the
fatal error '?FTLPTL Program too large'. Do not increase
the allowable size of a COMMON block, since we currently
cannot support over 512P.
********************************************************************************
EDIT 1152 FOR FORTRA
[SYMPTOM]
The Optimizer produces bad code for certain cases of
programs involving DO loops which contain OPEN/CLOSE
statements, having parameters which reference the DO loop
index as a subscript. An example is:
DIMENSION K(10)
DO 10 I=1,2
OPEN(UNIT=20,FILE=K(I))
DO 11 J=1,1
11 CONTINUE
10 CONTINUE
END
[DIAGNOSIS]
During global register allocation for certain classes
of DO loop segments, the optimizer will check to see if the
DO loop index that has been assigned to a register is used
only once inside the loop (as the loop index). If this is
the case, the loop variable will never be updated with the
value from the register, since the variable is not actually
used. At present, only the UNIT specifier is being checked
for OPEN/CLOSE statements, allowing usages of the loop index
in subscripts of other parameters to remain undetected.
This prevents register substituion for the loop variable,
gets the occurance count wrong, and generates bad code in
such cases.
[CURE]
Check all OPEN/CLOSE parameters for occurances of the
variables to be globally allocated to registers. Perform
register substituion as necessary.
********************************************************************************
EDIT 1153 FOR FORTRA
[SYMPTOM]
Programs containing large numbers of READ/WRITE
statements that used to compile with previous versions run
out of memory with version 6.
[DIAGNOSIS]
The syntax analyzer produces various lists for the
semantics routines to digest and extract information from.
Once the necessary information has been obtained, the list
pieces can be discarded. When edit 760 re-wrote the I/O
semantics routines, a substantial amount of the calls to
free up the list item space disappeared. There were also
some list items that were not being freed up by any version
of the compiler.
[CURE]
Free up the list items once they are no longer of any
use. Prevent one case of freeing up an item in the wrong
order. This edit can produce dramatic changes in memory
utilization. For the example supplied, an additional 32K of
memory was made available to the compile.
********************************************************************************
EDIT 1154 FOR FORTRA
[SYMPTOM]
Bad code is generated for expressions such as:
I=-(.NOT.(J.OR."7777))
[DIAGNOSIS]
The skeleton optimization routines determine that the
unary negation can not be pushed past the NOT down into the
expression, so they push the negation up to the assignment
node. A later check to see if the computation can be
performed to memory ignores the negation in the top node,
and the compute to memory flags get set. The code generator
is driven by the compute to memory flag in the expression
node and the top level node, and ignores the negation.
[CURE]
If a negation or NOT has been pushed up into the
assignment node, do not target the computation to memory.
Appropriate code will be generated to handle the
negation/NOT to memory when moving the calculation from an
AC to memory.
********************************************************************************
EDIT 1155 FOR FORTRA
[SYMPTOM]
The compiler gives up to quickly when processing
declaration statements for semantics errors. Once an error
is found, the remaining declarations, which might contain
additional errors, are ignored. This makes error correction
tedious.
[DIAGNOSIS]
The semantics routine which processes the various
declaration items stops when it encounters the first error,
and passes an error status back to the caller. The higher
level routines merely move on to the next statement.
[CURE]
Defer returning the error status until all declaration
items in the current list have been processed. This will
tend to produce more declaration error messages (most of
which will be useful), and fewer 'not dimensioned' error
messages.
********************************************************************************
EDIT 1156 FOR FORTRA
[SYMPTOM]
Version 6 compiler cannot compile as large a complex
expression as previous versions. A common symptom is a
stack overflow.
[DIAGNOSIS]
An additional local was added to a highly recursive
expression analyzer routine by edit 1004. Normally this
would merely mean that a less complex expression could be
handled. However the code that makes a check of the
remaining stack size to make sure it has enough room to
print a reasonable error message was not synonomously
updated. Consequently, the error routine frequently
overflows the stack.
[CURE]
Change the local to a module OWN, and eliminate the
problem altogether.
********************************************************************************
EDIT 1157 FOR FORTRA
[SYMPTOM]
The compiler diagnostic
%FTNMVC Line:nnnnn Number of variables does not equal the number
of constants in DATA statement
Is less helpful than it might be.
[DIAGNOSIS]
No attempt is made to specifiy just which list ended
first.
[CURE]
Clarify the message by replacing the constant phrase
'does not equal' with the phrase 'is less than' or 'is
greater than' for the respective condition.
********************************************************************************
EDIT 1160 FOR FORTRA
[SYMPTOM]
If a compile produces fatal errors, a .REL file may
still be produced, in which case it will contain only those
routines for which no fatal errors existed. Also, on the
20, a bogus .REL file will be produced when syntax only has
been requested.
[DIGNOSIS]
Edit 752 attempted to discard the .REL file if fatal
errors occured. However it checked a flag that was reset
for each program unit, and if the last routine contained no
errors, the .REL file was kept. For the syntax only
problem, no check is made on the 20.
[CURE]
Create a flag which is global to all program units in a
compile command, set it of any fatal errors have been
produced for any program unit, and use it to decide if the
.REL file need be discarded. Also add a check for syntax
only in the 20 code.
********************************************************************************
EDIT 1161 FOR FORTRA
[SYMPTOM]
The optimizer can produce bad code for assignments
dealing with variables that have recently been replaced by
other variables which have been allocated to live in
registers. Assume that A has been globally targetted for a
register for the following code segment:
T=A
A=X*A-Y+Z
O=T
The assignment to O will use the value in the register for
A, which is believed to still contain the value recently
stored into T.
[DIAGNOSIS]
During global register allocation, variables that are
used heavily during a code segment will be assigned to
registers for the duration of that segment. For assignments
involving variables allocated to registers, a special check
is made to determine if the variable also appears on the
right hand of the assignment, such that the computation can
be done directly to the assigned register. If the variable
does appear, but is nested too deeply to reliably do the
optimal targeting, a new register is allocated for the
computation, and the result is moved into the register
assigned to the variable. When this case occurs, the
optimizer forgets to note that the pertinent register has
been modified. If a recent assignment to some other
variable has occured from the register in question (T in the
example), the optimizer will use the register instead of the
other variable in later assigments involving the other
variable on the right hand side (O=T in the example).
[CURE]
If the computation optimization check fails, make sure
that the register table entry, with all associated
variables, is invalidated.
********************************************************************************
EDIT 1162 FOR FORTRA
[SYMPTOM]
Typing in FORTRAN program from a terminal directly to
the compiler can cause one of several internal compiler
errors under TOPS-20. Terminal input is read with an
obsolete JSYS. No CRLF is typed after the ^Z.
[DIAGNOSIS]
Terminal input is handled seperately under TOPS-20. ^Z
is detected as end of file by LEXICAL, which returns
ENDOFILE. If the ^Z is the character typed, LEXICAL will
return ENDOFILE to MRP1, which expects EOF. Buffers may be
allocated from memory which is not cleared. If a terminal
input buffer word has the least significant bit set, it may
be misinterperated as a line sequence number. The free list
pointers are not cleared before the first call to LEXICAL,
so if that call generates an error CORMAN may attempt to
allocate memory above .JBREL.
[CURE]
Change EOPRESTORE to check for ENDOFILE from LEXINI and
return EOF if so. Make MRP1 zero the free list and between
.JBREL and .JBFF before starting compilation of a file. Add
a routine to type a CRLF after ^Z.
********************************************************************************
EDIT 1163 FOR FORTRA
[SYMPTOM]
Subprogram function values are unavailable to FORDDT unless assigned
to another variable before return.
[DIAGNOSIS]
Even under /DEBUG conditions FNVALCHK in DOALC checks whether a
function value assigment is immediately followed by RETURN; if this
is true, a reg contents node (reg 0) is substituted for the function
variable node, and the value is merely passed back in 0 and never
stored.
[CURE]
If /DEBUG:INDEX is specified, bypass the optimization at FNVALCHK so
the function value is always stored.
********************************************************************************
EDIT 1164 FOR FORTRA
[SYMPTOM]
Certain programs containing extended ranges (branches
in and out of DO loops) can send the optimizer looping in
(the) SWAMP. The loop only occurs for a small class of
programs, usually those that have multiple paths of logic
flow, of which the following is an example:
INTEGER M(10,3)
DO 10 J=1,3
IF (J.EQ.2) GO TO 10
DO 20 K=1,3
GO TO 30
20 CONTINUE
30 IF (M(I,J).EQ.3) GO TO 20
10 CONTINUE
END
It is also possible that a loop will not occur for such
programs, however the potential exists for bad code to be
generated.
[DIAGNOSIS]
During optimization, the entire program is treated as
one gigantic DO loop, and analysis proceeds from the inner
DOs to the outermost one. The inital step is to graph the
flow of control in a particular loop, including exits and
entrances to and from outer loops (extended ranges).
Transfers to and from interior loops are designed to be
treated merely as branches to and from the inner DO itself.
Once each loop is processed, it is 'collapsed' into two
cross-linked nodes, the DO node and a unique DO terminus
node (commonly a CONTINUE). Following graphing, definition
points are determined based on the flow information
provided.
For the above program, the inner DO 20 loop is processed
first. Local labels are collected, and exits are collected
concurent with the graphing process. It is correctly
determined that the inner loop has an exit (to 30) and an
entrance (to 20).
The inner loop is then collapsed, and the outer DO 10 loop
is processed. Again local labels are collected, and at the
same time, all labels in the inner loop are 'pointed' at the
outer loop for interior do loop entrance checking. Graphing
and exit collection occur correctly until the IF statement
that branchs back into the inner loop is encountered. At
that point, the fact that the inner do loop label points to
the outer loop produces the incorrect decision that the
branch is an exit, and the graph pointers get setup such
that the outer DO is both its own successor and predecessor.
Code originally setup to detect this condition and produce
the FTNIDN diagnostic was removed by edit 1125, since the
condition mentioned is now detected in another fashion.
Once the graphing completes, it is not long before the
definition point routine SWAMP enters the loop trying to
move past the badly graphed outer DO 10 loop.
[CURE]
Move the code that walks inner DO loops and points
interior labels to the outer DO from the start of the
graphing process (in MAKLLL) to the end (DOCOLLAPSE) where
it belongs (and where the comments indicate is should be).
With this change in place, branches to interior loops are
correctly detected and the graphing is correctly
accomplished. Optimization will now occur for such cases
for the first time.
********************************************************************************
EDIT 1165 FOR FORTRA
[SYMPTOM]
Execution errors due to bad code generated. Program jumps to register
zero and can get a variety of errors depending on what the register
contains.
[DIAGNOSIS]
A JUMPL 0 and strange looking labels are generated for output.
Below is a case that fails with /DEBUG:LABELS (although some examples
may fail without /DEBUG:LABELS):
LOGICAL ONLINE
ONLINE(X,Y)=X.EQ.Y !Returns true
IF (.NOT. ONLINE(XT, TT)) KTNEW = KTNEW + 1
GOTO 20020
KTNEW = KTNEW + 1
20020 X = Y+1
END
In testing the conditional for the IF statement, a JUMPL 0 is executed
and an illegal instruction error results.
[CURE]
Correct 2nd argument passed to routine ADDLAB in PEEPOP.BLI.
********************************************************************************
END OF FORTRAN-20