GameBoy 颜色模拟器操作码自动化
我正在用 C 语言编写一个 GameBoy 颜色模拟器,只是为了向这个世界介绍自己,它是解释性的,没有动态或静态重新编译:P
现在我正在执行用 C 代码实现所有 CPU 操作码的繁琐任务,我必须写下所有这些: http://www.pastraiser.com/cpu/gameboy/ gameboy_opcodes.html 并且我不想从另一个模拟器中获取它们。
问题是,有什么方法可以自动化操作码的写入吗?也许这是一个愚蠢的问题,也会有一个愚蠢的答案,但我想尽可能少地工作。 :)
I'm writting a GameBoy color emulator in C, just to introduce myself into this world, it is interpreted, nothing of dynamic or static recompilation :P
Now I'm right in the tedious task of implementing all the CPU opcodes in C code, I have to write all these: http://www.pastraiser.com/cpu/gameboy/gameboy_opcodes.html and I don't want to take them from another emulator.
The question is, is there some way to automate the opcodes writting? Maybe it's a silly question and it will have a silly answer, but I want to work as less as possible. :)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我以前做过这种事情,我的方法是使用宏,但这样做最终会导致大量代码重复,从而溢出 CPU 缓存并使速度变慢。如果我今天要这样做,我会摆脱整个“操作码切换/可跳转”习惯用法,除了晦涩/罕见的操作码之外,并使用一些基于以下内容的小型查找表为所有正常的算术/逻辑操作编写通用的无分支代码操作码号。可以这样想:
这段代码当然过于简化,但可以扩展以处理内存操作数等。另请注意,跳转指令只是一条加法指令,其中程序计数器作为其操作数之一。
对于 Z80(或其 GB 变体)或 x86 等 CISC 架构,您还必须处理条件代码标志。但是,它们可以作为第二组计算来完成,例如上面的 res[...] = ...; 计算。
I've done this kind of thing before and the way I did it was with macros, but doing it that way you end up with a whole lot of code duplication that overflows the cpu cache and makes things slow. If I were to do it today, I'd get rid of the whole "opcode switch/jumptable" idiom except for obscure/rare opcodes, and write common branchless code for all the normal arithmetic/logical ops using some small lookup tables based on the opcode number. Think something like:
This code is of course over-simplified, but can be expanded to deal with memory operands, etc. Also note that a jump instruction is just an add instruction with the program counter as one of its operands.
For CISC archs like Z80 (or the GB variant thereof) or x86, you're also going to have to deal with condition code flags. However they can be done as a second set of computations like the
res[...] = ...;
ones above.我知道这是一个古老且已回答的问题,但为了记录,如果有人最终遇到同样的问题:
我编写了一个快速脚本来解析此文档页面并生成带有操作码描述的 JSON。
您只需加载此 JSON 并从中生成 GB [反]汇编器代码的样板,这显然可以节省时间,因为 JSON 很容易通过大多数脚本语言进行操作。
代码和生成的 JSON:
I know this is an old and answered question, but for the record, if someone ends up having the same problem:
I made up a quick script to parse this documentation page and generate a JSON with opcodes description.
You can just load this JSON and generate the boilerplate of your GB [dis]assembler code from it, that should clearly save time since JSON is easy to manipulate from most scripting languages.
Code and resulting JSON:
这就是为什么到目前为止,我只为 msp430、6502 和拇指...无打字做过模拟器或静态重新编译器。为了打破单调,我经常做的就是获取一个我想要看到工作的程序/游戏并执行,直到它遇到我尚未实现的操作码,然后实现该操作码并重试。
更糟糕的是,您可能需要使用两个或三个模拟器或对该模拟器进行两到三次重写,然后才能感受到如何节省大量打字和/或如何更好地重新设计。使用/逻辑。通过尝试执行最喜欢的 ROM,您会得到一个随机的指令组合,将您置于操作码表的各个部分,并且当您重复使用这些操作码的代码时,您可能...可能...能够以更少的时间改进您的设计重写。
正如 R. 可能描述的那样,如果您创建电子表格或其他一些软件可解析表,您可以从该表编写和重写模拟器代码生成器。在这里,您再次可以从小处开始,不必制作完整的表格,尝试一些不同风格的操作码,看看您是否无法找出允许解析器为模拟器生成代码的表格格式。您可以稍后添加标志和其他内容,并使整个过程随着改进而成长。但归根结底,无论是表格还是实际代码,您最终都必须输入所有这些操作码。
That is why, so far, I have only done emulators or static recompilers for msp430, 6502, and thumb...less typing. to break up the monotony what I will often do is take a program/game I want to see work and execute until it hits an opcode I have not implemented, then implement that opcode and try again.
What is worse, is that it may take you two or three emulators or two or three re-writes of this emulator before you get the feel for how you could have saved a lot of typing and/or how you could have better designed re-used/logic. By trying to execute a favorite rom you get a randomish instruction mix that puts you into various parts of the opcode table and as you re-use code for those opcodes you might...might...be able to improve your design with less re-writes.
As R. is probably describing if you instead create a spreadsheet or some other software parsable table you can write and re-write a simulator code generator from that table. Here again you can start small you dont have to make a complete table, try a handful of different flavors of opcodes and see if you cant figure out a table format that allows your parser to generate code for the simulator. You can later add flags and other things and make the whole process grow as it improves. At the end of the day though, be it a table or actual code, you are eventually going to have to have typed in all of those opcodes.