Tamas Rudnai wrote:

>> Not quite. Firstly, I was talking about /standard/ libraries, where
>> the compiler also "knows" what the functions are supposed to do
>> (because it's defined in the same place where is defined what the
>> compiler itself is supposed to do).
> 
> Now I completely lost. Are you saying that a C compiler recognizes
> specific function calls like printf and when you write printf("hello
> %s", "world"); it realizes that a puts("hello world"); would be much
> cheaper as part of the optimization? 

I'm not talking about C at all; this is a discussion of the merits of
features built into the compiler versus features in a standard library.
I talk about C when discussing Sergio's examples in C, and I talk about
other languages to bring in examples. This discussion is in principle
not specific to any language (other than maybe XSCB, given Sergio's
experience with it :).

But of course a C compiler may recognize a function "printf" and
possibly do such an optimization. IIRC I've heard about C
"preprocessors" that do exactly this: go through your code, analyze all
printf statements and replace them with their idea of what's an optimal
implementation.


> Or you are talking about intrinsic functions within the library ...

We seem to need a definition of "intrinsic function". It seems that
already what Sergio, Olin and I think of when we use this term doesn't
match, and you now added to the mix intrinsic functions in the library
:)

> ... where it still uses the printf function but makes all the code
> optimizations as the library function was written in the place where
> it was called from?

If by "in the place" you mean by the same vendor, then yes, this is a
possibility. 


> That's because of the operator '+' can be overloaded in a string type
> object. In laguages like Pascal the string has a different structure
> than in the ANSI C, so you have the actual length of the string at
> the very beginning of the string  buffer (it is like a minimalistic
> buffer header). That makes it possible to implement string
> manipulations faster and easier -- therefore a string concatenation
> is an easy task by language definition.

Here you're comparing two different string implementations. That's a
different issue; this here is all about built-in vs library. The
question whether Pascal-type strings are more efficient than C-type
strings has nothing to do with this.


>> Now what if I need to handle Unicode strings? Wait for a compiler
>> upgrade? And what if that compiler upgrade doesn't handle the
>> Unicode encoding I need?
> 
> I agree with you that in C++ they put these things in a way that it
> can be extended easily -- especially if the string was handled by
> STL. In the other hand on an x86 PC on the compiler side they only
> needed to change minor things, like replacing "rep movsb"  to "rep
> movsw" and problem solved -- while in C++ these things are function
> calls to the overloaded functions from the string class.

Haven't done much Unicode coding lately? :)  It's not so easy. Unicode
is /not/ just 16-bit wide characters. The arguably most common Unicode
encoding is UTF-8, which has its characters in 8, 16 and 32 bits,
depending on the character. Then there are other flavors, most with
varying character widths. So just treating each character as a 16-bit
entity doesn't work. 


> Also I am not sure with HiTech but in many embedded C compiler you can
> tell which type of printf do you want to use within your application
> (there are some minimalistic version, with some restricted version
> like no float types and the full version). Hang on a minute, are you
> saying the HiTech automatically chooses the smallest/fastest but
> still functional one when you are compiling your application?

Yes. Independently of what exactly HiTech does here (I don't have any of
their PRO compilers), one can go rather far with that and actually, in a
fine-grained way, automatically customize the printf source to really
only include the parts that are actually needed. (As long as you're
thinking of a C library, this could be done by preprocessor macros that
the compiler gathers while analyzing the application and the passes to
the printf source when it compiles it.)

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist