19
$\begingroup$

Memory is used for many things, as I understand. It serves as a disk-cache, and contains the programs' instructions, and their stack & heap. Here's a thought experiment. If one doesn't care about the speed or time it takes for a computer to do the crunching, what is the bare minimum amount of memory one can have, assuming one has a very large disk? Is it possible to do away with memory, and just have a disk?

Disk-caching is obviously not required. If we set up swap space on the disk, program stack and heap also don't require memory. Is there anything that does require memory to be present?

$\endgroup$
12
  • 5
    $\begingroup$ en.wikipedia.org/wiki/Drum_memory $\endgroup$
    – Yves Daoust
    Mar 4, 2016 at 11:40
  • 4
    $\begingroup$ What is the idea behind this question ? $\endgroup$
    – Yves Daoust
    Mar 4, 2016 at 11:43
  • 13
    $\begingroup$ Define "disk". We are quickly moving towards a diskless world (I'm glad Terry Pratchett doesn't have to witness it). This means that all storage will be some sort of solid state or another, which is kindof answering your question, albeit probably reversely. $\endgroup$
    – Peter - Reinstate Monica
    Mar 4, 2016 at 14:36
  • 3
    $\begingroup$ Memory is memory is memory $\endgroup$
    – Édouard
    Mar 4, 2016 at 15:46
  • 9
    $\begingroup$ Random-addressable memory is not, to the best of my knowledge, a requirement for computers. The tape from a Turing machine is not random-addressable. Nothing prevents you from reading/writing only one bit per block if you’d like. $\endgroup$
    – Édouard
    Mar 4, 2016 at 17:28

7 Answers 7

Reset to default
25
$\begingroup$

Sure. In principle, given appropriate hardware, you could have just a disk, with everything stored on disk. Any time the CPU did a load or store instruction, there could be some hardware that turns that into a disk read or write. It'd be extremely slow: on a magnetic disk, each seek takes about 10ms, so you could do about 100 random-access reads and writes per second.

Some systems have flash memory-mapped into their address space. Flash memory provides non-volatile (persistent) storage. So, in some ways this resembles what you mention -- though those systems usually also have RAM as well.

$\endgroup$
3
  • 6
    $\begingroup$ @MSalters makes a good point that if we modify a disk (or layer extra hardware on top of it) to make it RAM-like, then we might as well just call it RAM. The problem is that the question, "Is it possible to do away with memory, and just have a disk" is too vague. What do we mean by memory and disk? Do we mean those that exist in a modern desktop PC? Then the answer is no. Do we mean some hypothetical memory and disk? Then in that case the distinction between the two is blurred anyway, and the question is equivalent to "is it possible to have a computer with mechanical based RAM?". $\endgroup$
    – JBentley
    Mar 4, 2016 at 17:02
  • 1
    $\begingroup$ The AS/400 kind-of works like this. There is a Single-Level-Storage, and only a single Address Space. Disk and memory are combined into a single storage abstraction by the platform firmware, the OS itself sees only a single flat unified storage space. There are no pointers, only object references. Objects are moved from memory to disk and back transparently by the platform firmware (BIOS in PC-speak, SLIC in AS/400-speak). It would make no difference to the OS and applications if you removed the disks and had only RAM or removed the RAM and had only disks. $\endgroup$
    – Jörg W Mittag
    Mar 5, 2016 at 12:39
  • $\begingroup$ Also I think the HDDs life will be much shorter. And even worse for an SSD.Most likely the reason why Android phones don't have swap $\endgroup$
    – Suici Doga
    Mar 6, 2016 at 13:17
16
$\begingroup$

In terms of computability, it is known that every modern day computer can be simulated by a Turing Machine whose only storage is a single, linear tape cells that can be written. Assuming you can keep adding unlimited amounts of disk storage, a computer having only hard drives is just as powerful. So certainly you could make a computer without memory.

Of course, there are not "unlimited space" hard drives, but neither is there unlimited RAM.

There are a number of practical issues, for example, you would need conventions for mapping different areas and addresses on the disk, an operating system which wrote to the disk for intermediate storage and managed disk addresses. In reality, you would end up closely simulating RAM on your hard drive.

$\endgroup$
14
$\begingroup$

