log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- Elsear brings super-fast Networking to Risc PC/A7000/A7000+ (News:)
- Latest hardware upgrade from RISCOSbits (News:)
- RISC OS London Show Report 2024 (News:1)
- Announcing the TIB 2024 Advent Calendar (News:1)
- Code GCC produces that makes you cry #12684 (Prog:39)
- RISCOSbits releases a new laptop solution (News:)
- Rougol November 2024 meeting on monday (News:)
- Drag'n'Drop 14i1 edition reviewed (News:)
- WROCC November 2024 talk o...ay - Andrew Rawnsley (ROD) (News:2)
- October 2024 News Summary (News:3)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
Acorn Arcade forums: Programming: Strange C cross-compiler/ARM emulator bug
 
  Strange C cross-compiler/ARM emulator bug
  monkeyson2 (18:22 27/8/2006)
  monkeyson2 (20:06 27/8/2006)
    Phlamethrower (20:15 27/8/2006)
      monkeyson2 (20:17 27/8/2006)
        monkeyson2 (20:28 27/8/2006)
          monkeyson2 (20:34 27/8/2006)
            Phlamethrower (20:49 27/8/2006)
              monkeyson2 (21:01 27/8/2006)
            adrianl (21:02 27/8/2006)
              monkeyson2 (21:04 27/8/2006)
                adrianl (21:24 27/8/2006)
                  monkeyson2 (21:34 27/8/2006)
                    adrianl (21:36 27/8/2006)
                  adrianl (21:36 27/8/2006)
 
Phil Mellor Message #79292, posted by monkeyson2 at 18:22, 27/8/2006
monkeyson2Please don't let them make me be a monkey butler

Posts: 12380
I think I must be going nuts.

My code was working fine when it was all in one file. I split it into separate files because it was getting a bit big. Now it doesn't work.

touchpadWorld is defined externally in another file (touchpad.c, touchpad.h)

extern touchpad** touchpadWorld;

Then, in world.c, which #includes touchpad.h, I do:

touchpadWorld = (touchpad**) calloc(sizeof(touchpad*), WORLD_WIDTH * WORLD_HEIGHT);

and then a bit later on in another function, I do:

touchpadWorld[xy] = tp; // tp is of type touchpad*
touchpadWorld[xy] != tp) exit(1); // it seems the above line does nothing!

... and the thing exits! But surely something I assign should stay assigned? :|


I'm using the arm-eabi-gcc cross compiler on a PPC Mac to compile for the ARM9 DS, and testing on the Dualis emulator. I know this isn't the best forum to ask on, but I haven't found a decent one for DS emulation yet. And seeing as it used to work, I'm wondering if I've made a simple mistake somewhere.

[Edited by monkeyson2 at 19:23, 27/8/2006]

[Edited by monkeyson2 at 19:26, 27/8/2006]
  ^[ Log in to reply ]
 
Phil Mellor Message #79296, posted by monkeyson2 at 20:06, 27/8/2006, in reply to message #79292
monkeyson2Please don't let them make me be a monkey butler

Posts: 12380
Hmmm. I've changed back to the single file version, and it still doesn't work.

Now, the array has the correct values just before I exit the function. If I check just after calling it, it doesn't. What's going on?!
  ^[ Log in to reply ]
 
Jeffrey Lee Message #79298, posted by Phlamethrower at 20:15, 27/8/2006, in reply to message #79296
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
Check the disassembly?
  ^[ Log in to reply ]
 
Phil Mellor Message #79299, posted by monkeyson2 at 20:17, 27/8/2006, in reply to message #79298
monkeyson2Please don't let them make me be a monkey butler

Posts: 12380
Check the disassembly?
How?

Edit: Ah, -S :)

[Edited by monkeyson2 at 21:25, 27/8/2006]
  ^[ Log in to reply ]
 
Phil Mellor Message #79300, posted by monkeyson2 at 20:28, 27/8/2006, in reply to message #79299
monkeyson2Please don't let them make me be a monkey butler

Posts: 12380
It means nothing to me. :|
  ^[ Log in to reply ]
 
Phil Mellor Message #79302, posted by monkeyson2 at 20:34, 27/8/2006, in reply to message #79300
monkeyson2Please don't let them make me be a monkey butler

Posts: 12380
If I compile without optimisation, it works. :|

