10

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?

Improve this question
9
  • 3
    Modern languages like C++, D and Rust would love such an instruction to implement atomic move semantic perfectly.
    – Patrick Schlüter
    Apr 13, 2021 at 5:54
  • 2
    Another interesting variation would be read-modify-write instructions that don't bother rewriting the original value.
    – DoxyLover
    Apr 13, 2021 at 7:43
  • 3
    I haven't seen such an instruction. I don't know the reason, but I'd assume it doesn't make execution faster (after reading a value, you still have to do something with it, so you may as well concurrently write back the old value), and the added complexity for all the many commands that access memory just wasn't worth the benefit. Read-modify-write instructions do indeed exist, for example already on the PDP-1.
    – dirkt
    Apr 13, 2021 at 10:23
  • 2
    Another funny fact is that the currently used so-called 'ferroelectric RAM' has exactly the same destructive reads as core memory had.
    – lvd
    Apr 13, 2021 at 18:38
  • 2
    @lvd DRAM also destroys the memory when it is read but the rewrite is so deeply burried inside the circuit that it doesn't appear as such. One can look at Ken Shirrifs analysis of the MK4116.
    – Patrick Schlüter
    Apr 14, 2021 at 15:10

2 Answers 2

Reset to default
7

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, 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.

Improve this answer
4
  • 1
    So does a reset need to clear the whole nest?
    – Lorraine
    Apr 14, 2021 at 9:55
  • 1
    Director software needs to do it on machine startup. From what I recall, you set the nest full (of unknown content) and then pop off at least 16 cells.
    – another-dave
    Apr 14, 2021 at 11:43
  • 1
    Why clear the location and then OR the value to store it?
    – Lorraine
    Apr 14, 2021 at 13:04
  • 2
    A nest read leaves a cell as zero because it's faster to not write the content back. A normal store-to-core would be a read cycle to clear the existing content, followed by the write cycle. A store-to-nest can skip the read cycle.
    – another-dave
    Apr 14, 2021 at 13:36
3

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 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 in relation to synchronisation instructions.

Improve this answer
5
  • 2
    In some destructive-read technologies such as DRAM, the act of reading will leave memory in an undefined state, but in other technologies such as core, the act of reading will always set memory to a particular state. I don't know whether core read sense amplifiers would have been capable of detecting both 0-1 and 1-0 transitions, but it could have been interesting for an architecture to include an instruction which simultaneously stores a value and observes which bits changed, thus making an "exchange" operation faster than a non-destructive read.
    – supercat
    Apr 14, 2021 at 15:05
  • 1
    I looked up TS in the S/360 P.Ops manual, just out of curiosity. Only bit 0 of the fetched byte is used to set the condition code, so it's effectively limited to a single bit. Also, FWIW, the original ed. of the P.Ops did not have TS, but the 7th ed. (the next one available on bitsavers) has it.
    – another-dave
    Apr 15, 2021 at 1:29
  • 1
    @another-dave But it sets the whole byte, right? Otehrwise I might have used it wrong for 30 years :))
    – Raffzahn
    Apr 15, 2021 at 1:31
  • 2
    Yes - whole byte. You do not have 30 years worth of accumulated bugs to fix. Not on account of TS misuse, anyway.
    – another-dave
    Apr 15, 2021 at 1:43
  • 1
    I mean we only used it as x'FF' or x'00'. This was so standard, I never looked that detail up - or more likely, forgot about it. Fascinating how habit shapes knowledge.
    – Raffzahn
    Apr 15, 2021 at 10:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .