Re using BREAK in 'C'

[William "Chops" Westfield]

On Jul 12, 2009, at 11:58 PM, Marechiare wrote:

>> Getting a 25% speed increase by doing something trivial as
>> buying a new PC sounds good to me, beats waiting for the
>> next software release (which is very unlikely to be that good).
>
> I'm almost sure you are trolling, you were told that reinstalling all
> the software would take a day work. That's not cheap and it could be
> rather tricky for the compatibility issues

You know, I can see both sides of this pretty easily; On the one hand,  
upgrading hardware isn't that easy, especially if you're talking  
multiple users in a corporate environment with a large "other"  
applications portfolio.  This is the scope of IT departments, and I  
think I recall seeing studies that IT departments have NOT shrunk much  
since the mainframe days, despite each user having their own machine.

On the other hand, you see people struggling with ANCIENT computer  
setups, somehow thinking that struggling to run modern software on  
their aging Pentium 3 systems is saving them money vs dropping $500 on  
a new Dell (or whatever.)

Still, it'll be nice when Cadsoft comes out with the multi-core aware  
version of EAGLE and its autorouter.  It'd be a nice carrot for the  
commercial versions, too...  (although frankly I'm not convinced that  
some SW changes wouldn't help more.)

BillW

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

[CDB-3]

:: Does this work reliably when switching the whole system
:: (motherboard, processor, disk controller, ...)?

Define reliably! :)  For most Workstations this works fine, Servers
need a bit of planning and home PC's can be a nightmare.

:: Won't the system load the wrong
:: drivers before it can recognize that it needs other drivers and
:: starts to install them?

The cloning software I'm most familiar with has a utility that allows
drivers to be preloaded.

W7 and to some extent Vista have a better database of drivers inbuilt
and at the very least will boot and just require the new MB CD to be
inserted.

W7 beta/RC1 loaded onto my 4 year old system with no problem, only the
sound card wasn't recognised.

Colin
--
cdb, colin@... on 14/07/2009
 
Web presence: www.btech-online.co.uk  
 
Hosted by:  www.1and1.co.uk/?k_id=7988359
 

 
 
 
 

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

[Bob Blick-4]

On Mon, 13 Jul 2009 13:12:24 -0700, "William Chops Westfield"
<westfw@...> said:
>
> Still, it'll be nice when Cadsoft comes out with the multi-core aware  
> version of EAGLE and its autorouter.  It'd be a nice carrot for the  
> commercial versions, too...  (although frankly I'm not convinced that  
> some SW changes wouldn't help more.)

After seeing Eagle take half an hour to do a poorer job of routing than
15 seconds in SPECCTRA, I have to agree, the software has something to
do with it :)

Cheers,

Bob

--
http://www.fastmail.fm - A fast, anti-spam email service.

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

[Tamas Rudnai]

You just have to install the host operating system and a virtualised one and
install all your application on the guest OS -- on the virtual machine the
"hardware" does not change ;-)

(someone was talking about multi-virtualised hardware, so the virtualisation
works on the virtual memory feature of the CPU+HostOS, then the GuestOS has
it's own VirtualMemory Manager... and then you run a .NET or Java app on it
etc :-)  But who cares? We have enough CPU power and as mentioned earlier we
are able to do the same thing as with the Apple II but with a bit
complicated way :-) )

Tamas


On Mon, Jul 13, 2009 at 9:38 PM, cdb <colin@...> wrote:

>
>
> :: Does this work reliably when switching the whole system
> :: (motherboard, processor, disk controller, ...)?
>
> Define reliably! :)  For most Workstations this works fine, Servers
> need a bit of planning and home PC's can be a nightmare.
>
> :: Won't the system load the wrong
> :: drivers before it can recognize that it needs other drivers and
> :: starts to install them?
>
> The cloning software I'm most familiar with has a utility that allows
> drivers to be preloaded.
>
> W7 and to some extent Vista have a better database of drivers inbuilt
> and at the very least will boot and just require the new MB CD to be
> inserted.
>
> W7 beta/RC1 loaded onto my 4 year old system with no problem, only the
> sound card wasn't recognised.
>
> Colin
> --
> cdb, colin@... on 14/07/2009
>
> Web presence: www.btech-online.co.uk
>
> Hosted by:  www.1and1.co.uk/?k_id=7988359
>
>
>
>
>
>
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

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

[Olin Lathrop]

Tamas Rudnai wrote:

> You just have to install the host operating system and a virtualised
> one and install all your application on the guest OS -- on the
> virtual machine the "hardware" does not change ;-)
>
> (someone was talking about multi-virtualised hardware, so the
> virtualisation works on the virtual memory feature of the CPU+HostOS,
> then the GuestOS has it's own VirtualMemory Manager... and then you
> run a .NET or Java app on it etc :-)  But who cares? We have enough
> CPU power and as mentioned earlier we are able to do the same thing
> as with the Apple II but with a bit complicated way :-) )

It's really funny how threads evolve sometimes.  Upgrading to a new PC was
mentioned as getting a 25% speed increase of your application software, so
running a new OS in a virtual machine on a existing physical machine isn't
going to help.  Of course upgrading the PC was only brought up as a smoke
screen to Tony Smith's original rediculous (now apparently trolling)
statement that no software was speed-critical anymore.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Marechiare]

> :: How is "Disk cloning" related to the reinstalling the
> :: software on a new hardware set?
>
> Some disk cloning software does allow ' foreign ' bare
> metal restore,

As for me, this is totaly unaceptable idea to use third party software
to mess up with the op system at that depth.

A lot of problems even with the standard installation procedure on the
newest hardware, not to say about the security issues.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Dario Greggio (in giro)]

<http://blogs.techrepublic.com.com/programming-and-development/?p=1372&tag=nl.e055>

just an article I found today..
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Dario Greggio wrote:

> <http://blogs.techrepublic.com.com/programming-and-development/?p=1372&tag=nl.e055>
>
> just an article I found today..

