The Cray-1 had memory management hardware similar to that on DEC PDP-10s that had KA-10 processors and numerous 68K Unix workstations in the '80s, all of which served as interactive time sharing systems just fine.
The memory management hardware in those systems would take the addresses generated by the instructions, compare them to a limit register, and if below the limit would then add them to a base register to get the final memory address. Some systems would have more than one pair of base/limit registers, such as a pair for code and pair for data.
Some people do call such systems virtual memory, because the addresses specified in the code are not the addresses that the memory sees (unless the base register contains 0). But I think it was more common for systems where all the MMU did was simply relocate segments and all of the program's code and data had to be in memory for the program to run to not be considered to be virtual memory. Virtual memory usually meant systems that allowed you to run programs that used address spaces larger than the available memory.
Back in the day, the KA10 under Tops10 could “go virtual” which meant that some of the processes would overflow to spinning metal, either disk or IIRC drum. Otherwise the various processes would all be in RAM.
Yeah, the total size of all processes could be more than the available RAM. The key difference between systems like TOPS-10 on a KA10 and the systems people usually reserved the word "virtual memory" for is that to run a given process on TOPS-10 on a KA10 the processes had to be entirely in RAM. If a process had say 100k words of code, you need to give in 100k words of contiguous RAM for its code segment.
If you had two processes that each needed 100% of the RAM that was available for user program the operating system would have to keep one in RAM and one swapped entirely out to disk or drum. On a task switch it would have entirely swap out the current process, and entirely swap in the other process.
Even if each process was actually spending most of its time in just 10% of its code and most of the time was just actively using 10% of its data, it had to have 100% of its code and 100% of its data present.
The systems people usually gave the name virtual memory to had more sophisticated memory management hardware that would let them map a continuous process address space to a discontinuous physical address space, and you could have gaps in the mapping. Attempts to access gaps would interrupt the process in a resumable way, so the OS could handle that interrupt, map memory into that gap, and resume the process. With these systems they could run both of those 100% memory using programs at the same time while only having to actually allocate enough RAM to cover the 10% of the memory that the two programs were actively using. Context switches between the two did not have to touch drum or disk and so were much faster.
When a program switched to using a different 10% of its code or data, that OS could then map that to real RAM. Since both programs do over time do use 100% of their logical RAM eventually the OS will have to start moving data back and forth between RAM and the drum or disk. But it is not having to do that on every context switch like those systems that needed programs to be 100% in RAM did. Also since it only has to load regions of the program that are actively being used instead of the whole thing, when it does have to use the disk or drum it is for a smaller amount of data and so is faster.
Some TOPS-10 memory trivia. The "core" command allocates memory. On the KA-10 memory was allocated in multiples of 1k words, so "core 1k" was the minimal amount you could allocate. On the later KL-10 model (and I think the KI-10 model but am not sure) the hardware supported allocations in pages, which were half that size. On those you could use "core 1p" to allocate one page.
I saw that in the manual, and was curious what the error message would be if your tried to allocate 1 page on a KA-10. So I typed that command to see what it would say. The command never returned.
I then noticed there was silence in the room and some cursing, and it was apparent the system had crashed. I didn't think much of it because the system crashed fairly often. This was at Caltech and that PDP-10 was the computer that most undergraduate accounts were on, and people were always trying to push limits and explore interesting edge cases. So I figured this was another one of those.
I waited for the admins and operators to bring it back up, and then typed "core 1p" again hoping to this time get to see the error message. It crashed again!
When it came back up, and before I could try a third time, a broadcast message from the admins was sent to all terminals. It said something like "If you want to know why the system keeps crashing, ask tzs who is currently sitting at terminal 7".
Oops. Oh well, at least now I knew that there was not an error message for "tried to allocate 1 page on a system that does not support pages".
From what I remember the machine they were using had a Unix workstation that acted as the front end, so the Cray would be just as an accelerator. APL uses a stack based approach to memory management that maps well to bare hardware with minimal OS features.
