> On 4/30/2015 10:12 AM, David Brown wrote:
>> On 30/04/15 14:37, rickman wrote:
>>> On 4/30/2015 8:09 AM, John Devereux wrote:
>>>>
>>>>> On Monday, December 13, 2004 at 4:12:22 PM UTC+1, Thomas Carley wrote:
>>
>>>>
>>>>>> http://www.codesourcery.com/gnu_toolchains/arm.html
>>>>
>>>> This is good too but last time I looked had restricted libraries unless
>>>> you buy the for-pay version.
>>>
>>> Is there anything to prevent someone who has paid for this to release it
>>> publicly? Doesn't the license allow that? I think what you are really
>>> paying for is the support, no?
>>>
>>
>> I don't think you can release the binaries openly, but you can certainly
>> release the source code (which CodeSourcery, now owned by Mentor,
>> provide). To be useful, you would need to remove the license check code
>> that CS adds to their paid-for versions (to check the validity of your
>> license) - this check code is clearly written and under the GPL, and
>> included with the sources (and obviously also with the binaries).
>>
>> There will be additional restrictions on some of the target libraries,
>> some of which is CS's own code and under their licensing (for
>> unrestricted use on the target, but with restrictions on usage for
>> development). You also don't get the source code to all of these
>> libraries except with the most expensive options.
>>
>> So you pay for support (by the folks that actually maintain the ARM
>> port, and do a large amount of the gcc and gcc-arm development),
>> additional libraries, debugging "sprites" (code interfacing the hardware
>> to gdb and Eclipse), and the pre-packaging.
>>
>> In addition, you pay for the knowledge that the binaries you are getting
>> are well-testing, and have been run through third-party test suites like
>> Plum Hall (but I believe you must pay a fair amount extra if want the
>> results and certificates of such tests).
>>
>>
>> But you are certainly free to release the source of the toolchain
>> itself, along with some of the libraries. There's not much point,
>> however, since CodeSourcery makes a "lite" version for free containing
>> exactly the same stuff plus pre-compiled binaries.
>>
>>
>> (Disclaimer - it's been a while since I looked at CodeSourcery's site or
>> read their information, so it's possible that some of this is out of
>> date.)
>
> I was under the impression the free "lite" version was a release older
> than the paid for stuff.
>
I don't think so - but it may not be updated quite as often. But as I
say, I haven't looked for a while.
Reply by rickman●April 30, 20152015-04-30
On 4/30/2015 10:12 AM, David Brown wrote:
> On 30/04/15 14:37, rickman wrote:
>> On 4/30/2015 8:09 AM, John Devereux wrote:
>>>
>>>> On Monday, December 13, 2004 at 4:12:22 PM UTC+1, Thomas Carley wrote:
>
>>>
>>>>> http://www.codesourcery.com/gnu_toolchains/arm.html
>>>
>>> This is good too but last time I looked had restricted libraries unless
>>> you buy the for-pay version.
>>
>> Is there anything to prevent someone who has paid for this to release it
>> publicly? Doesn't the license allow that? I think what you are really
>> paying for is the support, no?
>>
>
> I don't think you can release the binaries openly, but you can certainly
> release the source code (which CodeSourcery, now owned by Mentor,
> provide). To be useful, you would need to remove the license check code
> that CS adds to their paid-for versions (to check the validity of your
> license) - this check code is clearly written and under the GPL, and
> included with the sources (and obviously also with the binaries).
>
> There will be additional restrictions on some of the target libraries,
> some of which is CS's own code and under their licensing (for
> unrestricted use on the target, but with restrictions on usage for
> development). You also don't get the source code to all of these
> libraries except with the most expensive options.
>
> So you pay for support (by the folks that actually maintain the ARM
> port, and do a large amount of the gcc and gcc-arm development),
> additional libraries, debugging "sprites" (code interfacing the hardware
> to gdb and Eclipse), and the pre-packaging.
>
> In addition, you pay for the knowledge that the binaries you are getting
> are well-testing, and have been run through third-party test suites like
> Plum Hall (but I believe you must pay a fair amount extra if want the
> results and certificates of such tests).
>
>
> But you are certainly free to release the source of the toolchain
> itself, along with some of the libraries. There's not much point,
> however, since CodeSourcery makes a "lite" version for free containing
> exactly the same stuff plus pre-compiled binaries.
>
>
> (Disclaimer - it's been a while since I looked at CodeSourcery's site or
> read their information, so it's possible that some of this is out of date.)
I was under the impression the free "lite" version was a release older
than the paid for stuff.
--
Rick
Reply by David Brown●April 30, 20152015-04-30
On 30/04/15 14:37, rickman wrote:
> On 4/30/2015 8:09 AM, John Devereux wrote:
>>
>>> On Monday, December 13, 2004 at 4:12:22 PM UTC+1, Thomas Carley wrote:
>>
>>>> http://www.codesourcery.com/gnu_toolchains/arm.html
>>
>> This is good too but last time I looked had restricted libraries unless
>> you buy the for-pay version.
>
> Is there anything to prevent someone who has paid for this to release it
> publicly? Doesn't the license allow that? I think what you are really
> paying for is the support, no?
>
I don't think you can release the binaries openly, but you can certainly
release the source code (which CodeSourcery, now owned by Mentor,
provide). To be useful, you would need to remove the license check code
that CS adds to their paid-for versions (to check the validity of your
license) - this check code is clearly written and under the GPL, and
included with the sources (and obviously also with the binaries).
There will be additional restrictions on some of the target libraries,
some of which is CS's own code and under their licensing (for
unrestricted use on the target, but with restrictions on usage for
development). You also don't get the source code to all of these
libraries except with the most expensive options.
So you pay for support (by the folks that actually maintain the ARM
port, and do a large amount of the gcc and gcc-arm development),
additional libraries, debugging "sprites" (code interfacing the hardware
to gdb and Eclipse), and the pre-packaging.
In addition, you pay for the knowledge that the binaries you are getting
are well-testing, and have been run through third-party test suites like
Plum Hall (but I believe you must pay a fair amount extra if want the
results and certificates of such tests).
But you are certainly free to release the source of the toolchain
itself, along with some of the libraries. There's not much point,
however, since CodeSourcery makes a "lite" version for free containing
exactly the same stuff plus pre-compiled binaries.
(Disclaimer - it's been a while since I looked at CodeSourcery's site or
read their information, so it's possible that some of this is out of date.)
Reply by rickman●April 30, 20152015-04-30
On 4/30/2015 8:09 AM, John Devereux wrote:
>
>> On Monday, December 13, 2004 at 4:12:22 PM UTC+1, Thomas Carley wrote:
>>> I have found 2 GCC ports for ARM. Any experience or opinions on which is
>>> best?
>>>
>>> Here are links to both.
>>> http://gnuarm.com/
>>> http://www.codesourcery.com/gnu_toolchains/arm.html
>
>
> That site no longer hosts anything as far as I can see. (Or are you just
> trolling for links to it?)
>
> It used to be rickmans site if I am not mistaken, it was a good resource
> in the past, when gcc ARM builds were not so widespread.
I lost the gnuarm.com domain name and it costs a bunch of money now to
reclaim it. The files were very stale though. I only put up the site
and someone else managed the tools. He eventually decided winarm is
better and went that route.
Is there anything to prevent someone who has paid for this to release it
publicly? Doesn't the license allow that? I think what you are really
paying for is the support, no?
--
Rick
Reply by John Devereux●April 30, 20152015-04-30
John Devereux <john@devereux.me.uk> writes:
>> On Monday, December 13, 2004 at 4:12:22 PM UTC+1, Thomas Carley wrote:
>>> I have found 2 GCC ports for ARM. Any experience or opinions on which is
>>> best?
>>>
>>> Here are links to both.
>>> http://gnuarm.com/
>>> http://www.codesourcery.com/gnu_toolchains/arm.html
>
>
> That site no longer hosts anything as far as I can see. (Or are you just
> trolling for links to it?)
>
> It used to be rickmans site if I am not mistaken, it was a good resource
> in the past, when gcc ARM builds were not so widespread.
>
> There is GCC ARM Embedded:
>
> https://launchpad.net/gcc-arm-embedded
>
> ...Which is my current favorite. It is maintained by ARM themselves and has
> no artificial limitations.
>
>>> http://www.codesourcery.com/gnu_toolchains/arm.html
>
> This is good too but last time I looked had restricted libraries unless
> you buy the for-pay version.
Haha I did not see the date on that!
Oh well...
--
John Devereux
That site no longer hosts anything as far as I can see. (Or are you just
trolling for links to it?)
It used to be rickmans site if I am not mistaken, it was a good resource
in the past, when gcc ARM builds were not so widespread.
There is GCC ARM Embedded:
https://launchpad.net/gcc-arm-embedded
...Which is my current favorite. It is maintained by ARM themselves and has
no artificial limitations.
This is good too but last time I looked had restricted libraries unless
you buy the for-pay version.
--
John Devereux
Reply by Robert Wessel●April 30, 20152015-04-30
On Thu, 30 Apr 2015 03:22:08 -0700 (PDT), info@serd.cz wrote:
>On Monday, December 13, 2004 at 4:12:22 PM UTC+1, Thomas Carley wrote:
>> I have found 2 GCC ports for ARM. Any experience or opinions on which is
>> best?
>>
>> Here are links to both.
>> http://gnuarm.com/
>> http://www.codesourcery.com/gnu_toolchains/arm.html
>
>Hello,
>
>do you know where I can find machine codes by math function, exactl big integers ?
There are many. Google for "bignum library".
GMP is one of the most comprehensive and fastest.
Reply by ●April 30, 20152015-04-30
On Monday, December 13, 2004 at 4:12:22 PM UTC+1, Thomas Carley wrote:
Hello,
do you know where I can find machine codes by math function, exactl big integers ?
Thanks
Michal
matej755@seznam.cz
Reply by Andrew Jackson●December 14, 20042004-12-14
Karl
>>
>> Do you have any figures for the actual floating point performance on,
>> say, a 60MHz ARM7?
>
>
> I did some single-precision tests for + - * / with the Keil simulator
> (which assumes 0 waitstates).
>
> Clocks for gcc-3.3.1, clocks for gcc-3.4.3, speedup:
>
> __addsf3: 514 73 7.0x
> __subsf3: 511 74 6.9x
> __mulsf3: 428 49 8.7x
> __divsf3: 634 142 4.5x
>
> If you are using newlib (and you do, if you use the www.gnuarm.com
> compiler) and need square root,
>
> extern float __ieee754_sqrtf(float x);
> a = __ieee754_sqrtf(b);
>
> is much faster than
>
> #include <math.h>
> a = sqrtf(b);
>
> sqrtf() is a wrapper around __ieee754_sqrtf() and adds the C error
> handling (errno and matherr()) stuff.
> Many similar __ieee754_ math functions exist which remove the C error
> handling from the math functions. The unwrapped functions just
> return Inf and NaN as appropriate in error situations.
>
Thanks very much for the information and tip: that's an impressive
improvement in the performance.
Andrew
Reply by Karl Olsen●December 14, 20042004-12-14
In news:pZmdnbH2fZdTASPcRVnyvg@eclipse.net.uk,
Andrew Jackson <alj@nospam.com> typed:
>>> The main difference between the 3.3 and 3.4 line of GCC is the new
>>> C++ parser code that got into 3.4. As usual, that fixes a lot of old
>>> issues and introduces a whole set of new ones. Most of the changes
>>> are around template handling and as such does not really make that
>>> much of a difference for embedded developers. The whole
>>> (overwhelming) list is here: http://gcc.gnu.org/gcc-3.4/changes.html
>>
>> For ARM users, an important item on the list is the floating-point
>> which got literally several times faster with the new hand-coded
>> routines.
>
> Do you have any figures for the actual floating point performance on,
> say, a 60MHz ARM7?
I did some single-precision tests for + - * / with the Keil simulator (which
assumes 0 waitstates).
Clocks for gcc-3.3.1, clocks for gcc-3.4.3, speedup:
__addsf3: 514 73 7.0x
__subsf3: 511 74 6.9x
__mulsf3: 428 49 8.7x
__divsf3: 634 142 4.5x
If you are using newlib (and you do, if you use the www.gnuarm.com compiler)
and need square root,
extern float __ieee754_sqrtf(float x);
a = __ieee754_sqrtf(b);
is much faster than
#include <math.h>
a = sqrtf(b);
sqrtf() is a wrapper around __ieee754_sqrtf() and adds the C error handling
(errno and matherr()) stuff.
Many similar __ieee754_ math functions exist which remove the C error
handling from the math functions. The unwrapped functions just return Inf
and NaN as appropriate in error situations.
Karl Olsen