The first paragraph of this has been true for at least ten years IMO. I
do a lot of C++ work, but I wouldn't use it for anything where it's not
really advantageous. And given the investment you have to put in to make
C++ actually useful, these are some few typically big and high
performance applications only -- as he says.

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

[sergio masci-2]

On Thu, 9 Jul 2009, Gerhard Fiedler wrote:

> sergio masci wrote:
>
> >> I was talking about standard libraries, where the programmer doesn't
> >> have to attach anything. The difference between libraries in general
> >> and standard libraries is that the standard libraries must conform
> >> to a standard to be a standard library, not any more or any less
> >> than a compiler. Of course such a standard in general doesn't define
> >> how it is implemented, but it defines what it does.
> >
> > So you are saying a standard library (I thought you were talking
> > about the STL as you were also discussing containers at the time)
> > should be different to a user defined library? I think the users
> > would eat you alive if you dared create a divide between the standard
> > and user libraries (such that the user libraries could not optimised
> > to the same high level as the standard libraries).
>
> You were talking about intent. For a normal library, the compiler
> doesn't know about intent. For a library with a standardized interface
> (for example, the C++ STL) the compiler does know about intent.
>
> >> This function should have been part of the interface in the first
> >> place. This is the tricky part of defining a good library interface:
> >> provide the interface that makes sense.
> >
> > No you've missed my point here. It's not that the function was
> > missing it's that the programmer didn't use it and the compiler had
> > no way of knowing that there was a better way to do things - because
> > they were library functions with a brick wall in the way.
>
> I'm not sure whether you're not missing my point. If all three functions
> are defined as functions of a standard library (including their
> semantics), the compiler "knows" about them and what they do. And if
> replace is a suitable (and more efficient) substitution for delete
> followed by an insert, it may substitute it.
>
>
> >> Of course. C for example lacks any multitasking specification; it
> >> wasn't relevant at the time the C spec was created, because it was
> >> handled by the operating system, exclusively.
> >
> > I think you might want to check that. C was used in multitasking
> > situations on bare metal (without a cosey OS or even a supervisor)
> > for some time before the C spec was created. Look at all the apps
> > written for embedded or process control systems in C. Also OCCAM and
> > ADA supported multitasking directly.
>
> I was talking about C, not about other languages. And besides sequence
> points and some additional guarantees for volatile variables, you won't
> find many help in the C standard for multitasking, especially when
> multiple cores are involved.
>
> It has been done, but one needs to know what one does when doing so, and
> it's not necessarily portable. For example, the standard doesn't
> prohibit RMW problems that occur because the compiler would load two
> 16bit variables in a 32bit register, work on one, but write both back
> (while potentially the other one has been overwritten in memory by
> another thread running on another core). There are a number of other
> such problems that are not addressed by the standard.
>
>
> > Having a language and compiler that would generate efficient
> > multitasking code on both a 628 and Windows XP in a multicore
> > processor would be a feat. But the hardest part (that of getting it
> > to work on a 628) is done! Surely you can see that doing the same for
> > a system with MUCH better resources is trivial in comparison.
>
> No, I can't see that. Portable, safe and efficient multitasking on a
> modern multicore system is in no way trivial. It is IMO more complex
> than multitasking on a 628, by a few magnitudes.
>
>
> > This discussion certainly is helping me think more deeply about things
> > I have taken for granted for a long time now.
> >
> > For one thing I wonder just how popular C would have been without the
> > conditional compilation capability provided by the C pre-processor.
> > Allowing one set of source files to be compiled for different
> > targets. There again the interface between the pre-processor and the
> > compiler proper is another brick wall.
>
> I think they serve different purposes, but the C preprocessor has been
> used to address some of the C compiler's shortcomings. I don't think the
> separation (or "brick wall") between the two is really a problem. I
> think C would be a "better C" (especially for small micros) if it had a
> compile-time evaluation capability. And Pascal would have been a better
> Pascal if it came with a preprocessor.
>
> (The latter is a bit easier to address if you're not using an integrated
> IDE like Turbo Pascal, because then you can add a preprocessor step to
> your build step. But then again, everybody would use a different
> preprocessor and the code wouldn't be portable again :)
>
>
> >> If the semantics of assign and mult are clearly defined by a standard,
> >> it could do the same optimizations.
> >
> > Yes it could but again it would be down to the compiler to generate the
> > appropriote optimised code and not just generate code to handle the
> > calling protocol of library functions.
>
> Right. But sometimes the compiler does generate the code for the library
> functions (or at least it's under control of the programmer whether it
> does or not), so I'm not seeing the difference.
>
> Of course, the traditional C concept of separate translation units is
> just the way you're describing. But this doesn't have to be so, and
> supposedly e.g. HiTech's OCG or Microsoft's link-time code generation
> are attempts to improve on this.
>
> I think it may be (trying to be careful here :) that you're focusing too
> much on some arbitrary limitations of C. It's probably unavoidable, but
> many of C's limitations are arbitrary (that is, mostly historical) and
> not necessary.
>
> > Can you not see that in adding more and more attributes to the library
> > all you are really doing is trying to push the libraries into the
> > compiler?
>
> I never thought or wrote about adding attributes to the library. I just
> wasn't thinking in terms of separate translation units, I was thinking
> of /standard/ libraries (that is, libraries with a clearly defined
> interface) and I was thinking about libraries that come in source code.
>
>
> > Yes but we are talking about what comes naturaly not what comes of
> > years of discipline of using a particular language. A great many
> > pleople get caught with this type of integer division in C. It takes
> > years for many people to reliably use integer division (without the
> > odd slip). The compiler is there to help you. The computer is there
> > to do what you want.
>
> I think when it comes to type conversion, it should always be explicit.
> This is especially important on small systems with limited resources. It
> is my experience that more often than not, if you don't do it
> explicitly, you have to comment it one way or another. I prefer not to
> comment it, but to do it explicitly in the code.
>
> > In XCSB the compiler says "Ah, you want to assign the result to a
> > floating point variable therefor I wont just discard the remainder
> > I'll do the calc as a float". In XCSB if you wanted to do an integer
> > division even though the result should be a float you would do
> >
> > x = (int)(y / z)
>
> IMO, as I just said, I don't like automatic conversions. I don't think
> the compiler has a good chance to figure out what I want. Pinning the
> operation on the result is just as dangerous as pinning it on the
> operands. I may divide one 32bit int by another 32bit int and put the
> result into an 8bit int. I don't want the division to be an 8bit int
> division. I may divide an 8bit int by another 8bit int and put the
> result into a 32bit int, and I don't want the division to be a 32bit int
> division. And so on... I think such type conversions should be explicit.
>
>
> > I'm not. The fact is the compiler does not know. It has an interface
> > definition for each funtion in the form of a function prototype in a
> > header file somewhere. But that's about it.
>
> I think this may be the one misunderstanding that we have. I'm thinking
> of libraries that are available in source code with a standardized and
> clearly defined interface, like most (if not all) C++ standard
> libraries.
>
> Also, even though the comparison between XSCB (did I get it right this
> time? :) and C is kind of underlying here, I don't think that C's
> arbitrary limitations are relevant to this discussion /in principle/.
>
> I know that for everyday work, you don't compile the standard library;
> you use pre-compiled "brick walled" object code libraries. (I don't know
> how much e.g. Microsoft's link-time code generation does bring here;
> supposedly, since it's at link time, it would also optimize library code
> that's pre-compiled.) But nothing would prevent the programmer from
> running the compiler on the whole source code.
>

Ok I've read and re-read your posts trying to understand what it is that
you are trying to say in order to better understand how I am failing to
get my point across.

You seem to be saying that provided a set of libraries are well written
and available in source form to the compiler that it can compile these
together with the user program and (given that the compiler is
implemented well enough by the compiler writers) that the compiler should
be able to extract enough information from all the combined source code
to generate a resulting executable that is as good as one that would be
generated if the language had more built-in features such as STRING,
LIST, DYNAMIC ARRAYS etc. Furthermore that the compiler should be able
to catch the same kind of bugs in both cases.

Ok given an infinately fast build system with an infinate amount of RAM
and a mega complex compiler that looks for every possible combination of
source code - breaking it down and rearrangeing everything in an attempt
to understand every possible consequence of every combination of
statements given - then yes I would agree. However this is just
completely impracticle.

As an example lets just consider how many different ways you can append
a number (as a string) to another string:

Here's a simple bit of code:

        char str[100];
        char buff[16];
        int j, len;


        strcpy(str, "hello world");

        lne = strlen(str);

        sprintf(buff, "%d", j);

        strcpy(str+len-1, buff);


another way of doing this would be

        strcpy(str, "hello world");

        sprintf(buff, "%d", j);

        strcat(str, buff);


yet another way would be

        sprintf(str, "hello world%d", j);


and another way would be

        strcpy(str, "hello world");

        sprintf(buff, "%d", j);

        lne = strlen(str);

        strcpy(str+len-1, buff);


and another

        strcpy(str, "hello world");

        sprintf(buff, "%d", j);

        strcpy(str+strlen(str)-1, buff);


and another

        strcpy(str, "hello world");

        sprintf(buff, "%d", j);

        lne = strlen(str);

        str += len-1;

        strcpy(str, buff);


and another

        strcpy(str, "hello world");

        str += sprintf(buff, "%d", j);

        str--;

        strcpy(str, buff);


and another

        strcpy(str, "hello world");

        strcpy(str + sprintf(buff, "%d", j) - 1, buff);


So if I tell the compiler that all the above is simply a way of
appending the ASCII representation of a number to a string what should
it make of the following incorrect piece of code:

        strcpy(str, "hello world");

        sprintf(buff, "%d", j);

        strcpy(str+len-1, buff);


How is the compiler supposed to know that I am trying to append the
ASCII representation of a number to a string and I got it wrong? In this
case is the compiler just supposed to take the code I've written as
correct (because it doesn't recognise what I actually wanted to do) and
so generate an executable with a bug?

if strings were built into the language we might instead write:

        str = "hello world" + string(j)

Wow, how cool is that! So easy to write, so easy to understand when you
come back to it years later. Even a dumb compiler would have no trouble
understanding this statement, and a clever compiler would be able to put
some nice optimisations in place. And we even got rid of the huge printf
library as a side effect.

I'm pretty sure that at this point you will (as others have done) start
telling me that I should be using other functions to "encapsulate" this
fragment of "knowledge". Ok so you encapsulate it, you produce yet
another standard library function but you still have the same problem -
the compiler still needs to be able to understand this fragment if it is
to have the same capabilities as a compiler that has this as a built-in.
The only thing you achive by placing this fragment in a function is to
reduce the possibility that someone will rewrite the code incorrectly.
Note here that I say reduce and not eliminate. A user would still rather
write a couple of lines of code than waste time looking up a trivial
function in an over inflated library. You need to give the user a real
incentive to use this new library function. On the other hand if this
fragment of functionality is built into the language (and compiler) and
is itself a sub-set of a basic component (feature) of the language (e.g.
string handling) then the user will embrace it sooner or later because
he/she will be constantly exposed to this feature and gradually progress
from using basic parts of this feature to the more complex aspects of
it.

Another problem with using functions as opposed to built-ins (call them
features if you like) is where you need to distinguish between the
overloaded functions and the parameters of both are of the same type.
Then you are stuck and need to resort to using different names for the
functions whereas it would be more natural to use one consistant name
(hance the function overloading in the first place).

So say for example I wanted to extract a sub-string from a string. I could
have a function:

        // create a new string from 'pos1' to the end of the string
        str2 = substr(str1, pos1);

        // create a new string from 'pos2' to the start of the string
        pos2 = -pos;
        str2 = substr(str1, pos2);

        // create a new string from 'pos1' to 'pos2'
        str2 = substr(str1, pos1, pos2);


but what if I wanted to extract a sub-string that was a given length
rather than bewteen two positions. I couldn't write

        str2 = substr(str1, pos1, len);


because this would be seen by the compiler as

        substr(char *, int, int);


which also corresponds with the above use for

        str2 = substr(str1, pos1, pos2);


I could have the equivalent functions

        // create a new string from 'pos1' to the end of the string
        str2 = substr_to_end(str1, pos1);

        // create a new string from 'pos1' to the start of the string
        str2 = substr_from_start(str1, pos1);

        // create a new string from 'pos1' to 'pos2'
        str2 = substr(str1, pos1, pos2);

        // create a new string from 'pos1' of length 'len
        str2 = substr_lengeth(str1, pos1, len);



But this comes with it's won hazards, mainly that the user could VERY
easily write:

        str2 = substr(str1, pos1, len);

where he actually needed:

        str2 = substr_lengeth(str1, pos1, len);


Realistically how is a conventional compiler (one that is not mega
complex and running on an infinately fast build machine with an infinate
amount of RAM) going to spot this type of mistake without adding a ton
of attributes to the function prototype?

If strings were built in we could simply say something like

        str2 = substr str1 from pos1 to pos2

or

        str2 = substr str1 from pos1 to end

or

        str2 = substr str1 from pos1 length len




I keep talking about the compiler understanding the intent of the
programmer and you keep saying that a compiler could do this if it had
all the source available. I wonder if what you are really saying is that
the compiler can do more error checking and optimisation because it has
all the source rather than pre-compiled libraries? Because this is
definately not what I'm getting at by "intent". What I mean is (as
above) where the compiler is able to recognise a fragment of code as
meaning "do something special" (such as append one string to another).

This (recognising intent) is easy to do if the language has an
understanding of common basic types such as strings, lists etc but
increadibly hard to do if it does not.

I talk about the brick wall between the compiler and the libraries and
you respond with "make the source of the libraries available". Making
the source available still means that the compiler needs to do a hell of
a lot of work to to try to understand the intend behind each and every
function. How for example would the compiler recognise a function whose
purpose it is to seach a list for a particular string and if it does not
exist then insert a copy of the string into the list in alphabetic
order?

Look at the way programs are commented now so that other programmers
coming along later can understand what a fragment of code is actually
trying to achive. There again we have a brick wall between the comments
and the compiler. The comments don't actually help the compiler verify
or optimise the code.

What we need are features that make it easier for the programmer to
understand the code. Features that cut down on the low level mundane
error prone repetetive code that the programmer needs to write. Features
that allow some of the code and comments to merge - making it hard for
incorrect comments to be left in place and making it easy to see what
the source code actually means. Does this all sound familiar? Isn't this
one of the arguments made when trying to persuade users to move from
assembler to high level languages.

Look at a small fragment for inserting an item into a list:

        item = &root;

        while (*item != NULL)
        {
                if (strcmp((*item)->key, key) > 0)
                {
                        temp = *item;
                        *item = new_item(key);
                        item = &(*item)->next_item;
                        *item = temp;

                        break;
                }

                item = &(*item)->next_item;
        }

re-written another way:

        item = &root;

        while (*item != NULL)
        {
                if (strcmp((*item)->key, key) > 0)
                {
                        break;
                }

                item = &(*item)->next_item;
        }

        if (*item != NULL  &&
            strcmp((*item)->key, key) != 0)
        {
                temp = *item;
                *item = new_item(key);
                item = &(*item)->next_item;
                *item = temp;
        }


Now try writing a rule that understands the above two small
fragments as two identical units.

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

[sergio masci-2]

On Thu, 9 Jul 2009, Olin Lathrop wrote:

> Gerhard Fiedler wrote:
> > You were talking about intent. For a normal library, the compiler
> > doesn't know about intent. For a library with a standardized interface
> > (for example, the C++ STL) the compiler does know about intent.
>
> I think you guys are talking past each other.  I think what Gerhard is
> trying to say, but not doing a good job of it, is that he wants things that
> look like library calls but that are really intrinsic functions that the
> compiler understands natively.  The compiler would completely know the
> intent of these functions and would be free to write in line code, call a
> runtime library function, or optimize the "call" in any other way it sees
> fit.  It could even eliminate it altogether if it could somehow detect that
> results are never used, for example.
>
> I think Sergio is saying is that this would be a great deal of work to add
> that kind of knowledge into the compiler about common functions.
>
> There have been cases where this was done, but naturally they are scarce
> given the considerable compiler development required to support them.
> First, most languages already have a set of intrinsic functions for basic
> low level operations.  Bit shifts in Pascal are done that way, for example.
> The LSHFT and RSHFT functions are known to the compiler and don't cause
> library calls in most implementations.  My Pascal front end detects them and
> a number of other intrinsic functions and writes out their resulting code.
> LSHFT and RSHFT result in the << and >> operators if the result is written
> in C.
>
> Another case I remember is Silicon Graphics built in a few of the key
> graphics calls of GL into their compiler.  Graphics functions are often
> speed-critical since they can easily be executed millions of times while a
> user is waiting for instant response.  A few of the GL calls were mapped
> directly to I/O operations on their proprietary hardware and could be just a
> few instructions.  A true call would have added at least as much overhead as
> the target instructions, and would have prevented the compiler from doing
> any optimization.
>
> All in all I think intrinsic functions should be limited, especially when
> common names are chosen.  It's dangerous to have a lot of reserved names in
> a namespace the user can also create symbols in.  Of course you don't want
> to have keyword bloat either, and the inline function syntax is convenient
> for expressing a lot of things.  So as with everything, its a tradeoff.

Thank you Olin, I had considered that Gerhard was maybe talking about
intrinsic functions. Originally I thought he was saying that the language
should allow you to give the compiler enough info on a nonmal
(non-intrisic) function to be able to use it the same way. Then I cottened
on to the fact that what he was actually saying is that if a compiler
could analyse all the source (including that of the libraries) then it
would be able to extract all the info needed to make a non-intrinsic
function intrinsic.

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

[sergio masci-2]

On Thu, 9 Jul 2009, Gerhard Fiedler wrote:

> sergio masci wrote:
>
> > Having a language and compiler that would generate efficient
> > multitasking code on both a 628 and Windows XP in a multicore
> > processor would be a feat. But the hardest part (that of getting it
> > to work on a 628) is done! Surely you can see that doing the same for
> > a system with MUCH better resources is trivial in comparison.
>
> No, I can't see that. Portable, safe and efficient multitasking on a
> modern multicore system is in no way trivial. It is IMO more complex
> than multitasking on a 628, by a few magnitudes.

No Gerhard the fundamental principle is still indentical - you switch
task contexts. Wheather this means that you need to completely save one
CPU context and load another OR you arrange for the the task contexts to
co-exist and simply switch between them is upto the implementor.

Having multiple CPUs each potentially executing a different task where the
task contexts are not protexted from one another (as in a 628) is no
differnt to having an interrupt coming along and modifying variables
belonging to a task when it is unsafe.

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

[Gerhard Fiedler]

sergio masci wrote:

> Ok I've read and re-read your posts trying to understand what it is
> that you are trying to say in order to better understand how I am
> failing to get my point across.

I resisted the temptation to quote all the stuff again... :)

> You seem to be saying that provided a set of libraries are well
> written and available in source form to the compiler that it can
> compile these together with the user program and (given that the
> compiler is implemented well enough by the compiler writers) that the
> compiler should be able to extract enough information from all the
> combined source code to generate a resulting executable that is as
> good as one that would be generated if the language had more built-in
> features such as STRING, LIST, DYNAMIC ARRAYS etc. Furthermore that
> the compiler should be able to catch the same kind of bugs in both
> cases.

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).

