我目前正在编写一个基于ARM7tdmi处理器的视频游戏控制台模拟器，我几乎处于我希望测试的阶段，如果处理器运行正常的话。我只开发了整个控制台的CPU和内存部分，因此只有调试处理器的可能方法是使用日志（控制台）系统。到目前为止，我只是通过获取伪操作码并执行随机指令来测试它。是否有专门为此类目的而设计的实际ARM7程序（或其他方法），以确保处理器正常运行？提前致谢。
我使用了虚拟操作码，例如，
ADD r0，r0，r1，LSL＃2
MOV r1，＃r0
但是采用32位操作码格式。
答案 0 :(得分：2)
我还写了一些测试，并在GBA模拟器中发现了一些错误。我还编写了自己的仿真器（以及处理器业务测试处理器和板卡）。
我有一些经常做的事情。这些是我的一般测试方法。
有很多开源库，例如zlib和其他压缩库，jpeg，mp3等。这些并不困难，伪造fopen，fread，fwrite和大块的数据和指针。压缩库以及加密和散列，您可以在目标处理器上进行自我测试。压缩一些东西，解压缩并将原始内容与未压缩的内容进行比较。我经常也会在主机上运行测试代码，并计算压缩和解压缩版本的校验和，并给我一个硬编码的检查值，然后我在目标平台上运行。对于jpeg或mp3或哈希算法，我使用被测代码的主机版本来生成一个黄金值，然后我在目标平台上进行比较。
在执行任何操作之前，尽管标记非常难以实现，特别是进位标志（以及有符号溢出），但有些处理器在进行减法操作时会将进位标志反转（减去是第二个的加法）操作数补充和进位补充（正常加载无进位为零进位，减去无进位然后是加第二操作数反转和进位1））。如果指令集具有借位减法，则进位的反转会影响进位，无论进位是否反转。
有时很明显，条件分支定义（如果C是这个，V是，如果C是这个，Z是那个），对于小于，大于等的无符号和有符号变体，关于特定处理器如何管理进位（无符号溢出）和有符号溢出标志，无需在实际硅片上进行实验。我不记得处理器做了什么，我按照指令集计算出来，所以我不知道ARM做了什么。
ARM对移位操作有细微差别，你必须小心，正确实现，读取每条指令下的伪代码，如果移位量== 32然后这样做，如果移位量== 0然后这样做，否则做这另一件事。使用arm7，如果故障被禁用，你可以进行未对齐的访问，它会在32位内旋转数据，或类似的东西。如果地址0的32位是0x12345678，那么在地址1处读取16位会在总线上给出类似0x78123456的内容，然后目标将获得0x3456。希望大多数人都不依赖于此。但那和其他＆＃34;难以置信的结果＆＃34; ARM ARM中的评论，从ARM ARM变为ARM ARM（如果你有一些不同的硬拷贝手册，这将更加明显，旧的白色覆盖一个（瘦一个和厚一个）和蓝色覆盖一个）。因此，根据您阅读的手册（对于那些armv4处理器），您有时可以做某事，有时不允许做某事。因此，如果您只依赖一本手册，您可能会发现代码/二进制文件执行您认为不可预测的事情。
不同的编译器生成不同的代码序列，所以如果你能找到不同的arm编译器（clang / llvm和gcc是明显的首选），如果可以的话，可以获得其他编译器的一些eval副本（Kiel是一个很好的选择，现在由我认为它包含基尔和RVCT臂编译器）。使用不同的优化设置编译相同的测试代码，测试每个变体，并为每个编译器重复这些。如果您只使用一个编译器进行测试，那么您将在指令序列中留下空白以及许多永远不会被测试的指令或变体，因为编译器从不生成它们。我曾经遇到过这个问题。使用开源代码也会得到不同的程序员习惯，无论是asm还是C或其他语言，不同的个人都有不同的编程习惯，因此会生成不同的指令序列和指令混合，这些指令可以隐藏或暴露处理器错误。如果这是一个单独的爱好项目，你最终将依赖其他人。当你开始使用roms时，这里的gba或ds或者任何模拟器都是好事，你将拥有大量其他人的代码，不幸的是调试很困难。
我听到一些传闻称英特尔/ x86设计验证人员使用操作系统，各种操作系统，以打败他们的处理器，它会产生很多混乱和变化。在处理器上打败但是像roms一样，如果出现问题，极难调试。我有个人使用缓存的经验，并且在我处理过的处理器上运行linux。在我们使用Linux移植和启动之前没有发现错误，并且很难找到这个错误...幸运的是arm7tdmi没有缓存。如果你有一个缓存然后采取我上面描述的那些组合，测试代码乘以优化级别乘以不同的编译器，然后在bootstrap或其他地方添加到那个编译一个，两个，三个，四个，nops或其他的版本数据使得二进制的对齐相对于高速缓存行改变，导致相同的程序以不同方式行使高速缓存。
在这种情况下，您尝试模拟真实硬件，您可以执行诸如生成随机alu机器代码的程序，使用随机选择的源和目标寄存器生成许多指令，随机添加，减去和，以及或者，等等，随机化标志的开启和关闭等，预加载所有寄存器，将标志设置为已知状态，运行该块代码，然后捕获寄存器和标志，看看它与真实硬件的比较。您可以生成无限量的单独测试，各种长度等，这比调试执行某些数据或标记更复杂程序一部分的代码序列更容易调试。
采用测试程序的组合，乘以优化设置，乘以编译器等。然后用中断打败它。改变中断的速度。因为这是一个模拟器，你可以做一些我曾经硬过一次的事情。在中断中，检查返回地址，计算一个地址，该地址是该地址之前的一些指令，记住该地址。从中断返回，当你看到被提取的地址触发预取中止时，有预取中止代码，当预取中止触发时（在模拟中）停止观察该地址并且让预取中止处理程序的代码返回到中止发生（按手臂）并让它继续。通过这种设置，我能够在被测处理器上产生相当大的痛苦...特别是在arm7tdmi上你没有的缓存......
请注意，很大比例的gba游戏都是拇指模式，因为在那个主要使用16位宽数据总线的平台上，拇指模式比手臂模式运行得快得多（即使拇指代码需要大约10-15％）说明。以及为二进制文件占用较少的rom空间。仔细检查blx指令，因为我认为基于架构armv4的不同实现与armv6或7不同，因此如果您使用armv6或7手册作为参考或硬件进行验证，请理解这些差异。
等等，等等，等等。 DR。对不起，这对我来说是一个有趣的话题......