Von Neumann and Harvard Architecture: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
mNo edit summary |
||
| Line 3: | Line 3: | ||
* the code and data sit in the same memory. | * the code and data sit in the same memory. | ||
* upsides: | * upsides: | ||
** in older hardware, this took fewer hardware components (back when things like ALU, CU and such were | ** in older hardware, this took fewer hardware components (back when things like ALU, CU and such were separate) | ||
* downside: | * downside: | ||
** has a bottleneck in that one bus - we're always ''either'' fetching code, or data, so the CPU is frequently not doing anything, and instructions always need more cycles | ** has a bottleneck in that one bus - we're always ''either'' fetching code, or data, so the CPU is frequently not doing anything, and instructions always need more cycles | ||
| Line 12: | Line 12: | ||
* in older hardware, this took more individual components and more space | * in older hardware, this took more individual components and more space | ||
* upsides | * upsides | ||
** faster, in that instruction fetches and data | ** faster, in that instruction fetches and data fetches could happen concurrently | ||
* downsides: | * downsides: | ||
** more complex, pricier | ** more complex, pricier | ||
| Line 18: | Line 18: | ||
That list is easy enough to find, but what most ''don't'' go into is how we've gone on to further change the model since the 1940s | |||
in, you know, ''almost any actual computer''. | |||
Turns out we've defined other variants since. | Turns out we've defined other variants since. | ||
But most everyday CPUs are modified Harvard, a.k.a. 'something inbetween and resembling that one more than the other one'. | |||
Generally, they | |||
* have a separate instruction cache and data cache at L1 | |||
: some have experimented moving the L1i inside the CPU in the form of a [https://en.wikipedia.org/wiki/Trace_cache trace cache], but by and large the cost/benefit is low | |||
* | * whereas any L2 and L3 are more agnostic | ||
* | * have instructions and code in the same memory | ||
: | : allowing self-modifying code, e.g. for | ||
:: obfuscation (may then be one-time) | |||
:: optimizations (on some archs may take extra care around caches) | |||
: e.g. buffer overflows are the attempt to overwrite code with writes to the data section | |||
* Does the OS mapping an executable into memory marks some pages as instruction, or is it implied by {{verify}} | |||
'Modified Harvard' actually includes various distinct individual choices, such as | |||
* shared memory, but separate data and instruction ''cache'' | |||
: so that you can actually use a mostly van Neumann but ''rarely'' have to wait on the memory bus | |||
* separate memory, but lets you mark instruction contents as fetchable data | |||
: less space wasted | |||
In fact, "modified harvard" is a pretty vague term, in that there may be a bunch | In fact, "modified harvard" is a pretty vague term, in that there may be a bunch | ||
| Line 49: | Line 54: | ||
Microcontrollers are sometimes much more like classical Harvard, | |||
in part because it's convenient (simpler bootstrapping) to have instruction memory be in something non-volatile, and data in RAM, | |||
(and it makes instruction caches simpler to implement{{verify}}) | |||
DSP chips also have their own design logic, in part because they may be cacheless, or have some specialized cache concepts. | |||