Oszkar Ambrus wrote:
Actually I haven't really planned anything related to this.
I don't even know yet what these actually mean (well I know it
theoretically, but
not in the compiler-linker context).
The data would definately be in the lower 64K, because of the 16-bit
pointers. (My guess was that nothing had to be changed in this,
because they are already located there, anyway).
Where the read-only data ends up is somewhat dependant on the way the
linking issues are resolved. But traditionally, .rodata is placed after
.text, which would mean it is likely to end up in the high memory if the
linker scripts are not changed appropriately. The RAM is all in low
memory, but it's important to keep pointers to flash data compatible
(this is one of the big advantages of the msp430 over the AVR, for
example). Of course, some people might want to use the extra flash
space for large tables or data, rather than more code...
What to do with the function pointers? Good question. If I want to use
full-size pointers,
I'll probably have to change a lot of things too.
What does using vectors mean? Having two pointers for one address?
Normally, if you have a function "foo", the code for "foo" is placed in
the .text section with the start of the function a symbol labelled
"foo". Any calls to "foo" use this symbol, as do any references to its
address (for use by function pointers).
If the real address of the function needs 20 bits, then you have
complications. Calls and returns must use 20 bit addresses (you need
"calla" when the callee is in high memory, and "reta" if the caller is
in high memory - basically, you need 20-bit call and return throughout).
But if you want to use 16-bit function pointers, since they are
smaller and therefore faster to manipulate and store, you need some sort
of indirection.
One way is to use vectors, or indirect jumps. To handle this, then when
generating function "foo", you make the real function in .text, with the
symbol "real_foo", and you make a small function in a new section
".jumps" called "jump_foo", which consists of a single "bra real_foo"
instruction. When code wants to call "foo" directly, it can use "calla
real_foo", and when it wants to load a function pointer to "foo" it can
use "mov.w #jump_foo, rX" and call it with "calla rX". Since the
".jumps" section is linked into the low memory, these indirect jumps
always have 16-bit addresses. Assuming you can ensure that the right
symbols are used in the two cases, and that unused jump vectors are not
linked in to the code, the cost is simply a small run-time overhead
caused by the double jump, and a small code space overhead for the
required indirect jump.
An alternative way to get your 16-bit function pointers to work is to
fiddle the alignments of functions (at least, those whose address is
taken), and rotate your pointers. To have access to 128 kB space, you
keep all functions aligned to 16-bit addresses (they are aligned like
this anyway), and right-shift the absolute address when it is used.
Calling through function pointers needs a left-shift before the call
(one word, one cycle). If you want access to 256 kB space, you need to
align the functions on double word boundaries, and shift twice (one
word, two cycles). Ideally, you'd have a command-line switch
determining the number of shifts needed, so that it could be optimised
according to the memory available on the chip.
I don't know how these features could best be implemented in gcc. I'd
love to get involved in the details of gcc, but I just don't have the
time. Good luck, and have fun with whatever you manage to do.
mvh.,
David
I think all of this is far too complicated for someone who hasn't ever
used/worked with these stuff.
I'll check the avr-gcc mailing list, thanks for the tip.
Best regards,
Oszkar
*David Brown <[email protected]>*
Sent by: [email protected]
04/13/2007 01:18 PM
Please respond to
"GCC for MSP430 - http://mspgcc.sf.net"; <[email protected]>
To
"GCC for MSP430 - http://mspgcc.sf.net";
<[email protected]>
cc
Subject
Re: [Mspgcc-users] mspcgg to support MSP430X
Before you go any further, you should probably have a look through the
avr-gcc mailing list archives, and possibly look at their
implementations. They have recently gone through a similar process for
the newer AVR cores with larger memories.
If you are only using 16-bit data pointers (and I agree that makes
sense, at least for most applications), then it's important that you put
the rodata section in the low part of the flash in your linker file.
What are you planning to do about function pointers? There are a few
ways to deal with this. You can either have full-size pointers, or put
vectors in the low memory so that function pointer calls are indirect.
It is somewhat of a challenge to get this working well, so that you use
vectors when needed, but don't waste the time or space when they are not
needed.
mvh.,
David
Oszkar Ambrus wrote:
>
> Ok, thank you very much.
> Then probably I'll start working on that, after adding 'calla' to the
> compiler.
>
> I'm not planning to add 20-bit data instructions to the compiler,
> because that would be very hard, and mostly useless.
> What I intend to do is add only tha calla and reta to support 1Mb of
> code size.
>
> What I ran into is that the msp430.c nor the msp430.md do not use an
> emit_call instruction, like other architectures do.
> That complicates things a lot. I do not know where to make it use a
> 20-bit call, if I implement that in binutils.
> So I'd like to see first, that it does generate the correct assembler
> code, and than add the binutils functionality.
>
> Your help would be really appreciated,
> Regards,
> Oszkar
>
>
>
>
>
> *Grant Edwards <[email protected]>*
> Sent by: [email protected]
>
> 04/12/2007 05:41 PM
> Please respond to
> "GCC for MSP430 - http://mspgcc.sf.net";
<[email protected]>
>
>
>
> To
> [email protected]
> cc
>
> Subject
> Re: [Mspgcc-users] mspcgg to support MSP430X
>
>
>
>
>
>
>
>
> On 2007-04-12, Oszkar Ambrus <[email protected]> wrote:
>
> > Thank you for your answers. So actually there isn't any
> > instruction generation for the MSP430X.
> >
> > Which version should I work on, if I want to add support for
> > that? The CVS mspgcc contains mspgcc for gcc-4.1.1 as well.
> >
> > And how should I start working? I added the 'reta' instruction
> > into the msp430.c file, but can't seem to find where to add
> > 'calla'. Are there many other things that need to be changed
> > (like binutils)?
>
> I presume that new 20-bit relocation types need to be defined
> and added to binutils?
>
> > Can I get any help on this anywhere? Should I post these
> > questions somewhere else? :)
>
