embarassing 'c' problem

Apr 03, 2005 4 Replies

Hi,



I'm working on a home project (embedded using Palm IIIx) and am having trouble writing to the system address space. I'm trying to write to the register that controls the cursor size. I can write to it ok using gdb (set *0xfffffa1c=0x1f1f), but the following program does nothing:


typedef unsigned short WORD; #define LCD_CURSOR_W_H *((volatile WORD *) 0xfffffa1c) // LCWCH



int main(void) { LCD_CURSOR_W_H = 0x1f1f;



while(1);



return 0; }


I compiled with prc-tools (gcc version 2.95.3) running in cygwin and with a cross compiler I built and ran on my linux box using gcc version



3.4.3. That gcc's -v: Configured with: ../../source/gcc-3.4.3/configure --target=m68k-elf --prefix=/usr/ local/m68k --with-newlib

Here's the output of objdump -S on main.o (same for both except for how while(1) is handled:



int main(void) { 0: 4e56 0000 linkw %fp,#0 LCD_CURSOR_W_H = 0x1f1f; 4: 31fc 1f1f fa1c movew #7967,fffffa1c



while(1); a: 60fe bras a c: 4e71 nop



Notice the odd 3B machine code output for the assembler line "movew...". I don't think that's right--wheres the preceeding word of



0xffff for the address? It looks like a bug, but how could it have gone unnoticed all this time? I must be doing something dumb. Geesh this should be easy. :) Please enlighten me!


Jim



It is implied. This is using 16-bit absolute addressing, which is sign-extending the address to 32 bits before it is used. See section

2.2.16 in the M68000PRM.

Andreas.

Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."

Hmm. I wonder if the "// LCWCH" is getting interpreted as part of the #define, so that your first line of main expands to

*((volatile WORD *) 0xfffffa1c) // LCWCH = 0x1f1f;

The bit before the "//" is a valid C statement and the rest after the "//" looks like a comment. So, if you've managed to get a stray semicolon on the next line, the whole thing will parse as effectively a dummy statement.

Richard [in PE12]

Andreas,

Thanks for the reply. Yeah, I couldn't believe I was seeing a compiler bug 'cause uCLinux ran on the Palms.

I'm guessing the supervisor bit must've been cleared by the startup rom program. Apparently, once you enter user mode, only an exception gets you to supervisor mode. And you have to be in supervisor mode to write to the system registers. What a pain :).

Jim

Hi Richard,

That comment after the #define is legit in ANSI C. Yeah, I get questions from other engineers every now and then about that. See my response to Andreas's reply for what I think the problem is.

Jim

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required