On 15 May 2006 08:49:05 +0200, David Brown
<david@westcontrol.removethisbit.com> wrote:

>
>I find the reentrancy data a pain for small programs which don't require 
>have to be thread-safe.  The idea itself is not bad - it means that each 
>thread can have its own copy of errno, stdin, etc.  These are all 
>collected together within a structure, with a single global pointer to 
>the current set.  The disadvantage is that if you use any element of 
>this structure, the whole structure is linked in to ram.  I don't know 
>any way to avoid this other than replacing or avoiding functions using 
>this structure.  Obviously for large programs it makes little difference.

Apart from errno, I do not see much need for reentrancy for the other
functions. It should be quite easy to concentrate any (l)user
interface things, such as printf etc. into the null task, thus,
avoiding most of the reentrancy problems anyway.

Paul

David Brown <david@westcontrol.removethisbit.com> writes:

> John Devereux wrote:
>>
>> What I did was replace malloc+friends with a trivial allocate-only
>> version that only gets called during initialisation.
>>
>> Then I found a public domain minimal (integer) printf that is ideal
>> for my purposes, and now it is integrated into my project I can also
>> easily adapt it to e.g. add my own conversion specifiers.
>>
>>>> However, if you avoid these then everything is quite efficient! My
>>>> test programs are coming out at a few k total, with nothing obviously
>>>> redundant in the object file.
>>
>
> I'm not a fan of malloc or printf myself - at least, not on small
> systems when a few hundred bytes of RAM are important.  The only time
> this has been a problem for me was making use of the time and date
> conversion routines in a program meant to run with 2K of RAM.

What I have ended up with has very little RAM penalty. Of course there
is some stack use during execution, but not much.

My "printf"-style function is quite useful for generating the display
(there is a tiny gui). And I wanted some kind of a "malloc" so that my
library routines are able to allocate their own workspace. They only
do this once during startup, so there is no problem with memory leaks,
indeterminism or heap fragmentation.

-- 

John Devereux

John Devereux wrote:
> David Brown <david@westcontrol.removethisbit.com> writes:
> 
>> John Devereux wrote:
>>> I have been playing with Newlib over the weekend... Basically I had to
>>> replace (or avoid) the printf and malloc families of functions. Which
>>> I am sure is a good idea anyway, for small devices. Also, if you use
>>> any of the library functions that have state, then a "reentrancy" data
>>> structure is linked in which is an additional few hundred bytes of
>>> RAM.
>>>
>> I find the reentrancy data a pain for small programs which don't
>> require have to be thread-safe.  The idea itself is not bad - it means
>> that each thread can have its own copy of errno, stdin, etc.  These
>> are all collected together within a structure, with a single global
>> pointer to the current set.  The disadvantage is that if you use any
>> element of this structure, the whole structure is linked in to ram.  I
>> don't know any way to avoid this other than replacing or avoiding
>> functions using this structure.  Obviously for large programs it makes
>> little difference.
> 
> Yes, this is precisely what I found. Luckily for me it appears that,
> printf and malloc aside, the functions that need the reent structure
> are ones that I never seem to use anyway. Things like strtok,
> multibyte and wide character support, locales. I am sure they have a
> place in larger programs.
> 
> What I did was replace malloc+friends with a trivial allocate-only
> version that only gets called during initialisation.
> 
> Then I found a public domain minimal (integer) printf that is ideal
> for my purposes, and now it is integrated into my project I can also
> easily adapt it to e.g. add my own conversion specifiers.
> 
>>> However, if you avoid these then everything is quite efficient! My
>>> test programs are coming out at a few k total, with nothing obviously
>>> redundant in the object file.
> 

I'm not a fan of malloc or printf myself - at least, not on small 
systems when a few hundred bytes of RAM are important.  The only time 
this has been a problem for me was making use of the time and date 
conversion routines in a program meant to run with 2K of RAM.

David Brown <david@westcontrol.removethisbit.com> writes:

