This old Algol68 code is a part of a database system for the results of statistical mechanical calculations. The computed data could be later retrieved for further processing. This self-contained code converted retrieval requests into the request language of the underlying hierarchical database, expanding the abbreviations for sequences of data sets.
The code illustrates parsing via a Turing-like machine -- so called Glushkov R-Technology. I implemented what I understood from a quick glance through Glushkov's book a few years earlier.
This PL/I code was written for simple text editing of source code files on an IBM mainframe (clone) that had no interactive editing devices save the operator console. The only way to edit source code disk files was to punch the changes on cards and submit a batch job to apply the changes, with the help of the system utility IEBUPDTE. Even if a user had access to a machine room, he still had to punch the updates on cards and run that batch job. That was quite inconvenient. This trivial utility was written to help such users fix simple errors in their source code files from the operator console. I had used the utility on many occasions -- until our computing center got display terminals.
This Modula-2 code is part of a larger project, an emulator of a non-traditional vector FPGA-like CPU architecture. Unlike the familiar FPGA, the processing elements (nodes) are connected in a full binary tree rather than in a regular rectangular mesh. The architecture was designed by Dr. Makarov at Kazan State University in 1987-1988. Besides the emulator, the project implemented higher-level operations like multiplication and division of integral and floating-point numbers.
Given below are general-purpose utilities and the user-interface-related code. As to the emulator proper, I do not feel I have the right to say anything more about it or the target CPU architecture. I am not aware of its further development.
I used the Modula-2 system developed by the `Interface Technologies Corporation'. The system included a smart, syntax-sensitive editor. The editor made sure that at all times the program is syntactically correct -- which sometimes was a hindrance.
Kbd and TIO implement low-level terminal i/o via BIOS and DOS interrupts. TIO also supports character escapes and printf-like formatted output. The module Window lets one write text into rectangular areas on the screen, supporting line wrap-around, scrolling, colors, and cursor positioning. The module used BIOS interrupts and directly accessed the videoRAM. On the top of these modules, MWDr implements a line editor and a menu processor. The utility modules include Lexem (string tokenizer) and Set (finite maps).The archetype of file integrity checking is tripwire, written by Gene Kim and Eugene Spafford at Purdue University in 1992 for the purpose of detecting modifications to system files, as signs of malicious activity. In the initialization mode, tripwire computes hashes (i.e., checksums) of system files and records them in a special file. In the checking mode, the tool recomputes the file hashes and compares them with the those recorded earlier. The mismatch indicates the file has been tampered with, e.g., infected by a virus.
Back in 1988 I have written the identical tool, called CHECKDS, for an IBM System/360 clone (EC-1033). The purpose was not checking for viruses however. I was alarmed by the corruption of a file on my (29 MB) disk pack. I wanted to detect such corruption early so I could correct the file or restore it from the backup. I would run CHECKDS from time to time, checking checksums of important disk files against the previously computed values.
The program CHECKDS was quite atypical System/360 program: it was opening dynamically-named files: the names of the files (called `data sets' in System/360 parlance) to check were read from another file. Normally, all files needed for a program must be reserved in advance of program execution and hence described on JCL DD-cards. In the batch-oriented System/360, the names of all files opened by a program must be statically known. Opening files whose names are computed was very rare, requiring special knowledge and administrative privilege (so-called ``zero memory key'', to modify operating system tables).
The program CHECKDS had another peculiarity: it processed so-called library files (``partitioned data sets'', in the official terminology) as if they were ordinary (i.e., sequential) data sets, which may contain records of zero length. Such records separate library members. Normally reading a record of zero length raises the end-of-data indicator. To ignore zero-size records when reading a partitioned data set, CHECKDS installs a call-back (formally called ``IO appendix'') to be executed upon the completion of IO channel operations. The call-back will check for the zero-length record and reset the error indicator. Installing IO callbacks too required zero memory key.
About a year later, working on a micro-computer, a clone of PDP-11, I had to check for corruption of disk files again. Soviet-built computers were notably unreliable. The disk controller of that particular computer broke down. A friend of mine, a remarkable electrical engineer, identified the failure in the checksum computation circuit, which he managed to disable. The computer could work again but disk data corruption could no longer be detected. I had to compensate for faulty hardware with software.
verify.c [9K]
The commented C code; DEC RT-11/XM operating system
oleg-at-pobox.com or oleg-at-okmij.org
Your comments, problem reports, questions are very welcome!
Converted from HSXML by HSXML->HTML