> As an example lets just consider how many different ways you can
> append a number (as a string) to another string:

Secondly, this was (in my mind, at least) a discussion /only/ about the
merits of features built-in (to the compiler) versus implemented in a
(standard) library. This is not a discussion about the shortcomings of C
(or about whether or not XSCB is better than C :).

So I snipped the following... all examples of how something can be done
in C. Whether something is possible or not in C isn't really relevant to
our discussion, I think.

> if strings were built into the language we might instead write:
>
> str = "hello world" + string(j)

See, in C++ for example, strings are /not/ built into the language, and
you can write pretty much exactly this. (Not with the std::string, but
if you extend it a bit, you can, so in the case of C++ it's not really a
question whether or not it can be done with strings in a library but
whether the library definition is sufficient.)

I agree that the lack of a built-in decent string type in C can be a
pain, especially in terms of syntax. OTOH, I bet your strings are 8-bit
strings. 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?

> And we even got rid of the huge printf library as a side effect.

If that's a concern, HiTech for example parses all printf strings in the
whole application and based on that decides what to include into printf.
Since printf is a /standard/ library function, they can do this -- and I
still can override theirs with mine, or make theirs work with my own
putch function. I don't know how exactly they do it, but it doesn't
really matter whether they have a bunch of configuration parameters for
a printf library function and the compiler sets the configuration
parameters accordingly, or whether their printf function is implemented
in the compiler itself. It doesn't matter because it's a standard
library, and as long as their compiler behaves accordingly (and lets me
override their function with my own if I want), it's all fine.