> John Devereux wrote:
>> I have been playing with Newlib over the weekend... Basically I had to
>> replace (or avoid) the printf and malloc families of functions. Which
>> I am sure is a good idea anyway, for small devices. Also, if you use
>> any of the library functions that have state, then a "reentrancy" data
>> structure is linked in which is an additional few hundred bytes of
>> RAM.
>>
>
> I find the reentrancy data a pain for small programs which don't
> require have to be thread-safe.  The idea itself is not bad - it means
> that each thread can have its own copy of errno, stdin, etc.  These
> are all collected together within a structure, with a single global
> pointer to the current set.  The disadvantage is that if you use any
> element of this structure, the whole structure is linked in to ram.  I
> don't know any way to avoid this other than replacing or avoiding
> functions using this structure.  Obviously for large programs it makes
> little difference.

Yes, this is precisely what I found. Luckily for me it appears that,
printf and malloc aside, the functions that need the reent structure
are ones that I never seem to use anyway. Things like strtok,
multibyte and wide character support, locales. I am sure they have a
place in larger programs.

What I did was replace malloc+friends with a trivial allocate-only
version that only gets called during initialisation.

Then I found a public domain minimal (integer) printf that is ideal
for my purposes, and now it is integrated into my project I can also
easily adapt it to e.g. add my own conversion specifiers.

>> However, if you avoid these then everything is quite efficient! My
>> test programs are coming out at a few k total, with nothing obviously
>> redundant in the object file.


-- 

John Devereux

John Devereux wrote:
> "Paul Curtis" <plc@rowley.co.uk> writes:
> 
>> "John Devereux" <jdREMOVE@THISdevereux.me.uk> wrote in message 
>> news:87ejyz5g8u.fsf@cordelia.devereux.me.uk...
>>> Hi Paul,
>>>
>>> We stopped buying "commercial" compilers 5 years ago, after we were
>>> unable to sort out dongle problems (and permanently lost the ability
>>> to compile our own source code!).
>>>
>>> Yours is the first commercial "compiler" (development system) that I
>>> have even *considered* buying since then.
>>>
>>> We primarily use arm-gcc with newlib. This works great for current
>>> projects. But for some of the new small ARM microcontrollers coming
>>> out now, newlib is probably not ideal. Something like avr-libc would
>>> be great but there does not seem to be anything like that as far as I
>>> can tell.
>> newlib is quite big, I grant you.
> 
> Thanks for the response.
> 
> I have been playing with Newlib over the weekend... Basically I had to
> replace (or avoid) the printf and malloc families of functions. Which
> I am sure is a good idea anyway, for small devices. Also, if you use
> any of the library functions that have state, then a "reentrancy" data
> structure is linked in which is an additional few hundred bytes of
> RAM.
> 

I find the reentrancy data a pain for small programs which don't require 
have to be thread-safe.  The idea itself is not bad - it means that each 
thread can have its own copy of errno, stdin, etc.  These are all 
collected together within a structure, with a single global pointer to 
the current set.  The disadvantage is that if you use any element of 
this structure, the whole structure is linked in to ram.  I don't know 
any way to avoid this other than replacing or avoiding functions using 
this structure.  Obviously for large programs it makes little difference.

> However, if you avoid these then everything is quite efficient! My
> test programs are coming out at a few k total, with nothing obviously
> redundant in the object file.
> 

"Paul Curtis" <plc@rowley.co.uk> writes:

> "John Devereux" <jdREMOVE@THISdevereux.me.uk> wrote in message 
> news:87ejyz5g8u.fsf@cordelia.devereux.me.uk...
>>
>> Hi Paul,
>>
>> We stopped buying "commercial" compilers 5 years ago, after we were
>> unable to sort out dongle problems (and permanently lost the ability
>> to compile our own source code!).
>>
>> Yours is the first commercial "compiler" (development system) that I
>> have even *considered* buying since then.
>>
>> We primarily use arm-gcc with newlib. This works great for current
>> projects. But for some of the new small ARM microcontrollers coming
>> out now, newlib is probably not ideal. Something like avr-libc would
>> be great but there does not seem to be anything like that as far as I
>> can tell.
>
> newlib is quite big, I grant you.

Thanks for the response.

I have been playing with Newlib over the weekend... Basically I had to
replace (or avoid) the printf and malloc families of functions. Which
I am sure is a good idea anyway, for small devices. Also, if you use
any of the library functions that have state, then a "reentrancy" data
structure is linked in which is an additional few hundred bytes of
RAM.

However, if you avoid these then everything is quite efficient! My
test programs are coming out at a few k total, with nothing obviously
redundant in the object file.

