CAC 2019-07-08 Coding needed

— One of the big things on deck is a 2.0 release (synchronized with a Multics 12.6g release). Open issues are platform testing — build, test and document various platforms. Most of the development and testing is done on Fedora, so Windows, MacOS, major LInux distros and various h/w (Pi) need attention. (We don't have a coordinated plan for this.)

— Better regression testing. We need a automated regression test. I have some regression tests, but result processing is poor.

— Pi performance issues. The emulator runs spectacularly badly on Pi's — it looks like the issue is poor cache performance. The code and data need reorganizing to improve things, but tools to analyze the hot spots are sparse. Tracking down some useful tools and doing some code tuning would be good for all platforms.

— Socket library. The Multics networking code was an unbundled product, and has been lost. We have have the start of code that works like a RPC call to socket devices, so the host system's network stack is used.

— FNP modem pool. trn wrote some code to manage multiple modem pools. This code need to be integrated in.

— FNP code robustness. There have been some crashes in the FNP code. That code relies heavily on uvlib, but the code that calls that library is not robust. libuv state is complex, and better error checking around the libuv calls is need to deal with unexpected events (hangups, signals).

— FNP line speed throttling.

— X.25 emulation. Multics "supports" Multics-to-Multics" over X.25; code to run in the FNP that mimics the needed X.25 states over a TCP connection. Advanced: connect to X.25 modem.

— Integrated ISOLTS support. ISOLTS is comprehensive CPU test suite that runs on multiple CPU systems. (It takes a designated CPU offline, remaps it memory, and runs the test code on it, leaving Multics running on the remaining CPUs.) We got it running a doing a single threaded multiple CPU system with a round-robin instruction scheduler (execute an instruction on CPU A, on B, on A…..). We now support multiple CPUs with multiple threads, but ISOLTS also requires mangling the memory map on the designated CPU. A plan to support that mangling without excessive overhead is needed.

— The Multics C compiler is near useless. I have a start of a VBCC backend.

— Optimization. Currently, the emulator spends most of it's time in doAppendCycle, which is a ginormous chunk of code that does many functions. It may be that replacing it with a half-dozen or so routines that perform a single function (instruction fetch, indirect operand fetch, …) might help A) the optimizer and B) better identify bottlenecks. Conceptually simple, but may be labor intensive to implement, as in some cases the particular needed function is passed in through several layers. There may also be some chances for data caching in the code which could help ("The last time I did this function, the address was on the same page and the page tables have not been updated, so I can skip a whole bunch of page table lookup and error checks").

— Improved emulator infrastructure. The emulator is outgrowing SIMH. We need better ways of emulating machine room operations (mounting tapes and disks) and hardware reconfiguration. Configuration management is particularly hairy. It was difficult back in the day, and the ability of the emulator to conjure up new pieces of multi-million dollar kit at the flip of a switch doesn't help. (Eight CPUs? No problem: "set cpu nunits=8". Configuring? Add a hundred "cable" commands to the startup and and a bunch of lines to the config deck.) We need tools to help manage this. For example, I started on some code that reads the emulator configuration and updates the Multics config deck to match; hopefully keeping them synchronized and relieving me of writing the short novel that documents the mapping between SIHM nomenclature and Multics.

— T&D tape. Tthe T&D tape now longer boots. (It used to boot, run a half-dozen test sets, that then start endlessly searching the tape, rewinding. and searching again; no-one could figure out if what it was trying to do. It might be a damaged tape image, a bug in the IOM/tape controller, or a configuration issue.)  Currently, it looks like at some point we broke the IOM and it no longer correctly parses the channel control programs that the T&D tape uses. (I think the tally word is being ignored; Multics reliably uses the DCW control bits to indicate end of program; I have spent way too much time struggling with the IOM code, and the lack of source code for the T&D tape makes the task enormously difficult.)

Advanced things that are not bugs per se, but are not implemented "correctly":

—— Several of the instructions are macro instructions — string handling, memory move, etc — that loop over N data items, and are restartable after a fault. The hardware saved operand pointers on fault, but the emulator only saves N and recomputes the pointers on restart. This was originally done because the format of the pointer storage was undefined and it was believed that insufficient bits were available. Over time, better understanding of the save data has located more bits, and plausible formats for storage can be constructed. (Additionally, there may be clues to the format in the Multics debuggers and crash analyzers.)

—— The decimal math instructions use the DECPUN library. For every instruction, the operands are converted to DECPUN format; DECPUN does its arbitrary length math calculations on the converted operands; the result is converted back. Losing the DECPUN library would be nice.

Way outside the box:

—- FNP emulation. The start of a instruction level FNP emulation is in place. The CPU is mostly coded, but the IOM and device controllers are not started.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License