arm-eabi-gcc generating UMULL

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
Post Reply
User avatar
MisterDave
DCEmu Freak
DCEmu Freak
Posts: 58
https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
Joined: Mon Apr 08, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

arm-eabi-gcc generating UMULL

Post by MisterDave »

I am currently having some trouble with running a section of code on the Dreamcast's ARM CPU. The error that I am getting in lxdream is for an unimplemented instruction, which after looking at the ARM program counter in the debugger is UMULL. My understanding is that the ARM7DI in the sound unit doesn't support UMULL, however, is there a flag for gcc that I'm missing to stop this instruction being generated?

In my Makefile I have set the arm-eabi-gcc flags to "-mcpu=arm7di -mno-thumb-interwork -Wall" and arm-eabi-as to "-mcpu=arm7di", however, this instruction is still being generated.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: arm-eabi-gcc generating UMULL

Post by BlueCrab »

How was your arm-eabi-gcc built (as in what flags did you give to the configure script when building it)? I've had troubles before with GCC spitting out invalid instructions if I don't configure it properly. If you used dc-chain to build it (and didn't modify the options therein), then it should be the following (look at the output of arm-eabi-gcc -v):

Code: Select all

../gcc-4.7.3/configure --target=arm-eabi --prefix=/opt/toolchains/dc/arm-eabi --without-headers --with-newlib --enable-languages=c --disable-libssp --disable-tls --with-arch=armv4
Flags wise at build time, KOS uses the following (which seems to work fine):

Code: Select all

	export DC_ARM_CFLAGS="-mcpu=arm7di -Wall -O2 -fno-strict-aliasing -Wl,--fix-v4bx -Wa,--fix-v4bx"
	export DC_ARM_AFLAGS="-mcpu=arm7di --fix-v4bx"
User avatar
MisterDave
DCEmu Freak
DCEmu Freak
Posts: 58
Joined: Mon Apr 08, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

Re: arm-eabi-gcc generating UMULL

Post by MisterDave »

Thanks for the help BlueCrab. From "arm-eabi-gcc -v" (built with dc-chain) my output is as follows, which looks to be consistent with what you posted:

Code: Select all

Using built-in specs.
COLLECT_GCC=../../../arm-eabi/bin/arm-eabi-gcc
COLLECT_LTO_WRAPPER=/home/david/dc/arm-eabi/libexec/gcc/arm-eabi/4.7.3/lto-wrapper
Target: arm-eabi
Configured with: ../gcc-4.7.3/configure --target=arm-eabi --prefix=/home/david/dc/arm-eabi --without-headers --with-newlib --enable-languages=c --disable-libssp --disable-tls --with-arch=armv4
Thread model: single
gcc version 4.7.3 (GCC)

What is odd is that with the exported DC_ARM_CFLAGS and DC_ARM_AFLAGS settings Lxdream is still throwing an error at runtime for an unimplemented instruction which after looking at the debugger PC is sitting on what is now a SMULL instruction.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: arm-eabi-gcc generating UMULL

Post by BlueCrab »

Out of curiosity, what exactly are you trying to run? My gut instinct here (barring some weird GCC bug) would be that somehow your code is jumping into some place in RAM it doesn't belong, thus causing it to try to execute random junk as code... Either that, or somehow you've overwritten your code with data (which would be very easy to do from the SH4 side).
User avatar
MisterDave
DCEmu Freak
DCEmu Freak
Posts: 58
Joined: Mon Apr 08, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

Re: arm-eabi-gcc generating UMULL

Post by MisterDave »

Sure, would be happy to - the motivation is to see if I can offload some of my lighting engine and run it on the slow ARM when I'm rendering with the PVR. Off the top of my head, the code is really just a couple of loops and a sin and cosine lookup table. I'm also storing two 512*512 buffers at a hard coded address set based on the s3m example, so there could be some code overwriting there if I've introduced something buggy in there somewhere.

When I get back to my computer and the source this weekend I'll post more detail.
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: arm-eabi-gcc generating UMULL

Post by PH3NOM »

Hi there MisterDave, it is always interesting to see what you are up to! :lol:

But I'm not sure this is the best approach?

If you are convinced that is the route to go you might want to check out the library by ayla posted on this thread
http://www.dcemulation.org/phpBB/viewto ... 9&t=102330

But my experience has indicated that the ARM cpu in the Dreamcast is SLOW at general purpose code execution.
For example, make a simple test code to run a very simple loop on the SH4 and the ARM.
Record the time it takes for both process to complete. You will see that even iterating a simple loop can take considerable time on the ARM.
I think running some simple look-ups should be very fast on the SH4.
Are you planning to output audio? I can imagine some problems trying to run code like this while having the system stream audio samples from the cpu.

I think your endgame is really to minimize the effect of the rendering process on the main CPU?
If so, you might want to consider some threading models.
In my mind, the biggest waste is

Code: Select all

pvr_wait_ready();
Maybe that could be done in a thread while you perform your code you are trying to offload in another?
User avatar
MisterDave
DCEmu Freak
DCEmu Freak
Posts: 58
Joined: Mon Apr 08, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

Re: arm-eabi-gcc generating UMULL

Post by MisterDave »

PH3NOM, the SH4 threading approach is something that I'm also wanting to consider with the ARM just being a little experiment just for fun (but not really something that would give any extra parallel performance). I was initially cautious about running multiple threads on the one SH4 core as from what I have benchmarked so far rendering with the PVR is so dependent on the SH4 for the matrix manipulation that it didn't seem to be idling too much in the rendering sections. I hadn't considered 'pvr_wait_ready()' to be something to look into for sneaking in a bit of extra execution time, but thanks for the suggestion and I will give it a try.

BlueCrab, the most relevant sections of the ARM code is really just:

float cos_table[] ={
1.0f,....

volatile int *sh4_light_x = (int *)(0x80000 + 0x4);
volatile int *sh4_light_y = (int *)(0x80000 + 0x4 + 0x4);
volatile int *sh4_light_z = (int *)(0x80000 + 0x4 + 0x4 + 0x4);

volatile unsigned char *height_buffer = (unsigned char *)0x100000;// 1 meg in //(0x10000 + 8 + 8 + 8 + (MAP_WIDTH*MAP_HEIGHT));
volatile unsigned char *shadow_buffer = (unsigned char *)(0x100000 + 0x200*0x200); //0x200 is 512

//Go through the arc
for( light_angle = light_angle_start; light_angle < light_angle_end; light_angle += light_skip_angle )
{
...
for( distance = 0.0f; distance < DEFAULT_LIGHT_DISTANCE; distance += 1.0f )
{
...
float sin_pre_calc = sin_table[light_angle % 360];
...
float end_x = (float)(*sh4_light_x) + sin_pre_calc;
float end_z = (float)(*sh4_light_z) - cos_pre_calc;
...

unsigned char raw_height_value = height_buffer[ end_x + MAP_WIDTH*end_z];

--> The SMULL appears to be generated from in the above statement.
Either that, or somehow you've overwritten your code with data (which would be very easy to do from the SH4 side)
That's probably my problem, but looking at how I've allocated my shared buffers and light coords I have left quite a bit of space from the start and end of the 2MB ARM RAM, however, saying that I can't recall where the ARM allocates it's stack.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: arm-eabi-gcc generating UMULL

Post by BlueCrab »

Look at the binary you're producing from the compiler and see if it has any illegal instructions when you disassemble it. If the binary itself doesn't contain any illegal instructions, then it's a runtime problem.

If it does, then you probably have a GCC bug that should be reported to the GCC bug tracker.
Post Reply