The question is not purely academic. It is a matter of historical record that one of the earliest commercially-produced computers [sorry, I don't recall which offhand] did not have any RAM - all programs were executed by fetching instructions directly off of a magnetic drum [a rotating cylinder with outer surface magnetizable (disks came later)]. It was comparatively slow, but much cheaper than a lot of the competition. [this was way back in the 'tube' days]

Interestingly, it came with a now-obsolete tool known as an 'optimizing assembler' - i.e the assembler not only generated machine instructions, it wrote them out onto the drum non-consecutively so as to minimize, for each instruction, the amount of time waiting for the drum to rotate to the next.

$\endgroup$
4
  • 3
    $\begingroup$ You may be thinking of the Stantec Zebra - archive.computerhistory.org/resources/text/Standard/… . They still had one in the CS department when I went to university in 1967. $\endgroup$
    – David Marshall
    Mar 4, 2016 at 16:04
  • 3
    $\begingroup$ Actually, I think I may have been thinking of the IBM 1408. $\endgroup$
    – PMar
    Mar 4, 2016 at 17:33
  • 8
    $\begingroup$ See also the Story of Mel (catb.org/jargon/html/story-of-mel.html) which is about a programmer who worked on the Royal McBee LPG-30, which had a drum memory. $\endgroup$
    – db48x
    Mar 4, 2016 at 18:37
  • $\begingroup$ @db48x: I'd forgotten how cool that story was. I probably haven't read it for 10 years. $\endgroup$
    – Peter Cordes
    Mar 6, 2016 at 10:40
7
$\begingroup$

No. Disk drives are not Random Addressable like RAM. Instead they're block storage devices. You can't read or write a byte from them. And your CPU cannot read a whole sector at once, they need that random access. Operating systems hide this level of detail from you, but they do so by reading a whole sctor into RAM, modifying it, and writing it back.

As a result, you need one block of random-access storage. This could be the CPU cache, though, which is made out of SRAM (a fast type of RAM).

It's not only disks. Flash memory is by design built out of blocks, which is key to its low price. It even has blocks far bigger than normal disk sectors, but it uses RAM internally to hide that from the OS.

You can make persistent storage that's directly usable by a CPU. EEPROM storage would fall in this category (Electronically Erasable Programmable "Read-Only" Memory - although "Read-Optimized" would be a factually better description).

$\endgroup$
11
  • 5
    $\begingroup$ I think your "No" should be "Yes, but it would require custom built disks". $\endgroup$
    – Taemyr
    Mar 4, 2016 at 13:23
  • 3
    $\begingroup$ You certainly can read a byte, on both. What you can't do is write a single byte, because writes need an entire block writing at once. However in principle there is no reason why you can't modify a block by copying the unmodified data from the original block into a new block, writing new data instead where necessary, and then copying it back to the original block. You'll wear your disk out pretty quickly, but that's inevitable from the OP's question anyway. $\endgroup$
    – Graham
    Mar 4, 2016 at 14:00
  • 3
    $\begingroup$ And "blocking" is done for efficient use of physical disk space: you need space around each piece of "real" data to identify the block, provide "guard" space between blocks etc. There's no technical reason why blocks couldn't be one byte long (but speed would drop even further as would capacity). $\endgroup$
    – TripeHound
    Mar 4, 2016 at 14:24
  • 6
    $\begingroup$ Actually, even current RAM isn't really byte-addressable - DDR3 works in bursts and the minimum read/write size is 8 64-bit words (i.e. 64 bytes); I'm not an expert, but I would bet that aligned access is also required. All this is not so dissimilar to older disks, where block size was in the order of 512 bytes, so I'd say that these distinctions are mostly historical, the line is really blurring. $\endgroup$
    – Matteo Italia
    Mar 4, 2016 at 16:11
  • 1
    $\begingroup$ (also, nothing stops you to use a whole block - whatever size it is - just to hold one byte - a bit inefficient but as long as I'm not the one paying the disks it's ok) $\endgroup$
    – Matteo Italia
    Mar 4, 2016 at 16:18
1
$\begingroup$

When you use virtual memory and need to handle page faults, then at the very least the exception handler handling the page fault, the disk driver that reads the data from the hard drive and first writes dirty pages to the disk, and the page tables need to be in RAM all the time. Because if they are not in RAM, you can't swap them back into RAM. Plus you need space for at least one page of RAM.

If you had a CPU like a massive 12 core Xeon with 30 MB of cache memory, it might be possible to have a system with neither RAM nor hard drive, but use just the cache memory. (Not sure if that actually works or if for some reason RAM is required).

$\endgroup$
2
  • $\begingroup$ IIRC, x86 has a mode where it uses internal cache as main memory. electronics.stackexchange.com/questions/16485/… has some details. I think it's sometimes called "no fill mode", i.e. the CPU doesn't try to actually fill cache lines from external memory. This might preclude using DMA for hard drive I/O, because the "system agent" can't DMA into L3 cache. It might work on a Skylake with L4 eDRAM, because it's set up as a memory-side cache (unlike Broadwell) that can cache everything, including DMA. Programmed-IO would still work for disk. $\endgroup$
    – Peter Cordes
    Mar 6, 2016 at 10:28
  • $\begingroup$ Of course, at that point you're running a System-on-Chip with 128MiB of RAM, which was a decent amount 15 years ago. With only L3 SRAM caches, that's still 4 to 8MiB in a desktop chip, which is maybe enough for a very stripped-down Linux, but easily enough for DOS. If most of your code is in ROM, not RAM, then that's fine. $\endgroup$
    – Peter Cordes
    Mar 6, 2016 at 10:52
1
$\begingroup$

It is conceptually possible. RAM is just a caching level. There are many caching levels in a modern computer (see the CPU's L1,L2,L3.. caches, of course Ram, the swap area -which is a logical section of the disk used as RAM...-), if you put or add one, the machine will work. For example, an Ubuntu live cd may not use the caching level of the HDD. However, i don't think there are any OS that can support the absence of a RAM level.

$\endgroup$
6
  • 1
    $\begingroup$ It's not the OS, but the hardware what is designed requiring the instructions to be into ram (actually, mapped on the address space). $\endgroup$
    – Ángel
    Mar 5, 2016 at 0:30
  • $\begingroup$ @Angel is it really required in a modern OS that the text (instructions), bss, stack and heap be loaded into memory for a program to execute? Can't they be on the swap (disk)? In Linux, say. $\endgroup$
    – Tosh
    Mar 7, 2016 at 22:02
  • 1
    $\begingroup$ We are talking about computer science or computer engineering? I don't know the implementation of a OS, neither the hardware level, I'm basing only on the Church-Turing thesis. Maybe this is impossible using current hardware available on the market or using existing OSs, but can be possible in a theorical scenario. $\endgroup$
    – Picci
    Mar 8, 2016 at 17:16
  • 1
    $\begingroup$ @Tosh it's not a problem of the OS but the hardware. Your CPU executes one instruction located at the memory address pointed by the instruction pointer. So just having a disk won't work (without altering your hardware). Answering your question, not all of the section would need to be loaded into the memory, in fact the OS may only load them when the program attempts to access them. As an extreme counter example, you could run the program "from disk" by using an emulator that reads one word* at a time from hdd. But your would need to be in memory, so you would still need some RAM. $\endgroup$
    – Ángel
    Mar 14, 2016 at 1:17
  • 1
    $\begingroup$ Sorry, @Tosh: "your emulator would need to be in memory". $\endgroup$
    – Ángel
    Mar 16, 2016 at 23:36
-1
$\begingroup$

Technically, RAM is a primary volatile memory that is used to improve the processing speed. Once the power is gone, the data in primary memory is lost. If we use a disk, ie as you say, only disk and not RAM, we could still run our computer but there would be more read write overhead thereby considerably slowing down the system . Hence, we use RAM.

$\endgroup$
3
  • $\begingroup$ Welcome to CS.SE! Can you justify your claim that more read-write overhead increases the chance of a frequent system crash? That doesn't sound right to me. $\endgroup$
    – D.W. ♦
    Mar 5, 2016 at 5:00
  • $\begingroup$ It depends on the is u are using. Like in unix/Linux there is a concept known as buffer cache. It can be used to store prefetched blocks or the blocks marked for delayed write. But in Windows or Mac there is no such concept. Hence, you have to access required blocks from secondary storage. Now while running parallel processes the read write overhead would increase and the processing speed would decrease consequentially. The processes won't be able to execute thereby slowing the computer such that it starts hanging and subsequently crashes $\endgroup$
    – Sanket Gupte
    Mar 5, 2016 at 5:51
  • 2
    $\begingroup$ That sounds like a misconception. Slowing a computer down doesn't mean that the computer will crash. $\endgroup$
    – D.W. ♦
    Mar 5, 2016 at 19:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.