embarassing 'c' problem

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

Reply to
Jim
Loading thread data ...

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."
Reply to
Andreas Schwab

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]

Reply to
Jet Morgan

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

Reply to
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

Reply to
Jim

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.