Not big deals. Please, keep me updated about this. I might be able to support you.
I am just curious. iPhone features a very powerful CPU. It is quite unlikely you really need anything faster than FAME/C. Have you thought about this?
.rept is not supported at all. Use .space instead
.ltorg is also not supported, so manually create literal pool (boo) periodically for the jumps
.global is .globl in Apple's version
After manually fixing this, I got it to compile, but the use of r9 is a no-no on iPhone, as this is used by the OS and can be used by the compiler. I globally replaced with r12, as it looked safe, but will review my changes and try again.
Not big deals. Please, keep me updated about this. I might be able to support you.
I am just curious. iPhone features a very powerful CPU. It is quite unlikely you really need anything faster than FAME/C. Have you thought about this?
- fox68k -
Thanks for the offer, mate. Very much appreciated.
The 3GS has an ARM Cortex A8 (like the Pandora) running at 600MHz and 256MB RAM. It runs at full speed with sound using FAME/C. The prior generation of devices (iPhone 3G and iPod Touch) have an ARM 1176 running at 412MHz & 500MHz respectively. This CPU has much less horsepower (although still good) and the FAME/C is just not quite there.
I have sound set at 22050KHz and a buffer size of 960 sample frames, and it only refreshing at around 15 - 18 times per sec on the older hardware (should be 22-23x). So, I do need to do some work on this.
Sound Bug:
I am running PAL, and set the time_slice and m68k_speed both at 0. The big problem I'm having right now is the sound is 'choppy', like portions of the buffer are skipped or some timing issue. I've used my iPhone sound routines several times now in other emu's / code without issue, so I'm fairly certain it is not them. Any suggestions here would be great. Interestingly, if I set the mode to NTSC, the sound choppiness goes away, by IK+ crashes on start. I'm using 0.7.2a of the gp2x version of uae4all. Not use if IK+ is incompatible with NTSC or it's a bug in uae4all yet.
Update on my approach:
My approach has changed a little again, as I'm now back to C68k, and rewriting it to use a hybrid C / inline ARM approach. I'm taking advantage of the ARM's CPSR, so the flags generally do not have to be calculated (like Cyclone). In addition, the hybrid method is cool, as I see the gcc instruction scheduler making interesting optimizations that otherwise would take me lots of time, pouring over the ARM 1176 technical reference manual. All the opcode handlers are set as 'naked' functions, so there is no prolog and epilog. This means I'm using the 'GOTO' approach like Cyclone, where the end of each opcode handler jumps to the next handler conditionally. It might be interesting for some people to look at, when I'm done. I've already got a number of unit tests which validate the core is working for the instructions I have implemented (ORI/ANDI/EORI, ORICCR/ANDICCR/EORICCR, and more).
Cheers,
Stu
@fox68k,
So far things are looking great with regards to performance of the hybrid C/ARM version. I have about 82 unit tests so far, testing a wide variety of expected results of the implemented instructions, such as flags. I'm finally at the point where I could test this little program:
ORG $0
START:
move.l #$80, d2
move.l #$00, d0
inner:
move.l #$7FFF, d1
loop:
addi.w #$3333, d0
dbra d1, loop
dbra d2, inner
trap #15 ; halt simulator
END START ; last line of source
Basically, it increments d0 by 1, 4194176 times.
(loop) = the time to execute the above program
(total) = the time for all 82 tests
The results:
3G ARM 1176 @ 412MHz
FAME/ARM core:
1.041s (loop)
1.711s (total)
FAME/C core:
1.708s (loop)
2.427s (total)
Speed up:
1.64x (loop)
1.42x (total)
3G[S] ARM Cortex A8 @ 600MHz
FAME/ARM core:
0.567s (loop)
0.818s (total)
FAME/C core:
1.081s (loop)
1.313s (total)
Speed up:
1.90x (loop)
1.61x (total)
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks