Re: [Mspgcc-users] Unofficial Red Hat Port

2013-09-14 Thread David Brown
On 14/09/13 01:25, DJ Delorie wrote:

 For small targets like this, it is common to compile C++ with -fno-rtti

 True, but even the static objects must be initialized code adds some
 runtime space/time cost.  It's not much, but the smallest MSP430's
 don't have much rom/ram to spare.


Correct me if I'm wrong here, but this only applies when the 
initialisation involves a constructor function rather than just 
assignment of a fixed value.  In C, initialisers must always be a 
compile-time constant, and the static objects are handled just like any 
global objects (but with non-global names) - they go in the initialised 
data section, and are set up before main() starts by a straight copy of 
the flash data into the ram data.

C++ allows initialisers that are not constant - they can be function 
calls, or object constructors.  For global and file-scope objects, these 
are all run before main() is called.  These might add extra code space 
because the constructor calls can't be fully inlined here, but it should 
not be much.

For function-local statics, there is an overhead - as far as I 
understand it, the compiler does the equivalent of this translation:

void foo(void) {
static type local = constructor();
rest_of_foo();
}

implemented very roughly as:

void foo(void) {
static type local;
static bool local_is_initialised = false;

if (!local_is_initialised) {
local = constructor();
local_is_initialised = true;
}
rest_of_foo();
}


If I am correct here, then yes, this means extra code, extra ram, and 
extra run-time to handle such static initialised objects.


However, I don't really see that as a problem.  This is an extra feature 
that C++ gives you, which you do not have to use - it is therefore fine 
that there is a cost associated with using the feature.  It is not like 
exceptions, that can sometimes have a cost even if you don't use them - 
that's why the -fno-exceptions flag is nice.


I wonder if it would be legal for the compiler to translate the above 
foo into:

static type foo_local = constructor();
void foo(void) {
#define local foo_local
rest_of_foo();
}

That way, the static construction of local would be done before main() 
using the table of global constructors (coming after the real global 
constructors, of course), and therefore minimal overhead.  The 
disadvantage is that such static objects would be constructed whether 
they are needed or not - but on embedded systems, you usually aim to 
avoid having functions that are never called, so all static objects 
would need to be constructed sooner or later.


mvh.,

David


--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users


Re: [Mspgcc-users] Unofficial Red Hat Port

2013-09-14 Thread David Brown
On 14/09/13 02:45, Brendan Conoboy wrote:
 On 09/13/2013 12:12 AM, David Brown wrote:
 Do you know of any timeplans for when it will be possible to get
 official toolchain snapshot packages with gcc, binutils and a library
 as prebuilt packages and source bundles?  As a developer, I can play
 around with a self-built gcc, but for professional work it is critical
 to be able to say I am using TI's msp430 gcc toolchain version
 2013-09-12 and know that the library and the code generators are
 identical (including bug-for-bug) whether I use that release on Windows
 or Linux, and whether I get it now or in ten years time.

 I don't mind whether it is Red Hat or TI that handle such packaging and
 releases, but that's what we need.  Getting the port working and into
 the FSF tree is the biggest step in this journey, but it would be nice
 to know the timeframe forward.

 This particular detail is a work in progress.  I would hazard a guess
 that TI will be able to comment in the not too distant future.


That's fine.  I just wanted to be entirely sure that it is coming - I've 
seen enough vendors get this wrong in the past.  I have no doubts that 
Red Hat understands the importance of proper packaging, versioning, and 
the importance for users that they can get exactly the version they 
need, for whatever platform they need, whenever they need it - and that 
they can install and use multiple versions at the same time.

But TI has not yet proved itself in this area (of course, I have no 
reason to think they will get it wrong - I just don't know yet), and I 
have seen Atmel get it wrong with the avr port of gcc.  I have told 
Atmel about this, but they just do not seem to understand the issue - so 
I hope that TI can learn here and do things even better.  (I don't want 
to talk down Atmel here - they do a good job of supporting the avr gcc 
port, and the avr gcc developers and maintainers are fantastic - but a 
few small steps would make things very much better.)

The problem Atmel has is they believe the latest toolchain is always 
the best.  Thus the latest version of their IDE always installs the 
latest compiler toolchain over old toolchains.  Even the toolchain 
only installers insist on upgrading the existing versions and 
overwriting the users PATH - there isn't even any options to avoid this. 
  (This applies mainly to the Windows installers, of course - their 
Linux toolchain packaging is better.)

In embedded development, toolchain versions can be critical - so the 
common rule is that if a project is started with a particular toolchain 
version, it stays with that version.  Changing versions is a major 
change to the project, and will require new rounds of qualifications and 
testing as well as perhaps changes to Makefiles, linker setup, etc.  So 
my development machines typically have many versions of the same 
toolchain for the same target - you never know when you need to make a 
small change to an old project from years ago.

So my ideal is that whenever you (TI and/or Red Hat) release a new 
version of the toolchain, you provide a bundle of gcc, binutils and 
libraries of a particular version.  The package should be available for 
Windows (as a zip file of the directory, and as a setup.exe installer 
for the point-and-click crowd - not everyone is as fussy as me), as a 
pre-build binary tarball for Linux (32-bit x86 version would be enough 
for most cases), and as a source tarball (for archiving and for other 
systems).  Some people might like a Mac version too.  And all these 
packages should be put in an archive that is available for ever after.


I am a professional developer - if such a service costs money, then 
that's okay.  The most convenient method is that my company buys chips 
from TI and TI uses some of that profit to pay for the development tools 
(and Red Hat's services, of course!) - i.e., the tools are free to the 
end user.  And of course payment for service and support is fine too - I 
am sure Red Hat and TI will figure something out here.


If my description here sounds patronising, or preaching to the 
converted, then I am very happy.

David


--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users


Re: [Mspgcc-users] Unofficial Red Hat Port

2013-09-14 Thread DJ Delorie

 Correct me if I'm wrong here, but this only applies when the 
 initialisation involves a constructor function rather than just 
 assignment of a fixed value.

Correct.

 are all run before main() is called.  These might add extra code space 
 because the constructor calls can't be fully inlined here, but it should 
 not be much.

There is some startup code to go through the list of such functions,
and call them all, too.  It's not much, but if every byte counts...

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users