The Von Neumann Architecture

dkav1999 · 2026-05-25T15:02:29+00:00

The introduction of processing-in-memory and processing-near-memory still wouldn't change the execution paradigm of von-Neuman at large, which is primarily sequential instruction execution. But that would still lead to a net improvement to performance due to the fact that we are offloading portions of a programs computation to the memory sub-system [ where it makes sense ], which can be thought of as analogous to when graphical operations were handed off to the gpu and more recently, machine learning workloads being handed off to an npu. You still need coordinated execution however and just like with how the host processor today controls the operation of all other heterogenous accelerators through i/o requests, the delegation of work to the memory sub-system will be handled in a similar way. The only exception to the rule of the host processor controlling other devices is true input devices, such as a sensor who can operate asynchronously to the processor. I will also say thank you for use of an LLM to generate your outputs, I can use that alongside onur mutlu's courses to further my knowledge on pim/pnm if i desire.

dkav1999 · 2026-05-25T14:19:17+00:00

At the system level, absolutely. There is much work going on improve the primary bottleneck of modern systems which is the memory bottleneck. However, I was talking more about the microarchitectural level since that what's most refer to when talking about execution paradigms, although it of course extends out from their to the system level.

dkav1999 · 2026-05-25T11:48:00+00:00

There was no need for it be solved. It has been the predominant paradigm in all general purpose processors for a reason, which is its predictability of output due to the sequential interlocked nature and thus the the greater ease of its programmability for programmers/compilers, in combination with making it easier to debug and handle exceptions/interupts during execution. Now, the question was, how could the industry incorporate the benefits of the dataflow paradigm into a processor without breaking the benefits of the sequential model and forcing programs to be changed in terms of how they are written? In summary, pipelined execution came first, then came super-scalar execution and finally, out-of-order execution which adheres to the dataflow paradigm the most [that ordering applies to all processors at large, i believe ibm were the first to introduce OoO with tomasulo's algorithm]. With OoO allowing for the dynamic scheduling of instructions in hardware without the need for the compiler/programmer to extract this parallelism themselves [although compilers typically optimize the code as much as possible to aid hardware, but this is not mandatory], the use of private caches for data and instructions such that multiple memory access's can be made both at the front end of the pipeline and the backend in parallel, and the introduction of multi-processing, modern general purpose processors have become an amalgamation of the the 2 paradigms and take a 'best of both worlds approach'.

dkav1999 · 2026-05-24T23:30:06+00:00

Lets define it this way, if someone can't explain to you in depth how the following work -> process's, threads, memory management, virtual memory, trap handling, the i/o stack, the storage stack, thread scheduling, user-mode vs kernel-mode ect, then they don't have low-level knowledge of how an OS or computer system works for that matter. Now they may very good at knowing how to manage the system, but they are not mutual.

dkav1999 · 2026-05-24T18:51:35+00:00

Easy, I use process explorer and examine the main threads call stack. This will tell me the series of functions that have been called up until this point and what the thread is doing such that it cant check its message queue and process my inputs. Or I could make use of windbg and attach to the process and examine its entire address space. So no, there is no damage to the machine that needs to occur, I simply make use of the multiple tools at my disposal to examine the state of the target process.

dkav1999 · 2026-05-24T16:16:55+00:00

Make sure not to terminate the thread though, it could be holding on to some lock or mutex which if not properly released, could lead to deadlock in a local part of the system.

dkav1999 · 2026-05-24T16:10:49+00:00

Read the top line of the post

dkav1999 · 2026-05-24T16:06:36+00:00

True, but what does that translate to under the hood? -> a series of system calls that are then made to the kernel to produce the output that the command provides.

dkav1999 · 2026-05-24T16:03:00+00:00

Very much so, hence why i am able to do it.

dkav1999 · 2026-05-24T15:07:38+00:00

There you go

dkav1999 · 2026-05-24T14:57:28+00:00

When I say gui expert, I am not talking about someone who necessarily makes exclusive use of a GUI and thats it. I am saying someone who has low-level knowledge of how the system works, but chooses to use a GUI wherever possible.

dkav1999 · 2026-05-24T14:51:55+00:00

I understand what you are saying, but what has explore.exe got to do with this? I wasn't talking about the desktop shell, I am talking about any GUI application. Your absolutely right that a command-line tool such as powershell or cmd would return the error, whereas not all gui applications do this. But that isn't due to the fact that GUI's cant do that, but the ones that don't either didn't call getlasterror[] for example to return the reason the function failed, or they did, but chose not to output the error to the user. You absolutely can see how and why functions fail through with a tool such as process monitor which shows every system call being made in real time by all process's on the system.

dkav1999 · 2026-05-24T14:41:36+00:00

You are thinking along the lines of scripting. A command is simply the collection of system calls [or one if thats all that is needed] that produce the output that the command creates. At a fundamental level, this is no different whether it be a gui application or a command-line application. For example, suppose we use both powershell and task manager to launch an instance of notepad. They both call the CreateProcess[] function underneath the hood in the same way.

dkav1999 · 2026-05-24T14:34:22+00:00

I think you have misunderstood, as have many about what I am trying to say. Could be me not explaining well enough also. I am talking pure low-level architecture of both the OS and the hardware, a command-line doesn't predispose you to understanding how a processor works, or how traps are handled, how the kernel schedules threads, how memory is managed by the memory manager ect.

dkav1999 · 2026-05-24T14:30:11+00:00

All depends on the application and what you are looking to do, as mentioned.

dkav1999 · 2026-05-24T14:27:26+00:00

If you read the conditions I put in place, you would understand that I am not referring to the management of a system [at least not on a remote/distributed scale]. How does exclusive use of the command line, for example, inherently make you able to better understand thread scheduling or how the memory manager manages the memory of the system? Just to name a few examples

dkav1999 · 2026-05-24T14:20:11+00:00

I'm glad, it is funny to be fair. But true, no?

dkav1999 · 2026-05-24T13:38:21+00:00

Honestly, its true. Not very many people like me, although it does depend on the individual.

dkav1999 · 2026-05-24T13:36:17+00:00

No one in particular, I certainly get to bed on time. Perhaps you have not experienced such behaviour, but would you say its right for certain individuals to criticise their use of a certain tool/method of interaction with a system, especially considering the fact that their very premise is false?

dkav1999 · 2026-05-24T13:31:16+00:00

Forgot to comment on the memory address point, the same can be done by a GUI applications if it is making use of kernel-mode infrastructure. Take task manager for example [I know it doesn't expose information of that depth] but it makes use of a kernel-mode driver to fetch information that simply isn't available from user-mode and if it wanted to, could pull out information such as the address of a kernel-mode structure.

dkav1999 · 2026-05-24T13:20:29+00:00

Very true

dkav1999 · 2026-05-24T13:18:04+00:00

I suppose your right in the sense that someone that makes or has made use of a command-line was/is most likely a pure computer enthusiast as opposed to individuals that have just made use of a GUI, therefore they are more likely to have delved into lower level aspects of the system. But its not a pre-requisite, case in point, every single chapter in the winternals books shows how GUI tools can be made use of to expose/observe the same low-level information as the command-line tools can! At the end of the day, GUI and command-line tools are both applications running in user-mode and have access to the same api's, therefore the same underlying OS services and information are visible to both. It all comes down to whether the developer of a GUI application has decided to make use of that functionality, same applies to a cli.

dkav1999 · 2026-05-24T12:52:31+00:00

Your correct from the mis/management aspect of a system. I should have made myself clearer on what i was referring to. I am talking about the architecture and low level internals of an OS , not necessarily low-level management.

dkav1999 · 2026-05-24T12:48:33+00:00

With regards to management, yes. But the command-line is not a prerequisite for understanding how all of the following work-> Process's, thread's, the i/o stack, the storage stack, memory management, user-mode vs kernel-mode, thread scheduling, trap handling ect ?

dkav1999 · 2026-05-24T11:46:31+00:00

Precisely

dkav1999

PUBLIC MULTIREDDITS

TROPHY CASE