expanding addrs for initializers

DJ Delorie dj@redhat.com
Wed Aug 24 02:45:00 GMT 2005


> Well, no.  If the result isn't the sign-extended version of the
> short, then you got the wrong answer, regardless of how many bits
> are in m16c addresses.

Good point.

In this case (long x = (long)&f) IMHO the intermediate step shouldn't
have been added, because it implies a conversion that wasn't asked for
- conversion to "int".  I've seen a lot of cases where things are
silently converted to int before being converted to the desired mode,
and while some are understandable, it does get annoying at times.

> What you're trying to generate is something that has all 20 bits
> valid.  Or am I mistaking what ".long f" will do?

The correct thing to do is emit ".long f".

Addresses on the r8c/m16c/m32c family are, well, interesting.  The r8c
and m16c have a 20 bit physical address bus, but only 16 bit address
registers.  You can concatenate two registers to form a 32 bit
pointer, or use a 24 bit displacement off a 16 bit register (er, a 24
bit base address plus a 16 bit offset).  "int" is 16 bits.  The reset
vector (well, any interrupt vector) is 32 bits, but only the lower 24
bits are used, and they hold a 20 bit address.  The upper 8 bits, fyi,
hold portions of the flash security key.  Most people set the key to
all zeros just to simplify things.  For gcc, .text goes above 64k but
everything else stays below it.

The m32c has a 24 bit physical address bus, and 24 bit pointers,
and... get this... 24 bit address registers.  Pointers here are
PSImode and convert to 32 bit scalars just fine.  In fact, PSImode
outside of the address registers are 32 bits anyway.  Because the
general registers are 16 bits, though, size_t (and thus array index
math) is done in 16 bits, limiting the size of individual items,
although such items can exist above the 64k address.

The assembler and linker treat everything like 32 bit addresses and
just truncate them according to where they're going.  If you have to
fit a function pointer into 16 bits and it's outside the first 64k, a
thunk is introduced - however, this doesn't work for reset vectors
because they're needed long before the thunks can be copied to low
memory.



More information about the Gcc-patches mailing list