> A user would still rather write a couple of lines of code than waste
> time looking up a trivial function in an over inflated library. You
> need to give the user a real incentive to use this new library
> function. On the other hand if this fragment of functionality is
> built into the language (and compiler) and is itself a sub-set of a
> basic component (feature) of the language (e.g. string handling) then
> the user will embrace it sooner or later because he/she will be
> constantly exposed to this feature and gradually progress from using
> basic parts of this feature to the more complex aspects of it.

It's the number of symbols and their structure that makes a feature set
"over inflated". IMO it doesn't make a difference whether you have 5000
symbols in a library and people think it's too much or whether you have
5000 symbols in a compiler and people think it's too much.


(Snipped prelude to substr argument.)

> But this comes with it's won hazards, mainly that the user could VERY
> easily write:
>
> str2 = substr(str1, pos1, len);
>
> where he actually needed:
>
> str2 = substr_lengeth(str1, pos1, len);
>
> Realistically how is a conventional compiler (one that is not mega
> complex and running on an infinately fast build machine with an
> infinate amount of RAM) going to spot this type of mistake without
> adding a ton of attributes to the function prototype?
>
> If strings were built in we could simply say something like
>
> str2 = substr str1 from pos1 to pos2
>
> or
>
> str2 = substr str1 from pos1 to end
>
> or
>
> str2 = substr str1 from pos1 length len