>>  - what copy protection is there with your product?
>
> We license per developer and you activate your product using the keys we 
> provide you.  A developer can activate the software wherever they feel 
> comfortable, on a laptop, desktop, home PC, lab PC, or any combination 
> thereof.  We also do not license per platform so if you need to use Windows 
> and Linux versions of our software you can, you don't need two licenses.
>
>>  - is the library source code made available (e.g. can you step
>>    through it in the debugger or perhaps compile it with different
>>    options etc).
>
> This is available on request, yes.
>
>>  - do you have any numbers for the amount of code and data space
>>    consumed by the larger functions (e.g. printf, malloc).
>
> Depends upon how you wish to compile this stuff.  We have a number of 
> standard formatters which support varying options such as integer widths 
> (16/32/64) and floating point or not, width and precision specifiers, and 
> character classes for scanf.  You configure what you want in the IDE and the 
> IDE takes care of linking in the right library.  We also offer hosted I/O 
> which means for debugging there is no printf formatter on the target (great 
> for small devices).
>
> Here are some numbers for the program...
>
> void main(void)
> {
>   printf("1=%d", 1);
> }
>
> ...with a simple null putchar and in debug build:
>
> 32-bit int, no width/precision, no fp: 1,340 bytes
> 32-bit int, with width/precision, no fp: 2,148 bytes
> 64-bit int, no width/precision, no fp: 1,732 bytes
> 64-bit int, with width/precision, no fp: 2,704 bytes
> 64-bit int, with width/precision, 64-bit float I/O: 9,772 bytes

Great, thank you.


-- 

John Devereux

"John Devereux" <jdREMOVE@THISdevereux.me.uk> wrote in message 
news:87ejyz5g8u.fsf@cordelia.devereux.me.uk...
>
> Hi Paul,
>
> We stopped buying "commercial" compilers 5 years ago, after we were
> unable to sort out dongle problems (and permanently lost the ability
> to compile our own source code!).
>
> Yours is the first commercial "compiler" (development system) that I
> have even *considered* buying since then.
>
> We primarily use arm-gcc with newlib. This works great for current
> projects. But for some of the new small ARM microcontrollers coming
> out now, newlib is probably not ideal. Something like avr-libc would
> be great but there does not seem to be anything like that as far as I
> can tell.

newlib is quite big, I grant you.

>  - what copy protection is there with your product?

We license per developer and you activate your product using the keys we 
provide you.  A developer can activate the software wherever they feel 
comfortable, on a laptop, desktop, home PC, lab PC, or any combination 
thereof.  We also do not license per platform so if you need to use Windows 
and Linux versions of our software you can, you don't need two licenses.

>  - is the library source code made available (e.g. can you step
>    through it in the debugger or perhaps compile it with different
>    options etc).

This is available on request, yes.

>  - do you have any numbers for the amount of code and data space
>    consumed by the larger functions (e.g. printf, malloc).

Depends upon how you wish to compile this stuff.  We have a number of 
standard formatters which support varying options such as integer widths 
(16/32/64) and floating point or not, width and precision specifiers, and 
character classes for scanf.  You configure what you want in the IDE and the 
IDE takes care of linking in the right library.  We also offer hosted I/O 
which means for debugging there is no printf formatter on the target (great 
for small devices).

Here are some numbers for the program...

void main(void)
{
  printf("1=%d", 1);
}

...with a simple null putchar and in debug build:

32-bit int, no width/precision, no fp: 1,340 bytes
32-bit int, with width/precision, no fp: 2,148 bytes
64-bit int, no width/precision, no fp: 1,732 bytes
64-bit int, with width/precision, no fp: 2,704 bytes
64-bit int, with width/precision, 64-bit float I/O: 9,772 bytes

> Feel free to answer by email if you don't want to say on usenet
> (although I bet others would be interested too!).

They possibly could be.

-- Paul.

"Paul Curtis" <plc@rowley.co.uk> writes:

