3 ms·

I wonder if anyone noticed how people first came up with the architecture of a single bus for data and code and how they then had endless problems due to writin

by aasasd 7y ago

I wonder if anyone noticed how people first came up with the architecture of a single bus for data and code and how they then had endless problems due to writing data where code should be and executing data as code. And they plug the problems by forbidding to write data and code in the same place and to read data as code (afaik). So yeah, should maybe computers be liberated from the single pipeline?

rwmj 7y ago
I have a Gigatron (https://gigatron.io/ https://gigatron.io/) which has this kind of architecture. Only the ROM can contain machine instructions, so the only way to program it is to use the ROM interpreter to run bytecode stored in RAM, or to burn a new ROM. Frankly this aspect of it sucks (the Gigatron in itself however is a wonderful learning project and recommended). There's really not a problem with having a "single bus" for code and data. On modern computers where you can mark the data with the NX bit to ensure it doesn't get run, while at the same time allowing you to load programs as data and mark them as executable.
cwzwarich 7y ago
> So yeah, should maybe computers be liberated from the single pipeline? Internally, they basically are. Instruction and data caches are separate and only connect at the L2 level. Aliasing between the two pipelines is only allowed if software requests it, with the specific architecture determining the amount of automatic vs. manual synchronization required. What would you prefer, physically disjoint DRAM?
- aasasd 7y ago
  I think I've read about programs misapplying the execution bits accidentally, such that malicious data can slip by. Buffer overflows still don't seem to be shrugged away despite the bits. Maybe finish the move and do exactly what was proposed before the single pipeline: don't ever mix data and code in the same memory. No need for physically separating the RAM. Just have designated areas, maybe even allocate code areas on the fly―only not by the program itself. Even JIT can be accommodated this way, I think: since you know that code comes from the program and not errant buffers, and if the program is marked as JIT-type, let it write to a code area allocated just for this program. But probably not copy from the data memory.
imtringued 7y ago
If you have two pipelines you still have a von Neumann architecture. The core principle of the von Neumann architecture isn't how many buses you have and what restrictions you apply to them. The point is that you separate the processing element from the memory and connect the two over a bus which then causes you to suffer from the downsides of having a bus.

by aasasd 7y ago

rwmj 7y ago

I have a Gigatron (https://gigatron.io/ https://gigatron.io/) which has this kind of architecture. Only the ROM can contain machine instructions, so the only way to program it is to use the ROM interpreter to run bytecode stored in RAM, or to burn a new ROM. Frankly this aspect of it sucks (the Gigatron in itself however is a wonderful learning project and recommended). There's really not a problem with having a "single bus" for code and data. On modern computers where you can mark the data with the NX bit to ensure it doesn't get run, while at the same time allowing you to load programs as data and mark them as executable.

cwzwarich 7y ago

> So yeah, should maybe computers be liberated from the single pipeline? Internally, they basically are. Instruction and data caches are separate and only connect at the L2 level. Aliasing between the two pipelines is only allowed if software requests it, with the specific architecture determining the amount of automatic vs. manual synchronization required. What would you prefer, physically disjoint DRAM?

aasasd 7y ago
I think I've read about programs misapplying the execution bits accidentally, such that malicious data can slip by. Buffer overflows still don't seem to be shrugged away despite the bits. Maybe finish the move and do exactly what was proposed before the single pipeline: don't ever mix data and code in the same memory. No need for physically separating the RAM. Just have designated areas, maybe even allocate code areas on the fly―only not by the program itself. Even JIT can be accommodated this way, I think: since you know that code comes from the program and not errant buffers, and if the program is marked as JIT-type, let it write to a code area allocated just for this program. But probably not copy from the data memory.

imtringued 7y ago

If you have two pipelines you still have a von Neumann architecture. The core principle of the von Neumann architecture isn't how many buses you have and what restrictions you apply to them. The point is that you separate the processing element from the memory and connect the two over a bus which then causes you to suffer from the downsides of having a bus.