This is a simple matter of syntax. You don't do much more here than
comparing C-style syntax with BASIC-style syntax. A matter of taste...
The BASIC-style syntax uses "substr ... from ... to" and "substr ...
from ... length". A similar C-style syntax could use substr_from_to and
substr_from_len -- or any number of similar variants. Then there's the
LISP syntax, and a few others. I don't see what this has to do with
built-in vs library.


> I keep talking about the compiler understanding the intent of the
> programmer and you keep saying that a compiler could do this if it
> had all the source available.

Nope, I never said that. I said that if we are talking about /standard/
libraries, the compiler "knows" the intent of the /standard/ library
functions just as well as it knows the intent of the built-in
constructs; both are defined in the same standard.

> I wonder if what you are really saying is that the compiler can do
> more error checking and optimisation because it has all the source
> rather than pre-compiled libraries?

What I'm saying is that if it has the intent /and/ the source (the
implementation), it can apply both for (usually different, and
complementary) optimizations. Not that different from what it can do for
built-in constructs.

> This (recognising intent) is easy to do if the language has an
> understanding of common basic types such as strings, lists etc but
> increadibly hard to do if it does not.

You seem to miss the point that the /intent/ of the functions in
standard libraries is just as defined as the intent of language
constructs built into the compiler.


> I talk about the brick wall between the compiler and the libraries and
> you respond with "make the source of the libraries available".