> "Chris Hills" <chris@phaedsys.org> wrote in message 
> news:K5+gdFCbQcYEFAZv@phaedsys.demon.co.uk...
>> In article <1147255537.443985.258740@y43g2000cwc.googlegroups.com>,
>> larwe <zwsdotcom@gmail.com> writes
>>>
>>>Did you try any of the alternatives, such as Rowley's product for
>>>instance?
>>
>> Why? Because Rowley is GNU.... Not sure why you would suggest buying a
>> gnu compiler though
>
> You should do your homework as an IAR reseller.  Sure, I know you need to 
> promote IAR, but basic facts are just so important.
>
> CrossWorks for MSP430, MAXQ, and AVR are all based on our own compilers 
> which are certainly nothing to do with any GNU world.
>
> Putting that to one side, why would you buy CrossWorks for ARM that's based 
> on GCC and binutils?  Well, you don't buy the GNU software, you're 
> purchasing a whole lot of other stuff that we do well, such as flash 
> programming, support for multiple boards right out of the box, support for 
> cheap JTAG adapters that can actually work with XScale devices, and great 
> product support.  And our own library.  We make the GNU software usable by 
> customers that don't want to configure it themselves by wrapping it in our 
> IDE and providing our own libraries, provide working board support packages, 
> and help customers get going.  You know, that's sometimes a little more than 
> IAR do.  And we don't charge the earth and have a realistic and appropriate 
> licensing policy.  And boy, we also listen to customers, which is what it's 
> all about.
>
> Of course, as a professional, you'd know that, no?

Hi Paul,

We stopped buying "commercial" compilers 5 years ago, after we were
unable to sort out dongle problems (and permanently lost the ability
to compile our own source code!).

Yours is the first commercial "compiler" (development system) that I
have even *considered* buying since then.

We primarily use arm-gcc with newlib. This works great for current
projects. But for some of the new small ARM microcontrollers coming
out now, newlib is probably not ideal. Something like avr-libc would
be great but there does not seem to be anything like that as far as I
can tell.

So,

  - what copy protection is there with your product?

  - is the library source code made available (e.g. can you step
    through it in the debugger or perhaps compile it with different
    options etc).

  - do you have any numbers for the amount of code and data space
    consumed by the larger functions (e.g. printf, malloc).

Feel free to answer by email if you don't want to say on usenet
(although I bet others would be interested too!).

-- 

John Devereux

In article <446491ef$0$2525$ed2619ec@ptn-nntp-reader01.plus.net>, Paul
Curtis <plc@rowley.co.uk> writes
>"Chris Hills" <chris@phaedsys.org> wrote in message 
>news:K5+gdFCbQcYEFAZv@phaedsys.demon.co.uk...
>> In article <1147255537.443985.258740@y43g2000cwc.googlegroups.com>,
>> larwe <zwsdotcom@gmail.com> writes
>>>
>>>Did you try any of the alternatives, such as Rowley's product for
>>>instance?
>>
>> Why? Because Rowley is GNU.... Not sure why you would suggest buying a
>> gnu compiler though
>
>You should do your homework as an IAR reseller.  Sure, I know you need to 
>promote IAR, but basic facts are just so important.
>
>CrossWorks for MSP430, MAXQ, and AVR are all based on our own compilers 
>which are certainly nothing to do with any GNU world.

My apologies... I was thinking ARM. 

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Chris Hills" <chris@phaedsys.org> wrote in message 
news:K5+gdFCbQcYEFAZv@phaedsys.demon.co.uk...
> In article <1147255537.443985.258740@y43g2000cwc.googlegroups.com>,
> larwe <zwsdotcom@gmail.com> writes
>>
>>Did you try any of the alternatives, such as Rowley's product for
>>instance?
>
> Why? Because Rowley is GNU.... Not sure why you would suggest buying a
> gnu compiler though

You should do your homework as an IAR reseller.  Sure, I know you need to 
promote IAR, but basic facts are just so important.

CrossWorks for MSP430, MAXQ, and AVR are all based on our own compilers 
which are certainly nothing to do with any GNU world.

Putting that to one side, why would you buy CrossWorks for ARM that's based 
on GCC and binutils?  Well, you don't buy the GNU software, you're 
purchasing a whole lot of other stuff that we do well, such as flash 
programming, support for multiple boards right out of the box, support for 
cheap JTAG adapters that can actually work with XScale devices, and great 
product support.  And our own library.  We make the GNU software usable by 
customers that don't want to configure it themselves by wrapping it in our 
IDE and providing our own libraries, provide working board support packages, 
and help customers get going.  You know, that's sometimes a little more than 
IAR do.  And we don't charge the earth and have a realistic and appropriate 
licensing policy.  And boy, we also listen to customers, which is what it's 
all about.

Of course, as a professional, you'd know that, no?

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors