Question: Magnetic core, the primary form of computer memory from the mid-fifties to the early seventies or thereabouts, had the slightly awkward property that reading it erased it, so every time the CPU performed a read, it had to spend an extra few microseconds writing back the word it just read.

It just occurred to me that you should be able to make such a computer more efficient by providing a variant instruction, read-and-erase, whose architectural specification would be 'read a word from memory into a register, and erase the memory location just read', and whose implementation would be 'read, and don't bother writing back'. It only occasionally happens in real code that you want to read a memory location and set it to zero, but it quite often happens that you don't care, you know the value in that memory location will only be used once, so it would be nice to save a few microseconds by skipping the writeback.

Did any computers of that era, provide such a variant instruction? If not, why not? Is there any disadvantage I am missing?

Answer: 
Yes. Sort of.

The KDF9 had an accumulator stack (the 'nesting store' or nest) which was mostly made of fast (1µs read, 1.5µs write) core - the top 3 elements were in fast registers, with 16 words of core underneath.

Arithmetic was done on the top elements of the nest, popping off operands and pushing the result in the usual manner. Though the top cells were in fast registers, any addition/removal there implied a change in the core part of the nest. This did not physically move contents up and down the stack, of course - a register tracked logical top of stack.

Once a word was popped off the core stack, the core location that had held that word was no longer accessible, so it did not matter if it had been erased by the read. There was no write-back cycle for the nest.

In fact, the erase was essential, since a push or'd the new content into the core location (\*1). Unused nest locations must therefore be zero.

See section 4.2 in [*The Hardware of the KDF9*](http://www.findlayw.plus.com/KDF9/The%20Hardware%20of%20the%20KDF9.pdf), by Bill Findlay.

So - implicitly, all operations on the nest were of the read-and-erase kind.

There was a separate return-address stack, the SJNS or Subroutine Jump Nesting Store, which likely did the same thing.

---

(\*1) Core store writes normally do a read cycle first, to zero the location, followed by a write to flip the magnetization direction of the bits that are to be set to 1 (effectively or'ing the new data into the word of zeroes). The read cycle was omitted for pushes onto the nest. That is, there are two complementary performance enhancements in the KDF9 nest. By omitting the write cycle on a pop, the cell is left clear, so you can then omit the read cycle on a push.
> 
> Did any computers of that era, provide such a variant instruction?
> 
> 
> 

Kind of, the /360 (1964) implemented a Test and Set (TS) instruction for process synchronisation. A byte addressed was read, tested for zero/not zero (\*1) and written back with all bits set (X'FF'). This write back was done not by the CPU in a follow up write access, but by the memory interface as part of the Read/Refresh cycle, thus guaranteed being as atomic as it ever can get (\*2)

> 
> Is there any disadvantage I am missing?
> 
> 
> 

Not writing back is a bad idea as it leaves memory in an undefined state - a classic source for program errors to hit. Also, any way to do so would need the write back being an active action from the CPU. Something maybe inherent on small/slow machines, designed to save money. On any computer that is about performance the refresh cycle would be done by the memory controller, independent of the CPU.

---

Nice modern fact, even though the /370 added a way more capable Compare and Swap (CS) instruction, which way more handy for managing linked lists in a multi-process(or) system, [TS still performs better](https://www.ibm.com/docs/en/ztpf/2020?topic=configuration-test-set-instruction) on even the newest zSeries machines - exactly due the way that the change is quite local, needs less resources and can be done without waiting for the CPU.

---

\*1 - While I think that the whole byte that was tested - at least that's the way I always used it, it might as well be only the high bit - or at least only on some machines.

\*2 - This has already [been mentioned](https://retrocomputing.stackexchange.com/questions/11937/how-was-concurrent-programming-achieved-on-the-pdp-10/11939#11939) in relation to synchronisation instructions.