Reputation: 44 Craftsman
- Active Posts:
- 686 (0.33 per day)
- 30-June 09
- Profile Views:
- Last Active:
- Feb 10 2015 10:25 AM
- OS Preference:
- Favorite Browser:
- Favorite Processor:
- Favorite Gaming Platform:
- Your Car:
- Who Cares
- Dream Kudos:
Posts I've Made
Posted 10 Feb 2015...I'm posting rather than running the idea through a compiler as I'm away from my workstations for a couple of days (just in case anyone suggests that) ...
QuoteThough, to my original question: is breaking a switch statement up into groups of case statements in headers compiler legal?
I suggest you try it and find out.
I usually just brush over this sort of thing, but that's easily the least helpful response I've had on DiC. I wouldn't have asked if I had access to my tools to try it. Appreciate all the help nonetheless.
(Edit) neg. rep'd for an answer seemingly disregarding the original post.
Posted 9 Feb 2015I'm not entirely sure how I missed that guide, but that was and will be incredibly helpful.
I can ignore most of it, since the Game Boy Z80 doesn't implement the DD/ED/FD extensions, just the base and CB ext. ops. Being able to mask and branch down to just a couple of parameterized functions won't necessarily be as maintainable, but with some good commenting it'll definitely be more readable.
Though, to my original question: is breaking a switch statement up into groups of case statements in headers compiler legal?
Posted 9 Feb 2015Have you searched the internet for ideas, you're not the first person to consider creating an emulator and I'm sure there is a lot of pertinent information available to help. For example this page.
Yes, I have. I've done extensive research into how the Game Boy works and have a number of references I'm using to help implement the various components. My question was specifically on whether a particular idea would be compiler legal, though I have a small number of other ways I'd already tested.
The Z80 opcode become much more manageable if you do bit masks and look at the results. Notice how much more organized the opcodes are at this web page: DECODING Z80 OPCODES.
This will let you put the opcodes into "families" of similar opcodes. You'll have less than 512 "families".
Briefly reading over this it looks really promising and it hadn't come up in my research, thank you!
Posted 9 Feb 2015Since I'm not positive as to what "FMP" or "GB" is actually referring I don't know what else to say, but it sounds like you may want to consider a conversion table instead of a gigantic switch statement. If you're trying to emulate a Game Boy how many base op codes does the Game Boy actually have?
Apologies, fmp refers to the final major project. Some places call it an honours project. My course refers to it as the final major project.
I don't know how (or why) I'd implement a conversion table.
The Game Boy has 256 base ops, one of which (0xCB) directs it to a 256 extended op table for a total of 512 ops.
The vector idea ties a method to each index, I.e 0x00 NOP -> functions();, but writing that is barely as manageable as writing a huge switch + is twice the code (unless I do some clever parameterization, which isn't completely unfeasible). I'm assuming that's what a conversion table is...
(Edit) Actually, parameterisation of the functions would add a new layer of complication wherein I must know, dynamically, whether or not there are parameters for a particular instruction. It's still not impossible, just an unnecessary layer of complication. I would also need to know what the parameters were - I.e registers, memory etc.
Posted 9 Feb 2015I would say that you would be better off trying to re-factor the code so you don't need such an extensive switch statement. For example you probably could use a series of if/else statements to break the statements into multiple parts that could then be placed in different files.
if( op < 10) call some function to evaluate the first "block" else if(op < 20) call some other function to evaluate this "block" ... else call some function to evaluate the case of a "bad" value.
While the the using the #include directives may work, would IMO be much more confusing.
I like your idea, but the key problem for me would be that the GB instruction table is out-of-order. The headers would enable me to have a header for each group of instructions (8-bit loads for example). This is why I thought headers would be a good idea.
I could write parameterized functions to further break the load down, but branching still wouldn't support that on account of out-of-order instructions.
That said, I'm still open to other suggestions. The vector is equally cumbersome since I have to push each member function on at least once.
- Member Title:
- The Leafiest of the Leif's
- 22 years old
- February 5, 1993
- Wolverhampton, UK
- Interesting things. Interestingly.
- Full Name:
- Leif Walker-Grant
- Years Programming:
- Programming Languages:
Experienced: C#, VB, (X)HTML, JScript, PHP, XAML, ASP, VBScript, C++/C, Java.
Some Knowledge: Actionscript, Lua.
Designed himself: SkySkrypt Object Markup Extensions (for Project 'Skylark')