Why so many toolchains ?

IoT Modules Development tools
1

Hi All,

DS appears to support ADS, RVDS, ARM EBI GCC and ARM ELC GCC toolchains.

I have been using ARM ELC GCC with a Q26 without any problems, why so may options ?

Comments please

Thanks,

Mark

2

Why are there so many differnet makes & models of cars available?

3

Point taken.

I re-phrase my question “has anyone created a table for each of the tools chains comparing MPG, top speed, available colours and options” ?

4

I think if you google “compiler wars” you will find plenty of “discussions” i [/i]between the protagonists of the various different compilers… :wink:

Unfortunately, such discussions do seem to have a tendency to quasi-religious bigotry… :frowning:

5

https://forum.sierrawireless.com/t/compiler-preference-gcc-ads-rvds/2493/3

https://forum.sierrawireless.com/t/application-size/4308/6

viewtopic.php?f=107&t=1030&hilit=ads+gcc&start=0

Some time ago, Wavecom used to provide ready-built binaries for all the samples - built by both GCC and ADS. IIRC, the ADS binaries were always noticeably smaller that the GCC ones…

6

Just another point on “why 2 GCC versions?”
The ARM ELF GCC 4.0.1 is the legacy one, we’ve bundled for many years now.
We’ve added a new ARM EABI GCC 4.4.1, starting from Developer Studio 1.1.2
Two main reasons for that:

  • Provide a newer version of GCC (the 4.0.1 is pretty old)
  • Being able to generate code binary compatible with RVDS 4

This second reason means that:
–> we can deliver packages with a smaller number of libraries (if you take a look at latest Open AT Software Suite 2.34 : no ADL lib for GCC EABI, you link your GCC app with the RVDS one.)
–> even in GCC linked apps, you embed RVDS ADL & plug-ins libs (wich are “tighter” as awneil said :wink:)
–> if for any reason you plan to make a plug-in to redistribute it to the community, no need anymore to buy RVDS (unless you need better performances, obviously): you deliver your GCC EABI built lib, and RVDS users will be able to link with it.

7

Does this fix the printf floating-point bug?

8

It could be, but we have a Firmware stack alignment bug which prevent correct handling of floating point values with both RVDS and ARM EABI GCC (This bug is planned for fix in 2.35 Software Suite).

BTW, concerning ARM ELF GCC, since memory stubs have been added to OS 6.34 (for malloc, calloc and free), floating point printf bug is fixed as soon as you add a calloc_r stub in your application:

#include "adl_global.h"

#ifdef __REMOTETASKS__
#define COMPILER "MinGW"
#else
#ifdef __GNU_GCC__
#if __GNUC_MINOR__ >= 4
#define COMPILER "GCC EABI 4.4.1"
#else
#define COMPILER "GCC ARM ELF 4.0.1"
#endif
#else
#if __ARMCC_VERSION >= 300000
#define COMPILER "RVDS"
#else
#define COMPILER "ADS"
#endif
#endif
#endif


#ifdef __GNU_GCC__
void *_calloc_r( struct _reent *reent, size_t n, size_t s)
{
	return calloc(n,s);
}
#endif

void goHandler (adl_atCmdPreParser_t * Params )
{
	// Float handling
	float myFloat = 2.3;
	char buff [ 100 ];
	snprintf ( buff, 100, "My float: %f", myFloat );
	TRACE (( 1, buff ));

	// Answer
	adl_atSendStdResponsePort( ADL_AT_RSP, Params->Port, ADL_STR_OK );
}

void main_task ( void )
{
	TRACE (( 1, "Float test application; built with " COMPILER "; " __TIME__ ));

	// Subscribe to AT command
	adl_atCmdSubscribe ( "at+go", goHandler, ADL_CMD_TYPE_ACT );
}