Were there any computers that did not support virtual memory? if yes, were these computers able to run multiple processes at the same time?
By “virtual memory” I mean when a process would want to access a memory address, it would access a virtual address, and then this virtual address would be translated into a physical address.
The Amiga from Commodore shipped in October 1985 with a preemptive multitasking operating system designed to run many processes. The hardware lacked any support for virtual memory, and the Operating System never added it.
As a multitasking system, it worked very well, especially measured against similarly priced competition that usually lacked this feature (Sinclair QL, notwithstanding). Indeed, most of the drawbacks of the Amiga OS would trace to lack of support for hardware protected memory, not the lack of support for virtual memory.
Protected memory is what allows a system to withstand corruption to kernel memory that is easily caused by errant application in a non-protected memory system. You might be familiar with the "Blue Screen of Death" famous on Windows systems in the past. On the Amiga, such crashes were a common occurrence, but had the less ominous sounding name "Guru Meditation" errors. Either way, you usually had to reboot the machine to recover.
There are three different concepts which may be bundled into the term "virtual memory", depending on whose definitions you prefer.
Separation between program addresses and physical memory addresses. This can be as simple as datum and limit registers to relocate the program.
Splitting of the program address space into pieces that can be independently relocated; the pieces may be variable-sized ('segments') or fixed-size ('pages').
Support for parts of the address space being non-resident, together with a way to stop an instruction that attempts to reference a non-resident part, and a way to restart the instruction when the missing part has been made resident.
There's a natural hierarchy there, in that the higher numbered facilities usually required the lower-numbered ones.
But yes, there were dozens of computers without any of that in hardware. I will note a few from memory, in no particular order and with no particular significance other than what I first thought of, off the top of my head.
A couple of 'firsts':
Big iron:
IBM 7090
IBM System/360 at its introduction.
Minicomputers:
PDP-8
PDP-11/20
PDP-11/40 without a KT11-D MMU.
The last-mentioned one nevertheless managed to run an operating system (RSX-11M) that supported multiple simultaneous tasks; it just required that you link the task file for a specific physical address.
Based on your clarification from comments, “I mean when a process would want to access a memory address, it would access a virtual address, and then this virtual address would be translated into a physical address”, yes, there were computers that did not support virtual memory: any computer where addresses were used with no indirection. There are many examples of this: most 8-bit micros, 8088- and 8086-based PCs...
Virtual memory is not required to run multiple processes simultaneously (within the limits of a system without multiple processors), nor even is bank switching; for example, MS-DOS arguably supports multiple processes loaded simultaneously in memory, and processes can grab control from each other (this is what TSRs do).
Hardware support isn’t even necessary to implement virtual memory; the Z-machine provided paging and virtual memory for its virtual machine, and worked very well on rather limited 8-bit micros.
Reading question and comment, it feels as if there is a confusion between address translation and virtual addressing vs. memory protection and separate (process) address spaces. These are more or less independent issues.
Address Translation is a mechanism to turn an address issued by a program into a real memory address to be used. There is no principal need for programs or processes to use different address spaces.
Virtual addressing is about allowing addressing more memory than there is, by providing a way to detect access to addresses that are currently not in main memory and have them brought in (one way or another)
Memory protection is about stopping one process from accessing memory assigned to another. This can and has been done long before usage of virtual addresses. For example the /360 family provides a 4-bit field for each memory page meant to hold a storage key. Similarly, a dedicated CPU register holds the key of the process running. Whenever it accesses memory with a different key, a protection fail is inserted.
Separate memory spaces are about giving every process the same (virtual) addresses, so it seems as if it's the only process on a machine - simplifying relocation issues a swell.
Equally important to this question, hardware support for virtual memory is the least important part here: it's all about an OS using this feature. An OS can still provide multi-processing without virtual memory, despite the hardware being present - like Classic MacOS on a 68040 LC475.
Were there any computers that did not support virtual memory?
Yes, essentially every computer did in the early days.
There were already a number of computers working when the concept of virtual addressing was first described in 1956 by F. Güntsch at TU Berlin, Germany. It wasn't until 1959 when the Manchester MUSE project showed off a first prototype of virtual addressing. Still, it only reached mainstream usage in the late 60s with the IBM 360/67.
It's important to understand that, at that time, virtual addressing wasn't about separating processes, but to allow a process to grow beyond existing memory. We all know that there is never enough memory in a computer, but that was even more scarce back in the days when mainframes with 128 KiB were considered large.
And while virtual addressing as a tool to support multiprocessing became useful in universities during the 1970s, most commercial use stayed with real mode environments to avoid the speed penalty of address translation.
The same was true when minis became a thing in the 1960s/70s - and it repeated of course with micros. Here, much as before, virtual addressing became available quite early on in the 1970s, but it wasn't until the mid-1980s that it caught on with workstations and mid 90s with mass market PC - not at least as its usage is way more of an OS issue than hardware related.
if yes, were these computers able to run multiple processes at the same time?
Of course= multi-programming and multi-processing do not rely on having virtual addressing. It only needs well-behaved processes, staying away from accessing any resources (memory, I/O, Disk, etc.) not assigned to them. Something to be expected anyway from any program, isn't it?
There have been many examples for operating systems supporting concurrent execution without virtual addressing on all classes. By just focusing on micros, a short list may look like this:
Please note that there are many ways to run different processes, and all of the above changed over time in what types were supported, or what restrictions applied. Also, some added virtual addressing (and memory protection) in later versions.
For classic Macintosh system versions prior to system 7, all applications used physical memory accesses all the time. Multiple applications could be resident in memory because the address of every application instance's static data would be immutably determined before it launched, and the static data would include a jump table with an entry for every function that could be called between 32K code segments, or whose address could be taken. Generated code Address register A5 was at all times left holding the base address of the current application's static data which, as noted, would never change during the execution of an application instance.
A multi-tasking OS like Multifinder 6.1b9 could switch between application instances whenever an application polled for events by saving the values CPU registers in the current application instance, and loading those registers with values for the application to switch to (either startup values or the last values saved for the that instance). An application which wrote to addresses it didn't own could corrupt other applications, but most applications didn't do such things and the system was remarkably functional and stable.
The PDP-8 did not have virtual memory — in the classic sense that there was no hardware page tables, no hardware page faults, no expandable virtual address space.
The PDP-8 has 12-bit instruction size and 12 bit address space for 4k 12-bit words. It was expanded with bank switching to hold up to 8 4k banks or 32k words total.
Under TSS/8, the operating system required 8k (2 4k banks), and you needed at least one more for user programs. User programs were given a full 4k bank and the bank switching instructions were privileged so could not access any other banks. In time sharing, the operating system would swap a user process to disc, swap another into memory, and give it a time slice. This worked best if you had at least 2 4k banks for processes, because it would use DMA to the disc to swap processes in/out while at the same time giving a CPU time slice to the user process in the other bank.
Most microcontrollers have no support for virtual memory in hardware. Microcontrollers running Linux will have this supported in software, but microcontrollers are typically used more for real-time systems. As such, they will normally run an RTOS instead, or often will simply go straight for bare metal. Neither will use virtual memory.
It is perfectly possible to run multiple tasks simultaneously in an RTOS. Unlike the time-slicing multitasking which you are probably most familiar with, RTOSes work slightly differently. The important part of real-time processing is that important processing is turned around in time, so tasks are prioritised. One task at a time (the highest priority) runs with full control over the processor, and it runs until it finishes. If a higher priority task comes along, the current task is frozen and the new task gets full control until it finishes. If a lower priority task is triggered, it goes in the queue. When this task finishes, the RTOS checks the queue for the next highest priority task which has been triggered, and runs that. Sometimes this is supported directly by the hardware using prioritised interrupts, and sometimes it is handled in software. This is called "pre-emptive multitasking", because a higher-priority task can "preempt" (interrupt) a lower.
Were there any computers that did not support virtual memory?
Yes, a great many.
if yes, were these computers able to run multiple processes at the same time?
Yes, if the operating system was designed for it and the programs were well-behaved. Generally, programs need to work when they're loaded at different locations in memory, they need to be able to figure out (with OS help) where they were loaded and how much memory is available to them, and they need to refrain from messing with each other's memory. It's helpful if they limit themselves to using OS facilities to access hardware, instead of direct access (otherwise, strange things can happen during task switch). And there needs to be some way (either preemptive or cooperative) to actually switch between tasks.
All of these things were, in fact, possible on MS-DOS on an 8086 (which had no memory management); DOS had sensible memory allocation routines (if programs used them) and facilities for hardware access (if programs used them), and third party software such as Quarterdeck DESQview provided task switching and even the ability to run multiple apps simultaneously in text-based "windows".
Many early time-sharing systems and early Unix also operated this way — sharing was based on convention and well-behaved apps. Putting processes into "virtual" spaces where everything they can see is their own was a later development.
