M68K for DC

[Alexvrb]

[quote author=quzar link=board=dcemu;num=1083323639;start=120#128 date=05/30/04 at 21:32:30]there has been but only hand done bigO examination caparing the instructions one gives compared to the other and figuring theoretical results. in practical uses though the sh4 snes core was around 10-15% faster(?) than its C equivilant. OT: Welcome to the forums and the scene Â*;D[/quote]

I thought that DreamSNES as a whole was %10-15 faster. That would indicate that the CPU core by itself was significantly faster than the old C core, because just comparing DreamSNES before and after doesn't take into account the video or sound emulation (which were still sucking up lots of cycles).

Basically, SH is not a primary target for GCC, so GCC produces shoddy code for the SH series. Also, 3.0.4 works, but all the versions after that until 3.4.0 produced broken code. So they just fixed it again recently. Speaking of which, has anyone tried compiling C68k with 3.4.0? I am curious to see whether -O1 or above still breaks it (I know its not quite done anyway, but it'd be interesting to see).

[Ian_micheal]

Was not much faster then c core at all. Hardly changed.

[Christuserloeser]

compare sfc v01 + sound to sfc v02 + sound. it is faster.

[Ian_micheal]

Hmm to you maybe. Every so slightly to me.

[Christuserloeser]

:'( Yeah, very slightly that is...

Too bad, better then nothin' bu video & sound is the real problem with SNES emulation 4 DC other then with the Genesis/MegaDrive. Its M68K is a really powerful beast.

[quzar]

its weird i use 3.3.1 cygwin special edition of gcc and my code is usually not broken. (i think there was one thing that was broken) can anyone help teach me how to update gcc? i have no clue at all lol.

[Ian_micheal]

[quote author=16Bits link=board=dcemu;num=1083323639;start=120#127 date=05/30/04 at 17:31:23]well, I'm currently working on a sh4 asm motorola 6502 cpu emulator, although it's going slowly since I just recently built me a serial cable and got the toolchain up and running (gcc3.04). anyway, my main gripe just now is getting the hang of the sh4 cpu and the general dreamcast hardware. Â*I've never programmed assembly on a risc cpu before and it differs somewhat from my previous experiences (6502, z80, 65816, 68000, x86) and takes some getting used to. my main gripe with the dc sofar is the lack of an l2 cache, as a 16kb data l1 cache means you'll likely trash the lines constantly unless you use carefully prepared data (which is a luxury we don't have in emulation). however, that the dc seems uncapable to emulate a snes in fullspeed wasn't a surprise, since the snes is a VERY hard machine to emulate, more difficult than say Sega genesis/megadrive. one of the things I remember from programming the snes that I imagine is hard to emulate fast is the cpu's rep/sep instructions that allows it to switch from 8/16bit accumulator register sizes (quick note, someone in this thread stated 6502 as the snes cpu, it is in fact 65816), this means that the emulator must constantly check wheter it is in 8 or 16bit accumulator state before decoding each instruction, not to mention it's graphics hardware (unless I remember this incorrectly, it was a looong time since I programmed the snes)

anyway, I read that the dreamsnes team will release the dc specific parts of the snes9x source and I am really looking forward to examining their sh4 65816 code.

enough of that though, the reason I opted for a 6502 emulator was because it's a cpu that I know very well and since I am to learn sh4 assembly while programming it, it definately helps if I don't have to spend time remembering how the cpu i'm emulating works. that said, when the 6502 emulator is done, I'm planning on making a z80 and a 68000 (yes, here is the reason I posted), however, wheter or not that will happen depends on just how much extra speed can be gained from programming the sh4 in pure asm as opposed to letting the compiler do the job. risc cpu's are generally the compilers dream, since it has plenty of registers, and the instruction set is very basic. so I'm wondering if there have been any benchmarks/efficiency tests done previously comparing sh4 optimized asm towards compiler generated code?
(this would save me alot of gas output examination )[/quote]

Best news ive herd all do i which you luck and no ive not seen any reports other then the offical docs that say sh4 asm is up to x3 faster then c on the dreamcast. Avoiding pipeline stalls and cache misses is a major problem.

[obelisk]

Awesome! I'm not a coder, or programmer, but I'm really happy all you guys are kickin' butt on this stuff. Hey, I have a quick question, please pardon the lack of knowledge... will / could this 68k stuff help out TG16 emulation on the DreamCast? Keep up the good work on all this kewl stuff!!!

[quzar]

68k is named because it is the name of a processor. the Motorola 68000. this may aide the emulation of any hardware that used that processor.

[Stef]

[quote author=16Bits link=board=dcemu;num=1083323639;start=120#127 date=05/30/04 at 17:31:23]well, I'm currently working on a sh4 asm motorola 6502 cpu emulator, although it's going slowly since I just recently built me a serial cable and got the toolchain up and running (gcc3.04). anyway, my main gripe just now is getting the hang of the sh4 cpu and the general dreamcast hardware. Â*I've never programmed assembly on a risc cpu before and it differs somewhat from my previous experiences (6502, z80, 65816, 68000, x86) and takes some getting used to. my main gripe with the dc sofar is the lack of an l2 cache, as a 16kb data l1 cache means you'll likely trash the lines constantly unless you use carefully prepared data (which is a luxury we don't have in emulation). however, that the dc seems uncapable to emulate a snes in fullspeed wasn't a surprise, since the snes is a VERY hard machine to emulate, more difficult than say Sega genesis/megadrive. one of the things I remember from programming the snes that I imagine is hard to emulate fast is the cpu's rep/sep instructions that allows it to switch from 8/16bit accumulator register sizes (quick note, someone in this thread stated 6502 as the snes cpu, it is in fact 65816), this means that the emulator must constantly check wheter it is in 8 or 16bit accumulator state before decoding each instruction, not to mention it's graphics hardware (unless I remember this incorrectly, it was a looong time since I programmed the snes)

anyway, I read that the dreamsnes team will release the dc specific parts of the snes9x source and I am really looking forward to examining their sh4 65816 code.

enough of that though, the reason I opted for a 6502 emulator was because it's a cpu that I know very well and since I am to learn sh4 assembly while programming it, it definately helps if I don't have to spend time remembering how the cpu i'm emulating works. that said, when the 6502 emulator is done, I'm planning on making a z80 and a 68000 (yes, here is the reason I posted), however, wheter or not that will happen depends on just how much extra speed can be gained from programming the sh4 in pure asm as opposed to letting the compiler do the job. risc cpu's are generally the compilers dream, since it has plenty of registers, and the instruction set is very basic. so I'm wondering if there have been any benchmarks/efficiency tests done previously comparing sh4 optimized asm towards compiler generated code?
(this would save me alot of gas output examination )[/quote]

Hello 16bits, i'm sure we already had some talks together or maybe i'm confusing with someone else...

It's true than RISC assembly is somewhat different from CISC one and specially x86, it appears far more limited !
But i had fun with ARM assembly, i know *a bit* about SH-X assembly (from what i learnt by making my SH-2 emulator)... but i expect to have fun too

You said SNES is complex, i agree, but not about the 65816 CPU which is (imo) simpler than 68000 cpu, the 8/16 bits trick of 65816 isn't a big problem really...
sound is complex, video is complex, but SNES cpu is easy


Then about SH-4 assembly versus C generated code.
First GCC isn't really a master about SH-X code optimisation, it does some weird stuff sometime and code is far from being optimal.
Second, when you're emulating a CPU, asm always help a lot compared to C, because you have access to some low level instruction as ROR / ROL which need several instruction in C.
So, even with the best C code, i think you can at least do 3 time faster in ASM.

C68K is definitly not the ultimate 68k emulator for the DC, we can do really better in ASM, but, that's really needed ? if C68K is already capable of emulating a 68000 running at 80/100 Mhz on the DC, then an ASM 68000 emulator isn't really a must.