Could be a compiler or emulator bug then.

I'd still like to know how apparently unchanged code stopped working though.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #79303, posted by Phlamethrower at 20:49, 27/8/2006, in reply to message #79302
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
if the assembly makes no sense to you, why not post (the releveant parts) here, where it will make sens to us? :P

if you're using a beta/unstable version of th compiler, it's probably best to go for stable version. I've seen some rather scary compiler bugs in beta compilers :S
  ^[ Log in to reply ]
 
Phil Mellor Message #79305, posted by monkeyson2 at 21:01, 27/8/2006, in reply to message #79303
monkeyson2Please don't let them make me be a monkey butler

Posts: 12380
in C:


void world_rect(u8 type, u16 rgb, u8 overwrite, u16 x1, u16 y1, u16 x2, u16 y2, touchpad* tp)
{
u8 check = (type == WORLD_EMPTY) ? WORLD_SCENERY : WORLD_EMPTY;
u16 x, y;
u32 xy = x1 + (y1 << WORLD_SHIFT);
for (y = y1; y < y2; y++)
{
for (x = x1; x < x2; x++)
{
if (overwrite == 0 || world[xy] == check)
{
world[xy] = type;
touchpadWorld[xy] = tp;
VRAM_A[xy] = rgb;
}
xy++;
}
xy += WORLD_WIDTH - x2 + x1;
}
}


Compiled with -O2:

