FAME/C generator source available?

[scarnie]

G'Day Chui,

I was wondering if the FAME/C generator source code was available somewhere to experiment with? I'm playing around with UAE4ALL, and would like to muck with it anad try to improve performance running on my iPhone - anything I do I'll gladly share back.

Cheers and thanks for the awesome work,

Stu

[fox68k]

You can check out FAME here: http://svn.emuforge.com/fame.

[scarnie]

Thanks mate - I notice that the actual code generator for FAME/C is not there, which is what I'm most interested in.

I've taken C68k and have it generating an almost identical version - still a bit of work to do, but close. I plan on taking this as a starting point and generating a more optimized version for the ARM. Unfortunately, Cyclone it is not compatible with the GPL (and I couldn't get it working with uae4all anyway). FAME/C is working fine.

Cheers,

Stu

[fox68k]

Thanks mate - I notice that the actual code generator for FAME/C is not there, which is what I'm most interested in.

You are confused. FAME/C does not rely on a code generator. FAMEx86 and sh4 do, though.

If you are trying to plug C68K in uae4all, you will face a long way. Some games require features not present in C68K.
From my point of you are better off getting started with FAME/C and optimizing code for ARM. An alternative might be adding ARM code to either FAME/x86 or sh4 generators which is probably what you were thinking about at first.

[scarnie]

You are confused. FAME/C does not rely on a code generator. FAMEx86 and sh4 do, though.

If you are trying to plug C68K in uae4all, you will face a long way. Some games require features not present in C68K.
From my point of you are better off getting started with FAME/C and optimizing code for ARM. An alternative might be adding ARM code to either FAME/x86 or sh4 generators which is probably what you were thinking about at first.

Hey mate,

Definitely not confused - and I do agree with you. FAME/C does not appear to rely on a code generator any more, but it was derived from C68k (as per comments I've read previously). Already, with minor changes to C68k, a good percentage of the opcodes being generated match identical to famec_opcodes.h (even spacing ).

I'm taking a very systematic and logical approach. I was never intending to just drop in C68k. My plan is to initially replace the famec_opcodes.h header file only - I've already reformatted C68k to output the opcodes in the same way FAME/C does today. Once that is working, I'll do 'black box' testing, whereby I'll generate a 68k test app, that unit-tests most many instructions of the CPU and records known outcomes, I'll then start experimenting with mine and ensure the same tests pass. As long as my tests cover a good percentage of the CPU functionality and my replacement CPU passes, it should be fine. My tests vary from simply executing 1 instruction and returning to running little programs. The already do things like verify cycles, flags, memory changes, etc.

Cheers and thanks for the input,

Stu

[fox68k]

FAME/C is heavily based on C68K. But that does not mean it has to follow the same approach. We got rid of the code generator long ago, cause we found it kinda pointless.

[scarnie]

Could you be more specific as to what problems I will run into? The way I see it, if I can make C68k generate an identical file to famec_opcodes.h, I have succeeded in my initial goal.

You're right, I could just modify the C code, but if I find a useful pattern that I could apply to all the bit-ops and numeric opcodes, why force myself to cut/paste (and be susceptible to error). Update the generator and regenerate the file is much better. Ultimately, the reason for writing a generator for the 68k was there is so much repetition, so I simply want to take advantage of that in my endeavours. Whether that generator is C or assembly is really irrelevant.

Cheers,

Stu

[fox68k]

Could you be more specific as to what problems I will run into?

As far as i remember, you need trace mode and bus and address error exceptions.

You're right, I could just modify the C code, but if I find a useful pattern that I could apply to all the bit-ops and numeric opcodes, why force myself to cut/paste (and be susceptible to error). Update the generator and regenerate the file is much better. Ultimately, the reason for writing a generator for the 68k was there is so much repetition, so I simply want to take advantage of that in my endeavours.

I would rather make use of macros and inlined functions in C instead. But that is a personal preference. Obviously, FAME/C is not a good example. It should be tidied up, but we are pretty busy and always find anything more interesting to spend our time on.

Whether that generator is C or assembly is really irrelevant.

In theory, it is. In practice, it is not. Preprocessing support is quite limited in many assemblers (being NASM one exception) where as C preprocessing is more flexible and powerful.

Regards.

[scarnie]

Okay, I'll take the approach of deriving an ARM version from the SH-4 generator - at least they are both RISC architectures.

What settings are used for the Dreamcast / SH-4 version of uae4all?

I could not get Cyclone to work, as it is not compatible with Apple's implementation of GAS.

Cheers,

Stu

[fox68k]

What settings are used for the Dreamcast / SH-4 version of uae4all?

Have a look at the Makefile. For uae4all:

--format=$(format) --inline-loop --accurate-timing --check-branches --multi-bank --undocumented --direct-mapping=16 --trace-mode --clock-counting --running-state --global-context

I could not get Cyclone to work, as it is not compatible with Apple's implementation of GAS.

Do you know what the differences are?

Cheers.