Talk:TSS/8

This article is rated Stub-class on Wikipedia's content assessment scale.
It is of interest to the following WikiProjects:

Computing: Software

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on the project's importance scale.
	This article is supported by WikiProject Software.
	This article has been automatically rated by a bot or other tool as Stub-class because it uses a stub template. Please ensure the assessment is correct before removing the `\|auto=` parameter.
	An editor has requested that an image or photograph be added to this article.

Re-entrancy bug

Footnote 4 to the TSS-8 paper by van de Goor, Bell and Witcraft (https://pdfs.semanticscholar.org/a353/7908df82b90c2f7390ae9f9cf27d78bca2b2.pdf) makes the ominous remark that, "Reentrant programs cannot easily be written. The subroutine calling instruction JMS places the return address in the subroutine. Also, the PDP-8 does not have index registers, thus it is difficult to access different data areas associated with a common process."

Nevertheless, the TSS-8 operating system attempted to handle certain cases of re-entrancy, such as when a file request occurred during the processing of another file request. The system placed the registers (PC, L, AC, MQ) describing the state into a set of temporary memory locations--not onto a stack, processed the new request, restored the registers, and returned to the previous request. In retrospect, this was clearly a blunder, because if the machine had enough memory to support several users (such as a full 32k word system) several simultaneous file requests could occur in real time, rather than being queued for swapping.

The usual error in such cases would be the loss of a return point within a user program, crashing only the user's virtual machine, but if a system field's return point (field 0, RMON) were lost, privileged control would pass to an incorrect place within field 0, resulting in a system crash.

The error was discovered through laborious crash-dump analysis about 1973 by a high-school student working a summer job at Systems for Educational Time Sharing (SETS) in Waltham, Massachusetts, where crashes were occurring about once per day. Snezzy (talk) 10:16, 23 August 2017 (UTC)[reply]