No. I say consider that the library is a /standard/ library. Adding the
source code is in addition, so that the compiler not only "knows" the
intent, but also sees the implementation.

> How for example would the compiler recognise a function whose purpose
> it is to seach a list for a particular string and if it does not
> exist then insert a copy of the string into the list in alphabetic
> order?

Because this intent is defined in the standard.


> Look at a small fragment for inserting an item into a list:
>
> [snipped C code]
>
> Now try writing a rule that understands the above two small
> fragments as two identical units.

Look at the C++ standard library definition for std::list::insert, for
example. It contains a definition that allows each C++ compiler to
"understand" what a call to std::list::insert is supposed to do.

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

[Gerhard Fiedler]

sergio masci wrote:

> Thank you Olin, I had considered that Gerhard was maybe talking about
> intrinsic functions.

Why don't you just read what I wrote rather than trying to guess? I
pretty much wrote what I meant. If I had meant intrinsics, I'd have
written about intrinsics.

> Then I cottened on to the fact that what he was actually saying is
> that if a compiler could analyse all the source (including that of
> the libraries) then it would be able to extract all the info needed
> to make a non-intrinsic function intrinsic.

No, I never said this. I said that if a library is a /standard/ library
(and I have mentioned this word "standard" a few times; you didn't seem
to pick up on this), the compiler "knows" about the intent of a
function, not any different than it "knows" about the intent of a
language construct. (The intent is a concept that you brought in as
being important, and I don't see what's the difference between a
standardized built-in construct and a standardized library in terms of
"knowing" about the intent.)

The thing about having the lib available in source code is in addition
to this, and about other optimizations (probably lower level than those
that deal with intent).

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

[William "Chops" Westfield]

On Jul 14, 2009, at 8:21 PM, Gerhard Fiedler wrote:

> If I had meant intrinsics, I'd havewritten about intrinsics.

> I said that if a library is a /standard/ library (and I have  
> mentioned this word "standard" a few times; you didn't seem to pick  
> up on this),

What exactly do you see as the difference between an "intrinsic"  
function and a Standard library function?  I mean sin() is a standard  
library function in C, but an intrinsic function in fortran/pascal/
etc, right?

Are you saying that a C compiler could understand that "sin()" is  
standard and generate straight math processor instructions (intel FP  
has had a FSIN instruction since forever) rather than a library call?  
(assuming that it "knows" that the instructions and the library are  
supposed to generate the same results...)

BillW

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

[Tamas Rudnai]

On Wed, Jul 15, 2009 at 4:14 AM, Gerhard Fiedler <lists@...
> 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? Or you are talking about intrinsic functions within 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 strings were built into the language we might instead write:
> >
> >       str = "hello world" + string(j)
>
> See, in C++ for example, strings are /not/ built into the language, and
> you can write pretty much exactly this. (Not with the std::string, but
> if you extend it a bit, you can, so in the case of C++ it's not really a
> question whether or not it can be done with strings in a library but
> whether the library definition is sufficient.)


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.



> I agree that the lack of a built-in decent string type in C can be a
> pain, especially in terms of syntax. OTOH, I bet your strings are 8-bit
> strings. 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.



> If that's a concern, HiTech for example parses all printf strings in the
> whole application and based on that decides what to include into printf.
> Since printf is a /standard/ library function, they can do this -- and I


I think that's a normal dead code elimination -- which you can do that with
either unused object code within a library or with intrinsic type of
functions within the object code. The first technique is rather old one --
in Turbo Pascal for example the linker never put a function from an object
file that was never been accessed to.

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?

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

[sergio masci-2]

On Tue, 14 Jul 2009, William "Chops" Westfield wrote:

>
> On Jul 14, 2009, at 8:21 PM, Gerhard Fiedler wrote:
>
> > If I had meant intrinsics, I'd havewritten about intrinsics.
>
> > I said that if a library is a /standard/ library (and I have  
> > mentioned this word "standard" a few times; you didn't seem to pick  
> > up on this),
>
> What exactly do you see as the difference between an "intrinsic"  
> function and a Standard library function?  I mean sin() is a standard  
> library function in C, but an intrinsic function in fortran/pascal/
> etc, right?
>
> Are you saying that a C compiler could understand that "sin()" is  
> standard and generate straight math processor instructions (intel FP  
> has had a FSIN instruction since forever) rather than a library call?  
> (assuming that it "knows" that the instructions and the library are  
> supposed to generate the same results...)

This is what I now understand Gerhard to mean.

Friendly Regards
Sergio Masci

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

[sergio masci-2]

On Wed, 15 Jul 2009, Gerhard Fiedler wrote:

> sergio masci wrote:
>
> > Thank you Olin, I had considered that Gerhard was maybe talking about
> > intrinsic functions.
>
> Why don't you just read what I wrote rather than trying to guess? I
> pretty much wrote what I meant. If I had meant intrinsics, I'd have
> written about intrinsics.

Hi Gerhard,

Did I upset you? I didn't mean to. I was not trying to "guess" what you
were thinking either, I was trying to understand what you were saying. In
any form of comunication there will be interpretation. You will know what
it is that you are saying. Somethings you will not say because you will
take it for granted that I will infer them (and I may not or I may infer
something else). Somethings you will say something that will have a
particular meaning to you and a slightly different meaning to me.
Sometimes two people can have a discussion, agree on what needs to be
done, leave the discussion and do something the other person was not
expecting.

What I was trying to do was understand "exactly" what you meant rather
than just trying to force you to accept my ideas.

>
> > Then I cottened on to the fact that what he was actually saying is
> > that if a compiler could analyse all the source (including that of
> > the libraries) then it would be able to extract all the info needed
> > to make a non-intrinsic function intrinsic.
>
> No, I never said this. I said that if a library is a /standard/ library
> (and I have mentioned this word "standard" a few times; you didn't seem
> to pick up on this), the compiler "knows" about the intent of a
> function, not any different than it "knows" about the intent of a
> language construct. (The intent is a concept that you brought in as
> being important, and I don't see what's the difference between a
> standardized built-in construct and a standardized library in terms of
> "knowing" about the intent.)
>
> The thing about having the lib available in source code is in addition
> to this, and about other optimizations (probably lower level than those
> that deal with intent).
>

