偶然在 AVR 发明之前很久就使用的哈佛架构确实为程序存储器和数据存储器提供了单独的地址空间。这给聚会带来的是设计电路的能力，使得可以使用单独的总线和控制电路来处理来自程序存储器的信息流和到数据存储器的信息流。使用单独的总线意味着程序的获取和执行可以继续进行，而不会因偶尔向数据存储器传输数据而中断。例如，在架构的最简单版本中，程序提取单元可能忙于提取程序序列中的下一条指令，与可能是先前程序指令的一部分的数据传输操作并行。

在这个最简单的层次上，哈佛体系结构有一个限制，即通常不可能将程序代码放入数据存储器并从那里执行。

在我所描述的这种最简单的架构形式之上，可以添加许多变体和复杂性。一个常见的添加是向程序信息总线添加指令缓存，允许指令执行单元更快地访问下一个程序步骤，而无需在每次需要时进入较慢的内存来获取程序步骤。

除了迈克尔斯回答的一些笔记：

1）哈佛架构不要求数据和代码有两个独立的空间，只是它们（大部分）是通过两条不同的总线获取的。

2）哈佛架构解决的问题是总线争用：对于一个代码内存可以快速提供指令以保持 CPU 全速运行的系统，数据获取/存储的额外负担会减慢 CPU下。Hardvard 架构解决了这个问题：内存（有点）对于 CPU 的速度来说太慢了。

请注意，缓存是解决此问题的另一种方法。哈佛和缓存经常以有趣的组合使用。

哈佛使用两辆公共汽车。没有固有的理由坚持使用两个，在非常特殊的情况下使用两个以上，主要是在 DSP（数字信号处理器）中。

Memory Banking（在将内存访问分配到不同芯片组的意义上）可以看作是内存系统本身内部的一种哈佛化，不是基于数据/代码的区别，而是基于地址的某些位。

纯哈佛架构通常允许具有给定复杂程度的计算机比冯诺依曼架构运行得更快，前提是代码和数据存储器之间不需要共享资源。如果引脚分配限制或其他因素迫使使用一条总线来访问两个存储空间，那么这些优势很容易在很大程度上被抵消。

“纯”哈佛架构将仅限于运行代码，这些代码由运行代码的处理器以外的某种机制放入内存中。这限制了此类架构在工厂（或具有专门编程设备的人）未设定用途的设备上的实用性。可以使用两种方法来缓解这个问题：

一些系统有独立的代码和内存区域，但提供了特殊的硬件，可以要求它们短暂地接管代码总线，执行一些操作，并在操作完成后将控制权返回给 CPU。一些这样的系统需要一个相当复杂的协议来执行这样的操作，一些有特殊的指令来执行这样的任务，还有一些甚至监视某些“数据存储器”地址并在尝试访问它们时触发接管/释放. 这种系统的一个关键方面是“代码”和“数据”有明确定义的内存区域。即使 CPU 可以读取和写入“代码”空间，它仍然被认为在语义上与数据空间不同。

在一些高端系统中使用的另一种方法是让控制器具有两条内存总线，一条用于代码，一条用于数据，两者都连接到内存仲裁单元。该单元又使用单独的内存总线连接到各种内存子系统。对一个内存子系统的代码访问可以与对另一个内存子系统的数据访问同时处理；只有当代码和数据试图同时访问同一个子系统时，任何一个都必须等待。

在使用这种方法的系统上，程序的非性能关键部分可能会简单地忽略内存子系统之间的边界。如果代码和数据碰巧驻留在同一个内存子系统中，事情就不会像它们在单独的子系统中那样运行得那么快，但对于典型程序的许多部分来说，这并不重要。在典型的系统中，会有一小部分代码对性能确实很重要，并且它只会对系统保存的一小部分数据进行操作。如果一个系统有一个 16K 的 RAM 被划分为两个 8K 分区，那么可以使用链接器指令来确保性能关键代码位于整个内存空间的开头附近，而性能关键数据靠近结尾。如果整体代码大小增长到例如 9K，最后 1K 内的代码运行速度会比放置在其他地方的代码慢，但该代码不会对性能至关重要。同样，如果代码只有 6K，但数据增长到 9K，访问最低的 1K 数据会很慢，但如果性能关键数据位于其他位置，则不会造成问题。

请注意，虽然如果代码低于 8K 而数据低于 8K，性能将是最佳的，但上述内存系统设计不会在代码和数据空间之间施加任何严格的划分。如果一个程序只需要 1K 的数据，那么代码可能会增长到 15K。如果它只需要 2K 的代码，数据可能会增长到 14K。比仅用于代码的 8K 区域和仅用于数据的 8K 区域更通用。

尚未讨论的一个方面是，对于通常只有 16 位地址总线的小型微控制器，哈佛架构有效地将地址空间增加了一倍（或三倍）。您可以拥有 64K 的代码、64K 的 RAM 和 64k 的内存映射 I/O（如果系统使用的是内存映射 I/O 而不是端口号，则后者已经将 I/O 寻址与代码和RAM 空间）。

否则，您必须将代码、RAM 和可选的 I/O 地址全部塞入同一个 64K 地址空间中。