[Mspgcc-users] MSPDebug, Olimex MSP430-JTAG-TINY
Hi All, Daniel and I have put into mspdebug code to enable the use of MSP430-JTAG-TINY device. This is this http://www.olimex.com/dev/msp-jtag-tiny.html device. The protocol of these are mostly the same as the TI-UIF although the baud rate and framing are slightly different. The changes are in the mspdebug GIT repository at the moment. Using the MSP430-JTAG-TINY under linux requires modifiing the cp210x driver and rebuilding it with the new VID etc for the device (15ba:0002). The serial adaptor inside the device is a SiLABS CP2102, which is then connected to a msp430x169. I need to add some documents on how to do this sometime. If anyone has one of these devices and want to give it a go, check out the code and give it a try. Regards, Peter Jansen
Re: [Mspgcc-users] memory input 0 is not directly addressable
Compiles and links perfectly on my 12/08 mspgcc.
Somehow the calculation PORT1_VECTOR + VECTOR_OFFSET lets the compiler cough
and does not resolve to either a relocation (to be filled by the linker) or a
discrete value.
Is PORT1_VECTOR known at this point?
JMGross
- Ursprüngliche Nachricht -
Von: Mark Rages
An: GCC for MSP430 - http://mspgcc.sf.net
Gesendet am: 16 Jun 2010 00:35:32
Betreff: [Mspgcc-users] memory input 0 is not directly addressable
I'm writing a little bootloader and I am jumping from the interrupt
vector to the relocated interrupted vector with little functions like
this
interrupt (PORT1_VECTOR) __attribute((naked)) PORT1SR (void) {
asm(br 0xfde4 :: );
}
This compiles and works fine. But it is ugly and has a magic number
in the assembly string.
So I would like to parameterize it out of the way:
#define VECTOR_OFFSET (-512)
interrupt (PORT1_VECTOR) __attribute((naked)) PORT1SR (void) {
asm(br %[add] :: [add] m (PORT1_VECTOR + VECTOR_OFFSET));
}
but this gives me an error:
main.c: In function PORT1SR:
main.c:18: error: memory input 0 is not directly addressable
What does not directly addressable mean?
Regards,
Mark
markra...@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
markra...@midwesttelecine.com
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Unused functions occupying unnecessary memory
I had this happen long time ago when I included the different object files or libraries in the wrong order with GCC under linux. After reordering them so that their contend had already been referenced, all was well. I think I had similar problems (immediately solved) with mspgcc. If these compiler flags allow treating different functions in the same files to be kept or discarded depending of whether they are used, it's obvious that they need to be be considered unused when they haven't been referenced yet. (It would be pretty useless to have such a feature if it could be inhibited by circular references of dead code.) Unless the linker has been greatly improved since then, the problem should be there. Maybe I'm wrong. About the reduced effectiveness of the optimization, this one is obvious. If the linker is allowed to include or discard parts of a compilation unit depending of their usage, the compiler may not do any optimization that crosses the boundary between functions. Else either common code may disappear when not linked or a reference is generated that will keep the normally unused other function from being excluded from the build. Or the common part is referenced by both with a branch (instead of a relative jump), making the code less efficient. Also, some addressing modes cannot be used under such a setup. Optimizations INSIDE a function are not touched, of course. Only those across functions (e.g. identical exit code). The common subexpression elimination was a bad example. (I was a bit in haste when I wrote this, it was at the end of my office hours) JMGross - Ursprüngliche Nachricht - Von: Grant Edwards An: mspgcc-users@lists.sourceforge.net Gesendet am: 15 Jun 2010 20:26:25 Betreff: Re: [Mspgcc-users] Unused functions occupying unnecessary memory On 2010-06-15, JMGross msp...@grossibaer.de wrote: The suggested compiler/linker flags, however, let the compiler treat each function as a separate compilation unit, starting at its own 0-offset address. This means teh compiler will not resolve any local references and let it all to the linker. Since all references are passed to the linker, the linker can link or discard every of these sections depending on the open references. What's references from a different module is kept, what's not referenced will be discarded. But it may happen that parts are discarded bwcause not yet referenced by any of the already loaded modules, bu twill be later and then the reference cannot be resolved as the target had been discarded already. If that happens, it's a bug. Can you post an example of that so it can be fixed? Also, it keeps the compiler for doing optimizations like common subexpression elimination or using the most efficient way to call functions or access variables, as they are all referenced as externals. I'd also be interested in seeing examples of that.
Re: [Mspgcc-users] Unused functions occupying unnecessary memory
On 2010-06-16, JMGross msp...@grossibaer.de wrote: I had this happen long time ago when I included the different object files or libraries in the wrong order with GCC under linux. After reordering them so that their contend had already been referenced, all was well. I think I had similar problems (immediately solved) with mspgcc. Those problems were with the --gc-sections feature? It sounds to me like you were linking libraries before you linked the object files that referenced the routines in the library. That's a different, unrelated issue. If these compiler flags allow treating different functions in the same files to be kept or discarded depending of whether they are used, it's obvious that they need to be be considered unused when they haven't been referenced yet. The garbage collection algorithm used by the linker shouldn't depend what order you link the object files. If you've got examples where it seems to matter, please post it because that's a bug and needs to be fixed. (It would be pretty useless to have such a feature if it could be inhibited by circular references of dead code.) True, but that doesn't mean that the object files have to be a partially ordered set. Nodes are not discarded based on a reference-count -- they're discarded based on a reachability. Unless the linker has been greatly improved since then, the problem should be there. Maybe I'm wrong. You seem to be assuming a single-pass linker. It works in two passes. First it reads all of the object files. Then it starts at all of the nodes (symbols) marked as keep and traverses the reference graph marking all reachable nodes. When it's done traversing the graph, it discards any nodes that haven't been reached from the initial set of keep nodes. Are you sure you're not thinking about the requirement that libraries be paritially ordered with respect to referencing objects? About the reduced effectiveness of the optimization, this one is obvious. If the linker is allowed to include or discard parts of a compilation unit depending of their usage, the compiler may not do any optimization that crosses the boundary between functions. I'm afraid that's not at all obvious to me. Example: A C file contains two functions: foo() and bar(). foo() is called by various external functions. bar() is called only by foo(). The compiler can inline bar() without causing any problems. Else either common code may disappear when not linked or a reference is generated that will keep the normally unused other function from being excluded from the build. Sorry, you've lost me. I'm not saying it doesn't happen, but I can't visualize it. Do you have an example? Or the common part is referenced by both with a branch (instead of a relative jump), making the code less efficient. IIRC, the linker will convert long branches into short/relative jumps at link time. At least it does that for all the other targets I use... Also, some addressing modes cannot be used under such a setup. I don't understand why. Can you provide an actual example? Optimizations INSIDE a function are not touched, of course. Only those across functions (e.g. identical exit code). The common subexpression elimination was a bad example. (I was a bit in haste when I wrote this, it was at the end of my office hours) Some things like optmizing addressing modes for far/short destinations have to be done at link time instead of compile time, but I don't see how that hurts anything. -- Grant Edwards grant.b.edwardsYow! This ASEXUAL PIG at really BOILS my BLOOD gmail.com... He's so ... so ... URGENT!!
Re: [Mspgcc-users] memory input 0 is not directly addressable
The value of PORT1_VECTOR + VECTOR_OFFSET is an integer, which is not the
same as an addressable memory location. In gcc4, the parameter to a memory
reference has to be an lvalue.
Try something like:
asm(br %[add] :: [add] m (*(uint16_t*)(PORT1_VECTOR +
VECTOR_OFFSET)));
Peter
On Tue, Jun 15, 2010 at 5:35 PM, Mark Rages markra...@gmail.com wrote:
I'm writing a little bootloader and I am jumping from the interrupt
vector to the relocated interrupted vector with little functions like
this
interrupt (PORT1_VECTOR) __attribute((naked)) PORT1SR (void) {
asm(br 0xfde4 :: );
}
This compiles and works fine. But it is ugly and has a magic number
in the assembly string.
So I would like to parameterize it out of the way:
#define VECTOR_OFFSET (-512)
interrupt (PORT1_VECTOR) __attribute((naked)) PORT1SR (void) {
asm(br %[add] :: [add] m (PORT1_VECTOR + VECTOR_OFFSET));
}
but this gives me an error:
main.c: In function ‘PORT1SR’:
main.c:18: error: memory input 0 is not directly addressable
What does not directly addressable mean?
Regards,
Mark
markra...@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
markra...@midwesttelecine.com
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
