diff options
| author | Joe Hunkeler <jhunkeler@gmail.com> | 2015-08-11 16:51:37 -0400 |
|---|---|---|
| committer | Joe Hunkeler <jhunkeler@gmail.com> | 2015-08-11 16:51:37 -0400 |
| commit | 40e5a5811c6ffce9b0974e93cdd927cbcf60c157 (patch) | |
| tree | 4464880c571602d54f6ae114729bf62a89518057 /doc/ports | |
| download | iraf-osx-40e5a5811c6ffce9b0974e93cdd927cbcf60c157.tar.gz | |
Repatch (from linux) of OSX IRAF
Diffstat (limited to 'doc/ports')
33 files changed, 15403 insertions, 0 deletions
diff --git a/doc/ports/README b/doc/ports/README new file mode 100644 index 00000000..7e077261 --- /dev/null +++ b/doc/ports/README @@ -0,0 +1,23 @@ +This directory contains notes on the various IRAF ports. Most of these +files do not contain an up-to-date record of the current ports, but rather +these are historical notes taken during each port. The name of the host +operating system is contained in each filename, while most files contain +the relevant dates of ports or upgrades inside them. Some of this material +may be of use to persons contemplating future ports. + +Conventions: + + aos AOSVS (Data General MV/10000) + ctio Cerro Tololo Interamerican Observatory + isi Integrated Systems; Jupiter workstation at IPAC + nso National Solar Observatory + st Space Telescope Science Institute + sun Sun Microsystems + sun2 SUN-2 hardware, SUN V2.0 + sun3 SUN-3 hardware, SUN V3.0 + v22 IRAF V2.2 (etc.) + +Where different files would otherwise have the same name, they are +distinguished by the date of the last modification to the system that +was part of the original "notes" file. For example, "sun3_062486.doc" +is the "notes" file as it existed on a Sun-3 on June 24, 1986. diff --git a/doc/ports/alliant_86.doc b/doc/ports/alliant_86.doc new file mode 100644 index 00000000..9b372493 --- /dev/null +++ b/doc/ports/alliant_86.doc @@ -0,0 +1,589 @@ +Notes on the port of IRAF V2.3+ to the Alliant FX vector workstation, +beginning 25 August 1986 (dct). This is a continuation of a port started +by Dennis Crabtree on 12 August, with some of the problems found then being +fixed before the bootstrap or sysgen in this port. +--------------------------------------------------------------------------- + +Read tape onto VAX 780 using IRAF `reblock' task. Worked great, except + that I allocated the drive in vms before running IRAF: this caused + the IRAF allocate to fail, causing a read error on the first + attempt to run reblock (confusing). (8/25) + +Copied archive to the Alliant via the ethernet which runs the Excelan + network software. The first attempt to unpack the archive on the + Alliant failed with a checksum error message from tar; this turned + out to be due to not specifying a binary transfer in TELNET before + copying the file (a newline was being inserted after every 512 + bytes). After retransmission to fix this, unpacked everything + successfully at /u2/iraf. (8/25) + +Notes - + There is a bug in the Excelan network software that causes it to + hang up the terminal if too many characters are transmitted, + forcing one to login on another terminal and STOP the process. + + The Alliant died on a kernel panic (mfree failure) during one + of these network crashes and had to be rebooted. Another time + it hung up in a hard loop when tyring to delete the large archive + file (bad disk block?) and had to be rebooted. + + DAO uses Plessey PT-100G graphics terminals. These have an awful + keyboard with keybounce and keylost problems. A screen redraw takes + 3 seconds. The screen color is orange - not as bright as amber, + green, or white. Other than that they seem fine - have not tried out + the graphics yet. (8/25) + + Tried the graphics finally, on VMS/IRAF. The graphics resolution is + good (480x1000?) and vector drawing is fast. Hardware cursor setting + is better than on the vt640 (shift and ctrl as used as accelerators, + and 45 degree motions are supported), but unfortunately there is no + software write cursor function, so the HJKL and other cursor write + features (as in in a zoom) do not work. The alpha and graphics + memories are separate and can be displayed together, as on the vt640. + + The main problems of this terminal are the keyboard, slow screen + redraw, and lack of a software write cursor function (but it is + better than a vt240!). (8/30) + +local/.login + Set up the .login for the new system. (8/25) + +Notes - + Tried using the vms COPY to copy the tar file to disk, to see if + that would work. COPY produced a variable length, 10240 byte max + record length, carriage control etc. file as output, i.e., a text + file. This explains why the initial attempt to read the tar tape + failed. Probably the best way to distribute tar archives to VMS + sites is by making a BACKUP tape of a disk tar file. This avoids + this type of confusion, and also gains access to the error recovery + provided by BACKUP. (8/26) + +/usr/include/iraf.h +/usr/bin/cl,mkiraf,etc. + Changed to point to /u2/. (8/26) + +unix/hlib/[dir]mach.f + Commented out pdp-11 entries and uncommented IEEE entries. In two of + the files, commented out the call to ILIBER; I don't think we want + that (should be fixed on Lyra). (8/26) + +unix/hlib/iraf.h +unix/hlib/mach.h + Changed the values of epsilonr, epsilond to the IEEE values. Set the + byte swap flags to NO. (8/26) + +unix/hlib/iraf.h + Set defines for and,or,xor to iand,ior,ieor. Not is not. (8/26) + +unix/hlib/mkiraf.csh + Changed iraf root directory to /u2/iraf. (8/26) + +unix/hlib/mkpkg.inc + Set siteid to `dao', turned off ncar, calcomp kernels. XC flags will + probably also have to be changed, but leave that for later. (8/26) + +unix/as/zsvjmp.s +unix/hlib/config.h +unix/hlib/libc/spp.h + Wrote the ZSVJMP/ZDOJMP for the Alliant (as$zsvjmp.s), and set the + jump buffer size parameters in config.h and spp.h. The current routine + saves the exception mask and all the floating point and vector + registers as well as the 68000 registers, which is more than is really + necessary. (8/26) + +unix/os/zgtime.c +unix/os/gmttolst.c +unix/boot/bootlib/ostime.c + From looking at Dennis's notes I see that time.h is in <sys/time.h> + rather than <time.h> on the Alliant. In fact it is referenced both + ways in the VAX/UNIX kernel, so I changed all references to + <sys/time.h>, don't know what the official answer to this one is. + Removed the link (added by Dennis) in /usr/include. (8/26) + +unix/hlib/libc/iraf.h +unix/os/zxwhen.c + In iraf.h, added a #define ALLIANT for use in HSI code. In zxwhen, + replaced the array of vax exceptions by an #ifdef-ed array of + alliant specific hardware exceptions (hwx_). (8/26) + +unix/os/zxwhen.c + The Alliant C compiler produced a syntax error for the declaration + for the pointer to function `vector'. Presumably this was due to + vector being a reserved keyword to the Alliant C compiler; changed + the name to `vvector' and it compiled. (8/26) + +unix/boot/spp/xc.c + Replaced f77 by the Alliant task `fortran' (the Alliant Fortran + compiler) to compile Fortran files. Modified to use cc rather + than f77 to compile all other files. Modified to add the .f + files produced from .x sources to the Fortran file list, rather + than the general source file list input to the C compiler (formerly + these files were processed by f77, which can compile anything). + Parameterized the names of the fortran compiler, the C compiler, + and the linker. Deleted the "-u" flag, which is not supported on + the Alliant. Changed the Fortran library name from `-lF77' to + `-lfortran'. (8/26) + + In the long run, XC needs to be rewritten to be more portable, + like mkpkg. This is still the original unix compiler, which was + never intended to be ported. + +unix/boot/spp/rpp/ratlibf/Makefile +unix/boot/spp/rpp/rppfor/Makefile + Modified to call `fortran' rather than `f77'. (8/26) + +--------------------------- +(first attempt to bootstrap) + +unix/os/zfiomt.c + C compiler error. The declaration of the automatic array in + the skip record forward function, i.e., + + char buf[32768]; + + caused the fatal error `too many local variables' from the + C compiler. I reduced the size to [28800]. Recall that this + used to be a small buffer, but I had to make it larger than the + maximum tape block size to avoid i/o errors on the SUNs. Use + of malloc is undesirable since skip record forward might be + called many times in a loop. In any case, this is an indication + that the Alliant C compiler has limited symbol table storage and + may have problems with large programs or modules. (8/27) + +Note on Alliant Fortran compiler (task `fortran'). + The compiler cannot handle a "-cO" flag on the command line. + The "-O" must be given as a separate flag. (8/27) + +unix/boot/spp/rpp/ratlibf/dsfree.f + On line 20, the hollerith string contained a tab instead of a space, + causing the line length to exceed 20 characters. (8/27) + +unix/boot/bootlib/mkpkg.csh + The executable nature of this .csh is a nusiance; a different way + should be found to do this. (8/27) + +unix/hlib/mkpkg.inc + Changed the default compile flags to "-c -Ovg -AS -OM" for the Alliant. + (8/27) + +--------------------------- +(bootstrap completed) + +unix/hlib/alloc.e + Changed owner to root. (8/27) + +sys/gio/gki/gkigca.x + The min() instrinsic function was being called with operands of mixed + type, i.e., int and short. Restructured so that both operands were of + type int. (8/27) + +sys/gio/gki/gkigca.x + In this case, the Alliant compiler found a real bug in a module. + The warning message `subscript out of range' was being produced + because Mems[] was being referenced with a compile time constant + subscript, caused by omission of the pointer variable from the + expression. The bug was harmless, however, since the affected + argument (the device name string) was not being used by the called + procedure (close workstation). (8/27) + +sys/vops/lz/mkpkg + Added $checkout libvops.a, etc., to the file header. (8/27) + +sys/vops/ak/*.x +sys/vops/lz/*.x +unix/boot/generic/generic.c + The Alliant fortran compiler complains about use of (0,0) as a + complex constant. This string is generated by the generic + preprocessor when the sequence 0$f is encountered (actually, + any sequence NN$f is permitted). Modified the generic preprocessor + to turn NN$f into (NN.0,NN.0) for the complex datatype, and + deleted all the complex files (and associated integer files) in ak + and lz containing the string (0,0). These will be automatically + regenerated by the preprocessor in the sysgen provided the integer + family member is not found - the mkpkg only checks the date (and + existence) of the integer file. (8/27) + +pkg/system/help/t_lroff.x + Added an extern declaration for `getline', since it is passed by name + to the lroff function. (8/27) + +pkg/cl/task.h + In the #define next_task, deleted the (unsigned) coercion. This should + not be necessary as a pointer is already an unsigned quantity, and the + Alliant C compiler would fail with the message + + `expression causes compiler loop: try simplifying' + + when trying to compile the file (although the same macro was used in + lots of other places without problems - maybe it was causing parser + stack overflow in the problem cases, due to a complex context). (8/27) + +unix/hlib/mkpkg.inc +sys/vops/mkpkg + As an experiment, added a new environment variable XVFLAGS to + mkpkg.inc; this is used when compiling vectorized code to get + whatever compiler options are desirable for such code. Added + a $set to the vops mkpkg to redefine XFLAGS as XVFLAGS so that + the vops package will be compiled for vectorization. At present, + the value of XVFLAGS is the same as XFLAGS, i.e., vectorization + is permitted in both cases, except that the vectorization warning + messages are not turned off by the XVFLAGS. (8/27) + +--------------------------- +(started the first full system sysgen) + +sys/gio/gki/gkiopen.x +sys/gio/gki/gkititle.x + More `subscript out of bounds' errors, caused by omission of the + pointer `gki' from gki instruction field references. (8/27) + +sys/fio/osfnlock.x + The procedure osfn_initlock was declared as an integer function but + the return value was never set, causing the fortran compiler to + complain `FUNCTION return value is not defined in this program unit'. + It turns out that the procedure is called as a subroutine everywhere, + so evidently the function declaration was not intended. Changed it + to a subroutine. So far, the Alliant fortran compiler is finding + more bugs in IRAF than IRAF is finding bugs in the compiler, a pleasant + turn of affairs. (8/27) + +sys/vops/amap.gx + Broke the min/max expression in the do loop up into two statements + to defeat a compiler warning message for case short; an integer + expression was being used as one of the min/max operands for case + short. (8/27) + +unix/boot/generic/tok.l + The external string variable xtype_string[] was declared as (char *) + rather than (char []) in tok.l, causing a runtime bus error on the + Alliant. This construct works on the VAX because the linker is smart + enough to figure out what is going on, but clearly the construct is + not portable and should be avoided. Probably it is always safe to + use (char *) in argument lists since a pointer value is always pushed + on the stack, but in extern declarations the array notatio must be + used. (8/27) + +sys/osb/mkpkg +sys/osb/achtb.gc +sys/osb/achtu.gc +sys/osb/achtzb.gc +sys/osb/achtzu.gc + A warning message from the C compiler led to the disovery of some + old complex ACHT procedures in OSB. There was a bug in these files + which had been fixed in the source .gc files, but type X had been + removed from the call to generic in the mkpkg, hence the complex + files were never regenerated. It appears that type complex was dropped + at some point from the mkpkg, but the complex files were never + deleted. The other file are more permissive with type coercion, + hence the problem was never discovered. I restored type complex to + the mkpkg and added a complex case (requires special processing) to + each of the .gc files. (8/27) + +sys/gio/ncarutil/sysint/ishift.x + This file contains source for two procedures IAND and IOR. This would + not compile since the Fortran compiler already has intrinsic functions + with the same names; commented the offending procedures out as a + workaround. (8/27) + +sys/ki/irafks.x + The procedure `kserver' was declared as a function but the return + value was never set, and the function was being called as a + subroutine. Changed to a subroutine. (8/27) + +math/iminterp/arider.x + This file contained the three procedures ii_pcpoly3, ii_pcpoly5, + and ii_pcspline3. These were all declared as functions had no + return values and were always called as subroutines, hence I changed + them to subroutines. Also, the same external names were used with + a different argument list in the file `mrider.x', leading to a very + serious library conflict - surprised it has not caused noticeable + runtime problems to date. As a temporary solution, I changed the + names to ia_* in the file arider.x to avoid this library conflict. + (8/27) + +pkg/xtools/icfit/icgdelete.gx +pkg/xtools/icfit/icgundelete.gx +pkg/onedspec/identify/icfit/icgdelete.gx +pkg/onedspec/identify/icfit/icgundelete.gx + Each file contained two procedures which were declared as functions + but which did not return function values and which were called as + subroutines, hence I changed them to subroutines. (8/27) + +pkg/images/imdebug/immake.x + Subroutine immake2 declared as a function. (8/27) + +pkg/images/tv/display/iiswnd.x + Contained constructs such as `max (0, lut[i])', where `lut' is a short + integer array. This caused a min/max type mismatch error. Also, a + statement had a nonfunctional C like ; at the end. (8/27) + +pkg/images/tv/cv/iism70/iishisto.x + Same problem, short integer variable `offset'. (8/27) + +pkg/images/geometry/blkav.gx + Main procedure blkav$t declared as a function but used as a subroutine + everywhere. (8/27) + +pkg/plot/gkiextract.x + In gke_make_index, `nchars_max = min...', contained an integer constant + and a short integer array element, causing a min/max argument type + mismatch. (8/27) + +noao/onedspec/t_dispcor.x + Procedure dcorrect declared as a function is really a subroutine. + Also, it has a ridiculously large number of arguments. (8/27) + +--------------------------- +(All compile time bugs found in this pass fixed. Stripped all non-HSI +(binaries and started another full sysgen to run overnight). + +kernel problems + When I came in in the morning the sysgen had completed successfully, + but the machine seemed rather sluggish. Trying to work, I immediately + found that processes which used to run would hang up on a pseudo-run + state, completely uninterruptable, sometimes unstoppable, unkillable, + and so on. Clearly a problem with the unix kernel, so I rebooted and + the symptoms went away. Most likely this was a bug in the Alliant + unix kernel, which is common with new unix ports. (8/28) + +math/interp/arider.x [OBSOLETE] + Missed one: the three procedures iidr_poly[35] and iidr_spline3 were + declared as functions but were really subroutines. (8/28) + +pkg/images/tv/cv/iism70/iisrange.x + Lots of problems mixing int and short in calls to AND, OR. (8/28) + +pkg/images/tv/cv/iism70/zsnap.x + This module caused the fortran compiler to core dump with an internal + error; it was trying to resolve mixed int/short operands in expressions + and couldn't handle this code, evidently. (I feel much the same way + trying to read it.) + + Deleted `int min(), max()' intrinsic function declarations. Added an + itemp temporary to fix a couple min/max statements which mixed int + and short operands. (8/28) + +pkg/images/tv/cv/iism70/iishisto.x + Lots and lots of compile time problems with short variables - took + several iterations to find them all. (8/28) + +pkg/images/imarith/imsum.x + In module MXMNSS, the Fortran compiler coredumps when run with + global optimization (-Og). Returns `error code 138': examination + of the corefile for `fortran1' (the first pass I presume) with adb + gives the reason as `bus-error page violation'. Saved the offending + segment of code in local$bugs for a bug report to Alliant, and compiled + the routine without optimization. (8/28) + +noao/mtlocal/cyber/cy_rbits.x + This file also causes the Fortran compiler to coredump and return + error code 138 - bus error page violation. Generated the minimum + Fortran module that would demonstrate the bug and installed it in + local$bugs. Hand compiled routine without optimization. (8/28) + +noao/mtlocal/cyber/cyber.h, *.x + The data structure for this package included a field named POINTER. + This is a reserved keyword, and is converted by the preprocessor + into `int', eventually causing a compile time error on the Alliant + (and a memory overwrite problem on the VAX). Aside from being a + reserved keyword, POINTER is not a very illuminating name for a + field of a structure: pointer to what? After a little investigation, + changed the name to COEFF, since it appears that the field contains + a pointer to some sort of coefficient array. (8/28) + +--------------------------- +All compile time problems have now been dealt with and all executables linked +and installed in bin. I tried running a couple of the executables, and +incredibly, they ran without apparent error on the first attempt! Of course, +that is too good to be true, the next step is runtime testing of the system. + +dev/graphcap +dev/termcap + Installed the local DAO additions to termcap and graphcap. Rather + than have a modified version of the vt640 entry for DAO, changed the + name of the new logical device to vt640d. (8/28) + +unix/hlib/mkiraf.csh + Set the default image storage directory to /u2 since it will be + empty when iraf is moved back to /iraf, and since there does not + seem to be any dedicated scratch area. Added a comment for the + pt100g graphics terminal. (8/28) + +unix/hlib/zzsetenv.def + Changed the names of the stdgraph and terminal devices to `pt100g'. + Did not set stdplot, stdimage, printer, since no such devices are + currently available from the Alliant. (8/28) + +local/login.cl + Ran `mkiraf' to set up a new CL login for IRAF. Tried starting the + CL and it hung up in pseudo-run mode as above. The problem is + definitely in the unix kernel, but it appears likely that the bug + occurs when an IRAF VOS (not HSI) process runs - possibly it is + related to the call to the internal Alliant `setcontext' routine + (which traps to the kernel), called from ZSVJMP. The system slows + way down when this occurs, so evidently it is hung in some sort of + tight kernel loop. (8/28) + +(rebooted) + +process spawn problem + This is turning out to be a hard problem to locate. ZSVJMP turned + out not to be the problem, and in fact it works fine. The difference + between the IRAF processes and the UNIX processes is that the IRAF + processes use the fancy vector compiler. The Alliant process header + contains a flag bit word describing the attributes of the process to + be run; the standard UNIX processes do not use any of the fancy + Alliant vector stuff, and in fact do not even use 68020 instructions. + The IRAF processes use 68020 instructions, vector instructions, + and something called multiple stacks. Once the kernel gets corrupted, + processes with these attributes enter the pseudo-run state when we try + to exec them. (8/29) + +(rebooted countless times) + +unix/os/zfiopr.c + After a lengthy battle, finally determined that due to some bug in + the Alliant kernel, ONLY A NORMAL PROCESS CAN EXEC A VECTOR PROCESS. + A vector process can exec a normal process with no problem, and a + normal process can exec a normal process, but if a vector process + execs a vector process the exec hangs in a tight kernel loop. + The workaround is for the vector process to exec a normal process + and have it turn around and exec the desired vector process. + I tried this, and it works, although there appear to be other less + serious bugs with IPC to be faced tomorrow. (8/29) + + [8/30 - IPC bug was not a real bug, just caused by "-c" switch not + [being passed to connected subprocess by `execute'.] + +unix/os/exec.c + +unix/hlib/exec.e + +unix/os/zfiopr.c +unix/os/mkpkg.csh +unix/os/mkpkg + Resolved the process connect problem as follows: [1] added a new + file exec.c (source for hlib$exec.e), which compiles into a nonvector + process to be called by the CL to spawn vector subprocesses; + [2] replaced the execl call in zfiopr.c/ZOPCPR by a call to execve + to spawn hlib$exec.e, which in turn spawns the IRAF suprocess. + Added entries to the mkpkg files to make the new modules. (8/30) + +-------------------------------------- +ALLIANT/IRAF is now up and ready for runtime testing, Saturday morning, +30 August. Spent two days on the port and one and a half days figuring +out the process connect problem. + +unix/hlib/iraf.h +unix/hlib/mach.h + In checking out some operations upon indefinites, discovered that + the values of INDEFR and INDEFD in <iraf.h> had accidentally been + set to the values of EPSILON[RD]. This was causing INDEF comparison + failures for files that included <mach.h> since INDEF is also defined + there. INDEF should not be defined in <mach.h> if it is already + defined in <iraf.h>, so I deleted the entries in <mach.h> and restored + the old values to <iraf.h>. (8/30) + +unix/as/zsvjmp.s + Discovered a minor problem with the new ZDOJMP routine. The address + of the error code was being returned, rather than the value, causing + error messages to come out as ERROR (*****, ".."). (8/30) + +(full sysgen and relink due to <iraf.h> and zsvjmp edits) + +Fatal Alliant hardware problem + Right away when trying to test out the IRAF science software I + ran into serious problems with floating point operations. A little + investigation showed that the Alliant floating point hardware is + faulty. Simple test programs were written in both Fortran and C to + print out the numbers 1.0, 2.0, 3.0: both failed. Testing of the + floating point instructions with ADB revealed that add and subtract + are ok, but 1.0 * 2.0 is 2.1375, and 1.0 / 2.0 is 0.53125. A simple + board swap should fix the problem (in fact it is probably a single + chip), but unfortunately this will prevent further testing of the + science software during this visit; virtually all programs that use + floating point produce invalid results, including all graphics + programs. Testing of the system software can continue, as can + execution of most benchmark programs. (8/30) + + IMPORTANT NOTE -- Once this problem is fixed it will be necessary to + recompile the entire system (and any other non-IRAF software as well), + since any floating point decode operations performed by the compilers + will likely have failed, causing invalid floating point numbers to be + compiled into programs. Hence these programs will fail even after the + hardware is fixed. + +unix/os/zopdpr.c + Had to make the same change here as in zfiopr.c, i.e., add a call to + the intermediate `exec.e' process to exec the bkg cl. Note that this + is not necessary for zoscmd, since zoscmd execs one of the unix + shells, both of which are nonvector processes. (8/31) + +Note on FTP +vms/boot/rtar + A binary file transfer via FTP to VMS resulted in creation of a file + with an undefined record type. Trying to unpack this file with RTAR + would immediately crash the VAX due to an exexpected exception during + a system call in the ACP (RMS). This should not happen, of course, + but the real question is why FTP created a file with an undefined + record type. Sure would be nice to have the IRAF networking software + up... (9/1) + +unix/os/zgtime.c +unix/hlib/libc/kernel.h (HZ) +sys/etc/sysptime.x + Rewrote the timer utility routines to use only integer arithmetic, + so that I could run some benchmarks of the vector hardware. (9/1) + +(relink) + +-------------------- +Timing tests + The Alliant documentation claims that use of the vector hardware will + increase performance by about a factor of 4. This is borne out by my + tests. The factor of 4 is determined by the ratio of the startup + time for a vector segment versus the time required to execute a + vector segment, where the segment length (number of elements in a + vector register) is 32 for the Alliant. + + aaddr, 512x512 + vectorized: 0.184 cpu + nonvector: 0.617 cpu + +(Moved new system to /iraf; deleted old system, it should be archived +(somewhere and probably won't be looked at again anyhow. I saved a copy +(of the original Alliant notes file as notes.den. Modified the links in +(/usr/include and /usr/bin to point to /iraf. Modified the pathnames in +(hlib and hlib/libc). (9/1) + +cleanup + Ran (most of) the standard benchmarks. Deleted the /u2 version of + iraf. (9/2) + +------------------------------ +Back at NOAO. Problems reading tar file on VMS backup tape brought back from +DAO. This is probably due to problems with the DAO software so I shall +document it here (copied from noao/lyra notes file). + +doc/ports/alliant_86.doc + Installed the notes file from the Alliant port. There was some + problem with the backup/tar file I made on the Alliant, hence it was + not easy to get the notes file off the tape. I had to use the new + SPLIT task to split the 24 Mb archive into 49 512000 byte segments, + and eventually determined that the notes file was at line 11115 of + segment 39! The problems with the tape are almost certainly not with + the tape itself, since I did a backup/compare at DAO, and backup did + not report any problems when the tape was read. + + I think the most likely culprit is the FTP software, which had to be + used to move the archive to the VMS VAX, since the DAO Alliant did not + have a tape drive. FTP (binary mode) insisted on making a file with + an undefined VMS record type; this would cause RTAR to crash the VAX + if I tried to look at the file on the VMS VAX at DAO. The 24 Mb archive + file has one enormous section which is all zeroed, and then in the + remainder of the archive all ascii zeroes appear to have been deleted + from the archive, causing the 512 byte TAR file headers to be much + shorter. I tried the exact same operation (with a smaller test file) + using our Eunice FTP and everything worked fine. The DAO TELNET + also gave problems; it would hang up if fed too much data too fast, + and would occasionally crash with a stack trace. Based on these + experiences, I would certainly have to recommend the Wollongong + networking software over the other vendor. (9/6) diff --git a/doc/ports/aos_ctio.doc b/doc/ports/aos_ctio.doc new file mode 100644 index 00000000..0fcc099c --- /dev/null +++ b/doc/ports/aos_ctio.doc @@ -0,0 +1,233 @@ +System notes file for CTIO AOS/VS IRAF installation. +9-17 April 1987 + +System installed by Gary Lee Webb on 9 April. +CL came up and ran with minor problems. + +Did not start keeping this notes file until 16 April (D.Tody). +May have missed some important mods. + +Extant Bugs +------------ + +1. OS escapes. + + Interrupting an OS escape often causes the escape mechanism to + get in a state where subsequent escapes will return immediately, + even though the command has been sent to the cli, sh, or whatever. + This leads to the CL and the host task reading from the terminal + at the same time, seizing alternate lines of input. + +2. Magtape i/o problem + + CTIO has a standard DG tape drive and two Cipher tape drives. + The standard tape drive will accept transfers up to 32768 bytes + (or maybe 32767 bytes), which is what the zfiomt.c driver code + is written for. The Cipher drives, however, have a maximum transfer + size of 8192 bytes, hence the max transfer size is device dependent + rather than just system dependent. As a kludge fix for this I + added some site dependent logic to zfiomt.c, but a real fix will + probably require addition of the max transfer size to the dev$devices + file, and changes to the VOS code to deal with this. + +3. Path and script problems + + There were a number of problems with missing directories and + confusion between executables and macro script tasks, leading to + failure of mkpkg, xc, etc. I will try to get Gary to document these + better. + One of the problems (glw) was the use of directories C_DIR and + F77_DIR to find the executable C and FORTRAN compilers. Unfortunately, + there are no standard directories for these (other than they should be + in :UTIL), perhaps the standard C and F77 macros should be used rather + than having IRAF write its own? + +4. File dates + + After the system installation, a mkpkg on any package results in + compilation of all of the files therein. Evidently the file modify + dates are not being restored properly when a backed up system is + restored from tape. + +5. Installation (glw) + + The current link initialization macro will delete /TMP and link it + to /DEV. I see no reason to combine these and did not do so. + For a user to be able to generate any processes under IRAF, he also + had to be a valid MV/UX user (i.e., have an entry in /ETC/PASSWD). If + this is not a bug, it should be documented in the installation guide! + There are !SOLPLs all over the place: a list of files to be changed + would be nice. + +6. Worries... (glw) + + I note that the editor description files end with a .ed, just like + the SED temporary files, making them likely to be deleted accidentally. + + +System Revisions +-------------------- + +aosvs/os/zfiomt.c + Did a kludge fix to set the max transfer size down to 8192 bytes + for devices other than mtb0. (4/15 dct) + +dev/vi.ed + Changed the OS escape for VI from "vi" to "!vi" to cause the command + to be executed by CSH rather than CLI. Also added an entry for the + vi500 to /etc/termcap, but I could never get VI to find the entry + for the device. Tried setting TERMCAP in .cshrc to point to another + file, or directly to the vi500 termcap entry, but none of this made + any difference. (4/16 dct) + +aosvs/os/prwait.c + The include file <sys/wait.h> was not being found; it turns out to + be in /usr/include on this system. I had to reference the file as + "/usr/include/wait.h" rather than the expected <wait.h> to get the + module to compile. It appears that the real include files are + coming from some other place (maybe a text library?) and that the + wait.h file is missing. (4/16 dct) + +aosvs/boot/rtar/mkpkg + Added a "-B" flag to the $link call. Without this the link fails + with a multiple reference to main.o, and unresolved externals for + all the bootlib routines. It looked like this was missing from + most of the other boot packages too. (4/16 dct) + +dev/slate.ed (glw) + Added this file (guessing a lot!) to provide Dan's favorite editor. + It must work -- that's how I'm adding this comment! + Where is the documentation for the *.ed format? + +dev/sed.ed (glw 16 IV 87) + Modified the command line to be SED/NOED to avoid leaving *.ed files + all over the place. + +dev/termcap (glw 16 IV 87) + Added lpt1, lpt4, and lpt5 printers, a/k/a adservs, diablo, laser. + +pkg/images/imdebug/mktest.x + Would integer overflow when creating a large image. This is harmless + on the other systems, but it has to be guarded against on the MV as + it causes the task to abort. (4/17) + +pkg/images/iminfo/t_imstat.x + Installed an optimized version of the IMSTAT task. (4/18) + +aosvs/boot/mkpkg/*.[ch] + AOS/VS evidently cannot restore the modify dates of files when reading + a tape onto disk. This causes mkpkg to try to recompile everything + when run for the first time on a newly installed system. Modified the + mkpkg program to add a new flag "-u". This flag, if present, causes + the dates of library modules to be forced to be no less than the date + of a magic file (currently hlib$iraf.h). It is assumed that the date + of the magic file is about the same as the date at which the system + was installed. To be precise, the file should be touched after the + tape is read in (already done for the CTIO system), and the first + time mkpkg is run on a package the -u flag should be used to forcibly + update the library module dates. (4/18) + +--------------------------------------------------------------------- +From SKIP@SOLPL.AS.ARIZONA.EDU Thu May 28 12:14:58 1987 +Received: from noao.arpa by noao-lyra.arpa.noao (5.51/SAG.7) + id AA08983; Thu, 28 May 87 12:14:53 MST +Received: from solpl.as.arizona.edu by noao.arpa (5.51/SAG.7) + id AA03426; Thu, 28 May 87 12:14:46 MST +Received: by SOLPL.AS.ARIZONA.EDU (1.00/1.0) + id AA00065; Thu, 28 May 87 12:14:20 mst +Date: Thu, 28 May 87 12:14:20 mst +From: Skip Schaller <SKIP@SOLPL.AS.ARIZONA.EDU> +Message-Id: <8705281714.AA00065@SOLPL.AS.ARIZONA.EDU> +To: chile@noao, tody@noao +To: Dan@SOLPL.AS.ARIZONA.EDU, Smith@SOLPL.AS.ARIZONA.EDU, + Gary@SOLPL.AS.ARIZONA.EDU, Webb@SOLPL.AS.ARIZONA.EDU +Fm: Skip Schaller + + I will be leaving Tucson on June 18 for Chile. I will call you +on Monday morning June 22. I expect to be able to pitch in immediately +if you so desire. I will be in Chile until August 16. Let me know as +soon as you know what it is exactly that you want me to do for you. If +I can prepare anything here ahead of time, so much the better. + + Please send me any AOSVS/IRAF bug reports as soon as possible. It +will be much easier for me to fix them here. + + + The following are my responses to the CTIO AOSVS/IRAF installation +notes that I got from Doug Tody: + +1) Keyboard interrupt during OS escape. + I duplicated this problem at solpl. I will try to fix during +this next update. It may be an AOSVS problem and not fixable. + +2) Magtape maximum record size for certain drives. + Doug changed the IRAF VOS just the other to deal with this problem. + +3) Pathname problems. + As far as I can tell (by looking at other AOSVS systems), +F77_DIR and C_DIR are the standard DG directories for those languages. +In any case, the installation manual tells you which scripts to check +and modify to agree with your system. (I had to do this for the +Tenerife installation. It was trivial.) Unfortunately, the standard +scripts cannot be used due to their lack of functionality and interface +to mkpkg. + +4) File dates. + Hopefully by the next release, Doug's changes to mkpkg to update +file dates for library members without recompiling, will be incorporated. +Many DG sites have complained about AOSVS not restoring the original +file modification times. + +5) Link installation problems. + The link installation script does NOT delete /TMP and link it to /DEV. +Read it again. With MV/UX installed, that part of the script does nothing. + +6) Problems with /etc/passwd. + I could not reproduce this problem at solpl. I did reproduce it +during the Tenerife installation. I found out that the minimum needed +was to have this file present with one entry for user "iraf". + Sometime ago I tried to eliminate IRAF dependence on this file +by avoiding the use of those C subroutines given in the DG documentation +that access this file. Apparently, there is at least one more, execl (). +In any event, the DG C subroutines should do something more graceful when it +can't access the information it wants. I will take this matter up with +DG. In the meantime, all current AOSVS/IRAF sites now have MV/UX so they +should really keep this file up to date for all users. + +7) Node name changes. + There are NOT solpl!'s all over the place. They are confined to +the files which may contain site dependence. In any event, since CTIO +does not have any networking software, the IRAF networking is automatically +turned off and the solpl!'s are harmless and need not be changed. If there +are any files that particularly bother you, give me their names and I'll +see what I can do. + +8) Editor descriptor files (.ed). + The editor descriptor 'edit' was already provided so that SED +does not generate files with conflicting extensions. + +9) Vi. + We execute vi directly from the CLI. We use a slightly different +entry for the vi500 in /etc/termcap than the one used by IRAF, so as to +get around some DG bugs. The user needs a .exrc file in his home directory +to set the terminal type. + +10) Wait.c + The include file wait.c is missing from the DG C release and +should be copied from :usr:include:wait.h to :util:c_dir:sys. + +11) Mkpkg -B flag. + The -B flag was present in the mkpkg file in the immediately superior +directory, but I will put it in all the subdirectory mkpkg files as it +should be. + +12) No documentation for dev$*.ed files. + I agree with you, Gary. However it turns out that most of it +is not necessary to change. + +13) image$imdebug/mktest.x + I reported the integer overflow problems to Doug some time ago +when I ran the benchmarks. + + +NNN diff --git a/doc/ports/aos_port.doc b/doc/ports/aos_port.doc new file mode 100644 index 00000000..fa88fcd2 --- /dev/null +++ b/doc/ports/aos_port.doc @@ -0,0 +1,223 @@ +/iraf/lib + clpackage.cl Changed terminal name + config.h AOSVS changes (HOST_CASE, etc.) + iraf.h AOSVS changes (added defines for and, or, etc.) + mach.h MV/10000 changes + make.h MV/UX changes +/iraf/lib/libc + iraf.h AOSVS changes + kernel.h AOSVS changes + The buffer size for IPC was changed from 4096 + to 1024, because of the error: + Warning: File Read Error (STDIN) when doing + set | match tty ... or ... type x | type + where x was 1024 or more bytes long. This error was followed by a hangup on logout, apparently + waiting for the sub-process to die after sending it 'bye'. The kernel routine ZFIOPR was tested + to record lengths of 4096 with no problems. I + don't understand this; it looks like a weird + problem in FIO. + knames.h AOSVS changes + libc.h AOSVS changes + math.h Added conditional for C math functions (nint) + spp.h AOSVS changes + xnames.h AOSVS changes +/iraf/math/bevington + chifit.f line 103 Ambiguous transfer of control to statement 70 +/iraf/math/curfit + OK +/iraf/math/deboor + cwidth.f line 112 Dummy argument declaration order + dtblok.f line 18 " + factrb.f line 25 " + fcblok.f line 29 " + sbblok.f line 15 " + shiftb.f line 33 " + slvblk.f line 119 " + subbak.f line 16 " + subfor.f line 21 " +/iraf/math/gsurfit + OK +/iraf/math/iminterp + Makelib ii_spline mentioned twice +/iraf/math/interp + interp.h Renamed to interpdef.h + clginterp.x Not found +/iraf/math/llsq + sva.f lines 179 & 181 Comma needed after P edit descriptor +/iraf/math/surfit + OK +/iraf/pkg/cl + bkg.c 2 places Declaration added for long c_clktime() + grammar.y Yacc conflicts: 8 shift/reduce + main.c The declarations for "rootpackage" & "clpackage" were made consistent with those in builtin.c so + that the "btbl" static table of builtins could + be properly initialized. + main.c envinit() 'lib/' changed to 'lib:' ????? + pfiles.c line 563 In addparam() prevent dereferencing a possibly + NULL pointer. + task.h prevtask and tp++ (or ++tp) didn't work due to + builtin.c (2 places) AOSVS alignment of pointers. Note: the fix for + debug.c VMS was not machine independent. + errs.c + exec.c (2 places) + pfiles.c + mem.h dereference() Changed to be machine independent. Previous + definition assumed byte addressing. +/iraf/pkg/help + nomore.x .f line 39 Relational operator with logical operands. + manout.x In man_breakpage(), identifier "nlines_per_page" was changed to "n_per_page" to shorten length of subroutine statement. (RPP maximum output line + length is set to 74.) +/iraf/pkg/help/lroff + output.x (3 places) 'col' multiply defined +/iraf/pkg/softools/boot/mklib + makefile AOSVS changes + mklib.c AOSVS changes + scanlib.c AOSVS changes +/iraf/pkg/softools/boot/spp + makefile AOSVS changes + readme AOSVS comments added + xc.c AOSVS changes + xc.c procedure "fatal" Missing argument to fprintf +/iraf/pkg/softools/boot/spp/rpp + makefile AOSVS changes +/iraf/pkg/softools/boot/spp/rpp/ratlibc + amove.c Changed link/unlink to amove for AOSVS + getnow.c Removed milliseconds + initst.c Changed _NFILE to 16 + makefile AOSVS changes + ratdef.h Added RF defines + readf.c Removed declaration for fread + writef.c Removed declaration for fwrite +/iraf/pkg/softools/boot/spp/rpp/ratlibf + caslab.f line 32 Warning: unreachable code + ctomn.f Changed and to iand + gitoc.f Changed and to iand + makefile AOSVS changes +/iraf/pkg/softools/boot/spp/rpp/rppfor + baderr.f Declared argument to be character*(*) + errchk.f line 78 Missing argument to call to GNBTOK + gtok.f line 132 Commented out B = 10 * B + C - 48 + to avoid fixed point overflows. + Not needed since radix conversion is done in XPP makefile AOSVS changes + synerr.f Declared argument to be character*(*) +/iraf/pkg/softools/boot/spp/xpp + decl.c Set MAXSYM = 200. Needed to compile + /iraf/sys/gio/nsppkern/gktopenws.x because of + include file nspp.com. Note: the overflow + check in d_enter is wrong. + makefile AOSVS changes + xppcode.c After MACHDEP, changed int to int2, int4, etc. + xppmain.c Check for NULL after calling getenv +/iraf/pkg/system + delete.x line 48 Relational operator with logical operands + match.x line 42 Relational operator with logical operands + line 76 Relational operator with logical operands + page.x line 204 Relational operator with logical operands + sort.x line 290 "answer" declared twice +/iraf/sys + OK + tsort cycle: libex.a gamove, gadraw, elogr + tsort cycle: libsys.a error, erract, xerfmt, environ, realloc, + malloc, syserr, itoc + environ, realloc, malloc, xerpop, erract, + xerfmt, gstrcpy + xerpop, erract, putci, flsbuf, fexbuf, + realloc, malloc + putci, flsbuf, fexbuf, realloc, xerpop, + erract, putline +/iraf/sys/clio + OK +/iraf/sys/etc + environ envgets broken out, to avoid tsort cycle +/iraf/sys/fio + fclobber.x .f line 67 Relational operator with logical operands + vfnmap.x .f line 546 Relational operator with logical operands +/iraf/sys/fmtio + dtoc3.x .f line 118 Parentheses needed for unary arithmetic operator evexpr.x .f line 393 Relational operator with logical operands +/iraf/sys/gio + elogd.x .f line 29 Parentheses needed for unary arithmetic operator elogr.x .f line 29 Parentheses needed for unary arithmetic operator/iraf/sys/gio/cursor + OK + tsort cycle : libcur.a gtrctrl, gtropenws, prpsio, giotr. +/iraf/sys/gio/gki + OK +/iraf/sys/gio/glabax + OK +/iraf/sys/gio/nspp + i1mach.f Copied from /iraf/sys/osb + r1mach.f Copied from /iraf/sys/osb + ibit.s substituted ishift.f + IAND - ignored + IOR - ignored + ISHIFT - calls ishiftc +/iraf/sys/gio/nspp/mctr + OK +/iraf/sys/gio/nspp/nspp + OK +/iraf/sys/gio/nspp/utilities + conrec.f line 387 Character constant broken over 2 lines + conterp.f line 1518 Compilier warning: padded short constant: 2HLO + line 1656 " +/iraf/sys/gio/nsppkern + nspp.com Changed all () to []. + pixels.f line 58 Arguments to intrinsic function not of same type/iraf/sys/gio/stdgraph + stgrcur.x .f line 66 Relational operator with logical operands +/iraf/sys/imio + OK +/iraf/sys/imio/db + idbpstr.x .f line 77 IM_NAXIS not defined in imio.h +/iraf/sys/imio/tf + OK +/iraf/sys/ki + kinode.com Added arrays n_local and n_nrefs. +/iraf/sys/libc + mathc.c Added conditional for C math functions (nint) + printf.c & The machine dependent technique of handling + scanf.c a variable number of arguments was only + very obscurely documented. All the + appropriate references of argp++ (sic) + were changed to argp-- for AOSVS. + OK +/iraf/sys/memio + OK +/iraf/sys/mtio + OK +/iraf/sys/os + MANY like zfaloc, zfiomt, zfiopr, zfrnam, zlocva, zmaloc, zmfree, + zopdir, zopdpr, zraloc : return (*status = XERR); etc. + C returning a value when CALLed by F77 causes + problems, at least with OPTimized code. + MANY AOSVS versions: zawset, zfacss, zfaloc, zfchdr, + zfgcwd, zfinfo, zfiomt, zfiopr, zfiost, zfmkcp, zfmkdr, zfpath, + zfprot, zfrnam, zfsubd, zfxdir, zglobl, zgtenv, zgtime, zinit, + zmain, zmaloc, zopdir, zoscmd, zsvjmp, zxwhen + makelib Dependencies corrected, and updated for AOSVS + zcall.c Dereference usage of PFI + Declare all arguments to be pointers + zfiolp.c line 116 Defererence "dispose" + line 129 ZOSCMD called with character arguments + zfiopl.c line 101 Same as zfiolp line 116 + line 114 Same as zfiolp line 129 + zfiopr.c line 55 Cast osfn as (char *) + zfiotx.c line 376 Dereference "status" + zlocpr.c An extra dereference was needed for AOSVS + zmain.c line 118 Cast osfn as (char *) + zopdir.c Modified input argument +/iraf/sys/osb + acht??.c Modification of input argument + bytmov.c Bug concerning undefined variable "otop" + bytmov.s MV/10000 version + d1mach.f Added entries for Data General MV/10000 + i1mach.f " + r1mach.f " + makelib AOSVS version + mii.x Removed call to high level routine "error" +/iraf/sys/tty + ttyopen.x .f line 208 Relational operator with logical operands + ttyputs.x .f line 43 Arguments to intrinsic function not of same type/iraf/sys/vops + OK +/iraf/sys/vops/achtgen + OK +/iraf/sys/vops/ak + Makelib Replaced .s modules with .x +/iraf/sys/vops/lz + Makelib Replaced .s modules with .x diff --git a/doc/ports/aux_port.doc b/doc/ports/aux_port.doc new file mode 100644 index 00000000..743d453c --- /dev/null +++ b/doc/ports/aux_port.doc @@ -0,0 +1,978 @@ +Begin IRAF port to Macintosh A/UX 2.0, 26Jan91. +----------------------------------------------- + +unix/as +unix/as.mac + +unix/bin +unix/bin.mac + +unix/hlib/irafuser.csh + Set up a new "mac" architecture. (01/26) + +unix/hlib/libc/iraf.h + Set the iraf root to point to /u1/iraf. (01/26) + +unix/as.mac/ishift.s +unix/as.mac/zsvjmp.s + Modified for the GNU assembler (GAS). (01/26) + +unix/hlib/*.csh + Modified for A/UX. (01/26) + +unix/hlib/config.h +unix/hlib/libc/spp.h + Checked that LEN_JMPBUF was large enough to handle the setjmp + buffer used by A/UX. (01/26) + +unix/boot/bootlib/mkpkg.sh +unix/boot/generic/mkpkg.sh +unix/boot/mkpkg/mkpkg.sh +unix/boot/rmbin/mkpkg.sh +unix/boot/rmfiles/mkpkg.sh +unix/boot/rtar/mkpkg.sh +unix/boot/spp/mkpkg.sh +unix/boot/spp/mkxc.sh +unix/boot/spp/rpp/mkpkg.sh +unix/boot/spp/rpp/ratlibc/mkpkg.sh +unix/boot/spp/rpp/ratlibf/mkpkg.sh +unix/boot/spp/rpp/rppfor/mkpkg.sh +unix/boot/spp/xpp/mkpkg.sh +unix/boot/wtar/mkpkg.sh +unix/boot/xyacc/mkpkg.sh +unix/gdev/sgidev/mkpkg.sh +unix/os/mkpkg.sh +unix/shlib/mkpkg.sh + Changed all occurrences of "cc" to "$CC" and all occurrences of + "f77" to "$F77". Changed all occurrences of "ranlib" to $RANLIB. + (01/26) + +unix/hlib/irafuser.csh + Added definitions for CC, F77, and RANLIB (set to "echo ranlib" for + A/UX, which uses COFF). For the first attempt to compile the system + I am using gcc and the Absoft A/UX Fortran compiler. Later I would + like to try f2c (Fortran to C translator) with gcc as an alternative + to the Absoft Fortran. Early tests indicate that this should work, + and may produce better optimized code than the Absoft compiler. I + have already verified that the A/UX f77 cannot be used to build iraf + - there were serious problems just trying to compile the files in + one directory. (01/26) + +------- +Begin bootstrap. For this I have the GCC flags set to fairly restrictive +values, enabling some optional warning messages, to flush out any +questionable coding constructs. GCC is also an ANSI C compiler, which may +mean additional problems. (01/26) + +unix/os/mkpkg.sh + GCC doesn't echo the filename (as in "file.c:") during compiles, + which I found annoying, so I changed the mkpkg.sh to use the Bourne + shell FOR construct to compile each file separately. (01/26) + +unix/setarch.sh + The A/UX version of "test" does not have the -h flag to test for + symbolic links, so the existing script did not work. Still trying + to a portable way to do this, I changed the script to use the + construct: if [ "`ls -d as`" = "as" ]; then ... (01/26) + +unix/os/alloc.c + 1. The file header comment section contained the sequence "for the + /dev/* entries...". The "/*" would cause a warning from gcc that + there might be a comment buried in another comment, which can cause + a comment to terminate prematurely. In this case it was harmless + and indeed there was no error, but I changed the text to eliminate + the warning. + 2. Moved the #include <sys/types.h> to before the #include <utmp.h>, + as the A/UX version of the latter requires the former. (01/26) + +unix/os/getproc.c + 1. Had to add + + #ifdef AUX + #include <sys/mmu.h> + #include <sys/page.h> + #include <sys/region.h> + #endif + + before the #include <sys/proc.h>, to get the latter to compile. + + 2. In the A/UX nlist facility n_name is an array rather than a + pointer to char, so entries such as + + nl[0].n_name = "_proc"; + + had to be changed to + + strcpy (nl[0].n_name, "_proc"); (01/26) + +unix/os/prwait.c + In pr_getipc(), deleted unused variables error_code, error_status, + waitpid. (01/26) + +unix/os/zalloc.c + 1. In ZDVALL, deleted unused variable x_status. + 2. Deleted unused variable i in loggedin(). (01/26) + +unix/os/zfioks.c + 1. Deleted the old, commented out code for rcmd(), as variables + defined for this were being reported as unused. Added a comment + explaining that rcmd and friendly-host authentication cannot be + used without making the process suid root. + 2. Added #ifdef SYSV support for SysV termio. Terminal driver + ioctls are used in this routine to set raw mode for the password + prompts. + 3. GCC was complaining that the setjmp/longjmp used in zardks, + zawrks could cause certain register variables to become undefined + (op and nbytes in zardks, ofd in zawrks), so I changed the storage + class from register to auto for these variables. (01/26) + +unix/os/zfiolp.c + I had to change the declaration + + static PKCHAR xnullstr[1] = XEOS; + to + static PKCHAR xnullstr[1] = { XEOS }; + + (PKCHAR=short and XEOS=0) or GCC would complain about an invalid + initializer. Must be a feature of the ANSI C syntax. (01/26) + +unix/os/zfiotx.c +unix/hlib/libc/kernel.h + 1. Modified to add #ifdef SYSV support for SysV terminal i/o. + 2. GCC complained about some functions which were used (default + storage class extern) and later declared static; added static + declarations for these functions to the file header to eliminate + these (harmless) warning messages. (01/27) + +unix/os/zfxdir.c + Deleted unused local variable "ch". (01/27) + +unix/os/zgcmdl.c + Deleted unused local variable "ev". (01/27) + +unix/os/zgcmdl.c + Produced a coupld of "/* within comment" warning messages due an + example of some <iraf.h> code in the header comment. Changed /* in + the example to /@ to avoid the (harmless) warning. (01/27) + +unix/os/zgtime.c + Had to #ifndef SYSV the #include <sys/timeb.h> as this file does + not exist on SysV systems. (01/27) + +unix/os/zmain.c + Deleted unused local variables "junk" and "wsetsize". (01/27) + +unix/os/zwmsec.c + Added "static" to explicitly specify the storage class in the first + declarations of "napmsx", which is declared static in the source + given later in the file. (01/27) + +unix/os/zxwhen.c + 1. The system dependent definition "fcancel" would not work for A/UX; + added a #ifdef AUX version. + 2. GCC did not realize that the call to kernel_panic in zxwhen was + an exit, and would warn that the value of variable "vex", used later + in the procedure, could be unitialized. Added a statement to init + this to null to avoid the warning message. + 3. In zxgmes, the char pointer to the returned error message was + not being initialized if no error had occurred. Modified to return + the null string in this case. (01/27) + +unix/os/zzstrt.c + Added #ifdef SUNOS4 conditionals around certain declarations which + are used only the #ifdef SUNOS4 code which follows, to avoid unused + variable warnings. (01/27) + +unix/boot/bootlib/envinit.c + Deleted the unused variable "osfn" in loadpkgenv. (01/27) + +unix/boot/bootlib/bootlib.h + Deleted the commented out #define NOVOS definition, which causes + a /* in comment warning and doesn't need to be in this file anyhow. + (01/27) + +unix/boot/bootlib/osfcopy.c + 1. Deleted the unused variable "binary_file". + 2. Added a return at the end of the function, to guarantee that + a function value was returned. (01/27) + +unix/boot/bootlib/ostime.c + Modified with #ifdef SYSV for SysV. This whole business needs to + be redone sometime to provide rigorously correct time primitives + for iraf. (01/27) + +unix/boot/bootlib/vfn2osfn.c + Local variable "first_time" defined but never used. (01/27) + +unix/boot/generic/generic.c + 1. In copy_comment(), added an entry time initializer for the + local variable "flag". + 2. GCC complained about the variable "ch" in evaluate_expr() possibly + being used before being initialized. This looked harmless in this + case, but I added a global initializer to eliminate the warning + message. (01/27) + +unix/boot/mkpkg/host.c + Deleted a couple of unused "exit_status" variables. (01/27) + +unix/boot/mkpkg/host.c + Deleted unused variable "ip" in search_mkpkgfile(). (01/27) + +unix/boot/mkpkg/mkpkg +unix/boot/mkpkg/mkpkg.h +unix/boot/mkpkg/scanlib.c + 1. Added a #include "mkpkg.h" to scanlib.c. This file includes extern.h + which references a structure defined in mkpkg.h. + 2. Deleted unused local variable "key" in h_scanlibrary(). (01/27) + 3. Replaced the MAX_SYMBOLS definition in scanlib.c by MAX_LIBFILES, + as there is also a MAX_SYMBOLS in mkpkg.h which means something + quite different. (01/29) + +unix/boot/mkpkg/sflist.c + In sf_scanlist, the GCC static analysis indicated that variable "tail" + could possibly be used without being initialized. Added code to + initialize tail=head before scanning the list. (01/27) + +unix/boot/mkpkg/tok.c + 1. In do_if(), in the event of a syntax error the local variable "bval" + could be used without being initialized. Once again probably harmless + but it makes GCC complain. + 2. Unused variable "ch" in do_call(). + 3. Module do_include() was not returning an exit status in all + cases. (01/27) + +unix/boot/rmfiles.c + 1. Unused variable "i" in main(). + 2. Another warning from GCC static analysis suggesting that local + variable "fp" might be being used before being initialized (definitely + not in this case, but I added an initializer to avoid the message). + (01/27) + +unix/boot/wtar/wtar.c + Unused variable "op" in putheader(). (01/27) + +unix/boot/spp/xc.c + 1. Unused variable "cmdbuf" in main(). + 2. Variable "append" in sys() could be used before being + initialized. (01/27) + +unix/boot/spp/xpp/xppcode.c + 1. Unused variable "irafdefs" in do_include(). + 2. parse_task_statement() did not return a function value in all cases. + 3. accum() did not return a function value in all cases. + 4. Unused variable "digit" in charcon(). Function did not return + a value in all cases. + 5. Variable "value" not initialized in all cases (when an error + occurs, but it causes a warning message). (01/27) + +unix/boot/spp/xpp/decl.c + Local variable "sp" was not being initialized in all cases (i.e., + when an error occurred). (01/27) + +unix/boot/spp/rpp/ratlibc/getlin.c + The local variable "c" was not being initialized in all cases. (01/27) + +unix/mkpkg.sh + Commented out the SHLIB build code, as there is no shared library + support for Mac/IRAF yet. (01/27) + +unix/gdev/sgidev/sgidispatch.c + Deleted unused local variables "maxch" and "status". (01/27) + +-------------------------- +Second bootstrap attempt. (01/27) + +unix/os/gmttolst.c + Added #ifdef SYSV support. (01/27) + +unix/os/mkpkg.sh + Changed the "rm alloc.o" to "rm -f alloc.o", as the .o file is + not being left behind on this system, using GCC. (01/27) + +unix/os/zfioks.c +unix/hlib/irafuser.csh + GCC still warns that longjmp could clobber the values of several + local variables in this routine. Evidently this is a feature of + ANSI C. The values of automatic variables not declared "volatile" + are not guaranteed to be preserved in a longjmp. Added a -DANSI + to irafuser.csh and some #ifdef ANSI code to zfioks.c to provide + the necessary (but not non-ANSI backwards compatible) definitions. + (01/27) + +unix/os/zfiotx.c + Another longjmp warning, this time in ZGETTX. Variable "op" might + not be saved over a longjmp. In this case I was able to avoid the + problem merely by moving the op initialization statement to after + the setjmp. (01/27) + +unix/os/zfiopl.c + In zclspl, another case of an array aggregate initializer "= val;" + having to be changed to "= { val };" when initializing an array of + length 1. (01/27) + +unix/os/zoscmd.c + Modified so that if SYSV is defined, "fork" is used instead of + the BSD-ism "vfork". (01/27) + +------------------------- +Third bootstrap attempt. + +unix/boot/spp/rpp/ratlibf/*.f +unix/boot/spp/rpp/rppfor/*.f + The Fortran compiler I am using (Absoft) is case sensitive by default + and does not append an underscore to symbol names. For testing + purposes it would be most useful to have the Fortran names occupy + the same name space as the C library names, so I translated the + contents of all the above files to lower case. (01/27) + + [In retrospect this wasn't the best way to do this, the Fortran + compiler has a switch which does it more simply. (01/29)] + +unix/boot/spp/rpp/ratlibc/ratdef.h + Removed the trailing underscore from the names of the Fortran + routines. (01/27) + +unix/hlib/libc/knames.h +unix/hlib/libc/xnames.h + Edited to remove the trailing underscore from all names. (01/27) + +unix/boot/spp/rpp/ratlibr/defs +unix/boot/spp/rpp/rpprat/defs + It probably doesn't matter, but these directories both have a copy + of the "defs" file and the files should be the same, but they aren't. + The version in rpprat has been changed to increase the size of + various size limiting buffers. The fortran sources should be + regenerated using compatible defs files. (01/28) + +unix/boot/spp/rpp/mkpkg.sh + RPP failed to link in the first bootstrap attempt. To fix this + it was necessary to modify the $CC link command in the mkpkg.sh, + as follows: + + $CC $HSI_CF -t rpp.o librpp.a libf.a libc.a -lf77 -o rpp.e + + The -t flag had to be added to avoid warnings about the inconsistent + sizes for the cdsmem common (see "defs", above). The -lf77 had to + be added for the Absoft compiler, as evidently it uses library + functions for a few simple things like ABS that some RPP code + references. (01/28) + +unix/boot/mkpkg/host.c + Added a #ifdef SYSV to the code which calls RANLIB, since this is + not used on SYSV (COFF) systems. (01/28) + +unix/os/irafpath.c + Added a #ifdef AUX conditional to search the "unix/bin.mac" directory + for Mac/IRAF system files. (01/28) + +unix/spp/rpp/rppfor/poicod.f + The HSI bootstrap completed successfully, although some things are + probably still not working correctly. XC now runs but in my very + first compile test I ran into a nasty problem in the third party + Absoft Fortran compiler. The compiler complains about the following + statement in fio$areadb.x being out of order: + + memi(fp+15) = 0 + + Evidently it thinks this array assignment is a statement function + or something. I was further able to isolate the problem with the + following source: + + subroutine areadb (fd) + integer fd + integer Memi(1) + real Memr(1) + equivalence (Memi, Memr) + common /Mem/ Memi + save + memi(fd+15) = 0 + end + + The compiler barfs on a syntax error on line 8 of this file, the + lone assignment statement. With a little further testing I was + able to establish that this is due to case sensitivity in the + compiler! Changing the memi to Memi causes the problem to go away. + To fix the problem in RPP I had to replace the file poicod.f by + a version that uses "mem" rather than "Mem" in the data strings. + (01/28) + +unix/hlib/libc/libc.h + The Absoft compiler prefixes the names of Fortran commons with C + (e.g., "Cfiocom", "Cmem", etc.) and omits the trailing underscore + as in C. Modified libc.h to reflect the above naming scheme. (01/28) + +--------------------------------- +Started first core system sysgen. (01/28) + +sys/plio/plr2l.gx +sys/plio/plp2l.gx +sys/plio/pllsten.x +sys/plio/pllrop.x + The Absoft Fortran compiler could not handle the following type of + statement in these files: + + ll_out[op] = M_DH + -dv + + It was necessary to place parens around the (-dv) to avoid the + problem. (01/29) + +unix/hlib/iraf.h +unix/boot/spp/xpp/decl.c + 1. There were a lot of problems in PLIO in the initial sysgen due to + the use of bitwise boolean intrinsics in these files. The Absoft + compiler does have some bitwise functions but 1) they are typed, + not generic functions, and 2) a function which takes two short + integer arguments as input can return an integer result (contrary + to the documentation). Also, this is not a problem but a comment, + but the compiler generates function calls for the bitwise operators, + which is rather inefficient. The only way I could come up with to + work around these limitations was to define the bitwise intrinsics + in hlib$iraf.h as follows: + + define and iand(int($1),int($1)) + define or ior(int($1),int($1)) + define not jnot(int($1)) + define xor ieor(int($1),int($2)) + + 2. Unfortunately the argument expansion in the above definitions + would cause problems with functions that declare the bitwise + intrinsics, i.e., that contains statements such as "int and()". + It was necessary to modify decl.c to add special processing for + function declarations so that any declarations of the bitwise + intrinsics could be omitted. This may be a generally useful + addition as special processing of intrinsic functions might be + required on any system. (01/29) + +sys/mwcs/mwtransd.x + This file also contained a "foo + -bar" construct requiring + parenthesis to get by the Absoft parser. (01/29) + +sys/imfort/imemsg.x + This file contained four Fortran escapes (error message strings) + which ran over the 72 character line limit of Fortran, causing the + Absoft compiler to complain. (01/29) + +unix/hlib/mkpkg.inc + Added the following default compile time flags: + + -f Fold all symbol names to lower case. This is needed + for some of the Fortran sources. + + -k Restore all registers when a procedure returns. + This is necessary if Fortran modules are to be + called from C code. + + Mac/IRAF also needs the -z link flag. (01/29) + +sys/gio/nspp/portlib/gridal.f + The equivalence on line 4 was incorrect (or at least ill-advised) + due to a dimension error. The code "mfmtx(1),ifmt(1))" should + have been "mfmtx(1),ifmt(1,1))". (01/29) + +sys/gio/nspp/portlib/z8zpbd.f +sys/gio/nspp/portlib/z8zpii.f + The Absoft compiler didn't want to permit use of DATA to initialize + variables in common so I had to move all the remaining DATA + statements out of z8zpbd.f into run time initialization statements + in z8zpbd.f (01/29) + +unix/boot/spp/xc.c + 1. The routine printargs() was printing one more argument then there + was, due to a <= that should have been a < in a FOR loop. + 2. Modified XC to use GCC for linking. (01/29) + +----------------------- +This took care of all the problems with the sysgen up to the attempt to +link the first task. Trying to build the system task, there was a file +that did not compile. Inexplicably the system hang twice requiring a +reboot, once while linking and the other time while trying to do a mkpkg +on the system task (the system hand requiring a reboot in my first attempt +to link an iraf task!). No idea why this happening. (01/29) + +The above problem was due to the rebuilding of XC after the first sysgen. +libsys.a and libvops.a existed this time so XC was not built NOVOS, which +was no good as the entire kernel needs to be consistent one way or the +other, and I haven't done runtime checks of the iraf libraries yet anyhow. +(01/30) + +unix/hlib/mkfloat.csh + The tar -x flags are "tar -xpf" for BSD systems, and "tar -xof" for + SysV systems. Added a new SET at the top to document the dependency + and set the value to -xof for AUX. (01/30) + +unix/hlib/irafuser.csh +unix/hlib/fc.csh +unix/hlib/cl.csh + Set up two different architectures for Mac/IRAF. These are the + following: + + mf2 Absoft MacFortran II binaries + f2c F2C/GCC binaries + + F2C is a publically available Fortran to C translator, and GCC is + the GNU C compiler. These can be combined to yield an interesting + Fortran compiler constructed from only publically available sources. + This is particularly interesting since we are already using GCC + as our C compiler for A/UX. Initially I am building with the Absoft + compiler but I plan to try F2C/GCC later. (01/30) + +mkpkg +noao/mkpkg +bin.generic + + Edited the root mkpkg file to add entries "mf2" and "f2c" for setting + the bin.mf2 and bin.f2c architectures. Deleted all the Sun + architecture entries. Added a bin.generic subdirectory. (01/30) + +pkg/system/help/lroff/textout.x + Modified to eliminate the ENTRY point. (01/30) + +----------------------- +First successful iraf process link on A/UX - xx_system.e (01/30) + +unix/hlib/iraf.h +unix/hlib/libc/xnames.h + The Absoft compiler does not append an underscore to function names + hence SPP/Fortran function names occupy the same name space as C + names. Probably there are a number of SPP procedure names which + redefine standard C library or other host system names (this has also + been a problem with VMS/IRAF so fixing that system will be another + benefit of dealing with this here). The first such name collision + found is GETPID. Since the SPP getpid was calling the host getpid + an infinite loop would result. This is probably what was causing + the system to hang up when XC was run earlier. (01/30) + + Summary of redefined names (to be added to as I locate them): + + getpid + + All such name collisions are handled by remapping the name in iraf.h + and libc/xnames.h. + +unix/boot/spp/xc.c +unix/hlib/mkpkg.inc + Modified XC to use CC for linking (I was using GCC) and change the + "-/t" link flag in mkpkg.inc to "-/Wl,-t", which instructs CC to + hand off the flag -t to the linker. (01/30) + +unix/os/zzstrt.c +unix/os/zxwhen.c + Digging into the A/UX internals to see how A/UX handles the IEEE + exceptions I find that a function "initfpu" is called during process + startup. It turns out though, that this function is a no-op! + From the assembler it appears that the current version is initfpu(){}. + Must be a placeholder for a future version of A/UX when it will be + done "right". No changes to zzstrt/zxwhen yet until I figure out + how... (01/30) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.MF2 + Uh oh... Absoft compiler bug, and a troublingly simple one. The + memio$sizeof.x procedure is only one line long: + + return (ty_size[dtype]) + + but the Absoft compiler with default optimization enabled is + eliminating most of the code and producing something which does + not even use the ty_size array. Added the file to the mkpkg + special file list to be compiled without optimization. (01/30) + +-------- +unix/hlib/mkpkg.sf.MF2 + On March 27 I finally got a few more hours to play with this port; + looked into the next runtime bug in x_system.e. It turned out to + be necessary to recompile file fio$fgetfd.x without optimization. + Once again, the bug was disturbing as it did not look like an + especially subtle bug. It looked like the compiler was allocating + the same location on the stack in two places and the second reference + would overwrite the first. After working around this one, I tried + running x_system.e and it failed again with another startup bug, + still trying to execute all the code in clopen.x. It begins to + look bad for the Absoft compiler; if we can't get any further than + this I suspect the system will be riddled with optimizer bugs. (3/29) + +-------- +I think it is time to give up on the Absoft compiler, at least for now, and +try F2C instead. (4/3) + +unix/hlib/irafuser.csh +unix/hlib/mkpkg.sf.F2C + + Configured for F2C architecture. (4/3) + +unix/hlib/libc/libc.h +unix/hlib/libc/xnames.h +unix/hlib/libc/knames.h +unix/boot/spp/rpp/ratlibc/ratdef.h +unix/as.mac/zsvjmp.s + Restored the trailing underscores, since F2C adheres to this + convention. (4/3) + +unix/hlib/iraf.h + Commented out the definitions for and,or,not,xor, since F2C uses + the SPP versions (which came originally from UNIX f77). (4/3) + +sys/fmtio/ctotok.x + Local variable numch never used (this is old code so I don't know + why no other compiler has found this). (4/3) + +sys/fmtio/evexpr.y +sys/fmtio/evexpr.x + The second argument (a debug flag) to yyparse (xev_parse) is a + boolean, but xev_parse was being called elsewhere with an integer + argument. Changed to a boolean since the Y*cc code contains many + if (yydebug) constructs. (4/3) + +sys/etc/main.x + FREDIR is a subroutine but was being called as a function in one + place in this file. (4/3) + +sys/tty/ttyputl.x + This file contained a statement call putci (fd, "_") which was + incorrect, since the argument "_" is type char but is supposed to + be integer. (4/3) + +sys/gio/gopen.x + The pointer array graphcap_file was not being used. (4/3) + +sys/pmio/pmplls.x + The second call to pl_plls was missing the ll_depth argument. (4/3) + +sys/qpoe/qpppar.x + The second call to qp_sizeof was missing an argument. (4/3) + +sys/imfort/bfio.x + There was an extra "status" argument to one of the calls to + zsttbf. (4/3) + +unix/boot/spp/xc.c + Built the CC link time flag "-Wl,-t" directly into XC, since it + is needed to link iraf programs and is too much of a nusiance to + have to type when XC is used manually. The flag turns off a linker + warning message warning about inconsistent lengths for commons. + (4/3) + +sys/gio/ncarutil/conran.f + Local variable LNGTHS not used. (4/3) + +pkg/plot/crtpict/t_crtpict.x + A call to gardwrd was missing the maxch argument. (4/3) + +unix/hlib/install + 1. Had trouble with the $hbin/sgi2* $hlib/sgi2* stuff in MODEFILES. + The second did not expand to anything and the string "$hlib/sgi2*" + was left in MODEFILES with the * unexpanded, causing problems later + when appended to a directory prefix. Since there are not supposed + to be any executables in hlib anyhow I deleted the second reference. + 2. In the code which checks the MODEFILES, I added a test to see + if the file exists as named, before looking for it in each of the + directories. Referencing a nonexistent directory can cause the + script to bomb on A/UX (it shouldn't, but it does - a bug in csh). + 3. Had to change /etc/chown to /bin/chown. (4/3) + +pkg/plot/getdata.x + The statement if(nxrows) was incorrect as nxrows is integer. (4/3) + +pkg/xtools/intrp.f +unix/hlib/mkpkg.sf.F2C +unix/as/intrp.c + + F2C failed to produce correct C code for this file (which contains + multiple ENTRY points). Hand edited the C version and added it to + the special file list. (4/3) + +pkg/dataio/fits/fits_wpixels.x +unix/hlib/mkpkg.sf.F2C +unix/as/fits_wpixels.c + + Same bug as above. (4/3) + +pkg/plot/t_graph.x + Variable window declared but not used. (4/3) + +pkg/plot/t_velvect.x + Variable nset declared but not used. (4/3) + +sys/fmio/fmlfundel.x + The two calls to fmio_bind and fmio_errck were both lacking the + fm argument. (5/3) + +sys/ki/kireceive.x + A call to strcpy was missing an argument. (5/3) + +sys/imio/imopsf.x + The call to pl_ssize had an extra unused argument. (5/3) + +sys/etc/pagefiles.x + ttyctrl, which is an integer function, was being called as a + subroutine. (5/3) + +sys/gio/gopen.x + Local string variable graphcap never used. (5/3) + +sys/imio/iki/oif/oifclose.x +sys/imio/iki/oif/oifdelete.x + The integer function protect() was being called as a subroutine. + (5/3) + +sys/plio/plglr.gx + The routine pl_rangerop was being called incorrectly. (5/3) + +sys/plio/plprop.gx + The VOPS routine argt (replace if greater than) was being + called incorrectly in three places. (5/3) + +sys/plio/plascii.x + The subroutine pl_glpi() was being called as a function. (5/3) + +sys/plio/pldebug.x + The integer function pl_l2ri() was being called as a subroutine. + (5/3) + +sys/pmio/pmglp.gx + The routine pl_pixrop was being called incorrectly. (5/3) + +sys/qpoe/qpioopen.x + A call to syserr was being made where syserrs was intended. (5/3) + +unix/os/zzstrt.c + Added a call to "setcompat (COMPAT_BSD)" to be executed upon + process startup. This tells the kernel to use BSD semantics + when executing system calls. This fixed a problem I was having + with ZWMSEC, which would result in the process being killed + with a SIGALRM when the interval timer interrupted, even though + a signal handler had been posted earlier with sigvec. (5/4) + +unix/os/zzstrt.c + Here is another problem that, like the previous one, was very + indirect and hence difficult to track down. The time-task feature + of iraf, e.g., "$imstat dev$pix", when run for the first time + in a new process, would return a clock time such as "-416:+0" + instead of "0:13" or whatever. Thereafter it would be ok, until + the process was restarted. This turned out to be due to the + clock time returned by the first call to ZGTIME being wrong. + The eventual solution was to add a call to TZSET to zzstrt to + initialize the SysV time stuff before any time calculations + take place. What I suspect was happening is that in gmt_to_lst + I was accessing "timezone", which is a global data variable in + SysV, but the value was being changed sometime later in an + indirect call to TZSET. Using a global variable for something + like this that is evidently not constant is a very questionable + feature of SVID (unless it is a bug in A/UX). (5/5) + +unix/hlib/mkpkg.sf.F2C + It turns out that the A/UX version of bcopy does not work (is + destructive) for overlapping arrays, so I had to remove all the + entries for amov$t and bytmov from the special file list. This + problem showed up as a segmentation violation in HELP. (5/5) + + All three of these last bugs were very difficult to track down - + essentially, in each case I eventually just guessed what it might + be, after tracking the problem down to a region of code. + +math/curfit/cvpower.gx + Changed a "amovk$t(INDEFR,...)" to "amovk$t(INDEF,...)". The former + causes a real to be passed where a double is expected. (5/6) + +sys/gio/cursor/grccmd.x + External pr_psio() declared but never used. (5/6) + +sys/gio/stdgraph/stgclws.x + External std_onerror() declared but never used. (5/6) + +sys/libc/qsort.c + The static function qst() was being used before being declared, + resulting in an extern/static declaration inconsistency. (5/6) + +math/gsurfit/gs_f1deval.gx + In the line: call amulk$t (Mem$t[sx], 2., Mem$t[sx], npts) + The real constant "2." was changed to the generic form "2$f". (5/6) + +sys/ki/irafks.x + The "task irafks = onentry" was incorrect since ONENTRY is an integer + function. This was harmless since the purpose of the task statement + was merely to get an iraf main, but I set up a dummy t_irafks task + to avoid the type clash. (5/6) + +pkg/cl/bkg.c + Static function bkg_close() used before being declared static. + Added a static function declaration to the file header. (5/6) + +pkg/cl/debug.c + Same as above, function dd_f(). (5/6) + +pkg/cl/edcap.c + Same as above, function map_escapes(). (5/6) + +pkg/cl/pfiles.c + Same as above, function mapname(). (5/6) + +pkg/cl/cl.x + Same problem as in irafks, above. ONENTRY is a function and should + not be referenced as a subroutine in the task statement. Added a + dummy t_cl procedure to avoid the type clash. (5/6) + +unix/hlib/login.cl + The line + + if (access ("home$loginuser.cl") cl < "home$loginuser.cl" + + causes the following statement to be ignored if the IF is true. + This is a CL bug, but for now the workaround is to add a null + statement ; to the line following the IF. (5/6) + +pkg/cl/gram.c + dumpparams() modified to write to t_out instead of t_stdout. + ccdphot related experiment. (6/21) + +------------------ +Rebuilt HSI with VOS facilities. (7/19) +Started build of NOAO packages. (7/20) + +unix/hlib/irafuser.csh + Added "-Wl,-t" to the HSI_CF flags. This gets rid of a linker + warning about xercom changing size. (7/20) + +-------------------- +System upgraded to V2.10. Started with the SunOS version of the system +from tucana, merged A/UX stuff back in, which many minor changes. (10/01) + +unix/hlib/irafuser.csh + Added -traditional to the GCC flags, to avoid some problems + in the A/UX system includes, probably introduced in the upgrade to + A/UX 2.0.1. (10/02) + +lib/libex.a + After the sysgen I had to do a "ar ts" on this file to regenerate + the symbol table; not clear why this library and no other. Until + the reason is clear, no action. (10/02) + + [This appears to be a bug in AR; it is failing to properly generate + [the symbol table for very large libraries. A manual "ar ts" seems + [to fix the problem, but this bug will cause problems with a sysgen.] + +sys/gio/ncarutil/pwrity.f + Unused variable LEN on line 335. (10/02) + +sys/gio/ncarutil/pwrzi.f +sys/gio/ncarutil/pwrzs.f +sys/gio/ncarutil/pwrzt.f + Variables HIGH,WIDE,WHITE, and LNGTH not used (same problem in + all three files). (10/02) + +math/gsurfit/mkpkg + Contained a statement $ifeq (USE_GENERIC, YES) which was incorrect, + as a lower case "yes" is required since $ifeq uses a simple string + comparison. (10/02) + +math/nlfit/nlzero.gx + Multiple problems; two calls to aclr had an extra argument, but + invalid pointer references too. (10/02) + +mkpkg + The special file list wasn't being used; this was traced to the + use of a symbol link to the iraf root directory. One cannot + reference the iraf root via a link or directory path comparisons + will fail. (10/03) + +sys/fio/fntgfn.x + A pattern such as "*%" would match all filenames, a potentially + disastrous feature if used, say, to delete host filenames containing + the % character. % is dangerous because it is just another character + in a unix filename, but in iraf it is one of the the pattern + matching metachacters (substring editing). The filename template + code was modified to 1) require at least two unescaped % characters + in a pattern for the % to be recognized as a metacharacter, and + 2) to allow the % character to be escaped (the code was supposed + to do this but it was only partially implemented). (10/14) + +---------------------------------------------------------------------- +Summer 1992 - Mac system upgraded to A/UX 3.0. New versions of F2C and GCC +installed. V2.10 upgrade resumed Oct 13-14 1992. There were a number of +minor changes most of which are probably not worth recording here. The +main changes were to "f77" and "xc". f77 is a script in /usr/local/bin +which calls f2c and gcc to act as a Fortran compiler. This was tuned to +improve the integration of f2c and gcc. XC was modified to support gcc +better, e.g. omit .o files from compiles to avoid annoying gcc warnings, +use gcc rather than cc for linking, search the right directories, etc. +The new version of GCC (2.2.1) is quite a bit changed from what I used +last year. I had to make one bug fix to cpp to get source level debugging +to work for .f files compiled with f77/f2c/gcc. + +diff/merged the HSI and did a fresh bootstrap, pretty routine. (10/13) +installed and built tables and noao. (10/13-14) +diff/merged the DEV directory. (10/14) + +unix/hlib/install + Changed the code which checks the ownership and permissions of alloc.e. + On a/ux, ls -l prints the group by default, and this was causing the + old string comparison to fail. (11/21/92) + +unix/os/zfioks.c +unix/os/zfiotx.c + Changed some TCSETAF ioctl's to TCSETAW ioctl's. The TCSETAF ioctl + claims to flush the output buffer before changing the terminal driver + settings, but output data was being lost. Using TCSETAW appears to + avoid this problem. (01/13 1993) + +unix/hlib/iraf.h +unix/hlib/libc/spp.h + Changed the values of INDEFR and INDEFD to the following. + + INDEFR 3.4e38 + INDEFD 1.7d308 + + and IS_INDEFR and IS_INDEFD were changed to + + IS_INDEFR (($1) > 3.3e38) + IS_INDEFD (($1) > 1.6d308) + + This was necessary as the floating point equality tests used to + check for INDEF were failing using F2C/GCC. (01/15 1993) + +math/iminterp/arbpix.x +math/interp/arbpix.x +noao/astutil/t_setairmass.x +noao/digiphot/photcal/evaluate/phprint.x +noao/mtlocal/cyber/cykeywords.x +noao/mtlocal/cyber/t_ridsfile.x +noao/onedspec/ecidentify/ecline.x +noao/onedspec/irsiids/t_bswitch.x +noao/onedspec/irsiids/t_flatdiv.x +noao/onedspec/irsiids/t_flatfit.x +noao/onedspec/irsiids/t_sums.x +noao/twodspec/apextract/peaks.x +noao/twodspec/multispec/fitclean.x +noao/twodspec/multispec/fitsmooth.x +noao/twodspec/multispec/intgauss5.x +noao/twodspec/multispec/peaks.x +noao/twodspec/multispec/solve.x +noao/twodspec/multispec/t_fitfunc.x +pkg/bench/xctest/lintran.x +pkg/images/lib/sigl2.x +pkg/images/tv/display/sigl2.x +pkg/images/tv/iis/src/sigl2.x +pkg/lists/lintran.x +pkg/plot/crtpict/sigl2.x +pkg/proto/t_imscale.x +sys/clio/clgeti.x +sys/clio/clgetl.x +sys/clio/clgetr.x +sys/clio/clgets.x +sys/clio/clglpi.x +sys/clio/clglpl.x +sys/clio/clglpr.x +sys/clio/clglps.x +sys/clio/clputi.x +sys/gio/calcomp/t_calcomp.x + The above files were modified to replace "equals-INDEF" style + constructs with "IS_INDEF" constructs. (01/15) + +unix/hlib/install + Added a number of "rm -f $TEMP" statements to delete any old $TEMP + files before attempting to create new ones. (2/01) + +unix/os/zzstrt.c + Added #ifdef AUX code to enable the IEEE exceptions in the 68882. + There is no A/UX support for this so it had to be done in assembler + by writing to the FP control register. (3/09 1993) + +unix/os/zxwhen.c + Added #ifdef AUX code to decode SIGFPE and print error messages + appropriate to the exception. There is no A/UX support for this so + it was necessary to write assembler to read the FP status register + and test which exception occurred. (3/09) diff --git a/doc/ports/notes.aix b/doc/ports/notes.aix new file mode 100644 index 00000000..203cff47 --- /dev/null +++ b/doc/ports/notes.aix @@ -0,0 +1,456 @@ +# Begin AIX IRAF configuration. 30Mar91. +# RS/6000 Model 530, deskside, 24 Mb RAM 355+670 Mb disk, 24bit color. + +# lslpp -h bos.obj says the following. This means our current OS is +# 3001. From the net I see that the latest release is 3003, so we +# are a bit behind. Also, the system was configured on 19-20 Sep 90. + +Option Name State Event Date/Time Release User Name +-------------------- ---------- ---------- --------- --------------- ---------- +bos.obj INACTIVE COMMIT 02/02/90 03.01.0000.0000 root + INACTIVE APPLY 09/19/90 03.01.0001.0003 root + ACTIVE COMMIT 09/19/90 03.01.0001.0003 root + +unix/as +unix/as.rs6000 + +unix/bin +unix/bin.rs6000 + + Set up AS and BIN directories for the machine architecture "rs6000. + (3/30) + +unix/as.rs6000/zsvjmp.c + +unix/os/mkpkg.sh +unix/os/mkpkg + It won't be easy to generate the assembler version of zsvjmp.s for + the RS6000, so I set up a C version temporarily just to get things + to link. The AIX CC doesn't have a -S flag and neither the AIX + assembler or architecture is simple, so it will take some work to + generate the assembler version. (3/30) + +unix/hlib/libc/iraf.h + Set the iraf root to point to /u1/iraf. (3/30) + +unix/hlib/config.h +unix/hlib/libc/spp.h + Checked that LEN_JUMPBUF was big enough for this machine; it wasn't, + had to increase it from 64 to 65. (3/30) + +unix/hlib/irafuser.csh +unix/hlib/mkiraf.csh +unix/hlib/fc.csh +unix/hlib/cl.csh + Made changes to reflect the new iraf root and architecture. (3/30) + +unix/shlib/mkpkg.sh +unix/gdev/sgidev/mkpkg.sh +unix/boot/rmfiles/mkpkg.sh +unix/boot/mkpkg/mkpkg.sh +unix/boot/rmbin/mkpkg.sh +unix/boot/bootlib/mkpkg.sh +unix/boot/wtar/mkpkg.sh +unix/boot/generic/mkpkg.sh +unix/boot/spp/mkpkg.sh +unix/boot/spp/rpp/mkpkg.sh +unix/boot/spp/rpp/rppfor/mkpkg.sh +unix/boot/spp/rpp/ratlibc/mkpkg.sh +unix/boot/spp/rpp/ratlibf/mkpkg.sh +unix/boot/spp/xpp/mkpkg.sh +unix/boot/xyacc/mkpkg.sh +unix/boot/rtar/mkpkg.sh +unix/os/mkpkg.sh + Replaced all the "cc" calls by $CC, the "f77" calls by $F77, and the + "ranlib" calls by $RANLIB. (3/30) + +unix/hlib/irafuser.csh + Set the architecture (MACH) to rs6000. Added definitions for CC, F77, + RANLIB. (3/30) + +--------------- +Begin bootstrap attempts. (3/30) + +unix/os/mkpkg.sh + Changed the "rm alloc.o" to "rm -rf alloc.o". The AIX CC doesn't + leave the .o file behind. (3/30) + +unix/hlib/irafuser.csh + Added compile time switches -D_BSD -D_NO_PROTO -D_BSDINCLUDES to + make the port go a little easier. (3/30) + +unix/os/zfiomt.c + AIX has modified the unix tape interface as follows: 1) mtio.h is + not tape.h, 2) MTIOCTOP is STIOCTOP (ST = streaming tape), 3) struct + mtop is struct stop, 4) all the MTfoo ioctls are now STfoo, 5), + BSF/BSR are RSF/RSR. Other than that things look very much the + same, just a few gratuitous name changes. (3/30) + +unix/os/zfiopl.c +unix/os/zfiolp.c + AIX CC insists that initializers be enclosed in { }. Added brackets + to the initializers for the variable xnullstr in these two files. + (3/30) + +unix/os/zgtime.c +unix/hlib/libc/kernel.h + Changed the macro define HZ to CLKFREQ. The former is defined in + AIX and was causing a redefined symbol warning. (3/30) + +unix/os/zxhwen.c + Modified the fcancel macro for the AIX stdio.h. (3/30) + +AIX + 1. The problem with pwd hanging the process in an infinite loop + recurred. Once this happens any pwd will hang. Evidently the only + way to clear the problem is to reboot. + 2. Once a task hung and after a while I get an error message about + an NFS timeout, server felis not responding. felis is the system I + am working on, the file access should be direct rather than NFS. + (3/31) + +unix/os/zwmsec.c + AIX likes signal handers to be declared type void rather than int. + Changed the #ifdef SUNOS4 to #ifdef _AIX. (3/31) + +unix/boot/spp/rpp/ratlibc/ratdef.h + Removed the trailing underscores from all the Fortran callable C + externals. AIX C and Fortran externals share the same name space + and both are preceeded by a leading period (rather than underscore) + in the host level symbol table. (3/31) + +unix/hlib/libc/libc.h +unix/hlib/libc/knames.h +unix/hlib/libc/xnames.h + Same as above. (3/31) + +unix/hlib/libc/setjmp.h + Commented out some SunOS #pragma stuff. (3/31) + +unix/mkpkg.sh + Commented out shared library stuff. (3/31) + +unix/hlib/libc/knames.h + Restored the trailing underscore to ushlib_,vshlib_,vshend_ to avoid + a name conflict on vshlib in zzstrt.c. Since these are not Fortran + generated externals we can have a trailing underscore or not as we + wish. (3/31) + +unix/boot/mkpkg/scanlib.c + AIX uses COFF libraries (actually something called extended COFF) + but for some reason they changed the <ar.h> symbols ARMAG, SARMAG, + and SARAMAG to AIAMAG, SAIAMAG, and SAIAAMAG (they changed the R to + IA in each name). It was not clear what was the reason for this + change. A perhaps more justifiable one was that ar_fmag and ar_name + are now elements of the union _ar_name. With these changes the file + at least compiles. (3/31) + +unix/os/irafpath.c + Added #ifdef _AIX conditional to cause bin.rs6000 to be searched. + (3/31) + +unix/boot/spp/xc.c + Modified for AIX. The fortran compiler is xlf, host libraries are + -lxlf, -lm, [-lbsd]. Default no shared library (yet). (3/31) + +unix/hlib/iraf.h + Bitwise intrinsic functions are AND,OR,NOT,XOR (same as SPP!) no + changes needed. (3/31) + +unix/hlib/mach.h + An "od" test appears to indicate that the RS6000 byte ordering is + big-endian (same as Sun) so no byte swapping needed. (3/31) + +AIX + The system IS pretty fast - only takes about 10min for a bootstrap. + (3/31) + +unix/hlib/install + 1. Added #!/bin/csh at the top of the file. The default root shell + is ksh and ksh was trying to exec the file. + 2. Commented out the line with `mach` and added one set to rs6000. + 3. Uncommented the exit 0 to skip the Suntools stuff. (3/31) + +--------------------------- +Start sysgen attempts. (3/31) + +unix/boot/spp/xpp/decl.c + XLF cannot compile integer*[2|4] functions (types char, short, and + long in SPP). Upon enountering a routine declared, e.g., + + integer*4 function foo (args) + + the compiler returns the message + + 1.17 1514-105: (S) Variable functionfoo was declared as + array of type OBJECT-TIME. This type of array is not + permitted in a main program. + 1516-036: (S) Variable foo has undefined type. + + this only happens for integer*2 and integer*4 functions. The + Fortran manual states that only integer functions are allowed + (excluding the other types such as real etc.). The compiler is + clearly treating the declaration as that of a variable rather + than a function. + + This is potentially a very serious problem - we may not be able to + use integer*2 if it is not fully implemented. As a workaround I am + going to try modifying the preprocessor to declare all integer-like + (char,short,int,long) functions as type integer. This should + almost work, but will probably fail at runtime if char or short + functions are passed in the argument list to another procedure. + (3/31) + +unix/boot/mkpkg/scanlib.c + The archive file changes for AIX turned out to be far more extensive + than mere name changes, and I ended up spending several hours + figuring out how AIX archives work and rewriting this file. A major + misconception that it took me some time to get over was that AIX + archives have a linked list of members, whereas UNIX systems have + a sequential list of members. You HAVE to follow the links. (3/31) + +AIX + The AIX implementation of symbolic links is funny, or at least the + "ls" task is. A while back I had to add the -L flag to ls to get + it to list directories pointed to by symbolic links, but with that + flag set it will always follow links, and a command such as "ls -l" + on a link lists the pointed to file, not the link. So far I have + not figured out how to get it to behave like "other" unix systems I + am familiar with (it is not clear AIX is really a unix variant so + I am not sure the "other" is accurate). (3/31) + +unix/gdev/iism75/zrdm75.x + Towards the end of the file there were a couple of calls to MOD + with mixed type arguments (short and int). It was necessary to + add an INT to the short arguments to make both argments integer + before XLF would accept the statements. (3/31) + +----------------- +Completed the first sysgen, although with many errors which I haven't begun +to check out yet. This thing IS fast - the full core system sysgen took +only 2:26. (4/1) + +AIX + A funny thing about the initial sysgen is that it produced libraries + and executables even in cases where there were serious errors. This + may be big system policy (VMS is like this too to some extent) but + it is not standard for unix. It causes problems because the objects, + even though broken, were produced with recent file, dates which + causes utilities like make/mkpkg to be useless for recompilation + following errors. Maybe I can find a way around this but I shouldn't + have to. (4/1) + +unix/hlib/iraf.h +unix/hlib/libc/xnames.h + Added definitions to map the VOS name "getpid" to "xgtpid" at the + host library level. On AIX Fortran and C names share the same name + space, and a name collision on getpid was causing infinite recursion. + (4/1) + +pkg/system/help/lroff/textout.x + This file failed to compile due to a complaint about the declaration + for the argument out to the ENTRY point textout. Rather than look + into this I installed a version of the file from the AUX port which + eliminates the entry point, and the problem went away. (4/1) + +dev/hosts + Added columba to hosts table. (5/22/91 SRo) + +------------------------------------- +Begin AIX/IRAF update to V2.10. (8/10/92) +AIX version 3.2.2. Fortran version 2.2. + +unix/as.rs6000/zsvjmp.s + Added the RS/6000 version of zsvjmp.s. It took over a day to learn + how to program in assembler on this machine (do to limited and + misleading documentation and tools) and about 20 minutes to write the + routine... (8/09) + +------------------------------------- +Performed a diff/merge of the HSI and merged changes into the V2.10 HSI. +The bootstrap proceeded with only minor problems. Started sysgen. (8/10) + +unix/hlib/mkpkg.inc + Still tuning default fortran compilation switches. Current set is + as follows: "-/qhalt=e -/qflttrap -/NQ20000". (8/10) + +sys/gio/gki/gkiclosews.x + In the call to zcall2, "Mems[...]" was changed to "Mems[gki+...]". + (8/10) + +sys/imio/imsetr.x + There were a couple of occurrences of IM_PLFLAGS(im) where the (im) + was missing. (8/10) + +lib/plio.h +sys/plio/* + Assorted changes to resolve type clashes; see notes above from + original port. (8/10) + +sys/qpoe/qpiomkidx.x + Type clash in two calls to min, referencing type short field of + bucket header. (8/10) + +sys/mwcs/mwtransd.x + The AIX compiler did not like a "... * -ltv_1[i]" expression, had to + put parens around the -ltv_1[i] term. (8/10) + +sys/vops/fftx.f + This routine contained a declaration "x(2), y(2)" where the arrays + X,Y are of arbitrary length. Later on in the code the third and + fourth elements of each array were referenced and this caused a + compiler message about an incorrect constant array subscript. + Changed the declaration to "x(*), y(*)". (8/10) + +sys/gio/ncarutil/agdflt.f +sys/gio/ncarutil/agdash.f +sys/gio/ncarutil/aglbls.f +sys/gio/ncarutil/agsetp.f + The AIX compiler doesn't like the CHARACTER*504 declarations in these + files. Had to change these to CHARACTER*500 to get the files to + compile. That could be incorrect, but IRAF doesn't use this code + anyhow (but we will keep it around until the ncar stuff is phased + out). (8/10) + +pkg/images/tv/display/iisofm.x + Added the "int" in "max (int(y[i]),..." to fix a type clash. (8/10) + +pkg/images/tv/iis/ids/idsinit.x + Fixed a type clash in two calls to MIN. (8/10) + +pkg/images/tv/iis/iism70/iissplit.x + Another type clash in a call to MIN. (8/10) + +pkg/images/tv/imexamine/iejimexam.x + Type clash - same one as seen earlier on cephus with the DEC + compiler. (8/10) + +pkg/images/imarith/iccclip.x +pkg/images/imarith/icsclip.x +pkg/images/imarith/icstat.x +pkg/images/imarith/icaclip.x + More type clashes, again the same as seen on cephus. (8/10) + +pkg/plot/t_gkidir.x + Another short/int type mismatch for MIN (that has been that way since + the dawn of time). (8/11) + +noao/lib/mkpkg.inc +noao/lib/mkpkg.sf.AIX3 + + Added artdata/t_mkechelle.x and astutil/t_gratings.x to the NOAO + package special file list. These files have to be compiled with the + optimizer turned off on the RS/6000 or the compiler generates the + following message. + + 1500-008: (S) COMPILER LIMIT EXCEEDED in astgrg: Program too + complicated to be compiled. Compilation ended. Reduce the + complexity of the program and recompile, or lower the level of + optimization and recompile. + (8/11) + +noao/digiphot/daophot/daolib/erf.x +noao/digiphot/daophot/daolib/dpevalpsf.x +noao/digiphot/daophot/psf/dpgaussfit.x +noao/digiphot/daophot/psf/dpsubgauss.x +noao/digiphot/daophot/psf/dpwritepsf.x + This code defines and uses a function called ERF, but ERF is a + Fortran intrinsic function (at least on the IBM compiler). Changed + the name to DAOERF. (8/11) + +noao/onedspec/dispcor/refgspec.x + Mixed real/double in call to MOD. (8/11) + +noao/onedspec/splot/fixx.x +noao/onedspec/shdr.x +noao/onedspec/t_deredden.x + Type clashes in intrinsics, already found and fixed on decstation. + (8/11) + +noao/onedspec/t_deredden.x + This file had another problem on the RS/6000 - syntax error in + expression. Had to add parens in "y * (-2.09002)". (8/11) + +noao/rv/coloncmds.x + The IBM compiler (like the decstation) also complained about cmd_write + being a function but no value was being returned. (8/11) + +noao/rv/fftutil.x + The IBM compiler generated the following messages for this file: + + 1514-047: (S) No initializations for this DATA statement will be + done because of presence of syntax error. + 1515-019: (S) Syntax is incorrect. + + Evidently this was due to the use of the name "data" for an argument + to the procedure fft_fixwrap. There was nothing wrong with the code, + the compiler was in error in this case. To workaround the problem + I changed the name of the data vector "data" to "v" in fft_fixwrap + and in the previous procedure. (8/11) + +noao/imred/ccdred/src/icstat.x + Type mismatch problems, already run into on cephus. (8/11) + +noao/imred/vtel/mscan.x + The function mtneedfileno() was declared boolean but used as an integer + function (which it is). (8/11) + +unix/os/zzstrt.c +unix/os/zxwhen.c + Added #ifdef _AIX code to these routines to enable and handle the + IEEE exceptions. This is quite difficult on the RS/6000, compared + to most systems. There really aren't any IEEE exceptions on this + machine. To catch things like floating divide by zero it is necessary + to compile code -qflttrap, which causes a test-and-branch and trap + instruction to be compiled in line *after every floating point + instruction*. If the floating instruction overflows, underflows, + or whatever, the branch will be skipped and the application generates + a SIGTRAP. The ex_handler routine in zxwhen gets called by the trap. + At that point the floating point status register can be examined to + determine what "exception" occurred. This appears to work but I + am still a bit uncomfortable about all this; the IBM documentation + is not very definitive and thus far I am unable to determine exactly + how the RS/6000 hardware works (e.g., no where does it say exactly + what happens when, for example, floating underflow occurs). (8/11) + +unix/boot/mkpkg/scanlib.c + While relinking the CL to test the exception handling code I noticed + a problem with mkpkg not reading the libpkg.a file. This was traced + to a problem in scanlib.c, used to read AIX archive files. The code + assumed that the first library member followed the file header. This + is normally, but not always the case. In reality the library member + list is a linked list and the offset to the list head is stored in + the file header. (8/12) + +unix/hlib/mkpkg.sf.AIX3 + I had a lot of trouble getting the integer divide-by-zero exception + to work. Finally I determined (by studying assembled code with adb, + not from the info-hider) that the compiler needs to generate extra + instructions to check for a divide by zero. The Fortran compiler + does this by default but the C compiler does not. Studying the + C compiler documentation I could not find a switch to enable this + option, but fortunately a query to usenet revealed that "-qcheck" + was what I was looking for. I inserted this in hlib$mkpkg.inc and + tried to rebuild the CL and got a number of messages such as the + following. + + compile.c: + *** PROGRAM ERROR *** No OTHERWISE or WHEN for execution in SELECT... + *** PROGRAM ERROR *** No OTHERWISE or WHEN for execution in SELECT... + *** PROGRAM ERROR *** No OTHERWISE or WHEN for execution in SELECT... + cc: 1501-230 Internal compiler error; please contact your IBM repr... + + Obviously some sort of compiler bug (C doesn't have these statements). + The workaround was to add only unop.c and binop.c, the CL files that + evaluate arithmetic expressions in scripts, to mkpkg.sf.AIX3. + Fortunately these files compile without the error messages. (8/12) + +unix/os/zgcmdl.c + Modified this file to pick up the argument list on AIX systems. + There is no portable way to do this, one does it by linking an + executable and studying the symbol table with nm and adb, looking + for something which will give the address of the argument list. + So far every system has proved to have a way to do this (on AIX + there is a symbol called p_argv). (8/12) + +unix/os/alloc.c + AIX magtape devices have names like "rmt.1", so I had to change + the code which checks for simple filenames to permit period. + This still excludes names like ../path, since / is not permitted. + (10/17) diff --git a/doc/ports/notes.convex b/doc/ports/notes.convex new file mode 100644 index 00000000..d6582383 --- /dev/null +++ b/doc/ports/notes.convex @@ -0,0 +1,761 @@ +Begin V2.8 CONVEX/IRAF BETA port, 6-8 August 1989. +See also notes from October 1987 ALPHA port (appended). +------------------------------------------------------- + +Summary: + Installation of V2.8 was straightforward except for a nasty bug + involving the host routine BCOPY. I originally tried to use the + C code versions of AMOVC etc. (installed in AS). This caused the + system environment list to become mangled, due to BCOPY modifying + the data it was copying during a copy used to shift by one char + to align the buffer in a REALLOC of the environment buffer. The + speculation is that the BCOPY uses vector instructions, and if the + input and output arrays are aligned to within less than one vector + register length data can be corrupted due to the whole vector + segment being copied at once. + + Aside from that, things came up fine. There were several compiler + crashes with core dumps, but all but one of these were a result of + problems with the IRAF code or system configuration. In general + the compiler seems to be in much better shape than during the + alpha port. + + The final system is configured as follows: the HSI is generic (no + floating point, can run on any Convex), and two architectures are + supported, IEEE and NATIVE, corresponding to the two floating point + architecture options available for the Convex. + + Detailed notes on the modifications made to port V2.8 BSD/IRAF follow. + +unix/as.convex/ +unix/as.convex/zsvjmp.s +unix/bin.convex/ + Added AS and BIN directories to the HSI for the Convex. Installed + the zsvjmp.s written for the alpha port. + +unix/boot/bootlib/osputenv.c + Commented out the call to putenv() - there is no comparable facility + on the Convex. + +unix/boot/spp/mkxc.sh + Fixed a bug - the call to CC was not referencing $HSI_CF. + +unix/boot/spp/rpp/rppfor/declco.f + Replaced by a version that enables IMPLICIT NONE, which is how + undeclared variable detection is handled by the Convex compiler. + +unix/boot/spp/rpp/ratlibf/mkpkg.sh +unix/boot/spp/rpp/rppfor/mkpkg.sh + Replaced the F77 by FC, the Convex fortran compiler. There is no + F77 on the Convex. + +unix/boot/spp/xc.c + 1. Replaced all F77 references by FC. + 2. The link library list for the Convex is + -lF77 -lI77 -lD77 -lm -lmathC1 + 3. Modified the list of directories searched by sys() (for XPP and + RPP) to include /local/bin, /usr/local/bin, and /iraf/local/bin. + Merely another hack until the problem is fixed properly. + 4. Modified the list of directories searched by run() (for FC) to + include /usr/convex, which is where FC resides on the Convex + (another hack until the problem is properly resolved). + +unix/boot/spp/xpp/xppcode.c + This HSI file turned out to have code in it (for converting HMS to + decimal floating) that used floating point. Replaced by an + equivalent routine which uses only integer calculations. + +unix/hlib/iraf.h + The bitwise intrinsics for the Convex are IAND, IOR, IEOR, and NOT. + +unix/hlib/i1mach.f +unix/hlib/r1mach.f +unix/hlib/d1mach.f + Replaced by the Sun versions. + +unix/hlib/mkpkg.sf.CX +noao/lib/mkpkg.sf.CX + Added special file lists for the Convex. At present there is only + one special file, images$geometry/geofit.x, which has to be compiled + at O1 due to a fortran compiler bug. + +unix/hlib/irafuser.csh +unix/hlib/libc/iraf.h +unix/hlib/libc/libc.h +unix/hlib/mkiraf.csh +unix/hlib/mkpkg.inc +unix/hlib/motd + Routine changes for the Convex. Added a #define CONVEX to <iraf.h>. + MACH is set to `convex' in the irafuser.csh. The HSI flags are + + setenv HSI_CF "-O -fx" + setenv HSI_FF "-sa -fx -O0 -na -nv -nw" + setenv HSI_XF "-q -/sa -/fx -/O0 -/na -/nv -/nw -z" + + The MKPKG flags for the IEEE architecture are + + $set FLOAT = "fi" + $set XFLAGS = "-c -q -/sa -/fi -/O2 -/na -/nw -/nv" + $set XSFLAGS = "-c -q -/sa -/fi -/O1 -/na -/nw -/nv" + $set XVFLAGS = "-c -q -/sa -/fi -/O2 -/na -/nw" + $set LFLAGS = "-z -/fi" + + and similarly for the NATIVE (Convex floating point) architecture. + +unix/os/getproc.c + This file, part of the tape drive allocation code, would not compile + on the Convex (it reads the kernel process table which is fairly + system dependent). Commented out the offending code (a status value + is returned indicating that the user does not have any processes) + until the tape drive allocation problem can be resolved for the + Convex. + +unix/os/irafpath.c + Modified to look for files in unix/bin.convex if the machine type + is convex. + +unix/os/zxwhen.c + Added FPE hardware signal codes from <signal.h>. + +mkpkg +noao/mkpkg +bin.ieee/ +bin.native/ +noao/bin.ieee/ +noao/bin.native/ +noao/lib/mkpkg.inc +unix/hlib/cl.csh +unix/hlib/mkpkg.inc + Configured the system for two architectures, IEEE and NATIVE, + corresponding to the two floating point options on the Convex. + The HSI is compiled generic (no floating point dependencies), + hence is runnable on either type of Convex. + +dev/pix.imh +dev/pix.pix +dev/vdm.gki + Installed versions for the Convex (IEEE architecture only!). + +sys/gio/nspp/sysint/encd.f + Fixed a bug in this file - this was fixed once before but evidently + never got merged back into the master system. The problem is the + statement + + if (len (char (ns + ichar ('0'))) .eq. 2) then + + which is evidently unnecessary and which makes an illegal or at + least very questionable use of CHAR. + +sys/gio/ncarutil/sysint/ishift.x +sys/gio/nspp/sysint/ishift.x + Commented out the code for IAND and IOR, since these are intrinsic + functions in Convex/Fortran. + +unix/hlib/install + Changed the machine type from `vax' to `convex'. + +---------- +Basic BETA port completed. (8/8) + +---------- +August 8-10: on site at the VLA testing IRAF on the VLA system, which +includes two Convexes (plus some Suns and VAXes). + +dev/devices + Configured for the Convex. (8/11) + +unix/hlib/login.cl + Added EDT and EMACS as foreign tasks to the default USER package. + (8/11) + +unix/as/zsvjmp.s + An IMAGES task failed during testing while trying to create a type + DOUBLE image, indicating that the MEM common was not double word + aligned. I was able to fix this by setting the symbol __mem_ (the + mem common) to the absolute value 0, which not only double word + aligns the common, it aligns it to any size, and simplifies + debugging by arranging for SPP pointers to directly index process + virtual memory. This technique (setting __mem_ to zero) did not + work for the Convex back when the alpha port was attempted. (8/12) + + [Postscript] Setting mem to zero evidently was the cause of a + number of mysterious program crashes that occurred once the system + was relinked with the new zsvjmp.o with mem=0. The problems went + away when things were relinked with the mem=0 commented out, + indicating that the mem=0 was the problem. There was not time + to check this out, but my guess is that since on the Convex program + memory begins at 0x80000000, setting mem=0 causes very large pointer + offsets which can overflow to negative integer values. I changed + zsvjmp.s to set mem=0x80000000 and the problems seem to have gone + away, and we still get double word alignment. (8/13) + +unix/hlib/ic.csh + +unix/hlib/install +unix/hlib/login.cl +unix/boot/spp/xc.c + Had problems getting IMFORT programs to link. + 1. The solution was to modify XC (FC) to link against the Convex + library -lU77 when linking a host program. This can only be done + when XC is called with the -h flag as the library will result in + a multiply defined loader error message if searched when linking + an SPP program. + 2. The iraf foreign task FC now calls a new cshell script ic.csh, + which calls XC after first determining the floating point option + switch required to link IMFORT programs so that they are consistent + with IRAFARCH. For example, if Convex/IRAF is running the IEEE + binaries, XC will be called with -/fi. + 3. Modified the install script to make a link for ic.csh. The new + task name stands for imfort-compile, and is not called FC because + that is the Convex Fortran compiler. Possibly FC should not be + used as the command name in the USER package either, but I did + not want to change that as it is shown as FC in all the user + documentation. (8/12) + +unix/hlib/cl.csh + Modified to define IRAFARCH if not already defined. (8/12) + +unix/os/alloc.c + Modified to support the Convex tape allocation facilities. Uses + the Convex TPALLOC and TPDEALLOC utilities to perform the actual + tape allocate/deallocate. As a result, alloc.e no longer needs + to have suid-root, although the install script will still install + it that way. Verified that local as well as remote network + allocation works. (8/12) + +pkg/images/imarith/imcmode.gx + IMCOMBINE would fail when presented with a section containing pixels + that all had the same value. The program would go into an infinite + loop in the code at the end of imcmode.gx. Modified to avoid a + floating point equality test, and to add some limit checking in + a couple of places to avoid infinite looping. (8/13) + +unix/hlib/mkfloat.csh + 1. While using "mkpkg [ieee|generic]" etc. on teh Convex, the message + "usage: rm -[rif]" would sometimes appear. This turned out to be due + to calling rm with a null file list when restoring from generic. + The fix was to to delete the file list file in the same command + which deletes the listed files, ensuring that there is at least + one file in the command. + 2. Also reorganized the code somewhat to use only one RMBIN rather + than two, which speeds it up by a factor of two. (8/14) + +unix/os/zmaloc.c + IMFORT programs would die on a memory allocator error: this was + traced to the fact that the custom memory allocator used for + BSD4.3/IRAF was still present in Convex/IRAF (which was built from + the BSD version). Commented out the memory debug code in zmaloc.c + and all was well. We will leave the applications relinked with the + custom memory allocator in for now, since they have already been + tested and did not show any problems. (8/14) + +---------- +ALPHA port notes follow. + +CONVEX/IRAF Port. D.Tody, beginning 26 October 1987. +Using machine in Greenbelt, MD, as follows: +----------------------------------------------------------------------------- + ********************************************************* + WELCOME TO C1EAST + ********************************************************* + SYSTEM MANAGERS: BRIAN CHRISTIANSON & DALE LANCASTER + +C1EAST IS A CONVEX C1-XP MINI-SUPERCOMPUTER. + + - 128 MEGABYTES OF PHYSICAL MEMORY + - 1.5 GIGABYTES OF DISK SPACE + - 40 MFLOPS PEAK PERFORMANCE + +C1EAST IS CONFIGURED WITH: + + - 25.6 MEGABYTES OF DISK BUFFER CACHE + - 64 USER SYSTEM + - ETHERNET + - IMAGEN LASER PRINTER + + - 4.2 BSD UNIX, CONVEX RELEASE 6.1.1 + - VECTORIZING FORTRAN VERSION 3.0 + - VECTORIZING C VERSION Beta 2.0 (vc 1.0 is still around) + - ANSYS VERSION 4.2 +----------------------------------------------------------------------------- + +Snapshot of V2.6 IRAF restored to disk (/extra/iraf) by Convex. (10/26) +Logged in via modem, took a look at Convex/UNIX, configured the IRAF login. + +unix/as -> unix/as.vax +unix/as/zsvjmp.s + Renamed the VAX assembler directory, and set up a new one for the + Convex. Wrote ZSVJMP/ZDOJMP for the Convex. This took a while, + and was one of the harder ones I have done, as the architecture and + the C setjmp/longmp are complex. The machine has a RISC architecture + but nonetheless is fairly complex (and fast and expensive). (11/2) + +unix/os/zxwhen.c + Modified the hardware specific exception codes table for the Convex. + In the process of doing this, discovered that the old code assumed + that hardware codes were distinct, while in fact they can be + numbered similarly for different signals. Modified the ZXGMES + routine to work with hardware codes of the form SIGNAL+HWCODE rather + than the old HWCODE. (11/2) + +unix/boot/spp/rpp/ratlibf/mkpkg.sh +unix/boot/spp/rpp/rppfor/mkpkg.sh + Replaced "f77" by "fc". (11/2) + +unix/hlib/irafuser.csh + Added an "-sa" flag for fc (the Convex Fortran compiler). This flag + prevents static compilation of argument lists and is necessary if C + code is to be called from Fortran. (11/2) + +unix/hlib/libc/spp.h +unix/hlib/libc/libc.h +unix/hlib/libc/iraf.h + Replaced the vax spp.h by the Sun version, which should be good + enough for now, and may even be correct (Convex evidently supports + IEEE floating as well as their native (Cray?) format). Modified + the Fortran COMMON external names in libc.h to add the extra + leading underscore, used by the Convex Fortran compiler to make + common external names distinct from other Forran externals. + Edited the iraf.h file for the new $iraf (= /extra/iraf). (11/2) + +unix/hlib/motd + Modified logo for the Convex. (11/2) + +------------------------------------- +Started up a bootstrap of the HSI. This completed without incident, except +for a great many copies of the following warning messages from FC: + + Obsolete flag '-O' - flag '-no' assumed. + fc: Warning on line X of Y.f: label defined but never referenced. + +Modified HSI_FF (fc flags) in hlib$irafuser.csh to "-O1 -sa -nw" and repeated +the bootstrap starting in the SPP directory. This worked, but now the +optimizer was enabled, and it helpfully produced a zillion of the following +advisory messages: + + fc: Advisory on line X of Y.f: more optimization is possible if this + function call has no side effects. + +Changed the flags to "-O1 -sa -nw -na" to fix this. Tested the main HSI +tasks (rmbin, rtar, wtar, mkpkg, xpp, rpp) and they all passed basic tests!. +(11/2) + +unix/hlib/i1mach.f +unix/hlib/d1mach.f +unix/hlib/r1mach.f + Installed the versions for the Sun (IEEE floating etc.) for now. + This will probably need to be tweaked later. (11/3) + +unix/hlib/iraf.h + Modified the name mappings for the bitwise intrinsic functions (and, + or, etc.). For the Convex they are the same as in VMS Fortran. + Set values of INDEFR and INDEFD, as below. (11/3) + +unix/boot/spp/xpp/xppcode.c + Changed the Fortran mappings of the SPP "char" and "short" type + coercion functions to "int2", which is implemented on the Convex. + (11/3) + +unix/boot/spp/xpp/decl.c + Convex Fortran supports IMPLICIT NONE, so I modified the code which + processes a procedure declaration to output this statement. (11/3) + +unix/hlib/mach.h + Modified the values of various numeric constants. The max exponent + for real is 38, for double is 307. The INDEF values were modified + slightly. The EPSILON values were very similar to those for the Sun. + Byte swapping is no - most significant byte first. (11/3) + +unix/hlib/mkpkg.inc + Set the default compiler flags as follows: + + XFLAGS = "-cq -/O2 -/nw -/na -/nv" + XSFLAGS = "-cq -/O1 -/nw -/na -/sa" + XVFLAGS = "-cq -/O2" + + I have added a new global flag variable XSFLAGS, to be used for the + VOS routines, i.e., for pure system code. XFLAGS is for normal + scientific applications code, which is pure SPP or SPP/Fortran code, + and which would often benefit from vectorization. System code may + call C routines (e.g., the kernel routines), and rarely involves + vector operations. Distinguishing between the two broad classes + of codes is necessary on the Convex in order to permit static + allocation of procedure argument lists in Fortran (SPP) code. + If Fortran code is to call C routines, all arguments must be pushed + on the stack, hence this optimization option cannot be used in VOS + code (flag -sa disables static allocation of argument lists). + + Optimization level O2 includes vectorization, O1 provides only local + and global scalar optimization but no vectorization. The -n flags + turn off various compiler informative and warning messages, which one + normally will not want to see (except perhaps once during development). + These messages are enabled by default only for the VOPS routines. + (11/3) + +iraf$mkpkg +sys/*/mkpkg + Added the line '$set XFLAGS = "$(XSFLAGS)"' to each VOS mkpkg file, + to override the default xflags with the xsflags. In the root mkpkg, + added the $set to the "syslibs" program. (11/3) + +unix/boot/spp/xc.c +unix/boot/spp/mkxc.csh -> mkxc.sh + Modified XC to use "fc" rather than "f77" as the compiler; omitted + the -u flag, since this is done differently for Convex Fortran. + To the "run" code, added /usr/convex to the search path, since that + is where fc is located (a better solution would probably be to put + the path in the #define). (11/3) + +local/bin/ + +local/bin/xc -> $hlib/xc.e (etc.) + Only for the purposes of the port, set up a local/bin directory for + iraf, and put it on PATH in the .login. This will work only for iraf, + but avoids having to make a request to the local system manager. + (11/3) + +------------------------------------ +Started up the first full sysgen. (11/3) + +Summary of results of first full sysgen: + The sysgen ran to completion, but not without problems. The spool file + was 19305 lines, 7205 lines when summarized (the extra stuff was + mostly advisory information about vectorizing the VOPS routines). + There were 23 serious runtime compiler errors of the form: + + fc: >>>>> C O M P I L E R E R R O R <<<<< + >>>>> See your system manager for help <<<<< + Error : Compiler error on line X of Y.c. + + These were distributed as follows: + + #times Error Message + + 16 Error : Compiler error on line 396 of misc.c. + 6 Error : Compiler error on line 155 of allocSReg.c. + 1 Error : Compiler error on line 584 of callintr.c. + + Note that these are errors in the Fortran compiler, not errors in + the Fortran source. The compiler routine which generated the error + is given in the message. These errors prevented compilation of the + affected source file. + + Other errors in the sysgen were [1] fc cannot compile .c files, + hence xc will have to be modified to call cc directly, and [2] in + sys/gio/ncarutil/sysint/ishift.x, functions IAND and IOR are defined + which appear to call themselves recursively, when the macros AND and + OR are expanded. These are dealt with further below. (11/4) + +local/bugs/ +local/bugs/spool.full +local/bugs/spool.bugs + Created a BUGS directory for the Convex and stored therein copies of + all the Fortran sources which cause compiler time compiler failures, + plus copies of the full spooled output from the first sysgen, and an + edited digest of the same containing only the compiler error messages. + Verified that the files cannot be compiled even at optimization level 0. + All files compiled with optimization turned off EXCEPT one, the + sysint/support.f file from gio/ncarutil. (11/4) + +sys/gio/ncarutil/sysint/support.f + The subroutine ENCD in this file contained a statement which would + cause the compiler to crash even with all optimization turned off. + The culprit is as follows: + + if (len (char (ns + ichar ('0'))) .eq. 2) then + + This is a pretty strange statement, and after staring at it for + a while I decided that it would always be false (NS can take on + values only between 4 and 6) and commented it out. Of course it + should not cause the complier to bomb, and I will report it to + Convex, but I think the code is incorrect and should be fixed. (11/4) + +sys/gio/ncarutil/ishift.x + This file contains source for the functions IAND and IOR, written in + SPP and defined in terms of the SPP intrinsics AND and OR, which are + implemented as macro defines in hlib$iraf.h. On the Convex these are + defined as the Fortran intrinsics IAND and IOR, but they are declared + as external functions, hence the Fortran compiler quite correctly + flags them as recursive references and fails to compiler the file. + A simple fix is to replace the calls to AND and OR by calls to the + OSB library functions ANDI and ORI; this is inefficient, but on the + Convex the calls in the NCAR code map directly to the Fortran + intrinsics anyhow, and if this were not the case the routines should + be encoded in assembler and put on the special file list. (11/4) + +unix/hlib/mkpkg.sf + Added the 22 or so files with runtime compiler failures to the special + file list for CONVEX/IRAF. Specifically: + + $set noao = "iraf$noao/" + $set XCP = '& "$xc -cq -/no -/nw -/na &"' + $set XCS = '& "$xc -cq -/no -/sa -/nw -/na &"' + + $special "sys$fio/": fseti.x $(XCS); + $special "math$iminterp/": msifit.x $(XCP); + $special "pkg$dataio/fits/": fits_rheader.x $(XCP) + fits_wheader.x $(XCP); + $special "pkg$images/imarith/generic/": imcmode.x $(XCP); + $special "pkg$images/filters/": t_convolve.x $(XCP); + $special "pkg$plot/": prows.x $(XCP); + $special "pkg$utilities/": t_curfit.x $(XCP); + $special "$(noao)proto/": t_bscale.x $(XCP) + t_imscale.x $(XCP); + $special "$(noao)onedspec/": t_addsets.x $(XCP) + t_bswitch.x $(XCP) + t_dispcor.x $(XCP) + t_flatfit.x $(XCP) + t_sums.x $(XCP) + t_widstape.x $(XCP); + $special "$(noao)twodspec/apextract/": excextract.x $(XCP) + excstrip.x $(XCP) + t_apnormalize.x $(XCP); + $special "$(noao)twodspec/longslit/": ilsetbins.x $(XCP); + $special "$(noao)imred/ccdred/src/generic/": imcmode.x $(XCP); + $special "$(noao)imred/dtoi/": hdtoi.x $(XCP); + (11/4) + +unix/boot/spp/xc.c + Modified to sort out .c source files and compile these separately + with CC (the original XC used f77, which would accept anything). (11/4) + +unix/as/zsvjmp.s + This file contains the code which attempts to set the address assigned + by the linker to the symbol __mem_ (the MEM common in Fortran) to 0. + This is not yet working on the Convex; get multiply defined symbol + errors. I have commented this out for the moment in order to proceed. + (11/4) + +------------------------------------ +Second attempt at a sysgen. Special files all compiled ok, but got loader +errors as noted above, hence no executables. After fixing zsvjmp.s I was +able to successfully link an executable. Tried running it, and wonder of +wonders, it actually ran and produced a prompt! The process did not quite +run correctly, but most of the iraf main stuff was evidently working if we +got that far, so this is encouraging. (11/4) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf + I just remembered that there are a number of VOPS routines coded in + C in the OSB directory, which can be called by any applications code. + Fortran code compiled with static argument lists enabled cannot be + call C routines directly, so until the OSB routines can be recoded + in Fortran for Convex, I have added the -sa switch for applications + code as well as VOS code. (11/4) + +---------------------------- +Third attempt at a sysgen. Deleted all non-HSI binaries and started up a full +sysgen. Should work this time with all the above bug fixes. (11/4) + +The sysgen completed normally, and this time suceeded in producing most of +the executables. The cl runs and most basic things work ok! There are a +number of runtime problems however, which need to be checked out. Looking +over the spooled output I find four more files that caused the compiler to +crash, this time with a core dump, without even a compiler error message. +The message from FC (indicating abnormal termination of a subprocess) is + + fc: System error in /usr/convex/fskel + +The files causing the problem were t_imarith.x in images, and in math, +gsaccum.x, gsrejectd.x, and isresolve.x. Dale, my contact at Convex, +says that there is a major new version of the Convex Fortran compiler, +currently in beta test, and that I should try that. I will proceed a bit +further with the current binaries before starting up another full sysgen, +as these have been running 8-9 hours. (11/5) + +unix/hlib/mkpkg.sf + Added the above four files to the special file list, to be compiled + with optimization level -O1 rather than -O2 (no vectorization). (11/5) + +unix/hlib/mkpkg.sf + After adding the above files to the special file list and resuming + the compile of the gsurfit and surfit packages, more files requiring + special treatment were uncovered. The total is now 34. (11/5) + +----------------------------- +With the math libraries now built, I was able to finish building the IMAGES +package and tried out a few things - IMSTATR was about 3.5 cpusec, IMSHIFTR +around 6+ cpusec. Interactive plotting is not yet working due to some +problem in the CL. Error recovery in the CL is not yet working due to a +problem in ZDOJMP, which has not yet been debugged. Until this is fixed, +any error will cause the CL to die. (11/5) + +unix/boot/spp/xc.c + Modified to use version 4.0 of the Convex Fortran compiler. (11/5) + +------------------------------------ +Sysgen 4. Archived (local/oldfc.arc) and deleted all the old non-HSI binaries. +Ready to start a full sysgen with the new compiler. Will do this in such a +way that the current executables remain intact for people to play with +tomorrow. (11/5) + +local/bugs.newfc + +local/bugs -> local/bugs.oldfc + Set up separate bug directories for the old and new FC. (11/5) + +unix/hlib/sf + +unix/hlib/sf/main.x + +unix/hlib/mkpkg.sf + The new sysgen has thus far compiled all the system libraries without + any compile time errors, hence looks much better (sysgen still in + progress; stay tuned). Even with the new compiler, however, I am still + getting an incorrect warning message "illegal transfer out of IFERR + block" from the iraf main. This was traced to the following code in + the main: + + iferr (...) + ; + or + call xerpsh + ... + if (.not.xerpop()) then goto NN + NN continue + + Even with the optimizer turned completely off, FC is chucking out the + call to XERPOP, causing the error message noted above. Since this is + not an optimizer problem, the only way to fix it was to hack on the + source file. The hacked version is in hlib$sf, and the file has been + added to the special file list for the new-fc. This is a particularly + worrisome bug, as there may be cases such as this scattered all over + the system. (11/5) + +----------------------------- +Sysgen with new FC looks pretty good. There was one fskel coredump (vectorizer +evidently) which I will check out below. (11/6) + +noao/onedspec/sensfunc/mkpkg +noao/onedspec/sensfunc/sfgraphs.x - + Deleted this zero length junk file and fixed up the mkpkg. (11/6) + +unix/hlib/mkpkg.sf + Added an entry for file dataio$reblock/reblock_file.x, which causes + fskel to coredump when compiled with level O2 optimization. Entered + in special file list for level O1 optimization. (11/6) + +unix/as/zsvjmp.s + Finished debugging ZSVJMP/ZDOJMP (this was the cause of the CL crashing + upon logout and during error recovery). The Convex version of this + routine was easily the most complex I have thus far encountered. + The Convex architecture and instruction set is simple, no problem; + the problem here as the complexity of the longjmp() code used to + make ZDOJMP. Instead of saving and restoring the machine context, + the routine actually pops successive stack frames off the machine + stack until it gets back to the stack frame of the ZSVJMP. There + are special cases, e.g., the stack frame pushed by the OS for an + interrupt handler. Twas a mess! (11/12) + +------------------------------------------------- +Resumed work on Convex port on 5 March - don't know how much time I have to +spend on this, but a little anyhow, and maybe the compiler is better. + + Cleaned up the some somewhat; moved some files to a save directory, + deleted a lot of junk test files scattered about the system. + Redid the bootstrap without incident. + Deleted all binaries and started a full sysgen. As of now (5 March + 5 pm) this is still in progress. The CL and x_system.e are up + and look fine. + +Here is the /etc/motd for the current Convex system: +------------------- + ********************************************************* + WELCOME TO C1EAST + ********************************************************* + SYSTEM WINGNUTS: BRIAN CHRISTIANSON & DALE LANCASTER + +C1EAST IS A CONVEX C1-XP MINI-SUPERCOMPUTER. + - 128 MEGABYTES OF PHYSICAL MEMORY + - 1.5 GIGABYTES OF DISK SPACE + - 40 MFLOPS PEAK PERFORMANCE + +C1EAST IS CONFIGURED WITH: + - 12.8 MEGABYTES OF DISK BUFFER CACHE + - 64 USER SYSTEM + - ETHERNET + - IMAGEN LASER PRINTER + - 4.2 BSD UNIX, CONVEX RELEASE 6.1 + - VECTORIZING FORTRAN VERSION 4.0 with In-Lining + - VECTORIZING C VERSION Beta 2.0 (vc 1.0 is still around) + - ANSYS VERSION 4.2 + + CONVEX COVUEshell V7.0 installed. Look in /usr/doc for + new release notices. + + +---------------------------------------------- +Resume testing yet again, this time with a new version of the Fortran +compiler. + +unix/boot/spp/xc.c +unix/hlib/mkpkg.inc + 1. Added a new flag "-N" to XC. Setting this flag causes XC to try to + use the beta test Fortran compiler, which is called as + + /usr/convex/newfc/fc -B/usr/convex/newfc ... + + 2. Added the -N flag to the flag macros in mkpkg.inc. (4/16) + +unix/as/zsvjmp.s +unix/os/zdojmp.c + +unix/os/mkpkg + Replaced the nativ ZSVJMP/ZDOJMP I originally wrote for the Convex + with a much simpler version which "piggybacks" on the C setjmp/longjmp. + The old file is zsvjmp.CONVEX. (4/16) + +---------------------- +Deleted the main system binaries and started a new sysgen. Will use the old +HSI for now. (4/16) + + The sysgen ran to completion with minor problems. One was the + appearance of the following warning message for every file, regardless + of the fact that none of our code uses any Convex Fortran preprocessor + facilities: + + fpp: WARNING: Use of fpp is being phased out; please update + your program by removing uses of #define, #if, #ifdef + + The second problem, more serious, what that a number of modules failed + to compile due to the IMPLICIT NONE statement being out of order; in + pointer functions, the Mem declarations were being output before the + IMPLICIT NONE (see below). (4/17) + +unix/boot/spp/xpp/decl.c +unix/boot/spp/rpp/rpprat/defs +unix/boot/spp/rpp/rpprat/declco.r +unix/boot/spp/rpp/rppfor/declco.f + 1. In decl.c, deleted the code previously added to generate the + implicit none statement. This is not the right place for it, as it + doesn't work for pointer functions. + 2. In declco.r, added code to output theIMPLICIT NONE immediately + after a function or subroutine statement. + 3. In defs, added a switch IMPNONE, which if defined, causes the + IMPLICIT NONE statements to be output. + 4. Processed the fortran for declco.r and put it in rppfor/declco.f. + The defs and declco.r files were not updated on the Convex; I made + the changes on lyra since this is a generally useful mod, and only + copied the processed Fortran to the Convex. (4/17) + + ... incremental sysgen now in progress... + +[Ran all benchmarks except [24]USER, networking, and IMLOADs. No errors.] +[4/18 SRo] +[Ran all test procedures except magtape i/o; no errors. 4/27 SRo] + +hlib/mkpkg.sf + Added the following files to the special file list, to be compiled + with the old fc compiler, to avoid a fatal bug in the new 4.1 fc. + + sys/imfort/clargs.x + sys/imfort/imemsg.x + sys/imfort/imokwl.x + sys/imfort/impixf.x + sys/imfort/imtypk.x + sys/gio/ncarutil/conlib/congen.f + sys/gio/ncarutil/conran.f + sys/gio/ncarutil/conrec.f + sys/gio/ncarutil/isosrf.f + sys/gio/ncarutil/threed.f + sys/gio/ncarutil/velvct.f + noao/onedspec/t_standard.x + + (5/13 SRo) + +[Relink sysgen to replace the missing executables in bin$ prior to having ] +[a tape cut for mailing to NOAO. (5/13 SRo) ] diff --git a/doc/ports/notes.dsux b/doc/ports/notes.dsux new file mode 100644 index 00000000..0f132092 --- /dev/null +++ b/doc/ports/notes.dsux @@ -0,0 +1,282 @@ +Begin port to DECstation 3100. 23 July 1989. +Start with source only archive of VAX/Ultrix system. +[note - rsh/tar hung up mysteriously while loading files onto decstation, +[and had to be restarted]. +-------------------------- + +unix/as.mips + +unix/bin.mips + + Created AS and BIN directories for Dec/MIPS. (7/23) + +unix/as.mips/zsvjmp.s + Prepared a dummy version of zsvjmp for the moment. All this does is + set the output status value to zero. (prepared by using the compiler + to generate the assembler source for a small C program). (7/23) + +unix/boot/spp/xc.c + It appears that for some reason, the MIPS C compiler or linker will + not accept a file with a .e extension as the output (-o) file. + Had to modify XC to output a .E file temporarily, which is renamed + to .e after the link. (7/23) + +unix/mkpkg.sh +unix/os/mkpkg.sh +unix/shlib/mkpkg.sh +unix/boot/bootlib/mkpkg.sh +unix/boot/generic/mkpkg.sh +unix/boot/mkpkg/mkpkg.sh +unix/boot/rmbin/mkpkg.sh +unix/boot/rmfiles/mkpkg.sh +unix/boot/rtar/mkpkg.sh +unix/boot/spp/mkpkg.sh +unix/boot/spp/mkxc.sh +unix/boot/spp/rpp/mkpkg.sh +unix/boot/spp/xpp/mkpkg.sh +unix/boot/wtar/mkpkg.sh +unix/boot/xyacc/mkpkg.sh +unix/gdev/sgidev/mkpkg.sh +unix/bin.mips/fixnames + + Modified all the mkpkg.sh files to generate .E files. Added a + fixnames script to bin.mips to rename any .E files therein to .e, + and added code the the root mkpkg.sh to call fixnames at the + end of the bootstrap. (7/23) + +unix/hlib/cl.csh +unix/hlib/mkiraf.csh +unix/hlib/install +unix/hlib/libc/iraf.h + 1. Modified the iraf root pathnames in these files. + 2. In the install, also deleted the entries for edsym.e to avoid + an error message during the install. (7/23) + +unix/hlib/extern.pkg + Commented out the stsdas entries. (7/23) + +unix/hlib/mkpkg.inc +unix/hlib/irafuser.csh +unix/hlib/mkpkg.sf.MIPS + Set MACH to MIPS. Added a case for machine type MIPS. Added an + empty special file list. (7/23) + +unix/hlib/motd + Modified to say DECstation/IRAF. (7/23) + +unix/os/zxwhen.c + Added a #ifdef mips section with some hardware exception codes for + the MIPS. (7/23) + +-------------------- +Start bootstrap. (7/23) + +unix/hlib/irafuser.csh + Linking of RPP produced a "gp relocation out of range" error message. + It was necessary to compile with "-G 0" (no global variables indexed + by global pointer) in order to get this to go away. (7/23) + +unix/boot/bootlib/mkpkg.sh + Modified to mv libboot.a to $hbin (../../bin) rather than $hlib, + since the libboot.a in $hlib is a symbolic link. (7/23) + +-------------------- +Start sysgen. (7/23) + +unix/as/gkiprint.o + +unix/hlib/mkpkg.sf.MIPS + The file gkiprint.x would fail with a slew (like, 700) syntax and + other errors. There was nothing wrong with the code and the few + workarounds I tried had no effect. I finally managed to compile + the file by breaking it up into half a dozen pieces, compiling each + separately, and linking the resultant objects into a single large + object gkiprint.o. Since this bug will probably go away before long + I merely placed the manually generated object file in AS, and made + an entry in the special file list to use this object. (7/23) + +unix/as/imsetr.f + +unix/hlib/mkpkg.sf.MIPS + In this case the file imsetr.f would cause the first pass of f77 + to core dump (not an optimizer problem). I had to hack the fortran + code to workaround the bug, placing the hacked file in AS. The + offending statement was: + + memi(im+33) = and (memi(+33) , not(1 )) + + the following version is ok: + + i = not(1) + memi(im+33) = and (memi(+33) , i) + + The bug must have something to do with the bit intrinsics. (7/23) + +unix/as/fseti.f + # FIO +unix/as/fmfcache.f + # FMIO +unix/as/fmlfbrd.f + +unix/as/fmlfbwr.f + +unix/as/fmlfcopy.f + +unix/as/fmlfundel.f + +unix/hlib/mkpkg.sf.MIPS + Modified to work around the same compiler bug as above. The NOT of + any compile time integer constant used in an expression seems to + always cause a core dump. (7/23) + +unix/boot/spp/xc.c +unix/hlib/mkpkg.inc + 1. In the first sysgen, x_images.e failed to link with a "gp relocation + out of range" type problem. Recompiling the IMAGES package libpkg.a + with -G 0 fixed the problem. + 2. Passing this flag through XC, however, was not possible without + a code change to XC, as there was no way to pass two consecutive + arguments such as "-G 0". In order to support this XC was modified + to permit flags of the form "-/#flag", which are passed as "flag". + This is similar to "-/flag" which is passed as "-flag", except that + it allows flags with no "-" to be passed. Hokey, but backwards + compatible and it solves the problem. (7/23) + +----------------- +Started sysgen of NOAO packages. (7/23) + +noao/lib/database.o + +noao/lib/mkpkg.inc +noao/lib/mkpkg.sf.MIPS + The database.x file in DTOI would cause the compiler to become + terminally confused, as with gkiprint above. Manually constructed + the database.o object, placed the latter in noao$lib, and modified + the NOAO special file list to use this object rather than try to + compile the file. (7/24) + +unix/hlib/config.h +unix/hlib/libc/spp.h + Set the size of the ZDOJMP jump buffer to 84 (83 ints for the jmp_buf + buffer plus 1 for the address of the status variable). (7/24) + +unix/as.mips/zsvjmp.s + Wrote and installed the real zsvjmp.s. (7/24) + +------------------- +Sysgen/relink with new zsvjmp. +Everything appears to work now. (7/24) + +bin.mips +noao/bin.mips + Stripped the BINS to save disk space, as it appeared that the symbol + table information is unusually large on the decstation. (7/25) + + Normal Stripped + + core system bin 21.5 16.0 + noao bin 18.0 12.3 + ------- -------- + 39.5 28.3 + +unix/as/zsvjmp.s + Modified slightly to eliminate a delay slot. This failed to work + at first and I eventually discovered that the reason was that the + *assembler* was modifying my assembler code, reordering the + instructions and inserting nop's in delay slots, producing invalid + code! I had to add a "noreorder" directive to get it to leave the + code alone. (7/25) + +unix/os/zxwhen.c + As a first step in testing exception handling I tried the following + in the CL: + + cl> = 5 / 0 + + This caused the CL to core dump on the uncaught signal SIGTRAP. + On all other unix systems thus far, integer divide by zero has been + mapped to SIGFPE, but on the MIPS it is a trap. Modified zxwhen.c + to map SIGTRAP onto the VOS exception class X_ARITH. (7/25) + +unix/os/zzstrt.c + Added the following #ifdef mips code to zzstrt, to enable the overflow, + invalid, and divzero IEEE exceptions: + + set_fpc_csr (get_fpc_csr() | 07000); + + The {set|get}_fpc_csr() routines appear to be undocumented but I + found them anyhow by searching the symbol tables of the host libraries + in /usr/lib. (7/25) + + [LATER] Well, enabling the IEEE exceptions works, but somehow this + is making the software misbehave in a way I do not yet understand + and do not have time to look into right now. Completely unrelated + things like "stty vt100", "imheader dev$pix" fail mysteriously with + the IEEE trap enable bits set in the FPU context and status register. + This doesn't make any sense and we will have to do without the IEEE + traps for now. Possibly this is due to a bug in the OS which will + go away in the next release. + +unix/hlib/mkfloat.csh + The code in this script which lists the tar archive back with + "tar -tf", to verify that a good archive has been generated before + deleting the files, does not work on the DECstation. The problem + is that tar -tf produces different output here than on the other + systems; the directories are listed as files in addition to the files. + I had to change the + + tar -tf + to + tar -tf | grep -v '/$' + + to get things to work. (7/26) + + +unix/bin.mips +noao/bin.generic +bin.generic + Stripped all the executables (HSI, IRAF, NOAO). + Made IRAF and NOAO generic. (7/26) + + +Summary of various problems encountered. +------------------- + + fortran compiler core dumps + c compiler core dumps + cannot -o to a .e file + rsh|tar hung once + NO ADB!! + dbx dies occasionally with internal error: stack overflow + 2 user limit on logins - prevents even having two windows + open from Sun with a different rlogin session in each. + System is very fast single user; much slower if anything else + is running on the machine (memory too small?). + System crashed on first day of testing with 2 users busy doing things. + (there did not seem to be a system message file). + Some routines which use floating point produce different results on + the MIPS than on other systems. Examples thus far are the FITS + programs, and IMHISTOGRAM. No doubt more will be discovered. + IEEE exception handling is not working currently. + + +---------------- +V2.8BETA system frozen and archived. (7/26) + +---------------- +Begin upgrade to V2.9ALPHA, 6 DEC 1989. +Working with newly arrived IRAF DECstation 3100! + + Installed the V2.8ALPHA HSI. + Merged in all relevant V2.9 modifications to the HSI. + +unix/boot/spp/xc.c + Changed the syntax "-/#foo" -> "foo" to "-//foo" -> "foo" for + escaping command line arguments to XC. (1/6) + +---------------- +Started a bootstap. (1/6) + +mkpkg + Extended the mkpkg summary filter in the root mkpkg to filter out + the great number of "local variable iyy never used" warning messages + produced by the MIPS compiler. (1/6) + +pkg/plot/t_graph.x + This file contained a routine im_projection equivalent to a routine + of the same name in file improject.x, resulting in two externals of + the same name in the package library. (1/7) + +unix/boot/spp/xc.c + To avoid a circular reference problem in the DS3100 Fortran libraries, + which causes an undefined symbols "s_abort" problem when linking some + programs, added a second search of libF77 to the end of the XC host + library link list, after the -lm. (1/7) diff --git a/doc/ports/notes.freebsd b/doc/ports/notes.freebsd new file mode 100644 index 00000000..35cb36e0 --- /dev/null +++ b/doc/ports/notes.freebsd @@ -0,0 +1,215 @@ +FreeBSD/IRAF (PC-IRAF) port +Tue Jul 16 18:38:15 MST 1996 +------------------------------------------------------------------------------- +FreeBSD lepus 2.2-960612-SNAP FreeBSD 2.2-960612-SNAP +Gateway P5-166, 64 MB RAM, 2 GB disk, Matrox MGA, 21" Vivitron +HP DAT, SMC PCI-bus 10 Mb/s Ethernet + +This port to FreeBSD is being done using IRAF V2.11DEVELOP and the Linux HSI. +The goal is to produce a single version of IRAF which can run on both Linux +and FreeBSD, using separate architectures for each. +------------------------------------------------------------------------------- + +mkpkg +noao/mkpkg + Added "freebsd" architecture. (7/16) + +bin.freebsd + +noao/bin.freebsd + + Added "bin.freebsd" bindirs. (7/16) + +unix/hlib/motd + This IRAF release will be called "PC-IRAF" rather than FreeBSD/IRAF, + since the intent is to support all PC-IRAF operating systems as + architectures. (7/16) + +unix/hlib/irafuser.csh + 1. Now supports both Linux and FreeBSD. + 2. Compile flags are -O -DBSD -w -Wunused. + 3. Link flags -static -lcompat. Currently using the compatibility + library -lcompat for rexec (and ftime). BSD doesn't like rexec but + there doesn't appear to be much of any alternative. (7/16) + +unix/hlib/cl.csh +unix/hlib/fc.csh +unix/hlib/install + Modified to autosense the system type and to support both Linux and + FreeBSD. (7/16) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.FBSD + Added support for FreeBSD. (7/16) + +unix/as.freebsd/zsvjmp.s + Using the Linux (i386) version of this file; the only difference is + that the jump point is _setjmp for BSD, ___setjmp for Linux. (7/16) + +unix/os/irafpath.c + Added "freebsd". (7/16) + +unix/os/zfaloc.c +unix/os/zfiobf.c +unix/os/zfioks.c +unix/os/zfiotx.c + Added <unistd.h>, lseek type changed to off_t. This appears to be + the new standard. (7/16) + +unix/os/zxwhen.c + Extensive changes/additions for BSD. FreeBSD appears to have fairly + complete exception handling facilities (including the IEEE exceptions). + Linux was weak in this area. (7/16) + +unix/boot/mkpkg/host.c + BSD does not use ELF, but does use ranlib. Symbolic link resolution + appears to be required. (7/16) + +unix/boot/spp/xc.c + Since both BSD and Linux are GNU/F2C-based XC is very similar for + both systems. Minor changes to support FreeBSD, such as adding + -lcompat to the host libraries, and disabling the ELF/aout stuff + except for Linux. (7/16) + +unix/boot/spp/xpp/xppcode.c + Changed "warn" to a static function. BSD has a library function + called warn, caused linker conflicts. (7/16) + +pkg/dataio/fits/fits_wheader.x +pkg/images/filters/median.x +pkg/images/imarith/icscale.x +pkg/images/tv/imexamine/iepos.x +pkg/xtools/gtools/gtcolon.x +pkg/xtools/inlfit/ingresults.gx + Assorted bugs detected at compile time by F2C. (not sure the warnings + are getting disabled). (7/16) + +sys/imfort/bfio.x + In zfaloc, the first arg to strpak was changed from fname (a Fortran + character variable which was incorrect) to sppname. (7/17) + +noao/artdata/lists/stcolon.x + Variable lumfuncs not used. (7/17) + +noao/digiphot/daophot/psf/dpmkpsf.x + dp_addstar called incorrectly. (7/17) + +noao/onedspec/dispcor/dcio.x + Variable axis never used. (7/17) + +noao/onedspec/identify/idshift.x + Function/subroutine confusion. (7/17) + +noao/onedspec/sensfunc/sfoutput.x + Variable axis never used. (7/17) + +noao/onedspec/splot/getimage.x + gt_setr called with an integer value. (7/17) + +noao/onedspec/t_fitprofs.x + pargi called with boolean argument. (7/17) + +noao/rv/rvfgauss.x + A couple of _old varables were declared but never used. (7/17) + +noao/twodspec/apextract/apids.x + Variables ra, dec declared double but used as both pointers and + doubles. (7/17) + +noao/twodspec/longslit/transform/t_transform.x + Variable axis not used. (7/17) + +noao/imred/ccdred/src/t_ccdmask.x + Procedure cm_mask called with wrong arguments. (7/17) + +noao/imred/ccdred/ccdtest/t_mkimage.x + Variable pixtypes not used. (7/17) + +noao/imred/dtoi/hdicfit/hdicebars.x +noao/imred/dtoi/hdicfit/hdicfit.h +noao/imred/dtoi/hdicfit/hdicgfit.x +noao/imred/dtoi/hdicfit/hdicggraph.x + Various type related problems. (7/17) + +dev/hosts + Updated entry for lepus, which is no longer an A/UX system. (7/19) + +unix/boot/mkpkg/host.c +unix/boot/mkpkg/main.c +unix/boot/mkpkg/mkpkg.h +unix/boot/mkpkg/scanlib.c + Various mods to support source code debugging. Mkpkg now supports + the -x flag. If this is seen -x will be added to all flag defines + (XFLAGS, XVFLAGS, LFLAGS). Mkpkg, whenever a library is referenced, + will check for a debug version of the library. For example if the + library is libsys.a the debug version is libsys_p.a. Calling mkpkg + as "mkpkg -x" automatically causes the _p.a versions of all libraries + to be updated, creating them and doing a full recompile if necessary, + without having to edit any mkpkg or mkpkg.inc files to modify the + compile/link flags. The normal and debug versions of all libraries + are maintained independently. (7/20) + +unix/boot/spp/xc.c + XC was also modified to support debugging via the -x switch. Defining + the -x switch causes it to be passed on to xpp, rpp, and f77 which + is necessary to compile for debuging. The -x switch also causes XC + to look for _p.a (debug) versions of any libraries. For example, + if the command line is "-x libpkg.a -lstg" then XC will look for + libpkg_p.a and libstg_p.a, falling back on the normal versions of + the libraries if the debug versions are not found. (7/20) + +unix/hlib/f77.sh + If the -x switch is given the intermediate C file is edited to replace + any "file.f" references with "file.x". (7/20) + +unix/boot/spp/rpp/rpprat/common +unix/boot/spp/rpp/rpprat/errchk.r +unix/boot/spp/rpp/rpprat/initkw.r +unix/boot/spp/rpp/rpprat/outdon.r +unix/boot/spp/rpp/rpprat/ratfor.r + RPP was modified to generate "#line file.x" statements in the output + Fortran code to support source code debugging. This is done only if + the -x flag is set. F2C supports #line but most Fortran compilers + do not. (7/20) + +unix/boot/spp/rpp/rpprat/Makefile + Added a call to sed to workaround a ratfor bug (generates an + unreachable statement). This makes "make fort" fully automatic. + This is used to generate the .f files from the .r files. (7/20) + +-------------------------- +The PC-IRAF (FreeBSD) HSI was erased in a botched rdist update from tucana. +Reloaded from a 3-Sep-96 backup tape. Tue Oct 29 16:05:37 MST 1996 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +-- diff --git a/doc/ports/notes.i386 b/doc/ports/notes.i386 new file mode 100644 index 00000000..0ab05de0 --- /dev/null +++ b/doc/ports/notes.i386 @@ -0,0 +1,1124 @@ +Sun 386i (RoadRunner) Sun/IRAF port. Begin 5 Oct 88. +-------------------------------------------------------- + + o Created the IRAF root directory at /files/vol/iraf in accordance + with the recommendations in the administration guide for 3rd party + software. + + o Moved in a copy of iraf from tucana. + o Installed the SunOS 4.0 mods made earlier on taurus. + +sun/hlib/libc/iraf.h + Manually edited for the new root. + +/etc/fstab +/usr/include/iraf.h + + Installed a symbolic link for iraf.h in /usr/include. In order to + do this on the 386i, I had to remount the /usr file system read-write; + it was read-only at first for some reason. + +unix/bin.i386 + +unix/as.i386 + + Added these directories. "mach" is "i386" on the 386i. + +unix/as.i386/zsvjmp.s + Figured out enough of the 386i assembler to write a stubbed out + zsvjmp routine. Will have to write a real one later. + +unix/sun/Makefile + Changed the float option to -fsingle as for the Sun4. + Added a "-o `mach` = "i386" condition to test for SunOS 4.0. + +------------------------ +Compiled GTERM and IMTOOL. They seem to work!. +Did a bootstrap. Completed normally except that the library scanning code +in MKPKG did not compile, no doubt due to the COFF objects on the 386i. +Did an INSTALL to install the iraf links, GTERM, IMTOOL, etc. + + o Configured /usr/local. + o Reconfigured my .sunview file (used to be .suntools) to use GTERM and + IMTOOL as on the Sun-3; came up ok. + +PROBLEMS + Window refresh is abysmally slow on the 386i. + Perfmeters sometimes core dump and die after running fine for a while. + +unix/hlib/irafuser.csh + Deleted the "-fsoft" entries - not used on the 386i. (10/19) + +unix/boot/mkpkg/scanlib.c + Had to add + + #ifdef i386 + #define PORTAR 1 + #endif + + at the top of the file to get include <ar.h> to define the appropriate + library format. Also, on the 386i, the code which scans the library + has to deal with the following peculiarities: + + o The first "file" in the archive is a dummy entry containing + symbol information; the name field is null, hence the code + can skip this entry by checking for archive members with + null-string names. + + o The names of the archive members now have a trailing /, + e.g., "file.o/", followed by blank padding. Previously + only the blank padding was there. I modified the code to + accept either / or blank as the name delimiter. + + I also added some debug code which prints the name and date of each + archive member as the library is scanned, if debug > 1. These + changes should be portable to other systems. (10/19) + +SUNBUG - f77 + The command "f77 -c -O file.c" produces the following: + + Assembler: /tmp/optim.01231.5.s + aline 1 : Warning: cannot field update- '.file' not + on first line + + This prevents use of f77 to compile C files, at least on the 386i! + (It works if the optimizer is not used). Will have to modify XC to + use CC instead. (10/19) + +unix/boot/spp/xc.c + 1. Hacked XC to use F77 only to compile Fortran source files, and to + use CC for everything else. + 2. Added /usr/local/bin to the list of directories to be searched for + commands like XPP and RPP. + 3. Changed the defined names from "xpp.e" and "rpp.e" to "xpp" and + "rpp", since this is how they appear in /usr/local/bin. (10/19) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.I386 + + Added code for case FPU = i386 (not really an fpu), plus a special + file list for the 386. (10/19) + +unix/hlib/cl.csh + Added a case for the i386, similar to that for sparc. (10/19) + +--------------------- +Sysgen completed with a half a dozen files with errors, but no executables +were linked due to a library conflict with the dummy zsvjmp.s I wrote. (10/20) + +unix/as/zsvjmp.s +unix/as/zzdebug.c + Wrote a ZSVJMP.S for the 386i (80386), plus a little test program to + make sure it works. (10/20) + +--------------------- +Linked x_system.e and it runs on the first attempt!! (10/20) +Start another sysgen - ignore files that didn't compile for now, until we +see which executables they prevent from being linked. + +sys/vops/acht.gx + On the 386i, statements of the form "b[i] = a[i]", where B was + COMPLEX and A was INTEGER*2, revealed a compiler error in the + 386i Fortran compiler (the error was a syntax error in the assembler + code input to the system assembler). I decided that assigning + an integer*2 to a complex in a straight assignment wasn't a very + safe thing to do anyhow, so the generic source was changed to + generate "b[i] = complex(real(a[i]),0.0)" instead, whenever B + is complex and A isn't. (10/20) + +sys/vops/amod.gx + No changes here, just logging the compiler bug. The code is as + follows: + + do 110 i = 1, npix + c(i) = mod (a(i), b(i)) + + where A, B, and C are integer*2. Once again, the compiler is + generating incorrect assembler for this case, causing a "syntax error" + from the assembler (evidently, because of the rather restrictive + instruction set of the 80386). I am not sure there is anything in + IRAF that uses this routine anyhow, so we will try to ignore it for + now. (10/20) + +unix/hlib/mach.h + 1. Set the BYTE_SWAP[24] flags to YES - forgot to do that before the + sysgen, unfortunately. + 2. Changed MAX_EXPONENTD and related variables (MAX_DOUBLE, INDEFD) + to reflect the fact that the max exponent for IEEE double is 2**1023 + or 10**307. (10/21) + +unix/hlib/mkpkg.sf.I386 + Commented out the entries for as$ishift.s for now. (10/21) + +noao/astutil/pdm/pdmstatistics.x pdmstats.x +noao/digiphot/apphot/center/apcentercolon.x apcencolon.x +noao/digiphot/apphot/center/aprefitcenter.x aprefitcen.x +noao/digiphot/apphot/center/apfitcenter.x apfitcen.x +noao/proto/t_mkhistogram.x t_mkhgm.x + Shortened the names of the above source files. These will not compile + on the 386i, which has a limit of 14 characters for the names of + modules in object libraries (which are COFF format libraries from + Sys V, hence the 14 char limit). (10/21) + +unix/hlib/mpkg.sf.I386 + Turned off the optimizer for conrec.f, srface.f, pwrzi.f. An apparent + optimizer bug was causing declaration of an external which would cause + an unsatisfied exernal error at link time. (10/21) + +pkg/images/iminfo/t_imstat.x + Replaced some ==INDEF constructs by IS_INDEF, and took the n=n+1 out + of the inner loop, since it isn't needed. (10/21) + +unix/boot/mkpkg/host.c + Disabled the ranlib (library rebuild) on the 386, since it uses COFF + type libraries, which don't need to be ranlib-ed. (10/21) + +unix/hlib/mach.h + For the moment, restored the former, incorrect for IEEE, values of + the machine constants for type double. There are obviously a number + of bugs in the system where code assumes that the values for types + real and double are the same. This will have to be addressed later + when there is more time to debug this. (10/21) + +unix/hlib/mpkg.sf.I386 +unix/as/amods.s + + Edited the assembler for the VOPS amods routine (to work around the + compiler bug mentioned above) and placed the assembler version in + AS and added the file to the special file list for the 386i. (10/21) + +------------------- + As far as I know, all bugs are now fixed and the system is up on + the 386i, although there is still a lot of work to be done on improving + the installation procedures, optimization to reduce paging, etc. + A full system mkpkg/relink (no compiles) took 23 minutes on the 386i. + (10/21) + +buglog + Cannot access 5!mta, although page 5!dev$devices works. (10/22) + (May be VOS bug not 386i bug?). + +sys/fio/mkpkg +sys/fio/ungetci.x + + Added a new routine UNGETCI to FIO. Since there is an ungetc for getc, + there should be an ungetci for getci. (10/22) + +buglog + The statement + + if (1) + ... + + does NOT result in any errors or warnings from the Fortran compiler. + (10/22) + +unix/hlib/libc/*.h +unix/hlib/irafuser.csh + In order to remove the need to modify anything in /usr (which wants + to be mounted read-only in the latest SunOS), I modified the HSI to + call the C compiler in such a way that $hlib/libc is searched for + include files, as well as the system directories. This is done via + the HSI_CF environment definition in $hlib/irafuser.csh, which adds + $hlib/libc to the list of directories to be searched. The C compiler, + presented with #include <iraf.h>, will load $hlib/iraf.h To avoid + having the compiler resolve files like <stdio.h> etc. to $hlib/libc + as well, I had to prefix the names of all these files with a "u", + e.g., "ustdio.h", modifing the references in <iraf.h> as well. + Since the files are referenced only in <iraf.h>, this change should + be completely transparent. (10/23) + +sys/memio/salloc.x + Hard to believe, but it appears that buffers allocated on the stack + are not necessarily aligned to TY_DOUBLE (proper alignment would + result for anything smaller). (10/24) + +unix/boot/spp/xc.c + Added a link time -align mem_ switch to double word (actually page) + align the MEM common. (11/11) + +unix/os/irafpath.c + Added a #ifdef i386 case. (11/14) + +unix/boot/mkpkg/host.c + Added support for IRAFULIB (a user defined private library) to + the $checkout and $checkin directives. For example, in + + $checkout libex.a lib$ + + if file libex.a is found in IRAFULIB, that version is checked out, + rather than the one in the system directory lib$. (11/15) + +------------------------- +Log of changes for the Sun/IRAF shared library facility. This was developed +on the 386i initially. This log was written on 28 December and summarizes the +revisions made during the period Tue 20 Dec to Wed 28 Dec 1988. + +[background] + Although SunOS 4.0 supports dynamic linking, mapped files, and shared + libraries, currently only the C compiler can generate position + independent code (PIC). Sun Fortran does not currently support shared + libraries since it cannot yet generate PIC code. In any case, PIC + code executes less efficiently than nonrelocatable code, and the + dynamic linking required by relocatable shared libraries slows down + process startup. + + Our strategy is to implement the equivalent of a shared library by + building a *nonrelocatable* shareable image (executable process), + and mapping it to a fixed address in the address space of client + processes at process startup time. A transfer vector is used to + vector procedure calls to arbitrary offsets in the shared image, + allowing new shared images to be installed without having to relink + client processes (in most cases). The mapped file feature of SunOS + 4.0 is the only thing essential for this scheme to work, and it is + the lack of the mapped file capability which has prevented us from + implementing a shared library up until now. + + Even when (and if) Sun/Fortran eventually adds support for PIC and + shared libraries, the mapped image approach we have followed here + may still be the best choice. Despite the slight loss of execution + efficiency caused by the use of position independent code, use of + PIC is not likely to be a serious drawback. More serious drawbacks + derive from the use of global data, and dynamic linking at runtime. + Dynamic linking, e.g., to set the address of a global variable for + which the location is not known until runtime, requires the + modification of every text page containing code which references the + variable. Aside from the obvious time penalty during process startup + while this linking and page copying is taking place, modification of + a text page defeats shared text, increasing memory and paging + requirements. + + Trying to avoid this problem in a relocatable shared library can be + very difficult, requiring modification to source code if it can be + done at all. The nonrelocatable approach we have followed guarantees + sharing of the entire text of the shared image and does not require + any changes to system or applications source code (provided no + interfaces have been violated). There are other advantages which + derive from the facility being part of the Sun/IRAF HSI, e.g., if + iraf is linked on an NOAO node and later installed with a different + root on a remote node, there is no problem locating the shared library + at runtime. Furthermore, since our approach requires on the part of + the host system only the ability to map files to fixed addresses, + and the ability to specify the base address of the text segment of + an image at link time, it should be applicable to other (non-Sun) + systems which may provide these capabilities but not shared libraries. + +unix/as.i386/zsvjmp.s + After a little experimentation I found that the .SET assembler macro + could be used to set the value of absolute symbols. This allows MEM + to be located at virtual address 0, making shared libraries possible + for the 386i, and improving assembly level debugging as well. + +unix/shlib/README +unix/shlib/S.nm.i386 external names in 386i shared library +unix/shlib/S.nm.mc68020 external names in Sun-3 shared library +unix/shlib/S.ver.i386 386i shared library version number +unix/shlib/S.ver.mc68020 Sun-3 shared library version number +unix/shlib/Slib.c support code +unix/shlib/aout.c utility to decode a.out format process headers +unix/shlib/coff.c utility to decode COFF format process headers +unix/shlib/edsym.c called by XC to edit symbol table of .e file +unix/shlib/mkpkg mkpkg tie-in +unix/shlib/mkpkg.sh called to boostrap edsym.e +unix/shlib/mkshlib.csh script which does it all +unix/shlib/omit.i386 external names to be excluded from 386i shlib +unix/shlib/omit.mc68020 external names to be excluded from Sun-3 shlib + + This directory contains all the code needed to build and maintain the + shared library. The shell script mkshlib.csh, normally called via + the mkpkg, does all the work. This constructs a name list for the + shared library, generates the assembler required for the transfer + vector modules (V.s and S.s), and links the shared image (S.e). + + When building a new shared library, mkshlib checks to see if any + externals have been deleted from or added to the name list of the + old shared library. If any externals have been deleted, the version + number is incremented and any applications linked with the shared + library will have to be relinked. If there were no changes to the + name list or new externals have been added, then the version number + is not incremented, and existing applications are permitted to use + the new shared image without having to be relinked. The shared image + is linked -Bstatic, meaning that any required host library procedures + are bound at link time. + + Only Fortran or Fortran-like externals are permitted, i.e., exported + from the shared image to the client via the transfer vector. This is + necessary to permit clients to be linked -Bdyamic, allowing use of + the host system shared libraries (otherwise name conflicts would + occur at link time). + + The objects produced by the SHLIB code are libshare.a (the shared + library) and S.e (the shareable image), discussed further below. + +bin/S.e + + The shared image. This gets mapped into the address space of any + process linked with the shared library. It is also a runnable process + in its own right; if run directly, it prints out some information + about itself and exits. The full contents (minus the omitted + externals) of the EX, SYS, VOPS, and OS libraries are currently + linked into this image; other libraries may be added in the future, + e.g., some of the MATH libraries. The transfer vector module V.o, + located at a fixed (absolute) offset in the image, is used to vector + procedure calls from the client process into the shared image. + +lib/libshare.a + The shared library. This contains several object modules, including + a single object S.o consisting of a short header plus a name list + containing all the externals exported by the shared image. Each + external (i.e., VOS procedure such as 'clgeti' etc.) appears in S.o + as an absolute symbol, pointing to a fixed location in the transfer + vector in the shared image. Note that externals appear in S.o only + as symbols, hence no actual executable code gets linked into the + client process. To link with the shared library, XC links with + libshare.a instead of libex.a,libsys.a,libvops.a,libos.a. + +unix/os/zmain.c + The zmain is the main procedure for an iraf process. The first thing + the zmain does now is call ZZSTRT, which is described below. Some + code was moved out of the zmain into ZZSTRT, and all references to + global variables in the kernel had to be eliminated, since the zmain + is no longer linked with the kernel procedures (which are off in the + shared image). Other changes included the addition of calls to ZZSETK + to set the values of the kernel variables, and changes to the calling + sequence of IRAFMN to permit the address of SYSRUK and ONENTRY to be + passed in the argument list, rather than being bound at link time. + +unix/os/zzstrt.c + The function of this procedure, which has been a no-op in UNIX/IRAF + up until now, is to perform any runtime initialization of the kernel. + Currently, ZZSTRT maps and initializes the shared image, sets the + desired IEEE exceptions (partially implemented at present), sets the + process working set soft limits, and sets the default values of the + kernel variables via the new ZZSETK procedure. + + Mapping and initializing the shared image is similar to what unix + does during startup of a normal process. The shared image file is + opened, and the header is read to determine the sizes of the text, + data (initialized data), and bss (unitialized data) segments. + IRAF uses an additional shared image header segment containing the + file header and the FIO common (fiocom), which has to be directly + accessed by the client, making it necessary to locate it at a fixed + address in virtual memory. + + The header segment containing the FIO common is then mapped read-write + private, meaning that if any pages are modified the client gets a + private copy of the page. The text segment of the shared image is + mapped read-only shared. The data segment is mapped read-write + private; pages are shared until modified by the client at runtime. + The BSS segment is then mapped onto an arbitrary file offset (zero) + and promptly zeroed, causing all of the pages to belong to the client. + Finally, the addresses of the unix malloc, realloc, and free procedures + are passed into the shared image (dynamic memory allocation must be + in the data space of the client), and the environment pointer in the + shared image is set to point to the environment of the client, so that + the VOS will see the host environment and command line arguments seen + by the client. + + Both ZMAIN and ZZSTRT are linked directly into each client process, + since they are required to map in and initialize the shared image. + (S.e has its own private copies, of course). + +unix/os/zlocpr.c + ZLOCPR had to be modified to deal with the transfer vector. + The problem is that calls to ZLOCPR in the client image and in the + shared image must return the same value, since equality comparisons + of procedure entry points are are used to determine, e.g., if a + particular file driver is referenced. ZLOCPR was modified to check + if the referenced procedure is actually a transfer vector entry, + returning the address of the actual procedure in the shared image + if so. Since this is a host level procedure, this is done by + disassembling the JMP instruction in the transfer vector. + +unix/os/zshlib.c + + This object contains everything needed to link a process against the + standard libraries, ignoring the shared library. Dummy shared image + descriptors and procedure entry points are defined so that the code + in ZMAIN and ZZSTRT will link properly. At runtime, the startup code + determines that the shared library is not in use, skipping the map and + initialize operations. + +unix/os/zzsetk.c + + This new kernel procedure is used to initialize the values of all the + global kernel variables formerly initialized via EXTERN references in + the zmain. A procedure (with transfer vector) must be used instead + of a series of global data references in order to be able to link + against the shared library. + +unix/boot/spp/xc.c + 1. XC was modified to link against the shared library by default. + The new switch -z (as in VMS/IRAF) is used to link without using + the shared library. Both the shared library and the shared image + may be in an IRAFULIB directory if desired. + + 2. If linking against the shared library, XC will by default call + EDSYM to edit the symbol table of the new executable, renaming the + symbols pointing to transfer vectors by prefixing a "V", and adding + new symbols to point into the shared image to the actual locations + of the VOS procedures referenced by the transfer vector. This provides + symbols for debugging executables that used the shared image. + + New XC switches: + + -e do not call edsym to do symbol editing + -s strip executable (UNIX linker switch; for XC, defeats + call to edsym). + + edsym switches (accepted by XC): + + -d print symbol table + -k do not delete "uninteresting" symbols + -n do not modify any files + -t omit transfer vector symbols to save some space + -T delete all symbols associated with the shared library + + 3. The -align switch, formerly passed to the 386i linker to page + align the MEM common, was deleted since MEM is now assigned to + location zero with a .SET. + +sys/etc/main.x +sys/etc/xmjbuf.x + + 1. The calling sequence of the iraf main was modified to add sys_runtask + (SYSRUK) and onentry (ONENTY) as arguments, allowing a runtime rather + than link time reference. This was necessary for the shared library + since SYSRUK and ONENTY are client symbols but are called by the iraf + main, which is in the shared image. The new scheme is more flexible + in any case. + 2. The new procedure XMJBUF is used to get an XCHAR pointer to the + zsvjmp/zdojmp context vector used by the iraf main for interrupt and + error recovery. Again, a runtime procedural reference using a pointer + is necessary since the global data area cannot be referenced at link + time. The CL uses both a custom onentry and a custom zdojmp context + vector in order to gain full control over command interpretation. + +unix/hlib/libc/libc.h +unix/hlib/libc/knames.h +unix/hlib/libc/xnames.h + 1. In libc.h, the ZJUCOM reference was deleted since the XMJBUF + procedure is now used to access the interpreter context vector. + 2. Entries for the new VOS and kernel procedures were added to + [xk]names.h. + +unix/hlib/irafuser.csh +unix/hlib/mkpkg.inc +mkpkg [at iraf root] + 1. The -z flag (no shared library) was added to the HSI_XF flags in + irafuser.csh, so that HSI executables will not use the shared image. + 2. The mkpkg.inc now includes a switch USE_SHLIB, which if set causes + mkpkg to automatically update the shared library and shared image + during a sysgen. This switch does not actually determine whether the + shared library is *used*, since that is determined by the -z switch + to XC at link time. + 3. For Sun/IRAF, the switch -/Bstatic was added to LFLAGS so that + the iraf executables will be statically linked, rather than using the + SunOS shared library (e.g., libc.a). This was not necessary - there + is no conflict between the iraf and SunOS shared libraries - but was + done to save disk space (see CAVEATS, below). + +unix/mkpkg.sh +unix/shlib/mkpkg.sh + Will build the edsym.e utility and install it in HBIN during a + bootstrap. + +unix/hlib/install + Will make a link for EDSYM in the local/bin directory. + +pkg/cl/main.c + A call to XMJBUF was added to convert to a vectored procedure reference + to the main interpreter context vector. + +sys/gio/cursor/prpsinit.x +sys/gio/cursor/mkpkg +sys/etc/mkpkg +sys/etc/prfindpr.x +sys/etc/propcpr.x +sys/etc/prsignal.x +sys/etc/prfilbuf.x +sys/etc/prgline.x +sys/etc/prupdate.x +sys/etc/prclcpr.x +sys/etc/prstati.x +sys/etc/prredir.x +sys/etc/prgredir.x +sys/etc/prclose.x +sys/etc/proscmd.x [moved from gio/cursor to ETC] +sys/etc/prpsio.x [moved from gio/cursor to ETC] +sys/etc/prc.com [moved from LIB to ETC] +sys/etc/prpsload.x + + Most of the "pr" prefixed files, e.g., PRPSIO, were moved from + gio/cursor to ETC, and the file prc.com (the PR common) was moved + from LIB to ETC, making it a private common. This was necessary + to avoid the global data reference, which would cause the process + control code to fail at runtime due to the client and shared image + having separate copies of the PRC common (another reason to not use + commons!). PRPSIO was modified to use a loadable driver to provide + a runtime technique for linking to the graphics pseudofile i/o + procedures in gio/cursor. In addition to making the shared library + cleaner to implement, this collects all of the process control code + together in one place in the VOS (in ETC - libsys.a), avoids some + circular library references, and makes it possible to use LIBC/stdio + in applications processes without an unresolved linker reference + to PRPSIO (STScI has run into this). + + PRPSINIT is a procedure called by the CL at startup time to load + the gio/cursor graphics pseudofile i/o driver into PRPSIO. + +lib/syserr.h +lib/syserrmsg + A new error SYS_PRPSIOEPA was added, in support of the above + modifications. + +pkg/images/filters/mkpkg +pkg/images/filters/convolve.x +pkg/images/filters/radcnvr.x [used to be called acnvrr.x] + This code contained a routine ACNVRR which redefined a VOPS library + procedure, causing a multiply defined linker error when linking with + the shared library. The offending procedure was renamed CNV_RADCNVR + (radially symmetric convolve, type real). Applications should not + use reserved package prefixes. + +unix/os/zfunc.c + + A set of new kernel primitives ZFUNC1, ZFUNC2, ... ZFUNC9 were added. + These are similar to ZCALL[1-9], but allow calling of functions by + their LOCPR entry point address, as has long been possible with + subroutines and ZCALL. + +CAVEATS - Shared libraries + Several interesting things about SunOS were learned in the process of + implementing the Sun/IRAF shared library. + + 1. Linker Bug. There is a bug in the SunOS linker. The size of the + BSS area is not being computed accurately. For processes with a very + small BSS section, this can lead to a BSS size of zero being computed. + Normally this does not cause a problem, since a small BSS area will + usually fit into the last page of the data area. In some cases, + however, the small BSS area is in an additional page, but since BSS + is zero no BSS area is allocated during process startup, causing a + segmentation violation when the unix code tries to set the value of + the BSS global variable "environ" during process startup. I managed + to avoid this problem by the subtle kludge of adding the following + declaration to the ZZSTRT object (which is linked into every iraf + process): + + int BSS_kludge[256]; + + This provides the process with enough BSS storage (statically allocated + unitialized data space) to avoid having the size of the BSS segment + being set to zero at link time. + + 2. Does using the SunOS shared libraries really save space? + For some reason which I was not able to determine, a small iraf + process linked -Bdyamic (the default, i.e., use the SunOS shared + libraries) always has a text segment of 75-85 Kb, even though the + sum of all the objects therein may be much less. It appears that + the linker may be incorrectly computing the size of the text segment, + causing it to effectively be padded out to a size considerably larger + than what it should be. Linking the process -Bstatic (no SunOS + shared libraries) avoids the bug, yielding a much smaller executable + file, even though more text space is actually required due to the + need to link in modules from the SunOS libraries which would otherwise + be shared. + + 3. Processes with a large BSS segment execute slowly. One thing which + became very clear to me while working on image execution was that + processes with a large BSS segment take a long time to execute. + The reason is that the BSS segment must be zeroed during process + startup. Zeroing a large region of mapped memory involves both the + cpu time required to zero the storage, plus all the mapped file i/o + (paging) required to initialize the mapped swap file pages. This is + not a big deal for processes with a BSS segment in the N*10K region, + but if the BSS is N*100K or N*1000K, then it can take seconds. The + moral is USE DYNAMICALLY RATHER THAN STATICALLY ALLOCATED BUFFERS. + I am going to modify some of the system code as a result of this + lesson, e.g., the CL currently statically allocates about 250K of + combined stack and dictionary buffer space. In applications, BSS + storage is most commonly found as declarations of the form + + char fname[SZ_FNAME] + char line[SZ_LINE] + + and so on. This is of no consequence for small individual programs, + but can add up to a lot of BSS for large packages. The unix "size" + utility may be used to determine the BSS requirements of a process. + +unix/boot/mkpkg/tok.c + An unrelated bug in MKPKG was fixed, which would cause one or the + other of IFOLDER or IFNEWER to fail, when presented with a list of + files to be compared. The bug was that IFOLDER is not equivalent + to !IFNEWER when more than one file must be compared. (12/28) + +unix/as.i386/README +unix/as.i386/aclrb.c +unix/as.i386/aclrc.c +unix/as.i386/bytmov.c +unix/as.i386/aclrs.c +unix/as.i386/aclri.c +unix/as.i386/aclrl.c +unix/as.i386/aclrr.c +unix/as.i386/aclrd.c +unix/as.i386/amovc.c +unix/as.i386/amovs.c +unix/as.i386/amovi.c +unix/as.i386/amovl.c +unix/as.i386/amovr.c +unix/as.i386/amovd.c +unix/hlib/mkpkg.sf.I386 + In an unrelated optimization, the above zero and move procedures + were added to AS. These are written to use calls to the host + BZERO and BCOPY functions to zero or copy blocks of memory, taking + advantage of the special repeat-string-op instructions provided by + the 80386 cpu. (12/28) + +sys/ki/irafks.x + In the open-binary-file code, the fprintf debug message was incorrectly + passing arg1 rather than arg2 as the file access mode. (12/29) + +unix/boot/mkpkg/tok.c + In the $ifeq code, strcmp() would be called with a NULL string pointer + if the referenced environment variable was undefined. (1/2)(1989) + +--------------------- +Moved shared library stuff to tucana (Sun-3) over the period 30Dec-2Jan. +Reworked mkshlib.csh, edsym.c, zzstrt.c etc. for the "a.out" format object +files used on the Sun-3; these are quite different than the Sys V COFF +object format used on the 386i. + +--------------------- +Moved everything back to the 386i, rebuilt the shared library, and relinked +the system. Merged in all recent changes from tucana. (1/3) + +--------------------- +Begin changes to better support layered external software. (1/28) + +unix/os/zgtenv.c +sys/etc/environ.x +sys/etc/envgets.x + ZGTENV, ENVFIND, and ENVGETS were changed to make it possible to + discriminate between undefined environment variables, and variables + that have a null string value. ERR is returned if the variable does + not exist; 0 if exists but has a null value. Since most programs + do a <= 0 test to check for valid environment definitions, this should + be a fairly safe change, although some programs may be affected + (i.e., any program that only does an == 0 test). (1/28) + +sys/libc/cenvget.c +pkg/cl/builtin.c + Minor changes to allow for null valued environment variables. (1/28) + +sys/fio/vfntrans.x + Added a new feature to virtual filename translation, to provide general + environment symbol replacement during translation. This was needed to + support multiple architectures, e.g., different version of the PKG and + LIB directories, but it is a general facility which will be useful + for multiple versions of other types of directories and files as well. + + For example, one might make the following definitions: + + set arch = "" + set bin = iraf$bin(arch)/ + set lib = iraf$lib(arch)/ + + Which become iraf$bin/ and iraf$lib/ by default. If arch is defined + as, for example, ".ffpa", then we have iraf$bin.ffpa/ and likewise + for lib. The default case, where arch is the null string, is what + required the revisions discussed earlier. (1/28) + +----------------- +The following revisions were made all together over a period of a couple +of weeks and summarized on 2/21. + +pkg/system/help/helpdb.x +pkg/system/help/helpdir.x +pkg/system/help/modlist.x +pkg/system/help/modtemp.x +pkg/system/help/prdir.x +pkg/system/help/prfile.x +pkg/system/help/prhlpblk.x +pkg/system/help/prsummary.x +pkg/system/help/t_help.x +pkg/system/help/tlist.x +pkg/system/mkhelpdb.par + 1. The compiled help database files are now stored externally in a + machine independent format. + + 2. HELP now permits multiple compiled help database files. The + parameter / environment variable `helpdb' is now a file template + (e.g., a comma delimited list of files) specifying the helpdb files + to be combined to produce the composite help database to be used + at runtime. HELP takes a little longer to respond the first time + while it is reading and combining all the files, but once the + composite database has been generated in-core all is as it was before. + If any of the helpdb files are modified, or if new files are added, + the incore composite database is automatically regenerated. + + It is still necessary that all package names be unique; this + restriction will be removed in a future implementation but it is + too difficult to fix in the current program. + +dev/help.db - +lib/helpdb.mip + + The old core sytem help database file dev$help.db has been deleted + and replaced by the new machine independent file lib$helpdb.mip, + which now contains only entries for core system help modules. + Each external layered package (noao, local, stsdas, etc.) will + have its own lib/helpdb.mip. + +mkpkg + 1. All references to the noao and local packages have been removed + from the root mkpkg file. Layered packages are maintained + independently of the core system and separate mkpkg sysgens, + etc, are required for each package. + 2. The `stripall' entry has been deleted leaving only `mkpkg strip' + for stripping the system. + +noao/README + Completely new README for the reorganized NOAO package. + +noao/bin + +noao/bin.i386 + + NOAO now has its own BIN directory. For Sun/IRAF, `bin' is a + symbolic link to the bin directory for the architecture for which + the system is currently configured, bin.i386 on my development + system. + +noao/lib/helpdb.mip + compiled help database +noao/lib/mkpkg.inc + global mkpkg definitions for noao +noao/lib/mkpkg.sf.I386 + special file lists for various architectures +noao/lib/mkpkg.sf.SUN3 + " +noao/lib/mkpkg.sf.SUN4 + " +noao/lib/root.hd + root help directory for the noao packages +noao/lib/strip.noao + stripper file for the noao directories + + The above files were added to noao$lib, the global library for the + NOAO packages. All files are maintained in a machine independent + format and may be included in distributions. Files like the mkpkg.* + include machine dependent information but are easily modified or + extended to support new architectures - there is no better way, + one must have things like special file lists for different + architectures (if there isn't one, as in a new port, the application + will still sysgen but there is a real possibility of undetected + compiler bugs). + + The helpdb.mip is machine independent as well, and should be generated + by the developers of an exportable package, and included in the + distribution. The ".mip" extension tells the HSI utilities such as + WTAR that it is a machine independent file and can be included in + "source only" archives. It can be generated under V2.8 with a command + such as + + cl> mkhelpdb helpdir=noao$lib/root.hd helpdb=noao$lib/helpdb.mip + + By default, MKHELPDB will generate the core system help database. + +noao/mkpkg + Added a `mkpkg strip' entry. Other entries will need to be added + in the future to support multiple architecture switching for Sun/IRAF. + +noao/noao.cl + Added the following lines to the noao.cl file: + + set noaobin = "noao$bin(arch)/" + package noao, bin = noaobin$ + + The bin= argument to package is required to tell the CL that noao + has its own bin directory and is discussed below. The `noaobin' + definition permits user redefinition of the noao BIN directory, + as well as specification of the architecture for all packages + via the environment variable `arch', which is defined in terms + of `mach', which defines the machine architecture. + +pkg/cl/bkg.c +pkg/cl/builtin.c +pkg/cl/exec.c +pkg/cl/main.c +pkg/cl/prcache.c +pkg/cl/task.c +pkg/cl/task.h + The CL was modified to generalize the BIN directory scheme. Formerly + executables could be stored either in the package directory or in BIN. + The same is true now except that there can be multiple BIN directories. + By default bin is iraf$bin/. This may be overridden for a package by + specifying the package bin directory with a bin=bindir argument to + the PACKAGE directive (see example above). The new bin will be used + for the referenced package and all subpackages of that package, unless + overridden by another PACKAGE directive. Note that no bin-path + searching is involved; the CL never has more than two directories to + look in for a given executable, since every package has a well defined, + unique BIN directory. + +sys/etc/envgets.x +sys/etc/environ.h +sys/etc/environ.x +sys/etc/envscan.x + 1. ENVFIND will now return ERR if the named variable does not exist, + and a string length of zero if the variable exists but has a null + string value. + 2. ENVSCAN now permits newline to be escaped in the value field, + permitting arbitrarily long value strings. Leading whitespace is + discarded in each continuation line, allowing continuation text to + be left justified at any arbitrary column for readibility. + 3. ENVSCAN recognizes both SET and RESET. + 4. ENVSCAN now supports the "set @filename" syntax for inclusion + of other files containing set environment definitions. All non + set or reset statements are ignored. + 5. The max size value string is increased to 512 chars. + + All of these changes hold also for the HSI version of ENVSCAN + (see the bootlib.envinit.c notes below). + +sys/fio/vfntrans.x + General environment variable replacement is now supported within + virtual filenames via the syntax "(envvar)", which is replaced + by the value of the named environment variable "envvar". This is + different from logical directory replacement which replaces + everything to the left of the $. (Perhaps we should have simply + used the unix symbol replacement syntax in the first place, but + it is too late to change now). For example, + + set mach = f68881 + set arch = .(mach) + set bin = iraf$bin(arch)/ + + This point of this facility is that it allows any field of a filename + to be parameterized with an environment variable. If the named + variable does not exist the null string is used. + +sys/imio/iki/ikiopen.x +sys/libc/cenvget.c + Replaced an "envfind() == 0" by "envfind() <= 0" to reflect the fact + that ENVFIND can now return a negative value. + +unix/boot/bootlib/mkpkg +unix/boot/bootlib/bootlib.h +unix/boot/bootlib/osfn2vfn.c +unix/boot/bootlib/vfn2osfn.c + The UNIX/IRAF HSI has been modified to use VOS filename mapping, + to facilitate use of the zzsetenv.def and extern.pkg logical directory + definitions, as well as all the other semantics of general filename + mapping. Note that this requires use of libsys.a (etc.), but it + was done in such a way that if the library does not exist, bootstrap + filename mapping is used. VOS filename mapping is used only if the + environment variable NOVOS is not defined at HSI bootstrap time; this + variable is defined in the file hlib$irafuser.csh which is assumed + to be referenced at login time by the account of whoever is doing + the bootstrap (normally user iraf). + + A true bootstrap is performed with VOS filename mapping disabled, + and then repeated once a sysgen has been performed to generate the + VOS system libraries. The HSI bootstrap filename mapping facilites + are adequate to compile the VOS but do not support external layered + packages. + +unix/boot/bootlib/envinit.c + This routine is used by the HSI to read the zzsetenv.def file. + This cannot be done with the VOS, even when VOS filename mapping + is in use, because the VOS routine envscan uses FIO (the filename + mapping primitives are much lower level, being layered on the kernel). + I made all the same changes as for ENVSCAN above, so that the + environment variables defined in hlib$extern.pkg will be defined + in the HSI. + +unix/boot/bootlib/osfpathname.c + 1. Modified to avoid the null filename bug that appeared in VMS/IRAF + long ago (VMS/IRAF also uses VOS filename mapping). + 2. Fixed a second bug that would probably only affect UNIX/IRAF. + The filename ".." was not being mapped properly on UNIX/IRAF, whereas + it worked fine on VMS/IRAF. This was because on UNIX/IRAF the call + to vfn2osfn to translate the ".." to the pathname of the previous + directory, whereas on VMS/IRAF all it would do is pass it on, to be + used in the later call to ZFSUBD. + +unix/boot/bootlib/ossysfile.c + Added support for an applications defined system library search path, + e.g., for XC command line -llib library references, or <file.h> global + include file references. LIB, HLIB, and any other system libraries + are searched first, followed by any package libraries as specified + by the environment variable `pkglibs'. The latter is defined in + extern.pkg and this mechanism is intended as a way of extending the + global library mechanism to support applications libraries. There is + a flaw - a search path opens the possibility of file name collisions, + resulting in the wrong file being used. At least this will be obvious + if it occurs, and the search path is the simplest mechanism in this + case. + + This HSI level library search path mechanism should not be confused + with the IRAFULIB facility used in UNIX/IRAF. Any IRAFULIB directories + are searched *before* the system libraries, allowing custom versions + of system library files for testing or development purposes. In the + case of the `pkglibs' the system libraries are searched first, with the + full search order being the IRAFULIBs, followed by the system libraries + (LIB, HLIB, and also BIN, bin.`mach` etc. for Sun/IRAF), and lastly + the package libraries in the order in which they appear in pkglibs. + There should be minimal execution time penalty from adding pkglibs + searching, since most global file references will be satisfied early + in the search by a system library. + +unix/boot/bootlib/osgetenv.c + Added VOS and NOVOS cases. The VOS case calls ENVFIND to lookup + environment names. This is required to make the environment used + for VOS filename mapping available in the HSI utilities, e.g., + in mkpkg. + +unix/boot/mkpkg/mkpkg +unix/boot/generic/mkpkg.sh +unix/boot/mkpkg/mkpkg.sh +unix/boot/rmbin/mkpkg.sh +unix/boot/rmfiles/mkpkg.sh +unix/boot/rtar/mkpkg.sh +unix/boot/spp/mkpkg.sh +unix/boot/spp/mkxc.sh +unix/boot/spp/xpp/mkpkg.sh +unix/boot/wtar/mkpkg.sh + All these files had to be modified to parameterize the list of + libraries to be used to link HSI executables. Formerly libboot + and libos were being referenced explicitly, but now that the HSI + can be linked either VOS or NOVOS, the list can also include + libsys and libvops. The parameter is the unix environment variable + HSI_LIBS defined in hlib$irafuser.csh. + +unix/hlib/clpackage.cl +unix/hlib/clpackage.hd + Removed all references to local, noao, and stsdas. External packages + now have their own root help directories and help database files, so + no entry in the clpackage.hd is required. The external packages are + picked up by clpackage.cl by the following statements: + + # Define the external (user-configurable) packages. + cl < hlib$extern.pkg + + which executes the TASK statements in the extern.pkg to define the + external packages. The environment variables in extern.pkg will + already have been defined by the zzsetenv.def @extern.pkg include, + so they are reset harmlessly when extern.pkg is reinterpreted by + the CL. + +unix/hlib/extern.pkg + +unix/hlib/zzsetenv.def + 1. Removed all references to noao, local, and stsdas from zzsetenv.def, + replacing these by the statement + + set @hlib$extern.pkg + + which includes set (actually reset) statements defining the root + directory of each external package. + + For HELP, deleted the entries for helpdir and helpdb. The helpdir + environment variable is no longer used, and helpdb has been moved + to extern.pkg. + + 2. Added the file hlib$extern.pkg, which is the sole link between the + core system and external packages. To install an external package, + ALL that should be required is to make an entry in this file, after + reading the files onto disk (a mkpkg at the package root will also + be required if the package is distributed in source only form). + To deinstall a package, all one need do is comment out or delete + the related entries in extern.pkg, and backup and delete the external + package directory tree. The core iraf system can be updated without + affecting external packages. + + These things are possible ONLY if we strictly localize package files + to package trees, i.e., do not install library files and executables + from an external package in core system directories, do not rebuild + a central help database file, etc. A further major advantage for + NOAO is that we can easily maintain private LOCAL packages, have + STSDAS on disk for our users, etc., without making modifications to + our export systems which would affect our distribution tapes. + By localizing the changes required to interface an external package + to a single file, we need only replace that one file to make a + distribution tape from one of our master systems. + + For software maintenance purposes, developers should assume that ONLY + the root directory of their package tree is globally defined in the + HSI, and use only references such as "noao$lib/", "-llib", or + "<file.h>" in their applications (any VOS pathname relative to the + package root is acceptable). Note that a package global library + may be set up by adding the path of the library directory (e.g., + "noao$lib/") to the `pkglibs' entry in the extern.pkg. + + Additional logical directories may be defined in the global package + mkpkg.inc and used in mkpkg files, but these logical directory names + will not be propagated to XC hence cannot be used in include file + references etc. Additional environment variables could in principle + be added to the entry for the package in the extern.pkg, but I would + like to keep the interface as small as possible, localizing all + package information in the package itself as far as possible. + + VMS/IRAF users should note that since XC executes in the context of + MKPKG in VMS/IRAF, mkpkg definitions may be propagated to XC (I + haven't tested this), but to make use of this side effect of how XC + is implemented in VMS/IRAF would be nonportable. + +unix/hlib/gripes.cl +unix/hlib/gripesfile- + Commented out the code which appends gripes to the gripesfile, and + deleted the gripesfile. We will use only electronic mail to enter + gripes from here on. + +unix/hlib/irafuser.csh + 1. Added NOVOS and HSI_LIBS entries to define whether or not VOS file + name mapping is to be used in the HSI, and to list the libraries + to be searched to link HSI executables. If libsys.a does not exist + NOVOS is automatically set, hence bootstrapping UNIX/IRAF on a source + only system will automatically generate the HSI without the VOS. + Redoing the bootstrap once the VOS is compiled will cause the HSI + to be rebuilt with VOS filename mapping, as may be required to compile + any external packages (the core system does not require VOS filename + mapping in the HSI). + + 2. Added a couple of utility command aliases. `mkv' runs mkpkg with + the link flags set in such a way that the resultant executable has + symbols for the transfer vector entries. This is necessary to be + able to see what VOS routines are being called from an application + when debugging (otherwise one sees an offset from vshlib_). Perhaps + I should make this the default on our development system, even though + it almost doubles the size of the symbol table in each executable. + + A second utility definition `mkz' runs mkpkg, linking without the + shared library (like xc -z). These name may change but they should + serve to illustrate how to use the linker options for debugging. + +unix/hlib/libc/knames.h + Made several new entries. + +unix/hlib/login.cl + Added commented out commands to load the `noao' and `tv' packages. + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.I386 +unix/hlib/mkpkg.sf.OS4 +unix/hlib/mkpkg.sf.S34 +unix/hlib/mkpkg.sf.SUN3 + 1. In the mkpkg.inc, changed the FPU definition to MACH, since FPU + is too restrictive a name for what we use this switch for; MACH for + machine architecture comes closer. Possible values of MACH are + f68881, ffpa etc. for Sun-3 hardware options, sparc for the Sun-4, + i386 for the Sun-386, vax for the VAX, and so on. This switch is + used to select default compile and link flags, determine which + special file list to load, etc., allowing the generation of relatively + machine independent mkpkg definition files. + +unix/hlib/strip.iraf + 1. Changed the name from stripper to strip.iraf (strip.noao etc. for + other packages.). Deleted the stripall since I have never been happy + with what that level of stripping anyhow. Still need to review the + action of the strip file to ensure that everything that can be deleted + is being deleted, to add something to strip executables on unix + systems, and so on. + 2. Deleted all entries for the noao and local packages. These packages + now have their own strip files. + +unix/os/zfacss.c + Modified to test for the null filename and return NO in that case. + +unix/os/zgtenv.c + Will now return ERR for a undefined variable, and 0 for a defined + variable with a null string value. + +unix/os/zmain.c +unix/os/zshlib.c [DEBUGGING POINTER] +unix/os/zzstrt.c + Added a new command line switch "-w" to the zmain. Currently this is + only used in Sun/IRAF. Specifying -w causes the shared image text to + be mapped with write permission, allowing breakpoints to be set in + VOS routines. This cannot be done by default because one has to + reserve swap space for the entire shared image text segment in order + to have write (copy on modify) permission. + +unix/shlib/mkpkg + Fixed a bug in the code used to delete old versions of the S.e shared + image files in BIN. + +--------- (end of accumulated notes) ------------ diff --git a/doc/ports/notes.irix b/doc/ports/notes.irix new file mode 100644 index 00000000..487d3093 --- /dev/null +++ b/doc/ports/notes.irix @@ -0,0 +1,158 @@ +Begin IRIX/IRAF port/upgrade. +Thu May 30 13:31:15 MST 1996 +------------------------------------------------------------------------------ +Host - almond (WIYN remote observing host) +IRIX almond 5.3 11091812 IP22 mips +150 Mhz MIPS R4400 +64 Mb RAM +Indy 8-bit +Vino video +A2 Audio Processor +IRIX 5.3 + +Graphics board 0 is "NG1" graphics. + Managed (":0.0") 1280x1024 + 8 bitplanes, NG1 revision 3, REX3 revision B, VC2 revision A + MC revision C, xmap9 revision A, cmap revision C, bt445 revision A + Display 1280x1024 @ 72Hz, monitor id 2 + +Note - use "iiv" to view CD-ROM documentation. +------------------------------------------------------------------------------ +The following are notes from the IRIX 5.3 port, which was done mostly during +June 1-2 1996. Sun Jul 7 13:01:50 MST 1996 + +./local/notes.irix + + +./local/.4Dwmrc +./local/.cshrc +./local/.exrc +./local/.login + Customized for IRIX. This includes a workable desktop via .4Dwmrc. + +./unix/hlib/extern.pkg + Minimal package list for the port. + +./unix/hlib/install + Changed "mach" (the HSI machine type) from ssol to irix. + +./unix/hlib/irafuser.csh + 1. MACH is generated from uname differently than for Solaris. + 2. IRIX/IRAF compile flags are -/DSYSV -/DSOLARIS. + 3. IRIX/IRAF link flags are -lelf -lfpe. + 4. No -Bstatic flag for IRIX. + +./unix/hlib/login.cl + FC calls XC directly in the conventional manner rather than using + hlib$fc.csh. + +./unix/hlib/mkiraf.csh +./unix/hlib/mkpkg.inc +./unix/hlib/motd + Minor customization. + +./unix/hlib/mkpkg.sf.IRIX + + Pretty standard, did need to increase size of compiler tables for + fmtio$evvexpr.x and cl$ytab.c. + +./unix/os/irafpath.c + Added "irix" for #ifdef sgi. + +./unix/os/mkpkg +./unix/os/mkpkg.sh + Deleted enbint.s (a solaris special routine). + Modified to use $CC to compile the assembler files, as we have done + recently on other platforms (allows compile flags to be used). + +./unix/os/zawset.c + Minor compile time customization (nuke solaris #define RLIMIT_RSS + RLIMIT_VMEM). Poking arount it appears that IRIX handles the + set/getrlimit stuff ok. + +./unix/os/zxwhen.c + The error handler code was remarkably similar to Solaris (i.e. SYSV + I suppose), down to the codes for the arithmetic exceptions. All I + had to change was a sigaction structure definition: solaris uses + sig.sa_sigaction, IRIX uses sig.sa_handler. + +./unix/os/zzstrt.c + Include <sigfpe.h> for IRIX. + The IEEE exception handling initialization for this platform consists + of: + + > sigfpe_[_UNDERFL].repls = _ZERO; + > handle_sigfpes (_ON, _EN_OVERFL|_EN_DIVZERO |_EN_INVALID, + > 0, _ABORT_ON_ERROR, 0); + + This enables exceptions for overflow, divide by zero, and invalid + operand. It is also supposed to be possible to arrange for things + to underflow to zero, however it is not clear if it is possible to + do this without enabling the underflow exception. I didn't have + time to look into it further, and the system passes all tests with + the underflow handling disabled. + +./unix/as.irix/zsvjmp.s + The DECstation (MIPS) version works also for IRIX - the SGI of course + uses a MIPS chip. + Checked size of SETJMP/ZSVJMP buffer; the Solaris value is larger than + needed for IRIX so I left it unchanged. + +./unix/boot/mkpkg/host.c + The ELF library code for solaris works fine for IRIX too. The only + problem encountered was that during library updates the link mkpkg + creates to the actual library would be clobbered by the updated + library file which would subsequently be deleted, causing the mkpkg + to be a no-op. Linux/IRAF had the same problem so I merged in the + "resolvefname" code from Linux/IRAF. This takes a library name and + checks to see if it is a link and keeps this up until a fully + resolved filename is obtained. This is then used to perform the AR + updates. + +./unix/boot/spp/xc.c + Sysbindir (default compiler location) is /usr/bin. + System libraries are the conventional U77,F77,I77,U77, plus fpe, isam. + Implemented the -// syntax for passing on host switch arguments. + +./unix/boot/spp/xpp/xppcode.c + Had to declare errflag an external. + +./unix/gdev/sgidev/sgi2uapl.c +./unix/gdev/sgidev/sgi2uhpgl.c +./unix/gdev/sgidev/sgi2uimp.c +./unix/gdev/sgidev/sgi2uqms.c + Various local variables named "sgi" caused problems here. Changed + the names to "sgip". + +./dev/hosts + Replaced with newer version. + +./dev/pix.imh + Someone modified this on Tue 17:56:52 04-Jun-96. I don't know who or + why, but the image appears the same. + +./dev/tapecap + Modified for IRIX 5.3. The default configuration should provide + variable block size support ("v" in device name) so long as the + host level support for the device permits it. See "man tps" for + information on the IRIX SCSI tape driver. + +./pkg/cl/globals.c +./pkg/cl/grammar.h + Added global declarations for parse_state, proc_script, parse_pfile, + and changed the declarations in grammar.h to extern. + +./unix/boot/spp/xc.c.NOSHARE +./unix/shlib/README +./unix/shlib/mkpkg +./unix/shlib/mkshlib.csh +./unix/shlib/so_locations + The shared library code in IRIX looked remarkably similar to that in + DEC Alpha OSF/1 (including quickstart etc.) so I did an experiment + to implement shared libraries for IRIX/IRAF. This pretty much worked, + but I had to set it aside due to some obscure runtime error occurring + during process startup, which I didn't have time to investigate. + The code is still there in case we get time to go back and look into + this further. + +------------------------------ +Fri Jul 5 18:04:26 MST 1996 +IRIX/IRAF distribution built. diff --git a/doc/ports/notes.linux b/doc/ports/notes.linux new file mode 100644 index 00000000..241dc3b0 --- /dev/null +++ b/doc/ports/notes.linux @@ -0,0 +1,325 @@ +Begin Sat Apr 29 21:05:25 MST 1995 Linux 1.1.93. +Files actually set up initially last weekend. +----------------------------------------------------- + +unix/hlib/irafuser.csh MACH is "linux", architecture is "linux" compiler is + GCC. Set up generic compile and link flags for the moment. (4/23) + +unix/hlib/mach.h + x86 boxes are little-endian so all the SWAP flags are set to YES + on this platform. (4/23) + +unix/os/mkpkg.sh + 1. Was using HSI_LIBS to link alloc.e, but the iraf libraries are not + used in this file. Changed to use HSI_OSLIBS instead. + 2. Deleted the reference to as$enbint.s, not used for Linux. (4/29) + +(linux) + 1. After booting typing "cd unix", which uses cdpath to go to + $iraf/unix, would hang the xterm. The problem went away following + a reboot. + 2. Got a bunch of failures to compile when doing a reboot of the + HSI, no apparent reason (message said couldn't write .o files). + Started another reboot and the problem went away. + 3. Manpages can be very brief and do not fully specify system or + library routines. + 4. Problems with cut and past, not resolved. + +unix/os/zfiomt.c + The structure "mtpos" used in this file redefines a different + structure defined in <sys/mtio.h>. Changed zfiomt.c to use _mtpos + for its internal structure. (4/30) + +unix/os/zfiomt.c + Linux doesn't have SIGEMT. Changed to use SIGABRT. (4/30) + +unix/os/mkpkg + Commented out enbinit.s. (4/30) + +unix/boot/gdev/sgidev/sgi2uapl.c + Added a #undef SOLARIS to cause the routine to use gethostname() + rather than sysinfo which is implemented differently in Solaris + and Linux. (4/30) + +unix/hlib/install + Minor changes for Linux. (4/30) + +unix/hlib/motd + Modified for Linux/IRAF V2.10.4BETA. (4/30) + +unix/boot/mkpkg/host.c + Added #undefs for SYSV and i386 to cause this code to use ranlib. + (4/30) + +---------------------------------------------- +Completed HSI bootstrap. (4/30) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.LINUX + + Modified mkpkg.inc for Linux, no compile/link flags of note yet at + this point. Add a base special file list for Linux, currently only + references the C files in AS. (4/30) + +unix/boot/spp/xc.c + Modified the code which compiles "other" files (not .x or .f) to + explicitly compile only .c and .s files. This prevents unrecognized + command line flags from confusing the code and causing a command to + be issued that contains nothing to be compiled. (5/03) + +(linux) + Another Linux oddity with libraries: on linking the CL _zawrim_ would + always come up undefined, even though an "ar tv" of libds.a showed + it looked fine. Deleting zawrim.o and updating the library made the + problem go away. (5/03) + +unix/os/zfiond.c + Added a #include <sys/time.h>, needed to pick up the FD_SET etc. + definitions on Linux. (5/03) + +unix/as.linux/ieee.gx + Installed the little-endian version (from OSF/1). F2C complained + about statements following DATA so I had to rearrange the code in + ieemap$t a bit. (5/03) + +unix/hlib/cl.csh +unix/hlib/fc.csh + Deleted the uname stuff and just fixed MACH=linux. Added linux + case code where needed. (5/03) + + +unix/as.linux/zsvjmp.s + I had to change the reference to `__setjmp' to `___setjmp' (3 under- + scores) to get the routine to call the function `__setjmp'. (5/03) + +unix/os/zawset.c +unix/hlib/libc/kernel.h + Installed the zawset (begmem) changes from tucana. (5/03) + + +Begin Sat Jul 22 20:24:16 MST 1995 +The Linux port was set aside for a time while IRAF V2.10.4 was prepared +and our Linux system was upgraded to Slackware 2.3 and Linux 1.2.11. +The port is being redone using Solaris/IRAF V2.10.4. The above revisions +will be merged before we resume taking notes. +--------------------------------------------------------------------------- + +unix/hlib/spy.cl + Added a Linux clause and set this to use "ps -axuf" for Linux. The + "-f" option provides a parent/child ordering similar to sps. (7/22) + +unis/os/zawset.c + Added an ifdef for Linux to cause it to uset {set|get}rlimit. (7/22) + +unix/os/zgtime.c + Modified to use CLK_TCK (100 Hz), as on Solaris. (7/22) + +unix/os/zpanic.c + Use SIGABRT on Linux rather than SIGEMT, which doesn't exist. + The Linux documentation doesn't specify which signals cannot be + caught, hopefully ABRT will do it. (7/22) + +unix/boot/mkpkg/host.c + Linux uses the GNU "ar" to maintain object libraries. This turns out + to have a bug which prevents it from properly updating a library which + is a symbolic link to the actual library. The library is updated in + the current directory, and the symbolic link is replaced by the + updated library, hence the actual (remote) library is never updated. + To work around this a new internal function "resolvefname" was added + to host.c This back traces any symbolic links and returns a fully + resolved library name. (7/24) + +unix/os/zxwhen.c + I noticed during testing that when interrupting the cl or a task + run stand alone, while waiting for command input, that following + the interrupt processing the most recent block of input would be + reread and executed. Evidently what happens is that Linux stdio + partially initializes the stdin file descriptor before the read, + and then never finishes initializing it since the read is interrupted + and never returns (in other words no critical section protection for + stdio). The workaround was to extend the fcancel() macro in zxwhen + to reset both the input and output buffer pointers, and add a fcancel + for stdin to the error handler to cancel the input buffer if an + interrupt occurs. (7/24) + +unix/os/zzstrt.c +unix/os/zxwhen.c + These routines were further modified to implement exception handling + for Linux. This turned out to be hard to do properly as about all + Linux provides is a simple signal() interface. + + 1. The first problem was that interrupts were being disabled after + the first interrupt, as signals are "one-shot" by default. The fix + here was to re-register the signal handler after each signal, and + to reinitialize the FPU control register during process startup and + during exception recovery. + + 2. After getting some Intel hardware manuals and some time digging + around in the Linux kernel to see how signals are handled I finally + found that the kernel pushes a frame on the stack before entering the + user exception handler. The EBP register can be used to get the + address of this frame. This frame describes the cpu state at the + time that the exception occurred and includes the hardware trap + number. This is sufficient to identify all system traps but only + identifies floating point exceptions to the coprocessor trap level. + The floating point unit status register has been cleared by the time + the user exception handler is entered and so far I haven't discovered + how to differentiate the floating point exceptions, but at least + things like the integer divide by zero and overflow exceptions are + properly diagnosed. The kernel is saving the information on the + FPU status internally, but so far I haven't found out how to access + this information from the application. (7/29) + +unix/boot/spp/xc.c + The f77 command on Linux, which is a shell script based on F2C, + erroneously returns an exit status of 4 when successfully compiling + a Fortran file. This would cause commands such as "xc foo.x" to + fail to link the output program thinking that the compilation had + abort on an error. To workaround this bug XC was modified to ignore + an exit status of 4 when calling f77 under Linux. (7/30) + +unix/os/zgcmdl.c + Linux also uses xargc,xargv. (7/30) + +dev/termcap + Added "lp" alias for "lpr", as used in zzsetenv.def. (7/30) + +------------------------- +Downloaded and built TABLES without incident. (8/01) +Built NOAO packages without incident. (8/01) + +unix/os/zmain.c + Changed the call to exit() to _exit() for Linux. I was having trouble + with tasks in NOAO and TABLES doing horrible things during process + shutdown (hanging up the console for minutes with the disk thrashing + heavily, or doing a panic shutdown). Although I did not check it out + fully, this appeared to be due to an "onexit" feature of the GNU exit() calling + calling random parts of process memory with essentially unpredicable + results. The simplest solution was to simply use _exit instead, which + avoids this feature. (8/01) + +unix/hlib/f77.sh + + Copied the default "f77" script that comes with Linux to $hlib/f77.sh. + The script was modified to eliminate the "f2ctmp_" prefix that it was + prepending to Fortran file names before compiling with GCC. This + feature (used by the script to implement Fortran includes) breaks + source code debugging since the file which is actually compiled has + the f2ctmp prefix and this file no longer exists after compilation. + This fix also eliminated the "exit 4" problem mentioned above in the + xc.c fix. (8/02) + +unix/boot/spp/xc.c + Modified XC to use the f77.sh script as the Fortran compiler, instead + of "f77". It will still fall back and use f77 if it can't find + f77.sh. (8/02) + +unix/hlib/f77.sh + 1. Modified so that the -w flag inhibits warning messages from both f2c + and gcc. This is necessary to get rid of a few warning messages seen + when compiling the IRAF code which do not indicate any real problems. + 2. Added a call to sed in the f2c call to workaround a bug in f2c + where -w fails to strip out all the lines of a multiline warning + message. (8/02) + +----------------- +Wed Aug 16 13:00:13 MST 1995 +System has been in testing since last thursday. + +dev/tapecap + Modified this file for Linux. Linux has a nice tape interface + supporting variable block sizes, behavior is very standard, however + there is no support for compression or any non-generic tape features, + and the default maximum block size on a read is 32K. (8/15) + +local/ + Installed a Linux specific set of startup files for the IRAF + account. (8/24) + +mkpkg +noao/mkpkg + Added "linux" targets. (8/28) + +unix/hlib/irafuser.csh + Added "-static" to the link flags for the HSI. (8/28) + +unix/os/zfiotx.c + Added #ifdef LINUX code in a couple of places to cancel the input + stream if an interrupt occurs (workaround for same bug as in zxwhen + above). (9/02) + +--------------------------------------- +Installed V2.10.4 patch1. Bootstrap, sysgen-update. (9/02) + +unix/hlib/install + Added "chmod -t /tmp" to allow multiuser deletion of files, e.g. + magtape lock files, in /tmp. (9/03) + +local/* + Configured the login files for the IRAF account, including setting + up the window system. Installed gzexe-compressed binaries for xgterm, + ximtool, and the tin newsreader in $iraf/local/bin. Set up window + system to start up by default 5 seconds after logging in, using fvwm + as the window manager. An "ADASS news" entry in the root menu accesses + the ADASS news using the tin executable provided. (9/03) + +unix/boot/bootlib/osfiletype.c + Added ".gz" to the list of source file types. (9/03) + +doc/rev2.hlp + Renamed this file to rev2.txt, it is not a help file. (9/03) + +unix/hlib/strip.iraf +noao/lib/strip.noao + Various minor enhancements and updates. (9/03) + +bin.linuz + +noao.bin.linuz + +unix/hlib/cl.csh +mkpkg +noao/mkpkg + Added a new architecture "linuz", which is a gzexe (gzip compressed) + version of bin.linux. (9/03) + +---------------------------------------------------------------- +V2.10.4 Linux/IRAF release cut. (9/04) + +unix/hlib/install + Deleted reference to edsym.e, which is not used on Linux/IRAF. (9/18) + +unix/boot/rtar/rtar.c + RTAR would immediately die on a segvio. This was traced to the use + of a local variable "setuid" which evidently conflicts with some + Linux include file definitions. Changed a number of local variables + in the program to static local variables and this fixed the problem. + (9/20) + +unix/hlib/f77.sh + Added a -b flag to allow calling f77 with the "-b i486-linuxaout" flag + to build a.out executables on ELF systems. (1/03/96) + +unix/hlib/irafuser.csh + Added "-b -i486-linuxaout" to the HSI compile and link flags. (1/03) + +unix/boot/spp/xc.c + Added "-b -i486-linuxaout" flags to all compile and link instances. + (1/03) + +unix/bin.linux/libf2c.a + + Added a copy of the a.out version of libf2c.a to HBIN since this is + not present on Slackware ELF systems, and possibly other Linux + verisons. (1/03) + +unix/os/mkpkg.sh + Changed the call to "as" to use $CC -c $HSI_CF instead, to cause any + platform specific flags to be used to assemble the files. (5/29 1996) + + +---------------------------- +TODO + +*** Provide sh/bash equivalent of irafuser.csh. + +Wed May 29 11:11:00 MST 1996 + New version of spp/xpp/xppcode.c does not work on Linux - some problem + with tokens. Using old version for now. + + diff --git a/doc/ports/notes.mips b/doc/ports/notes.mips new file mode 100644 index 00000000..c00dd6b0 --- /dev/null +++ b/doc/ports/notes.mips @@ -0,0 +1,398 @@ +# MIPS/IRAF alpha port. +# System arrived on thursday 17 May. + +----------------- +Configure UNIX (RISC/os 4.10) + +/etc/passwd +/etc/hosts +/etc/group +/etc/fstab +/etc/local_hostname +/tucana/ + +/u2 + + 1. Usual local configuration of passwd,hosts,group,fstab. NFS + mounted a number of tucana disks. + 2. local_hostname is a MIPS special, used to set hostname (columba + in this case) and network parameters (netmask, broadcast). (4/17) + + [didn't do anything more with the system for several days...] + +/usr/adm/periodic/daily/10.makehosts.system +/usr/hosts + Sometime later I discovered that /usr was 99% full and the directory + /usr/hosts contained over 8000 files totalling about 9 Mb. There + turned out to be a crontab file which makes a link to rsh in /usr/hosts + for every node alias in /etc/hosts. We like to keep a very large + hosts file around for reference, so this would end up producing an + enormous /usr/hosts. It is not clear if /usr/hosts is needed; the + node name entries can be executed to rsh to the node so perhaps that + is what it is for. Rather than disable the facility entirely, I + edited the makehosts script to make entries only for the local hosts. + (4/26) + +login customization + The MIPS is a nearly pure SysV UNIX machine with the default login, + which provides the SysV ls, ps, etc., the old unix kill, erase, etc. + characters for the terminal driver, and so on. A bit of hunting + turned up the following interesting items. + + /bds43/bin + /usr/ucb + Contains 200 or so BSD commands which are no where else to be + found, e.g., nroff, troff, lpr, head, etc., as well as BSD + versions of popular commands like ls, stty (in some cases there + are merely front ends to the SysV versions, like stty). + + /usr/new + Contains some interesting utilities, including LESS and PATCH, + and a couple of things I hadn't seen before, VSAR (a screen + oriented version of the SysV SAR) and VMSBACKUP (claims to be + able to read VMS BACKUP tapes). + + man pages + PAGER can be defined as "less -cqm" to use less to page man + pages. There are two man programs, /bsd43/bin/man or /usr/ucb/man, + which prints the BSD man pages, and /usr/bin/man, which prints + the SysV man pages followed by other entries for the named topic, + prompting each time the pager is exited. Given the default search + path, you have to type /usr/bin/man explicitly to get the SysV + version. + + If the SysV STTY is used one needs to use "winsize" to set the + screen size for programs like LESS and VI. (4/26) + +/usr/lib/cmplrs + This directory contains the runtime files for the compilers. It + appears that the system as delivered by MIPS does not have the + latest (2.10) versions of the compilers installed. The installed + versions are all 2.0. I sent mail off to MIPS to see if we can + get the 2.10 compiler tape (we already have the 2.10 Fortran tape, + but this is useless on the MIPS without the 2.10 compiler backend + programs). (4/26) + +/etc/printcap + +/usr/spool/* + +/etc/rc2.d/S01noao + + Configured LPR for the noao devices. (4/26) + +/usr/lib/tmac/tmac.s +/usr/local/bin/itroff* + +/usr/local/bin/vpr + +/usr/local/bin/qdplot + + Configured nroff/troff and the local noao troff and printer queues. + (4/26) + +/usr/lib/aliases + Installed the noao mail aliases file. (4/26) + +------------------------ +Begin IRAF port to the MIPS. +Start with DECstation/IRAF sources, since these are already set up to +use the MIPS compilers. +Using MIPS BSD43 programming environment. (5/27) + +local/.login +unix/hlib/cl.csh +unix/hlib/irafuser.csh +unix/hlib/libc/iraf.h +unix/hlib/mach.h +unix/hlib/mkpkg.inc + 1. Set new iraf root. + 2. In mach.h, change the byte swap parameters to NO. + 3. Checked size of setjmp buffer; DECstation value is larger + than needed for MIPS, so leave it as is. (5/27) + +bin.mips + +noao/bin.mips + +mkpkg +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.MIPS + +noao/mkpkg +noao/lib/mkpkg.inc +noao/lib/mkpkg.sf.MIPS + +unix/mkpkg.sh +unix/setarch.sh + +unix/bin.mips + +unix/as.mips + + Add support for architecture "mips". (5/27) + +unix/os/irafpath.c +unix/os/zgcmdl.c +unix/os/zxwhen.c + 1. irafpath.c and zgcmdl.c modified to discriminate between Ultrix + and RISC/os operating systems: #ifdef mips is true for both systems. + On a DECstation the architecture is known as "dsux", on a MIPS it + is "mips". + 2. Modified zxwhen for the MIPS hardware exception codes. (5/27) + +unix/boot/bootlib/osputenv.c + The MIPS does not have putenv, but it has setenv. (5/27) + +unix/boot/mkpkg/host.c + The MIPS has COFF libraries, so disabled ranlib. (5/27) + +unix/hlib/install + It turns out that when using the BSD version of CC, the include + files in /bsd43/usr/include are used rather than /usr/include. + Modified INSTALL to make an <iraf.h> link in both places (and + manually created the link in order to complete the bootstrap). (5/27) + +------------------- +Bootstrap successfully completed, except for alloc.c which failed to +link. Will take a look at that later. (5/27) + +unix/boot/spp/xc.c + The MIPS is unusual in that it has two sets of compilers (or at + least compiler front-ends) and two sets of programming environments + for BSD and SysV. For our purposes it is simplest to use the BSD + environment. This necessitated a change to XC since we want to + use the versions of CC and F77 in /bsd43/bin rather than the SysV + versions in /usr/bin. + + 1. Modified "run" in XC to search /bsd43/bin before /usr/bin (we + should, of course, be using PATH instead). + 2. Modified XC to link with F77 instead of CC. Using CC is awkward + since the F77 libraries are hidden away in /bds43/usr/lib/cmplrs/... + (5/27) + +------------------- +Begin sysgen. + + The initial sysgen went well except for some problems with the F77 + compiler, which was not installed properly when the system was set + up. First I had to modify XC to use the /bsd43/bin versions of the + compilers (see above). Even when this was done links would still + fail, due to the compiler being only partially installed. I was + able to continue by faking a BSD F77 compiler by combining the 2.10 + F77 front end and libraries with the cc2.0 back end. The full compile + sysgen will have to be redone when the new compilers are properly + installed, and there is little point in pursuing any bugs until + this is done. (5/27) + +math/deboor/mkpkg +math/deboor/setdat.f - +math/deboor/setdat2.f - +math/deboor/setdat3.f - + The DEBOORT math package turned out to have a set of files setdat.f, + setdat2.f, setdat3.f, all of which defined the same routine "setdat" + and which were being redundantly loaded into the library. It turns + out that these routines are not part of the math library anyhow, and + are only used to generate test data for the test programs. I moved + them to deboor/progs (the test programs source library) and deleted + the entries in the mkpkg file. (5/27) + +sys/gio/gks/gcas.x + The MIPS librarian found another duplicate library entry here. The + GKS emulation library has two files gca.x and gcas.x, both of which + define the same routine "gca". Changed the gcas.x version to define + a subroutine "gcas" instead. (These are integer and short versions + of the cell array routine - GCAS is a nonstandard IRAF extension to + GKS, which is not used anywhere to my knowledge). (5/27) + +------------------- +Sysgen complete. + + With these changes the first sysgen completed, except for x_images.e + which failed to link, probably due to the F77 compiler problems + discussed above. Other than that the sysgen went remarkably well. + None of the problems we had with the MIPS compilers on the DECstation + were present on this system. IRAF is up and running, minus IMAGES, + although from browsing the MIPS manuals I see that there are still + some subtle items to take care of. (5/28) + +dev/hosts + Added an entry for node columba and tested iraf networking. (5/28) + +unix/os/zmaloc.c + RISC/os uses the BSD 4.3 memory allocator, which allocates storage in + units that are a power of 2. This can be very wasteful of space for + large buffers, so we don't want to use the default memory allocator. + MIPS provides a couple of other allocators as options, but I had + trouble using these with the BSD43 environment due to unresolved + symbols resulting from the SysV libraries not being searched. + The solution was to replace zmaloc.c by the version used on BSD 4.3 + and Ultrix, which includes an older, simpler, and better behaved + memory allocator. (5/28) + +unix/hlib/libc/iraf.h +unix/os/zzstrt.c +unix/os/zxwhen.c +unix/os/zgcmdl.c +unix/os/irafpath.c + Added a #define MIPS and a commented out #define DSUX. This is more + direct than trying to use #ifdef mips (which is defined by the system) + since this is defined for both the MIPS and DECstation (at least) and + doesn't really tell us what system we are compiling for. (5/28) + +MIPS bug + Running NM on a library with the output redirected causes a + segmentation fault when the process exits. (cd /lib; nm *.a | ...). + +unix/os/zzstrt.c +unix/os/zxwhen.c + Enabled the IEEE exceptions (overflow, divide by zero, and invalid + operand) for MIPS/IRAF processes. Modified ZXWHEN to detect and + decode the floating point exceptions (this required doing bit tests + on the floating point control and status register). + + To figure out how to do this I first did a "man -k ieee". This + turned up a man page for fp[get|set][round|mask|sticky], which + looked like it would do the trick, except that evidently this routine + doesn't exist anywhere in the system (maybe it is a standard SysV + feature which MIPS doesn't support; the man page mentions the default + behavior on 3B systems). By doing an "nm *.a | grep fp" on the system + libraries I eventually turned up set_fpc_csr/get_fpc_csr which is + what is actually implemented on the MIPS. This seems to do the + trick; thus far, setting a nondefault FPCSR doesn't seem to introduce + any new problems. (5/28) + +/etc/init.d/netdaemons +/etc/rc2.d/S01noao +/usr/local/bin/ntp + +/usr/spool/cron/crontabs/root + 1. Had to add a command "route add default gateway 1" to allow network + access to the outside world. + 2. Commented out the gated/routed daemons, which we don't need. + 3. Installed a copy of NTP in local/bin, and set up cron to run it + once a day. This sets the system clock from atomic clock at another + site, by requesting the time via the internet from a network time + daemon running on the remote node. (Forgot to log it, but the timezone + had to be changed to MST a while back too). (5/31) + +----------------------- +New compilers (V2.10) installed and the system bootstrapped and fully +recompiled from scratch. Lacking a tape drive on the system, the compilers +had to be installed manually from the raw distribution tape: I think I set +up all the necessary links etc., but the installation was complex enough +that it is difficult to be sure. (6/19) + +Perusing the output of the sysgen, it appears that there were a number of +problems with the V2.10 compile, whereas the sysgen with the V2.0 compilers +went almost flawlessly. At this point, from the nature of the errors I think +they are real and not something induced by errors in the installation of the +compilers. Another problem was that the disk filled up during the sysgen, +a dangerous problem which can cause errors such as zero length objects being +inserted into libraries. + +At least one compiler bug was observed, this one harmless. Some of the old +NCAR and math library Fortran code contains statement functions. The dummy +variables in such statements functions result in "local variable X never used" +warning messages. (6/20) + +unix/hlib/mkpkg.inc + Added -Olimit 1024 to the default sysgen flags. This sets the max + size in blocks of a procedure to be optimized. With the default + value of 500 the compiler issued warnings for 7 files during the full + sysgen, and failed to optimize 9 procedures. (6/20) + +math/deboor/core +sys/gio/ncarutil/autograph/core +sys/vops/core +pkg/dataio/cardimage/core +pkg/images/tv/cv/core +pkg/images/geometry/core +pkg/plot/core +pkg/xtools/ranges/core +pkg/xtools/core +noao/imred/ccdred/src/generic/core +noao/imred/vtel/core +noao/onedspec/dispcor/core +noao/twodspec/multispec/core + Discovered why the sysgen ran out of disk space - 12 Mb of core + files from compiler optimizer (uopt) crashes! Deleted. (6/20) + +---------------- +I tried recompiling a couple of the files that were associated with +optimizer core dumps in the first sysgen, but could not duplicate the +problem. Started an incremental sysgen to compile the files skipped +in the first sysgen, and this completed without any errors. The system +comes up and runs, ready for runtime testing. (6/20) + +---------------- +/usr/local/bin/saoimage + Installed saoimage. 7.6 Mb left in /usr. As there was so little + disk space, the RISC/os source for saoimage is currently in + /tucana/tmp3/rooke/sao/riscos. (6/21 SRo) + +/usr/man/manl/saoimage.man + Created /usr/man/manl, and placed saoimage manpage in it. (6/21 SRo) + +---------------- +Resume testing on alpha port, 16 July 90. + +sys/vops/amov.gx + This routine could fail, corrupting the data array, in some cases + when the input and output arrays overlap. The same problem exists + in standard V2.9 iraf except that in most iraf implementations, + a host optimized version of AMOV is used, hence the bug has not + been seen. (7/16) + +unix/hlib/mkpkg.sf.MIPS + I added entries for the host optimized versions of AMOV, ACLR, etc., + using the C versions in AS that use bcopy/bzero. Unfortunately + it turned out that the MIPS version of bcopy also cannot be used + when the input and output arrays overlap in a certain way, hence + I had to copy out the entries for the AMOV and BYTMOV routines. + The optimized versions of the ACLR routines are still used. (7/16) + +unix/as.mips/zsvjmp.o + I tried setting the address of MEM to zero and it worked on the MIPS. + The same code failed on the DECstation with a linker error. (7/16) + +unix/os/zmain.c +unix/os/zzsetk.c +unix/os/zfiopr.c + Added a new facility to UNIX/IRAF for debugging interprocess + communication (IPC). This feature will also be useful for debugging + tasks standalone, particularly in cases where a bug seen when the + task is run from the CL is difficult to reproduce when the task + is run standalone. If LOGIPC is defined in the host environment, + the input and output IPC streams of each connected process with + process id PID are logged to the files PID.in and PID.out. (7/18) + +unix/hlib/mkpkg.sf.MIPS + Added system/help/lroff/textout.x to the list of files requiring + compilation without optimization (actually it is the first such file + for this system). Evidently the use of multiple entry points in + this procedure is running into an optimizer bug. The argument "out", + which should be the address of "putline" was being transformed to + the address of "getline" somewhere in this routine, causing output + via textout to be discarded. (7/18) + +sys/imfort/tasks/pcube.f + This file contained a subroutine containing the following sequence of + statements (irrelevant statements ommitted): + + subroutine pcuber (pix, nx,ny,nz, i1,i2, j1,j2, k1,k2) + real pix(nx,ny,nz) + integer nx, ny, nz + + On the MIPS, this produced a warning about nx/ny/nz already having + been declared. Probably when the compiler processes the REAL + statement it assumes the parameters are type integer. This seems + reasonable, so I moved the INTEGER card up before the REAL and the + warning went away. (7/19) + +unix/os/zxwhen.c + While looking into a problem of a task aborting on a floating point + exception, I noticed that the IEEE exception being reported was + "floating inexact", which iraf does not enable. It turned out that + both inexact and overflow were being signalled, but due to the way + the zxwhen code was written only the inexact was being reported. + Since we are not very interested in those exceptions which are not + enabled, I changed the code to check the exception bits for the + enabled exceptions before checking the others. + + In this case the exception of interest was floating overflow, which + is occuring in the routine DET called by SPLOT. It appears that + the matrix being input to this routine is garbage. Since only the + one application is affected I will leave it to someone else to check + into it further. (7/19) + +------------- +Full system testing has been in progress for the past week or so. Things +looks pretty good. One task is dying with an out of memory error; after +hunting around a bit, I determined that the MIPS/SysV command used to +monitor swap space usage is "swap l", which gives the free space in 512 +byte blocks. (7/30). diff --git a/doc/ports/notes.osf1 b/doc/ports/notes.osf1 new file mode 100644 index 00000000..09bb2399 --- /dev/null +++ b/doc/ports/notes.osf1 @@ -0,0 +1,409 @@ +DEC Alpha OSF/1 V2.0 port. Begun 28 December 1994. +Based in part on the preliminary port done by Nelson Zarate of STScI. +Starting point is the Solaris/IRAF system at V2.10.3. +This platform is BSD-oriented with only partial SYSV support so we +will use the BSD code in the HSI. +-------------------------------------------------------------------------- + +unix/hlib/motd + Edited the motd to indicate that the system is DEC-ALPHA/IRAF, + alpha test version. (12/28) + +unix/hlib/irafuser.csh + Edited this file sufficiently to allow it to be sourced during login. + 1. Set MACH to "alpha" using `uname -m`. + 2. Set HSI flags to define "OSF1" for compile time ifdefs. For the + moment set all other HSI compile and link flags to null. + 3. Added some code to try to automatically determine $iraf if not + defined in the user's environment when the script is run. A list + of standard root directories are searched for; these can be links + to the actual location and it will still work. (12/28) + +unix/hlib/libc/spp.h + 1. Set LEN_JUMPBUF to 2*(84+1) for the Alpha (the 2 is because IRAF + uses type int for the array while OSF1 uses type long). (See also + hlib/config.h below). + 2. Set XLONG to int (=32 bits) for this 64 bit machine. + 3. Compiled osb/zzeps2.f and verified that the IEEE epsilons work. + 4. OSF1 f77 evidently uses trailing underscores so it should not + be necessary to modify the Fortran/C name mappings. (12/28) + +unix/hlib/libc/kernel.h + 1. SIGFUNC is a pointer to void for OSF1. + 2. OSF1 has bcopy but the manpage does not say whether it can handle + overlapping arrays, so we will use memmove/memset instead. (12/28) + +unix/hlib/libc/setjmp.h + Comment out the #pragma unknown_control_flow, not support for OSF1 + and there doesn't appear to be anything comparable. (12/28) + +unix/os/getproc.c + Added an #ifdef OSF1 to cause the nlist-based code to be used. (12/28) + +unix/os/irafpath.c + Added a #ifdef __alpha for the alpha architecture. (12/28) + +unis/os/zfioks.c + Changed a number of #ifdef SOLARIS conditionals to #ifdef OSF1 + where appropriate. (for example use the select macros, updated + typing for socket calls). (12/28) + +unis/os/zfiond.c + Modified to use the socket macros as above. (12/28) + +unix/os/zgcmdl.c + Modified similarly to the Ultrix version, using the external __Argv + to pick up the host argument list. (12/28) + +unix/os/zopdir.c + 1. Modified to use <dirent.h>. (12/28) + 2. zopdir would pass back a pointer coerced to an int as the "file + descriptor" but this would fail on 64 bit systems where pointers + don't fit in 32 bits. Modified the routine to allocate a kernel + file descriptor for the directory and pass back a normal fd instead. + (12/29) + +unix/os/zxwhen.c + Modified for OSF. OSF1 has sigaction, so this is used for handling + the floating point exceptions (as with Solaris). (12/28) + +unix/os/zzstrt.c + Modified to call the OSF1 function ieee_set_fp_control to enable the + invalid, divide by zero, and overflow exceptions. (12/28) + +unix/os/zdojmp.c + Had to modify to treat jmpbuf as pointer to long rather than to int, + in order to retrieve the quadword address of the status variable + from jmpbuf[0] and to correctly compute jmpbuf[1]. (12/28) + +unix/as.alpha + +unix/as.alpha/zsvjmp.s + + Set up an AS directory for the alpha/osf HSI. Wrote an Alpha version + of zsvjmp. The trick with this one, which I missed at first, was + to set register 27 (pv) to the address of setjmp before branching + into it. The alpha procedure calling sequence assumes that the caller + of a procedure does this and it is required to set the global pointer + correctly for the procedure being executed. + + The STScI version of zsvjmp (produced by technical support at DEC) + could not be used as it was just setjmp with the name changed. + The status argument used by zsvjmp was being ignored, and setjmp + was being called with the wrong jump buffer address. (12/28) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.OSF1 + + Set up a basic mkpkg.inc for OSF1. (12/28) + +unix/.../mkpkg.sh + The OSF1 compilers refuses to produce a file with the extension ".e", + so all the HSI mkpkg.sh files were modified to use .E instead. When + the executables are moved to $hbin the extension is changed to .e. + (12/28) + +unix/os/prwait.c + Like Solaris, OSF1 wait() wants an int exit_status argument. (12/28) + +unix/os/zgtime.c + time() is of type time_t in OSF1. (12/28) + +unix/os/gmttolst.c +unix/boot/bootlib/ostime.c + These routines use ftime() which on OSF1 is only available in an + optional compatibility library. Added a #ifdef OSF1 case which + uses localtime() instead of ftime to compute the timezone in + seconds west of GMT. (12/28) + +unix/hlib/irafuser.csh + 1. Set the default optimization level for Fortran files to -O3, to + disable inter-procedural optimization which causes a warning when + compiling files for a library. + 2. Added a -lots reference to HSI_F77LIBS, this library is evidently + used internally by the Fortran compiler. (12/28) + +unix/boot/wtar/wtar.c + Fixed a bug in WTAR involving coercion of a pointer to an integer + (line 536, bp = ...). (12/28) + +unix/boot/spp/xc.c + Modified for OSF1. The Solaris version pretty much works, about + all I had to modify was the list of Fortran libraries. Also set + the default optimization to -O3 for f77 (-O1 for cc) and set up to + produce a .E output executable which is renamed to the .e version + internally. (12/28) + +--------------------------- +Completed bootstrap. (12/28) +Attempted the first sysgen, numerous errors to be tracked down. + +unix/boot/spp/xc.c + Modified XC to call f77 with "-warn nounreachable" when compiling + SPP generated Fortran files. Technically unreachable statements + occur naturally and harmlessly in some cases in SPP generated Fortran. + (for example in compile time conditionals). (12/29) + +sys/gio/gks/gcas.x + Changed the procedure name from "gca" to "gcas". There is already + another procedure in the same library called "gca". "gcas" is + supposed to be the type short version. (12/29) + +sys/gio/ncarutil/autograph/agrstr.f + Commented out statements number 901, 902: "no path to this statement". + These statements are never called as the code that calls them is also + commented out. (12/29) + +sys/gio/ncarutil/autograph/agsave.f + Same thing, statement 901. (12/29) + +sys/gio/ncarutil/conlib/consld.f + Commented out statement functions SCRTCH and IARVL. These are never + called and result in a warning message. (12/29) + +sys/gio/ncarutil/conrec.f + Commented out three lines around line 1226. These lines were no + longer used because other code had been commented out, and were + resulting in a "Variable XX is used before it value has been + defined" warnings. (12/29) + +sys/gio/nspp/sysint/encd.f + Commented out several lines that were no longer used and were causing + a "no path to this statement" warning. (12/29) + +math/deboor/setdat2.f +math/deboor/setdat3.f + This library contains three files setdat.f, setdat2.f, setdat3.f + all of which contain a procedure "setdat", causing library conflicts. + These routines are not really part of the library anyway and are + only used to generate data for examples in DeBoor's book, but to + avoid the library conflicts I changed the names of the second and + third procedures to setdt2, setdt3. (12/29) + +pkg/xtools/icfit/icdosetupd.x + Problem with mixed type real and double arguments in calls to + the min and max intrinsic functions for xmin, xmax. (12/29) + +pkg/cl/bkg.c +pkg/cl/builtin.c +pkg/cl/compile.c +pkg/cl/config.h +pkg/cl/debug.c +pkg/cl/decl.c +pkg/cl/errs.c +pkg/cl/exec.c +pkg/cl/gram.c +pkg/cl/main.c +pkg/cl/mem.h +pkg/cl/modes.c +pkg/cl/opcodes.c +pkg/cl/opcodes.h +pkg/cl/operand.c +pkg/cl/param.c +pkg/cl/prcache.c +pkg/cl/scan.c +pkg/cl/stack.c +pkg/cl/task.c + The CL has long defined the dictionary and stack as arrays of + unsigned integer. This causes problems on a 64 bit machine like + the Alpha where integer and pointer are not the same size. + To avoid this problem a new type "memel" was defined in a typedef + in config.h. The CL code was modified as necessary to declare + all dictionary and stack storage and references using this new + type. (12/29) + +pkg/cl/scan.c + The varargs code in this routine failed to compile on the Alpha, + which defines va_list as a structure rather than a variable. + This caused a (va_list) cast to fail. After studying this for + a while I couldn't find any way to safely and portably use varargs + to fake an argument list as an array. The solution adopted was + to just make a normal call to sscanf, putting the variable number + of arguments on the argument list in the normal fashion as v[0], + v[1], v[2], and so on. The current implementation imposes a + limit of at most 32 arguments for a CL scan operation. (12/29-30) + +unix/as.alpha/ieee.gx +unix/as.alpha/ieeed.x +unix/as.alpha/ieeer.x + Installed the DEC little-endian versions of the IEEE conversion + routines. (12/29) + +mkpkg +noao/mkpkg + Added an entry for the "alpha" architecture. (12/29) + +unix/hlib/mkfloat.csh + 1. Modified to look for .E files as well as .e files. + 2. The script was failing because tar -tf would output file names + with a trailing space after the filename (surely a bug in OSF1 tar). + Had to add a filter to trim the whitespace. + 3. Modified the script to treat the "generic" architecture specially, + avoiding any attempt to restore any binaries etc. (12/29) + +sys/libc/zzdebug.c -> zztest.c + Renamed zzdebug.c zztest.c to avoid a name conflict with the zzdebug.x + in the same directory. (12/29) + +unix/hlib/libc/stdio.h + In struct _iobuf, changed the type declarations from long and int + to XLONG and XINT. (12/29) + +unix/hlib/config.h + Also set LEN_JUMPBUF here (see above). (12/29) + +dev/hosts + Added an entry for "lyra" to the hosts table. (12/29) + +--------------------------- +Completed sysgen. Core system runs now but a few bugs are evident and remain +to be tracked down. (12/29) + +dev/pix.imh +dev/pix.pix +dev/wpix.imh + Replaced these files with the little-endian versions from Ultrix/IRAF. + Having unreadable images was a major source of the "system" problems! + (12/30) + +lib/helpdb.mip +noao/lib/helpdb.mip + The help system would not read these files... Had to rebuild them + to get things to work. Woops - I forgot to set the byte swap flags + in the HSI before building IRAF. (12/30) + +unix/hlib/mach.h + Set all the SWAP variables to YES. Did a sysgen update. (12/30) + +unix/hlib/install + Modified the install script for OSF1. (12/30) + +unix/boot/spp/xc.c +unix/hlib/mkpkg.inc + Moved the "-taso" flag into XC. This is needed to compile all + iraf programs on the Alpha, and users shouldn't have to type it + when running XC standalone outside of mkpkg. (12/30) + +--------------------------- +Core system is up and running now with no serious bugs evident. +Built bin.alpha for TABLES package. The libraries built (all IRAF uses) +but the compiler core dumped trying to link the executables. Haven't +looked into it yet. Started a sysgen of NOAO. + +noao/artdata/t_mk1dspec.x + Fixed two cases of MAX called with arguments of different types, + in this case the real constants 1. and 0. were being compared to a + type double expression. (12/30) + +noao/mtlocal/cyber/pow.inc +noao/mtlocal/cyber/rrcopy/pow.inc - +noao/mtlocal/cyber/rrcopy/rcrbits.x + The include file pow.inc contained some very small real constants + in the E-38 or E-39 range, which caused compile time evaluation errors. + The offending values in the table were replaced by the value 0.0. + Probably other platforms that don't report this problem have been + underflowing to zero when evaluationg the these values. Deleted + the rrcopy of pow.inc and modified the include in rcrbits.x to + reference the version in the root directory instead. (12/30) + + This program is pretty much obsolete and should probably be retired, + but it is easier to fix the compile time problems for now. + +unix/hlib/mkpkg.sf.OSF1 + Added cl$ytab.c to the list of special files for OSF1. This file + needs to be compiled with -Olimit 2048 to have enough table space + to optimize such a large file. (12/30) + +unix/hlib/fc.csh + Modified for OSF1. The main change required was that the file + /usr/lib/cmplrs/fort/for_main.o must be explicitly included on the + link line in order to link the Fortran program. (12/30 1994) + +--------------------------- +Merged in latest 2.10.3 revisions from tucana. (2/16 1995) + +dev/tapecap + Modified the Ultrix/IRAF tapecap to add support for OSF/1. Added + compressed and uncompressed DAT (TLZ06) unit 0, 1 entries. These + worked on the first try, although I did have to add an ":se" to + make appending work after readting to EOT. (3/01) + +unix/as.alpha/ieee.gx + I did not actually modify this file for the problem noted below, + but wanted to record this oddity of the Alpha architecture. (3/01) + + The inconsistency seen on the Alpha with the IEEE test files is not + due to the NaN values, which are handled correctly, but to the + special case negative zero (-0) value included in this test data. + For some reason the Alpha fp unit is generating an exception for an + operation comparing zero and negative zero. Other platforms have + not had a problem with this (although one wonders what the correct + result should be in this case). It does seem rather an odd problem + and it is not clear if it is worth worrying about. If necessary we + can modify our IEEE i/o routines to map such values to positive zero + but I don't know if it is worth it, unless we find out that such + values can occur in real world data. + +--------------------------- +Merged in latest 2.10.4 revisions from tucana. (4/20 1995) + +unix/os/mkpkg.sh + Modified the OS boot mkpkg.sh to use as$zshlib.s rather than + os$zshlib.c. The mkpkg special file list was set up to do this, but + the wrong version was used when the system was bootstrapped. (4/21) + +unix/hlib/mkpkg.sf.OSF1 + Modified to compile as$zshlib.s without optimization, the default xc + flags produce a warning message when used to compile as$zshlib.s. + (4/21) + +unix/os/zxwhen.c + This code was modified to use signal instead of signal plus sigaction. + I was having problems with signals not being caught resulting in + infinite loops. See the comments in the code. (5/03) + +unix/os/zawset.c + Installed new version from tucana. (5/03) + +unix/hlib/libc/kernel.h + Modified values of SZ_DEFWORKSET and SZ_MAXWORKSET to 8 Mb and 256 Mb + as was done on tucana for ZAWSET above. (5/03) + +unix/hlib/zzsetenv.def + Default printer changed to "lp". (5/03) + +unix/os/mkpkg.sh + Fixed a couple minor problems found in redoing the bootstrap. + 1. Changed HSI_LIBS to HSI_OSLIBS for building zalloc.e, which doesn't + use the IRAF libraries. + 2. The "set zsrc = ..." was incorrect for the Bourne shell, changed + to BS syntax. (5/03) + +unix/os/zawset.c + This routine would not work properly on OSF/1 even though it should + according to the docs (behavior should be the same as on other + systems). Any attempt to set RLIMIT_RSS would fail, causing the + value 50 to be returned. Modified the code to merely comment out + the setrlimit. getrlimit still works and the routine will still + return an accurate indication of the physical memory available to a + process. Probably this problem with setrlimit() explains why the + "limit" command in the cshell doesn't work either. (5/09) + +unix/hlib/spy.cl + Updated to use ps -ef instead of px -axu. (5/23) + +sys/fio/fioclean.x +sys/fio/stropen.x + Two new internal routines str{set,get}mode were added to stropen.x. + These are used to set or query the file access mode as strored for + the string file, which represents these in a file-dependent way. + fio_cleanup was modified to force the access mode of a string file + to READ_ONLY before closing it during file cleanup, to prevent the + writing of the trailing EOS when closing a string file opened for + writing. The latter could cause a segmentation violation if the + string buffer was no longer in a mapped region of memory, as is + possible if the string file is still open (i.e. not closed normally) + following task termination when fio_cleanup is called. (6/06) + +--------------------------- +V2.10.4 release June 07 1995. + +unix/hlib/install + Changed /etc/mknod to /usr/sbin/mknod. (6/21) diff --git a/doc/ports/notes.solaris b/doc/ports/notes.solaris new file mode 100644 index 00000000..46a5fed2 --- /dev/null +++ b/doc/ports/notes.solaris @@ -0,0 +1,514 @@ +Begin IRAF port to Solaris 2.3 +Wed May 25 15:38:55 MST 1994 +---------------------------------------- + +bin.ssun + +bin.ssun/IB.SSOL.SUN + +bin.sf2c + +bin.sf2c/IB.SSOL.F2C + +noao/bin.ssun + +noao/bin.ssun/IB.SSOL.SUN + +noao/bin.sf2c + +noao/bin.sf2c/IB.SSOL.F2C + + Set up the Solaris platform (SSOL = Sun Solaris) and the two planned + Solaris architectures, SUN (Sun unbundled compilers) and F2C (F2C + and FSF compilers). (5/25) + +unix/hlib/irafuser.csh + 1. Replaced the `mach` reference by something that will work on both + SunOS and Solaris, using uname. + 2. Modified to define either SUNOS or SOLARIS in HSI_CF, so that + kernel code can support both systems. (5/25) + +unix/os/getproc.c + Added a Solaris version of uid_executing(). This reads /proc and + scans the process files to see if any belong to the given uid. (5/25) + +unix/hlib/irafuser.csh +unix/os/mkpkg.sh + 1. alloc.e would no longer link without linking against the library + -ldl. Note that -ldl can only be linked dynamic (no -Bstatic). + 2. Added a new definition HSI_LFLAGS to irafuser.csh and modified the + mkpkg.sh in OS to use this to define the link flags for alloc.e. + This will probably have to be done for other HSI executables as well. + (5/25) + +unix/os/prwait.c + Solaris defines the exit_status argument to wait() differently and + the code had to be modified to allow for this. (5/27) + +unix/os/zfioks.c + The select facility on Solaris uses fd_set, FD_SET, etc. and it + was necessary to add #ifdef SOLARIS code to reflect this. (5/27) + + +Fri Jun 24 14:23:32 MST 1994 +---------------------------------------- +Resume port (elsewhere for the past month) + +unix/hlib/libc/kernel.h + Added a definition PFV; PFI is now a pointer to function returning + int, and PFV is a pointer to a function returning void. Also added + a new definition SIGFUNC, which is whatever type signal() refers to + on the local system. (6/24) + +unix/os/zfioks.c + 1. Changed a number of PFI instances to SIGFUNC. + 2. Changed the second two arguments to ks_onsig to type int*. These + are not used and the actual type is different on Solaris than other + systems. Probably the args should just be omitted but it may be + more portable to define a couple of dummy args. + 3. The second argument to bind() is type (struct sockaddr *) in + Solaris, was (caddr_t) on other systems. (6/24) + +unix/os/zfiotx.c + 1. Deleted the import_fset, which apparently isn't used and which + contains a #define which conflicts with a Solaris one. + 2. Changed a bunch of PFI instances to SIGFUNC. Added some + (SIGFUNC) declarations to the signal handler arguments to signal(). + 3. Replaced the two dummy arguments (same as item 2 above) in three + instances of event handlers with dummy args declared (int *). (6/24) + +unix/os/zopdir.c + Modified to use Solaris version of opendir/readdir. (6/24) + +unix/os/zoscmd.c + Modified to use SIGFUNC instead of PFI, and to declare generic + dummy arguments for an event handler. (6/24) + +unix/os/zshlib.c + Fixed a syntax error on the last line, an extra ';' following a + stubbed out function declaration. (6/24) + +unix/os/zwmsec.c + 1. Modified to use signal instead of sigvec; the latter is BSD specifc. + 2. sigpause() takes a signal number instead of a signal mask. Omitted + sigblock, which is no longer needed since we aren't using a mask, and + which doesn't exist on Solaris. + Possibly this routine should be completely rewritten on Solaris, + there may be better facilities for small timed delays. (6/24) + +unix/os/zxwhen.c + 1. For Solaris we must include <sys/siginfo.h> and <sys/ucontext.h>. + 2. fcancel macro modified to use the constant BUFSIZ. + 3. The table of hardware exceptions was modified to omit all + codes other than those for SIGFPE; the other codes (at least on + Solaris) alias with the FPE codes, and aren't used anywhere in + zxwhen anyway. Added Solaris SIGFPE codes. + 4. Modified calling sequence of exception handler ex_handler to + the form Solaris requires. Added a statement to get the hardware + exception code out of the siginfo argument. + 5. Replaced a number of PFI's by SIGFUNC's. (6/25) + +unix/os/zfiomt.c + Modified signal handling code to use type SIGFUNC. (6/25) + +unix/os/zzstrt.c + Made a few changes to get this code to compile, although the shared + library support isn't expected to work at this point. (6/25) + +unix/hlib/irafuser.csh +unix/os/zzstrt.c + Added a new define SHLIB, used to conditionally compile zzstrt for + shared library support. (6/25) + +unix/boot/bootlib/bootlib.h + This file had a #ifdef UNIX in it, but this define is not defined + anywhere. Modified to #ifdef VMS but assume unix otherwise. (6/25) + +unix/hlib/irafuser.csh + Modified to define RANLIB as "echo ranlib" for Solaris. (6/25) + +unix/hlib/kernel.h + Solaris doesn't have bcopy/bzero, so added a couple of #defines to + kernel.h to map these functions onto the equivalent Solaris versions + memmove/memset. (6/25) + +unix/os/zoscmd.c +unix/os/zopdpr.c +unix/os/zfiopr.c + Replaced all calls to getdtablesize() by corresponding calls to + getrlimit(). (6/25) + +unix/os/zfgcwd.c + Replaced getwd() by getcwd(). (6/24) + +unix/boot/mkpkg/scanlib.c + It was necessary to add an (int) cast to (int)fread(...) > 0 + to avoid a warning message from the compiler, because fread has an + odd type on Solaris. (6/25) + +unix/hlib/irafuser.csh + Added -lsocket -lnsl (the Solaris socket emulation library) to the + list of HSI host libraries used to link the HSI utilities. (6/25) + +unix/boot/spp/xc.c + Made some minor changes to xc for Solaris - not clear yet what all + will be needed. Most of it looks like it will work. Added a #ifdef + conditional for the Solaris F77 libraries, taking the SunSoft + compiler as the builtin default. Modified signal handling to use + SIGFUNC to be more portable. (6/25) + +unix/boot/rmfiles/rmfiles.c + Added an "extern char *vfn2osfn()" declaration. (6/25) + +unix/boot/spp/rpp/ratlibc/initst.c + Added a #ifdef conditional to access the stdio streams on Solaris. + (6/25) + +unix/gdev/sgidev/sgi2uapl.c +unix/gdev/sgidev/sgi2uhpgl.c +unix/gdev/sgidev/sgi2ueps.c + 1. These files contained a number of cases where the file descriptor + "out" was declared int where (FILE *) was intended. + 2. Replaced an instance of gethostname() in sgi2uapl.c by a call + to sysinfo(). (6/25) + + +Sat Jun 25 23:26:24 MST 1994 +---------------------------------------- +Completed first bootstrap. Try initial sysgen of core system. + +unix/boot/spp/xc.c + Modified xc to automatically do a "-t" when linking. This disables + linker warnings about different size commons. (6/26) + +unix/os/irafpath.c + Added a case for Solaris/sparc. (6/26) + +mpkg +as.ssol + +bin.ssol + +unix/setarch.sh +unix/hlib/irafuser.csh + For Solaris/sparc the HSI AS and BIN are as.ssol and bin.ssol. + Hopefully it will be possible to use a single set of directories + for both the ssun and sf2c binary architectures. (6/26) + +unix/hlib/install + Added some code to set the platform architecture automatically for + either SunOS or Solaris. On a Solaris system the suntools stuff is + skipped. (6/26) + +unix/boot/bootlib/envinit.c + Fixed a bug/typo in this code: "printf (stderr, ...)". (6/26) + +unix/boot/bootlib/vfn2osfn.c + Several more cases of a null statement ";" at the end of this file. + This happens in dummy function constructs like "foo(){};". (6/26) + +unix/hlib/mkpkg.inc + Added cases for IRAFARCH=ssun and sf2c. (6/26) + +unix/hlib/mkpkg.sf.SSUN + +unix/hlib/mkpkg.sf.SF2C + + Added starter special file lists for the two Solaris architectures. + (6/26) + +unix/as.ssol/zsvjmp.s + This assembler source appears to assemble ok, but I had to remove the + leading underscore from _zsvjmp_ as the SunSoft Fortran compiler + doesn't use leading underscores. (6/26) + + +Sun Jun 26 20:18:48 MST 1994 +---------------------------------------- +Completed first core system sysgen: system starts up and runs, but a number +of bugs are evident. + +unix/hlib/irafuser.csh + HSI_XF now includes flags such as -/DSYSV -/DSOLARIS etc., so that + mkpkg can be used to update HSI libraries such as OS. This is only + a temporary solution, ideally XC should accept HSI_CF. (6/27) + +sys/fio/fdirname.x + There was an actual bug in this file that showed up during testing + of the new port. zfxdir (kfxdir) was being used incorrectly to + test for the existence of host directory pathnames. (6/27) + +unix/os/zopdir.c + The above testing also revealed a bug in this file. This was + preventing commands such as "dir /" from working, due to a bug in + the code which strips trailing slashes from directory names. (6/27) + +unix/os/zfiotx.c + 1. Raw mode terminal i/o was not working properly on Solaris; output + data was being lost when raw mode was entered, even though the ioctl + used would (presumably) wait for the output to drain before changing + the terminal mode. It is not clear what the connection might be, + but this was fixed by deleting the iflag=0, i.e., not resetting the + iflags, when entering raw mode. Evidently clearing one of the + default input flags was the source of this problem, even though + ICANON was disabled. Since ICANON is disabled we shouldn't need + to change the iflags anyway, so it should be safe to omit this. + In fact, it is probably safer to preserve all default terminal flags + by default and change only those affecting raw i/o, but at present + I will leave it fully setting the oflags and lflags, since this + is working. + 2. Solaris also provides the POSIX termios interface which is the + recommended interface. This appears to be a simple front end to + the termio ioctl interface. I decided to avoid this for the moment + since the SYSV termio interface appears to be widely available. + (6/27) + + +Sun Jul 3 23:08:27 MST 1994 +---------------------------------------- +Resume work on Solaris port. + +unix/as.ssol/enbint.s + +unix/os/zzstrt.c +unix/os/zxwhen.c + After a bit more research got IEEE floating point exception handling + working under Solaris. The new routine enbint.s is used to enable the + exceptions. sigaction turned out to block SIGFPE when the handler + was called and it proved necessary to add the SA_NODEFER flag to + prevent this. (7/03) + +unix/os/zfioks.c +unix/os/zfiond.c + Fixed a couple bugs that were keeping networking from working. + "RSH" was not being defined correctly in zfioks, and it was necessary + to add FD_ZERO calls to zero the select fd arrays before calling + FD_SET. (7/04) + +sys/imfort/tasks/ +unix/hlib/fc.csh + Tested FC on the imfort tasks. This worked without incident following + minor changes to the fc.csh script. The only thing unusual is that + an IEEE retrospective is printed when the task exits, indicating + that the IEEE divzero,overflow,invalid exceptions were enabled. + This is annoying but is not exactly a bug (ieee_retrospective is always + called by Fortran programs, it just doesn't usually generate any + output), so for the moment I don't see the need to change anything + at present. (7/04) + +Build of ssun binaries for TABLES proceeded without incident. (7/04) + +unix/boot/bootlib/ossymlink.c + This file used #ifdef BSDUNIX incorrectly, preventing the #ifdef-ed + code from compiling on UNIX systems for which BSDUNIX was not set. + Changed the statement to #ifndef VMS. (7/05) + +unix/shlib/zzzend.c + Deleted ";" at the end (empty declaration). (7/10) + +unix/shlib/medit.c + Added a #define for bcopy, which doesn't exist in Solaris. (7/10) + +unix/shlib/mkpkg + Modified to avoid use of ranlib on Solaris platforms. (7/10) + +unix/boot/spp/mkxc.sh + Modified to do the compile and link in separate steps. (7/14) + +unix/gdev/sgidev/sgi2uapl.c + Modified to put "%!PS" in the Postscript file header. (7/19) + +dev/tapecap + Added Solaris support. (7/20) + +unix/boot/spp/xc.c + Added -lintl to the list of builtin host libraries. (7/23) + +unix/os/zfiotx.c + Rather than leaving iflags unmodified when raw mode is entered, + now clears several input processing flags, in particular CR is not + mapped to NL. (7/23) + +unix/hlib/zzsetenv.def + Changed the default printer device to "lw". (7/25) + +unix/shlib/Slib.c +unix/shlib/edsym.c +unix/shlib/elf.c + +unix/shlib/medit.c +unix/shlib/mkpkg +unix/shlib/mkpkg.sh +unix/shlib/mkshlib.csh.ssol + +unix/shlib/zzzend.c +unix/os/zzstrt.c + There were many changes here, especially to mkshlib.csh, edsym.c, + Slib,c, and zzend.c, to support IRAF shared libraries under Solaris. + Most of the changes were made earlier but I did not keep detailed + notes during development. The changes are not fully backwards + compatible, so it will be necessary to configure separate shlib + directories for SunOS and Solaris. (7/25) + +unix/hlib/mkpkg.inc + A wfits problem was traced to a bug in the Fortran optimizer using + SunSoft Fortran 2.0.1. Compiling -O2 avoids the problem. (7/29) + +unix/hlib/install + The install script was modified earlier to just exit when it came + to the gterm/imtool config stuff. Modified this to continue on + with this, but to do only the X11 related configuration. This + consists of making the /dev/imt fifos, installing the imtoolrc, + and checking that termcap and graphcap are sufficiently up to date + to contain xgterm and imtool entries. (7/30) + +unix/hlib/libc/kernel.h +unix/os/zfiotx.c +unix/os/zzstrt.c + Replaced the terminal driver by a version which maintains a unique + descriptor for every hardware terminal device, regardless of the + file descriptor used to access the terminal. (8/02) + +dev/graphcap + The xgterm graphcap entry now recognizes either CR or LF as the + trailer code for a cursor read. (8/02) + +unix/boot/mkpkg/mkpkg + Changed "cc" to "$(CC)". (8/17) + +unix/boot/spp/xc.c + XC now supports multiple packages in PKGENV. (8/18) + +----------------------------------------------------- +Solaris 2.10.3 release +*** apus upgraded to Solaris 2.4, SunSoft V3.0 compilers *** + +unix/os/zfiotx.c + Installed the tty_reset bugfix. (9/17) + +unix/os/getproc.c + This routine was omitting the "/proc" from pathnames of process + files in the /proc directory, causing uid_executing to always + return zero. (10/05) + +----------------------------------------------------- +Merged in V2.10.4 revisions from tucana. (4/22 1995) + +unix/hlib/mkpkg.sf.SSUN + Added explicit $xc build commands to the special file list entries for + C files. The default compile flags from mkpkg.inc would cause a + warning when applied to C files, as CC doesn't understand -O2. (4/26) + +unix/shlib/mkshlib.ssol-sc2 +unix/shlib/mkshlib.ssol-sc3 + + Renamed mkshlib.csh.ssol to mkshlib.ssol-sc2. This is the version for + the version 2x SunSoft compilers. Started a variant mkshlib.ssol-sc3 + for the version 3x compilers. In this made various minor changes: + 1) File header size increased from 0x74 to 0x78. + 2) Compiler libraries and objects are now in /opt/SUNWspro/SC*/lib + instead of /opt/SUNWspro/SC*. + 3) There is a new library -lsunmath which follows -lF77. (4/26) + +unix/boot/spp/xc.c + Modified to add the -lsunmath library if used with the Version 3 or + greater SunSoft compilers. XC attempt to automatically distinguish + Version 2 and Version 3 and do the right thing. (4/26) + +unix/hlib/mkpkg.inc + Removed the -O2 switch from the standard compile flags in mkpkg.inc. + This was put in for an older version of the compilers and probably + isn't needed any longer. This also avoids the problem of passing -O2 + to the C compiler when compiling C code. (4/26) + +----------------------------------------------------- +Completed a full bootstrap and sysgen of V2.10.4 Solaris/IRAF using +Solaris 2.4 and the SunSoft V3 compilers. (4/26) + +unix/hlib/zzsetenv.def + Updated "version" to 2.10.4EXPORT. (5/18) + +unix/hlib/spy.cl + Rewrote spy.cl to work on both BSD and SYSV systems (SunOS and + Solaris in the case of Solaris/IRAF). (5/19) + +unix/os/zgtime.c + Modified for Solaris systems to use CLK_TCK (which does a runtime call + to sysconf) to get the clock frequency, instead of the compile time + kernel constant CLKFREQ. On our development system CLK_TCK is 100, + rather than 60 which is the value compiled into the kernel. (5/19) + +unix/os/gmttolst.c + In the internal routine get_timezone added a call to "tzset()" + before accessing the external variable timezone. This is necessary + to set the value of timezone in the first call after process + startup. (5/19) + +unix/os/zoscmd.c + This fix was made to resolve a problem where EMACS or VI would + hang up when run from the CL and ctrl/g or ctrl/c was typed. + Evidently this was due to the code in zoscmd.c which pretends to + ignore interrupts while the child is executing, but in reality was + catching interrupts and setting a flag then continuing to wait for + the child process to terminate. Evidently on SysV systems, or at + least on Solaris, the interrupt handler was causing the process + to read from the terminal, and wait() was not being reentered + folowing an interrupt causing both the parent and the child to read + from the terminal at the same time. The fix was to modify zoscmd.c + so that on SYSV systems the parent does not post any interrupt + handler. (5/19) + +unix/os/zzstrt.c +unix/shlib/mkpkg +bin.ssun/S10_5.4.e + + It appears that the system library libsocket.a in Solaris is + incompatible between Solaris 2.3 and 2.4. Networking is broken if + an IRAF executable linked under Solaris 2.3 is run on 2.4 and vice + versa. Our workaround, at least for the moment, is to have different + versions of the IRAF shared image for different versions of solaris. + During startup an IRAF process will query the OS release number, + e.g. 5.3 (Solaris 2.3) or 5.4 (Solaris 2.4) and map the corresponding + shared image. A mkpkg in unix/shlib updates the version of the + shared image corresponding to the OS release on which IRAF is + currently running. The new shared image file names are S10_5.3.e + for Solaris 2.3 and S10_5.4.e for Solaris 2.4. If the release + dependent version is not found the system will automatically fall + back to S10.e. (5/22) + +----------------------------------------------------- +Did another sysgen-relink and rebuilt the distribution files. (5/22) + +unix/boot/spp/xc.c + Modified to compile only C and assembler files in the catch-all + compile phase. Prevents compile attempts where the file list + contains only object files. This was a problem under Solaris 2.5. + (10/19) + +unix/shlib/mkshlib.ssol-sc3 + Modified to suport the SC4.0 compilers under Solaris 2.5. There was + a bug in the script if both SC3.0.1 and SC4.0 compilers were present + in the same system. The link line was slightly different for the + new compiler. (10/19) + +unix/shlib/mkshlib.ssol-sc3 - +unix/shlib/mkshlib.ssol-sc34 + + 1. Changed the name of this file to sc34 since it supports both the SC3 + and SC4 compilers. Updated the comments accordingly. + 2. I tried changing the page alignment for the shared image from + 0x2000 (8K) to 0x4000 (16K). The intent was to support Sparc clones + with 16K pages. It worked (at least on a Sun sparc), but would + produce a bogus version match please relink error message on startup + for old executables, due to relocation of the transfer vector. I had + to set things back to 0x2000 as we can't afford to break old + executables for a patch. (3/25 1996) + +unix/os/zmain.c + Added a #ifdef SYSV conditional to allow for different calling + sequences for setpgrp() on SYSV and BSD systems. (4/24) + +unix/os/zfinfo.c + Commented out the setpwent/getpwent, they are not needed on Solaris + and appear to cause an associated Solaris bug to crop up. (8/16) + +------------------------------------------- +V2.10.4 patch 2 released. (5/22 1996) + + +TODO + o Tue Nov 21 12:50:24 MST 1995 + XC assumes /opt/SUNWspro in isv3(). + + o Thu Feb 1 11:54:17 MST 1996 + Skip reports networking failure - AA05224 + + o Mon Mar 11 12:24:55 MST 1996 + Modify zawset.c to use actual physical memory as determined by sysconf. + + o Mon Mar 11 12:25:10 MST 1996 + Change SHLIB address from 0a000000 to 03c000000 to allow 1 Gb process + data segment. This requires that all applications be relinked so + cannot be done until V2.11. diff --git a/doc/ports/notes_orig.hp b/doc/ports/notes_orig.hp new file mode 100644 index 00000000..da07675f --- /dev/null +++ b/doc/ports/notes_orig.hp @@ -0,0 +1,657 @@ +1 February 1988, HP/UX port, HP 9000 Series 800 Model 850 +Steve Rooke, NOAO + +[read tape from NOAO/lyra; source tape cut 30 Jan 88. +[at least the last file, probably the whole last block worth of the tape +[was missing, including the root mkpkg file. Have been unable to dial in +[to NOAO to recover. +[Had to do this several times, trying dd then tar; couldn't write with +[tar xp due to existence of an account with same group, user id, so had +[to read as root, then chown/chgrp afterwards, in order to preserve file +[dates. + +local/.login + Set iraf root to /aura/iraf; commented out mail command (didn't + like $user); modified stty to get rid of a bunch of Berkeley stuff. + This works: + stty tabs intr ^C kill ^U susp ^X eof ^Z erase ^H + (2/1 SRo) + +unix/* + Spliced Sun HSI into lyra source system, on the theory that there + will be less editing A#pqthan for a VAX. (2/1 SRo) + +hlib/libc/iraf.h +hlib/mkiraf.csh + Reset iraf root. (2/1 SRo) + +/usr/include/iraf.h + Copied in from libc/iraf.h; there are no symbolic links in HP/UX + V1.2. They will arrive in HP/UX V2.0 in March '88. + **TODO** remember to remove copy in /usr/include and replace + with sym.link when available. (2/1 SRo) + +vms/* + Removed vms directory. (2/1 SRo) + +hlib/mkfloat.csh - +hlib/cl.csh - + Removed these sun-specific files. The 9000 800 series has only + one kind of floating point hardware. (2/1 SRo) + +osb/zzeps.[fe] + Compiled and ran zzeps; machine single & double precision same as + on the Suns (IEEE standard works, apparently). (2/1 SRo) + +hlib/libc/spp.h + Increased LEN_JUMPBUF from 16 to 51, as /usr/include/setjmp.h + allocates 50. (2/1 SRo) + +local/.login +local/ranlib + Removed /usr/ucb, /local/bin, and /usr/local/bin from search path + (not present here), and added $iraf/local. Created a dummy shell + script called RANLIB, to avoid having to edit out the ranlib command + all over the system. In HP/UX, AR performs the ranlib function. (2/1) + +unix/os/zdojmp.c +unix/os/mkpkg + Added Doug's new zdojmp.c from tucana (hardcopy), which uses UNIX + longjmp call, replacing some assembler code formerly used in + as$zsvjmp.s. (2/1 SRo) + +hlib/libc/iraf.h +/usr/include/iraf.h + Commented out BSD43 define; "hpux" automatically defined for all + C files. (2/2 SRo) + +os/zxwhen.c + Included FAULT and TRAP hardware exception codes from + /etc/conf/h/signal.h. (2/2 SRo) + +hlib/libc/kernel.h + Set _NFILE to 60 for HP/UX, MAXPROCS to 25 (as per maxuprc in + /etc/conf/gen/S800). (2/2 SRo) + +hlib/irafuser.csh + Set all HSI compiler flags to "-O", which is optimization level 2, + the highest of 0,1,2. (2/2 SRo) + +[Begin first bootstrap attempt. cd $host; sh -x mkpkg.sh] +unix/mkpkg.sh + Commented out "test" command and symbolic link from as.MACH to + as; no "test" in HP/UX, currently no symbolic links. (2/2 SRo) + +unix/os/mkpkg.sh +unix/as/zsvjmp.c + Temporarily replaced as/zsvjmp.s with as/zsvjmp.c in order to + get past compiler error. Apparently if an error occurs in one + of the source modules listed on a cc command line, none of the + objects is produced (also see next entry). (2/2 SRo) + +os/zxwhen.c + Modified reference to fp->_bufsiz; (HP/UX no longer has _bufsiz as + structure element; rather it is defined in terms of an external + bufendtab[] and existing structure elements): fp->_bufsiz becomes + _bufsiz(fp) as per #define in stdio.h. (2/2 SRo) + +os/alloc.c + Moved the #include <sys/types.h> after the #include <utmp.h>, as + the time_t symbol is defined in the former in HP/UX. (2/2 SRo) + +hlib/libc/iraf.h +hlib/libc/hpux.h + Added an `if hpux, include hpux.h' directive, and created the + latter. Without symlinks, difficult to keep modifying iraf.h. + Iraf.h seems to be the best place to include special redefinitions + of system calls and the like that are in the HSI but not present + in HP/UX (or SysV). This seems safer for later updates than editing + a dozen files all over the HSI. hpux.h now contains: + + #define MAX_IPATHLEN 127 /* max IRAF pathlen */ + #define getwd(a) getcwd(a,(MAX_IPATHLEN+2)) + +unix/boot/spp/rpp/mkpkg.sh + Removed the "kludge for Sun-4" code which used the command "mach", + apparently a SunOS command. (2/2 SRo) + +unix/boot/bootlib/mkpkg.sh +unix/boot/bootlib/rename.c + Added routine to simulate BSD "rename" call; we tried this with + macros, but turned out to be too complicated with error checking. + Mkpkg.sh only compiles rename.c if test "`uname`" = "HP-UX". (2/2 SRo) + +local/.login + Added /usr/local/bin to path. (2/2 SRo) + +unix/os/zfiotx.c + Removed "struct sgttyb ttystat;" statement from ZCLSTX, where + it was declared but not used. (2/2 SRo) + +unix/os/zfgcmd.c +hlib/libc/hpux.h + Added ifdefs hpux around getwd(x), which is now getcwd(x,MAXPATHLEN). + Removed similar redefinitions from hpux.h, which now has nothing + in it, and should be removed later if nothing further is added. + **TODO** Remove hlib/libc/hpux.h and include for it in iraf.h?? + (2/2 SRo) + +hlib/libc/kernel.h + SysV does not use the sgttyb structure, and ioctl flags are different. + added #ifdefs to redefine part of the FIODES structure if hpux. Should + later modify for a more general way to determine whether SysV at + compile time. (2/2 SRo) + +unix/os/zfgcwd.c + SysV uses getcwd(p,maxlen) rather than getwd(p). Ifdef'd. (2/2 SRo) + +unix/os/zfiotx.c + Extensive modifications to support SysV termio, using #ifdefs, so + should still work with BSD. (Would not compile with any references + to the BSD sgttyb structure.) (2/[23] SRo) + +unix/os/zfioks.c + Added ifdefs around ioctl call for no echo while getting password. + (2/3 SRo) + +unix/boot/bootlib/ossettime.c + Ifdefs for hpux; in SysV utimes becomes utime, and the tv_sec + structure element from timeval has become UNSIGNED long. (2/3 SRo) + +unix/boot/mkpkg/host.c + Same for another utime[s] call, unsigned long tv_sec. (2/3 SRo) + +hlib/libc/kernel.h + Added extra structure element initialization for hpux (SysV) + fiodes structure (zglobl.c wouldn't compile). (2/3 SRo) + +boot/spp/rpp/ratlibc/ratdef.h + HP-UX does not tack on trailing underscores to fortran + external identifiers. Removed same from all identifiers + in this include file. (2/3 SRo) + +hlib/libc/knames.h +hlib/libc/xnames.h + Removed trailing underscores from fortran external identifiers. + (2/3 SRo) + +unix/boot/spp/xc.c + Replaced FORTLIB[1-3] values with "-lcl", "-lm", and "" for HP-UX. + Symptom was unresolved external symbols "$$lr_wa_[8-13]", or + hpux "millicode" routines; "cl" stands for "compiler library". + (2/3 SRo) + +unix/boot/spp/rpp/mkpkg.sh + Added explicit "-lcl" after user libraries on CC command line. + The CC compiler in HP-UX does not automatically pass this + flag on to the loader (not set up for arbitrary mixing of C + and F77). (2/3 SRo) + +[Bootstrap finally completes error-free.] + +unix/os/mkpkg.sh +unix/as/zsvjmp.s + Installed Jim Dillon's just-completed zsvjmp assembler routine + (had a stub in there before), and restored os/mkpkg.sh to its + initial state. (2/3 SRo) + +[Ran rmbin on the HSI and performed another bootstrap.] + +unix/hlib/mkpkg.inc + Removed Sun stuff; the hppa has no special compiler flags for + floating point. (2/3 SRo) + +[Began sysgen at 16:55. Proceeding smoothly at 18:00 except for numerous ] +[warnings: WARNING: TEST MAY FAIL DUE TO FLOATING POINT IMPRECISION (781)] + +[Thursday Feb. 4. +[Sysgen completed at 02:03 2/4; this was a 9-hour sysgen. There were 1011 +[of the fp imprecision warnings, and about 2 dozen errors of various kinds. +[The spoolfile summary contained 2569 lines! There was one fatal compiler +[error plus several compiler deaths due to my having forgotten to map the +[intrinsics AND etc. +[The fp imprecision warnings result from "if (variable .eq. CONST)" in +[HP-UX f77, and there is nothing we can do about them except turn off all +[f77 compiler warnings with "-w". + +unix/hlib/iraf.h + Defined and=iand, or=ior, xor=ixor for HP-UX. (2/4 SRo) + +TODO: Remember to search for and delete .BAK files in the HSI. + +unix/boot/spp/xc.c + Modified to compile C source files with CC rather than F77. There + were several places in the sysgen where we attempted to compile C + source with f77 (mkpkg.inc: USE_CCOMPILER is YES), in addition to + the CL C source. HP-UX f77 does not recognize C source. Desinger + feels that it should, and suspects it never came up before. (2/4 SRo) + +sys/imfort/imemsg.x + This file contained a half dozen "% msg = '...'" statements, + where the quoted string exceeded column 72 (assuming the leading + tab got expanded into 8spaces). Abbreviated each offending + character string to fit into 72 columns. Obviously, only these + "%" source statements that bypass the preprocessor could possibly + exceed 72 columns, however we would not have noticed any that would + not have ended in a missing quote, so TODO: filter all spp source + files for ^% lines longer than 72 chars, after expanding tabs. + (2/4 SRo) + +sys/gio/ncarutil/conbdn.f + There was an uncommented DATA statement at line 342, following + assignment statements, and the f77 compiler complained. (2/4 SRo) + +sys/gio/ncarutil/conbd.f + Had to move a "data first" statement up into its proper position + (it followed some assignment statements). This was lower case, so + it looked not to be a typo as in the previous case. + Also had to add dummy variable in data statement as cannot init + variables or arrays via data statement in named common in HP-UX. + (2/4 SRo) + +sys/gio/ncarutil/gridal.f + Compiler warned about compile-time algrbraic expressions that can + be reduced; there are stmts at lines 1554,1566 subtracting 0. from + an expression (harmless, no mods made, just noting). (2/4 SRo) + +sys/gio/ncarutil/srfabd.f + Compiler complained (error) about illegal initialization of "first", + which was in a data statement and also in common. Added a dummy + variable in data stmt, and subsequent assignment to "first". (2/4 SRo) + +sys/gio/nspp/portlib/gridal.f + "ifmt" was declared to be two-dimensional, but it appeared in an + equivalence statement at line 217 with only one subscript. (2/4 SRo) + +sys/gio/nspp/portlib/z8zpbd.f + More arrays & variables in common initialized in data statement + (mfmt[xy]). (2/4 SRo) + +noao/onedspec/dbx/dbmore.x + This routine initializes an array with DATA that is in common. + Hacked for now, leaving to Frank V for later. (2/4 SRo) + +noao/imred/dtoi/hdicfit/hdicgdelete.x + The int procedure icg_deleted() did not return a function value, + causing a proper error message from f77, but generating a fatal + error and infinite loop in the optimizer. Hacked for now to + return (0). TODO: investigate hdicgdelete.x to see what, if + any, return value should be generated. (2/4 SRo) + +unix/boot/mkpkg/host.c + Finally noticed that the system libraries were disappearing instead + of being checked into lib$. There is code in host.c that attempts + to copy the file if it cannot be moved any other way, but it must + never have been tested for moving a file to a directory, because the + creat() call took as its new file name just the host pathname of lib$, + lacking the name of the library. Since u_fcopy() looked like it was + intended to be a general copy routine, I added a strcat in the calling + routine to append the library to the directory. This ought to be + investigated (TODO), in case anything other than a file in the local + directory is the "old" file. + (2/4 SRo) + +[Began new sysgen at 17:21:22 PST 2/4/1988. Still leaving in the compiler ] +[warnings; when all have been checked out, the flag "-w" ought to be added ] +[to mkpkg.inc; there is no way to ignore just the floating-compare warnings.] + +math/interp/arider.x + Compiler objected that real function did not return value. Kludged + the three returns to "return (0.0)". (2/4 SRo) + +unix/boot/spp/xc.c + XC was correctly compiling C source with "cc" rather than "f77" now, + but immediately afterwards was also trying to compile them with f77. + Fixed the subsequent filter that I hadn't noticed earlier. This will + necessitate a followup sysgen (mostly a relink), as XC thought it + shouldn't try to link after getting run errors from UNIX. (2/4 SRo) + +[This doesn't look so good... dates of object modules do not appear to +[be in the object libraries, and mkpkg is recompiling all files regardless. +[Getting too late to fix tonight. Also, using cc to link (passed from XC) +[results in a fatal /bin/ld error... + +unix/os/zawset.c + Finally (manually) got past enough loader problems to find the + unresolved symbols... [gs]etrlimit() not implemented in SysV. + As this is not critical code for basic port purposes, merely + stubbed out for now. TODO: find some way to implement this in + SysV/HP-UX. Investigate plock() for HP-UX only (real-time programming + manual) (2/5 SRo) + +unix/os/zwmsec.c + In SysV, sigvec() is sigvector(), with no other changes. Used ifdefs. + (2/5 SRo) + +unix/boot/spp/xc.c + Set FORTLIB3 to "-lbsdipc", the HP-UX library containing the likes + of rexec(); networking probably won't work anyway, but it might be + worth a try. (2/5 SRo) + +unix/os/zfprot.c + Added #ifdef hpux to redefine rindex(). (2/5 SRo) + +[HIATUS -- Accidentally trashed this entire notes file last night with +[a typo (redirecting some error output to the end of this notes file +[with ">&" rather than ">>"). File recovered from Friday (2/5) noon backup +[by Bob Desinger. There were about 11 hours of time during which a moderate +[number of notes file entries were made that were lost. The following are +[from memory but will have to be verified by diff'ing back in Tucson. + +unix/os/zawset.c + Could not immediately find a way to alter the working set size on this + system, so simply ifdef'd out the entire body of the routine to get + past unresolved symbol (getrlimit) at load time. + TODO: adjust workingset size in SysV? (2/5 Sro) + +unix/os/zopdpr.c + No way to alter the timesharing (as opposed to HP-UX extended realtime) + priority of another process. Ifdef'd around the [gs]etpriority calls. + (2/5 SRo) + +unix/boot/mkpkg/scanlib.c + In HP-UX, the object libraries have a different structure than under + BSD. The symbol table is the first "module", immediately after the + 8-byte magic header, then is followed by N modules. When the space + allocated to the first symbol table entry is full, apparently, a symbol + table extension is tacked on. Since module names are terminated with a + "/", and none of the symbol table entries has a module name, module + names beginning with "/" are always symbol table entries, so we check + each module to see if it is the latter, and skip file_size bytes if so. + Also, in exercising the code: + while (fread (&arf, 1, sizeof(arf), fp) > 0) { + it was apparent that the structure was not being passed correctly. + Though the size and number of instances seemed to be reversed, that + should have been harmless, but the structure itself was not being + passed correctly to fread. Solved with the following: + while (fread (arf, sizeof(arf), 1, fp) > 0) { + (2/5 SRo) + +unix/os/zlocpr.c + The CL was dying at startup time, after trying to set an entry + point address in fseti(). Determined that the f77 EXTERN declaration + generates an address pointing to the address of the external function. + Modified zlocpr.c to use onenOxD extra level of indirection. For some + reason, the typedef PFI declaration does not work; left the declaration + of proc as "int *proc" (something to do with how the compiler handles + "()" as part of a declaration??). (2/5 SRo) + +unix/hlib/mkpkg.inc + Added "-w" flag to turn off all compiler warnings. All such warnings + have already been investigated and accounted for, and the 1011 floating + compare warnings clutter up the spoolfiles unnecessarily. (2/5 SRo) + +unix/boot/mkpkg/host.c + Cleaned up a bug I had introduced earlier in moving file to directory. + (2/6 SRo) + +sys/gio/nspp/sysint/ishift.x +sys/gio/ncarutil/sysint/ishift.x + Both these files had their own "iand" and "ior" functions, generating a + compiler error, as "and" -> "iane:rtd" already, in hlib$iraf.h; as it + is the last day, I don't have time to recompile the whole system + by placing some redefinition in iraf.h; the procedure calls are + the same as those supplied by HP-UX, so just commented out the + ncar equivalents. (2/6 Sro) + +noao/astutil/asttools/pdmstatistics.x +noao/twodspec/apextract/t_apnormalize.x + Ha! Just like the Masscomp, TAR will not write files that have + a "." in the 14th position, and reports no error message. These + files are missing from the system. (2/6 SRo) + +noao/imred/dtoi/hdicfit/hdicebars.f +unix/hlib/mkpkg.sf + This file generates a fatal internal error in the 2nd pass of the + optimizer, after staying in a loop for a very long time. Left + f77 source with HP. Added to special file list. (2/6 SRo) + +noao/twodspec/multispec/fitclean.f +noao/twodspec/multispec/fitsmooth.f +unix/hlib/mkpkg.sf + These files generate fatal address compiler errors in 2nd pass + of optimizer. Left with HP. Added to special file list. (2/6 SRo) + +noao/imred/dtoi/hdicgundelete.x +noao/imred/ccdred/t_badpiximage.x +noao/imred/ccdred/t_mkfringecor.x +noao/imred/ccdred/t_mkillumflat.x + Files missing; "." in 14th column. (2/6 SRo) + +[Several minor errors in new relink-sysgen; didn't compile newly-added +[files in mkpkg.sf w/o pass2 optimization, irafks tried to call rename. +[Still getting: + + dictionary starts at 1073968624 (010000672760) + pfileload, task cl + task `cl' has no param file + Fatal startup error. CL dies. + +[irafks.e failed to link because our kludged "rename" routine is in +[bootlib, not libos, of course. TODO: investigate better way to handle +[rename(); getting late, so won't try anything now. + +[Continuation of notes file begin 2/1/88 for HP-UX port] + +unix/os/mkpkg.sh + Separate compilation of zsvjmp.s; pass 2 of the optimizer causes the + routine to fail! (2/11 SRo) + +sys/fio/open.x +sys/fio/filopn.x + After grubbing around for a while trying to figure out what was + wrong with file descriptors and/or os channels, tried compiling + these routines without optimization. For the first time, this + permitted getting all the way to the "cl>" prompt, but with all + the CL debugging turned on. I used ADB to turn off debugging + (cldebug/W 0), but it kept getting turned on automatically. + I was able to have the system task do a successful long directory + listing of hlib$motd, but was unable to type it out. Everything + looked so badly garbled, that: + +unix/hlib/mkpkg.inc + Set optimization flag to "O1" rather than "O2". If all works well + tomorrow morning, I'll at least know I'm looking at optimizer, not + system, bugs. (2/11 SRo) + +[Ran RMBIN from the root; started new sysgen.] + +[5-hour sysgen, only minor incidents, mostly due to missing >14char filenames] +[Same startup symptoms firing up CL: + + dictionary starts at 1073968624 (010000672760) + pfileload, task cl + task `cl' has no param file + Fatal startup error. CL dies. + +[Recompiling fio$filopn.x with NO optimization (rest of system is now at +[opt level 1 rather than 2 originally) gets past that problem but again +[cldebugging is turned on automatically so at 1200 baud you have to wait +[about 5 minutes for the prompt. A lot of things are still screwed up -- +[can't access hlib$motd (can from system process run standalone); the +[command "show iraf" generates an error with no return to the prompt; +[^C then causes error recursion and the CL dies. + +unix/hlib/config.h + Finally realized there was another LEN_JUMPBUF after seeing the + global variable cldebug get trashed by setjmp after 16 words, same + as the old LEN_JUMPBUF in the Sun HSI. Increased to 51, started + another sysgen. (2/12 SRO) + +[CL comes up fine now, and all the builtins I tested work fine. "directory" +[results in an eventual core dump, with possible error recursion. Running +[the system process standalone just generates a segmentation violation. +[As I am working from home, without access to printouts or another terminal, +[I decided to take advantage of another 48 hours before getting back to the +[office by stripping all binaries and recompiling everything with NO +[optimization (last sysgen was with -O1). Since filopn.x generates a fatal +[error even compiled with -O1, I consider it reasonable to gen the whole +[system without opt, then fix all the non-opt bugs, then start increasing +[the level of optimization to see just how bad it is. (2/14 SRo) + +Best so far. CL comes up fine, can do direN |ctory listings etc. without +system process dying. IMDEBUG/MKIMAGE still coredumps with no warning to6\D5| +the CL, and when "bye" is given, the CL warns about an error in the subprocess +then hangs. 2 ^C's generate error recursion with CL death. Apparently there +are some routines causing fatal problems even with optimization level 1, but +at least there are some other bugs to isolate first before tackling opt. +(2/15 SRo) + +unix/hlib/iraf.h +unix/hlib/libc/xnames.h + Defined getpid as xgetpd; with no trailing underscores in HP-UX, + SPP getpid collides with UNIX getpid. (Symptom was infinite + recursion in getpid->zgtpid->getpid...) (2/16 SRo) + +unix/hlib/motd + Updated banner page for HP-UX. (2/16 SRo) + +unix/as/zsvjmp.s + Set value of "status" to zero, as this had been neglected originally. + Symptom was infinite error recursion in the CL for commands such as + "lpar junk" (not infinite stack accumulation, due to the nature of + setjmp/longjmp). (2/18 SRo) + +[Another relink sysgen, as everything links with zsvjmp.s] + +[MKHELPDB got stuck; name collision between spp rename and faked UNIX +[routine. + +unix/hlib/iraf.h +unix/hlib/libc/xnames.h +unix/os/zfrnam.c +unix/boot/bootlib/rename.c - + Defined RENAME as xfrnam to avoid name collision, removed earlier + rename.c, which didn't belong in bootlib in the first place, and + added u_rename() function to zfrnam.c. (2/19 SRo) + +pkg/cl/main.c + Modified memneed() to add memory on 64-bit boundaries. Otherwise, + there is a bus error whenever a double floating point word that + is not 64-bit aligned (in actual memory, not just relative to + some data structure) is loaded into a floating point register. + Must also have next fix as well. (2/25 SRo) + +pkg/cl/pfiles.c + In one place, after a call to memneed(), there was verification + code to assure synchronization; this failed when memneed() was + modified to be 64-bit aligned. Current fix is a shameless hack. + (2/25 SRo) + +[Success!! I can load packages, stat images, get graphics in a gterm +[window over the phone lines from "urand | graph", etc. There will +[doubtless be further bugs when more exhaustive testing is undertaken, +[but things look far better than at any time up til now. + +dev/pix.imh +dev/pix.pix + Due to tape problems when I originally prepared the source tape, + the standard dev$pix 512*512 short image was not on tape. I brought + a separate tape with the binary image in FITS format, but forgot + to read it in before I had to dash off to the airport, so I built + the image from a Mandelbrot set test program I copied over the + phone line into local/sr/mandel.x. (2/29 SRo) + +unix/hlib/alloc.e + Had Jim Dillon change ownership to root. (2/29 SRo) + +unix/hlib/iraf.h + Name collision with getuid(); defined as xgetud. Symptom was + segmentation violations in wfits and in the CL when attempting + to allocate the drive. (2/29 SRo) + +dev/devices + Cleaned up and added all relevant aliases. SysV uses /dev/rmt/* + and /dev/mt/* for raw and block special device names respectively; + only the sysmgr is supposed to be able to use /dev/mt/* devices, + so these need not be added as aliases. However, the standard + AT&T device installation leaves the tape head positioned after + the 2nd EOF mark during write/close; if special minor device + names are added, the interface is "berkeley style". Convention + adopted here was a trailing "b" for those device names, for lack + of anything better. The device bits are as follows for Berkeley: + + crw-rw-rw- (...) 0x140000 Mar 1 17:39 /dev/rmt/0hb + crw-rw-rw- (...) 0x1c0000 Mar 1 17:39 /dev/rmt/0hnb + crw-rw-rw- (...) 0x120000 Mar 1 17:38 /dev/rmt/0mb + crw-rw-rw- (...) 0x1a0000 Mar 1 17:39 /dev/rmt/0mnb + + IRAF entry for drive 0 on the "hpufoca" machine is as follows: + + mta rmt/0hnb rmt/0hb rmt/0mnb rmt/0mb \ + rmt/0hn rmt/0h rmt/0mn rmt/0m + mta.6250 rmt/0hnb rmt/0hb rmt/0mnb rmt/0mb \ + rmt/0hn rmt/0h rmt/0mn rmt/0m + mta.1600 rmt/0mnb rmt/0mb rmt/0hnb rmt/0hb \ + rmt/0mn rmt/0hn rmt/0h + + The numeral is the drive number, h=high, m=medium, and l=low + density, "n" is for no-rewind. This does appear more rational + than BSD UNIX. (3/1 SRo) + +noao/astutil/pdm/pdmstats.x +noao/astutil/pdm/mkpkg + Transferred this file over the phone, formerly called + pdmstatistics.x, >14 chars; lost during 1st sysgen. (3/1 SRo) + +noao/twodspec/apextract/t_apnorm.x +noao/twodspec/apextract/mkpkg + Transferred from noao; >14 chars. (3/1 SRo) + +noao/ccdred/src/t_badpixim.x +noao/ccdred/src/mkpkg + Same. (3/1 SRo) + +[Ran RMBIN and began a new sysgen to ensure recent changes to iraf.h +[get picked up everywhere (just relinked a couple of executables by hand +[after getuid() change). (3/1 SRo) +[Tue Mar 1 19:47:39 PST 1988 --> Wed Mar 2 00:48:55 PST 1988 +[5-hour sysgen (full recompile & relink); roughly same as on Model 850. + +noao/imred/dtoi/hdicfit/hdicgundel.x +noao/imred/dtoi/mkpkg + Re-transmitted this file (formerly named hdicgundelete.x), which + got deleted during one of the last sysgens, as it still had >14 + chars, and the .o file replaced the .x file during compilation. + Although renamed back on lyra, it still was not returning function + values, so just added 2 "return(0)"'s. (3/2 SRo) + +noao/imred/ccdred/src/t_mkfringe.x +noao/imred/ccdred/src/t_mkillumft.x +noao/imred/ccdred/src/mkpkg + Transferred these files with shortened names from Tucson; >14 char + files were trashed earlier. (3/2 SRo) + +[Ran IRAF test procedures, including tape drive ones, and using the +[dev$pix created from the Mandelbrot Set, as original one didn't make +[it. No problems encountered. (3/2 SRo) + +[Ran benchmarks over dialin, excluding image display, networking, and +[multiple-terminal graphics ones. No software problems encountered. (3/2 SRo) + +unix/os/zfrnam.c + Had neglected to unlink oldfile when implementing BSD rename() + with link/unlink. (3/2 SRo) + +local/terminfo +local/terminfo/s/sun +local/terminfo/s/sun24 +local/terminfo/s/sun34 +local/terminfo/s/sun40 + Created this directory to hold private terminfo descriptions. + A new description may be compiled by first using untic(1M) to + decompile one of the existing entries in /usr/lib/terminfo/?/file, + editing the result, setting the environment variable TERMINFO + to a pathname, and running tic(1M) to compile the entry. Tic + actually creates the single-letter subdirectory, and names the + resulting file from EACH alias in the untic'd file. To use a + non-standard terminfo description, here sun40: + + % setenv TERMINFO $iraf/local/terminfo + % setenv TERM sun40 + + (3/8 SRo) + +[ Tar tape cut for CFHT; no further work expected to be done on hpufoca +[ system at Foster City. HP-UX/IRAF maintenance & update will now be done +[ on Model 825 at CFHT. (3/8 SRo) diff --git a/doc/ports/notes_v22.st b/doc/ports/notes_v22.st new file mode 100755 index 00000000..230ab876 --- /dev/null +++ b/doc/ports/notes_v22.st @@ -0,0 +1,1185 @@ +Space Telescope Science Institute iraf$local/notes.st + +[ Many of the below notes and bugs have long been fixed, however the CL ] +[ changes have yet to be fully integrated into both ST and NOAO versions, ] +[ so we'll keep them around for a little longer. Some notes have been ] +[ added below (in [[ ]]) where necessary/appropriate. JJT 8-Mar-1986 ] + +-------------------------------- +Monday 23-DEC-1985 17:32:26.42 + +Subject: CL Changes Nov-Dec 1985 + (T.McGlynn, J.Travisano) + +grammar.y + - delete opnl's in procedure declarations to eliminate s/r conflicts. + - create LP and RP for parentheses to eliminate some expressions. + - repositioned initialization processing. + - modified var_decls slightly. + - if/else fixes, so don't need { if ... }. + - better syntax error reporting in scripts: gives (correct) line number, + points to offending position, and continues parsing script for errors. + +history.c gram.c + - changes to support above grammar changes + +history.c exec.c pfiles.c decl.c + - changes to deal with script line numbers correctly, i.e. + task->t_scriptln, which is used in syntax error messages; also, + a fix in the skip_to() function in decl.c. + +history.c + - problem of getting a "begin" in the history when running (or parsing) + a procedure script was fixed. The original command is now recorded + in the history (and logfile) correctly. Unfortunately, there is + one case where this does not work -- when get an error parsing the + parameter declarations in a procedure script. + +eparam.c + - format changes for real arrays (so exponent shows up) + - tried to fix MOVE_END problem when going across page boundaries; + can't seem to find the bug, so for now just print out a message that + says to use NEXT_PAGE a few times instead of MOVE_END. + +pfiles.c param.c gram.c + - added support for '\r' and '\f', so can be used in prompt strings + for better formatting control (\f not fully supported in EPAR yet) + +modes.c decl.c pfiles.c + - whitespace-only filename parameters are turned into null strings; + so users can check null filenames easily in a script (fn != "") + without having to deal with whitespace. Filenames with whitespace + only are not really legal anyway (?). + +modes.c + - bug fix to prevent trashing of enumerated parameters in certain + instances. + +param.h + - minor typo 'ai' --> 'ar' + +-------------------------------- +Friday 27-DEC-1985 14:47:48.01 + +Subject: CL history editor [[ known feature ]] + +The following is another lexmodes=yes problem: + + pl> contour img1[*:16,*:16] + ... + pl> surface ^^ + surface img1[*:16 + Warning: ... + +The get-arguments code in pkg/cl/history.c checks for comma-delimited strings. +Putting the whole argument in quotes, i.e. "img1[*:16,*:16]", and then using +^^ works fine. (No fix/change was made.) + +-------------------------------- +Friday 3-JAN-1986 14:59:06.87 + +Subject: Local vars in CL procedure scripts + +It is generally assumed that local variables in CL procedure scripts, i.e. +those after the "begin" statement, will be initialized by the user with +simple assignment statements. There is one (possibly more) case where this +assumption can cause problems. For example, + + ... + begin + string buf + + if (fscan (plist, buf) != EOF) ... + ... + +Here, "buf" is used before being initialized, and the result is an error +saying "Attempt to use uninitialized local variable 'buf'". Perhaps local, +uninitialized variables should be initialized automatically by the CL, but +have done nothing to fix/change this yet; just making a note of it. + +-------------------------------- +Tuesday 7-JAN-1986 15:37:59.59 + +Subject: Miscellaneous + +These are various notes and suggestions by IRAF users at STScI and elsewhere. +I decided to finally add them all here since they were beginning to pile up +on various scraps of paper on my desk. Some of them are minor bugs, but most +are suggestions of some kind. Nothing has been done with any of them in terms +of IRAF changes. Most of the text is from mail messages or typed in verbatim +from paper copies. Any notes by me (JayT) are indicated in brackets []. + + +From ST users: + +CL + Would it be possible to put a feature into iraf whereby you say +'task=xxx', which would then set a default so that you could just +type lpar, or an input, without having to specify which task? +Ie, instead of having to type 'xxx.infile=etc', you could specify +the task and then just type 'infile=etc', with iraf filling in +the task name. This would not interfere with those who like the +system as it is, but could streamline things for those of us who +like the way AIPS does things. + +Integer parameters + We have encountered another peculiar feature of IRAF. Suppose you have a +parameter that is declared as integer in a .par file, and the user attempts +to put in a value for that integer that exceeds the range of INT*4. The cl +fills in that parameter with the value 'indef', a character string. When +SDAS goes to read the parameter, we get a crash because the parameter is not +in integer form. Now, it seems that a parameter declared as an integer ought +to be an integer no matter what, not a character string. Wouldn't it be better +to leave the parameter value unchanged from its current or default value rather +than put in this string? + + +From RAL users: + +CL Parser + li> ?? | words | match ':' stop+| sort | table + + does NOT work correctly, but separating the "+|" to "+ |" works okay. + +Help on parameter prompt + It is very complicated to provide additional help at the prompt for + parameter stage especially for non-string parameters. This facility + is almost essential to provide a user-friendly interface. + For example: + A string specified in the parameter file is output if ? is + typed in response to a prompt or possibly even enter the help + system. + + [NOTE: One can make the prompt quite verbose, up to something + like 2K characters; e.g., many SDAS prompts are long and multiline.] + +Range check and default display in sexagesimal + There needs to be an option in the parameter file to cause the range + check and default information to be output in sexagesimal. For example, + it is ugly to type in 12:34:56.7 and have it reappear as 12.582417. + +Date type + I think there ought to be special facilities for handling dates. At + present you can't enter a date all in one line (except using a + grotty fudge involving sexagesimal, which precludes proper range + checking), and if you enter the Y,M,D separately you can get things + like 1985 2 30 past the range checks. + + +From U. of Cal/San Diego (Doug Tudhope): + +lists.gcursor [and imcursor] [[ fixed in feb release ]] + Get syntax error line 2. [known "feature" since CL2 grammar] + + [NOTE: doing an "lpar gcursor" activates the graphics cursor, + but then get an error of "EOF encountered in list parameter..."] + +plot.graph task + If only 2 points are given, only the axes are drawn, e.g. + + pl> graph STDIN + 10 10 + 20 20 + <EOF> + axes, but no line! + pl> + +images.imtranspose + Made a transposed output file of a real 190*800 image -> 800*190 + but neither onedspec.splot nor images.implot would work on it. + they stopped with "reserved operand fault". + When imcopy run on transposed image, got "pixel storage file truncated". + +-------------------------------- +Tuesday 7-JAN-1986 15:51:02.98 + +Subject: pkg/softools/boot/spp/xc.c [VMS] [[ now in vms/boot/spp/ ]] + +Added EXTEND_SOURCE option for calling Fortran compiler from XC. This lets +source statements go up to column 132 (instead of 72). One line added to +source: + +fcompile() { + ... + sp = strcpy (outbuf, F77); ++ sp = strcpy (sp, "/EXTEND"); /* Allow statement in cols 1-132 */ + if (portable) + ... +} + +-------------------------------- +Tuesday 7-JAN-1986 16:11:20.85 + +Subject: pkg/images/tv/display/deanza/* [[ updated in march ]] + +Deanza now works with tv/display under VMS! All of the source files and Deanza +libraries are here. See the README file for more detailed information. + +Also changed "pkg/image/tv/display/mkpkg.com" to make the Deanza code instead +of the IIS-dependent code. + +-------------------------------- +Wednesday 8-JAN-1986 12:21:09.73 + +Subject: pkg/imred/.../*.e [[ fixed with new iraf$bin/ dir ]] + +The ONEDSPEC executables are copied all over the place into IMRED. Comments in +the mkpkg.com files say this is to use different par files for different +directories. There's GOT to be a better way, as this eats up a lot of +diskspace (and tape as well at distribution time), which we always seem to be +running up against here. + +-------------------------------- +Friday 10-JAN-1986 15:29:37.13 + +Subject: More SDAS concerns/suggestions + +Environment variables [[ discussed, to be resolved ]] + When a script task ends or a user bye's from a package, all "set" + declarations made in the task or since the package started are + "popped" during task restoration. Comments in pkg/cl/exec.c indicate + that this is for keeping the environment the same across processes. + + However, this can lead to confusion. If a user does a "set stdgraph=" + and later bye's out of a package, stdgraph reverts back to the + previous value, just as any other environment variable. The same + thing occurs in script tasks during the restore, making it difficult + to have global environment variables. Putting a "keep" in scripts at + various places can get around this to some degree, but it's sometimes + awkward. + +Process cache + SDAS has been set up under IRAF such that the user can choose which + version of SDAS he wants (baseline|standard|develop). This choice + can be made when starting the sdas package or any of its packages. + There is a problem, however, when running a package from 'standard' + and then running the 'develop' version when the executable is already + out there. When a task is invoked, it will simply use the subprocess + already in the cache, even though it's a different executable (with + the same IRAF logical name). + + The suggestion that came up was to do an implicit "flprcache" whenever + there is a "bye" to a package, i.e. when all the tasks associated with + the executable are gone. I've looked at this a little bit and don't + see an easy way of determining when we're bye'ing from a package which + has tasks that are in an executable. I imagine there's a decent amount + of overhead associated with checking all the tasks associated with + an executable as well. In general, getting rid of old executables + does make sense if they're not longer referenced, since it frees up + system and user resources (especially important on VMS given the + large process and executable sizes). + +Table parameters + SDAS and CDBS now have a new type of input file, a table, which may or + may not have a header as well. They have asked if it would be easy + to add a new parameter (or two) to IRAF, i.e. a table parameter and + possibly a table-with-header parameter. + + I don't think this is a good idea, as it is something which only + benefits SDAS and CDBS, and does very little if anything for IRAF. + I have encouraged the SDAS people to find an SDAS-only solution to + this problem using existing IRAF facilities. One simple way is to + have tasks which use tables to have a 'type' parameter which tells + if the input file is a table or something else. + +-------------------------------- +Tuesday 14-JAN-1986 08:48:36.11 + +Subject: doc/clintro* [[ missing again, noao has most recent version ]] + +Copied the TeX source for the CL User's Intro doc from Peter's directory +to the general IRAF DOC directory. + +-------------------------------- +Tuesday 14-JAN-1986 10:49:06.01 + +Subject: Size of IRAF... [[ resolved w/ Feb release ]] + +A concern has risen, once again, on the size of IRAF. Garrett Jernigan +(Berkeley Space Sciences Lab) has mentioned problems finding diskspace to +handle all of IRAF. The suggestion he made to Peter was "to split the source, +obj and executables into separate libraries for the distribution, or at least +put them into different sub-directories. If either a tape could be generated +that only had executables, or that had the whole works, but allowed only the +required files for execution to be loaded it would be a real boon." I guess +this means having something analagous to the bin/, src/ scheme in Unix. + +I think a better solution to this is to add something to the installation docs +to describe how to load only parts of IRAF, i.e. everything, or no source, +etc., so the IRAF installer can load only the parts needed/desired. Both Tar +and Backup can handle selective copying in some manner. + +-------------------------------- +Tuesday 14-JAN-1986 11:37:46.40 + +Subject: CL strings + +It is currently impossible to get the length of a string in the CL. This +should be quite trivial to implement, but it is not. The documentation on +"paramaters" states that p_length contains the maximum length of the string, +though in reality, saying =param.p_length simply prints the string, just as +=param does. + +There should be some way of getting the current length of a string, since it +could be used as the 'last' parameter in stridx, for getting the rest of a +string starting at column n. ST users have continually asked me about ways to +get the current length of a string parameter (e.g., from within a CL script). + +One solution is to change the meaning of some of the parameter attributes for +string parameters to something which makes more sense: + + p_length -- contains the current string length, updated whenever + the parameter is changed. + p_max -- contains the maximum string length + +These would require changes primarily in param.c and gram.c. + +Also, currently trying an =param.p_min or p_max on a string parameter results +in an access violation. + + +===> Released new Public version of IRAF at STScI, Mon Jan 13, 1986 <=== + +===> Sent Notes, CL changes, SDAS-related items to KPNO, Thu Jan 16, 1986 <=== + + +-------------------------------- +Thursday 16-JAN-1986 13:58:15.69 + +Subject: pkg/cl/config.h + +Changed DICTSIZE from 20000 to 25000 and STACKSIZ from 4000 to 8000, to deal +with large scripts and tasks with zillions of parameters now used at STScI +which have been causing some overflows. The VMS CL's executable size is no +larger, since uninitialized arrays are allocated at run-time. + +Also changed NFGPROC from 4 to 3. Originally changed in an effort to improve +performance, it's causing more problems with page-file quotas because of the +very large SDAS executables, so back it goes. + +-------------------------------- +Friday 17-JAN-1986 09:25:22.96 + +Subject: Loading packages from within procedure scripts [[ resolved below ]] + +It is a known "feature" in the CL that packages cannot be loaded from within a +procedure script or from within braces. An old-style script, like the current +IRAF package scripts, can contain statements which load packages (e.g. onedspec +loads the list and plot packages). + +Loading packages from within procedure scripts should be supported at some +point (if possible). SDAS uses procedure scripts almost exclusively now, even +their package scripts are procedures. + +Checking into it a little bit, it appears that putting a `keep' statement in +the package script fixes this problem. But this is not a good solution for +general interactive use. A possible solution is to add an implicit `keep' when +a cl() call is made from a script called by a script (as in most package +scripts). This may be the easiest solution and will require no changes to +existing package scripts. + +-------------------------------- +Monday 20-JAN-1986 11:17:09.92 + +Subject: pkg/language/doc [[ used Feb release instead ]] + +A few minor changes to the help text; typos, corrections, added examples, etc. + +-------------------------------- +Monday 20-JAN-1986 16:42:18.87 + +Subject: pkg/cl/Makelib [[ use mkpkg instead ]] + +Corrected Makelib file to contain correct include files for CL source. + +-------------------------------- +Tuesday 21-JAN-1986 12:25:29.74 + +Subject: pkg/system/gripes.cl [[ now in vms/hlib/ ]] + +Changed to mail entire gripe text to IRAF development account, as in KPNO +version, and not just a message that a gripe has been made. Also changed +to use `userid' for the From field instead of `home'. + +-------------------------------- +Tuesday 21-JAN-1986 15:37:48.27 + +Subject: pkg/cl/grammar.y + +Added initialization code for the label list structure used for goto statements +in CL scripts. Simply added "label1 = NULL;" statements to the three places in +the grammar where things are initialized. The absence of this would eventually +cause access violations and other fatal side effects when goto's were used +again and again. + +-------------------------------- +Wednesday 22-JAN-1986 09:12:46.73 + +Subject: pkg/cl/builtin.c [[ fixed at noao too ]] + +Two instances of + flags != LT_PFILE; +changed to + flags &= ~LT_PFILE; + +-------------------------------- +Friday 24-JAN-1986 08:11:29.20 + +Subject: pkg/cl/pfiles.c + +Added line to reset parse state in certain circumstances within a script. + +-------------------------------- +Tuesday 28-JAN-1986 09:16:18.48 + +Subject: sys/fmtio/lexnum.x [[ fixed at noao too ]] + +A previous fix to lexdata.xi caused a bug in lexnum.x to show up, although the +relation between the two is unknown. The stk_ip[] array in lexnum() was +declared as short; this would sometimes overflow since it was storing pointers +which could be quite large. This showed up when a user tried to add a field in +an image header with 'hedit', resulting in an arithmetic trap. The fix is to +declare stk_ip[] as int instead of short. + +-------------------------------- +Tuesday 28-JAN-1986 11:06:27.14 + +Subject: GIO and graphcap [[ fixed in Feb release ]] + +Setting stdgraph to tek4014 results in an "openws: illegal graphics window" +error message when running the graph task. Using showcap to see what is +really in the graphcap entry shows that although it points back to tek4012, +all of the upper case values (X1,X2,Y1,Y2,etc) do not get set properly. + +-------------------------------- +Tuesday 28-JAN-1986 11:44:54.72 + +Subject: pkg/cl/exec.c [[ #ifdef st stuff removed 3/11 ]] + +Quick patch to allow packages to be loaded from within any type of script. This +fix has been #ifdef ST'd for now (ST is #define'd in config.h). Basically, when +a "cl" or "clbye" statement is encountered within a script, the package is kept +for the duration of the script task that called it. + +-------------------------------- +Tuesday 28-JAN-1986 16:29:25.83 + +Subject: pkg/twodspec/longslit/apdefine.x [[ fixed at noao too ]] + +Was getting a lot of "adjustable array dimension errors" when running apdefine. +The following changes fixed them: + + real apdata[3, naps] --> real apdata[3, NAPS] + real imdata[npts] --> real imdata[ARB] + +In the original code, if 'naps' or 'npts' were invalid (e.g., zero or negative) +when the arrays were declared, this error occurred. + +-------------------------------- +Monday 3-FEB-1986 10:25:45.69 + +Subject: iraf$vms/loc.c [[ ST tool, moved to local/ ]] + +Threw together a quick and dirty Lines-of-Code counter to handle C, SPP, +Fortran, MACRO and Ratfor source files for IRAF. It only counts non-blank and +non-comment lines, considering them "executable". (NASA folks like this +software metric to see how much we're supporting.) + +-------------------------------- +Monday 3-FEB-1986 13:00:23.77 + +Subject: pkg/twodspec/longslit/apextract.x [[ fixed in Feb release ]] + +Changed + int fopen(), ... +to + int open(), ... + +Would result in a "bad file descriptor" error message in IRAF/VMS since open() +function was assumed to be real instead of int. + +-------------------------------- +Tuesday 4-FEB-1986 13:40:44.07 + +Subject: sys/os/zopcpr.c [VMS Kernel] + +Added the following initialization code before the call to ZOPNPR to prevent +error recovery problems which occurred occasionally. + + *inchan = *outchan = XERR; + +-------------------------------- +Tuesday 4-FEB-1986 15:43:51.21 + +Subject: sys/tty/ttyputl.x [[ see below... ]] + +The parameter 'map_cc' in this routine is declared as 'int', but everything +that calls it (e.g. lprint, type, page, help), passes in a 'bool'. This is +probably a bug and most certainly a possible portability problem. I did not +change anything, but 'map_cc' should probably be treated as a 'bool' in this +routine. + +-------------------------------- +Wednesday 5-FEB-1986 13:47:01.28 + +Subject: pkg/cl/exec.c + +In mk_startupmsg(), added redirection support for STDERR, so the iraf main will +know about it as well as STDIN and STDOUT (for STDERR, the string sent down is +" 5> $"). A low-level SPP routine used by SDAS for error logging depends on +knowing the redirection status of STDERR. + +-------------------------------- +Wednesday 5-FEB-1986 16:30:12.55 + +Subject: sys/os/zfiopr.c [VMS] [[ in Feb release ]] + +Made changes in the memory allocation strategy. Instead of using _zmaloc and +then mapping to it, let the $crmpsc and $mgblsc system services create and map +the global memory sections. This is a simpler and more standard way of doing +things, according to the examples in the VMS documentation. The system service +$deltva is used to delete the sections. + +These changes were prompted by spurious errors when creating connected +subprocesses, with the following VMS error from $crmpsc: + + SECTBLFUL, section table (process/global) is full + +There is a system paramater (GBLPAGFIL) that controls this and may be too low. +However, the initial implementation of zfiopr with _zmaloc may have been +causing some troubles as well. Memory sections may not have been fully +unmapped/deleted because of problems with memory (de)allocation in the context +of global pagefile sections. The solution mentioned attacks this concern, +and it is better than changing system parameters in the long run. + +Inter-process communication still works fine with this new implementation of +zfiopr and I haven't been able to recreate the error above, so I'm hoping it's +fixed and behaves better as far as deallocation of global pagefile sections. + +Warning: DEC recommends that programs which allocate memory not mix allocation +techniques (lib$get_vm vs. $cretva/$expreg), so there still may be some strange +problems. The full warning is in the VMS System Services manual and some notes +on it are in sys/os/zvaloc.c. + +-------------------------------- +Wednesday 12-FEB-1986 09:07:16.44 + +Subject: sys/os/zmain.c [VMS] + +For interactive HOST and non-batch DETACHED processes, the error channel is now +set to the output channel explicitly. It used to be opened as a separate +channel to the VMS SYS$ERROR. This makes no difference within IRAF, as FIO +(and the CL) keeps track of them as separate entities. It does, however, give +us more control over the VMS SYS$ERROR stream, for example, to redirect +SYS$ERROR to a file to get SDAS tracebacks, etc. + +Also modified to translate SYS$ERROR for the logical assignments made when a +connected subprocess (rather than assigning in/out/tt/command to "SYS$ERROR"). + +-------------------------------- +Wednesday 12-FEB-1986 09:22:34.24 + +Subject: pkg/cl/eparam.c + +A number of changes have been made: + + - bug fixes for arrays and multiline prompts, and movement in + multiple pages when these things are around. + - bug fixes for old patches - the "real" bugs have been found + and fixed. + - enhancement for hidden parameters; now, Eparam output of hidden + params (when showall set in epinit) is similar to Lparam, i.e., + `(name = value) prompt' and for arrays, `(name) prompt \n values' + - updated and added comments where appropriate (and necessary) + - made all debugging/diagnostic code (within eparam) print at the + bottom of the screen, to prevent screen rolling while in eparam. + cldebug messages elsewhere still cause screen craziness, however. + - a bit of code reorganizing and cleaning up + +Eparam continues to get harder to debug. Some of the changes here will +hopefully make future debugging easier. At some point, much of this code +should probably be redesigned/rewritten (as mentioned before). + +-------------------------------- +Wednesday 12-FEB-1986 13:01:46.18 + +Subject: pkg/language/language.hd [[ use Feb release instead ]] + +Added entry for 'stridx', pointing at "string.hlp" + +-------------------------------- +Thursday 13-FEB-1986 13:08:00.00 + +Subject: pkg/cl/gquery.c + +This is used by EPARAM for checking ranges and enumerated values. Fixed some +bugs in the range message generation. Old messages would stay around in a +static array and show up on different parameters in Eparam; modified to null +out string when no range specified. Also did a little bit of cleanup on the +source file. + +-------------------------------- +Thursday 13-FEB-1986 13:13:01.10 + +Subject: sys/os/zxwhen.c [VMS] + +Changed TRACEBACK code (conditionally compiled to show VMS tracebacks rather +than recovering) to force traceback to a file as well as the terminal. This +also gets rid of the double traceback seen when subprocesses abort. The output +file is called ".ERROR", and will be written in the user's current directory +(if writable). + +-------------------------------- +Thursday 13-FEB-1986 17:12:52.80 + +Subject: pkg/cl/decl.c + +Changes to deal with parameters declared in the procedure statement that are +later defined as hidden. We print out a warning message and override the mode, +from hidden to auto. If the user really wants a parameter hidden, it should +not be in the procedure statement, as this can screw up positional arguments. + +-------------------------------- +Thursday 13-FEB-1986 17:54:59.57 + +Subject: abbreviations in the CL + +This "feature" continually comes up here at ST. A lot of people are writing +scripts here and always having problems with abbreviations. The comments +in the abbrev() function in pkg/cl/modes.c says that only interactive (or +batch) tasks can be abbreviated, meaning tasks called from within scripts +must always be fully spelled out. + +I imagine the original reason for this was to insure "good" script programming +practices at the expense of convenience. However, when writing front ends that +use tasknames as parameters and then call lparam, eparam, etc. (e.g., +system.mkscript), it forces the user to type the taskname in full, which makes +it inconsistent with normal interactive usage. + +-------------------------------- +Friday 14-FEB-1986 08:27:57.42 + +Subject: pkg/clpackage/clpackage.men [[ fixed ]] + +typo: 'utilties' --> 'utilities' for System package + +-------------------------------- +Friday 14-FEB-1986 09:35:58.21 + +Subject: package rearrangement for ST [[ to be further resolved ]] + +Put most of the KPNO-specific and general IRAF packages into a new package +called NOAO. This is to avoid name conflicts and confusion with the ST +software, especially SDAS and CDBS. The files affected are: + + lib/clpackage.cl + + lib/noao.cl + pkg/clpackage/clpackage.hd + pkg/clpackage/clpackage.men + + pkg/clpackage/noao.hd + + pkg/clpackage/noao.men + +CLPACKAGE now consists of: sdas noao language lists softools system. + +-------------------------------- +Friday 21-FEB-1986 14:34:26.46 + +Subject: lib/clpackage.cl login.cl [[ now vms/hlib/ ]] + +Changed startup file and template login.cl so filewait="no" is the default. +Too many "Waiting for access to file" messages, especially on the logfiles, +which are in heavy use around here for lots of things besides what the CL +puts in them. + +-------------------------------- +Tuesday 25-FEB-1986 13:48:30.21 + +Subject: pkg/cl/builtin.c + +clhidetask(): Removed check for tasks without parameter files. This should +not matter when hiding a task. The inability to hide foreign tasks prompted +this change. + +-------------------------------- +Monday 3-MAR-1986 13:25:02.14 + +Subject: pkg/cl/eparam.c + +Minor change in eparam to clear the bottom line before returning to the CL. +This clears the "<key> for Help" message from the command line, to avoid +confusion. + +-------------------------------- +Thursday 6-MAR-1986 09:24:31.20 + +Subject: system package, copy and rename + +Copy does not allow wildcard files as output, but rename does. Thus, copy +seems to be modelled after the Unix cp whereas rename acts like the VMS task of +the same name. This seems inconsistent and is sometimes annoying to users +here. + +Also, if the copy command cannot read the input file for some reason, the +resulting error message says that it can't create the output file (because the +call to zfmkcp fails). This is misleading, and is due to the logic in +fio$fcopy and fmkcopy, which check only for the existence of the input file and +not whether it can be read. + + +---------------------------------------------------------- +Merge Notes -- NOAO Feb release +Starting March 6, 1986 Jay Travisano + +Mostly ST-specific notes, but some notes on VMS/IRAF... +---------------------------------------------------------- + +Read backup tape to [iraf.new...]. Will merge IRAFX changes into that and then + backup whole thing; NOAO has made a lot more changes than we have. + +doc/vmsnotes.* --> doc/ports/* + save old vmsnotes files, may be useful + +vms/hlib/irafuser.com + site-dependent changes; also added MYDISK job logical to deal with + dollar signs in disk names. Will change mkiraf.com to use MYDISK + if can't get rid of dollar sign in home disk. Also, reinstate + IMDIRDISK for the IRAFTMP directory... +*** + We don't have system logical names without '$' in them and even the + physical names have them too (VAX cluster). Having another system + logical name without the '$' is not the answer here, since we have + over 30 cluster disks. Forcing IRAF sites to change system logicals + is an unreasonable method to avoid the '$' (as the installation doc + recommends). It may be easy at NOAO but our experience here and + at other VMS-only sites shows otherwise; system managers around here + are even reluctant sometimes to raise users' paging file quotas, as + it requires more pagefile space on the system disks. + + One solution to this is to have a fully supported (consistent) escape + mechanism. The "disk\\$newton:[irafx]" works in most cases + and is used currently at ST. The MYDISK job logical for the home + directory in the login.cl also helps out. + + A better solution perhaps is to change vfnmap/vfntrans so that + during logical dir translation, a check is added to see if we have + an OS path. If so, don't bother rescanning the string for more + logical directories. This would allow + + set junk = "disk$newton:[iraf.local.jay]" + type junk$file + + and after the first translation of "junk$", it would realize that + we've got an OS path and continue on with the "file" portion. +*** + +vms/hlib/libc/iraf.h + site changes for ST; not crazy about site disk and dir names in this + file which must be moved to sys$library. assuming vms logicals + will be set correctly so won't need to read this file at run-time. + +vms/hlib/gripes.cl + added subject to mail message + use USERID instead of HOME for From field + +vms/hlib/install*.com + changed for ST; only install CL and SYSTEM package here + +vms/hlib/irafemacs.com + newer version of emacs command file, plus a few minor changes for IRAF + +vms/hlib/zzsetenv.def +vms/hlib/login.cl +vms/hlib/mkpkg.inc + setups for ST + +vms/hlib/mkiraf.com + use MYDISK job logical instead of SYS$DISK; avoids '$' garbage. + +vms/os/net/zfioks.c + turned on DECnet instead of TCP; never worked all that well, but we'll + try it again + +vms/os/zmain.c + merged in our changes and updated comments + +vms/os/zopcpr.c + merged in old change missing from noao distribution + +vms/os/zxwhen.c + merged in new traceback handling stuff + *NOTE*: this is currently turned ON for ST, for debugging of access + violations and arithmetic faults. To turn it off, #define NOTRACEBACK. + +vms/os/rms.c + (debug) references to EP2 changed to _EP2 + +vms/boot/spp/xc.c + added /EXTEND qualifier for Fortran; allow statements in cols 1-132 + +dev/devices + magtape entries for ST cluster + +pkg/cl/tests/* + Note in Unix notes file says this was deleted because it wasn't used + anymore. In fact, it has been used here at ST for (crude) regression + testing when making CL changes. Have moved these into my (Jay) + private directory in case they're needed in the future. + +vms/boot/spp/rpp/mkpkg.com + DCL syntax errors in "if f$search()" line: + () screwed up + "then" missing + (I booted the tools from scratch, to test everything out) + +pkg/cl/* + used ST version as a base; merged in NOAO changes where necessary + +pkg/cl/mkpkg + added lines to lex and yacc the grammar, if stsci and vms, since we + muck around with the grammar too. + also, typo in install comment (move to bin$, not lib$) + +vms/hlib/notes.com rcscom.com --> local/ + these are ST-specific tools; notes file (notes.st) will also be here + +doc/ports/ <-- old vms/ctio.hlp vmsprog.hlp (from old distribution) + +backup current ST develop/experimental version (IRAFX) to tape +backup new merged version to IRAFX +remake... +testing... +everything looks good... + +Networking w/ DECnet seems to work fine; tried remote file access, remote +subprocesses (will be useful for IDM access). Tried very simple remote tape +access and didn't work; seemed to abort quickly though as if it failed on +local host. The noao notes file says it won't work on VMS because of the +process structure; not sure what this means exactly -- looks like it should +work with the allocation built into the kernel server as it is now. Will +look into it more later... + +dev/hosts + set up ST nodes +*** + took out the single quotes on the vms executable name (from noao). + can't access "node!iraf$file" with them in, i.e., the "iraf$" + logical doesn't get set up correctly. appears that the quotes are + left over from some previous syntax. don't think noao has vms + servers (for tcp) yet (?). +*** + +vms/hlib/irafuser.com + changed most job logicals to process ones, since they aren't needed + at the job level, and job table space is limited around here. + (Process logicals are automatically copied when spawning DCL commands + or background jobs.) So, now (at least for ST), + job logicals: IRAFDISK (IMDIRDISK) IRAFTMP IRAFIRAF IRAFHOST + IRAFHLIB + process logicals: IRAFLIB IRAFBIN IRAFLIBC IRAFVMS batch-logicals + +vms/hlib/mkiraf.com + bypass sections that delete login.cl and uparm files; + let a new version of the login.cl be made in case user must go + back. for uparm files, the 'out of date' message will be enough + to tell the user to do an unlearn. besides, the sdas par files + don't change that much (or do they?) In any event, I'd get lots of + complaints if everyone's par files disappear when running mkiraf. + +vms/gdev/ + made library as is, to resolve link references w/ irafks, display and + cv. For deanza at ST, probably won't use this interface; easier to + use old deanza code until new display code and image interfaces are + in place. + +pkg/language/doc/edit.hlp + typo: edcapf --> edcap + +pkg/system/doc/directory.hlp + typo: \fb --> \fB + +pkg/* + many packages list a 'revisions' task in the help menu but don't + have one in the package; I imagine this is a future enhancement. + +pkg/images/tv/display/mkpkg + /deanza/* + Added temporary deanza code (vms and stsci dependent). Changed mkpkg + in display/ to make the deanza/ subdir instead. + +dev/graphcap + added entry for `deanza'; no more .imh files...Yeah! + added entries for Selanar-enhanced vt100 (vt100s), and Pericom. + +dev/termcap + added/updated ST entries. + +vms/hlib/clpackage.cl + changed 'page' to 'type'. if a long motd, user may inadvertantly + type ahead and get all screwed up, so just type the message out. + +pkg/cl/grammar.l + modified to accept double precision real numbers on input, e.g. + + cl> task.param=12d20 + + used to give a syntax error. Simple change in lex input, namely: + [eE] --> [eEdD] for real numbers. + +vms/as/README +vms/as/cstr.mar + + Added assembler versions of LIBC string routines; added to list in + README file. These are much faster than the LIBC string routines + written in C, and although they may not make a significant increase + in performance of the CL, we have them, so why not use them. + +sys/libc/mkpkg + Modified to use as$cstr.s if available, otherwise use the portable + routines written in C. + +vms/boot/mkpkg/mkpkg.help + typo: \fmkpkg --> \fBmkpkg + +math/mkpkg + added "$purge lib$" at end of 'mathgen' + +----------------------- +CL Logging Enhancements +Feb/Mar 1986 +----------------------- + +The following enhancements to the CL logging facilities were made: + + 1) a 'putlog' builtin was added, so a user's script or program + can log important messages and errors + 2) added logging from the CL itself, when script and executable + tasks are started/stopped (i.e., a task trace) + 3) errors are logged, from the CL, when from a script or executable + 4) background logging supported (a result of above changes) + +These functions are parameter controlled, by the CL parameter `logmode', e.g., + + cl> logmode = "commands background error trace" + (nocommands nobackground noerror notrace) + +The old `keeplog' parameter has the same function, turning the whole thing +on or off. + +Note: To avoid file access conflicts (e.g. bkg logging), the environment + variable 'filewait' must be set to "no". (This is now the default + at ST.) As a result, some log messages, especially those from the + background, may still not get to the (single) logfile. The use of + multiple logfiles is encouraged because of this, but SDAS developers + and testers prefer a single logfile with everything in it. Not much + we can do to change their minds. + + +Source changes in pkg/cl/: + +builtin.c + Added clputlog() function for the 'putlog' builtin. + Added code so that the clerror() function calls putlog with + the error message, when logging is on. + +history.c + Fixed the code for shared logfile access. Modified so login/logout + messages are not printed for background jobs. + Added putlog() function, which formats the log messages from the + user and/or the CL and writes to logfile. + Added reset_logfile() function to reopen logfile if name is changed. + This is only for share_logfile=no and has not been tested here, + but it's just a close and reopen. + +exec.c + Added code to log a message when starting/stopping a script or + executable task. This is the "trace" feature. + +bkg.c + Added code to log a message when a background job is started or + completes. + +errs.c + Added code to log the error messsage if a script or executable task + (and it hasn't already been logged by clerror()). + +param.h + Added P_CL value for p_flags field of the param structure. This + is used to test (quickly) whether a parameter is a CL parameter. + +param.c + Added check in paramset() for a CL parameter (p_flags & P_CL); + if so, call parse_clmodes() (below). + +modes.c + Added parse_clmodes(), to parse logging control parameter and + epinit/ehinit parameters and to call reset_logfile() if logfile + name is changed. + +clmodes.h + Added extern declarations for logging/epinit/ehinit variables + +eparam.c +history.c +cl.par + "epinit" and "ehinit" changed from environment variables to CL params + as per mail discussion with Doug. Removed all setoption() stuff as + this is now taken care of in parse_clmodes() (in modes.c). + +hlib/clpackage.cl + Removed epinit and ehinit env vars. + +hlib/login.cl + Added commented out default values for logging and epinit/ehinit + parameters to the template login.cl file. + +pkg/language/doc/cl.hlp + ehistory.hlp + eparam.hlp + Modified due to move of epinit/ehinit vars to CL parameters and + addition of new logging parameter. + +pkg/language/language.hd + language.men +pkg/language/doc/logging.hlp + + putlog.hlp + + Added help for the "logging" discussion and the "putlog" builtin. + The "logging" man page talks about the CL logging as a whole, + discussing the parameters involved in a little more detail than the + help on the cl. + +------------------- + +pkg/cl/* + Cleaned up some of the CL source code; mostly just removed some + old, useless cldebug statements, etc. Also cleaned up grammar.y + a lot, at least to make the style consistent and more readable. + Gram.c and decl.c also got a bit of this as well. + +pkg/cl/README + Updated text; still referred to Unix "make" and VMS DCL/Makelib + generation techniques. + +-------------------------------- +Monday 24-MAR-1986 12:01:48.70 + +Subject: VMS/IRAF Plotting + +dev/graphcap + Added entries for QMS, EQMS, and NULL (testing) for STScI. + +vms/os/ vms.h + zfipol.c + mcsub.c + + mkpkg + +Implemented ZFIOPL for VMS to use NCAR Metacode translator (MCVAX). A +spoolfile is written in the necessary VMS file format by ZFIOPL. On close, +MCVAX is started up as a subprocess and commands are sent to it to set the +device (from graphcap DD string), read the spoolfile, and plot until finished. + +This code may depend on peculiarities of the ST version of MCVAX which I don't +know about. + +-------------------------------- +Tuesday 25-MAR-1986 11:53:12.75 + +Subject: vms/boot/bootlib/vfn2osfn.c + +Changed to return a null string if an error occurs mapping the file; it used to +return the last result of a filename mapping operation. This would to lead to +problems in mkpkg, e.g., + + $delete dir$sub/file.c + +If this file did not exist, the previous filename returned by vfn2osfn() would +be deleted. + +-------------------------------- +Wednesday 26-MAR-1986 12:04:53.81 + +Subject: mkpkg + +vms/boot/mkpkg/tok.c + $ifdef/$ifndef was not working -- bug when setting boolean variable; + fixed. + + changed os_cmd() to host_xc() for do_omake(), do_link(), do_xc(), so + the VMS DOCVCL routine can be used (to eliminate some spawning). + +vms/boot/mkpkg/host.c + docvcl() -- don't check return status and change to XYES/XNO; + leave as is (OK or ...) + + added host_xc() routine to call docvcl(). + +vms/boot/spp/xc.c + bug fix -- `firstobj' variable was not being reinited to NULL; caused + problems with above host_xc() changes. Added reinit in do_cleanup(). + +vms/boot/mkpkg/mkpkg + added ../spp/xc.c dependency for xcsub.c + +-------------------------------- +Friday 28-MAR-1986 09:37:16.83 + +Subject: ttyputline and map_cc + +pkg/system/lprint.x + page.x + type.x + ./help/houtput.x + + Changed map_cc from bool to int to work correctly with ttyputline(), + which expects an int and checks for YES/NO. In VMS Fortran, .true. is + encoded as a -1, not a 1 (YES). To change ttyputline() would mean + changing the LIBC interface c_ttyputline() so that it knew about this + feature of the host Fortran, so let's use the int YES/NO method. + +-------------------------------- +Friday 28-MAR-1986 10:12:49.38 + +Subject: graphcap entry for selanar hirez 100xl + +Not sure if this is a graphcap entry problem or a limitation on the selanar +itself: When in cursor mode in a task (e.g. onedspec.splot), typing 'c' to +print the cursor position will print "x,y: ... ..." in the lower left hand +corner, but then immediately erase it. Help via '?' does the same thing, i.e., +gets printed and erased immediately. + +-------------------------------- +Wednesday 2-APR-1986 13:22:46.16 + +Subject: pkg/cl/edcap.c + +Added the editor name to the eparam help page. + +-------------------------------- +Wednesday 2-APR-1986 15:24:20.96 + +Subject: vms/boot/bootlib/dcl.c + +Added interrupt support. When ^C typed, return status of dcl() (and os_cmd) +will be SYS_XINT, so MKPKG can deal with the error as on Unix. + +-------------------------------- +Wednesday 2-APR-1986 16:51:37.03 + +Subject: vms/boot/spp/... + +xc.c fixed inconsistencies in error/status checking, removed + old code, rearranged some functions (main to front, etc)., + and general cleanup. +xc.com command file to make xc (only) +mkpkg.com call xc.com + +-------------------------------- +Thursday 3-APR-1986 08:06:49.57 + +Subject: editor + +Just realized that "editor" is still an environment variable, used by +eparam/ehistory and the edit builtin. Epinit/ehinit have been changed to CL +parameters during the logging changes, but I forgot about this one. + +Should we change "editor" to a CL parameter, too? If so, it would require +changes in pkg/cl/edcap.c,builtin.c,cl.par and the help files for +eparam,ehistory,edit,cl. diff --git a/doc/ports/nsoport.hlp b/doc/ports/nsoport.hlp new file mode 100644 index 00000000..334471aa --- /dev/null +++ b/doc/ports/nsoport.hlp @@ -0,0 +1,193 @@ +.help +NOAO/NSO IRAF/UNIX installation, Nov. 14-15 1985, S. Rooke +.br + + A full binary copy of lyra!/iraf (in two tapes) was loaded into the +sunspot! VAX-11/750 running UNIX at NSO. The following notes describe the +various steps taken in the installation. + + +.nf +1. Leonard Sitongia selected his /u1/ root directory for IRAF as it contained + about 100 Mb in its disk partition. + + % mv /u1 /iraf + % vi /etc/fstab # replace "u1" with "iraf" for ra1d + % mount /iraf + % vi /etc/group # add IRAF group members so we can see who + # owns the various IRAF files + % vipw # yanked IRAF group members' entries from + # /etc/passwd/aquila + Now have /iraf with 100000 bytes available; IRAF developers have accounts + for the duration of the installation, mainly so we can easily look at + file ownerships. + +2. Read the two tapes into /iraf. + + % cd /iraf + % tar -xpf /dev/rmt0 # 1st tape contains /iraf... minus sys/* + (load second tape) + % mkdir /iraf/sys + % cd sys + % tar xp + + TAPE READ ERROR AFTER libsys.a + tu0: hard error bn25780 mbsr=13080 <ATTN, DTCMP, DTABT, MBEXC> + cr=100 <INCUPE> + ds=54640 <ERR, MOL, WRL, DPR, DRY, PES> + +3. At this point we looked at the tar listing, and saw that the only files + that didn't make it were the following six: + + Mkpkg.sh + libcur.a + libmain.o + libstg.a + prelink.e + zzsetenv.def + + Not realizing immediately that the 2 libraries must have been development + ones (the real ones were already in /iraf/lib), we attempted to bring + them across from Tucson using TIP(xmodem). + + % vi /etc/remote # set Tucson baud rate (1200) for Robotics modem + % tip us-0 # (U.S. Robotics modem looks in /etc/remote) + (now talking to modem) + atdp 1,602,3259251 + (got message from micom at remote, in Tucson) + (had to request class "102" rather than class "2"). + 2% xmodem -sb filename <cr> + (got xmodem message) + ~? # to get help from sunspot! tip; look for + # "receive xmodem binary" + ~( # (got prompt for local file name) + + Thus we copied the 2 libraries and Mkpkg.sh over (we would rebuild the + other files from files already present). We also brought over some files + from lyra!/u2/rooke... for working on graphcap and stdgraph. + +4. We now have almost the full binary IRAF under root directory /iraf/. + Now proceed to set up links outside the /iraf/ directories into a few + critical files within it so that all users can access them from a unix + shell. + + % su + % cd /usr/include + % ln -s $iraf/lib/libc/iraf.h iraf.h + % cd /local/bin + % ln -s $iraf/lib/mkiraf.csh mkiraf + % ln -s $iraf/lib/cl.e cl + % ln -s $iraf/lib/mklib.e mklib + % ln -s $iraf/lib/xc.e xc + +5. We now configure the magtape device tables and give the KI a real host + name then do a "sysgen". + + % vi /iraf/dev/hosts # create entries for "sunspot!" and "penumbra!" + % vi /iraf/lib/libc/kernel.h # find "TAPEDRIVE_TABLE"; enter correct + # magtape devices for sunspot! + % su + % cd /iraf/sys + % make >& spool & + + (inspecting the spool file found a phase error on envscan.o + from ranlib: libsys.a; mangled string table. + + % cd /iraf/sys/etc + % rm envscan.o + % touch envscan.x + % cd .. + % make >& spool & # this time it was OK. + + We have now completed the sysgen; however, there had been a minor stdgraph + kernel bug which was removed in a development version of stg_encode I had + tip'd over; I replaced /iraf/sys/gio/stdgraph/stgencode.x and rebuilt the + stdgraph kernel manually: + + % cd /iraf/sys/gio/stdgraph + % make >& spool & + + (Make wouldn't work; it turned out there was a spurious SPACE + character in the Makefile: "make lib" rather than "makelib" on + the "all: " line; fixed this and rebuilt.) + +6. By analogy with the Johns Hopkins installation, since the system + libraries had been modified, I went ahead with relinking the applications + packages; furthermore, I had a development version of showcap which I + used to replace /iraf/pkg/plot/tshowcap.x with in order to debug the + vt240 graphcap entries later on. + + % su + % cd /iraf + % csh -x Mkpkg.sh >& spool & + + However, talking with Doug Tody during this relink, I found out we only + needed to rebuild the DATAIO package. To save time, I killed the relink, + observed that it had been in the middle of the IMAGES package, and + manually completed the IMAGES rebuild: + + % cd /iraf/pkg/images + % make >& spool & + + (DATAIO had already successfully built, along with several others. I made + sure that the PLOT package had built successfully with the showcap + change.) + +7. All compile-time operations are now complete; we need only modify the + run-time environment for terminal and graphcap entries and set up for + local "mkiraf"'s. + + % cd /iraf/dev + % vi termcap # provide vt240 entry + % vi graphcap # provide vt240 entry; this was yanked from + # my development ReGIS graphcap file which + # I had previously "tip"'d over. + % cd /iraf/lib + % vi mkiraf.csh # setenv users /u2/compsup/mother/irafusers + # and directory names at the bottom (prob. no + # changes in these); changed 2 lines about + # vt100 vs vt640 to vt240 vs some other term. + + % vi clpackage.cl # change default device names, version, site: + + set printer = "imagen" --> "tp" + set stdgraph = "vt640" --> "vt240" + set stdimage = "iism70" --> "? (I forget)" + set stdplot = "versatec" --> "tp" + set terminal = "vt100" --> "vt240" + set version = "NOAO/IRAF V2.0" --> "NOAO/NSO/IRAF V2.0" + + % vi login.cl # uncommented printer, stdimage, stdplot and + # gave them the local names. + + We also "bgrep"'d some zzsetenv.def files to make sure they weren't + pointing to Tucson pathnames. + +8. This completed the non-graphics part of the installation. We were now able + to bring up the cl successfully: + + % cd (user's main iraf directory) + % mkiraf + % vi login.cl # modify as desired + % cl + +9. The remainder of the installation involved setting up a workable ReGIS + graphcap for NSO's vt240's. I copied the development graphcap entry I + had previously created for the ENCORE HostStation100, and went through + the vt240 Programmer's Summary capability by capability. There were + about six changes from the hs100. Graphics output then worked correctly, + but we had the same problem reading the cursor that I had had with the + hs100 in Tucson. It turned out later, back in Tucson, that the problem + was that I was directing the cl to "lib$xstdgraph.e" (the "kf" parameter) + in graphcap, rather than to "cl" itself. The precedence for the cl + process, when it receives a read-cursor request, is to take the kernel + name from the graphcap entry, regardless of the fact that the cl (or + any other process) was linked directly with the stdgraph kernel code + and calls gki_inline_kernel(). Thus the "kf" parameter in graphcap + must point to the cl itself in order to use the inline kernel. At + present, cursor readback does not work with an external kernel. + + Several days after the installation (Nov. 20) I called the "kf" change + in to Leonard at NSO. He made the change and checked out "implot" and + "=gcur", and said they worked correctly with no further changes to our + ReGIS graphcap. diff --git a/doc/ports/sun2_032786.doc b/doc/ports/sun2_032786.doc new file mode 100644 index 00000000..298139db --- /dev/null +++ b/doc/ports/sun2_032786.doc @@ -0,0 +1,152 @@ +SUN/IRAF V2.2 Installation, 6 March 1986 Sun-2, software floating point +------------------------------------------------------------------------------ + +/usr/iraf/***** +/usr/iraf + Located IRAF root directory at /usr/iraf, created iraf/local + for personal file storage. Unpacked tar archive of v2.2, 6 Mar + version, from master VAX/UNIX system "lyra". (3/6) + +/usr/iraf/local/ + Unpacked earlier Sun archive of /usr/iraf/local; this contains + development stuff for Sun graphics kernels, plus the .login file + for the IRAF account. It is important that this file sources + $iraf/unix/hlib/irafuser.csh to pick up environment definitions + and aliases. Make sure iraf root and home directories match + the real thing. (3/6) + +unix/as +unix/as/ishift.s +unix/as/zsvjmp.s + Moved the VAX as/ to unix/vaxas. Created an empty unix/as and + copied the two SUN .s files into it from unix/mc68000. (3/6) + +unix/hlib/mach.h +unix/hlib/libc/spp.h + Set EPSILONR and EPSILOND for the SUN as in unix/mc68000/README. + Set BYTE_SWAP2 and BYTE_SWAP4 to NO in mach.h. (3/6) + +unix/hlib/mkmlist.csh + Changed bgrep to grep, since bgrep not available in standard + UNIX. (Not important, doesn't have to work, so the efficiency + of bgrep on the development machine is worth the mach. dependence.) + (3/6) + +home$.login +unix/hlib/mkiraf.csh +unix/hlib/libc/iraf.h + Changed all occurrences of iraf root directory pathname. (3/6) + +unix/hlib/mkpkg.inc + Set USE_CALCOMP to no. (3/6) + +/usr/include/iraf.h -> $hlib/libc/iraf.h + Establish this symbolic link as superuser (i.e. %su; cd /usr/include; + ln -s $hlib/libc/iraf.h iraf.h). This is necessary for compiling + IRAF programs. (3/6) + +TODO: unix/hlib/[dif]mach.f + These files were NOT set up for the Sun, since we did not have the + values, but this should be done later. Once modified, a mkpkg at the + root will recompile all affected programs. + +TODO: unix/as/*.x + It would be nice to have some additional assembler modules for + efficiency reasons. See unix/vaxas. Coding of these can be left + for later. + + +/usr/iraf/hlib/libc/kernel.h + Commented out DEBUGMEM in order to use the standard UNIX malloc rather + than IRAF's version. This is necessary for some reason on the Sun for + SunCGI programs to be callable from SPP programs. (3/6) + +------------------------------------------------------------------------------ +That completes the initial setup. Now we bootstrap the system. + + % cd $iraf/unix + % sh -x mkpkg.csh >& spool & + +This builds all the bootstrap utilities, then as a final step compiles the +portion of LIBSYS in host/gdev, which exercises MKPKG, XC, etc. If all that +works things are in excellent shape. (3/6) + +/usr/bin/alloc -> $hlib/alloc.e +/usr/bin/generic -> $hlib/generic.e +/usr/bin/mkpkg -> $hlib/mkpkg.e +/usr/bin/rmbin -> $hlib/rmbin.e +/usr/bin/rmfiles -> $hlib/rmfiles.e +/usr/bin/rtar -> $hlib/rtar.e +/usr/bin/wtar -> $hlib/wtar.e +/usr/bin/xc -> $hlib/xc.e + Establish these symbolic links as superuser (e.g. cd /usr/include; + ln -s $hlib/mkiraf.csh mkiraf). These are required for regular + users who do not have a .cshrc or .login which sources + $iraf/unix/hlib/irafuser.csh, for running the cl or mkiraf. + Ordinarily we only link xc, mkiraf, and mkpkg here, but since we're + doing development on the Sun outside IRAF, the rest are useful. (3/6) + +unix/hlib/alloc.e + This file must belong to root, since it needs root permissions at + runtime to allocate devices. Do the following: + + % cd $hlib + % su + % /etc/chown 0 alloc.e (3/6) + +------------------------------------------- +The bootstrap is now complete. The next step is to do a full system compile. + +There are 5 files that need to be hand-compiled without optimization (from +previous experience on the SUN) to avoid getting in an infinite loop in pass +c2 of the compiler. "xc -c" each file to create an object file in its +directory; mkpkg will then avoid recompiling it. Note: see local/bugs +README for description of "-P" for partial optimization instead. + + sys/fio/fstati.x + math/bevington/matinv.f + sys/gio/nspp/portlib/gridal.f + sys/ki/irafks.x + pkg/twodspec/longslit/transform/igsfit/igsfit.f + +(The last file wasn't included in the initial hand-compile, but stalled +the later sysgen in an infinite loop; placed here for completeness next time.) +Now perform the full system compile (sysgen). + + % cd $iraf + % mkpkg >& spool & (3/6) + + The sysgen was started at 17:02 on March 6, 1986. It stalled at 9:47 + Friday March 7, in an infinite loop in: + pkg$twodspec/longslit/transform/igsfit/igsfit.f + I hand-compiled it and restarted the sysgen at 13:30, renaming the first + spool file spool1. (3/7) + + The sysgen finished at 15:53 with no further errors (the "Termination + code 9" in $iraf/spool is due to another stall in igsfit -- I had + hand-compiled the wrong file, so mkpkg stalled again; this time I just + killed the lowest-level process and ran mkpkg from longslit/transform + by hand during the main sysgen, and later checked that there weren't + any collision problems). + + Clock time was thus 19:08 hours, but at least 5 of these hours saw two + interactive users (mostly editing, but some compiling) competing for + resources. (3/7) + +/usr/bin/xc -> $hlib/xc.e + Established this symbolic link as superuser, now what we have a + CL in $iraf/bin. This completes the software-building part of the + installation. (3/7) + +unix/as/ishift.s + Would not do a right shift, since the 68010 uses two different + instructions to do left and right shifts, unlike the vax, which + allows the shift argument to be negative. Changed to use the ROL + and ROR instructions. (3/14) + +sys/gio/stdgraph/stgdrawch.x + When stdgraph kernel attempted to draw high-quality text, it + began drawing lines and garbage text all over the screen until it + hit a segmentation violation. Traced to module sgch_flush(), + "call stg_polyline (pl, op / 2)", (SHORT op), where stg_polyline + wanted an INT for the 2nd argument. Changed to "int (op / 2)". (3/27) diff --git a/doc/ports/sun2_042386.doc b/doc/ports/sun2_042386.doc new file mode 100644 index 00000000..c2807994 --- /dev/null +++ b/doc/ports/sun2_042386.doc @@ -0,0 +1,141 @@ +SUN/IRAF V2.3 Installation, 17 April 1986 Sun-2, software floating point +------------------------------------------------------------------------------ + +/usr/iraf/***** +/usr/iraf + Located IRAF root directory at /usr/iraf, created iraf/local + for personal file storage. Unpacked tar archive of v2.3, 17 Apr + version, from master VAX/UNIX system "lyra". (4/17) + +unix/as +unix/as/ishift.s +unix/as/zsvjmp.s + Moved the VAX as/ to unix/vaxas. Created an empty unix/as and + copied the two SUN .s files into it from unix/mc68000. (4/17) + +unix/hlib/mach.h +unix/hlib/libc/spp.h + Set EPSILONR and EPSILOND for the SUN as in unix/mc68000/README. + Set BYTE_SWAP2 and BYTE_SWAP4 to NO in mach.h. (4/17) + +unix/hlib/mkmlist.csh + Changed bgrep to grep, since bgrep not available in standard + UNIX. (Not important, doesn't have to work, so the efficiency + of bgrep on the development machine is worth the mach. dependence.) + (4/17) + +home$.login +unix/hlib/mkiraf.csh +unix/hlib/libc/iraf.h + Changed all occurrences of iraf root directory pathname. (4/17) + +unix/hlib/mkpkg.inc + Set USE_CALCOMP to no. (4/17) + +/usr/include/iraf.h -> $hlib/libc/iraf.h + Establish this symbolic link as superuser (i.e. %su; cd /usr/include; + ln -s $hlib/libc/iraf.h iraf.h). This is necessary for compiling + IRAF programs. (4/17) + +unix/hlib/[dir]1mach.f + Commented out the VAX data statements, and uncommented the IEEE/ + 68000 data statements. (4/17) + +TODO: unix/as/*.x + It would be nice to have some additional assembler modules for + efficiency reasons. See unix/vaxas. Coding of these can be left + for later. + +/usr/iraf/hlib/libc/kernel.h + Commented out DEBUGMEM in order to use the standard UNIX malloc rather + than IRAF's version. This is necessary for some reason on the Sun for + SunCGI programs to be callable from SPP programs. (4/17) + +------------------------------------------------------------------------------ +That completes the initial setup. Now we bootstrap the system. + + % cd $iraf/unix + % sh -x mkpkg.csh >& spool & + +This builds all the bootstrap utilities, then as a final step compiles the +portion of LIBSYS in host/gdev, which exercises MKPKG, XC, etc. If all that +works things are in excellent shape. (4/17) + +/usr/bin/alloc -> $hlib/alloc.e +/usr/bin/generic -> $hlib/generic.e +/usr/bin/mkpkg -> $hlib/mkpkg.e +/usr/bin/rmbin -> $hlib/rmbin.e +/usr/bin/rmfiles -> $hlib/rmfiles.e +/usr/bin/rtar -> $hlib/rtar.e +/usr/bin/wtar -> $hlib/wtar.e +/usr/bin/xc -> $hlib/xc.e +/usr/bin/cl -> $hlib/cl.e + Establish these symbolic links as superuser (e.g. cd /usr/include; + ln -s $hlib/mkiraf.csh mkiraf). These are required for regular + users who do not have a .cshrc or .login which sources + $iraf/unix/hlib/irafuser.csh, for running the cl or mkiraf. + Ordinarily we only link xc, mkiraf, and mkpkg here, but since we're + doing development on the Sun outside IRAF, the rest are useful. (4/17) + +unix/hlib/alloc.e + This file must belong to root, since it needs root permissions at + runtime to allocate devices. Do the following: + + % cd $hlib + % su + % /etc/chown 0 alloc.e (4/17) + +------------------------------------------- +The bootstrap is now complete. The next step is to do a full system compile. + +There are 5 files that need to be hand-compiled without optimization (from +previous experience on the SUN) to avoid getting in an infinite loop in pass +c2 of the compiler. "xc -c" each file to create an object file in its +directory; mkpkg will then avoid recompiling it. Note: see local/bugs +README for description of "-P" for partial optimization instead. + + sys/fio/fstati.x + math/bevington/matinv.f + sys/gio/nspp/portlib/gridal.f + sys/ki/irafks.x + pkg/twodspec/longslit/transform/igsfit/igsfit.f + + (The following two entries are from the previous NOTES file on tucana; + I'm not sure if this ishift is the correct one: Doug indicated that + the fixed ishift on tucana hadn't made it back to lyra, but DIFF showed + only half of a comment line difference between the lyra version and the + version unpacked from the $iraf/unix directory in the tucana archive. + The stgdrawch.x fix also hadn't made it back to lyra prior to cutting + the tape for this installation.) + + unix/as/ishift.s + Would not do a right shift, since the 68010 uses two different + instructions to do left and right shifts, unlike the vax, which + allows the shift argument to be negative. Changed to use the ROL + and ROR instructions. + + sys/gio/stdgraph/stgdrawch.x + When stdgraph kernel attempted to draw high-quality text, it + began drawing lines and garbage text all over the screen until it + hit a segmentation violation. Traced to module sgch_flush(), + "call stg_polyline (pl, op / 2)", (SHORT op), where stg_polyline + wanted an INT for the 2nd argument. Changed to "int (op / 2)". + +Now perform the full system compile (sysgen). + + % cd $iraf + % mkpkg >& spool & (4/17) + + Begun at Thu Apr 17 13:13:22 MST 1986; ended at Fri Apr 18 06:35:16 + MST 1986, for a sysgen time of 17h22m. The only suspicious thing in + the spoolfile was in XTOOLS, where mkpkg could not find module or + label "generic". (4/20) + +$iraf/bin/x_cv.e +$iraf/bin/x_display.e +$iraf/vms/ + Removed these files and directories to free up disk space. (4/20) + +(help database) + Ran MKHELPDB from the CL, having neglected to do so immediately + after the sysgen. (4/23) diff --git a/doc/ports/sun2_062486.doc b/doc/ports/sun2_062486.doc new file mode 100644 index 00000000..d483e475 --- /dev/null +++ b/doc/ports/sun2_062486.doc @@ -0,0 +1,134 @@ +SUN/IRAF V2.3 Installation, 13 June 1986. Sun-2, software floating point +-------------------------------------------------------------------------------- + +/usr/iraf/ + Ran rmbin on bin, sys, pkg, math, lib, local, unix. Unpacked + source-only archive from master VAX/UNIX system "lyra" of + 12-June-86 17:00. (6/13) + +unix/as/ +unix/as/ishift.s +unix/as/zsvjmp.s + Deleted VAX contents of as/, copied mc68000/ishift.SUN and + zsvjmp.SUN to as/*.s. (6/13) + +unix/hlib/[dir]1mach.f + Commented out pdp (vax) data statements and uncommented IEEE + statements. (6/13) + +unix/hlib/mach.h +unix/hlib/libc/spp.h + Replaced EPSILONR and EPSILOND with values from unix/mc68000/README. + Set both BYTE_SWAPs to NO in mach.h. (6/13) + +unix/hlib/mkiraf.csh + Edited iraf root to new pathname. (6/13) + +unix/hlib/mkpkg.inc + Set USE_CALCOMP to "no". (6/13) + +unix/hlib/libc/iraf.h + Changed iraf root pathname. (6/13) + +unix/hlib/libc/kernel.h + Commented out DEBUGMEM (i.e. use standard UNIX malloc()) + in order that spp programs can call SunCGI. (6/13) + +unix/ + Bootstrap (sh -x mkpkg.csh); no problems. (6/13) + +unix/hlib/alloc.e + As su, "/etc/chown 0 alloc.e" so it can allocate devices. (6/13) + +/usr/bin/alloc -> $hlib/alloc.e +/usr/bin/generic -> $hlib/generic.e +/usr/bin/mkpkg -> $hlib/mkpkg.e +/usr/bin/rmbin -> $hlib/rmbin.e +/usr/bin/rmfiles -> $hlib/rmfiles.e +/usr/bin/rtar -> $hlib/rtar.e +/usr/bin/wtar -> $hlib/wtar.e +/usr/bin/xc -> $hlib/xc.e +/usr/bin/cl -> $hlib/cl.e + Made sure these symbolic links existed. (6/13) + +-------------------------------------------------------------------------------- +Bootstrap is complete. Hand-compile the Sun f77 optimizer-bug routines before +performing the full recompile sysgen. + +sys/fio/fstati.x F77 runtime +math/bevington/matinv.f F77 runtime +sys/gio/nspp/portlib/gridal.f F77 runtime +sys/ki/irafks.x F77 runtime +noao/twodspec/longslit/transform/igsfit/igsfit.f F77 runtime + All these files have to be hand-compiled without optimization + from previous experience with the Sun V2.0 f77 compiler; none + of these files nor their .x parents have changed since last + built on a Sun-2. (6/13) + +iraf/ + Began full compile & link sysgen at 16:33. (6/13) + +fio/fioclean.x + Fixed null pointer bug. (6/14) + +bin/x_display.e +bin/x_cv.e +images/tv/cv/libpkg.a +images/tv/display/libpkg.a + Removed to free up disk space. (6/14) + +$iraf + Unpacked an incremental archive from lyra! to bring us current + to 09:15 June 20, 1986. Performed an incremental sysgen from + the root. (6/20) + +noao/twodspec/apextract/* + The preceding sysgen failed to find all files in icfit/* except + for 3 source files. To be safe, I (sr) made a complete archive + of apextract from lyra at 10:20, unpacked it, and did a "mkpkg + update" from here. (6/20) + +pkg/images/geometry/t_imtranspose.x F77 runtime + f77 optimizer bug was causing "Pixel subscript out of bounds" + in imtranspose. Compiled without optimization from cl with + "cl> !mkpkg xflags=-c; cd ..; mkpkg update". (6/20) + +noao/twodspec/apexold/* + Because of old file dates and because this directory on lyra + was created only by renaming the directory itself, it didn't + get copied in the incremental tar earlier this week. Made + a fresh archive on lyra and a "mkpkg update". (6/20) + +$iraf + Unpacked a lyra! incremental archive taken at 14:40 June 21; + performed a root incremental sysgen. (6/21) + +$iraf + Unpacked a lyra! incremental archive taken at 08:10 June 23; + performed a root incremental sysgen. (6/23) + +noao/lib/scr/* +noao/twodspec/apexold/* +noao/twodspec/apextract/* + Replaced with full archives from lyra! to attempt to clear up bugs + possibly related to renaming, rather than copying, files on lyra! + since the June 12 full archive -- these could be missed by the + incremental archives (find . -mtime -N). MKPKG updates in both + apextract directories. (6/23) + +pkg/cl/unop.c + Changed call to sscanf (sval, "%f", &rresult) in case OP_REAL to + sscanf (sval, "%lf", &rresult) because on SUNs, only the first + four bytes starting at rresult were being written into (rresult + is declared "double"). Should be changed on master system as well. + (6/23) + +-------------------------------------------------------------------------------- +June 24, 1986: Extensive testing for several days has revealed no further +bugs particular to the SUN-2 in its implementation at NOAO (SUN V2.0, no +fpa, no array processor). Although we do not have a 1/2" tape drive on the +SUN-2, the SUN-3's have a known bug which appears to be SUN's problem -- +I/O error when trying to backspace-record when the drive is positioned between +the two EOF marks written at close time. It is probable we will have a +workaround for this bug in early July. +-------------------------------------------------------------------------------- diff --git a/doc/ports/sun2_102885.doc b/doc/ports/sun2_102885.doc new file mode 100644 index 00000000..adf5055c --- /dev/null +++ b/doc/ports/sun2_102885.doc @@ -0,0 +1,190 @@ +SUN/IRAF V2.0 Installation, 28 October 1985 Sun-2, software floating point +------------------------------------------------------------------------------ + +find . \! -type d -print > _files # get list of nondirectory files +grep '\.[aoe]$' _files > _bin # find binaries +grep '\.s$' _files > _mach # find assembler files +ls _bin | grep '[2-9] iraf' > _links # find binary files with links +rm _bin # delete binary files + +deleted all .[aoe] files (22 Mb) +not necessary to edit Makefiles + +/usr/include/iraf.h + Made symbolic link in pointing to /iraf/lib/libc/iraf.h; necessary + before compiling any C programs. + +built mklib.e +built preprocessor: xc.e, xpp.e, rpp.e +built generic.e (had to do this manually; no Makefile) + lex generic.l; cc lex.yy.c -lln -o generic.e + +/usr/bin + Made symbolic links for unix tasks cl, xc, mklib, mkiraf + +lib/*.e + Made symbolic links for xc.e, xpp.e, rpp.e, mklib.e generic.e + +lib/libc/spp.h +lib/mach.h + Changed defn of machine epsilon (use Fort program in osb). + Set byte swap flags to NO. + +sys/os/zsvjmp.s + Replaced VAX version with MC68000 version. + +sys/osb/bitpak.s +sys/osb/bitupk.s +sys/osb/bytmov.s + Edited Makelib to replace bitpak.s and bitupk.s with the portable + version in bitfields.c. Likewise replaced bytmov.s with bytmov.c. + +sys/vops/ak/Makelib +sys/vops/lz/Makelib + Commented out the VAX .s optimized files in the Makelib, and + uncommented the portable .x versions. + +cd sys; make >& spool & # start sysgen of system libraries + (pass c2 of f77 hung in infinite loop on fio$fstati.f; optimizer bug) + +cd libc; mklib -O >& spool & # make libc.a (C runtime library) + + +(peruse output from sysgen and fix compile time bugs) +---------------------------------- + +sys/gio/gki/gkigetwcs.x + Array 'ret' no longer used, deleted. + +sys/vops/achtXY + When datatype X is the same as Y, the loop variable I is not used + (no action taken). + +pkg/softools/boot/spp/xpp/decl.c + The XPP declarations code which output the argument list for a + procedure could sometimes generate an output line too long for RPP to + handle. The code was breaking the argument list after 8 arguments + had been output, a simplistic technique which would fail when the + identifiers were too large. Changed to keep track of the output + column and break lines that are close to 80 cols in length. + +sys/libc/ckimapc.c + Local variable maxch redefines argument; argument maxch not used to + control length of output string. + +pkg/system/x_systest.x +pkg/system/system.cl + Procedure mtdevlist was still being referenced in this package. + +(system package, cl came up with no problems) + + +cd math; make >& spool & +------------------------------------- + +math/Makefile +math/Makelib + Added a Makelib to the math directory, with an entry for each math + package. Set up Makefile to make all the libraries. Must still + be linked to lib when done, if not already. + +math/bevington/matinv.f + Apparent optimizer failure in matinv.f. Recompiled successfully + without optimization. + +(all other math libraries compiled successfully; linked em all into /iraf/lib) + + +cd /iraf; csh -x Mkpkg.sh >& spool & +----------------------------------------------- + +pkg/*/Mkpkg.sh + The "rm -f *.e" causes the script to abort without doing anything if + there is no .o or .e file to delete. Got around this with a temporary + fix, i.e, making a junk.e in each directory before doing the rm. + +As expected, the links failed due to the following libraries not being present +in lib$ yet: + + all math libraries math/ + xtools pkg/xtools + nspp sys/gio/nspp + ncar sys/gio/ncarutil + gks sys/gio/gks + calcomp local UNIX (not IRAF) library + +sys/gio/ncarutil/ishift.s +sys/gio/nspp/ishift.s + Wrote SUN/MC68000 version. + +sys/gio/nspp/* + The usual complaints about questionable or nonportable constructs + in the NCAR fortran. + +sys/gio/nspp/nspp/gridal.f + Optimizer failure. + +sys/gio/nspp/utilities/conrec.f + Invalid hollerith specification on line 387; count is incorrect due + to continuation. Changed to quoted string. + +pkg/Mkpkg.sh + Reordered packages to make the lower level packages first. + In particular, imred cannot be made until after onedspec. + +pkg/softools/boot/spp/xc.c +pkg/softools/boot/spp/xpp/xppmain.c + Added a fflush(stderr) after each write to stderr. On the SUN stderr + appears not to be flushed automatically when i/o is redirected to an + ordinary file. + +pkg/dataio/lib/cyboow.s + Wrote a stubbed out SPP version of these procedures so that the DATAIO + package can be linked. + +pkg/images/tv/display/t_mkdisplay.x + Changed the obsolete IM_PIXELS to IM_PIXOFF. + +pkg/twodspec/longslit/Makefile + Would not make the library before linking, causing a rebuild to fail. + x_aperture.e was made first, but mklib was called only for x_longslit.e. + +ADB usage note: + Breakpoints should be set at procedure+4 to get a correct stack trace + showing the arguments to the procedure (vs. +2 on the VAX). + +pkg/twodspec/longslit/Makefile (etc. in subdirs) + Turned off the -F -g; this is for debugging and should NOT be turned + on in an installed package (the images are larger and there is no + optimization). Also, the f77 compiler aborted with a DBX error + related to a call to an external procedure passed as an argument to + a procedure (file igsfit.f). I did not investigate further; hand + compilation of the procedure worked. + +sys/libc/cfpath.c + The third (maxch) argument was being passed to FPATHNAME by value + rather than by reference. + +dev/uhosts +dev/hosts +dev/hostlogin + Added more machines to the network tables. + +pkg/images/Mkpkg.sh + Added entry for subpackage imdebug. + +pkg/images/imdebug/Mkpkg.sh + New file. + +dev/helpdb + Recompiled the help database (in the CL using the mkhelp task in the + softools package). + +sys/libc/cfmapfn.c + The third (maxch) argument was being passed to FPATHNAME by value + rather than by reference. + +pkg/system/allocate.cl + As a temporary fix, commented out the call to UNIX to allocate a + device. Removed the enumerated device names from the parameter file + since device names are not constant strings (this was never correct). diff --git a/doc/ports/sun2_skyfpa.unc b/doc/ports/sun2_skyfpa.unc new file mode 100644 index 00000000..fcc97f48 --- /dev/null +++ b/doc/ports/sun2_skyfpa.unc @@ -0,0 +1,168 @@ +SUN/IRAF installation U. North Carolina, Sun-3 UNIX on Sun-2 hardware. +Beginning 24 September 1986, dct. +---------------------------------------------------- + +unix/... + Deleted all binary files (should have been done before distribution). + (9/24) + +local/.login +unix/hlib/mkiraf.csh +unix/hlib/mkpkg.inc + Changed the -f68881 flags to -fsky. (9/24) + +cd unix; sh -x mkpkg.csh >& spool & + Started up the first bootstrap. (9/24) + +------------------------- +(Resume 27 Sept) +Bootstrap succeeded without any apparent problems, except that there were +still binaries in lib, so the mkpkg in gdev did not recompile the IIS +interface into libsys.a. + + - Ran RMBIN on the non-HSI directories to get rid of the binaries. + Worked fine, except that it also deleted the .login file which + contained some control codes which fooled RMBIN into thinking it + was a binary file. + +Next, tried mkpkg again in GDEV. This failed immediately with RPP generating +an error message something like `unknown x$type directive'. Traced this to +a Fortran optimizer bug in rpp/ratlibf/enter.f. Compiled that module and +tried again. Failed again: this time it ran, but some of the symbols came +out with all the characters set to the | character. Traced this one to yet +another (very similar) optimizer bug in spp/rppfor/ludef.f. Fixed that one +and relinked, and this time was able to compile GDEV, although by this time +I have little confidence in the quality of the compiled objects!! + +local/bugs/unc/enter.[fs] +local/bugs/unc/ludef.[fs] + Generated the assembler for these bugs and captured it with tip so + that we can send it to the place where bugs go at SUN. (9/27) + +unix/hlib/SUN_kludge/precomp.csh + Changed the -f68881 switches to -fsky. (9/27) + +----------------------------------------------- +Started the first full sysgen. + cd $hlib/SUN_kludge; precomp.csh + cd $iraf + mkpkg >& spool & (9/27) + +unix/hlib/mkiraf.csh + Set root imdir to /usr/tmp. (9/28) + +Sysgen Progress: (9/28) + There were a couple of problems with the sysgen, but mostly it seems to + be running ok. This machine is very slow, the Sun-3 is MUCH faster. + + [1] When I rebuilt gdev manually (due to the problems with the SPP), + I was in a subdirectory hence did not make everything. This caused + some of the links in the main sysgen to come up short. This is + not unusual; probably a mkpkg gdev should be included in the + main sysgen, just in case it was missed in the bootstrap, or in + case libsys.a was deleted. + + [2] There were some f77 failures in VOPS, despite the reduction in the + command line lenth to 400. This is almost certainly a bug in the + f77 program itself. The error message is + + Compiler error on line 0 of (null): invalid flag c + + Where c is some character. This always happens to a file at or + near the end of the file list (maybe 384 would be a good length?). + The workaround until Sun gets this fixed is simply to mkpkg + again, that will recompile the remaining files. + + NOTE - NOTE - NOTE - I just discovered some Sun docs noting bugs + in the V3.1 f77. One is "f77 cannot handle more than about forty + source files in a single command". This is the problem we have + here. + + (fixed these items and restarted sysgen, keeping libraries thus far + (compiled intact.) + +unix/boot/mkpkg/host.c + Decreased the size of the host command line to 320 characters to + avoid the above mentioned f77 40-file bug. (9/28) + +--------------------------------------- +Begin testing, x_system.e, cl.e,... + We have very serious problems here. x_system.e runs, but most of + the tasks misbehave in one way or another. The cl just hangs up + during startup. + +unix/os/zmain.c +unix/os/zopdpr.c +unix/os/zfiopr.c +unix/os/zoscmd.c + The runtime problem mentioned above turned out to be due to the Sky + floating point board ignoring all floating point instructions; the + last operand sent would be the one read back, with no operation + being performed. Took a while to figure this one out: everything + was being compiled and linked correctly with the -fsky option, + and indeed the skyboard startup code was being called during process + startup. + + What it finally turned out to be was the series of close() cy{alls in + the IRAF main. These were used to close the unwanted file + descriptors inherited from the parent process via the usual UNIX + convention of passing all open files on to the child. Unfortunately, + the sky board is opened as a file during process startup, before the + IRAF main is entered, hence the IRAF main would immediately close + it down and all floating point would thereafter fail miserably. + + The solution was to use the new 4.2BSD `fcntl' to set the close-on-exec + flag on the unwanted file descriptors (3 on) before calling execl(). + It is conceivable there might be problems with using this in + conjunction with vfork (don't want to affect parents file descriptors, + e.g., if execl fails), but I think it will probably work; more + testing is warranted later. (^R +{9/28) + +-------------------------------------------- +With this fix and a relink, CL runs, spawning system process, etc. +Sysgen resumed at its incredibly slow pace; will check back later for further +tests. (9/28) + +Sysgen completed normally (Monday 29 September) +Begin testing. + +sys/gio/gascale.x + IMPLOT failed immediately on the first attempt. The problem was traced + to a Fortran optimizer bug in this routine - very straightforward code, + too. My confidence in this compiler is pretty low this point. + A few more of these, and we should recompile the entire system without + optimization; it is probably already justified. (9/28) + + Moved sample bug file into in local/bugs/unc. It is a register + allocation bug in a case statement; the code is testing the value of + a register that was never loaded with the value it is supposed to + be testing. + +image templates + The image template code is returning garbage image names; imheader, + imstat, etc., fail on dev$pix. + +---------------------------------------- +That does it, we recompile everything without optimization. The bootstrap +appears to be ok, so we will not redo that. Probably VOPS can be compiled +with optimization, that would gain back much of the speed for image operators. +I will leave the executables in case anyone wants to use them; they will be +replaced automatically when the sysgen reaches the link stage. (9/29) + +unix/hlib/mkpkg.inc + Remove -O flag. (9/29) + +cd $hlib/SUN_kludge; precomp.csh + This step not necessary since we are not using the optimizer, + nor the -f68881 switch, which gave problems with complex. (9/29) + +cd $iraf; rmbin lib pkg noao (except keep the optimized VOPS) +cd gdev; mkpkg +cd $iraf; mkpkg >& spool & (and renice it) + +--------------------------------- +Sysgen completed; ran a few tests and things?`[5'4llright. (9/30) + + TODO: as root, `chown 0 $hlib$alloc.e' + backup system, strip it to save space (probably) diff --git a/doc/ports/sun3_042586.doc b/doc/ports/sun3_042586.doc new file mode 100644 index 00000000..03f26c72 --- /dev/null +++ b/doc/ports/sun3_042586.doc @@ -0,0 +1,250 @@ +SUN/IRAF V2.3 Installation, 14 April 1986 Sun-3, software floating point +------------------------------------------------------------------------------ + +/usr/iraf/ + Unpacked a source-only TAR archive made on lyra this afternoon; + didn't first delete anything. Made sure we had a .login with + $iraf defined as the local IRAF root (/usr/iraf/). (4/14) + +/usr/include/iraf.h + As Superuser, "ln -s unix/hlib/libc/iraf.h ." (4/14) + +/usr/bin/alloc -> $hlib/alloc.e +/usr/bin/generic -> $hlib/generic.e +/usr/bin/mkpkg -> $hlib/mkpkg.e +/usr/bin/rmbin -> $hlib/rmbin.e +/usr/bin/rmfiles -> $hlib/rmfiles.e +/usr/bin/rtar -> $hlib/rtar.e +/usr/bin/wtar -> $hlib/wtar.e +/usr/bin/xc -> $hlib/xc.e +/usr/bin/cl -> $hlib/cl.e + As Superuser, performed these symbolic links. (4/14) + +unix/hlib/mkiraf.csh +unix/hlib/libc/iraf.h + Modified IRAF root pathname, HOST definition; irafuser.csh not + modified, as $iraf is defined in the IRAF account .login. (4/14) + +unix/hlib/mkmlist.csh + Changed bgrep to grep, since bgrep not available in standard + UNIX. (Not important, doesn't have to work, so the efficiency + of bgrep on the development machine is worth the mach. dependence.) + (4/14) + +as/ +vaxas/ +mc68000/ + Moved as/ to $iraf/vaxas/; moved $iraf/mc68000/ishift.SUN, + zsvjmp.SUN to as/ishift.s, zsvjmp.s. (Now that we have a + SUN-3 with 68020, the BYTPAK etc. assembler sources should also be + implemented). (4/14) + +unix/hlib/mach.h +unix/hlib/libc/spp.h (EPSILON) + Compiled osb$zzeps.f with "f77 -O -f68881 -o zzeps.e zzeps.f"; + ran it to check hardware floating point epsilon; turned out to + be same as software floating point to 4 places. Modified machine + epsilon and byte-swapping definitions (see unix/mc68000/README). + (4/14) + +unix/hlib/[dir]1mach.f + Commented out the VAX lines and uncommented the IEEE floating + point lines for the 68000. (4/15) + +unix/hlib/mkpkg.inc + Modified XFLAGS to "-c -O -f68881" for our hardware floating point + option. To verify that this works, I examined zzeps.e, compiled with + the same flags, with adb and found that, indeed, only single arguments + were being passed and actual floating point instructions were being + generated. Set USE_CALCOMP to NO. (4/15) + +unix/hlib/libc/kernel.h + Commented out DEBUGMEM in order to use the standard UNIX malloc rather + than IRAF's version. This is necessary for some reason on the Sun for + SunCGI routines to be callable from SPP programs. (4/15) + +unix/hlib/libc/iraf.h + Added definition for SUN3; the Sun IRAF kernel is still mostly + identical with the VAX kernel, but zxwhen.c needs to know if it + is being compiled on a Sun-3. (4/15) + +unix/ + Attempted a bootstrap; had to make the following modification to + get it to work: (4/15) + +unix/os/zxwhen.c + Renamed structure vax_exception to hwx_exception; added ifdef branch + for SUN3 FPE traps-to-strings structure. (The version that compiled + under the Sun-2 failed to compile under the Sun-3.) (4/15) + +unix/ + Performed a bootstrap with "sh -x mkpkg.csh >& spool &". + The only error showing was in bootlib/mkpkg.csh, "syntax error + at line 13: `end of file' unexpected", presumably due to the + conditional construct, and possibly a CSHELL bug (libboot.a + built correctly and ended up in $hlib as it should anyway). (4/15) + +unix/hlib/alloc.e + This file must belong to root, since it needs root permissions at + runtime to allocate devices. Do the following: + + % cd $hlib + % su + % /etc/chown 0 alloc.e (4/15) + +------------------------------------------- +The bootstrap is now complete. The next step is to do a full system compile. + + + Attempted a "mkpkg >& spool &" from the root directory. Got compiler + failure in fio$; "Compiler error line 0 of (null): invalid flag + s...y...s...t...e...m...=" when trying to compile fowner.f. Also + got similar errors in fmtio$gstrcat.f and other places. No further + files from the original XC command line were compiled. Common + denominator was the length of the command line to the f77 compiler. + Made the following change: (4/15) + +unix/boot/mkpkg/host.c + Changed SZ_CMD from 512 to 400; this shortens the command line + that MKPKG constructs for XC. Rebuilt MKPKG with "sh -x mkpkg.csh". + (4/15) + + + Started another sysgen. Noticed compiler errors on the following + files; let the sysgen continue while fixing them. + + sys/fmtio/gctod.f + sys/fmtio/xtoc.f + These routines had to be hand-compiled without switch "-f68881". + Made copies of the fortran in local/bugs, and hand-compiled + each routine in its own directory. Something to do with complex + numbers? Since it didn't look like they affected anything else, + just did a "mkpkg" to load them back into libsys and let the + sysgen continue. (4/15) + + sys/vops/ak/abeqkx.f + sys/vops/ak/abeqx.f + sys/vops/ak/abgekx.f + sys/vops/ak/abgtkx.f + sys/vops/ak/ablekx.f + sys/vops/ak/abltkx.f + sys/vops/ak/abnekx.f + sys/vops/ak/abnex.f + sys/vops/ak/advzx.f + sys/vops/lz/allnx.f + sys/vops/lz/alogx.f + sys/vops/lz/arcpx.f + sys/vops/lz/arczx.f + Same with these routines; again, all contained complex datatypes. + Hand-compiled, then a "mkpkg" from vops. (4/16) + +unix/hlib/mkpkg.inc + Changed LFLAGS from "" to "-f68881" to get pick up the references + generated by the same switch during default compilation. This may + cause a problem with those files hand-compiled without this switch + due to compiler errors. (4/16) + +pkg/dataio/reblock/t_reblock.x line 56 +pkg/dataio/cardimage/t_wcardimage.x 39 +pkg/images/imutil/imdelete.x 43 +pkg/onedspec/t_widstape.x 65 +pkg/plot/gkiextract.x 99 +pkg/utilities/t_translit.x 41, 68 +pkg/imred/vtel/dicoplot.x 324 +pkg/imred/vtel/tcopy.x 59 +pkg/imred/vtel/vtfix.x 60 +pkg/imred/vtel/writevt.x 42 + All these lines tested a boolean conditional against "true" or "false". + The Sun-3 f77 compiler refused to compile these; all were changed to + just the name of the boolean or !boolean as appropriate. + This was only done on the Sun, since this is an experimental version; + mail will be sent on lyra. (4/16) + +pkg/images/tv/display/iisers.x + No change made, since there is no need for this code on the Sun, + and it looked like there were non-obvious consequences in other + routines for changing either the values or changing shorts to ints. + However, note should be taken on lyra that "erase" is a short integer, + and it is being assigned to ERASE (in one of the local include + files), which has the value "32768" -- too high by one, apparently. + +pkg/images/tv/cv/iism70/iiscursor.x +pkg/images/tv/cv/iism70/zclear.x + Also no change made, but similar problem: the include file + definitions IREAD (100000B) and ERASE (32768) are being used + in assignments to short integers, in one case "32768+256". (4/16) + +unix/boot/spp/xc.c + Added references for the standard Fortran libraries -lI77 and -lU77, + plus a reference to the temporary library $hlib/libk.a, which contains + several routines referenced by the Fortran compiler, but not provided + in any SUN library. See below. (4/25) + +unix/hlib/SUN_kludge/ + This a temporary directory added to build the kludge library libk.a + so that IRAF programs can be linked on the SUN-3. Source for the + following routines were added: + + Fc_eq compare complex numbers for equality + Fc_conv_h convert complex to short + Fh_conv_c convert short to complex + + The conversion routines appear to have been overlooked by SUN, and + should be added to /usr/lib/libF77.a. (4/25) + +unix/mkpkg.csh + Added a line to compile the kludge library during the bootstrap. (4/25) + +unix/hlib/mkpkg.inc + Added the flag "-f68881" to LFLAGS (the linker flags). This is + necessary to get the linker to reference /lib/Mcrt1.o rather than + /lib/Fcrt1.o. If this is not done and one attempts to link code + compiled with the -f68881 switch, an unresolved reference to + the external "f68881_used" will result. (4/25) + +sys/osb/miiupk16.x +sys/osb/miiupk32.x + Replaced by the new versions from lyra, which fix the BYTE_SWAP + bug. (4/25) + +sys/gio/nspp/portlib/flush.f +sys/gio/nspp/portlib/flash[13].f +sys/gio/nsppkern/gktcancel.f +sys/gio/nsppkern/gktclear.f +sys/gio/nsppkern/gktclose.f +sys/gio/ncarutil/sysint/spps.f + Changed the name of the NSPP routine "flush" to "mcflsh" to avoid + a library conflict with the Fortran FLUSH. (4/25) + +pkg/images/tv/display/iisers.x +pkg/images/tv/cv/iism70/iiscursor.x +pkg/images/tv/cv/iism70/zclear.x + All these files produced a compiler bug due to a compile time + assignment of an unsigned short integer number 1XXXXX into a + short variable. Had to change these to run time assignments to + get the desired truncation assignment. (4/25) + +local/.login +local/login.cl + Aliased XC to 'xc -f68881' since all floating point is handled that + way on this machine. (4/25) + +unix/hlib/libc/finfo.h + The fi_owner field of the finfo structure was not dimensioned + properly, causing the storage allocated for the structure to be + overrun. This was found in a call to pfileopen/filetime in the + CL; the finfo structure is allocated space on the stack, hence the + stack was being corrupted. This was a fairly serious bug which has + been in the system for a long time. (4/25) + +[[ The system is now up (4/25) ]] + +dev/pix +dev/pix.pix + Moved the test image over from lyra: + + wfits dev$pix /u2/tody/pix.fits (on VAX lyra) + rfits lyra!/u2/tody/pix.fits (on SUN) + + We ought to add a dev$pix.fits file so that the test image is + available on source only archives. (4/25) diff --git a/doc/ports/sun3_062486.doc b/doc/ports/sun3_062486.doc new file mode 100644 index 00000000..16a1107e --- /dev/null +++ b/doc/ports/sun3_062486.doc @@ -0,0 +1,202 @@ +SUN/IRAF V2.3 Installation, 12 June 1986 Sun-3, MC68881 floating point +------------------------------------------------------------------------------ + +/usr/iraf/local/notes + Began this new notes file. All subsequent pathnames assume + "/usr/iraf/" preceding them. (6/12) + +unix/ + Made a tar backup in /tmp2/iraf/tuc_unix.arc. (6/12) + +local/ + Made a tar backup in /tmp2/iraf/tuc_local.arc. (6/12) + +bin/ +lib/ +pkg/ +sys/ +unix/ + Ran rmbin to remove all binary files. (6/12) + +/usr/iraf/ + Unpacked new "wtar -o" source-only archive from lyra. (6/12) + +unix/as/ +unix/mc68000 + Replaced VAX contents of as/ with those from mc68000; renamed + .SUN's to .s's. (6/12) + +unix/mkpkg.csh + Replaced with the one from the archive; contains SUN_kludge + mkpkg.csh command. (6/12) + +unix/hlib/[dir]1mach.f + Replaced with those from archive for 68000; using MC68000 + versions of machine-independent stuff for nspp software. (6/12) + +unix/hlib/mach.h + Compared with archive and replaced with archive version to pick + up BYTE_SWAP[24] = NO, and to use the 68000 fp epsilons. (6/12) + +unix/hlib/motd + Short message about SUN/IRAF system testing. (6/12) + +unix/hlib/mkpkg.inc + Ran diff; replaced from archive to pick up 68000 compiler + and linker switches for this SUN-3, which has MC 68881 floating + point (XFLAGS -c -O -f68881; LFLAGS -f68881). Set USE_CALCOMP + to NO. (6/12) + +unix/hlib/mkiraf.csh + Replaced iraf root definition. (6/12) + +unix/hlib/libc/iraf.h + Changed root directory to /usr/iraf/, added "#define SUN3". (6/12) + +unix/hlib/libc/kernel.h + Commented out DEBUGMEM so that the normal UNIX malloc() is + used. This was and probably still is necessary in order to + link with SUNCGI. (6/12) + +unix/hlib/libc/spp.h + Ran diff; replaced with archive version to pick up MC68000 + fp epsilons. (6/12) + +unix/boot/mkpkg/host.c + Changed SZ_CMD from 512 to 400 to get around SUN-3 f77 command- + line bug. (6/12) + +unix/boot/spp/xc.c + Ran diff; replaced with archive version to pick up all the + extra Fortran library definitions and command-line args. (6/12) + +unix/os/zxwhen.c + Ran diff; replaced with archive version to pick up Sun floating + point exception definitions. (6/12) + +local/notes + Renamed to notes.vax. (6/12) + +local/login.cl + Renamed root directory in "home"; aliased "xc" to "xc -f68881". (6/12) + +/usr/include/iraf.h -> $hlib/libc/iraf.h + Made sure this symbolic link existed. (6/12) + +unix/ [BOOTSTRAP] + Attempted bootstrap ("sh -x mkpkg.csh"). (6/12) + +unix/boot/bootlib/mkpkg.csh + This time the bootstrap failed because of the "unexpected end of + file" error and did NOT create libboot.a. Resolved by inserting + "#! /bin/csh -f" as the first line. (6/13) + +unix/ [BOOTSTRAP] + Successful bootstrap this time. (6/13) + +unix/hlib/alloc.e + Changed ownership to root in order to allocate devices at runtime. + (6/13) + +/usr/bin/alloc -> $hlib/alloc.e +/usr/bin/generic -> $hlib/generic.e +/usr/bin/mkpkg -> $hlib/mkpkg.e +/usr/bin/rmbin -> $hlib/rmbin.e +/usr/bin/rmfiles -> $hlib/rmfiles.e +/usr/bin/rtar -> $hlib/rtar.e +/usr/bin/wtar -> $hlib/wtar.e +/usr/bin/xc -> $hlib/xc.e +/usr/bin/cl -> $hlib/cl.e + Made sure these symbolic links existed. (6/13) + +sys/fmtio/gctod.f F77 compile-time +sys/fmtio/xtoc.f F77 compile-time +sys/vops/ak/abeqkx.f F77 compile-time +sys/vops/ak/abeqx.f F77 compile-time +sys/vops/ak/abgekx.f F77 compile-time +sys/vops/ak/abgtkx.f F77 compile-time +sys/vops/ak/ablekx.f F77 compile-time +sys/vops/ak/abltkx.f F77 compile-time +sys/vops/ak/abnekx.f F77 compile-time +sys/vops/ak/abnex.f F77 compile-time +sys/vops/ak/advzx.f F77 compile-time +sys/vops/lz/allnx.f F77 compile-time +sys/vops/lz/alogx.f F77 compile-time +sys/vops/lz/arcpx.f F77 compile-time +sys/vops/lz/arczx.f F77 compile-time + Hand-compiled without "-f68881" switch (but with optimization); + otherwise the compiler fails due to complex datatype expressions. + This will be the case until the next Sun f77 release. (6/13) + +sys/fmtio/fprfmt.x F77 run-time + Hand-compiled without optimization (but with "-f68881"). Have not + yet determined source of problem (symptom was garbage appearing + in text files) -- pursue shortly. (6/13) + +$iraf + Started sysgen at 10:22. (6/13) + +dev/devices + Replaced with version from suntest!, since we now have a 1/2 inch + tape drive on tucana. Added mtb entry for the 1/4 inch drive. (6/13) + +noao$onedspec/getnimage.x F77 run-time + There is a bug in the optimizer which seems to be caused by a + logical comparison to MAX_INT. To get around the problem do the + following after a full sysgen. (6/19) + + touch getnimage.x; mkpkg xflags=-c fluxcal; mkpkg install + +$iraf + Unpacked an incremental archive from lyra to bring tucana up + to current as of 09:15 June 20, 1986. Performed an incremental + sysgen. (6/20) + +noao/twodspec/apextract/* + The preceding MKPKG found the entire contents of icfit/* missing + except for 3 source files. To be safe, I (sr) made a complete + archive of lyra!/...apextract/* and unpacked it here, followed + by another root sysgen. (6/20) + +noao/twodspec/apexold/* + Because this directory was created by renaming the directory + apextract after the full archive of June 12, it had old file + dates and the incremental archives this week didn't pick it + up. Unpacked a full archive and MKPKG'd. (6/20) + +sys/gio/cursor/grcwcs.x F77 run-time + Apparent f77 optimizer bug; hand-compiling w/o optimization + and relinking the CL clears up the problem of IMPLOT's "l" + and "c" commands returning bad pixel rows/columns. Before, + clgcur was sometimes returning the y coordinate in pixel, + rather than data, units -- i.e. in WCS 1 rather than 2. Haven't + had time to try to isolate the source of the optimizer bug. (6/21) + +$iraf + Unpacked an incremental archive from lyra! current to 14:40 June + 21; performed an incremental sysgen. (6/21) + +noao/mtlocal/r2df/r2df.com + The preceding sysgen died because this file was missing; it had + a date earlier than the incremental archive, so was missed. + Added it and rebuilt mtlocal. (6/21) + +$iraf + Unpacked an incremental archive from lyra! current to 08:15 June + 23; performed an incremental sysgen. (6/23) + +noao/lib/scr/* +noao/twodspec/apextract/* +noao/twodspec/apexold/* + Unpacked full, not incremental, archives from lyra! to pick up any + files missed during the incremental archives as a result of renaming + rather than copying files since the June 12 full archive. mkpkg + updates in both apextract directories. (6/23) + +pkg/cl/unop.c + Changed call to sscanf (sval, "%f", &rresult) in case OP_REAL to + sscanf (sval, "%lf", &rresult) because "rresult" is declared type + "double", and on the SUNs, sscanf was only writing into the first + four bytes of rresult, giving erroneous answers to REAL coercion, + as in "cl> =real(imgets.value)". Should be changed on master system + as well. (6/23) diff --git a/doc/ports/sun3_f77Obugs.doc b/doc/ports/sun3_f77Obugs.doc new file mode 100644 index 00000000..1f06a3e5 --- /dev/null +++ b/doc/ports/sun3_f77Obugs.doc @@ -0,0 +1,1666 @@ +# f77 source programs and corresponding assembler code generated with +# "f77 -S -O -f68881" that cause run-time failure, where the corresponding +# unoptimized code does not. +#=============================================================================== +# fprfmt.f: + integer function fprfmt (ival) + integer ival + logical ivalad + integer ctoi + integer stridx + integer*2 ch + integer*2 chrlwr + integer fd + integer ip + integer width + integer decpl + integer col + integer leftjy + integer radix + integer fmtste + integer ofilee + integer formar + integer*2 fillcr + integer*2 format(161 +1) + integer*2 obuf(1024+1) + integer sw0001 + common /fmtcom/ fd,ip,width,decpl,col,leftjy,radix,fmtste, ofilee, + *formar,fillcr,format,obuf + integer*2 st0001(17) + integer*2 st0002(35) + integer*2 st0003(1) + save + integer iyy + data (st0001(iyy),iyy= 1, 8) / 98, 99,100,101,102,103,104,109/ + data (st0001(iyy),iyy= 9,16) /111,114,115,116,117,119,120,122/ + data (st0001(iyy),iyy=17,17) / 0/ + data (st0002(iyy),iyy= 1, 8) / 87, 97,114,110,105,110,103, 58/ + data (st0002(iyy),iyy= 9,16) / 32, 85,110,107,110,111,119,110/ + data (st0002(iyy),iyy=17,24) / 32,102,111,114,109, 97,116, 32/ + data (st0002(iyy),iyy=25,32) /116,121,112,101, 32, 99,104, 97/ + data (st0002(iyy),iyy=33,35) /114, 10, 0/ + data st0003 / 0/ + sw0001=(fmtste) + goto 110 +120 continue + ivalad = .false. + goto 111 +130 continue + goto 2 +140 continue + goto 3 +150 continue + goto 4 +160 continue + goto 5 +170 continue + goto 6 +180 continue + goto 7 +110 continue + if (sw0001.lt.1.or.sw0001.gt.7) goto 111 + goto (120,130,140,150,160,170,180),sw0001 +111 continue + if (.not.(format(ip) .eq. 0 .or. format(ip) .ne. 37 )) goto 190 + width = (-999) + decpl = (-999) + formar = (-999) + fillcr = 32 + leftjy = 0 + fmtste = 1 + fprfmt = (1) + goto 100 +190 continue + ip = ip + 1 +191 continue + if (.not.(format(ip) .eq. 42 )) goto 200 + ip = ip + 1 + if (.not.(ivalad)) goto 210 + fmtste = 2 + fprfmt = (0 ) + goto 100 +210 continue +2 ivalad = .true. + if (.not.(ival .lt. 0)) goto 220 + leftjy = 1 + goto 221 +220 continue + leftjy = 0 +221 continue + fillcr = 32 + width = abs (ival) + goto 201 +200 continue + if (.not.(format(ip) .eq. 45)) goto 230 + leftjy = 1 + ip = ip + 1 + goto 231 +230 continue + leftjy = 0 +231 continue + fillcr = 32 + if (.not.(format(ip) .eq. 48)) goto 240 + if (.not.((format(ip+1).ge.48.and.format(ip+1).le.57) .or + * . format(ip+1) .eq. 42 )) goto 250 + fillcr = 48 + ip = ip + 1 + goto 251 +250 continue + fillcr = 32 +251 continue +240 continue + if (.not.(format(ip) .eq. 42 )) goto 260 + ip = ip + 1 + if (.not.(ivalad)) goto 270 + fmtste = 3 + fprfmt = (0 ) + goto 100 +270 continue +3 ivalad = .true. + if (.not.(ival .lt. 0)) goto 280 + leftjy = 1 + goto 281 +280 continue + leftjy = 0 +281 continue + width = abs (ival) + goto 261 +260 continue + if (.not.(ctoi (format, ip, width) .le. 0)) goto 290 + width = (-999) +290 continue +261 continue +201 continue + if (.not.(width .eq. 0)) goto 300 + width = (-999) +300 continue + if (.not.(format(ip) .eq. 46)) goto 310 + ip = ip + 1 + if (.not.(format(ip) .eq. 42 )) goto 320 + ip = ip + 1 + if (.not.(ivalad)) goto 330 + fmtste = 4 + fprfmt = (0 ) + goto 100 +330 continue +4 ivalad = .true. + decpl = ival + goto 321 +320 continue + if (.not.(ctoi (format, ip, decpl) .le. 0)) goto 340 + decpl = (-999) +340 continue +321 continue + goto 311 +310 continue + decpl = (-999) +311 continue + if (.not.(format(ip) .eq. 42 )) goto 350 + ip = ip + 1 + if (.not.(ivalad)) goto 360 + fmtste = 5 + fprfmt = (0 ) + goto 100 +360 continue +5 ivalad = .true. + formar = ival + goto 351 +350 continue + formar = format(ip) + ip = ip + 1 +351 continue + if (.not.((formar.ge.65.and.formar.le.90))) goto 370 + formar = (formar+97-65) +370 continue + ch = formar + if (.not.(stridx (ch, st0001) .le. 0)) goto 380 + call putlie (5, st0002) + call fmterr (st0003, format, ip-1) + formar = (-999) + goto 381 +380 continue + if (.not.(formar .eq. 114 )) goto 390 + ch = chrlwr (format(ip)) + ip = ip + 1 + if (.not.(ch .eq. 42 )) goto 400 + if (.not.(ivalad)) goto 410 + fmtste = 6 + fprfmt = (0 ) + goto 100 +410 continue +6 ivalad = .true. + radix = ival + goto 401 +400 continue + if (.not.((ch.ge.48.and.ch.le.57))) goto 420 + radix = (ch-48) + goto 421 +420 continue + if (.not.((ch.ge.97.and.ch.le.122))) goto 430 + radix = ch - 97 + 10 + goto 431 +430 continue + radix = 10 + ip = ip - 1 +431 continue +421 continue +401 continue + goto 391 +390 continue + if (.not.(formar .eq. 119 .or. formar .eq. 116 )) goto 440 + ivalad = .false. +440 continue +391 continue +381 continue + if (.not.(ivalad)) goto 450 + fmtste = 7 + fprfmt = (0 ) + goto 100 +450 continue +7 ivalad = .true. + fmtste = 1 + fprfmt = (1) + goto 100 +100 return + end +c leftjy left_justify +c fmterr fmt_err +c fmtste fmt_state +c ivalad ival_already_used +c fillcr fill_char +c putlie putline +c ofilee ofile_type +c formar format_char +#------------------------------------------------------------------------------- +# fprfmt.s: + .data + .data1 + .bss + .data + .globl _fprfmt_ + .comm _fmtcom_,2416 + .globl _ctoi_ + .globl _stridx_ + .globl _putlie_ + .globl _fmterr_ + .globl _chrlwr_ + .align 4 + .text +|#PROC# 07 + + .bss + .align 4 +VAR_SEG1: + .skip 10 + .data1 + .align 2 +L1D186: + .long 5 + LF1 = 228 + LS1 = 8432 + LFF1 = 208 + LSS1 = 0 + LP1 = 20 + .text + .globl _fprfmt_ +_fprfmt_: + link a6,#-228 + moveml #8432,sp@ + movl a6@(8),a5 + movl _fmtcom_+4,d4 + movl VAR_SEG1+4,d5 + cmpl #1,_fmtcom_+28 + jge L77020 + jra L77005 +L77007: + moveq #1,d5 + movl a5@,d7 + jge L77043 + movl d5,_fmtcom_+20 + jra L77044 +L77009: + moveq #1,d5 + movl a5@,d7 + jge L77078 + movl d5,_fmtcom_+20 + jra L77079 +L77011: + moveq #1,d5 + movl a5@,_fmtcom_+12 + jra L77109 +L77013: + moveq #1,d5 + movl a5@,d7 + jra L77118 +L77015: + moveq #1,d5 + movl a5@,_fmtcom_+24 + jra LY00019 +L77017: + moveq #1,d5 + jra LY00006 +L77018: + movl _fmtcom_+28,d0 + moveq #8,d7 + cmpl d7,d0 + bcc L77005 + addw d0,d0 + movw pc@(6,d0:w),d0 + jmp pc@(2,d0:w) +L1I1: + .word L77023-L1I1 + .word L77004-L1I1 + .word L77007-L1I1 + .word L77009-L1I1 + .word L77011-L1I1 + .word L77013-L1I1 + .word L77015-L1I1 + .word L77017-L1I1 + jra L77005 +L77020: + cmpl #7,_fmtcom_+28 + jle L77018 + jra L77005 +L77023: + jra L77005 +L77030: + addql #1,d4 + movl d4,d7 + lea _fmtcom_+40,a0 + movw a0@(0,d7:l:2),d0 + extl d0 + moveq #42,d6 + cmpl d6,d0 + jne L77035 + addql #1,d7 + movl d7,d4 + tstl d5 + jeq L77007 + moveq #2,d6 + jra LY00016 +L77024: + movl #-999,_fmtcom_+8 + movl #-999,_fmtcom_+12 + movl #-999,_fmtcom_+36 + movw #32,_fmtcom_+40 + clrl _fmtcom_+20 +LY00006: + moveq #1,d6 + moveq #1,d7 + jra LY00010 +L77129: + movl d4,_fmtcom_+4 + asll #1,d4 + addl #_fmtcom_+40,d4 + movl d4,sp@- + jbsr _chrlwr_ + addqw #4,sp + movl _fmtcom_+4,d4 + addql #1,d4 + extl d0 + movl d0,d7 + moveq #42,d6 + cmpl d6,d7 + jne L77136 + tstl d5 + jeq L77015 + moveq #6,d6 + jra LY00016 +L77136: + moveq #48,d6 + cmpl d6,d7 + jlt L77146 + moveq #57,d6 + cmpl d6,d7 + jgt L77146 + moveq #-48,d6 + addl d6,d7 + movl d7,_fmtcom_+24 + jra LY00019 +L77146: + moveq #97,d6 + cmpl d6,d7 + jlt L77152 + moveq #122,d6 + cmpl d6,d7 + jgt L77152 + moveq #-87,d6 + addl d6,d7 + movl d7,_fmtcom_+24 + jra LY00019 +L77152: + moveq #10,d7 + movl d7,_fmtcom_+24 + moveq #-1,d7 + addl d7,d4 + jra LY00019 +LY00020: + movl d4,_fmtcom_+4 + pea v.17 + pea L1D186 + jbsr _putlie_ + addqw #8,sp + movl _fmtcom_+4,d0 + moveq #-1,d7 + addl d7,d0 + movl d0,a6@(-20) + pea a6@(-20) + pea _fmtcom_+42 + pea v.18 + jbsr _fmterr_ + lea sp@(12),sp + movl _fmtcom_+4,d4 + movl #-999,_fmtcom_+36 +LY00019: + tstl d5 + jeq L77017 + moveq #7,d6 + jra LY00016 +L77110: + addql #1,d4 + tstl d5 + jeq L77013 + moveq #5,d6 + jra LY00016 +L77096: + addql #1,d7 + movl d7,d4 + tstl d5 + jeq L77011 + moveq #4,d6 +LY00016: + moveq #0,d7 +LY00010: + movl d7,d0 + movl d6,_fmtcom_+28 + movl d4,_fmtcom_+4 + movl d5,VAR_SEG1+4 + moveml a6@(-228),#8432 + unlk a6 + rts +L77004: + moveq #0,d5 +L77005: + lea _fmtcom_+40,a0 + movw a0@(0,d4:l:2),d0 + extl d0 + movl d0,d7 + jeq L77024 + moveq #37,d6 + cmpl d6,d7 + jeq L77030 + jra L77024 +L77035: + moveq #45,d4 + cmpl d4,d6 + jne L77052 + moveq #1,d6 + movl d6,_fmtcom_+20 + addql #1,d7 + jra L77053 +L77043: + clrl _fmtcom_+20 +L77044: + movw #32,_fmtcom_+40 + tstl d7 + jlt L77046 + jra LY00023 +L77088: + movl #-999,_fmtcom_+8 + jra L77091 +L77052: + clrl _fmtcom_+20 +L77053: + movw #32,_fmtcom_+40 + movl d7,d6 + asll #1,d6 + lea _fmtcom_+40,a0 + movw a0@(0,d6:l),d0 + extl d0 + moveq #48,d4 + cmpl d4,d0 + jne L77057 + lea _fmtcom_+42,a0 + movw a0@(0,d6:l),d0 + extl d0 + movl d0,d4 + moveq #48,d6 + cmpl d6,d4 + jlt L77061 + moveq #57,d6 + cmpl d6,d4 + jgt L77061 + jra L77058 +L77057: + lea _fmtcom_+40,a0 + movw a0@(0,d7:l:2),d0 + extl d0 + moveq #42,d6 + cmpl d6,d0 + jne L77070 + addql #1,d7 + movl d7,d4 + tstl d5 + jeq L77009 + moveq #3,d6 + jra LY00016 +L77065: + movw #32,_fmtcom_+40 + jra L77057 +L77058: + movw #48,_fmtcom_+40 + addql #1,d7 + jra L77057 +L77061: + moveq #42,d6 + cmpl d6,d4 + jne L77065 + jra L77058 +L77070: + movl d7,_fmtcom_+4 + movl d7,_fmtcom_+4 + pea _fmtcom_+8 + pea _fmtcom_+4 + pea _fmtcom_+42 + jbsr _ctoi_ + lea sp@(12),sp + moveq #0,d1 + tstl d0 + sle d1 + negb d1 + movl d1,a6@(-52) + movl _fmtcom_+4,d4 + tstl d1 + jeq LY00002 + movl #-999,_fmtcom_+8 + jra LY00002 +L77078: + clrl _fmtcom_+20 +L77079: + tstl d7 + jge LY00023 +L77046: + negl d7 +LY00023: + movl d7,_fmtcom_+8 +LY00002: + tstl _fmtcom_+8 + jeq L77088 +L77091: + lea _fmtcom_+40,a0 + movw a0@(0,d4:l:2),d0 + extl d0 + moveq #46,d7 + cmpl d7,d0 + jne L77105 + addql #1,d4 + movl d4,d7 + lea _fmtcom_+40,a0 + movw a0@(0,d7:l:2),d0 + extl d0 + moveq #42,d6 + cmpl d6,d0 + jeq L77096 + movl d7,_fmtcom_+4 + movl d7,_fmtcom_+4 + pea _fmtcom_+12 + pea _fmtcom_+4 + pea _fmtcom_+42 + jbsr _ctoi_ + lea sp@(12),sp + moveq #0,d1 + tstl d0 + sle d1 + negb d1 + movl d1,a6@(-48) + movl _fmtcom_+4,d4 + tstl d1 + jeq L77109 +L77105: + movl #-999,_fmtcom_+12 +L77109: + lea _fmtcom_+40,a0 + movw a0@(0,d4:l:2),d0 + extl d0 + movl d0,d6 + moveq #42,d7 + cmpl d7,d6 + jeq L77110 + movl d6,d7 + addql #1,d4 +L77118: + moveq #65,d6 + cmpl d6,d7 + jlt L77123 + moveq #90,d6 + cmpl d6,d7 + jgt L77123 + moveq #32,d6 + addl d6,d7 +L77123: + movw d7,VAR_SEG1+8 + movl d7,_fmtcom_+36 + movl d4,_fmtcom_+4 + pea v.16 + pea VAR_SEG1+8 + jbsr _stridx_ + addqw #8,sp + moveq #0,d1 + tstl d0 + sle d1 + negb d1 + movl d1,a6@(-44) + movl _fmtcom_+4,d4 + tstl d1 + jne LY00020 + cmpl #114,_fmtcom_+36 + jeq L77129 + cmpl #119,_fmtcom_+36 + jeq L77017 + cmpl #116,_fmtcom_+36 + jne LY00019 + jra L77017 + .globl f68881_used + .data1 + .align 4 +v.16: + .long 0x620063,0x640065 + .long 0x660067,0x68006d + .long 0x6f0072,0x730074 + .long 0x750077,0x78007a + .word 0x0 + .align 4 +v.17: + .long 0x570061,0x72006e + .long 0x69006e,0x67003a + .long 0x200055,0x6e006b + .long 0x6e006f,0x77006e + .long 0x200066,0x6f0072 + .long 0x6d0061,0x740020 + .long 0x740079,0x700065 + .long 0x200063,0x680061 + .long 0x72000a + .word 0x0 + .align 4 +v.18: + .skip 2 +#=============================================================================== +# ========================== +# FORTRAN for get_next_image +# ========================== + integer function getnee (infile, recors, nrecs, image, szname) + integer infile + integer nrecs + integer szname + integer recors(3,100) + integer*2 image(szname+1) + integer nextnm + integer stat + logical flag1 + logical flag2 + logical flag3 + integer*2 image0(63 +1) + integer clgfil + integer getney + integer xstrln + common /gnicom/ flag1, flag2 + integer*2 st0001(6) + save + data st0001 / 46, 37, 48, 52,100, 0/ + data flag3/.true./ + if (.not.(flag1 .or. flag3)) goto 110 + nextnm = -1 + call rstgey () +110 continue + if (.not.(nrecs .eq. 2147483647)) goto 120 + stat = clgfil (infile, image, szname) #<--- Never executed + goto 121 +120 continue + if (.not.(flag1)) goto 130 + stat = clgfil (infile, image0, szname) + if (.not.(stat .eq. -2)) goto 140 + getnee = (stat) + goto 100 +140 continue +130 continue + stat = getney (recors, nextnm) + if (.not.(stat .ne. -2)) goto 150 + call xstrcy(image0, image, szname) + call sprinf (image(xstrln(image)+1), szname, st0001) + call pargi (nextnm) +150 continue +121 continue + flag1 = .false. + flag3 = .false. + getnee = (stat) + goto 100 +100 return + end + +#==================================================================== +#Optimized assembly +#==================================================================== + +_getnee_+4: moveml d4/d5/d6/d7,sp@ + tstl _gnicom_ + beqs _getnee_+0x30 + bras _getnee_+0x20 +_getnee_+0x12: movl d7,d0 + moveml a6@(-0x50),d4/d5/d6/d7 + unlk a6 + rts + bras _getnee_+0x38 + moveq #-1,d6 + movl d6,ARR_SEG5+0x294 + jsr _rstgey_ + bras _getnee_+0x38 + tstl v.150+0x90 + bnes _getnee_+0x20 + movl a6@(8),d4 + movl a6@(0x18),d5 + movl a6@(0x14),d6 + movl a6@(0x10),a0 + cmpl #0x7fffffff,a0@ <-------- + beq _getnee_+0xd4 <-------- Causes return + tstl _gnicom_ + beqs _getnee_+0x76 + movl d5,sp@- + pea ARR_SEG5+0x298 + movl d4,sp@- + bsrl _clgfil_ + lea sp@(0xc),a7 + movl d0,d7 + moveq #-2,d4 + cmpl d4,d7 + beqs _getnee_+0x12 + pea ARR_SEG5+0x294 + movl a6@(0xc),sp@- + jsr _getney_ + addqw #8,sp + movl d0,d7 + moveq #-2,d4 + cmpl d4,d7 + beqs _getnee_+0xd4 + movl d5,sp@- + movl d6,sp@- + pea ARR_SEG5+0x298 + bsrl _xstrcy_ + lea sp@(0xc),a7 + pea v.150+0x84 + movl d5,sp@- + movl d6,sp@- + bsrl _xstrln_ + addqw #4,sp + asll #1,d0 + addl d6,d0 + movl d0,sp@- + bsrl _sprinf_ + lea sp@(0xc),a7 + pea ARR_SEG5+0x294 + bsrl _pargi_ + addqw #4,sp +_getnee_+0xd4: clrl _gnicom_ + clrl v.150+0x90 + bra _getnee_+0x12 + +_resete_: linkw a6,#0 + movl #1,_gnicom_ + unlk a6 + rts + +_addspc_: linkw a6,#-0xec + moveml d3/d4/d5/d6/d7/a3/a4/a5,sp@ + fmovex fp7,a6@(-0xcc) + moveq #0,d6 + movl a6@(0x14),a0 + movl a0@,a5 + tstl a5 + bnes _addspc_+0x8e + moveq #-1,d6 + bras _addspc_+0x8e + moveq #1,d4 + movl a4@,d7 + subl d4,d7 + tstl d7 + blt _addspc_+0xb4 + + +#=============================================================================== +# grcwcs.f: + subroutine grcscs (stream, sx, sy, wx, wy, wcs) + integer stream + real sx + real sy + real wx + real wy + integer wcs + logical Memb(1) + integer*2 Memc(1) + integer*2 Mems(1) + integer Memi(1) + integer*4 Meml(1) + real Memr(1) + double precision Memd(1) + complex Memx(1) + equivalence (Memb, Memc, Mems, Memi, Meml, Memr, Memd, Memx) + common /Mem/ Memd + integer w + integer tr + real mx + real my + real ct(2,4) + integer grcses + integer gtrint + save + tr = gtrint (stream) + call grcscc (sx, sy, mx, my) + if (.not.(memi(tr+16) .eq. 0)) goto 110 + wcs = grcses (tr, mx, my) + goto 111 +110 continue + wcs = memi(tr+16) +111 continue + w = ((tr)+154+(wcs)*11) + call grcsen (w, ct) + call grcnds (ct, mx, my, wx, wy) +100 return + end + subroutine grcsen (w, ct) + logical Memb(1) + integer*2 Memc(1) + integer*2 Mems(1) + integer Memi(1) + integer*4 Meml(1) + real Memr(1) + double precision Memd(1) + complex Memx(1) + equivalence (Memb, Memc, Mems, Memi, Meml, Memr, Memd, Memx) + common /Mem/ Memd + integer w + real ct(2,4) + real worign + real scale + real m1 + real m2 + real w1 + real w2 + integer transn + integer ax + real elogr + save + do 110 ax = 1, 2 + if (.not.(ax .eq. 1)) goto 120 + transn = memi(w+8) + w1 = memr(w) + w2 = memr(w+1) + m1 = memr(w+4) + m2 = memr(w+5) + goto 121 +120 continue + transn = memi(w+9) + w1 = memr(w+2) + w2 = memr(w+3) + m1 = memr(w+6) + m2 = memr(w+7) +121 continue + if (.not.(transn .eq. 0 )) goto 130 + worign = w1 + scale = (m2 - m1) / (w2 - w1) + goto 131 +130 continue + if (.not.(transn .eq. 1 .and. w1 .gt. 0 .and. w2 .gt. 0)) + * goto 140 + worign = log10 (w1) + scale = (m2 - m1) / (log10(w2) - worign) + goto 141 +140 continue + worign = elogr (w1) + scale = (m2 - m1) / (elogr(w2) - worign) +141 continue +131 continue + ct(ax,1) = transn + ct(ax,2) = scale + ct(ax,3) = worign + ct(ax,4) = m1 +110 continue +111 continue +100 return + end + subroutine grcwcc (ct, wx, wy, mx, my) + real wx + real wy + real mx + real my + real ct(2,4) + real v + integer transn + integer ax + real elogr + save + do 110 ax = 1, 2 + transn = nint (ct(ax,1)) + if (.not.(ax .eq. 1)) goto 120 + v = wx + goto 121 +120 continue + v = wy +121 continue + if (.not.(transn .eq. 0 )) goto 130 + goto 131 +130 continue + if (.not.(transn .eq. 1)) goto 140 + v = log10 (v) + goto 141 +140 continue + v = elogr (v) +141 continue +131 continue + v = ((v - ct(ax,3)) * ct(ax,2)) + ct(ax,4) + if (.not.(ax .eq. 1)) goto 150 + mx = v + goto 151 +150 continue + my = v +151 continue +110 continue +111 continue +100 return + end + subroutine grcnds (ct, mx, my, wx, wy) + real mx + real my + real wx + real wy + real ct(2,4) + real v + integer transn + integer ax + real aelogr + save + do 110 ax = 1, 2 + transn = nint (ct(ax,1)) + if (.not.(ax .eq. 1)) goto 120 + v = mx + goto 121 +120 continue + v = my +121 continue + v = ((v - ct(ax,4)) / ct(ax,2)) + ct(ax,3) + if (.not.(transn .eq. 0 )) goto 130 + goto 131 +130 continue + if (.not.(transn .eq. 1)) goto 140 + v = 10.0 ** v + goto 141 +140 continue + v = aelogr (v) +141 continue +131 continue + if (.not.(ax .eq. 1)) goto 150 + wx = v + goto 151 +150 continue + wy = v +151 continue +110 continue +111 continue +100 return + end + integer function grcses (tr, mx, my) + logical Memb(1) + integer*2 Memc(1) + integer*2 Mems(1) + integer Memi(1) + integer*4 Meml(1) + real Memr(1) + double precision Memd(1) + complex Memx(1) + equivalence (Memb, Memc, Mems, Memi, Meml, Memr, Memd, Memx) + common /Mem/ Memd + integer tr + real mx + real my + integer w + integer wcs + integer closes + real tol + real sx1 + real sx2 + real sy1 + real sy2 + real distae + real olddie + real xcen + real ycen + integer nin + integer in(16 ) + save + nin = 0 + closes = 1 + olddie = 1.0 + tol = (1.192e-7) * 10.0 + do 110 wcs = 1, 16 + w = ((tr)+154+(wcs)*11) + sx1 = memr(w+4) + sx2 = memr(w+5) + sy1 = memr(w+6) + sy2 = memr(w+7) + xcen = (sx1 + sx2) / 2.0 + ycen = (sy1 + sy2) / 2.0 + if (.not.(abs ((sx2-sx1) - 1.0) .lt. tol .and. abs ((sy2-sy1 + * ) - 1.0) .lt. tol)) goto 120 + goto 110 +120 continue + distae = ((mx - xcen) ** 2) + ((my - ycen) ** 2) + if (.not.(distae .le. olddie)) goto 130 + closes = wcs + olddie = distae +130 continue + if (.not.(mx .ge. sx1 .and. mx .le. sx2 .and. my .ge. sy1 . + * and. my .le. sy2)) goto 140 + nin = nin + 1 + in(nin) = wcs +140 continue +110 continue +111 continue + if (.not.(nin .eq. 1)) goto 150 + grcses = (in(1)) + goto 100 +150 continue + grcses = (closes) + goto 100 +100 return + end +c gtrint gtr_init +c grcses grc_selectwcs +c grcscs grc_scrtowcs +c olddie old_distance +c grcsen grc_settran +c transn transformation +c distae distance +c grcscc grc_scrtondc +c closes closest_wcs +c grcnds grc_ndctowcs +c grcwcc grc_wcstondc +c worign worigin +#------------------------------------------------------------------------------- +# grcwcs.s: + .data + .data1 + .bss + .data + .data1 + .bss + .data + .data1 + .bss + .data + .data1 + .bss + .data + .data1 + .bss + .data + .globl _grcscs_ + .comm _mem_,8 + .globl _gtrint_ + .globl _grcscc_ + .globl _grcses_ + .globl _grcsen_ + .globl _grcnds_ + .globl _elogr_ + .globl _grcwcc_ + .globl _i_nint + .globl _aelogr_ + .align 4 + .text +|#PROC# 07 + + .bss + .align 4 +VAR_SEG1: + .skip 16 + .bss + .align 4 +ARR_SEG1: + .skip 32 + LF1 = 20 + LS1 = 128 + LFF1 = 16 + LSS1 = 0 + LP1 = 28 + .text + .globl _grcscs_ +_grcscs_: + link a6,#-20 + movl d7,sp@ + movl a6@(8),sp@- + jbsr _gtrint_ + addqw #4,sp + movl d0,VAR_SEG1+4 + pea VAR_SEG1+12 + pea VAR_SEG1+8 + movl a6@(16),sp@- + movl a6@(12),sp@- + jbsr _grcscc_ + lea sp@(16),sp + movl VAR_SEG1+4,d0 + lea _mem_+60,a0 + movl a0@(0,d0:l:4),d7 + jne L77006 + pea VAR_SEG1+12 + pea VAR_SEG1+8 + pea VAR_SEG1+4 + jbsr _grcses_ + lea sp@(12),sp + movl a6@(28),a0 + movl d0,a0@ + jra L77007 +L77006: + movl a6@(28),a0 + movl d7,a0@ +L77007: + movl a6@(28),a0 + movl a0@,d0 + movl d0,d1 + addl d1,d1 + addl d1,d0 + asll #2,d1 + addl d1,d0 + movl VAR_SEG1+4,d1 + addl #154,d1 + addl d1,d0 + movl d0,VAR_SEG1 + pea ARR_SEG1 + pea VAR_SEG1 + jbsr _grcsen_ + addqw #8,sp + movl a6@(24),sp@- + movl a6@(20),sp@- + pea VAR_SEG1+12 + pea VAR_SEG1+8 + pea ARR_SEG1 + jbsr _grcnds_ + lea sp@(20),sp + movl a6@(-20),d7 + unlk a6 + rts +|#PROC# 07 + + .bss + .align 4 +VAR_SEG2: + .skip 32 + .data1 + .align 2 +L2D24: + .long 0 + .data1 + .align 2 +L2D22: + .long 0 + LF2 = 432 + LS2 = 15612 + LFF2 = 392 + LSS2 = 63 + LP2 = 12 + .text + .globl _grcsen_ +_grcsen_: + link a6,#-432 + moveml #15612,sp@ + fmovem #63,a6@(-392) + moveq #1,d7 + movl d7,VAR_SEG2+20 + movl a6@(12),d0 + moveq #20,d7 + addl d7,d0 + movl d0,a6@(-4) + movl a6@(12),d0 + moveq #12,d7 + addl d7,d0 + movl d0,a6@(-8) + movl a6@(12),d0 + addql #4,d0 + movl d0,a6@(-12) + movl a6@(12),d0 + moveq #-4,d7 + addl d7,d0 + movl d0,a6@(-16) + movl a6@(8),a0 + movl a0@,d7 + asll #2,d7 + movl #_mem_+16,d0 + addl d7,d0 + movl d0,a6@(-20) + movl #_mem_+12,d0 + addl d7,d0 + movl d0,a6@(-24) + movl #_mem_,d0 + addl d7,d0 + movl d0,a6@(-28) + movl #_mem_+-4,d0 + addl d7,d0 + movl d0,a6@(-32) + movl #_mem_+28,d0 + addl d7,d0 + movl d0,a6@(-36) + movl #_mem_+24,d0 + addl d7,d0 + movl d0,a6@(-40) + movl #_mem_+20,d2 + addl d7,d2 + movl #_mem_+8,d3 + addl d7,d3 + movl #_mem_+4,d4 + addl d7,d4 + movl #_mem_+32,d5 + addl d7,d5 + movl VAR_SEG2+20,d6 + asll #2,d6 + movl d6,a2 + addl a6@(-4),a2 + movl d6,a3 + addl a6@(-16),a3 + movl d6,a4 + addl a6@(-12),a4 + movl d6,d0 + addl a6@(-8),d0 + movl d0,a5 +L77011: + moveq #4,d7 + cmpl d7,d6 + jne L77015 + movl a6@(-36),a0 + movl a0@,d7 + movl a6@(-32),a0 + fmoves a0@,fp3 + movl a6@(-28),a0 + fmoves a0@,fp2 + movl a6@(-24),a0 + fmoves a0@,fp7 + movl a6@(-20),a0 + jra LY00000 +L77015: + movl d5,a0 + movl a0@,d7 + movl d4,a0 + fmoves a0@,fp3 + movl d3,a0 + fmoves a0@,fp2 + movl d2,a0 + fmoves a0@,fp7 + movl a6@(-40),a0 +LY00000: + fmoves a0@,fp5 + tstl d7 + jne L77020 + fmovex fp3,fp6 + fmovex fp5,fp0 + fsubx fp7,fp0 + fmovex fp2,fp1 + fsubx fp3,fp1 + jra LY00001 +L77020: + cmpl #1,d7 + jne L77027 + fcmps L2D24,fp3 + fjngt L77027 + fcmps L2D22,fp2 + fjngt L77027 + flog10x fp3,fp0 + fmovex fp0,fp6 + fmovex fp5,fp0 + fsubx fp7,fp0 + flog10x fp2,fp1 + fsubx fp6,fp1 +LY00001: + fdivx fp1,fp0 + fmovex fp0,fp4 +L77021: + fmovel d7,fp0 + fmoves fp0,a3@+ + fmoves fp4,a4@+ + fmoves fp6,a5@+ + fmoves fp7,a2@+ + addql #4,d6 + moveq #8,d7 + cmpl d7,d6 + jle L77011 + fmovem a6@(-392),#63 + moveml a6@(-432),#15612 + unlk a6 + rts +L77027: + fmoves fp3,VAR_SEG2+12 + pea VAR_SEG2+12 + jbsr _elogr_ + addqw #4,sp + fmoves d0,fp6 + fmoves fp2,VAR_SEG2+16 + pea VAR_SEG2+16 + jbsr _elogr_ + addqw #4,sp + fmoves d0,fp0 + fsubx fp6,fp0 + fsubx fp7,fp5 + fdivx fp0,fp5 + fmovex fp5,fp4 + jra L77021 +|#PROC# 07 + + .bss + .align 4 +VAR_SEG3: + .skip 12 + LF3 = 264 + LS3 = 15608 + LFF3 = 228 + LSS3 = 7 + LP3 = 12 + .text + .globl _grcwcc_ +_grcwcc_: + link a6,#-264 + moveml #15608,sp@ + fmovem #7,a6@(-228) + moveq #1,d7 + movl a6@(20),a2 + movl a6@(24),d3 + movl a6@(8),d6 + movl d6,d0 + moveq #20,d5 + addl d5,d0 + movl d0,a6@(-4) + movl d6,d0 + addql #4,d0 + movl d0,a6@(-8) + movl d6,d0 + moveq #12,d5 + addl d5,d0 + movl d0,a6@(-12) + movl a6@(12),a0 + fmoves a0@,fp5 + movl a6@(16),a0 + fmoves a0@,fp6 + moveq #-4,d5 + addl d5,d6 + movl d6,a6@(-24) + asll #2,d7 + movl d7,a3 + addl a6@(-4),a3 + movl d7,d4 + addl d6,d4 + movl d7,a4 + addl d0,a4 + movl d7,a5 + addl a6@(-8),a5 +L77034: + movl d4,sp@- + jbsr _i_nint + addqw #4,sp + movl d0,d6 + moveq #0,d0 + moveq #4,d5 + cmpl d5,d7 + seq d0 + negb d0 + movl d0,d5 + jeq L77038 + fmovex fp5,fp7 + jra L77039 +L77038: + fmovex fp6,fp7 +L77039: + tstl d6 + jeq LY00002 + cmpl #1,d6 + jne L77048 + flog10x fp7,fp0 + fmovex fp0,fp7 + jra LY00002 +L77050: + fmoves fp7,a2@ + jra L85 +L77048: + fmoves fp7,VAR_SEG3 + pea VAR_SEG3 + jbsr _elogr_ + addqw #4,sp + fmoves d0,fp7 +LY00002: + fsubs a4@,fp7 + fmuls a5@,fp7 + fadds a3@,fp7 + tstl d5 + jne L77050 + movl d3,a0 + fmoves fp7,a0@ +L85: + addql #4,d7 + addqw #4,a5 + addqw #4,a4 + addql #4,d4 + addqw #4,a3 + moveq #8,d6 + cmpl d6,d7 + jle L77034 + fmovem a6@(-228),#7 + moveml a6@(-264),#15608 + unlk a6 + rts +|#PROC# 07 + + .bss + .align 4 +VAR_SEG4: + .skip 12 + LF4 = 264 + LS4 = 15608 + LFF4 = 228 + LSS4 = 7 + LP4 = 12 + .text + .globl _grcnds_ +_grcnds_: + link a6,#-264 + moveml #15608,sp@ + fmovem #7,a6@(-228) + moveq #1,d7 + movl a6@(20),a2 + movl a6@(24),d3 + movl a6@(8),d6 + movl d6,d0 + moveq #12,d5 + addl d5,d0 + movl d0,a6@(-4) + movl d6,d0 + addql #4,d0 + movl d0,a6@(-8) + movl d6,d0 + moveq #20,d5 + addl d5,d0 + movl d0,a6@(-12) + movl a6@(12),a0 + fmoves a0@,fp5 + movl a6@(16),a0 + fmoves a0@,fp6 + moveq #-4,d5 + addl d5,d6 + movl d6,a6@(-24) + asll #2,d7 + movl d7,a3 + addl a6@(-4),a3 + movl d7,d4 + addl d6,d4 + movl d7,a4 + addl d0,a4 + movl d7,a5 + addl a6@(-8),a5 +L77060: + movl d4,sp@- + jbsr _i_nint + addqw #4,sp + movl d0,d6 + moveq #0,d0 + moveq #4,d5 + cmpl d5,d7 + seq d0 + negb d0 + movl d0,d5 + jeq L77064 + fmovex fp5,fp7 + jra L77065 +L77064: + fmovex fp6,fp7 +L77065: + fsubs a4@,fp7 + fdivs a5@,fp7 + fadds a3@,fp7 + tstl d6 + jeq LY00004 + cmpl #1,d6 + jne L77074 + ftentoxx fp7,fp0 + fmovex fp0,fp7 + jra LY00004 +L77076: + fmoves fp7,a2@ + jra L121 +L77074: + fmoves fp7,VAR_SEG4 + pea VAR_SEG4 + jbsr _aelogr_ + addqw #4,sp + fmoves d0,fp7 +LY00004: + tstl d5 + jne L77076 + movl d3,a0 + fmoves fp7,a0@ +L121: + addql #4,d7 + addqw #4,a5 + addqw #4,a4 + addql #4,d4 + addqw #4,a3 + moveq #8,d6 + cmpl d6,d7 + jle L77060 + fmovem a6@(-228),#7 + moveml a6@(-264),#15608 + unlk a6 + rts +|#PROC# 07 + + .bss + .align 4 +VAR_SEG5: + .skip 52 + .bss + .align 4 +ARR_SEG5: + .skip 64 + .data1 + .align 2 +L5D70: + .single 0r1.00000000000000000e+00 + .data1 + .align 2 +L5D68: + .single 0r1.00000000000000000e+01 + .data1 + .align 2 +L5D67: + .single 0r1.19200000000000000e-07 + .data1 + .align 2 +L5D49: + .single 0r2.00000000000000000e+00 + .data1 + .align 2 +L5D41: + .single 0r-1.00000000000000000e+00 + LF5 = 356 + LS5 = 8444 + LFF5 = 328 + LSS5 = 63 + LP5 = 8 + .text + .globl _grcses_ +_grcses_: + link a6,#-356 + moveml #8444,sp@ + fmovem #63,a6@(-328) + moveq #0,d3 + moveq #1,d2 + movl L5D70,VAR_SEG5+4 + fmoves L5D68,fp0 + fmuls L5D67,fp0 + fmoves fp0,VAR_SEG5+40 + moveq #1,d6 + movl a6@(16),a0 + movl a0@,a6@(-60) + movl a6@(12),a0 + fmoves a0@,fp2 + movl a6@(8),a0 + movl a0@,d0 + addl #154,d0 + movl d0,a6@(-36) + movl d3,d0 + asll #2,d0 + movl d6,d5 + movl d5,d1 + addl d1,d1 + addl d1,d5 + asll #2,d1 + addl d1,d5 + addl #ARR_SEG5+-4,d0 + movl d0,a5 + movl d5,d4 + addl a6@(-36),d4 + jra L77087 +LY00009: + moveq #1,d7 + cmpl d7,d3 + jne L77108 + movl ARR_SEG5,d7 +LY00008: + movl d7,d0 + fmovem a6@(-328),#63 + moveml a6@(-356),#8444 + unlk a6 + rts +LY00006: + addql #1,d6 + moveq #11,d7 + addl d7,d5 + addl d7,d4 + cmpl #176,d5 + jgt LY00009 +L77087: + movl d4,d7 + asll #2,d7 + lea _mem_+12,a0 + fmoves a0@(0,d7:l),fp6 + lea _mem_+16,a0 + fmoves a0@(0,d7:l),fp4 + lea _mem_+20,a0 + fmoves a0@(0,d7:l),fp5 + lea _mem_+24,a0 + fmoves a0@(0,d7:l),fp3 + fmovex fp6,fp0 + faddx fp4,fp0 + fdivs L5D49,fp0 + fmoves fp0,VAR_SEG5+28 + fmovex fp5,fp0 + faddx fp3,fp0 + fdivs L5D49,fp0 + fmoves fp0,VAR_SEG5+32 + fmovex fp4,fp7 + fsubx fp6,fp7 + fadds L5D41,fp7 + fabsx fp7,fp0 + fcmps VAR_SEG5+40,fp0 + fjnlt L77092 + fmovex fp3,fp7 + fsubx fp5,fp7 + fadds L5D41,fp7 + fabsx fp7,fp0 + fcmps VAR_SEG5+40,fp0 + fjlt LY00006 +L77092: + fmovex fp2,fp7 + fsubs VAR_SEG5+28,fp7 + fmoves fp7,a6@(-20) + fmoves a6@(-60),fp7 + fsubs VAR_SEG5+32,fp7 + fmoves fp7,a6@(-24) + fmoves a6@(-20),fp7 + fmulx fp7,fp7 + fmoves a6@(-24),fp1 + fmulx fp1,fp1 + faddx fp1,fp7 + fcmps VAR_SEG5+4,fp7 + fjnle L77096 + movl d6,d2 + fmoves fp7,VAR_SEG5+4 +L77096: + fcmpx fp6,fp2 + fjnge LY00006 + fcmpx fp4,fp2 + fjnle LY00006 + fcmps a6@(-60),fp5 + fjnle LY00006 + fcmps a6@(-60),fp3 + fjnge LY00006 + addql #1,d3 + addqw #4,a5 + movl d6,a5@ + jra LY00006 +L77108: + movl d2,d7 + jra LY00008 + .globl f68881_used + .data1 +#=============================================================================== diff --git a/doc/ports/sun4_sep87.doc b/doc/ports/sun4_sep87.doc new file mode 100644 index 00000000..e10f5232 --- /dev/null +++ b/doc/ports/sun4_sep87.doc @@ -0,0 +1,296 @@ +Begin port of Sun/IRAF to the Sun-4 (RISC/sparc cpu). +Beginning Saturday, 26 Sep 1987 (dct). +========================================= + +V2.5 release was installed on the disk at /usr/iraf and stripped of all m68x +binaries, by Skip before I started. + +/etc/termcap +/usr/local/* + +/local -> /usr/local + + The first step was to add some local utilities to the standard Sun + release. Added entries for terminals sun{24,34,40,54},unixpc to the + termcap (unixpc is so I can work from home). Added a bunch of stuff + in local, e.g., less, egrep, top, sps, mon, a modified 'man' which + uses less, etc. (9/26) + +cd $iraf/unix +sh -x mkpkg.sh >& spool & + Did a trial bootstrap just to see what would fail. The only files + giving problems were, as expected, as$zsvjmp.s and os$zxwhen.c. (9/26) + +unix/os/zxwhen.c + Replaced the entire hardware exception initialization list by a + version which will work on any sun (680XX or sparc) or a Vax. (9/26) + +unix/hlib/libc/iraf.h + Deleted the BSD42 and BSD43 entries, which were never used. Replaced + with BSDUNIX (which has still not been used but will be, along with + a SYSVUNIX or some such). In zxwhen.c, the #ifdefs use the system + type names defined by the C compiler, e.g., vax, sparc, m68k, etc. + (9/26) + +bin +bin.sparc + +bin.ffpa - +bin.f68881 - + Deleted the .ffpa and .f68881 binaries for this host, and added a + bin.sparc directory for the sparc binaries. Set bin to point to this. + (9/26) + +unix/mkpkg.sh +unix/as -> unix/as.`mach` +unix/as.vax +unix/as.sparc + +unix/as.mc68020 + + The different assemblers are quite incompatible, even on a Sun. + To make it possible to maintain sources for all Suns in one Sun/IRAF + source, I set up as.XX directories for the assembler sources for + each main hardware type, and made as a symbolic link to the particular + version in use. The value of as is set automatically by mkpkg.sh + during a bootstrap. Note that this does not necessarily work when + using a single source to maintain multiple versions of the system; + I will wait and resolve that later. (9/26) + +unix/as.sparc/zsvjmp.s + Wrote a zsvjmp/zdojmp for the sparc architecture. This was not + difficult, except for the time required to figure out the machine + architecture and assembler, which is not very well documented in the + gamma release of the SunOS for the Sun-4. (9/26-27) + +cd $iraf/unix +sh -x mkpkg.sh >& spool & + Did a real bootstrap, this time it completed with no errors. (9/27) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf + In mkpkg.inc, set the FPU option to 'sparc'. Added some $ifeq code + to set the XFLAGS,LFLAGS,XVFLAGS different for sparc than anything + else, since no -/fparc is tolerated on the commands to the compiler + programs. In the mkpkg.sf, deleted all the old special file entries + having to do with compiler bugs, since we have a completely new set + of compilers to deal with on this machine (they really are very + different, especially in the optimization and code generation). (9/27) + +local/.login + Commented out the code which sets FLOAT_OPTION, since the compilers + give errors if this is set to 'sparc', even on a sparc cpu (this is + inconsistent). (9/27) + +unix/hlib/cl.csh + Added support for machine type 'sparc'. (9/27) + +cd $iraf +mkpkg >& spool & + Tried to do a sysgen of the full system. This died on the very first + file, with rpp.e going into an infinite loop. This was traced to an + optimizer bug in rpp.e, see below. (9/27) + +unix/boot/spp/rpp/mkpkg.sh + Added some code to compile rpp/rppfor/outch.f without optimization, + to work around an optimizer bug which would cause an infinite loop. + (9/27) + +cd $iraf +mkpkg >& spool & + Successfully started up a sysgen of the full system and went home + for the day. (9/27) + +unix/hlib/mkpkg.sf + When I checked the next day, the sysgen was hung in an infinite loop + in the optimizer (iropt), trying to compile pkg$lists/unique.x. + Added an entry with flags "-cq -P" to the special file list, allowing + the file to be compiled. Checking back over the spooled output, + I found that the only other file giving problems was pkg$cl/ytab.c, + which produced the following error message when compiled: + + Routine _yyparse too big: + use a lower level of optimization or + increase stack limit and / or + size of swap space + + compiler(iropt) error: alloca: out of memory + + This was due to the static control flow analysis perfomed by the + fancy new 3 level C code optimizer that comes with the Sun-4. + The yyparse routine (the parser) in the CL is a very large function, + and it is not surprising that it overflows something. In this case + the runtime data structures required for the static flow analysis + exceeded something like 10 Mb (!), causing the compiler to run out + of memory. Added the file to the special file list with the flags + "-cq -/O2" (the default -O gives -O3 or third level optimization). + (9/28) + +------------------- +With these changes, the sysgen completed normally. Some brief testing showed +that x_system.e would run stand alone, but the CL would die on a bus error. +Some interesting comparisons of object and executable sizes: + + BSD(11/750) Sun-3 Sun-4 + du -s bin 17345 16801 20593 + du -s lib 3234 2932 3787 + + Hence, it turns out that the binaries for the Sun-4 with its RISC cpu + are not that much larger than for the CISC machines, after all. + The slighly larger disk file size of the BSD VAX compared to the Sun-3 + was due to the symbol table in the (unstripped) executables being + larger for BSD than for the Sun. (9/28) + +sys/etc/envreset.x + The bus error in the CL turned out to be due to a short being passed + as an int in a procedure call in the above routine. It took me a + while to figure this out, due to the time required to learn to use + ADB on a RISC machine. Most of this was just becoming familiar with + the machine architecture, but it is a bit harder to match the + assembler up with the high level code on a RISC machine, due to the + many similar looking simple little instructions, and the heavy + optimization performed by the compiler. A lot of little ADB things + are different - the register set in the sparc architecture is like + nothing you have ever seen before, the pipelining is visible (the + instruction after a branch or function call is always executed + even if the branch is taken, and is shown AFTER the branch!), + the arguments to a procedure seem to be always passed in registers + (haven't tried any procedures with very long argument lists yet), + so on. One interesting discovery was that there are no MUL and DIV + instructions in the RISC cpu!. These are implemented as subroutines, + but seem to be pretty fast nonetheless (but about 6 times slower than + an add). (9/28) + + [With this change the CL now comes up fine, and all the little system + [things I tried work. zdojmp/zsvjmp are not working correctly in + [the CL, although they worked fine in a C test program I wrote, and + [they work fine in x_system.e run stand alone.] + +unix/hlib/libc/setjmp.h + Added a "#pragma unknown_control_flow", #ifdef-ed for the sparc. + This is necessary to tell the C optimizer that any routine which calls + setjmp (zsvjmp_) may trash the registers or do other strange things. + This was the cause of the zsvjmp failure in the CL (C) code. (9/29) + +dev/help.db + Rebuilt the help datbase - all is well. (9/29) + +---------------------------- +A little further testing immediately shows further problems, although a lot +of stuff is working correctly now. We still have a very buggy system here. +Did not get much time to work on this today. (9/29) + +pkg/cl/unop.c +pkg/cl/binop.c +pkg/cl/opcodes.c + The problem with the CL getting confused about whether certain files + existed or not turned out to be due to another IRAF bug, rather than + a Sun bug. The problem was the macro VALU(o) in the CL. This checks + the operand type and conditionally accesses and returns either the + integer or real value. This was being used to fetch the value of a + boolean operand, and it was natural for the code to assume that VALU + would return an integer value for a boolean operand. Not so, however. + The datatype of the conditional expression used in this macro is + evaluated at compile time, hence is double rather than int, and the + CL was doing boolean operations on double floating quantities. + + This has gone undetected up until now, but for some reason zero values + were testing not zero-floating on the sparc cpu. Integer 0 was being + loaded into a floating register, and the floating result after a + convert integer to double instruction was a very small floating point + number (exponent -212), with value exactly 0 when printing the binary + floating number in hex. Evidently binary zero is not the same as + floating zero on this cpu. (9/30) + +---------------------------- +Did a new sysgen to relink all executables to pick up bug fixes. +Things seem to be working pretty well now. Known problems: + + Contour dies on a segmentation violation every time, + and ERROR RECOVER IS NOT WORKING (the latter is true + on all systems I think, and must be due to a bug in + this program) + +local/sun +local/sun/Makefile + Deleted this code and replaced by the new (3.4) version from tucana. + Rebuilt suntools.e. This died on the first attempt due to a symbol + CPUTYPE=-mc68010 in the Makefile that came with the suntools code + from Sun, on the Sun-4! Modified the Makefile in local/sun to call + the suntool Makefile with CPUTYPE="", and suntools.e was built + successfully. (9/30) + +cd $hlib +install + Installed the custom suntools software. This has not yet been tested, + since I am working remotely. (9/30) + + +Begin IRAF Installation on ORION (NOAO/Tucson Sun-4) +SunOS Release Sys4BETA1 (ORION) #1: Fri Oct 23 13:09:29 PDT 1987 +---------------------------------------------------------------- + +Did a little UNIX level configuring, as orion only just came up: + Replaced termcap by tucana version. + Replaced /etc/group by tucana version. + Created /usr/local; someone else installed sources; I compiled and + installed sps, man, less, etc. + NOTE: the f77 compiler is back-ordered, so we nabbed the GAMMA + release compiler from hercules, until ours comes in. + +Created directory on /usr, read in V2.6 export version from lyra (same as + prepared for the Convex Port). + +Configured Sun-3 kernel from tucana for the Sun-4: + Made as a link to as.sparc. + Replaced mkpkg.inc and mkpkg.sf by the Sun-4 versions. + Uncommented #pragma in hlib/libc/setjmp.h. + Fixed a bug in boot/spp/rpp/mkpkg.sh (mach -> `mach`). + +Booted the system successfully. +Started a full sysgen and went home. (10/23) + +Examine spooled output from Sysgen (10/24): +-------------------------------------------- + +sys/fmtio/evexpr.x + Failed with the message: + f77: Fatal error in iropt: Segmentation fault (core dumped) + But it compiled just fine when I ran mkpkg on the directory. (??) + +noao/onedspec/sensfunc/mkpkg +noao/onedspec/sensfunc/sfgraphs.x + Deleted the junk file (zero length) sfgraphs.x, and its entry in + the mkpkg file list. (10/24) + +local/tasks + There was a problem here caused by my forgetting to delete the binaries + when I moved the Sun/IRAF version of local over from tucana. (10/24) + +local/sun/mksuntools.csh + Contained the statement "rm -rf *", used to delete the old 'suntool' + subdirectory before building a new one. If the directory already + happended to be empty, this would cause rm to return an error exit + status, causing the script to terminate prematurely. The suntools + executable would appear to be built correctly, but gterm and imtool + would not run. (10/24) + +unix/hlib/mkpkg.sf +unix/hlib/libc/setjmp.h + Had problems with register allocation again in the CL main, where + setjmp (ZSVJMP) is used. Unlike the case with the gamma release, + the #pragmas in <libc/setjmp.h> did not fix things this time, so I + had to add the affected files to the special file list to be + compiled with no optimization. (10/24) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.SUN3 +unix/hlib/mkpkg.sf.SUN4 + Replaced mkpkg.sf by two versions, one each for the Sun-3 and Sun-4. + The one to be used is conditionally loaded via a $ifeq statement in + the mkpkg.inc file. (10/24) + +local/sun/imtool.c + There is a bug in the C library SCANF routines: scanning a perfectly + legal input string with a format such as "%f%f%f..." results in the + scan terminating after processing only the first floating point number. + I had to rewrite a section of code in IMTOOL to use the lower level + ATOF conversion routine to read the wcs file. (10/25) + + [The above was due to us getting a BETA release of the OS, and went + [away when we got the GAMMA release.] diff --git a/doc/ports/sun_f77bugs.doc b/doc/ports/sun_f77bugs.doc new file mode 100644 index 00000000..e4a39469 --- /dev/null +++ b/doc/ports/sun_f77bugs.doc @@ -0,0 +1,15 @@ +Different problems were encountered in both Sun-2's and Sun-3's +with the f77 compiler. On the Sun-2, the problems were in the +optimizer. See the "sun2*.doc" files for documentation on which +IRAF source files generated compile-time and run-time problems. + +On the Sun-3, the worst problem was that Sun forgot about complex +datatypes after Sun V2.0. See the notes in the "sun3*.doc" files. +Sun still (June 24) has not solved the problem, but Doug Tody came +up with workarounds; look for the string "kludge" in "sun3_042586.doc" +and in the directory $iraf/unix/hlib/SUN_kludge/. + +There were also three IRAF source files that generated run-time +errors on the Sun-3 due to bugs in the "-f68881" version of the f77 +optimizer; these files are documented in "sun3_f77Obugs.doc". + diff --git a/doc/ports/unix.isi b/doc/ports/unix.isi new file mode 100644 index 00000000..a45b8c9c --- /dev/null +++ b/doc/ports/unix.isi @@ -0,0 +1,87 @@ +From rooke Thu Feb 27 11:35:41 1986 +Received: by lyra.noao.UUCP (4.12/4.7) + id AA06429; Thu, 27 Feb 86 11:35:35 mst +Date: Thu, 27 Feb 86 11:35:35 mst +From: rooke (Steve Rooke) +Message-Id: <8602271835.AA06429@lyra.noao.UUCP> +To: tody +Subject: Ebert's mail +Status: R + +>From ipac3!rick Wed Feb 26 19:35:54 1986 +Received: from noao.UUCP (carina) by lyra.noao.UUCP (4.12/4.7) + id AA03007; Wed, 26 Feb 86 19:35:50 mst +Received: by noao.UUCP (4.12/4.7) + id AA27537; Wed, 26 Feb 86 19:36:52 mst +Received: by ipac3.ARPA (4.12/4.7) + id AA10161; Wed, 26 Feb 86 18:32:49 pst +Date: Wed, 26 Feb 86 18:32:49 pst +From: ipac3!rick (Rick Ebert) +Message-Id: <8602270232.AA10161@ipac3.ARPA> +To: rooke@noao +Subject: IRAF @ IPAC [up] +Cc: noao\!tody +Status: RO + +Steve, + +The news is mostly good: IRAF is up at IPAC! The blessed event +occurred at 11:44:46 PST on 26 Feb. The new addition weighed in at +a little over 46Mb. + +All of our trouble seems to have been related to an obstinate fortran +optimizer. Once I figured out how to turn off that -O flag everywhere +in IRAF's mkpkg, it all fell into place. (As promised, a list of +files that gave our optimizer indigestion follows, but I'm convinced +the problem is with some northern California compiler writers and not +with IRAF.) + +I did run into a problem quite quickly though. I managed to make the +help data base by doing this: + +cl> softools +so> mkhelpdb + +IRAF proceeded to produce lots of stuff. +With many of the "help" requests that I tried the formatted manual +page printed on the screen as expected, followed by a listing of +what appeared to an unformatted copy of the same help file (there +were lots of .xx commands at the beginning of lines). Once this +starts to print out, a response of "n" to "More?" causes the whole +of iraf to crash. If I coax it with an interupt I receive the message, + +ERROR: subprocess is hung: process should be killed + +wait several seconds and interupt again, then I'm back in the csh +(this is probably our unix doing houskeeping). + +Not a very well documented bug, but I wanted to get it to you +right away. The "help" is all I have to learn IRAF! (Sob, poor me). + +Rick Ebert, Infrared Processing and Analysis Center (IPAC) +Cal Tech MS 100/22, Pasadena, CA 91125 + +Ma Bell: 818-584-2963 (MWF) +UUCP: ipac3!rick + +"Problem" files: + +./sys/fio/fwtacc.x +./pkg/system/help/helpdb.x +./pkg/system/help/prfile.x +./pkg/system/directory.x +./pkg/system/isdir.x +./pkg/onedspec/identify/isdir.x +./pkg/system/lprint.x +./pkg/system/page.x +./pkg/xtools/isdirectory.x +./pkg/dataio/imtext/rt_rwpix.x +./pkg/dataio/cyber/rrcopy/rc_rheader.x +./pkg/dataio/cyber/rrcopy/read_rcopy.x +./pkg/dataio/cyber/t_ridsfile.x +./pkg/dataio/cyber/read_dumpf.x +./pkg/dataio/cyber/read_pft.x +./pkg/images/geometry/geogmap.x +------that-is-all--------------------- + + diff --git a/doc/ports/vms_jan85.st b/doc/ports/vms_jan85.st new file mode 100644 index 00000000..3ad46793 --- /dev/null +++ b/doc/ports/vms_jan85.st @@ -0,0 +1,994 @@ +Notes file for VMS/IRAF V2.2 Installation +Beginning 16 January 1985 (code prepared on UNIX) +------------------------------------------------ + +vms/* + Moved unix/* to vms/*. (1/16) + +vms/os/* + Moved the current VMS kernel into host$os. (1/16) + +vms/os/mkpkg + Wrote mkpkg file for OS. (1/16) + +vms/as/*.s + Replaced all these assembler files by their VMS equivalents. Deleted + all the arithmetic VOPS machine files, as they are not worth it on + VMS (probably not worth it any more on UNIX, either). Wrote the new + routine ACLR.S for VMS. (1/17) + +vms/os/zsvjmp.s + Moved to AS. (1/17) + +vms/os/str.s + Added _strupk, _strpak, since the VMS kernel references these + internally, they need to be in LIBOS. Added the underscore to avoid + conflict with the OSB (C) versions used by the VOS. I know it seems + wasteful to duplicate essentially the same routine in different parts + of the system, but the subsystem interfaces must be respected. The + alternative is to add the routines to the kernel, but this involves + an expensive interface modification, and I don't think its worth it + for such trivial little routines. (1/17) + +vms/os/zfiotx.c +vms/os/zfioty.c +vms/os/zfrnam.c + Changed references to strpak, strupk to _strpak, _strupk. (1/17) + +vms/hlib/* + Set up the HLIB directory. This involved minor edits to config.h, + clpackage.cl, etc., and most of the .cl scripts therein. Moved in + all the .com files from the original "vms" directory from V2.0 of + VMS/IRAF. Added logical names for TMP and HOST to irafuser.com, + also logical names for MKPKG, RMBIN, etc. (1/18) + +vms/hlib/libc/iraf.h + Modified for VMS. The remaining files are now the same for both + UNIX/IRAF and VMS/IRAF. (1/18) + +vms/boot/bootlib/* + Minor changes for VMS. (1/19-20) + +vms/boot/generic/* + Minor changes for VMS. (1/20) + +vms/boot/mkpkg/* + Fairly extensive changes for VMS. Picked up the SCANLIB code from + the old VMS mkpkg; for the rest (mkpkg/host.c) I just modified the + new UNIX code as necessary for VMS. Still using the docvcl() stuff + to call XC, which is a kludge, but presumably it helps cut down on + process spawns. (1/20-21) + +vms/boot/mkpkg/scanlib.c,rec.c + Had second thoughts about this code. A full but null sysgen must be + incredibly slow on anything less than an 8600, since the old vms mklib + would physically open and read each file to map an object file name + into an object module name to get a date. Even on the 8600 it is + probably an order of magnitude slower than the new MKPKG on the UNIX + 750. Opening the source files with the C i/o can also change the file + modify dates, and the modify date is valuable information which I hate + to lose. + + To avoid this dreadful situation, I have decided to not use the VMS + librarian at all to track object module dates. Instead, for each + library there is an associated module date database file, e.g., + libsys.mlb for libsys.olb. This is updated by MKPKG when + objects are inserted into the library. If modules are replaced in + the library at the VMS level, MKPKG will simply recompile those + modules when eventually it is run (unless a utility program is run + to update the .mlb dates). But since the new MKPKG is such a screamer + anyhow, there is no need to use REPLACE.COM, or whatever, to update + modules in libraries - and the thing is dangerous anyhow (it is easy + to put the module in the wrong library, for example). + + This approach has the further advantage that the technique and the + code are both portable and can be reused on other systems that, like + VMS, do not manage libraries the way we would like. (1/21) + +vms/boot/rmbin +vms/boot/rtar +vms/boot/wtar + No changes for VMS, other than to replace the mkpkg.csh by a mkpkg.com. + (1/22) + +vms/boot/xyacc + Not supported on VMS. (1/22) + +vms/boot/spp/[...] + Some work was required here for VMS. The VMS version of RATLIBC was + picked up wholesale, but the UNIX versions of RATLIB[RF], RPPRAT, and + RPPFOR were used without change (these contain recent revisions which + were documented elsewhere). The VMS version of SPP.C was used (it + does more), but the UNIX versions XPPMAIN.C, XPPCODE.C, and DECL.c + were used, since they should be portable, now address all of the + issues dealt with in the VMS versions, and have recent revisions. + The VMS version of XC.C was used with very minor revisions. DCL.C + (the special ZOSCMD) was moved to BOOTLIB and hooked into os_cmd(). + + To summarize, the VMS versions of XC.C, RPP.C, and RATLIBC were used + with minor changes since they have been extensively modified for VMS. + The UNIX versions of the remaining files were used since they should + work for VMS, and it is desirable to minimize the differences between + the two versions to ease future merges. + + A DCL mkpkg.com was written for each directory under SPP. These are + for bootstrap purposes and will always recompile everything. It is + assumed that some version of LIBSYS and LIBVOPS is available for + filename mapping purposes. (1/22) + +vms/os/zfiomt.c + Removed the device table stuff, since the drive argument to ZZOPMT + is now the VMS device name. Density checking is performed at allocate + time by the VOS. It appears that the density is not being set + anywhere. (1/22) + +vms/os/zalloc.c + +vms/os/cltape.c - +vms/os/devtable.c - + Added the two new kernel routines ZDVALL and ZDVOWN, in the file + zalloc.c. They were easy to generate as the original cltape.c code + was quite well structured. Deleted the files cltape.c and devtable.c + since they are no longer used. (1/22) + +------------------------------------------- +That completes the coding modifications for VMS/IRAF, done on UNIX. +System moved to VMS for compile test beginning the 23rd. (1/22) + +(edited the mkpkg.coms, fixed compile time bugs, not worth recording here) + +vms/boot/generic/lexyy.c + Made the same changes for VMS as were made for the Lex/C output of + xpp.l. Should add editor script in UNIX version to make these + changes whenever lexyy.c is generated. (1/23) + +vms/os/zfnbrk.x +vms/os/zfxdir.x +vms/os/zfpath.x +vms/os/zfsubd.x + Replaced these SPP source files by equivalent C versions, to simplify + bootstrapping the system. It is just as easy to work on XCHAR arrays + in a C program as char arrays, hence there is no advantage to using + SPP for these routines. (1/23) + +TODO + Note - ZFNBRK differs from the UNIX version in that it ignores \ in + filenames (rather than interpreting them as directory delimiters). + Should merge back into UNIX version, too. (1/23) + +vms/boot/bootlib/osfn2vfn.c +vms/boot/bootlib/vfn2osfn.c + Added #undefs for fprintf, strcpy to cancel out the defines in libc.h. + (1/23) + +vms/hlib/libc/xnames.h +vms/hlib/libc/xnames.no_ + Added a define for VFNUNMAP. (1/23) + +vms/os/zzstrt.c +vms/hlib/libc/knames.h +vms/hlib/libc/knames.no_ + Discovered that the VMS kernel does not have the entry points _zstartup + and _zshutdown. These are used in programs that do not have a ZMAIN. + They are currently no-ops in both UNIX and VMS, but in general it sure + seems that they might be needed; the bootstrap utilities would not + link because the routines were missing. If we are going to have them + they should be Fortran callable too, so I changed the names to ZZSTRT + and ZZSTOP and added them to the VMS kernel (as no-ops). (1/23) + +vms/boot/* + Replaced all references to _zstartup and _zshutdown by references to + ZZSTRT and ZZSTOP. (1/23) + +vms/boot/rtar/rtar.c + Declared getblock() at the head of the file and deleted the local + definitions in each procedure. (1/23) + +vms/hlib/libc/xnames.h +vms/hlib/libc/xnames.no_ +vms/boot/bootlib/vfn2osfn.c +vms/boot/bootlib/envinit.c + Use of the VOS for filename mapping requires initialization of the + iraf environment table. VFN2OSFN will now initialize the env. table + the first time it is called, taking SET declarations from the + zzsetenv.def file in hlib. Added a define for ENVINIT to xnames.h + to initialize the env data structures; ENVPUTS is called to make + entries in the table. The bootlib init procedure is _envinit(). (1/23) + +vms/boot/bootlib/osfpathname.c + Added call to vfn2osfn() before call to ZFPATH. (1/23) + +vms/boot/bootlib/oschdir.c + Replaced call to os_fpathname() by call to ZFSUBD, since the former + produces an OS filename rather than an OS directory name, and VMS + insists on the latter. (1/23) + +vms/boot/hlib/libc/spp.h + Added a definition OSOK to spp.h. This is the value a foreign task + should return for normal successful completion, i.e., 0 for UNIX, + and 1 for VMS. (1/23) + +vms/boot/mkpkg/host.c +vms/boot/mkpkg/modlist.c +vms/boot/bootlib/*.c + Lots of changes to the system interface code to get MKPKG to work + properly on VMS. (1/23-24) + +vms/boot/bootlib/osdir.c + This code was rewritten to vfnopen the directory at diropen time + for efficiency reasons. Debugged the VOS filename mapping interface. + RMBIN was used to test the OSDIR code. (1/24) + +vms/boot/hlib/libc/libc.h + Added a #ifdef to turn off LIBC name redefinitions, for programs like + the bootstrap utilities which need to import_libc, but which want to + use the host system strcpy, printf, etc. (1/24) + +vms/boot/rtar.c +vms/os/zfiotx.c + I had a binary file on a supposedly text only tar tape. The file would + pass the ZFACSS test and appear to be a text file. RTAR would try to + use ZFIOTX to write the output file; the result was an access violation + in ZPUTTX, presumably because of the binary data. (1/24) + + [not yet resolved] + +vms/boot/rmbin [!!! NASTY BUG !!!] +vms/os/zfdele.c + Ran into an interesting problem with RMBIN. This task reads through + a directory, deleting any binary files found. The problem is that on + VMS, while the directory is open for reading, one cannot delete any + files in the directory because the directory file is locked. Not only + does this make RMBIN fail, it will also make a regular file delete, + create, rename, etc., fail, if the request is issued while another + process is reading from the directory!!! This means that bkg jobs + will mysteriously bomb out at random intervals on a file error. (1/24) + + [not yet resolved] + +sys/mkpkg + Added a $purge lib$ to the end of the sysgen section (after updating + all the system libraries). This will purge all the old versions of + the libraries after a sysgen. In the first attempt at a full sysgen + on the 24th, MKPKG went into a loop and filled up a disk, creating + 43 versions of each system library! (1/25) + +sys/mkpkg/pkg.c + The MKPKG loop mentioned earlier turned out to be due to a bug in the + VMS C stdio. FTELL returns the offset of the current record, rather + than the offset of the next record as the documentation states (and as + is necessary for UNIX compatibility). MKPKG would therefore repeat + the last command after pushing (ftell) and restoring (fseek) its state + to call a lower level module. This explains the problem, but does not + explain how it ever worked as well as it did in the first trial; we + may not know the whole story yet. + + No choice but to add an #ifdef vms to pop_context() in pkg.c to skip + forward one line after an FSEEK. (1/25) + +vms/os/net/kutil.c + Eliminated the reference to the macro define IRAFDIR, which has been + deleted. (1/25) + +vms/mkpkg + Added a call at the end to MKPKG to update LIBOS, since the bootstrap + does not get the networking stuff. (1/25) + +sys/libc/cfnames.c - + Deleted this file, which was apparently forgotten about after the + contents were unpacked into separate files. (1/25) + +vms/boot/mkpkg/pkg.c + As expected, the FTELL/FSEEK problem has not yet been resolved. After + running tests for several hours, most of which worked, I was unable to + isolate the problem. Simple little test programs always work correctly + (i.e., they always seek to the wrong line). I was able to determine + that when it fails it is because FTELL returns the wrong offset. It is + conceivable that MKPKG could be corrupting a stdio data structure, but + I doubt it. More likely there is a bug in the VMS FTELL. + + The next attempt at a workaround is to avoid the use of FTELL entirely + for VMS. Instead, I wrote a little package k_getc, k_fgets, k_ftell, + k_fseek. The getc counts characters, the ftell returns the char + offset, and the fseek rewinds the bloody file and reads so many + characters to get to the seek position. With this change, "mkpkg -n" + was able to traverse the system successfully. This code could be + useful on any system, so I will leave it in with a switch; there is + little effect on speed. (1/25) + +vms/os/zfiotx.c + It appears that the RTAR crash when writing binary data into a text + file was due to the lack of overflow checking in ZPUTTX. Added + overflow checking. (1/25) + +------------ +Started a full sysgen on 25 January. This ran to completion, uncovering the +usual assortment of compile time bugs not found on UNIX/IRAF. + +NOTE TO VMS/IRAF PROGRAMMERS + To relink a package executable for debugging on VMS, enter the + following command to relink with the "-x" flag: + + mkpkg lflags=-x + + For most packages, this will produce a debug version of x_test.e in + the local directory. The user package in the IRAF login.cl file + defines a foreign task "mkdebug" to make this easier: + + task $mkdebug = "$mkpkg lflags=-x" + + After debugging is complete, the following command will relink and + install a new executable: + + mkpkg update + + Alternatively, you can always type in a long "xc -x ..." command. + DCL .com files should not be used in the SYS or PKG directories. + +sys/mkpkg + Made compilation of libmain.o optional, under control of a switch in + hlib$mkpkg.inc. The VMS XC does not need a separate object module, + hence it is turned off for VMS. LIBMAIN is a prelinked object module + on UNIX, and will eventually be the sharable library on VMS, once we + figure out how to have MKPKG udpated during a sysgen. (1/26) + +vms/hlib/libcalcomp.a [SITE DEPENDENT] + Copied the VMS version of this library into HLIB. The source for the + library is local and is not part of IRAF. To link with this library, + one must reference the C runtime library CRTLIB.OLB in their login.com + file. Other sites may have a different version of the calcomp library, + or the Versaplot library, any of which will probably do as well for + the GIO calcomp kernel. (1/26) + +math/llsq/sva.for + On lines 179, 181, the comma at the end of the line was in column 73, + hence VMS/FORTRAN would ignore it. Moved to column 7 of the first + continuation line. (1/26) + +pkg/dataio/idsmtn/bswap6.c + Changed the [include "iraf.h"] to [include <iraf.h>]. (1/26) + +pkg/images/geometry/geotran.x + On line 531, changed a couple of '0's to '0.'s in calls to the intrinsic + function MAX (argument type mismatch). (1/26) + +pkg/local/mkpkg + Disabled the PERITEK code on VMS. This is a local, UNIX dependent pkg + (written by a staff astronomer) not intended for use outside of NOAO. + Will compile now only if site=noao and hostid=unix. (1/26) + +pkg/local/intrp.f + Near the end of file, contained a line that extended way beyond col 72. + Detabbed the file and made extra continuation for the long line. Has + already been updated on UNIX/IRAF (where I did the detab). (1/26) + +pkg/onedspec/identify/idpeak.x + Argument type mismatch in call to max(). (1/26) + +pkg/twodspec/longslit/transform/trtransform.x + Several array arguments were dimensioned using variables NX,NY defined + in COMMON. Changed to ARB to get it to compile (the original is not + legal Fortran), but passing the array dimensions via common is a more + serious problem. (1/26) + +pkg/utilities/t_polyfit.x +pkg/utilities/pfregres.f + + The polyfit task called the Bevington procedure REGRES which implicitly + called a function with the explicit external name FCTN. The source + for FCTN was provided with that for the polyfit task, but the VMS + librarian would store it in a separate library object module. Hence, + at link time REGRES causes a backwards reference to FCTN in the package + library, but since that library had already been searched the module + would not be found and the link would fail. + + This could be solved by moving FCTN into a separate object file not + in the package library, and linking it explicitly by name. Instead, + I copied the source for REGRES into the local file pfregres.f, and + added a reference to FCTN (renamed pf_fctn) in the pf_regres argument + list as an external. The real problem here is the Bevington library, + a simple instructional tool which was never intended to be used in an + application such as ours. Coupling to the outside world via a reserved + external name (FCTN) is as bad as common coupling. In both cases the + information should come into the procedure in an obvious way via the + argument list. (1/26) + + The new code should be tested. + +pkg/imred/vtel/readvt.x + Assignment to DO variable `subswath' within loop. Recoded to use a + FOR loop. (1/26) + +pkg/mkpkg + Added a "purge [...]" at the end, to be executed only on a vms host. + (1/26) + +------------- +(End of compile time bug fixes) +(All of the above files where also updated in UNIX/IRAF, so that the PKG +(sources are still identical in both systems). + + +pkg/cl/opcodes.c [+ globaldef] +pkg/cl/globals.c [+ globaldef] +pkg/cl/main.c [+2 globalref] + I was forced to add #ifdef vms globaldef, globalref nonsense to these + files to enable a standard XC call to link the CL. I suspect that + linking C data-only modules will be a problem on other systems as well; + in the future, we may want to outlaw data only modules in portable C + code. (1/26) + +(With this last fix, the new system is fully up and seems to be running +(fine, performing all basic functions normally). + +dev/devices + Edited for VMS. Decided to use the third field ("aliases" for UNIX) + to pass the density at device allocation time. For VMS it appears + the density must be set at ALLOCATE (mount) time. (1/26) + +vms/hlib/devstatus.cl + Edited for VMS. After printing the IRAF status (which is obtained + by a direct inquiry to VMS, not by just looking for a lock file), + devstatus will scan the device table dev$devices and do a + "!show devices/full device" to print the VMS info. (1/26) + +pkg/cl/scan.c + Would only skip blanks between the tokens; will now skip both spaces + and tabs. (1/26) + +vms/boot/spp/xc.c + Modified to actually create a shareable image with no traceback when + the -n flag is specified (it was a no-op before). Doesn't seem very + useful yet (the resultant image cannot be executed or installed), + but it will be useful for testing purposes. (1/26) + +vms/hlib/devstatus.cl + Added a boolean param verbose, default no, controlling whether the + SHOW DEV info is printed. Since the IRAF device status now comes + from VMS, we no longer need the VMS output, and it is a lot faster + without it. (1/26) + +vms/hlib/login.cl + Added a default NOAO USER package to the default login.cl. This serves + as a starter package for each user to modify as they wish. Each site + will wish to set up their own default package. (1/27) + +vms/os/open.c + Modified to provide shared access to files opened for reading, to + avoid the locked directory problem mentioned earlier. (1/27) + +sys/etc/syserr.x + In syserrs, added a check for overflow on the error message string. + These messages do not necessarily come from <syserrmsg>, and can be + quite long. (1/27) + +sys/ki/kiconnect.x + Added a call to ki_gethosts() if the node table has not yet been + read. There are circumstances (although unusual) in which ki_connect + can be called before the node table has been read, causing the system + to try to open the resource on the local node. (1/27) + +(All these bugs I am fixing have been in the system for some time, they +(are not new with this release...) + +vms/os/zmain.c +vms/os/zfiopr.c + Added support for monitoring IPC messages a run time, a useful tool + for debugging connected subprocesses. To enable logging of IPC + communications for a process, the programmer runs the VMS PATCH + facility to set the value of the global variable debug_ipc to 1. + The process must first be linked -x (or -M) to get the address of + the variable debug_ipc. + + cl> mkdebug + cl> adb x_test + DBG> ev debug_ipc + 1D58 + DBG> exit + cl> !patch x_pkg + PATCH> deposit 1d58=1 + PATCH> update + PATCH> exit + + This is similar to the way one does this on UNIX. (1/29) + +sys/fmtio/lexnum.x + Changed stk_ip[] from short to int. (1/29) + +pkg/cl/builtin.c + Changed two instances of + + flags != LT_PFILE; + to + flags &= ~LT_PFILE; (1/29) + +sys/clio/zfiocl.x + There was some confusion between bytes and chars here, causing the + numstr[..] = EOS to overwrite the static "xfer" string, resulting in + the command "x(3,2044)" being sent to the CL. This would cause + tasks which read from the standard input to fail. (1/29) + +pkg/system/help/t_help.x + Added , to the stridxs search for pattern metacharacters, so that + commands like "help taska,taskb" do not stop after printing only the + first task. (1/29) + +pkg/images/tv/display/imdopen.x +pkg/images/tv/cv/iism70/imdopen.x + Added an include <knet.h>. (1/29) + +vms/os/net/zfioks.c + Modified to not return a channel value of zero, which makes the KI + think the server has not been connected, even though it has. (1/29) + +Proposed Changes based on recent Installation Experiences +---------------------- +The following observations followed a trip to the Univ. of Wash. to install +IRAF and interface the display software to the model 75 IIS. This served +as a test case to refine our installation procedures before the release. + + - The quota requirements need to be better defined. In this case + the paging file quota was too small, and we had problems spawing + connected subprocesses. + - Make the [iraf.local] directory a standard thing, to hold all + local and VMS junk, e.g., login.com, test login.cl and uparm, + notes file, sysbull.dat, etc. etc. + - Replace IMAGEDISK by a definition of the default image storage + directory, which need not be a disk device. + - The symbol IRAF (used to load the logical names) collides with + the iraf system login IRAF. Mail cannot be sent to IRAF, it + has to be sent to _IRAF, which is confusing to the user. + Solution: use "IRAF" for the system login, [IRAF] for the + root directory, and IRAFDEFS for the symbol which used to be + called IRAF. + - Add a new subdirectory off the root called BIN, and install all + the executables there. Modify the CL to read the parameter + files from the source directories for the package, rather than + constraining the .par files to be in the same directory as the + executable. + - Add a utility to strip the system of all sources, objects, and + libraries not needed at runtime or for simple user software + development applications. All machines do not need to have + a full copy of the system with all sources. + - We need to include NSPP/MCVAX in the distribution, so that people + can get hardcopy on a Versatec or Printronix. + +(end of observations) +----------------------- + +vms/gdev/zfiogd.x + Broke iism70, iism75 into two separate cases, calling two separate + sets of interface procedures for each device. (2/5) + +vms/gdev/iism75/* + Added a new subdirectory IISM75 containing the interface procedures + for the Model 75 IIS. This device was interfaced without any changes + at all to the existing high level code, which was written for the + Model 70. Instead, the IISM75 procedures perform transformations on + the data stream to and from the physical device. M70 output + instructions are converted to M75 format, and M75 responses are + converted to M70 format. In effect, we have added software to convert + the model 75 back into a 70. This makes it possible for us to modify + the complex high level software and test in on the model 70, with a + reasonable expectation that it will still work on the 75 as well. (2/5) + +vms/gdev/iism70/m70io.f + The .for QIO interface procedures in gdev/iism70 are used for both + the model 70 and 75 (probably they should be moved into a separate + directory). The M70IO procedure would fail with the max transfer + size set to 32768 bytes. This was traced to the following expression + in a QIO call: + + %val(2*count) + + Here, `count' is a short integer variable. The result of the + expression is a long integer. The Fortran compiler would do the + multiplication with short integer arithmetic and then convert the + result to long integer, causing the unsigned integer result to overflow + into the sign bit, causing sign extension and an invalid QIO request + resulting in a cryptic insufficient working set message from VMS. + + The solution was to store count into a long integer temporary before + evaluating the expression. Applying the INT intrinsic function to + COUNT had no effect. Note also that one might assume that 2 is of + type "integer" and that the multiplication would be evaluated using + integer arithmetic, but that is not how this compiler does it. + + After this modification, the interface still failed, no doubt due + to the same problem elsewhere in the interface; I did not persue the + matter any further. I am documenting this carefully here because it + illustrates the danger of short integer arithmetic with the VMS + Fortran compiler, and anyone using such arithmetic must understand + in detail how such expressions are evaluated. Short integer arithmetic + was used in this particular application only because I cribbed the + QIO level interface routines from somewhere else, and they were + written to be compiled /I2. (2/5) + +pkg/images/tv/display/iisrcr.x + Added a 30 millisecond delay, so that cursor loop applications (e.g., + to window the display) do not hog the cpu polling the system in an + infinite loop. (2/5) + +dev/graphcap + Added an entry for the CIT-414a graphics terminal. (2/5) + +sys/tty/mkpkg +sys/tty/ttyclear.x +sys/tty/ttyclln.x +sys/tty/ttyctrl.x +sys/tty/ttydelay.x +sys/tty/ttygoto.x +sys/tty/ttyputs.x +sys/tty/ttywrite.x + In the process of developing a graphcap for the CIT-414a, I found + a problem with the TTY interface. The interface was set up to + operate upon EOS delimited control strings. This would prevent + inclusion of NULs in the control string (used to generate delays), + since the NUL would be interpreted as the EOS. A new routine TTYWRITE + was added, and TTYPUTS was modified to call STRLEN and then TTYWRITE. + The remaining routines were modified to call TTYWRITE rather than + TTYPUTS. I considered adding a notation to be used in control strings + to represent delays, but did not do so since the resultant TERMCAP + entries would no longer be compatible with UNIX TERMCAP. Instead, + one must explicitly include the nulls as \0\0\0 in the control strings. + (2/5) + +sys/gio/stdgraph/stdgraph.h +sys/gio/stdgraph/stgencode.x + Added a new operator !! to the stdgraph encoder, used to generate + millisecond delays by inserting NUL characters into the output text. + The delay in milliseconds is popped from the stack. For example, + (#20!!) is a 20 millisecond delay. (2/5) + +sys/gio/stdgraph/t_showcap.x + Modified to use the count returned by the encoder to find the end + of the output string, rather than assuming that the control string + is EOS delimited. This is necessary because the string may contain + embedded NUL characters. SHOWCAP will represent these as \0 in + diagnostic output. (2/5) + +dev/graphcap + Made a pass through this and made minor revisions to bring the comments + up to date. Deleted all the "old graphcap" stuff at the end of the + file, as the code which used it has all been deleted. (2/6) + +vms/boot/mkpkg/host.c + Modified h_outcheck() ($checkout) to always check out the latest + version of a file, even if a local file already exists with the + same name as the file to be checked out (the old version is deleted + and a new version is checked out). (2/6) + +vms/boot/mkpkg/tok.c + Added verbose messages to do_copyfile() and do_movefile(). (2/6) + +vms/os/zgtenv.c +vms/hlib/libc/iraf.h +sys$library:iraf.h + After having what appeared to be problems with the passing of logical + names to subprocesses spawned by batch queue jobs, I added the logical + name table lookup code from UNIX/IRAF to the VMS version of ZGTENV. + This code will fetch the values of the three essential logical names + IRAF, HOST, or TMP from the file <iraf.h> at runtime, if not found in + the VMS environment. These logical names are currently defined as VMS + logical names in hlib$irafuser.com as well, but these values can be + deleted should it prove desirable, and the system will automatically + pick up the default values from <iraf.h>. This is the way this works + on UNIX/IRAF too. (2/6) + +vms/boot/boot/* [UNRESOLVED] + This is a problem with the bootstrap utilities. At present, these + work great when run interactively from either DCL or the CL. + Even background execution works, provided the subprocess type of + bkg job is used. When run in a batch queue, however, my test case + (MKPKG) apparently completes successfully (an executable is linked), + but the spool file contains a DCL dump claiming that the MKPKG died + during startup because it could not find a file (it looks like the + hlib$zzsetenv.def file, but the RMS error message does not give the + file name). No other output is produced. I looked for a while but + could not figure out where the real output is going, or why this + apparently ficticious error output is being generated. Since the + MKPKG job apparently completes normally, it must be something during + job termination, but I don't have time to look into this further + now. (2/6) + +vms/os/net/zfioks.c +vms/os/net/inet.h + Reduced the max transfer size to 32256. A transfer size of 32768 or + larger causes the Wollongong network driver to crash VMS (this was + reported before, but the value checked for was still too large). (2/9) + +pkg/images/tv/display/iisopn.x + Added a strupk to unpack devinfo before calling ki_gnode. (2/9) + +pkg/images/tv/display/zsttim.x + Added code to multiply the max buffer size by 2 if "packit" is set, + allowing twice as many pixels to be stored in the same space. (2/9) + +vms/os/zgtenv.c + We don't want to use VMS logical names like "IRAF" and "TMP" because + problems are likely due to name collisions. On the other hand, we + don't want to change the IRAF names. The solution adopted was to + have ZGTENV, when asked to lookup NAME, look for IRAFNAME first. + This allows all logical names to be defined in irafuser.com with the + IRAF prefix. + + The exact sequence of events followed by ZGTENV when a request for NAME + is received is the following: + + [1] Look in VMS land for IRAFNAME. + [2] If NAME is one of "IRAF", "HOST", or "TMP", the three host level + logical names required by the IRAF VOS, and the VMS lookup for + "IRAFIRAF", "IRAFHOST", or "IRAFTMP" failed, fetch the default + value from <iraf.h>. + [3] Lastly, simply look in the VMS tables for NAME. + +vms/hlib/irafuser.com +vms/hlib/mkiraf.com + Now defines the following machine dependent logical names: + + IRAFDISK locates IRAF root at IRAFDISK:[IRAF] + IRAFTMP default TMP directory (public) + + fast,batch,slow aliases for batch queues + (SYS$NODE) not needed for 4.X VMS. + + The remaining definitions in irafuser.com are site independent. + The old logical IMDIRDISK has been replaced by IRAFTMP. The latter + is needed in any case to define the IRAF "tmp$", and it was desirable + for the default image storage location to be a directory rather than a + disk. MKIRAF was modified to create the default user IMDIR as a + subdirectory of the directory IRAFTMP. The temporary logical names + IRAF, HOST, and TMP were replaced by IRAFIRAF, IRAFHOST, and IRAFTMP. + The logical names EDT and VI were replaced by IRAFEDT and IRAFVI, + under the assumption that code will be added to EDCAP to define what + name to pass to the host to run the editor. It was annoying to have + an important symbol like VI used by IRAF, and always calling the + editor via the very slow @irafvi.com script. (2/11) + + TODO: add "host command" string to EDCAP, modify CL to use it. + +VMS Environment + This is a summary of the VMS environment configuration recommended + for IRAF. + + IRAF Symbol, loads irafuser.com + IRAFDISK Logical name, disk iraf sources are on + IRAFTMP Default public scratch directory + + IRAFDISK:[IRAF] Root directory of iraf on IRAFDISK + IRAFDISK:[IRAF.LOCAL] Login directory for vms user "IRAF". + + If no IMDIR is defined, the CL uses IRAFTMP. The default IMDIR + created by MKIRAF is the subdirectory .USER] of IRAFTMP. The system + should be installed under the login name IRAF. IRAF related VMS + mail should be sent to user IRAF (no need to use _iraf). (2/11) + +pkg/cl/builtin.c +pkg/cl/edcap.c +pkg/cl/globals.c +pkg/cl/eparam.h + Added a new field EDITOR_CMD to the EDCAP database. The "escape" + field contains the command to be sent to the host system to run the + editor. The function HOST_EDITOR() accesses edcap and returns the + command string for the named editor. (2/11) + +dev/edt.ed +dev/emacs.ed +dev/vi.ed + Added an EDITOR_CMD entry to each table file. (2/11) + +vms/hlib/clpackage.cl +vms/hlib/zzsetenv.def + Since the CL is an IRAF task run from the host, it reads the default + zzsetenv.def file during startup. Since this file already defines + all the logical directories, I moved the remaining non CL specific + SET definitions from clpackage.cl to zzsetenv.def. The clpackage.cl + file is now machine and site independent, and is one less file to + have to worry about during an installation. Since the system package + is loaded during startup now, I also replaced the fscan stuff, used + to type the message of the day, by a call to PAGE. (2/12) + +sys/ki/kishownet.x +pkg/system/netstatus.x +pkg/system/system.cl,x_system.x + Added function ki_shownet (outfd), used to print the network status. + Added a task NETSTATUS to the system package which simply calls the new + function and prints the network status as seen by x_system.e. (2/12) + +dev/hosts +dev/uhosts + Updated these tables. (2/12) + +vms/os/zopdpr.c + This interface routine was modified to give the user more control over + the priority of "interactive" background jobs (bkg jobs run as + subprocesses, rather than in a batch queue). The syntax is as follows: + + & [+|-]N + + where +(-) causes the bkg job to run at a higher(lower) priority than + the parent, and N is a decimal number. If neither + or - appears N is + the absolute priority of the process. + + For example, + + &15 run job at priority level 15 + &-1 run job at a priority one level down + + The default if nothing is specified is to run the job at a priority + level one less that that of the parent. (2/12) + +vms/os/zgtenv.c + This procedure was returning ERR if it could not find the name or the + output string overflowed. Changed to return 0, as is the standard for + operators that return string values. (2/12) + +iraf$mkpkg + Added an "update" entry point to the root mkpkg, so that I don't + have to run update twice in sys and pkg when relinking the system. + (2/12) + +dev/edt.ed +dev/emacs.ed + Added the NEXT_PAGE and PREV_PAGE operators as indicated in the ST + notesfile, received last month in the mail (the VI edcap file was + updated some time ago). There was a conflict for EDT; there was a + duplicate entry for MOVE_START which used the same code as one of + the new commands (keypad-7). I solved the problem by deleting the + duplicate entry. (2/12) + +pkg/cl/builtin.c + Everywhere there was a reference to the _pname (physical task name) + for an executable file, added a call to findexe() to get the name + of the executable which is actually used. If this is not done, + things like testing to see if a process is in the cache (prc, flpr) + fail. (2/12) + +sys/sys.hd +host/os/doc/os.hd + Changed sys$ references to host$ references to reflect the relocation + of OS to the HOST directories. (2/12) + +pkg/images/tv/cv/ids/idsfont.x +pkg/images/tv/cv/iism70/idsoptn.x - + There was a name collision with the routines IDS_OPEN and IDS_OPTN. + The latter was a no-op in any case, so I deleted it and commented + out the only reference to it in IDS_FONT. (2/13) + +sys/gio/cursor/grcwaitp.x + Modified to display the "wait" message again after the user responds + to the previous "wait" with a space bar, causing the system help + to be printed. (2/13) + +dev/termcap +dev/graphcap + Added a few new entries to each file, contributed from our early + test sites. Updated the cached entries. (2/13) + +pkg/language/* + Extensively revised, edited, corrected, extended, brought up to + date, added new examples, etc. the manual pages for the CL. + Most of the changes were minor, but some important new material + was added. Manual pages were added for those tasks added since + the docs were originally written. A manual page CURSORS was + added for cursor mode. The BEGIN and END manual pages were + deleted since these keywords are merely components of the PROCEDURE + declaration, not entities in themselves. (2/12-13) + +softools/*.hlp + Added manual pages for all the softools utilities, including all + bootstrap utilities (generic, mkpkg, rtar, wtar, rmbin, mkhelpdb, + hdbexamine, mkmanpage, etc.). (2/13) + +pkg/cl/builtin.c + Deleted a couple of task placeholder entries for the language package + and added a couple others, so that "? lan" will prompt with a certain + set of tasks or functions. The keywords and common intrinsic fcns + are excluded. (2/15) + +dev/termcap + Added a new device entry VMSPRINT, used to queue print jobs to the + standard VMS print queue SYS$PRINT. (2/15) + +sys/imio/imfort/ + +vms/os/zgcmdl.c + + Added a new interface IMFORT, the Fortran programmer's interface to + IRAF images. This is implemented as the library lib$libfort.a. + Linking requires also libsys.a, libvops.a, and libos.a. Documentation + is in the README file, and a manual is on the way. The interface is + minimal at present. + + A new routine, ZGCMDL, was added to the kernel to support IMFORT + (I also have plans for it for the LIBC interface, to be able to + emulate main(argc,argv)). This in available in IMFORT as the + Fortran callable procedure GCMDLN. The idea is that the user + interfaces their Fortran (or C) program to the CL as a foreign task, + then calls it with arguments like any other task. The Fortran program + gets the command line and parses it in memory to get the arguments. + (1/17) + +vms/os/zfiopr.c + We have been having problems connecting subprocesses, so I added a + call to _zerror if the create and/or map global section fails when + setting up IPC, so that hopefully we can determine why. (2/18) + +sys/etc/propcpr.x + A very minor change, while looking over this code. Added an errchk + for the syserr SYS_PROVFL, to prevent a memory overrun in the event + that there are no more process slots. (2/18) + +vms/hlib/gripes.cl + Modified the gripes script to send the entire text of the gripe to + IRAF (as in UNIX/IRAF), rather than just a line stating that a gripe + has been posted. On our system, mail to IRAF on any node is + forwarded to a central node, with the mail file for IRAF on that + node serving as the central gripes database. A copy of the gripe + is still appended to the gripesfile on the local node. The temporary + file was moved from TMP to UPARM and the extension ".txt" was added + to keep VMS mail happy. The second temporary file for the mail + message is no longer created, since the osfn() function now allows + us to pass the host name of the first tempfile to the host mail + program. (2/19) + +vms/os/zfiopr.c + Installed a new version of this driver from ST, which should fix + the IPC connect failure problem we have been experiencing lately. + ST went though the same thing several weeks ago. The problem was + traced to a SECTBLFUL (section table full) problem in VMS. This is + fixable by rebuilding VMS with a larger table (param GBLPAGFIL), + but the new driver will hopefully avoid the problem altogether, + avoiding the need for sites istalling IRAF to change a system + parameter. The recent debug_ipc mods were merged into the new + driver. (2/19) + +exception handling [UNRESOLVED] + After relinking the system with the new IPC driver from ST, we had + problems when interrupting subprocesses. Relinking with the old + IPC driver helped, but while testing I continued to have problems + with exception handling. Nothing I have done in recent history + should have anything to do with these problems, so I ran the same + tests on an executable in the old system (untouched for some months). + Exactly the same thing happened there, so evidently the problem has + been with us for some time. + + The test is this: I run the x_system.e process standalone, entering + the command "count files=*.x", and then <ctrl/c> interrupt the + task while it is running. Five times out of six, or thereabouts, + it will work, going through error recovery successfully. When it + fails VMS prints the message "improperly handled condition" along + with a dump of the stack and registers, and does a panic shutdown of + the process. This is preceeded by an access violation message. + +-------------------------------------------------------------------------- +VMS/IRAF V2.2 frozen on 21 Feb. + + +vms/hlib/mkpkg.e + Relinked; old executable was using an obsolete version of zgetenv + that had a bug. (3/4) + +pkg/cl/config.h + Doubled the size of the stack and increased the dictionary from 20K + to 30K. (3/6) + +dev/termcap + Added an entry for device "imagend", the new imagen on node draco, + plus an alias "imagena" for the original imagen on node aquila. (3/13) + +sys/ki/kireceive.x + Will now echo "out of band" error messages to STDERR, prefixed by + the node name, before returning ERR on the kernel server channel. + (3/14) + +sys/osb/miiupk16.x +sys/osb/miiupk32.x + These procedures were modifying their input arguments. (3/14) + +mkpkg, zgtenv.c [OBSERVATION] + We are running with two different versions of the system, IRAF and + IRAFX. When I linked a process with mkpkg from the IRAFX CL I found + that the old IRAF libraries were being used. The pathnames in the + global <iraf.h>, read by ZGTENV when it cannot find IRAF etc. in + the VMS tables, were still set for the old system. After editing + <iraf.h> and repeating the mkpkg, the IRAFX libraries were accessed. + This proves that indeed the logical names are NOT always getting passed + down through all the process spawns, and the new ZGTENV facility is + doing its job. (3/14) diff --git a/doc/ports/vms_oct85.st b/doc/ports/vms_oct85.st new file mode 100644 index 00000000..d4e23104 --- /dev/null +++ b/doc/ports/vms_oct85.st @@ -0,0 +1,786 @@ +Space Telescope Science Institute IRAF Notes (File: iraf$vms/notes) + + +-------------------------------- +Wednesday 23-OCT-1985 14:20:08.71 + +Subject: I/O redirection support for IRAF/VMS + +Added the ability to do I/O redirection on the command line (Unix-style). + + interactive $ cl + i/o to files $ cl <infile >outfile (or >>outfile) + +This allows people to run the CL in a VMS batch job or as a "background" +subprocess, specifying the CL commands in a text file. + + +sys$os/zmain.c + Added code to support I/O redirection (parsing, file setup, etc.) + +sys$os/zfiotx.c, zfiofi.c + Fixed ZSEKTX to work correctly (had troubles with redirected i/o for + some reason). + + Changed append mode access so it has RMS Update access (for seeking). + +pkg$cl/exec.c + Added a global variable 'logout_on_eof' (default=0), which is set + by the VMS ZMAIN when I/O is redirected to files. If the user forgets + to put the 'logout' command in the infile, then EOF will get him out. + Otherwise, it's very easy to fill up a disk with "ERROR: use 'logout'.." + messages in a file, something we definitely want to avoid. + + This is only a TEMPORARY fix. The same thing happens under Unix, so + maybe their should be some way of handling this in a general, + system-independent way. Will users use the CL with input from a file + instead of the terminal? They are here (for now) and the capability + should probably be supported, since it is automatically supported + under Unix. + + This fix does not affect normal operation of the CL in interactive mode; + the user still has to say 'logout' to get out of the CL. + + Note: If a user has a parameter which has a range specified, and the + value is out-of-range, while running the CL in this "OS-background" + mode, it will probably just loop until death saying "parameter out of + range", and fill up a disk with these error messages. This is also + a problem, but not sure how (or if) to fix it; the user should make + sure that the parameters are indeed correct when running the CL this + way to avoid this problem (?). + +-------------------------------- +Friday 25-OCT-1985 17:16:02.53 + +Subject: pkg$cl/eparam.c + +Hacked EPARAM to fix a number of problems with multi-line prompts, arrays, +and other things. There are still a few known "features", but they are so +obscure and such special cases that I'm not going to worry about them now +(there are easy ways to "reset" eparam to fix these offset problems). + +Also, changes so that value field is not overwritten by prompt string. + +-------------------------------- +Wednesday 30-OCT-1985 09:40:22.45 + +Subject: Parameter cacheing (pkg$cl/exec.c) + +Parameter cacheing mechanism (pkg$cl/exec.c mk_startupmsg, sys$etc/main.x, +clio$clcache.x, etc.) does not handle array parameters. Eventually, it should, +but this will mean some non-trivial changes in all of these places. There +are a few places in SDAS that do indeed have array parameters, so the course +of action for now is to not pass them in the startup message (as is done with +list-structured parameters). This fix is a simple "if" statement in exec.c/ +mk_startupmsg(). + +-------------------------------- +Monday 4-NOV-1985 12:33:48.79 + +Subject: pkg$cl/grammar.y (ytab.c) decl.c + +Bug fixes for 'real' declarations with negative values for min and max. + +-------------------------------- +Monday 4-NOV-1985 14:34:10.38 + +Subject: pkg$cl/lex.sed lex.com (for lexyy.c) + +Added editor functions to change (YYLMAX 200) --> (YYLMAX 2048), so lexical +analyzer can handle long prompts given in procedure scripts. + +-------------------------------- +Monday 4-NOV-1985 15:35:36.85 + +Subject: pkg$cl/linkcl.com [VMS] + +Changed to generate the CLDATE file in MACRO rather than C (i.e. cldate.mar). +This is so IRAF/VMS sites don't need a C compiler to relink IRAF (one site had +this problem already). + +-------------------------------- +Tuesday 5-NOV-1985 16:22:14.70 + +Subject: pkg$cl/task.c + +Additional check added before strncmp() call in ltasksrch() to check first +character first. Some profiling on Unix showed this to cut down the calls to +strncmp() significantly. + +-------------------------------- +Wednesday 20-NOV-1985 08:59:41.61 + +Subject: sys$os/ [VMS Kernel] + +The VMS Kernel routines have been overhauled. The large number of changes +consisted of: deleting obsolete code, consolidating common code segments, +some name changing, improving readability and consistency, and some tweaks +for efficiency. Most of the changes were indeed cosmetic, in an effort to +bring the code into conformance with the IRAF coding standards (though perhaps +not 100% there). To list all the changes would be impossible, so here are +some of the major ones... + +A number of files have been renamed, as well as support routine names, to be +more descriptive (and to remove the "z" on many of the support routine names). + +File name changes: + zconvtim.c --> convtime.c + zexit.c --> exit.c + zget*.c --> get*.c + zprocname.c --> procname.c + ztrnlg.c --> tranlog.c + zfiofi.c --> rms.c + ast.c deleted (no longer needed) + +Function name changes: + _zopnfi, _zclsfi --> _rms_open, _rms_close + _ztrnlg, _zcrelg --> _tranlog, _createlog + _zrequestio --> _zqio + _zsttfi deleted + others... + +New files: + dirname.c + queue.c + eprintf.c (from Kitt Peak, VMS net stuff) + +The file status functions (formerly in _zsttfi) have all been moved into each +of the ZFIO* drivers, with appropriate buffer size values in the include file +"vms.h". Some of these values have been modified, where appropriate, or as a +result of recommendations from Kitt Peak. + +No effort was made to completely redesign anything, though some files and +routines were restructured quite a bit. The effect on executable sizes of +these changes is negligible. + +-------------------------------- +Friday 22-NOV-1985 10:43:50.93 + +Subject: pkg$softools/boot/... + +All of the VMS source code for the boot utilities (MKLIB, XC, support ...) +have been overhauled to look like the rest of IRAF (at least partially), just +as the VMS Z routines. Besides a few name changes because of Z-routine +name changes, there was only 1 functional modification: + + pkg$softools/boot/spp/xc.c [VMS] + /dcl.c + + Changed to use the function DCL instead of ZOSCMD. DCL does + everything ZOSCMD does without all the weird features to + support interactive commands. The output is much more + consistent here as well, no longer generating ".;" and ".LOG;" + files all over the place when running XC and MKLIB in batch + or background. (DCL is essentially an earlier, stripped-down + version of what eventually became ZOSCMD). + +-------------------------------- +Monday 25-NOV-1985 15:41:56.73 + +Subject: Support for VMS batch jobs + +The VMS kernel has been modified to support VMS batch jobs as well as +parallel subprocesses for IRAF background jobs. Changes in the higher level +IRAF code is necessary to selectively use these two options. Since the +calling sequence for ZOPDPR has been changed, the new one is currently +commented out until these higher level changes are finished (at Kitt Peak). + +[received CL and system lib changes, 9-DEC] + +The changes include: + + ZOPDPR -- extra parameter 'batch_queue', null or "" for subprocesses, + a batch queue name for a VMS batch job. A few new routines + in this module were added and everything was reorganized a + bit. + + ZMAIN -- some extra checks were added to deal with the batch case. + + ZFIOTX -- In ZSEKTX, added a check for STDIN/STDOUT when a VMS batch + job. This is necessary to avoid seek errors on NLA0: and + the batch log file. (VMS really makes it hard to deal with + I/O in a consistent manner.) + + queue.c - Contains VMS batch and print queue support functions. Used + by ZOPDPR and ZFIOLP. + +-------------------------------- +Monday 2-DEC-1985 09:40:50.23 + +Subject: pkg$cl/builtin.c + +Changed SZ_FNAME to SZ_PATHNAME in cledit() to handle longer VMS filenames +resulting from filename mapping. + +-------------------------------- +Monday 9-DEC-1985 08:27:39.00 + +Subject: pkg$cl/prcache.c + +Interrupts were not being enabled if connected subprocess create failed. +Added call to intr_enable() in before returning NULL. + +-------------------------------- +Tuesday 10-DEC-1985 12:39:20.67 + +Subject: New version of IRAF/VMS from Kitt Peak. Merge notes: + +sys/os/* + Remerged the VMS kernel. No major problems, even though we both had + made a number of changes. Will test it all out soon. + +sys/os/net/decnet.c + + zfioks.c + Makelib + eprintf.c --> ../ + + Added support for DECnet, though this is not fully tested yet. This + is a compile time option (DECnet or TCP) in ZFIOKS and will not affect + the TCP implementation. The eprintf.c file was moved to the sys/os/ + directory, since some debugging code there uses it now as well. + +sys/gio/gks/gtx.f + Did NOT use KPNO version of file since it was calling f77upk with + the wrong number of arguments. There is no min-length arg to f77upk + in either version of IRAF. + +sys/osb/f77pak.f + Changed DO loop to pop out when done, rather than going around until + it reaches 9999. + +sys/gio/ncarutil/sysint/uliber.f + Following change need to compile on VMS. + integer*2(80) sppmsg --> integer*2 sppmsg(80) + +pkg/images/imarith/imadiv.x + imamax.x + imamin.x + (>>> imarith.x) + POINTER --> PIXEL + +pkg/imred/generic/Makelib, x_generic.x, generic.cl + Removed references to 'cmdstr' in these files. Assumed 'cmdstr' was + moved to the system pkg, since no cmdstr.* files on the tape. (?) + +sys/fio/vfnmap.x + Reference to ztslee changed to zwmsec. + +pkg/system/x_systest.x + Removed reference to mtdevlist. + +pkg/images/tv/display/t_mkdisplay.x + Moved call to open_display_header to AFTER getting name of stdimage + and frame number. Was before it, resulting in dev$_0.imh, instead + of dev$deanza_1.imh. + +pkg/language/doc/*.hlp + Some of these files were updated recently to correct errors, typos, + misspellings, etc. Forgot to note these changes before. + +Testing re-merged system + Tested out a number of the usual things: CL, test scripts, SYSTEM and + LISTS pkgs, some graphics and image tasks, etc. Everything seems to + be working okay. There are still a number of known bugs, especially + in eparam and procedure scripts (history gets a 'begin' in the history + for procedure scripts). I'll be looking into these again soon. + +VMS Batch Jobs + Tested out the CL with both types of background jobs, subprocesses and + batch. Both work fine. A logfile for the batch job case is kept + in the user's sys/login directory with a name like "12345678_D_1.LOG", + (i.e., like detached subprocess names). This logfile is largely + login garbage, but if the user does not redirect output, it will go + here as well. When things settle down and everything is working okay, + we may want to have the logfile deleted, or add an option for keeping + it or not. + + Logical names for batch queues work as expected. For example, the + following can be done: + + $ define b sys$batch + $ define f localfastbatch + $ define s localslowbatch + ... + + cl> task >&task.out &f # IRAF bkg job to 'localfastbatch' + + This means that zopdpr.c can remain system-independent, with system + dependent batch queues set up in logical names or spelled out fully + when in the CL. + +Magtapes + Tested the tape stuff with all the new changes from Kitt Peak merged + in. Used mtexamine and rfits and was able to read in about 20 small + FITS images and run some tasks from the images and plot pkgs on them + with no problems. + + +======> Sent tape of changes above to KPNO (16-Dec-1985) <===== + + +-------------------------------- +Tuesday 17-DEC-1985 16:07:42.04 + +Subject: sys/os/zpanic.c + +Bugs in formatting the error message fixed. + +-------------------------------- +Tuesday 17-DEC-1985 16:29:52.99 + +Subject: sys/os/zmain.c + +Changed code in _get_prtype() to figure out whether we're a batch job +by examining the PCB status bits, instead of the process name. If the user +sets his process name in the login.com file, then the background CL starts +up thinking it's a regular host process. + + +===> Sent above fixes to KPNO 17-Dec <=== + + +-------------------------------- +Wednesday 18-DEC-1985 12:36:34.43 + +Subject: dev/*.ed + +Added NEXT_PAGE and PREV_PAGE sequences to edcap files for EDT, EMACS and VI. + +edt -- + NEXT_PAGE \033Ow keypad-7 + PREV_PAGE \033OP\033Ow gold-7 + + (In edt, prev_page is really keypad-5,keypad-7, but this would + set direction backwards; gold-7 in edt is "command", which is not + used in eparam anyway.) + +emacs -- + NEXT_PAGE ^V ^V + PREV_PAGE \eV ESC-V + PREV_PAGE \ev ESC-v + +vi -- + NEXT_PAGE ^F ^F + (Nothing added for PREV_PAGE; not sure what to use, since ^B and ^U + are already being used.) + +-------------------------------- +Wednesday 18-DEC-1985 16:43:41.78 + +Subject: pkg/cl/builtin.c + +Fixed a bug in clflprcache() so that everything is not flushed if the named +task is not found in the process cache. Previously, if a user said + + cl> flprcache notask + Warning: 'notask' not in cache + +Then everything would go anyway, including locked tasks. The fix is simply +to do a 'continue' in the while loop when we print out this warning message. + +-------------------------------- +Wednesday 18-DEC-1985 18:44:37.98 + +Subject: sys/fmtio/lexdata.xi + +Changed action table for +/- in state QRX from Rvt to QRX. This is to fix +a bug when getting numbers like 1.0e-10 which returned nchars=3 instead of +nchars=7. This code is (eventually) used to check the type of command line +arguments in the CL when lexmodes=yes, which is where the problem was first +noticed. + +The code in lexnum.x along with the action table are somewhat difficult to +follow and there may be other implications here which are not apparent, but +based on other entries in the table, this looked like it was indeed a bug. +Ran the debug code in sys/debug/nop.x (lex task) and things worked correctly +in all cases tested. + +-------------------------------- +Friday 20-DEC-1985 11:42:48.72 + +Subject: VMS batch jobs and DCL commands + +When running a DCL command as an IRAF/VMS batch job (e.g. a foreign task), if +the output just goes into the logfile, it ends up being written into files with +names like .;1 and .;2, etc. This goes back to all the old crazies with the +funny ZOSCMD to defeat slow spawning and still provide interactive +capabilities. The user should redirect output in this case somewhere else and +not let it go to the VMS logfile. Tried a few changes in zoscmd.c and open.c +to no avail, so I'm just going to let this slide for now. + +-------------------------------- +Monday 23-DEC-1985 08:50:37.80 + +Subject: pkg/system/help/Help.hlp + +Formatting change to fix indentation: + + .ls + helpdb = "helpdb" +to + .ls helpdb = "helpdb" + +-------------------------------- +Monday 23-DEC-1985 10:35:15.82 + +Subject: Help task (discussion) + +Some SDAS users have voiced a "concern" over the help task. When saying "help +abc", everything that matches "abc" is given, even if something has already +matched it in the current package. This is confusing to novice users, even +though it is documented in the help that it will perform this way. A more +concrete example: + + cl> system + sy> help co + ... concatenate + ... copy + ... count + ... imred.coude + ... language.command + ... + +Would it be possible (and/or desireable) to stop the searching if help is found +somewhere in the current package for a named task or abbreviation? + +Another problem is getting help on something in a different package than what +was intended because of a common abbreviation (and no help file for the task in +the current package). The fix for this might be to limit the help search to +the current loaded packages, unless an explicit pkg-template.module-template +were given by the user. + +To go one step further, a suggestion by some SDAS people was to have an extra +parameter that controlled the search. For example, if matchall=yes, then help +would act as it does currently, otherwise, it would only search the current +package. + +-------------------------------- +Monday 23-DEC-1985 17:32:26.42 + +Subject: CL Changes Nov-Dec 1985 + (T.McGlynn, J.Travisano) + +grammar.y + - delete opnl's in procedure declarations to eliminate s/r conflicts. + - create LP and RP for parentheses to eliminate some expressions. + - repositioned initialization processing. + - modified var_decls slightly. + - if/else fixes, so don't need { if ... }. + - better syntax error reporting in scripts: gives (correct) line number, + points to offending position, and continues parsing script for errors. + +history.c gram.c + - changes to support above grammar changes + +history.c exec.c pfiles.c decl.c + - changes to deal with script line numbers correctly, i.e. + task->t_scriptln, which is used in syntax error messages; also, + a fix in the skip_to() function in decl.c. + +history.c + - problem of getting a "begin" in the history when running (or parsing) + a procedure script was fixed. The original command is now recorded + in the history (and logfile) correctly. Unfortunately, there is + one case where this does not work -- when get an error parsing the + parameter declarations in a procedure script. + +eparam.c + - format changes for real arrays (so exponent shows up) + - tried to fix MOVE_END problem when going across page boundaries; + can't seem to find the bug, so for now just print out a message that + says to use NEXT_PAGE a few times instead of MOVE_END. + +pfiles.c param.c gram.c + - added support for '\r' and '\f', so can be used in prompt strings + for better formatting control (\f not fully supported in EPAR yet) + +modes.c decl.c pfiles.c + - whitespace-only filename parameters are turned into null strings; + so users can check null filenames easily in a script (fn != "") + without having to deal with whitespace. Filenames with whitespace + only are not really legal anyway (?). + +modes.c + - bug fix to prevent trashing of enumerated parameters in certain + instances. + +param.h + - minor typo 'ai' --> 'ar' + +-------------------------------- +Friday 27-DEC-1985 14:47:48.01 + +Subject: CL history editor + +The following is another lexmodes=yes problem: + + pl> contour img1[*:16,*:16] + ... + pl> surface ^^ + surface img1[*:16 + Warning: ... + +The get-arguments code in pkg/cl/history.c checks for comma-delimited strings. +Putting the whole argument in quotes, i.e. "img1[*:16,*:16]", and then using +^^ works fine. (No fix/change was made.) + +-------------------------------- +Friday 3-JAN-1986 14:59:06.87 + +Subject: Local vars in CL procedure scripts + +It is generally assumed that local variables in CL procedure scripts, i.e. +those after the "begin" statement, will be initialized by the user with +simple assignment statements. There is one (possibly more) case where this +assumption can cause problems. For example, + + ... + begin + string buf + + if (fscan (plist, buf) != EOF) ... + ... + +Here, "buf" is used before being initialized, and the result is an error +saying "Attempt to use uninitialized local variable 'buf'". Perhaps local, +uninitialized variables should be initialized automatically by the CL, but +have done nothing to fix/change this yet; just making a note of it. + +-------------------------------- +Tuesday 7-JAN-1986 15:37:59.59 + +Subject: Miscellaneous + +These are various notes and suggestions by IRAF users at STScI and elsewhere. +I decided to finally add them all here since they were beginning to pile up +on various scraps of paper on my desk. Some of them are minor bugs, but most +are suggestions of some kind. Nothing has been done with any of them in terms +of IRAF changes. Most of the text is from mail messages or typed in verbatim +from paper copies. Any notes by me (JayT) are indicated in brackets []. + + +From ST users: + +CL + Would it be possible to put a feature into iraf whereby you say +'task=xxx', which would then set a default so that you could just +type lpar, or an input, without having to specify which task? +Ie, instead of having to type 'xxx.infile=etc', you could specify +the task and then just type 'infile=etc', with iraf filling in +the task name. This would not interfere with those who like the +system as it is, but could streamline things for those of us who +like the way AIPS does things. + +Integer parameters + We have encountered another peculiar feature of IRAF. Suppose you have a +parameter that is declared as integer in a .par file, and the user attempts +to put in a value for that integer that exceeds the range of INT*4. The cl +fills in that parameter with the value 'indef', a character string. When +SDAS goes to read the parameter, we get a crash because the parameter is not +in integer form. Now, it seems that a parameter declared as an integer ought +to be an integer no matter what, not a character string. Wouldn't it be better +to leave the parameter value unchanged from its current or default value rather +than put in this string? + + +From RAL users: + +CL Parser + li> ?? | words | match ':' stop+| sort | table + + does NOT work correctly, but separating the "+|" to "+ |" works okay. + +Help on parameter prompt + It is very complicated to provide additional help at the prompt for + parameter stage especially for non-string parameters. This facility + is almost essential to provide a user-friendly interface. + For example: + A string specified in the parameter file is output if ? is + typed in response to a prompt or possibly even enter the help + system. + + [NOTE: One can make the prompt quite verbose, up to something + like 2K characters; e.g., many SDAS prompts are long and multiline.] + +Range check and default display in sexagesimal + There needs to be an option in the parameter file to cause the range + check and default information to be output in sexagesimal. For example, + it is ugly to type in 12:34:56.7 and have it reappear as 12.582417. + +Date type + I think there ought to be special facilities for handling dates. At + present you can't enter a date all in one line (except using a + grotty fudge involving sexagesimal, which precludes proper range + checking), and if you enter the Y,M,D separately you can get things + like 1985 2 30 past the range checks. + + +From U. of Cal/San Diego (Doug Tudhope): + +lists.gcursor [and imcursor] + Get syntax error line 2. [known "feature" since CL2 grammar] + + [NOTE: doing an "lpar gcursor" activates the graphics cursor, + but then get an error of "EOF encountered in list parameter..."] + +plot.graph task + If only 2 points are given, only the axes are drawn, e.g. + + pl> graph STDIN + 10 10 + 20 20 + <EOF> + axes, but no line! + pl> + +images.imtranspose + Made a transposed output file of a real 190*800 image -> 800*190 + but neither onedspec.splot nor images.implot would work on it. + they stopped with "reserved operand fault". + When imcopy run on transposed image, got "pixel storage file truncated". + +-------------------------------- +Tuesday 7-JAN-1986 15:51:02.98 + +Subject: pkg/softools/boot/spp/xc.c [VMS] + +Added EXTEND_SOURCE option for calling Fortran compiler from XC. This lets +source statements go up to column 132 (instead of 72). One line added to +source: + +fcompile() { + ... + sp = strcpy (outbuf, F77); ++ sp = strcpy (sp, "/EXTEND"); /* Allow statement in cols 1-132 */ + if (portable) + ... +} + +-------------------------------- +Tuesday 7-JAN-1986 16:11:20.85 + +Subject: pkg/images/tv/display/deanza/* + +Deanza now works with tv/display under VMS! All of the source files and Deanza +libraries are here. See the README file for more detailed information. + +Also changed "pkg/image/tv/display/mkpkg.com" to make the Deanza code instead +of the IIS-dependent code. + +-------------------------------- +Wednesday 8-JAN-1986 12:21:09.73 + +Subject: pkg/imred/.../*.e + +The ONEDSPEC executables are copied all over the place into IMRED. Comments in +the mkpkg.com files say this is to use different par files for different +directories. There's GOT to be a better way, as this eats up a lot of +diskspace (and tape as well at distribution time), which we always seem to be +running up against here. + +-------------------------------- +Friday 10-JAN-1986 15:29:37.13 + +Subject: More SDAS concerns/suggestions + +Environment variables + When a script task ends or a user bye's from a package, all "set" + declarations made in the task or since the package started are + "popped" during task restoration. Comments in pkg/cl/exec.c indicate + that this is for keeping the environment the same across processes. + + However, this can lead to confusion. If a user does a "set stdgraph=" + and later bye's out of a package, stdgraph reverts back to the + previous value, just as any other environment variable. The same + thing occurs in script tasks during the restore, making it difficult + to have global environment variables. Putting a "keep" in scripts at + various places can get around this to some degree, but it's sometimes + awkward. + +Process cache + SDAS has been set up under IRAF such that the user can choose which + version of SDAS he wants (baseline|standard|develop). This choice + can be made when starting the sdas package or any of its packages. + There is a problem, however, when running a package from 'standard' + and then running the 'develop' version when the executable is already + out there. When a task is invoked, it will simply use the subprocess + already in the cache, even though it's a different executable (with + the same IRAF logical name). + + The suggestion that came up was to do an implicit "flprcache" whenever + there is a "bye" to a package, i.e. when all the tasks associated with + the executable are gone. I've looked at this a little bit and don't + see an easy way of determining when we're bye'ing from a package which + has tasks that are in an executable. I imagine there's a decent amount + of overhead associated with checking all the tasks associated with + an executable as well. In general, getting rid of old executables + does make sense if they're not longer referenced, since it frees up + system and user resources (especially important on VMS given the + large process and executable sizes). + +Table parameters + SDAS and CDBS now have a new type of input file, a table, which may or + may not have a header as well. They have asked if it would be easy + to add a new parameter (or two) to IRAF, i.e. a table parameter and + possibly a table-with-header parameter. + + I don't think this is a good idea, as it is something which only + benefits SDAS and CDBS, and does very little if anything for IRAF. + I have encouraged the SDAS people to find an SDAS-only solution to + this problem using existing IRAF facilities. One simple way is to + have tasks which use tables to have a 'type' parameter which tells + if the input file is a table or something else. + +-------------------------------- +Tuesday 14-JAN-1986 08:48:36.11 + +Subject: doc/clintro* + +Copied the TeX source for the CL User's Intro doc from Peter's directory +to the general IRAF DOC directory. + +-------------------------------- +Tuesday 14-JAN-1986 10:49:06.01 + +Subject: Size of IRAF... + +A concern has risen, once again, on the size of IRAF. Garrett Jernigan +(Berkeley Space Sciences Lab) has mentioned problems finding diskspace to +handle all of IRAF. The suggestion he made to Peter was "to split the source, +obj and executables into separate libraries for the distribution, or at least +put them into different sub-directories. If either a tape could be generated +that only had executables, or that had the whole works, but allowed only the +required files for execution to be loaded it would be a real boon." I guess +this means having something analagous to the bin/, src/ scheme in Unix. + +I think a better solution to this is to add something to the installation docs +to describe how to load only parts of IRAF, i.e. everything, or no source, +etc., so the IRAF installer can load only the parts needed/desired. Both Tar +and Backup can handle selective copying in some manner. + +-------------------------------- +Tuesday 14-JAN-1986 11:37:46.40 + +Subject: CL strings + +It is currently impossible to get the length of a string in the CL. This +should be quite trivial to implement, but it is not. The documentation on +"paramaters" states that p_length contains the maximum length of the string, +though in reality, saying =param.p_length simply prints the string, just as +=param does. + +There should be some way of getting the current length of a string, since it +could be used as the 'last' parameter in stridx, for getting the rest of a +string starting at column n. ST users have continually asked me about ways to +get the current length of a string parameter (e.g., from within a CL script). + +One solution is to change the meaning of some of the parameter attributes for +string parameters to something which makes more sense: + + p_length -- contains the current string length, updated whenever + the parameter is changed. + p_max -- contains the maximum string length + +These would require changes primarily in param.c and gram.c. + +Also, currently trying an =param.p_min or p_max on a string parameter results +in an access violation. diff --git a/doc/ports/vmsbugs.doc b/doc/ports/vmsbugs.doc new file mode 100644 index 00000000..e67d62e1 --- /dev/null +++ b/doc/ports/vmsbugs.doc @@ -0,0 +1,328 @@ +From stsci Thu Jan 17 08:30:15 1985 +Received: by lyra.noao.UUCP (4.12/4.7) + id AA10600; Thu, 17 Jan 85 08:30:03 mst +Date: Thu, 17 Jan 85 08:30:03 mst +From: stsci (Space Telescope ) +Message-Id: <8501171530.AA10600@lyra.noao.UUCP> +To: tody +Status: R + +Doug, + + Here is a list of bugs, changes, suggestions, etc. compiled during +the port of IRAF to VMS. + + Some of the bugs have the bug fixes listed here; others were too +elusive and/or time-consuming to try to figure out at this time. When you +get the latest, greatest VMS version of IRAF, what changes we made will +certainly be there; we'll probably send along RCS files as well so you could +easily update some of your files. However, most of the changes are +just a few lines here and there. + + We await any comments or any bug fixes you have there... + + Jay and Fred + +P.S. + We were discussing using mapped sections such as sdas +uses for static files. There is one major difference in the way that +iraf and sdas handle static (image) files. In the sdas routine +a pointer is passed back to where the image resides in memory. This +is due to the way the mapped sections work in VMS. In Iraf the zroutine +is given a pointer to where the data is to reside, so we have to do +a memory copy for each image reference, and may not be more efficient +than just writing to or reading from disk. Can you see any easy +way around this problem, or maybe an additional flag to zopnsf which +indicates that a pointer is to be passed back from zardsf or zawrsf +for the data rather than a passing in a pointer to where the data is to +be read to or written from? (fred) + + +---------------------------------------------------------------------------- + + + ------------------------ + NOTES file for IRAF (VMS) + ------------------------ + + +Contents: + 1. Bugs + + 2. Portability Considerations + + 3. Source file name changes + + +------------------------------------------------------------------------------- + + +1. Bugs + + /pkg/cl/bkg.c + In rbkgfile(), following fix: + ... fgets (set, fp) ... TO + ... fgets (set, SZ_LINE, fp) ... + + /sys/libc/qsort.c -- qcmp() --> (*qcmp)() + /sys/libc/cfilbuf.c -- filbuf() --> (*filbuf)() + + /sys/vops/advz.x -- '$t' missing for generic function + /sys/vops/advz*.x -- procedure advz[idx...] + + (extra files ?) + /sys/vops/ak/aif*.x -- aiftrrr.x + /sys/vops/ak/aff*.x -- afftrxx.x, afftxrr.x, afftxxx.x + /sys/vops/ak/acjgx.x -- acjgxx.x + + /sys/fio/fdebug.x -- "int and()" statement missing + /sys/fio/fputtx.x -- "int and()" statement missing + /sys/fio/fgetfd.x -- "int or()" statement missing + + /pkg/cl/pfiles.c -- pfcopyback() + 'pt' was going NULL before 'pf' in a for loop check; + was changed to check for 'pt' being NULL instead of 'pf' + + /pkg/cl/builtin.c, binop.c, bkg.c, history.c, lexicon.c, + debug.c, errs.c, exec.c, pfiles.c + + problem getting to next task by doing 'tp++'; due to VMS + alignment of structures. Fixed with a macro definition in + /pkg/cl/task.h for "next_task()", namely: + + #define next_task(tp) \ + ((struct task *)((unsigned)tp + (TASKSIZ * BPI))) + #define prevtask next_task(currentask) + + + /pkg/help/lroff/output.x -- references constant MAX_INT + "include <mach.h>" statement missing + + /pkg/lists/tokens.x -- last_nscan() --> last_nscan + + SPP/RPP compiler bug -- + + define and jiand (e.g. in <iraf.h>) + + if (x == FIVE && y == SIX) ... (SPP) + if (x == FIVE & y == SIX) ... (RPP) + if (x .eq. 5 .jiand. y .eq. 6) ... (FORTRAN) + + only occurs when a macro is replaced before the '&&', + in this case FIVE. + + /sys/fio/vfnmap.x + vfnunmap() -- when an OS extension was (un)mapped to a null + IRAF extension, the character count returned + was not right: + (e.g.) doc.dir --> doc but nchars = 7 + This caused problems later on in the directory + task of the system package. + The fix: + ... { + vfn[extn_offset-1] = EOS + op = extn_offset - 1 <-- was missing + } ... + + /sys/fio/vfntrans.x + filename mapping for directories sometimes doesn't work; + sys$ --> drb4:[irafx.sys]sys instead of + drb4:[irafx.sys] + made a quick fix in zopdir() and zfchdr() to deal with this + for now; can't seem to locate the exact problem in vfntrans.x + + /sys/fio/vfnmap.x + When deleting a file and the parameter subfiles=yes, and + no mapping file is currently in directory, a null mapping + file is (sometimes) created. Then doing a system.directory + fails when trying to read this null mapping file. + + E.g. cl> delete aaabbb.ccc + subfiles=yes (default .par file) + + delete() is called with 'aaabbb.ccc' and then + 'aaabbb.ccc.zsf', which is degenerate; + therefore, if a mapping file doesn't + exist, it is created. + + Haven't fixed this yet; not sure about the best way to go. + Some simple suggestions: + + -- Could somehow figure out whether the file is being + added or deleted (i.e. was vfnmap() called from + vfnadd() or vfndel()?). + + -- Or, whenever a mapping file is created, it has the + appropriate header info in it rather than being null? + + -- Or, some special case of reading null mapping files? + + + /sys/etc/environ.x + env_hash() + return (sum**2 / CONSTANT) + + causes integer overflow on VMS; changed to: (for now) + return ( int( float(sum) / CONSTANT * float(sum) ) ) + + arithmetic overflows: + /sys/etc/urand.x and others... + + These seem to occur in a few places, sometimes purposely. + An easy VMS fix is to use "FORTRAN/NOCHECK file", but it's + a pain to have to remember which files need this special + treatment. + + /sys/fio/ + Seems to be a bug in the file i/o related to writing + asynchronously to binary files. In VMS, this is REALLY + asynchronous, and it caused problems when trying to write + the help database; making VMS do it synchronously (like + UNIX) fixed the problem, for now anyway. + + It may be that a single buffer is being played with between + the write and the wait; at least that's what it looks like + in some of the binary files that were written -- there were + missing blocks and misaligned data, which were there when + displayed on the terminal. + + I don't think it's a problem with RMS, since double buffering + was used to test the binary file driver, with success. + + + /pkg/system/directory.x + - call strcat ("$", Memc[template]) --> + call strcat ("$", Memc[template], SZ_FNAME) + + - should sort and output the file name list ONLY + if (nfiles > 0) + otherwise, an "adjustable array error" occurs in qsort() + (i.e. an array with dimension of 0 is passed to qsort, + causing VMS to complain) + + +------------------------------------------------------------------------------- + + +2. Portability Considerations + + + (life would be easier if most source files and include files did + not need to be mapped ... especially C source files) + + -- no underscores + -- only alphanumeric + -- case insensitive (i.e. lower case) + -- (9 chars).(3 chars) + + (Notes: Some source file names and references to include files + had to be changed to create the filename mapping in the + first place, see list below. + + This is not so crucial now, since XC and XPP have been + written/modified to handle filename mapping. But, it + still does cause problems when making bug fixes to source + files with degenerate names and trying to keep track of + them with RCS. Of course, 99% of the mapping problems will + disappear with VMS V4.0.) + + also, directories should be case insensitive: + /sys/vops/AK --> ak + /sys/vops/LZ --> lz + + + sys/libc/cfilbuf.c -- filbuf --> vfilbuf (VMS) + since 'FILBUF' gets translated to + 'filbuf' on VMS, not 'filbuf_', + which causes a conflict: + FILBUF and (*filbuf)() + + + SPP coding conventions that cause problems for VMS FORTRAN compiler: + + a) multiple declarations, e.g. + + int ip + ... + int ip, this, that + + files: /sys/fmtio/ctoi.x + /sys/fmtio/sscan.x + /sys/fmtio/chdeposit.x + /pkg/system/sort.x + + b) 'real' function, e.g. + + real (dval, 0) --> real (dval, 0.0) + /sys/fmtio/gctod.x + + c) array declarations in procedures, e.g. + + procedure proc1 (array, count) + type array (count) + int count # should be BEFORE array declaration + # (tries to use 'count' as a REAL) + /sys/fmtio/patmatch.x + /pkg/utilities/t_translit.x + makeset(), filset() + + + and(), or(), not() --> andi(), ori(), noti() ??? + lots of references in /sys/fio/ to these procedures + (added them for VMS, using andi(),...) + xor() referenced in /sys/vops/...axorki.x + (added xor() for VMS, using xori()) + + FIO + file mode "APPEND" -- create the file if non-existent?? + UNIX (and now VMS) do this automatically, but system + reference document isn't clear about this. Without this + feature, /pkg/system/bugmail.cl and revisions.cl don't work. + + I/O drivers + ZMAIN passes the EPA of the read driver to IRAF_MAIN() ... + + This is OK in UNIX (and VMS, for now), but may have cases + where I/O is to different devices and the drivers are NOT + compatible. (I don't know enough of the internals of + other operating systems to say for sure that this is a + problem, but it seems like it could be.) + + Eg. STDIN from a file and STDOUT to terminal + + If the file and terminal drivers are incompatible, then + things won't work. We may eventually have some problems + in this area with VMS, especially if we start to support + some network I/O access. Eventually, we may store the + actual read/write function in the channel structure and + check it whenever a read/write function is called; that is, + override the higher level IRAF I/O at the kernel level. + + zardlp() function referenced in /sys/etc/lpopen.x ?? + (added dummy function for VMS) + + + modf() function used in /pkg/cl/unop.c + was missing from /sys/libc/ + (added modf.mar to /sys/os/ for VMS) + + +------------------------------------------------------------------------------- + + +3. Source file name changes + + + /pkg/softools/boot/spp/xpp/xpp_main.c --> xppmain.c + + Necessary for file name mapping: + + /sys/memio/ty_size.dat --> tysize.dat + + /sys/memio/coerce.x, salloc.x, sizeof.x + include "ty_size.dat" --> include "tysize.dat" + + +------------------------------------------------------------------------------- + + diff --git a/doc/ports/vmsport.doc b/doc/ports/vmsport.doc new file mode 100644 index 00000000..63e09193 --- /dev/null +++ b/doc/ports/vmsport.doc @@ -0,0 +1,1271 @@ +> From stsci Mon Dec 17 06:37:53 1984 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA15814; Mon, 17 Dec 84 06:37:48 mst +> Date: Mon, 17 Dec 84 06:37:48 mst +> From: stsci (Space Telescope ) +> Message-Id: <8412171337.AA15814@lyra.noao.UUCP> +> To: tody +> Subject: VMS .dir files +> Status: R +> +> Doug, +> +> Had some questions on how you handle directory files, especially in VMS. +> The filename mapping stuff takes a ".DIR" file on VMS and strips it off +> for IRAF. Is there a need to go the other way, and if so, how do you do +> it ? Do you keep a flag that says that a particular file is a DIRECTORY_FILE? +> The reason I ask, is that ZFINFO is supposed to tell whether a file is +> a directory file. Before, for VMS, zfinfo just looked for the ".DIR" +> extension. I have since modified it to do an additional check on files +> with null extensions, if it doesn't find the file in the 1st place. +> (since testing the single directory bit in the file header on VMS takes +> about 100 lines of code!!) I guess my overall question here is do you map +> the names back, somehow, for the case of zfinfo, or should I just keep my +> extra little check in there in case a file with a null extension comes in? + +The directory files are unique in the filename mapping scheme because they +have no extension in IRAF form, as when listing a directory (this is controlled +by the extension mapping string in config.h). This is necessary for +compatibility with UNIX and to ease pathname generation, e.g., "a/b/c" is +easy to generate if directory filenames are returned as "a", "b", etc., +but no so easy if they are "a.d", "b.d", and so on. If we used the second +form with the ".d" extension, and tried to add the ability to generate the +extension on UNIX via an FSTAT call on each file, listing a directory on UNIX +would be prohibitively expensive. If we put the ".d" extension explicitly +in the directory name on UNIX, then it would have to appear explicitly in +all UNIX pathnames and other directory file references. + +For these and other reasons, it seemed that the simplest solution was to +omit the extension for directory references. Directory files are almost always +referenced in a context where it is known that the file is a directory, +hence the kernel can add the extension if it needs to. Normally the kernel +will receive a directory filename with a null extension. ZFINFO should +definitely make an explicit check to see if a file is a directory, rather +than merely looking at the filename. As far as I can remember, all other +kernel primitives know if they are dealing with a directory file. Note that +ZFACSS was recently modified to add the DIRECTORY_FILE file type, used when +checking for the existence of a directory file (the new filetype tells the +kernel to add the ".dir" extension). + +The high level code does not maintain any flags telling which files are +directory files. In no case is a directory extension appended, except in +a machine dependent name entered by the user. + +> Also, re filename mapping, it seems that filenames without extensions +> (including +> directory files once they've been mapped on VMS) don't get listed correctly +> by the directory task in /pkg/system/. It seems to be a problem with +> /sys/clio/fntgfn.x, but I'm not sure - I'll see if I can locate it and fix it. +> It does the following: +> +> Files --> File +> Makefile --> Makefi +> README --> READM + +The function of FNTGFN is to expand filename templates, i.e., read VFN's from +a directory or directories using DIROPEN, select all filenames which match a +pattern, returning a list of filenames as output. It is unlikely that this +code could perturb a filename in the manner described. I recommend writing +an SPP test program which calls DIROPEN to verify that VFN's are being read +from the directory correctly, before doing anything to FNTGFN. The latter +package should be machine independent. + +By the way, the DIRECTORY task has bugs (machine independent) which are +annoying, but should not affect the basic operation of the routine. +These will be fixed eventually with a new version of DIRECTORY, but this +is not a high priority item at present. + +> Other than that, things are coming along; the system and help packages are up +> and running standalone, and the CL is coming along -- we had to backtrack a +> little and redo the old fixes for VMS... +> +> Jay. + + +> From stsci Mon Dec 17 13:58:50 1984 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA22347; Mon, 17 Dec 84 13:58:44 mst +> Date: Mon, 17 Dec 84 13:58:44 mst +> From: stsci (Space Telescope ) +> Message-Id: <8412172058.AA22347@lyra.noao.UUCP> +> To: tody +> Subject: iraf +> Status: R +> +> Doug, +> I hope you didn't get that last letter. I got hugh up on. Any way, I have a +> couple of iraf questions. I will start with the simple one first. +> How long should +> EOF last in the terminal driver?? Currently I return EOF once for each time it +> is typed. THis could be changed to only happening at beginning of line, or so +> that EOF is given for every call to zgetty after the first EOF is typed. + +Treat EOF like a character, except that EOF is not returned if there is any +data left to return. An input line, delimited by EOF but not newline, is +returned as a line of text not delimited by newline, followed by EOF in the +next read. The next read after that will return the next line of text from +the terminal, i.e., EOF does not "stick". + +> Also I got my problem fixed with task definitions. I had a tp = tp + TASKSIZ +> instead of tp = tp + TASKSIZ * BPI. We had to changed to this format since +> TASKSIZ * BPI is different from the actual size of the task structure in +> VMS. I changed all of the tp++ and tp + 1 to this format. Also I decided to +> use a macro instead to get to the next task structure so I didn't run into +> the problem again. + +Right, I recognize that as one of the more subtle bugs that Jim discovered +working with the prototype version of the system. Sorry that the bugfix did +not get into the version of the CL that you received. + +> Now for a couple of problems. The cl currently gets up on its own, but will +> not talk to any subprocesses. What happens is that it sends the one piece +> of data to the subprocess, and then the subprocess kind of takes off and reads +> millions of bytes of data instead of just 4 (internal length of data package). +> It apears from the debugs that I get that zardpr is not being used to get +> the data??? I don't know if you have seen this before. + +You might have a look at the UNIX version of ZFIOPR. This driver contains +support for debugging IPC. Debugging IPC with the OS debugger is difficult +or impossible. I instead put a debugging switch in the driver (an external +variable named debug_ipc, settable with the debugger before or during +execution), which causes debugging information to be printed during task +execution. There is also a "-C" flag on the UNIX IRAF Main which causes +the task to run standalone in CONNECTED mode, using the IPC driver, but packs +and unpacks char data so that I can run in IPC mode from a terminal. +Installing something similar in the VMS IPC driver would make it easier to +debug problems involving IPC. + +If ZARDPR is not being called to read from CLIN it may be because the integer +entry point address of ZARDPR, as returned by ZLOCPR, is not being passed +correctly to the IRAF Main by the ZMAIN. + +I am not sure what the 4 byte quantity referred to is. The 4 byte record +header used in the UNIX IPC driver is peculiar to UNIX and is not necessary +on a system which supports record level IPC i/o. UNIX pipes are byte streams, +causing record boundaries to be lost, and I had to use the 4 byte header to keep +records intact across the pipe. All knowledge of the 4 byte record header +is concentrated into the UNIX IPC driver. The high level code merely +calls ZARDPR, ZAWRPR, and ZAWTPR to read and write headerless records. + +> Opps got hung up on again... +> Another problem I had was with the -c flag. It seems that irafmain redirects +> i/o to the null device on task startup and shutdown. After redirecting +> STDOUT and STDERR, it sets them with fseti so that they are no longerT +> +> Hung up again... +> redirected, but does not swap the fd's back again. Then on task shutdown, it +> does through and closes the users files that weren't kept and manages to +> close the redirected stdout and stderr because they were copeid into a file +> descriptor greater than last_fd. Have you seen this before??. This also +> may be my problem with subprocess also. +> fred. +> + +The STDOUT and STDERR streams are redirected to the null file during +process startup when in CONNECTED mode (when process is spawned by CL). +Redirection is effected with FREDIR and cancelled with CLOSE, not FSETI. +FSETI is used to set the redirect flag in FIO if the stream has been +redirected remotely by the CL. + +The redirection to dev$null during startup and shutdown is a new wrinkle +added to the IPC protocol since the Sys.Int.Ref.Man was written. What +happens is: + + cl spawns subprocess + subprocess runs IRAF Main + Main redirs STDOUT,STDERR -> dev$null + cl sends envlist (sequence of + SET statements) + cl sends chdir curdir + cl sends "_go_" + Main cancels redirection + +The CL (actually, etc$propen.x) must send the "_go_" command to the subproc +to tell it that process startup is complete. Output is discarded during +startup to avoid deadlock due to two processes writing to the IPC at the +same time. + +Redirection is cancelled when the "_go_" is received by closing the affected +files. The FD's are swapped back at CLOSE time. If the redirection during +startup is not being cancelled it is probably because the Main is not seeing +the "_go_" command. +> From stsci Thu Dec 20 09:05:22 1984 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA05472; Thu, 20 Dec 84 09:05:17 mst +> Date: Thu, 20 Dec 84 09:05:17 mst +> From: stsci (Space Telescope ) +> Message-Id: <8412201605.AA05472@lyra.noao.UUCP> +> To: tody +> Subject: help db +> Status: R +> +> Doug, +> +> Jay here; having a bit of trouble with the help database. Running help +> standalone, I can do a mkhelpdb on lib$root.hd and it gets all the way to +> the end before dying. It seems to die when it tries to make the root/index +> entry, though I'm a little shaky on what's actually going on there. +> +> Does it read back the entire help db and then try to make a full index ? +> If so, then the problem is probably in our binary file driver. That's what +> it looks like to me, anyway. Any ideas, suggestions on where to look?... + +I could help more if I knew more about how it is dying. On UNIX one usually +gets a fault which can be caught by the debugger, after which one does a +stack trace to find out where the crash occurred. The most common cause of +faults are memory violations of various flavors. Unfortunately any bugs +having to do with memory violations are usually hard to track down, because +the fault is often not remotely related to the bug which caused memory to be +overwritten. In the event of a memory violation of unknown origin I usually +take the brute force debugging approach, i.e., I first find out what region +of memory is getting clobbered and then repeatedly rerun the program, doing +a binary search for the code which is causing memory to be clobbered by +setting breakpoints in time sequence. This always works but requires intimate +knowledge of the code and a good debugger. Probably you should try to avoid +this and check the low level routines first. + +From what you are saying it sounds like the problem is most likely in +hdb_make_rhd() in helpdb.x. I agree that the most likely cause of the problem +is the binary file driver. During compilation compiled help directories are +appended to the help database. This is done as follows: + + NOTE is called to note the one-indexed XCHAR offset at which + the next segment will be written. FIO keeps track of this + itself (not the kernel) hence this should not be the problem. + WRITE is called twice to append the two parts of a compiled help + directory to the output file. Since output is buffered there + may or may not be a corresponding call to ZAWRBF. + +This sequence is repeated for each help directory in the system. When the +tree has been exhausted the file position is NOTEd and used to compute the +length of the data area. HDB_MAKE_RHD is then called to make the root +help directory, taking the following FIO operations: + + SEEK to the beginning of the data area. This will lead to a file + fault to the file buffer containing the seek offset, i.e., + ZARDBF will be called to read in a file buffer somewhere back + toward the beginning of the file. This is something to check + since it is a random access and most or all file accesses thus + far tested have been sequential. + + READ is called to read in the entire data area. The resulting kernel + level operations are likely to be the following: + + - ZAWRBF to flush the buffer at the end of the file + - a sequence of ZARDBF calls to read the file buffers + containing the data segment (which is large, about 70KB). + - for each ZARDBF there will be one or more calls to AMOVC, + which is optimized in assembler calling the VAX MOVC3 + instruction (check that). + +The memory allocation routines are absolutely crucial to all of this (and to +the whole system), and are another possible source of trouble. In particular, +you might check ZRALOC, which is rarely used but is definitely used here. +The things to check are the pointer (if the buffer moves, is the returned +pointer a pointer to XCHAR) and the data alignment (if the buffer moves, the +buffer contents should be simply copied as a byte array with no byte shifts; +the high level code will shift the data to correct any alignment problems). + +> Also, the help tasks like lroff, mkhelpdb, and hdbexamine - can they be +> run from under the CL ? I can't seem to get them to work there , so I'm +> just running them standalone... +> +> Jay +> + +These tasks are available in the package SOFTOOLS and are nothing special. +They should run just like any other task. It is misleading because the +source is in pkg$help and the task declarations are in pkg$softools. +I will put a comment in the README. + +--Doug +> From stsci Thu Dec 20 11:32:09 1984 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA06285; Thu, 20 Dec 84 11:32:02 mst +> Date: Thu, 20 Dec 84 11:32:02 mst +> From: stsci (Space Telescope ) +> Message-Id: <8412201832.AA06285@lyra.noao.UUCP> +> To: tody +> Subject: file name mapping +> Status: R +> +> Doug, +> I am running into a couple of small problems. I am trying to use VFNDEL +> from xc. I have a file name t_rcardimage.x. I generate t_rcardimage.r and +> then t_rcardimage.f. At this point t_rcardimage.f maps to tj8rcarde.for +> which I would guess is correct. I then delete the entry for t_rcardimage.r +> the mapping for t_rcardimage.f then changes to t_widsout.r. Have you +> seen this before? Also from the cl if i delete a file in a directory and +> then try to do a directory listing of that directory I get: +> "Cannot open file drb4:[...]zzfnmap.zvf". May question is does the +> filename mapping still have the mapping file open for write or read_write +> access?? VMS has a tendancy to lock files against read if someone else is +> writing it. +> fred. + +Fred-- + + This one is a bug in the high level code. The filename mapping code could +not delete files with long filenames properly. There were two independent +bugs, for which I have included fixes below. I have tested this on UNIX +after compilation with the VMS file parameters in config.h (that's the best +I can do without going to a lot of trouble). + +The bug was such that file deletion of a file with a long filenames will have +corrupted your zzfnmap.zvf mapping file (the first long filename will have +been overwritten). After the bug fix, however, the mapping file will again +be readable and can probably be patched up with a rename or something. + +FIO knows whether or not the OS locks files opened for writing, as is the case +for VMS. If the file is locked by another process FIO will wait for it to +become available. FIO is careful to open the mapping file for as brief a time +as possible to minimize contention problems. Care is taken to avoid deadlock +between concurrent processes in cases such as a rename where it may be +necessary to open two different mapping files (what a pain that was...). +This sort of thing should not be a source of problems unless there is a bug. +See fio$doc/vfn.hlp if you want to know the nasty details. + +By the way, if a file such as "t_rcardimage.x" should appear as "t_rcarde.x" +in a directory listing, that is a sign that FIO could not find an entry for +the file in the mapping file. You reported something like this a while back. +Let me know if the problem should recur. + + --Doug. + + +[1] VFNMAP.X line 115, old ......................................: + + define FN_VFN Memc[M_FNMAP($1)+($2*2-2)*LEN_FN] + define FN_OSFN Memc[M_FNMAP($1)+($2*2-1)*LEN_FN] + +[1] VFNMAP.X line 115, new + + define FN_VFN Memc[M_FNMAP($1)+(($2)*2-2)*LEN_FN] + define FN_OSFN Memc[M_FNMAP($1)+(($2)*2-1)*LEN_FN] + + +[2] VFNMAP.X line 729, old ......................................: + + # entire MFD is written to the mapping file. + + checksum = vvfn_checksum (Memi[mfd+1], (len_file - 1) * SZ_INT) + ntrys = ntrys + 1 + +[2] VFNMAP.X line 729, new + + # entire MFD is written to the mapping file. Note that the + # file will contain garbage at the end following a file + # deletion (the file list gets shorter but the file does not). + # Compute checksum using only the valid file data, since that + # is how it is computed when the file is updated. + + len_file = LEN_MFD - (MAX_LONGFNAMES - M_NFILES(mfd)) * + (SZ_FNPAIR / SZ_STRUCT) + checksum = vvfn_checksum (Memi[mfd+1], (len_file-1) * SZ_INT) + + ntrys = ntrys + 1 +Re: file not closed when filename mapping -- + + I fixed the same bug in the version here, so you won't see it next time +around. + +> From stsci Wed Jan 2 06:42:10 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA26294; Wed, 2 Jan 85 06:42:05 mst +> Date: Wed, 2 Jan 85 06:42:05 mst +> From: stsci (Space Telescope ) +> Message-Id: <8501021342.AA26294@lyra.noao.UUCP> +> To: tody +> Subject: file i/o +> Status: R +> +> Doug, +> We had a problem with the interaction between iraf file i/o and the +> zroutines. The problem seems to be with the asynchronousity. If we do the +> same thing as unix everything flys, but if we make it asychronous, it falls +> apart. The file name mapping works just fine, and so have our tests with it +> running asychronously [[synchronously?]]. Is it possible that the iraf fio +> plays with the buffer before the operation has completed?? + +The FIO code was written to call ZAWTBF after every i/o request, before using +the buffer, but this mode of operation has never been tested since UNIX is not +asynchronous. My feeling is that it is not worthwhile to test this mode of +operation until FIO supports more than one buffer per file. The current +interface still supports only one buffer internally, so you have to wait on +every i/o operation in any case, and having asynchronous primitives does not +make much difference (I just use very large buffers when I want it to go fast). +Unless you can find the bug in FIO without spending a lot of time, it might +be best to leave this until I modifiy FIO to support multiple buffers, +at which time the bug will certainly disappear. For the moment it is +sufficient to test the asynchronous features of the zroutines outside FIO. + +> Has anything happened with the new process caching. We do the impression +> (oops got) that there would be more changes in the cl. Something about having +> a bunch of processes loaded but not having the nesting and always being at +> the cl prompt? You had mentioned something about this before, and we were +> wondering if it might have got lost somewhere in getting the tape. + +All of the process caching code is brand new, written to use the new process +control code accessed via LIBC. The CL process cache code is a package +contained wholly within the file "prcache.c". This version supports nesting +of calls from one process to another (although deadlock will occur if the +cache fills up). The newest parts of the CL are the files "prcache.c", +"main.c", and "bkg.c". + +> Also with the text i/o the file size may not represent the actual size +> (in characters) of the file, due to VMS standard record files. Will this +> be a problem. Any Iraf created files will have the correct size since +> they are stream_lf. +> Fred & Jay + +This is ok, the file size need be known accurately only for binary files. +For text files the file size is not used for anything serious (see the +description of FSTT_FILSIZE in the manual page for ZFIOTX). + +Glad to hear that the filename mapping code is working well. It is crucial +to the port, and I was concerned about bugs since it is such a complex +package. + Doug +Fred and Jay: + + Answers to recent questions follow. Is the system ready yet for me to +look at over the modem? When you get it to a state where you feel it is +working fairly well, I would like to fire it up and try a few things. + + Doug. + +> From stsci Thu Jan 17 08:30:15 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA10600; Thu, 17 Jan 85 08:30:03 mst +> Date: Thu, 17 Jan 85 08:30:03 mst +> From: stsci (Space Telescope ) +> Message-Id: <8501171530.AA10600@lyra.noao.UUCP> +> To: tody +> Status: R +> +> Doug, +> +> Here is a list of bugs, changes, suggestions, etc. compiled during +> the port of IRAF to VMS. +> +> Some of the bugs have the bug fixes listed here; others were too +> elusive and/or time-consuming to try to figure out at this time. When you +> get the latest, greatest VMS version of IRAF, what changes we made will +> certainly be there; we'll probably send along RCS files as well so you could +> easily update some of your files. However, most of the changes are +> just a few lines here and there. +> +> We await any comments or any bug fixes you have there... +> +> Jay and Fred + +Thanks a lot for the bug reports. I will wait and install these bug fixes +during the upcoming system integration period when I get the new VMS version +of the system back from you guys. + +I have been working on some of the more subtle bugs here and will send you +a bug list and/or code updates at some point. I have a few hard to catch +bugs to track down yet before this will be worthwhile. + +> P.S. +> We were discussing using mapped sections such as sdas +> uses for static files. There is one major difference in the way that +> iraf and sdas handle static (image) files. In the sdas routine +> a pointer is passed back to where the image resides in memory. This +> is due to the way the mapped sections work in VMS. In Iraf the zroutine +> is given a pointer to where the data is to reside, so we have to do +> a memory copy for each image reference, and may not be more efficient +> than just writing to or reading from disk. Can you see any easy +> way around this problem, or maybe an additional flag to zopnsf which +> indicates that a pointer is to be passed back from zardsf or zawrsf +> for the data rather than a passing in a pointer to where the data is to +> be read to or written from? (fred) + +My impression from a glance at the VMS system services was that the create +and map section function could be broken into smaller functions. The idea +was that ZARDSF, when requested to read/map file segment A onto memory +segment M, could unmap M (from the paging file) and remap it onto A. +A subsequent ZARDSF on the same M would unmap from file segment A and +remap onto file segment B. ZCLSSF would unmap file segment B (etc.) +and remap onto the paging file. When using the static file driver, the +high level system code will see to it that M is always aligned on a virtual +memory page boundary and is an integral number of pages. + +Will that work? If not something can be done, but at least conceptually +it makes sense to me, and it would eliminate artifical distinctions between +the two types of i/o. + +> From stsci Tue Jan 22 12:44:59 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA22373; Tue, 22 Jan 85 12:44:51 mst +> Date: Tue, 22 Jan 85 12:44:51 mst +> From: stsci (Space Telescope ) +> Message-Id: <8501221944.AA22373@lyra.noao.UUCP> +> To: tody +> Subject: vfn mapping +> Status: RO +> +> Doug, +> We are having a problem with degenerate directory names. It appears that the +> filename mapping handles degenerate filenames, but no directory names +> contained within the path to that file. Is this correct? I would guess that +> the translation should be done in vfn_translate some where. +> fred. + +The mapping file is not used for directory names for performance reasons. +First, OS filenames are not mapped at all. An OS filename is any filename +for which ZFXDIR returns an OS directory prefix (the test is necessarily +machine dependent). Pathnames containing directory names are parsed by +VFN_TRANSLATE, extracting successive directory names. Each directory name +is processed through VFN_ENCODE to map illegal characters, then through +VFN_SQUEEZE to make it fit in an OS filename. It is possible that multiple +directory names will map to the same internal name. + +It is possible to modify the mapping code to use the mapfile for long +directory names, but I would prefer to make everyone use short names. +Is the problem with names in the system you got from us? We will change +the directory names if so. Long directory names will also lead to problems +with truncation of pathnames, hence should be avoided in any case. +> From stsci Wed Jan 23 10:40:52 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA05645; Wed, 23 Jan 85 10:06:56 mst +> Date: Wed, 23 Jan 85 10:06:56 mst +> From: stsci (Space Telescope ) +> Message-Id: <8501231706.AA05645@lyra.noao.UUCP> +> To: tody +> Status: RO +> +> DIFFERENCES /MERGED=1/OUTPUT=DISK$USER1:[IRAF.FRED]DOUG.TXT;1- +> DISK$USER1:[IRAFX.SYS.FIO]VFNTRANS.X;5- +> DISK$USER1:[IRAFX.SYS.FIO]VFNTRANS.X;4 +> +> Also, back to the static file driver. There are a number of hitches with +> mapping the file into the user's buffer. One problem with mapped sections +> is that we may run into the working set limit or paging file limit when +> mapping a file. Another is that the buffer pointer must point to a virtual +> address which has not been "created", so the pages in the user's buffer +> must be freed. The users buffer must be on a virtual page boundry. +> Also remote files cannot be used in a mapped section due +> to DECNET and RMS restrictions. Also in writting an image out to disk, the +> create mapped section cannot be into the users buffer, since the data would +> be lost, So a memory copy would be necessary. Also should a mapping be +> undone after a wait, so that the buffer can be reused, and what should +> be done about requests which overlap in some of the pages? Do you see any +> easy ways around these? In sdas a pointer to where the data is to be read +> or written is returned. This removes the problems of page overlap, memory +> copies, and page allignment. +> fred. + +I think I need to go into more detail on the scheme I had in mind for the +static file driver, including more information on how FIO works. The file +i/o zroutines are designed to be called only by FIO under carefully controlled +circumstances. + +FIO works internally by "paging" file segments the size of a FIO buffer into +the FIO buffer. A file is a series of logical pages, each the size of the +FIO buffer, which is in turn an integral number of disk blocks in size. +FIO guarantees that these logical pages will not overlap; if this were not +the case, ordinary i/o would not work properly, let alone static file i/o. + +A "file fault" occurs when i/o is done to a file segment not currently +mapped into a FIO buffer. If the file is open for RW access the file segment +will be read into the FIO buffer. This is true for both reads and writes. +A write causes the file segment to be faulted into the buffer, followed by +modification of the buffer contents. Nothing is actually written to the +file until another file fault occurs, causing the modified buffer to be updated +on disk. There is one exception to this scheme: when a write occurs which +would write the entire file segment, the read is skipped to save i/o. + +All of the above discussion concerns only FIO, and is independent of whether +the file is a static file, an ordinary disk file, a DECNET file, or whatever. +A static file is by definition a file which does not change in size while +i/o is in progress. At open time file space has already been allocated and +the system knows exactly where the file blocks are, making optimization +possible. A static file is never created by ZOPNST. It either already +exists or is preallocated by ZFALOC. + +FIO buffer space for a static file is allocated before i/o occurs (before +any sections are mapped) by the MEMIO procedure VMALLOC, which ensures that +the buffer is allocated on a virtual memory page boundary. VMALLOC calls +ZMALOC to allocate a conventional buffer larger than necessary, computes +the offset of the first page boundary, and returns a pointer to that page +to the caller. On VMS, VMALLOC would therefore allocate a potentially +large segment of storage in the paging file. The paging file space would +probably be freed very shortly therafter, but it is possible to run out +of space in the paging file if very large buffers are to be allocated. +The virtual page count limit of the process must be large enough to +accommodate the buffer, but since no i/o will be incurred the working set +size should not matter. If I understand VMS correctly, the principal +expense in allocating a large, say 1 MB buffer will be the expense of +initializing the associated 16 pages of process page table space. This will +likely incur several page faults (to fault in the pages of the page table), +plus .1 second or so to initialize the page table entries. + +The initial operations required to map an entire section into memory for FIO +are thus the following: + + open calls ZOPNST to assign a channel for the section file + VMALLOC calls ZMALOC to allocate a buffer the size of the section + (i.e., the size of the pixel storage file). Pages are + initially allocated from the system paging file. + +The next operation will almost certainly be a ZARDST to "fault" the file +into the FIO buffer, which is probably the size of the entire image. ZAWTST +would be called next to get the status of the read. No further FIO faults +would be incurred while accessing the image, since all of the data is +effectively accessible in memory. Eventually ZCLSST or possibly ZAWRST, +ZAWTST, ZCLSST would be called when the file is closed. + +I see the functions of the static file i/o routines in terms of VMS system +service calls as follows: + + ZOPNST Assign file to a channel. + + ZARDST Unmap buffer pages with $DELTVA. Map buffer pages onto + new section with $CRMPSC. + + ZAWRST Call $UPDSEC to update the section on disk. Do non unmap + pages as they may be reused. If the pages are not mapped + (very unlikely) perform a map and copy operation or just + return ERR. + + ZAWTST Static file i/o is not really asynchronous. Just return + status. + + ZSTTST Easy. + + ZCLSST Unmap all sections associated with the file. It may be + necessary to remap sections back onto the paging file to + keep the VMS memory allocator happy, but it is not necessary + for IRAF reasons since file buffer space is freed when the + file is closed. + + +Response to specific questions: + +> The users buffer must be on a virtual page boundry. + +Alignment on virtual page boundaries is not a serious problem; the +current VMALLOC procedure already does so. + +> Also remote files cannot be used in a mapped section due to DECNET and +> RMS restrictions. + +The static file driver scheme works well here because it makes it possible +to access files via DECNET if we wish to do so, by copying the data rather +than mapping it. This would be slow if the entire image were being mapped, +but might be worthwhile in some cases, since the software would at least +function. + +> In writting an image out to disk, the create mapped section cannot be into +> the users buffer, since the data would be lost, So a memory copy would +> be necessary. + +The buffer is mapped by a ZARDST call onto the section file, hence no +copy operation is necessary. ZAWRST merely updates any modified pages. + +> Also should a mapping be undone after a wait, so that the buffer can +> be reused.. + +I/o to mapped sections would not be asyncronous. The wait primitive would +only return a status value. Pages would be unmapped only at close time +and when the buffer is faulted (in a FIO sense) onto another section. + +> what should be done about requests which overlap in some of the pages? + +FIO does not permit such overlaps. FIO divides a file into a series of +logical pages the size of a FIO buffer. All i/o is initiated on logical +page boundaries. The FIO buffer is an integral number of disk blocks in +size. + +If there are serious problems with the scheme I have described (e.g., +because it does not fit the real VMS) then let me know and there are probably +things we can do. For example, VMALLOC could have a special kernel routine +instead of calling ZMALOC, and might only allocate virtual space without +mapping it, not using the VMS memory allocator at all to avoid conflicts. + + +> From stsci@aquila.noao Wed Jan 30 11:21:12 1985 +> Received: from aquila.noao.UUCP by lyra.noao.UUCP (4.12/4.7) +> id AA00912; Wed, 30 Jan 85 11:21:09 mst +> Received: by aquila.noao.UUCP (4.12/4.7) +> id AA21711; Wed, 30 Jan 85 07:28:33 mst +> Date: Wed, 30 Jan 85 07:28:33 mst +> From: stsci@aquila.noao (Space Telescope ) +> Message-Id: <8501301428.AA21711@aquila.noao.UUCP> +> To: tody@lyra.noao +> Subject: fortran hex values +> Status: RO +> +> Doug, +> We have just run into a non-protable problem. In VMS fortran hex values look +> like '111111'x and in unix fortran they look like x'111111'. Neither compiler +> will accept the other. (oops portable above). Do you know which is supposed to +> be standard??. The other way around it would be to run all fortran files +> through the cpp on our end, so that we can use ifdefs as you can under unix. +> fred. + + +The Fortran standard permits only decimal integer constants. The octal and +hex forms noted are both nonstandard exceptions and cannot be used in portable +Fortran code. There are many other things just like this, e.g., ! comments, +byte, integer*N, logical*N, etc. datatypes, nonstandard intrinsic functions, +do while, identifiers which are nonalphanumeric or which are longer than +six characters, continuation longer than a few lines, inclusion of character +in common blocks, use of normal data statement to initialize data in common +blocks, passing an integer*2 to a function which expects an integer +or vice versa, use of ichar for byte operations, and so on. A simple +preprocessor like cpp is a big help but will not solve problems like the ! +comments and identifiers longer than six chars, and I don't think it does +anything about octal, hex, character, etc. constants. + + +> ZGTENV (new kernel procedure) + + I changed the specifications trivially to make it consistent with the +other kernel procedures. See the code in the new version of IRAF I recently +sent you on tape. I also modifed TTY to permit device unit specs etc in +device names. The ZMKDIR primitive has not been specified because it is not +yet proven that we need it (I started to add it for making subdirectories +off UPARM in the CL). + + +From stsci Fri Feb 15 06:37:12 1985 +Received: by lyra.noao.UUCP (4.12/4.7) + id AA15277; Fri, 15 Feb 85 06:37:06 mst +Date: Fri, 15 Feb 85 06:37:06 mst +From: stsci (Space Telescope ) +Message-Id: <8502151337.AA15277@lyra.noao.UUCP> +To: tody +Subject: IRAF things... +Status: RO + +Doug, + +Got the tape read on to VMS with rtar; had to make some small mods to read +from tape. Seems the C lib read() function can't handle it. We found all +the different files and new files, and are remaking the entire system. + +Some thoughts and questions: + +> 1. Fred was wondering whether there exists some documentation on XC and Mklib +> other than what's in the source files. + +There is no additional documentation at present. XC is however much +like the UNIX cc and f77 commands. + +> 2. In much of the GIO, FIO, IMIO source files, you have 2 conventions for +> include files, namely include "gio.h" and include <gio.h>. This works +> fine in UNIX because you have linked files to iraf$lib/, but on VMS this +> means we have to have 2 copies of the .h files. We are taking it upon +> ourselves to change all the "fio.h", "gio.h" etc. to <fio.h>, <gio.h>,... +> It makes more sense to us, and to IRAF in general, it seems. Is this +> okay with you? + +I agree that it is best to avoid links for portability reasons, but sometimes +they make things much easier. Regarding the "file" and <file> problem, I agree +that it is desirable to have only one copy of an include file (and of course +the link provides this on UNIX). To eliminate the possibility of error on VMS +we will have to get rid of the "file" references, but only in cases where the +named file is global, i.e., referenced in more than one directory. Whenever +possible I use local include files rather than global ones to reduce the +coupling between different parts of the system, and this should not be changed. + +This problem with eliminating the local copy of a global include file is +that the package source is no longer self contained. When a package is +listed or moved the included file may be omitted. + +Include files are not the only linked files. There are also linked libraries +and executables. In all cases I have tried to restrict the number of links +to 2 to make it obvious where the second entry is. The use of links for +libraries and executables can be eliminated by use of file moves or copies, +e.g., with a "make install" in the package Makefile (see pkg$cl/). This +solution works fine for executables, but there are problems with libraries. +Probably the best solution is to modify Mklib to permit library names like +"lib$libsys.a". + +> 3. Some of the VOPS routines have .s versions as well as .x ones. The +> Makelib files don't always use the .s files, but they're there. We've +> been converting your .s files to VMS .mar files (added to the filename +> mapping pairs), and using them instead of the .x files, updating the +> Makelib files appropriately. Some of the .s files (e.g. /vops/AK/aadd*.x) +> are simply output from the fortran compiler, possibly w/ a few things +> taken out. + +Sounds good. It seems to me that we can have both the unix and vms assembler +sources in the same directory with the filename mapping selecting the file to +be used when the extension is mapped (on VMS, the UNIX files should appear +as "file\.s" in directory listings). Assembler sources which appear in +directories but which are not referenced in the Makelib are garbage and +should probably be deleted. In some cases, e.g., AADD, there may be no +advantage in having a VMS assembler version since the VMS Fortran compiler +is better than the UNIX one. + +> By the way, we changed the IPC routines on VMS to use shared memory regions +> instead of mailboxes. This was due to lots of problems we had with ^C +> interrupts and the mailbox I/O. Shared memory regions helped a lot, +> but are still prone to the problems occasionally. Your latest changes +> dealing with interrupts look they will help us a lot too. In any event, +> the shared memory IPC is much faster and seems a lot more reliable than +> mailboxes. +> +> Jay and Fred + +The bug fixes I made should help a lot but do not yet fully solve the problem. +Also, in the UNIX IPC driver I had to disable interrupts while writing a record +to ensure that the data structures would not be corrupted. You might need to +do something similar. + +What is your schedule for converting to VMS version 4.0? We are still +running 3.7, and should coordinate the conversion to 4.0 between the +observatories. The 8600 will run 4.0, and should arrive sometime in May. +We should convert to 4.0 sometime before then. + +Do not waste time trying to get the new GIO stuff working yet. We are still +actively working on the many pieces of the graphics subsystem and it is not +yet completely installed nor user tested. The GIO/NSPP kernel should be +completed later this week or next and then we will complete the installation. +I can send you a tape containing only the affected files at that time if you +wish. + Doug +> From stsci Wed Mar 6 14:00:12 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA29984; Wed, 6 Mar 85 13:59:45 mst +> Date: Wed, 6 Mar 85 13:59:45 mst +> From: stsci (Space Telescope ) +> Message-Id: <8503062059.AA29984@lyra.noao.UUCP> +> To: tody +> Subject: IRAF +> Status: RO +> +> Doug, +> +> Jay here... IRAF VMS is coming along. Having some difficulties dealing with +> 4.0 though, asI'm sure Peter has told you about. The filename mapping +> stuff in particlular - we're keeping it as 3.x filenames even though +> it would be possible to convert to the nice longer ones in 4.0. +> But then it's not possible to go back very easily. W Something we have +> to think about some more and which Peter may talk with you about. + +At some point we should reconfigure the system to use the long filenames. +This requires reloading the system with RTAR, editing the filename parameters +in the <config.h> file, and recompiling the system. Any system dependent +makefiles or VMS .com files you guys have added would also have to be changed. +I am considering renaming some files in the directories for the core system +to minimize these sorts of problems, allowing us to get the basic system up +and running and then use the system to handle the filename mapping required +for the applications directories. This does not solve the Make problem unless +we add an IRAF Make to the SOFTOOLS package, which is probably the thing to do. + +> Your ideas on using mapped sections for the VMS static file driver look +> okay, thou and should work, with some slight mods, +> but we haven't gotten around +> to it yet (may be lots of line noise here...). +> Also some other enhandcements +> are in the queue for VMS, time allowallowing... +> +> Had a question re Help and Help dtaatabases. +> In SDAS, we have 2 choices for +> Help under IRAF - 1) use 1 big Help db with IRAF and SDAS help combined, or +> 2) have a separate SDAS help db. I've done some simple tests with 2 +> separate dbs and it doesn't look to good. If you've run help in IRAF and +> then turn around and specify a new db, does the new database get read +> in entirely? One can envision an SDASHELP script that does: +> set helpdb=sdas$sdas.db +> help ... +> set helpdb=dev$help.db +> But this method can be terribly slow if you go back and forth between IRAF +> and SDAS help and requires a separater task , SDASHELP, to invoke it. +> +> Maybe I'm not don't fully understand the details of the +> helpdb stuff...would it be +> possible to have a couple of helpdb's loaded in memory at the same time, or +> a list of helpdb's to search in the event of a 'help'.? Or, should we +> just use one huge helpdb for IRAF and SDAS and avoid all these problems?? + + Jay + +I think the best solution is for each system to have one big help database +for all packages. I see no problem with this, but the current help database +facilities are probably not up to the task and will have to be replaced +eventually possibly with a DBIO based version. + + +> From stsci Sat Apr 6 07:52:33 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA07328; Sat, 6 Apr 85 07:52:27 mst +> Date: Sat, 6 Apr 85 07:52:27 mst +> From: stsci (Space Telescope ) +> Message-Id: <8504061452.AA07328@lyra.noao.UUCP> +> To: tody +> Subject: Mapped sections on VMS +> Status: RO +> +> Doug, +> +> Finally got around to implementing a static file driver for VMS using mapped +> sections. Your ideas were partially used here, as well as the stuff I threw +> together for the IPC driver using shared global sections. However, there +> are 2 problems which don't want to be solved very easily. +> +> 1. When closing a static file (mapped section file), the pages must +> be unmapped. Since they are mapped within the IMIO via VMALLOC, +> I can't unmap them at the Z-routine level because of the way ZMALOC +> works (puts the count in the longword ahead of the returned buffer +> address). So the pages must be unmapped before the call to ZCLSSF. +> +> However, I have not been able to get this to work. That is, even +> unmapping the pages and then closing the file doesn't work very well +> This may be due to some incompatabilities between the $CRMSPC +> ssystem +> service and the LIB$GET_VM() routine used by ZMALOC to get virtual +> memory. Seems that using the $CREVTA (create virt address space) +> doesn't work too well with the LIB$GET_VM - in fact, DEC warns about +> using them together, since they don't communicate with each other. +> +> The effect of this is that the image file remains open until your +> executable image exits - the close doesn't really close... +> +> The only way I see around this is to rewrite ZMALOC/ZRALOC/ZMFREE +> to use $CREVTA/$DELVTA and then hope for the best, or possibly +> use another idea you had, of having a special Z-routine for a +> allocating virtual memory on page boundaries w/out mapping it... +> maybe that would work, as long as the pixel-file buffers were +> unmapped before the call to ZCLSSF. + +I thought the memory allocation might be a problem, in which case the best +solution is probably to add two new kernel procedures (sigh) to be used to +allocate and free pages of virtual memory independently of the ZMALOC allocation +facilities. The pages would initially be unmapped and would not get mapped +until a ZARDSF call was made. Since we would then be able to package the +virtual memory allocator and static file driver together in a self contained +unit, we should be able to do whatever needs to be done to make it all work. +If this looks reasonable I will have to generate some specifications for the +kernel procedures and work out the details of the high level code (not a big +task). + +> 2. If you open an image file w/ READ_WRITE access, any changes made +> to the buffer will be made in the file, whether or not a call to +> ZAWRSF is made. This is the way mapped sections work on VMS and +> I haven't found a way around it yet. This could be a potentially +> major obstacle... + +I don't see any problem here. If FIO writes into a buffer opened on a file +with read write access, the file is expected to be modified. The only +difference between this and normal i/o is that the write may occur sooner +and cannot be cancelled, but there is no software in the system which depends +upon such subtle semantics. + +> Peter probably talked to you a few times about device specifications within +> IRAF, possibly of the form set stdimage=(iis,image_unit_2) or something of +> the sort. Support for this is definitely needed at some higher level than +> the kernel. For the line printer driver, I had to play all kinds of games to +> map the printer names without having to recompile the ZFIOLP source and relink +> the system package. Basically, I used some VMS means to find out where +> iraf$dev/ was and then read a file called "lprtable.vms" which had things like +> +> qms LCA0 +> printronix SYS$PRINT +> +> By setting printer=qms for example, 'qms' would be looked up in termcap and +> satisfy all that stuff, then at the ZFIOLP level, qms would be mapped to +> the VMS queue LCA0. +> +> For things like this, it would be nice to have some system-dependent device +> mapping table that is read at a level higher than the kernel, that would +> map a device-type (for termcap/graphcap/printcap/...) +> into an OS/system-dependent +> name or queue_name. For example: +> +> qms LCA0 +> deanza ABC0: (i.e. some VMS device name) +> ... +> +> I know it's easy in UNIX to have these tables built into the kernel, so all +> you do is a 'make' and IRAF is remade. In VMS, this is not so easy, and we +> would like to be able to distribute executables. Also, our RCSMake hasn't +> worked since VMS V4.0 came along -- we're using Mklib and DCL command +> procedures everywhere. +> +> I think this kind of device mapping would not be hard and would make it easy +> to add devices without remaking part of the system. + +I agree that a runtime table lookup would be nicer in some cases than a +compiled table. I suspect however that the structure and contents of the table +may be too machine dependent to be worth trying to standardize. The easiest +solution may be to have the kernel read the table, rather than IRAF. In that +case it may be more appropriate to put the table in the OS directory, rather +than in DEV. It would not be difficult to call to the ZFIOTX primitives +directly to read such a table. + +Some information can now be included in the device specification in the +CL environment. Peter mentioned a syntax such as + + deanza!unit=2 + +or some such. Anything can follow the ! and is assumed to be system +dependent. The high level code will ignore the ! and all that follows +in the termcap and graphcap access, but will pass the full string on to +the kernel to parse as it wishes. + + +> From stsci Thu May 9 05:41:11 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA17243; Thu, 9 May 85 05:41:06 mst +> Date: Thu, 9 May 85 05:41:06 mst +> From: stsci (Space Telescope) +> Message-Id: <8505091241.AA17243@lyra.noao.UUCP> +> To: tody +> Subject: IRAF +> Status: RO +> +> Doug, +> +> Jay here; have had a hell of a time trying to login to your system, though I +> think it's a problem with our phone system - which means you're probably +> having trouble getting in to ours as you did before. + +I have been having lots of trouble getting modem access, but have not tried +it for a week or so. The next test will be trying to send this mail. + +> In any event, a few items/questions... +> +> Peter talked to you about the filename mapping and using actual VMS names in +> the CL. We initially thought it was a filename mapping problem, but you were +> right in that it is already handled quite well. The problem, as we quickly +> discovered, is that most of the tasks which open files, handle lists of files +> and templates. The template matching code is the problem with respect to +> VMS names, since things like "[a-zA-Z0-9]*" can be used as a filename, and +> using a VMS name like [iraf.jay.cl]file.dat is processed as a template. +> I don't see a real easy way around it - Peter's suggestion about quoting all +> OS-dependent entities with !'s may be the answer, meaning VMS names would +> be ![iraf.jay.cl]file.dat! on the command line... Sorry if you went about +> the filename mapping code looking for this non-existent bug... If !'s are +> used, some higher-level decoding must be done, but I'm not sure exactly where, +> probably in the template stuff and the filename mapping... + +I see the problem now and of course you are right, the template expansion code +is at fault. It is not out of the question to consider changing the logical +directory metacharacter to something less troublesome, e.g., one of "!@%^". +It should be a character which satisifes the following criteria: + + not routinely used in filenames on any of our target systems + not an operator character when "lexmodes=yes" + +Unfortunately the $ fails criteria number one. Let me know what you think of +such a change and I will discuss it with my group in a meeting on Wednesday. +It is not too late to make such a change if it will make life significantly +easier on VMS. + +> Sometimes (a lot less now than before) we have a situation where a connected +> subprocess gets astray and is running while we are back at the CL, i.e. doing +> a 'prcache' shows a state of 'R' for the process. 'Flprcache' can't kill it, +> and on logout, the CL will hang forever for what is seemingly a running +> process. Is there a way we can just kill these guys off, especially on +> logout? Seems to +> me that connected subprocesses should never be asynchronous anyway, so being +> in this state is really an error, though maybe there are future ideas I'm not +> aware of. In any event, sometimes an interrupt at a certain time can put a +> subprocess in this sort of state and making logging out hang the process, and +> the user will need to type ^Y to get out on VMS. Have you seen this type of +> occurence on Unix, and if so, have you any ideas on how we might combat this +> portably? If you don't see it there, we can just do some "#if vms" sections +> in the CL to make sure subprocesses die on logout, but I'm hoping for a more +> portable method. + +We also sometimes get hung processes with state R (apparently running). This +happens rarely but is evidently a bug in the system independent code, which +I will fix eventually. I may not be able to prevent processes from getting +into such a state, but I should be able to make the system detect such a state +and recover automatically. + + - Doug + 13 April 85 +> From stsci Thu May 23 06:16:18 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA11890; Thu, 23 May 85 06:16:14 mst +> Date: Thu, 23 May 85 06:16:14 mst +> From: stsci (Space Telescope) +> Message-Id: <8505231316.AA11890@lyra.noao.UUCP> +> To: tody +> Subject: major portability problem in fortran +> Status: R +> +> Doug, +> We have run into a snag up here. The problem is with fortran integer +> constants. We currently have iraf moved over to the Sun and I was working +> at getting it up and running. It seems that all integer constants are +> passed as I*4. This causes problems for functions that expect I*2 values +> (xpp character constants). Due to the byte ordering the value which +> gets to the other end is the high bytes rather than the low bytes of the +> I*4. This problem would also exist going from I*2 to I*4. Do you know +> of any easy (portable) way to type cast constants in fortran. The other +> method I considered was putting he character constants into the string +> array that gets created by either rpp or xpp (I can't remember which). This +> would solve the problem for xpp characters, but would not solve any +> problems for xpp routines expecting short parameters and getting an I*4 +> constant. +> fred. +> + +1. Discussion + + I knew this would be a problem but could see no easy way to address the +problem until we had access to a non-DEC machine with the bytes in an integer +reversed. It is considered an error in SPP if the programmer declares an +argument as I*2 and passes an I*2, or vice versa. Similar problems occur if +the mismatched types are int and long or int and bool, or if a procedure is +passed the wrong number of arguments. Such bugs will go unnoticed on a DEC +machine because of the architecture (or Fortran implementation). The first +port of IRAF to a non-DEC machine will require finding all such bugs. + +I had always planned that my group would do this kind of debugging, but have +no objection if you wish to push ahead and find the bugs for us. The rule is +that an integer constant appearing in an argument list must be declared as +an integer argument in the called procedure. If a short, char, or long is +required than an explicit type coercion must be used, e.g., "(a,long(1),b)". +A character constant, e.g., 'a', is defined as an operand of type char. + +It is up to the programmer to use explicit type coercion where necessary to +match the datatypes of actual and dummy arguments. In the case of the +character constant I expected that we would have to add a switch to the +preprocessor to automatically add a call to a I*2 coercion function when +a character constant is used as an argument to a procedure. Of course +Fortran does not define such a function since I*2 is itself non standard +Fortran. The VAX/UNIX Fortran compiler does not provide such a function, +but then none is required since I*2 and I*4 are interchangeable as arguments +on the VAX. Compilers for machines where this is not the case would hopefully +provide such functions. The AOS compiler does, but I never checked the +UNIX implementation on non-Dec machines. It does not surprise me if the +SUN/UNIX Fortran compiler omits the INT2 and INT4 (or whatever) intrinsic +functions. + +My plan if the host compiler did not provide INT2 and INT4 intrinsic functions +was for the compiler to generate a Fortran temporary variable of the necessary +type. This will always work but requires care to implement in the current +preprocessor due to the complications of statement labels, error checking, etc. +If the time has come then I can do this or perhaps you would like to have a +go. An easier, but less attractive solution might be to add the intrinsic +functions to the Fortran compiler itself and report the extension to SUN. +If this were done the Fortran generated for 'a' would be 'int2(97)' when the +paren level is greater than zero, skip the INT2 otherwise. + +In retrospect I think it would have been better to define character constants +as integer rather than char values. It is not too late to make such a change +to the language definition but doing so will introduce bugs into existing code. +Since we have not already debugged such code, this is not a great problem. +Rather than find such bugs at run time, I would do a pattern search of the +entire system looking for occurrences of ' within parens, then examine each +such occurence interactively. We should really do this ourselves for our +own code, rather than having you guys do it. + + +2. Conclusions + + Having thought all this through, I think the best course of action is the +following: + + [1] Change the SPP language definition to define a character constant as an + integer, rather than char value, e.g., 'a' would be exactly equivalent + to 97 in all contexts. + + [2] Modify XPP to declare and initialize hidden Fortran I*2 and I*4 + intermediate variables whenever the coercion functions "short", "char", + or "long" appear in SPP code within the body of a procedure. + +It would be best for NOAO to do this since we are responsible for the code +which is causing the problem. There is a big merge coming up with the +installation of VMS IRAF at NOAO, and that would be an appropriate time to +address the problem. If you cannot wait and wish to forge ahead, feel free +to do so, but please keep notes on the changes required (I would expect there +will be only a few dozen such occurrences). + + +3. Other + + We are in the process of submitting a request to NSF to purchase a SUN +system for delivery this fall to Tucson. I plan to port IRAF to the SUN, +including special performance enhacements for disk access and an interface +for the Sky Warrior array processor. Anything you guys (or JPL) do in the +interim will of course help make this easier. + +The JPL port to the JUPITER running the ISI version of 4.2BSD UNIX has run +into serious problems with the ISI Fortran compiler, which turns out to be +untested and quite buggy. An AOS port has also begun, with Steward doing +most of the work. I would like to eliminate this type of bugs from the system +before these sites really attempt to bring the system up. + +By the way, in the process of trying to compile IRAF on the JPL system we +found two bugs in the SPP compiler, both caused by the wrong number of +arguments to a procedure. One was in XPP (xppcode.c) and can be found with +LINT. The other was in RPP in the file "rpprat/errchk.r", in the call to the +procedure GNBTOK. Presumably you have already found both of these problems +since you have already succeeded in compiling the system. + +Other bugs were found in OSB in the same port. Some of the ACHT procedures +had bugs, the Makelib file had a bug. In OS in the ZCALL file, "pointer to +function" was being used where "function" was required; the UNIX/C compiler +does not complain about such usage. If you have not already found these +I can supply notes (they will be fixed on the next tape you receive in any +case). +> From stsci Thu Jul 11 05:33:23 1985 +> +> Doug, a few short notes... +> +> 1. XPP +> +> The 'lexyy.c' file for the new XPP (output of 'xpp.l') causes the VMS C V1.5 +> compiler to bomb of a symbol table overflow, so we're still using the old +> XPP. I tried the C V2.0 compiler (on our 8600) and it fixes this problem, +> but spouts out other warnings; I'll have to check them out when it gets +> installed on our machine. This is just a warning; I don't know which +> version you're running. + +I have had the V2.0 C compiler installed on the 8600 and that is what I will +be using when I recompile the CL etc., hope it does not give serious problems. + +> 2. RPP +> +> The file '...imdis/cv/load.x' causes RPP to stop somewhere and say it's +> got a storage overflow. I split the file into 2 files (load1.x and load2.x) +> and things work okay. Don't know if you have this problem, too. + +Just want to make sure you know (I already told Peter) that the CV code is +preliminary and will be changed significantly. I am not happy with it yet +and it will be reworked considerably before being installed (ideally the +display interface subroutines Starlink is working on would come along in time +to prevent a third major revision). On the other hand, either the old display +using the IMIO interface or the new CVL (to eventually replace "display" and +inherit the same name) are both infinitely faster than the infamous SDAS image +load code I have been hearing about. PLEASE SPEED THAT THING UP!! I have +been overhearing comments from the astronomical community about how slow "IRAF" +is, following the recent SDAS/IRAF demo. People do not understand that IRAF +and SDAS are quite different things, or that SDAS is not using IRAF yet for +anything having to do with image display or vector graphics. + +The IRAF image load software runs 12 clock seconds on an unloaded 750, and +should run twice as fast as that on a 780 with its faster cpu and faster, +asynchronous i/o system (512 square by 16 bit image). Note that only standard +hight level IRAF interface software is being used and the DISPLAY program is +a sophisticated program with lots of fancy options. This proves that is it +possible to have features and speed, too. + +> 3. VMS Kernel +> +> I wrote an assembler version of the str*() routines for VMS last year to +> remove dependencies on the VMS C libraries (str.mar). There are 2 +> "phantoms" in there that have been known to cause access violations at +> randomly spaced intervals and disappear when you try to throw in extra +> code to debug them. The two lines containing the 'DECB' instruction should +> be changed to 'DECL' instead; subtracting 1 from an address can have strange +> effects when only the low-order byte is changed! This is an old phantom +> which has finally been killed, but as we all know, phantoms have brothers... +> +> Jay + +Unless it can be demonstrated that the assembler versions of the string +routines are a good deal faster than the C versions in LIBC, I do not plan +to use them. I will look at the /mach output for the C versions before +deciding. If the assembler versions used (already use?) the VMS string +instructions that would be different. + |