Talk:von Neumann architecture

Open problems

Currently this "von Neumann architecture" article is tagged with "Category: Open problems".

My understanding is that the "von Neumann architecture" itself is not an open problem, since many implementations of it seem to be working fine.

Is there, perhaps, one or more unsolved problems or other open problems associated with "von Neumann architecture", perhaps something related to the "von Neumann bottleneck"? If so, it would be nice if they were explicitly spelled out in this article rather than letting readers like me wonder what the open problems are. If not, the "Category: Open problems" tag should be removed. --DavidCary (talk) 23:17, 8 September 2020 (UTC)

Done. The Von Neumann bottleneck is not an example of an open problem. --Guy Macon (talk) 23:37, 8 September 2020 (UTC)

Does the use of ROM make an architecture non Von Neumann?

It seems to me that the statement " both program instructions and data in read–write, random-access memory (RAM)" is incorrect. Does the use of ROM for instructions (or data) make an architecture not Von Neumann . DGerman (talk) 00:06, 15 August 2021 (UTC)

It's simpler than that. People are constantly editing the architecture to match what they see as "normal" today.

Today we use ROM and ram and have a distinction between those and flash and hard drives.

However in the Von Neumann architecture there IS no difference. They are ALL memory.

Programs are store on your hard drive, they can be loaded into ram making the hard drive essentially an input device too. But the OS is capable of running the program from the HDD directly, we just don't like to do that as it's slow.

So instead we use the HDD as Virtual Memory where we can swap pages of fast RAM to the slow memory, the HDD and load the program into the fast memory.

All this is not part of the architecture, we extended it and complicated it as we have massive limits on our memory speeds. If hard drives were as fast as DDR, you wouldn't need any DDR...

Any distinction between memory types is what we have bolted on and none of it is necessarily official as it can change when we like. For example, flash is slow so we like with HDDs don't execute code from it. But, we actually do. NAND flash can't be written to in a random access manner, but NOR flash can. And NOR flash is capable of letting a CPU execute from it. Thus ROM as you mentioned today is normally NOR flash and yes it is part of the memory as your BIOS is executed from it when you turn on the PC. Actually, technically it's copied to DDR RAM to use the fastest memory but you can turn that off.

Memory in the Von Neumann architecture is ANYTHING that stores instructions or data. Hard drives, SSDs are part of that (most of the time) as we memory map files off them into the address space of the computer. It's all memory, whether it's a delay line made out of mercury or a drum memory or a platter of spinning rust or a flash chip or a set of dynamic ram chips. They are all the same in our Von Neumann architecture we use. But we added stuff on top, to define and separate different mediums resulting in most people thinking that memory is only dynamic ram. 86.21.15.252 (talk) 07:25, 27 July 2025 (UTC)

In the First Draft of a Report on the EDVAC (published in 1945), there is no mention of hard disk drives (announced in 1956) or flash memory (invented in 1980), just of an "outside recording medium of the device".

In practice, there is a distinction between primary memory and secondary storage, with the latter treated, at the hardware level, as an "outside recording medium" in that sense, just as punched cards, punched tape, magnetic tape, input and output terminals, etc. are "outside recording [media]". The hardware only fetches instructions and data from primary memory (and may cache it in hardware caches); system software running on that hardware may use virtual memory techniques to make it appear as if data stored on some types of "outside recording media" is in primary memory.

Not that this is in any way relevant to the question first asked. And, as I noted below, the article no longer speaks of instructions or data necessarily being stored in read-write memory. Guy Harris (talk) 08:27, 27 July 2025 (UTC)

Some computers, such as the IBM 650, used drum memory as primary memory; others used it as secondary storage. Guy Harris (talk) 08:32, 27 July 2025 (UTC)

I'd like to make a note that this isn't even simply incorrect in the context of non-Von Neumann architectures, but it is also an incorrect description of the subject matter which the sentence in question is actually describing which is the stored-program computer. That jojo (talk) 15:05, 21 February 2023 (UTC)

The article no longer speaks of instructions or data necessarily being stored in read-write memory. Guy Harris (talk) 06:44, 17 March 2024 (UTC)

"A control unit that includes an instruction register and a program counter"

Hello,

Not sure where to ask this so I'll do it here. Please tell me if you want this comment removed.

I learned in class that the instruction register and a program counter are the same things.

Why the use of the word "and" then ? Saulepleureur (talk) 15:05, 4 March 2024 (UTC)

Because whoever taught you that in class might have been mistaken, in which case you learned something that's not correct. The instruction register Wikipedia page says that "the instruction register (IR) or current instruction register (CIR) is the part of a CPU's control unit that holds the instruction currently being executed or decoded". whereas the program counter Wikipedia page says that "The program counter (PC) ... is a processor register that indicates where a computer is in its program sequence." The two definitions given in the article are not the same - the program counter indicates where the current instruction was fetched from or where the next instruction is going to be fetched from, whereas the instruction register contains the instruction in question. (In practice, modern machines might not have something as simple as an "instruction register", but that's a different matter.) Guy Harris (talk) 06:40, 17 March 2024 (UTC)

They are not the same.

The Program Counter points to the memory location of the next instruction to be loaded into the instruction register.

The instruction register is a area of memory in the CPU typically, that holds the current instruction for execution.

Once that instruction has been executed the CPU will fetch the next instruction from where the Program Counter is pointing and will increment the PC by one. The instruction can change the PC when executed allowing for jumps etc. 86.21.15.252 (talk) 07:29, 27 July 2025 (UTC)

Citation standards for explanatory remarks

Under the mitigations section there is a tag. However, the explanations are fairly straight forward for each technique and all boil down to reducing the number of times main memory needs to be touched either by improving cache's hit rate, expanding the cache, or performing instructions with values already in the registers. AFAIK most of the literature about these techniques do not feel the need to explain this, as it is assumed that the reader can infer why improving, e.g., the cache hit rate would reduce bottlenecking.

If we expand this to clarify, what are the standards for the sources that would need to be used? I feel uncomfortable with some of the sources that are typically considered RS because the loss of precision that comes with explaining technical topics to laypersons. --Ostip (talk) 22:03, 9 January 2025 (UTC)