总结下现在的工作，感觉应该顺带着把内存管理的一部分一并解决掉：


原来想叫关联数组,但是现在不关联了,所以改叫映射内存.
定义一种叫做映射内存的内存模块,可以将输入映射到常数,并且可以更改这个映射.
也就是说反应了一个可修改的F：input -> output.
在实际中，映射值域会被约束在一些不可更改的数值上.
性质上,要求F属于单射.


应该提供三个方法
$remapping(input,output)//将一个input与一个output绑定.
$mapping(input)//将input通过f映射到output上,返回output.
$reset()//这个方法会把整个内存中的映射关系删除.
并且应该可能抛出两个异常:
$undefined_mapping//未定义的映射,表示在f上没有定义input的输出,这可能由mapping导致.
$mapping_conflict//映射冲突,也就是存在冲突的映射,可能在remapping上抛出.


功能大致这样,但是还需要考虑在内存管理中的部分.以及有关的地址转换表(以下简称ATT).


在内存中完整实现这样的内存开销太大,也没必要,所以只会让cache中的相关块获得这些功能.


然后考虑一下具体的设计,首先应该确定一下是块划分还是段划分还是基于块的段.
很明显段划分不行,然后关于块划分或者用块组成段.如果出现比较大的数据结构,后者应该是有些必要的.
$这两个策略应该到时候与内存管理策略统一更好.总之纯分段是不大可能.
不过注意可能有些程序在这方面的需求会有但是很少.甚至反而分配会导致更多开销,当然就另说了.


应该可以确定采用块策略,可以在分配大小上考虑影响:

$增大块尺寸:
reset,remapping,mapping会经过更多单元,导致块内访问更多卡顿与线延迟.
reset,remapping,mapping跨块请求更少(块编号少)
利用率可能更低

$减少块尺寸:
reset,remapping,mapping经过较少单元,可以减少块内访问的卡顿与线延迟
reset,remapping,mapping跨块请求更多(块编号多)
利用率可能更高


除此之外,操作系统使用的查表,包括ATT,都可以被存储于映射内存中,以优化性能.
关于TLB,现在被拆了几个步骤:
TLB缺失->访问ATT的映射表部分(映射内存中)->获得线性表中的偏移量->访问ATT的线性表部分(普通内存中)->获得映射项->TLB置换.
不过有TLB的话感觉不是啥问题.甚至这方面还应该需要一定的分析.
当然最主要最主要的目的还是为一般程序提供一个强大的映射效率.这个不算重点.

然后大概确定了寻址和内存管理的部分。但是还需要考虑对称多核心间的同步协议。除此之外。可以给出一些设计参数的精确优化方程。但是需要具体数据支持。

关于一致性应该统一到一个表上记录所有的cache块状态就行了。这样又多了一块特殊的内存

要考虑包括程序跳转分布以选择最佳的块尺寸。可能因为简化。这个系统的内存模型基于块。或者块尺寸会比较大。但是这对一些共享数据结构不利，可能的做法是采用哈佛架构到主存储器上，另外就是将部分小型同步机制整合到操作系统模块。

emmmm又反过来寻思这个内存架构到底怎么样了。因为线延迟和卡顿。如果长时间保持运行单个程序，而且结构不复杂。划分出辅助存储会不会更好呢。。。另外还有就是线程的切换。当然这个我觉得应该只会在本地的寄存器窗口间处理了，或者说这么做的开销最低如果假定总线程数不会太夸张（应该不会）。当然这样的话，在分配处理器资源上麻烦了不少

考虑了一些例程，我觉得256*宽度的块规格就够了。为了方便可能会采用16bits的pc。高8作为索引，低8作为偏移。另外偏移的溢出导致段号改变似乎会更好用一些。于是界限检测在索引数值上。

还有中断问题。。。尤其是外源中断。这方面似乎还需要补充一下知识

还是假定一下外设比较好,主要是确定某些不同规格的接口.

被提醒后注意到一些单次规模比较大的传输请求。这部分在设计原则上应该跟更普通的传输分开。考虑到的解决方案就是提供一些所谓的独立通道完成这些操作，在考虑通用性后将整合为所谓的南桥模块。与北桥一并构成完整的片上通讯系统与接口

除此之外，关于中断系统。意识到这部分的工作可以放到接下来再做。因为除了中断信号转发，本身影响的是处理器状态。

关于外周的数据转移，现在我觉得得大致划分两族请求类型。
第一族主要在传输靶向上较为灵活，并且假设他的讯息长度不会太长。
第二族在靶向上基本固定，也就是在os初始化的时候就直接确定链路拓扑，在这方面，直接考虑其为P2P类型的讯息传输，并且认为它拥多多少少拥有规模较大的传输请求。
对于这两族传输请求类型的链路最佳适配，很显然出现了明显的分化，所以现在得考虑就是划分所谓的南北桥。
具体两族分别包括哪些，那种请求类型，是需要进一步考虑的

那么还需要考虑的是。存在哪些需要适配的硬件接口，或者说，这方面有什么需求。也许可以在一开始就考虑大部分的类型，一并实现支持后，在部署到实际系统时屏蔽部分功能。或者提供较好的客制化参数接口。或者在考虑应用场景后，才设计出专用设计。这几个思路不一定冲突，但是问题是接下来该怎么办

顺便的，关于中断信号，可能考虑通过一般的信号途径经北桥转导。或者在南桥开辟独立同路。因此在体系上，是经由一个全局中断处理单元转导发配到处理器的，因此可以将所有的中断接口，或者大部分的接口都设置在照顾全局的处理单元，好处是可以用更规范的帧数据格式表示到本地的中断信号。这方面与操作系统配合，或许可以获得要相对不错一些的表现。