>From what you are saying now, it is clear to me that yes you are talking
about intrinsic functions. Yes the function is defined in a library but
the compiler also knows about the intent of the function. The intent is
seperate from the definition since and is included by the compiler writer
directly into the compiler. The definition of the function is provided by
someone else (library implementor?) and may even be at odds with what the
compiler understands it to be.

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

[sergio masci-2]

On Wed, 15 Jul 2009, Gerhard Fiedler wrote:

> sergio masci wrote:
>
> > Ok I've read and re-read your posts trying to understand what it is
> > that you are trying to say in order to better understand how I am
> > failing to get my point across.
>
> I resisted the temptation to quote all the stuff again... :)

I felt it was necessary because several days have gone by between
your post and my response.

>
> > You seem to be saying that provided a set of libraries are well
> > written and available in source form to the compiler that it can
> > compile these together with the user program and (given that the
> > compiler is implemented well enough by the compiler writers) that the
> > compiler should be able to extract enough information from all the
> > combined source code to generate a resulting executable that is as
> > good as one that would be generated if the language had more built-in
> > features such as STRING, LIST, DYNAMIC ARRAYS etc. Furthermore that
> > the compiler should be able to catch the same kind of bugs in both
> > cases.
>
> 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).

It is now clear to me that you are talking about intrinsic functions. Yes
the function is defined in a /standard/ library but the compiler also
knows about the function independently of the library.

>
> > As an example lets just consider how many different ways you can
> > append a number (as a string) to another string:
>
> Secondly, this was (in my mind, at least) a discussion /only/ about the
> merits of features built-in (to the compiler) versus implemented in a
> (standard) library. This is not a discussion about the shortcomings of C
> (or about whether or not XSCB is better than C :).

Yes I agree this discussion is only about the merits of built-in features
versus library functions. I do use examples written in C because many
people on this list can relate to them and C uses library functions
extensively to overcome its shortcomings.

>
> So I snipped the following... all examples of how something can be done
> in C. Whether something is possible or not in C isn't really relevant to
> our discussion, I think.
>
> > if strings were built into the language we might instead write:
> >
> > str = "hello world" + string(j)
>
> See, in C++ for example, strings are /not/ built into the language, and
> you can write pretty much exactly this. (Not with the std::string, but
> if you extend it a bit, you can, so in the case of C++ it's not really a
> question whether or not it can be done with strings in a library but
> whether the library definition is sufficient.)
>

But the C++ compiler understands what is going on here even less. We now
end up adding even more run time overheads just to make the source code
look better.

> I agree that the lack of a built-in decent string type in C can be a
> pain, especially in terms of syntax. OTOH, I bet your strings are 8-bit
> strings. 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?
>

Yes I understand your point of view, but 8-bit strings are still very
useful even if you need to use Unicode in the same program. Just like
integers are very useful even though you might need to use floating point.

Anyway having built-in features doesn't stop you adding sets of functions
as libraries.

> > And we even got rid of the huge printf library as a side effect.
>
> If that's a concern, HiTech for example parses all printf strings in the
> whole application and based on that decides what to include into printf.
> Since printf is a /standard/ library function, they can do this -- and I
> still can override theirs with mine, or make theirs work with my own
> putch function. I don't know how exactly they do it, but it doesn't
> really matter whether they have a bunch of configuration parameters for
> a printf library function and the compiler sets the configuration
> parameters accordingly, or whether their printf function is implemented
> in the compiler itself. It doesn't matter because it's a standard
> library, and as long as their compiler behaves accordingly (and lets me
> override their function with my own if I want), it's all fine.
>

GCC allows you to add an attribute to a function so that the compiler will
check the type of an actual parameter against a format string.

>
> > A user would still rather write a couple of lines of code than waste
> > time looking up a trivial function in an over inflated library. You
> > need to give the user a real incentive to use this new library
> > function. On the other hand if this fragment of functionality is
> > built into the language (and compiler) and is itself a sub-set of a
> > basic component (feature) of the language (e.g. string handling) then
> > the user will embrace it sooner or later because he/she will be
> > constantly exposed to this feature and gradually progress from using
> > basic parts of this feature to the more complex aspects of it.
>
> It's the number of symbols and their structure that makes a feature set
> "over inflated". IMO it doesn't make a difference whether you have 5000
> symbols in a library and people think it's too much or whether you have
> 5000 symbols in a compiler and people think it's too much.
>

Agreed.

>
> (Snipped prelude to substr argument.)
>
> > But this comes with it's won hazards, mainly that the user could VERY
> > easily write:
> >
> > str2 = substr(str1, pos1, len);
> >
> > where he actually needed:
> >
> > str2 = substr_lengeth(str1, pos1, len);
> >
> > Realistically how is a conventional compiler (one that is not mega
> > complex and running on an infinately fast build machine with an
> > infinate amount of RAM) going to spot this type of mistake without
> > adding a ton of attributes to the function prototype?
> >
> > If strings were built in we could simply say something like
> >
> > str2 = substr str1 from pos1 to pos2
> >
> > or
> >
> > str2 = substr str1 from pos1 to end
> >
> > or
> >
> > str2 = substr str1 from pos1 length len
>
> This is a simple matter of syntax. You don't do much more here than
> comparing C-style syntax with BASIC-style syntax. A matter of taste...
> The BASIC-style syntax uses "substr ... from ... to" and "substr ...
> from ... length". A similar C-style syntax could use substr_from_to and
> substr_from_len -- or any number of similar variants. Then there's the
> LISP syntax, and a few others. I don't see what this has to do with
> built-in vs library.
>

