Everyone knows about the von neumann architecture and the bottle necks that come with it. I have an idea though.
Why not have two separate sets of ram, one for memory and one for programs? Both would be exactly the same, both able to read/write/store code like normal ram, but while one ram is executing it can use the other one for memory storage eliminating the bottle neck. Also all programs would be backwards compatible because a program can still run on a single side of ram and leave the other alone.
Would this be an easy solution or am I missing something here.
That still would just be a Von Neumann machine though. I'm not sure you're entirely clear on where the bottlenecks in a Von Neumann lie.
Actually, why, in this day and age, would anyone even consider a computer architecture without touching on the massive shift towards parallel execution? Anything that aims for high performance today will involve parallelism, and if there's any improvement to be made, it's in doing something fancier than just slapping a bunch of traditional processors on a chip with some cache glue and calling them cores.
But you've got a lot of reading on that too ahead of you before you're ready to innovate.
Name:
Anonymous2009-08-31 8:23
There must be a reason if OP doesn't work for Intel or AMD. And the reason is: You did not understand how paging works.
Also, have you ever heard about Operatingsystem?
Name:
Anonymous2009-09-01 7:58
Almost all modern CPUs use a Harvard architecture internally, with separate instruction and data caches. The external interface is von Neumann for a number of reasons including compatibility and conceptual simplicity.
Name:
Anonymous2009-09-01 13:37
>>8
Uhwhat? So self-modifying code is strictly impossible? IHBT
Name:
Anonymous2009-09-01 14:58
>>9 Self-modifying code would be possible if you allocate the 2xtimes of memory to the application and let it store itself into the another part of the memory after completing its normal sycle then run the new stored code structure and erase the old. It might end up beaing the program where in the end there will be a retarded program which cant complete its original reason for exsinstance but still i would love to try it one day when im bored from reading SICP and watching chamichingas.
>>9
No. >>8-chan is talking about the caches, which are organized like the Harvard arch for the simple reason that executable code and non-executable data are generally stored in completely different parts of the address space. If you did operate on code as if it were data, you could still push it back out to main memory and then execute a jump to wherever you put it. BAM! You have modified your code.
Name:
Anonymous2009-09-01 15:39
>>14
Well, >>14-kun - I can see how that might be what he meant, but what he said was a bit different - and it sounded a bit retarded at that. If anything, he should have said that CPU caches follow the Harvard model closely, since most software actually doesn't need or use all freedoms of the von Neumann model.
also ITT people who know just enough (but no more) to sound like assholes
Name:
Anonymous2009-09-01 19:53
If you want to be a hacker, keep reading. If you want to be a cracker, go read the alt.2600 newsgroup and get ready to do five to ten in the slammer after finding out you aren't as smart as you think you are. And that's all I'm going to say about crackers.
Name:
Anonymous2009-09-02 4:19
>>9
No, but it may not be as simple as on uncached processors. Some CPUs (e.g. x86) contain lots of extra logic to maintain the illusion of a pure von Neumann architecture while others require e.g. explicit flushing of both the data and instruction caches to ensure you're not running stale code. In any case, self-modifying code on systems with CPU cahces are bad for performance.