.global world_rect
.code 16
.thumb_func
.type world_rect, %function
world_rect:
.LFB61:
.file 1 "/Users/phil/Documents/NintendoDS/particles/source/world.c"
.loc 1 33 0
push {r4, r5, r6, r7, lr}
.LCFI0:
mov r7, fp
mov r6, sl
mov r5, r9
mov r4, r8
push {r4, r5, r6, r7}
.LCFI1:
.LVL0:
sub sp, sp, #20
.LCFI2:
.loc 1 33 0
str r1, [sp, #4]
ldr r1, [sp, #68]
.LVL1:
mov r9, r3
.LVL2:
str r1, [r3, #12]
add r3, sp, #56
mov r8, r2
ldrh r2, [r3]
.LVL3:
add r3, sp, #60
ldrh r3, [r3]
mov fp, r0
mov sl, r3
add r3, sp, #64
ldrh r1, [r3]
.loc 1 34 0
cmp r0, #0
beq .L2
.LVL4:
mov r3, #0
str r3, [sp, #8]
.LVL5:
.L4:
.loc 1 37 0
cmp r2, r1
bcs .L17
.loc 1 36 0
lsl r3, r2, #8
add r3, r3, r9
mov ip, r3
.LVL6:
sub r1, r1, r2
.LVL7:
mov r3, #0
str r3, [sp, #12]
str r1, [sp]
.LVL8:
.L7:
.loc 1 39 0
cmp r9, sl
bcs .L14
mov r3, ip
mov r1, #208
lsl r1, r1, #19
lsl r5, r3, #2
lsl r3, r3, #1
add r4, r3, r1
mov r2, sl
mov r3, r9
ldr r6, .L23
mov r1, ip
.LVL9:
mov r0, #0
.LVL10:
sub r7, r2, r3
b .L8
.L22:
.loc 1 41 0
ldr r3, [r6]
ldr r2, [sp, #8]
ldrb r3, [r3, r1]
cmp r3, r2
beq .L11
.L12:
.loc 1 47 0
add r3, r0, #1
lsl r3, r3, #16
.loc 1 39 0
lsl r2, r7, #16
.loc 1 47 0
add r1, r1, #1
add r5, r5, #4
add r4, r4, #2
.loc 1 39 0
lsr r0, r3, #16
cmp r2, r3
beq .L21
.L8:
.loc 1 41 0
mov r2, r8
cmp r2, #0
bne .L22
.L11:
.loc 1 43 0
ldr r3, [r6]
.LVL11:
mov r2, fp
strb r2, [r3, r1]
.loc 1 44 0
ldr r3, .L23+4
ldr r3, [r3]
ldr r2, [r3, #12]
str r2, [r3, r5]
.loc 1 45 0
mov r3, sp
ldrh r3, [r3, #4]
strh r3, [r4]
b .L12
.LVL12:
.L21:
.loc 1 39 0
sub r3, r0, #1
lsl r3, r3, #16
lsr r3, r3, #16
add r3, r3, ip
add r3, r3, #1
mov ip, r3
.LVL13:
.L14:
ldr r3, [sp, #12]
.loc 1 37 0
ldr r1, [sp]
.LVL14:
.loc 1 39 0
add r3, r3, #1
lsl r3, r3, #16
.loc 1 37 0
lsl r2, r1, #16
lsr r1, r3, #16
str r1, [sp, #12]
cmp r2, r3
beq .L17
.loc 1 49 0
mov r2, r9
mov r1, sl
sub r3, r2, r1
mov r2, #128
lsl r2, r2, #1
add r3, r3, r2
add ip, ip, r3
b .L7
.LVL15:
.L17:
.loc 1 51 0
add sp, sp, #20
@ sp needed for prologue
.LVL16:
.LVL17:
.LVL18:
pop {r2, r3, r4, r5}
mov r8, r2
mov r9, r3
mov sl, r4
mov fp, r5
pop {r4, r5, r6, r7}
pop {r0}
bx r0
.LVL19:
.L2:
.loc 1 34 0
mov r3, #3
str r3, [sp, #8]
.LVL20:
b .L4
.L24:
.align 2
.L23:
.word world
.word touchpadWorld
  ^[ Log in to reply ]
 
Adrian Lees Message #79306, posted by adrianl at 21:02, 27/8/2006, in reply to message #79302
Member
Posts: 1637
Compiler bug should really be your last hypothesis, and only when you've whittled down the code to an extremely small, simple test case that still misbehaves.

Software is so complex, and there are so many abstractions between what you intended at the source level and the machine-level instruction sequence plus memory contents, that it's very easy to make a mistake somewhere and misattribute culpability to the compiler. It can and does happen, of course, but 9 times out of 10 the true explanation lies elsewhere - memory corruption, use of undefined variables, pointer aliasing etc etc. (Just a couple of days ago I was baffled by the behaviour of my program until I eventually realised that I'd assumed operator precedence that was incorrect, == having higher priority than ^ in C)


[Edited by adrianl at 22:04, 27/8/2006]
  ^[ Log in to reply ]
 
Phil Mellor Message #79307, posted by monkeyson2 at 21:04, 27/8/2006, in reply to message #79306
monkeyson2Please don't let them make me be a monkey butler

Posts: 12380
Software is so complex, and there are so many abstractions between what you intended at the source level and the machine-level instruction sequence plus memory contents, that it's very easy to make a mistake somewhere and misattribute culpability to the compiler. It can and does happen, of course, but 9 times out of 10 the true explanation lies elsewhere - memory corruption, use of undefined variables, pointer aliasing etc etc.
Very true. That's why I'm going to blame the DS emulator instead. :)
  ^[ Log in to reply ]
 
Adrian Lees Message #79311, posted by adrianl at 21:24, 27/8/2006, in reply to message #79307
Member
Posts: 1637
BTW, you've got your calloc() arguments the wrong way round.
  ^[ Log in to reply ]
 
Phil Mellor Message #79315, posted by monkeyson2 at 21:34, 27/8/2006, in reply to message #79311
monkeyson2Please don't let them make me be a monkey butler

Posts: 12380
BTW, you've got your calloc() arguments the wrong way round.
:blush:

Does it matter? Doesn't it just do x * y?
  ^[ Log in to reply ]
 
Adrian Lees Message #79316, posted by adrianl at 21:36, 27/8/2006, in reply to message #79311
Member
Posts: 1637
And on this occasion I do believe you've got a compiler bug -

.LVL2 str r1,[r3, #12] where r3 still holds the value 'x1'
and possibly others, it looks as though the compiler's mapped two variables to the same register or perhaps it's just a broken optimiser;
cba to unravel it all. Unless you want to bugfix the compiler, get a stable version or disable opts ;)
  ^[ Log in to reply ]
 
Adrian Lees Message #79317, posted by adrianl at 21:36, 27/8/2006, in reply to message #79315
Member
Posts: 1637
Does it matter? Doesn't it just do x * y?
I didn't say it matters, in the sense of breaking the code. It's very unlikely to give problems in practice.
  ^[ Log in to reply ]
 

Acorn Arcade forums: Programming: Strange C cross-compiler/ARM emulator bug