It makes a difference if you consider that each statement helps the
compiler understand what the perpose of a variable is. In the above
example 'length len' within the 'substr' statement allows the compiler to
understand that 'len' is being used to manipulate strings in this fragment
so it WOULD be able to help me catch a simple error such as:

        for (j=0; j<len; j++)
        {
                len2 = strlen(arr[j]);

                arr2[j] = substr(arr[j], 0, len-2);
        }

>
> > I keep talking about the compiler understanding the intent of the
> > programmer and you keep saying that a compiler could do this if it
> > had all the source available.
>
> Nope, I never said that. I said that if we are talking about /standard/
> libraries, the compiler "knows" the intent of the /standard/ library
> functions just as well as it knows the intent of the built-in
> constructs; both are defined in the same standard.

Ok I missinterpreted what you said - sorry :)

>
> > I wonder if what you are really saying is that the compiler can do
> > more error checking and optimisation because it has all the source
> > rather than pre-compiled libraries?
>
> What I'm saying is that if it has the intent /and/ the source (the
> implementation), it can apply both for (usually different, and
> complementary) optimizations. Not that different from what it can do for
> built-in constructs.

Ok, but you really are talking about intrinsics as I understand them with
the addition of a standard library function for each intrinsic.

>
> > This (recognising intent) is easy to do if the language has an
> > understanding of common basic types such as strings, lists etc but
> > increadibly hard to do if it does not.
>
> You seem to miss the point that the /intent/ of the functions in
> standard libraries is just as defined as the intent of language
> constructs built into the compiler.

I understand what you mean by this now.

>
>
> > I talk about the brick wall between the compiler and the libraries and
> > you respond with "make the source of the libraries available".
>
> No. I say consider that the library is a /standard/ library. Adding the
> source code is in addition, so that the compiler not only "knows" the
> intent, but also sees the implementation.

got you. intrinsic + library

>
> > How for example would the compiler recognise a function whose purpose
> > it is to seach a list for a particular string and if it does not
> > exist then insert a copy of the string into the list in alphabetic
> > order?
>
> Because this intent is defined in the standard.
>
>
> > Look at a small fragment for inserting an item into a list:
> >
> > [snipped C code]
> >
> > Now try writing a rule that understands the above two small
> > fragments as two identical units.
>
> Look at the C++ standard library definition for std::list::insert, for
> example. It contains a definition that allows each C++ compiler to
> "understand" what a call to std::list::insert is supposed to do.

I will look at this. Can you point me at a specific doc and library so
that I can be sure to look at exactly what you are looking at.

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

[Olin Lathrop]

Gerhard Fiedler wrote:
> I resisted the temptation to quote all the stuff again... :)

It really has been confusing trying to figure out what exactly your point
is.

> 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).

But that's exactly what intrinsic functions are, which you strongly claimed
you weren't talking about when I suggested that's what you might mean.  Now
I am (and I think Sergio too) really confused.  How is what you mean not
intrinsic functions?

> I agree that the lack of a built-in decent string type in C can be a
> pain, especially in terms of syntax. OTOH, I bet your strings are 8-bit
> strings. Now what if I need to handle Unicode strings?

Tell your customers to use ASCII like civilized people ;-)

> Wait for a
> compiler upgrade? And what if that compiler upgrade doesn't handle the
> Unicode encoding I need?

Note that you're no worse off if it doesn't support the character
representation you like.  The reverse can also be a pain, like Java where
everything is one of those unicode thingies.  Maybe that's nice if you want
to appease some illiterate in a distance jungle somewhere, but it's a hassle
if you want to send a stream of 8 bit characters to a microcontroller.  And
now even 65K glyphs are apparently not enough.  Is this nonsense ever going
to end?

>> And we even got rid of the huge printf library as a side effect.
>
> If that's a concern, HiTech for example parses all printf strings in the
> whole application and based on that decides what to include into printf.

There are usually several ways around a single problem, but I'm not sure
what exactly your point is here.

> Since printf is a /standard/ library function, they can do this -- and I
> still can override theirs with mine, or make theirs work with my own
> putch function. I don't know how exactly they do it, but it doesn't
> really matter whether they have a bunch of configuration parameters for
> a printf library function and the compiler sets the configuration
> parameters accordingly, or whether their printf function is implemented
> in the compiler itself. It doesn't matter because it's a standard
> library, and as long as their compiler behaves accordingly (and lets me
> override their function with my own if I want), it's all fine.

So it sounds like you want a bunch of intrinsic functions (which represent a
large amount of compiler work), but have any optimization defeated and your
own function called if you define one?

> It's the number of symbols and their structure that makes a feature set
> "over inflated". IMO it doesn't make a difference whether you have 5000
> symbols in a library and people think it's too much or whether you have
> 5000 symbols in a compiler and people think it's too much.

I think part of the point is that certain features, like the string handling
Sergio described, require a lot less special syntax when built in than they
would require special functions if "built in" that way.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

sergio masci wrote:
>> Are you saying that a C compiler could understand that "sin()" is
>> standard and generate straight math processor instructions (intel FP
>> has had a FSIN instruction since forever) rather than a library call?
>> (assuming that it "knows" that the instructions and the library are
>> supposed to generate the same results...)
>
> This is what I now understand Gerhard to mean.

I think now that he wants this, which is what a intrisic function is whether
he likes to call it that or not, but also wants to override it if he defines
such a function himself.  I think languages that have intrinsic functions
are split on how this is handled.

I can see the point of generating a error if you try to define your own
routine with the name of a intrinsic function.  Never letting you redefine a
intrinsic is the safe thing to do.  It avoids nasty problems of scope, which
could be difficult to know at link time where some of this may have to be
resolved.  For example, your application may want a specialized version of a
intrinsic function, but its not clear what version a routine deep in a
library ends up getting when you may not even be aware the library used the
particular intrinsice.  In some cases, like if you are making use of special
hardware you know is present, you may want the library routines to use your
version.  In other cases the library may work incorrectly with your version,
if you took a few short cuts to gain speed, for example.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist