http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10565 <pre>That's now done using standard gcc builtin functions. __attribute__((interrupt(ISR_VECTOR))) void isr () { extern volatile void* ra_isr; extern volatile void* fa_isr; /* Read the vector to clear the interrupt. */ (void)P1IV; /* { dg-final { scan-assembler "mov\t2\\(r4\\), &amp;ra_isr *\n" } } */ ra_isr = __builtin_return_address(0); /* { dg-final { scan-assembler "mov\tr4, &amp;fa_fnma *\n" } } */ fa_isr = __builtin_frame_address(0); } On Fri, May 18, 2012 at 4:19 PM, Sergei Sharonov &lt;sergei&lt; at &gt;houston-radar.com&gt; wrote: ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Peter Bigot 2012-05-18T21:39:34 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10564 <pre>Dear All, I am porting some old code from mspgcc v3.x to v4.x and came across missing macro GET_FRAME_ADDR_F(). I was using that to determine from ISR if CPU was sleeping: psr = (int *) GET_FRAME_ADDR_F(__FUNCTION__); if((*psr &amp; (LPM3_bits)) == LPM3_bits) { /* in LPM3 mode */ .... What is the preferred method of doing that with a new toolchain? Thanks, Sergei ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Sergei Sharonov 2012-05-18T21:19:52 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10563 <pre> Is floating point code linked in somewhere? I haven't worked much with msp430-gcc for a while, and I seldom use printf(), but very often unexpected large code size can be traced to including floating point support by mistake. Other things to look for in the map file are if you've accidentally pulled in other large chunks of the C library. Sometimes innocent looking library functions end up forcing in malloc() and friends, or exit(), or other bits and pieces. Adding a stub such as "void exit(void) {}" in the C code can sometimes eliminate this sort of thing. As for "magic flags", does link-time optimisation work for msp430-gcc? If not, then maybe "-combine -fwhole-program" could help? mvh., David ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile securit</pre> David Brown 2012-05-18T08:08:49 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10562 <pre> Checking inlines is not a "stupid" suggestion - it's quite a relevant one. But also don't forget that sometimes inlining /saves/ code space - if your code makes heavy use of silly little "getter" and "setter" functions, then making these inline will save the compiler from generating function calls and give it far more freedom to optimise register usage and ultimately save a lot of code space. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> David Brown 2012-05-18T08:00:08 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10561 <pre> Using these flags will only reduce code size if you have source code (or data) that is compiled but never used in the binary. In most cases, that indicates a mistake in the source code or that the source is due for a spring clean. (Some people make more active use of such flags, letting them write library-style code modules for re-use in different projects, and therefore have good reason for having lots of "unused" code.) mvh., David ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> David Brown 2012-05-18T07:56:22 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10560 <pre> Sometimes the ability to debug conflicts with the optimiser, as you say. When gcc is used both with "-g" and with heavy optimisations, it does its best to resolve them and give you debugable optimised code. But I am not sure whether it always sacrifices debugging to give you optimal code when there is a conflict - it may pick a different balance. So removing the debug flag is worth trying, as it /may/ have some effect - but it will only be a very marginal effect at most. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> David Brown 2012-05-18T07:53:00 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10559 <pre>Hi Everyone, I finally got around to doing some work towards packaging the uniarch version of mspgcc and friends for Fedora. I'm working on getting them into the Fedora repos, but in the meantime you can grab the RPMs from here: http://users.ecs.soton.ac.uk/rds/rpm/mspgcc-uniarch/ Cheers, Rob ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Rob Spanton 2012-05-17T21:15:22 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10558 <pre>2012/5/16 William Antunes da Maia &lt;will.antunesdamaia&lt; at &gt;gmail.com&gt;: use I haven't yet tried it with Windows myself yet, so I can't say if it works. The code for the plugin is publicly available at https://gitorious.org/msp430eclipse and patches are welcome. No problem. Let me know if you have problems and suggestions. Best regards, Paul ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Mspgcc-users mailing list Mspgcc-users&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users </pre> Paul Fleischer 2012-05-17T06:48:29 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10557 <pre>Peter Bigot scrisse: Last month has seen some troubles with a tentative main gcc transition in debian, so I've hold the upload a bit. Moreover, as Peter has seen, as I was not able to pinpoint why debian patches and mspgcc won't work/build on some architecture, I'm now approaching the vanilla sources and see if everything is ok. Packages are now on their way to experimental. Cheers, Luca </pre> Luca Bruno 2012-05-17T06:37:59 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10556 <pre>2012/5/16 Peter Bigot &lt;bigotp&lt; at &gt;acm.org&gt;: Therefore I would suggest to compare the code size on a module by module basis (e.g. msp430-size -t *.o) and compare it with the output of the linker map file from IAR (Don't know exactly anymore, but IAR could generate a file with all the linker information and the size of the individual modules). That should give you an idea if the code size difference is mainly in your code, or contributed by the libc. Other stupid suggestions: Check for use of inline functions. I am currently using a fixpoint library, which originally defined all basic operations as inline functions in its header file. Well, something like "return (fixedpt_t)(((acc_t)a * (acc_t)b)&gt;&gt;FIXEDPT_SHIFT);" looked quite innocent but with acc_t being "long long" and FIXEDPT_SHIFT=20 there was quite some code generated for each multiplication. Turning that into a function saved a lot. Guido ------------------------------------------------------------------------------ Live Security Virtual Conference Exc</pre> Guido Muesch 2012-05-16T21:40:26 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10555 <pre> No; in fact that's the default for the 4.7.x development series. There should be no issues with the library using those flags; if there are, report it as a tracker item and I'll get it fixed. Peter ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Peter Bigot 2012-05-16T19:16:49 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10554 <pre>Thanks. do you see any harm in compiling the libc with the -fdata-sections -ffunction-sections CFLAGs set? When I compile the library without the 64-bit printf and those flags set, I can successfully link my code. But before I do that, I wanted to know if that would break something. I have the -gc-sections linker flag set in my code's LDFLAG. Thanks adam On 05/16/2012 01:02 PM, Peter Bigot wrote: This email, including any attachments and files transmitted with it, are for the sole use of the intended recipient(s) to whom this email is addressed, and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please be advised that you have received this email in error, and please contact the sender by reply email and destroy all copies (including all electronic and hard copies) of the original message. Thank you. ------------------------------------------------------------------------------ Liv</pre> Adam Ford 2012-05-16T19:04:05 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10553 <pre> On May 16, 2012, at 8:14 AM, Adam Ford wrote: Assuming that the map file numbers match up with the IAR code sizes, you have gcc code size of 49728 and constant size of 6758. While a 10% increase in code size from one compiler to another is somewhat believable, the 37% increase in constant data is pretty mysterious, IMO. If you can track down the causes of that, it might yield some interesting clues. Also, doesn't the 149 have 60K of flash? Even with the larger segments, I only see them adding up to about 56k… BillW ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> William "Chops" Westfield 2012-05-16T19:01:46 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10552 <pre>2012/5/16 William Antunes da Maia &lt;will.antunesdamaia&lt; at &gt;gmail.com&gt;: Morning. [...] I have created a small plugin for Eclipse "MSP430 Eclipse", which integrates mspgcc and MSPDebug into Eclipse. The plugin is still in its early stages, but it should work for basic compile, upload, and debugging. See http://xpg.dk/projects/msp430/msp430-eclipse/ for details. Cheers, Paul ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Paul Fleischer 2012-05-16T18:04:14 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10551 <pre>Thanks Paul, Ill try it in my Ubuntu 10.04, thanks for your contribution. But first, Im trying in Windows, because I want to teach some people to use de MSPGCC and show that isnt IAR the Unique solution workable ! Thanks again Paul for your attention ! 2012/5/16 Paul Fleischer &lt;paul&lt; at &gt;xpg.dk&gt; ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Mspgcc-users mailing list Mspgcc-users&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users </pre> William Antunes da Maia 2012-05-16T18:26:57 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10550 <pre> The biggest low-hanging fruit I've found is to avoid printf(3c), which adds about 2 kB. If you can't avoid it, you can get a few hundred bytes back by building an msp430-libc that doesn't support printing 64-bit integers. Look at the README at the top level of msp430-libc and invoke configure appropriately. Beyond that rather unhelpful suggestion, no, there are no magic flags that I know of. Peter I wonder if we need to add a disclaimer to the list saying that confidentiality disclaimers are meaningless when sent to a publicly archived mailing list. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Peter Bigot 2012-05-16T18:02:46 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10549 <pre>Am 16.05.2012 19:14, schrieb Grant Edwards: Yes, I'm sorry, that was some error on my side. I just checked again and size of the text segment does not increase with the -g switch. Sorry for the noise. Stefan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Stefan Nürnberger 2012-05-16T17:32:53 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10548 <pre> If that's true, it's a compiler bug isn't it?. Enabling debug symbols should not affect the generated code or the size of the resulting text segment. Enabling debug symbols with certain types of optimization doesn't always produce usable results (in terms of setting breakpoints on particular source lines, single-stepping, etc.), but it shouldn't produce a larger code size. </pre> Grant Edwards 2012-05-16T17:14:19 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10547 <pre>If it is purely about code size you should definitely compile without the debugging symbols (drop the -g switch). This should reduce the size of the binary dramatically. Stefan Am 16.05.2012 17:18, schrieb Adam Ford: Live Security Virtual Conference Live Security Virtual Conference ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Stefan Nürnberger 2012-05-16T16:27:38 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10546 <pre>As a followup... I have also compiled without: -fdata-sections -ffunction-sections and linked with --no-keep-memory -Wl,-gc-sections Having them on seems to make the code slightly smaller, but not much. adam On 05/16/2012 10:14 AM, Adam Ford wrote: This email, including any attachments and files transmitted with it, are for the sole use of the intended recipient(s) to whom this email is addressed, and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please be advised that you have received this email in error, and please contact the sender by reply email and destroy all copies (including all electronic and hard copies) of the original message. Thank you. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can resp</pre> Adam Ford 2012-05-16T15:18:00 http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10545 <pre>I'm sorry for bugging people, and I have Googled this question, but the answers I'm finding are really old and I know there are updates to mspgcc since most of the answers were posted.... I am trying to port 3 different programs from IAR to MSPGCC for work. I'm using the latest released version, but 2 of the 3 won't fit even when compiling using optimizations: -mmcu=$(MCU) -g -Os -Wall -fdata-sections -ffunction-sections and linked with --no-keep-memory -Wl,-gc-sections Does anyone have any ideas how I can further optimize the compiler (other than rewriting - which I've been trying to do)? With an MSP430F149 processor, under IAR, the code compiles and links (Code = 45858, data = 3000, CONST=4935) Under GCC, it won't link because '.rodata won't fit into region rom' and rom overflows by 796 bytes. Examining the Map file shows .rodata is 0x1a66 in size, .text is 0xc240 in size, .bss is 0x712 Any ideas how to make the libraries or optimizer make smaller code? adam This email, including any attachments a</pre> Adam Ford 2012-05-16T15:14:52 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.hardware.texas-instruments.msp430.gcc.user