Tor, I could have phrased my question better: do all of the functions prototyped in #included files get loaded ... ? So your answer about the linker brings up the next question: how smart is the linker provided with SimpleIDE?
-Phil
Edit: I think Steve has indirectly answered this question.
The linker "provided" with SimpleIDE is actually the one used by GCC since SimpleIDE acts as a frontend to GCC. While not the most capable linker ever written the linker provided with GCC is actually very good only linking in functions that are actually used and the functions they require.
That, of course, depends heavily on how big the program itself is.
Of course - but this argument applies to any of the C library function. That doesn't mean you don't include them - especially when they are such a standard part of the language that you can't claim to implement C without them.
Of course - but this argument applies to any of the C library function. That doesn't mean you don't include them - especially when they are such a standard part of the language that you can't claim to implement C without them.
Ross.
I don't think anyone was suggesting leaving them out. Both PropGCC and Catalina provide them. It's just that more compact versions are sometimes useful on space limited platforms like an unexpanded Propeller.
Though I personally doubt it, and during its later heydays I was using Forth a lot, though for the most part my programs never got bigger than a page of text
And sadly, it seems the same issue applies for Kernighan and Richie's The C Progamming Language:2ed which I have previously provided links to.
If you choose to seek out and download PDF versions, do so at your own risk.
======================
Expert C Programming seems to soothe some of the frustration I have had with learning C late in life. It may help younger programmers that were not aware of the history of C, or why Dennis Richie might say such a thing.
BTW, there was a time when programmers were a fun-loving irrevernt lot. Read the book to find out more about that side of the whoe industry.
I'm sorry if I'm starting this thread up again but I found what appears to be the paper in which Dennis Ritche made the comment that is the title of this thread. I was in a paper he wrote about the history of C. It's a very interesting paper to read and not that long. The fascinating part of the paper was where Dennis critiqued the language with (at the time) ~30 of it being out in the wild!
I'm sorry if I'm starting this thread up again but I found what appears to be the paper in which Dennis Ritche made the comment that is the title of this thread. I was in a paper he wrote about the history of C. It's a very interesting paper to read and not that long. The fascinating part of the paper was where Dennis critiqued the language with (at the time) ~30 of it being out in the wild!
It also occurs to me that using the separate output functions instead of calling printf will let the program run faster, since printf would need to parse the format string every time it's called.
-Phil
I doubt that would be very noticeable but you're right of course.
Forth is intelligible, and works quite nicely on the Propeller.
Meanwhile GCC has me in a tailspin... multiple files with lots of #include "whatever.h", external and internal variables, possible ANSI C 1999 inclusions, standard libraries and non-standard libraries, and so on. And what is pragma? Where is the pragma?
According to this article, "The ‘#pragma’ directive is the method specified by the C standard for providing additional information to the compiler, beyond what is conveyed in the language itself." I particularly like the "poison" pragma. However, I take issue with their pluralizing "pragma" as "pragmas." It should be "pragmata."
At this point I am just grateful that Propeller GCC has apparently not fallen prey to pragmata.
GCC is awash with non-standard pragmas - see here. Also GCC also has another related mechanism you probably need to know about called function attributes.
For a full list of GCC's extensions to the C language, see here.
The GCC pragmas are nearly always for trying to be compatible with some other compiler or architecture, or, when not, for weird testing or diagnostics. Well, better check them out indidivually. Bottom line is that even more so than the GCCisms, its pragmas can easily be considered totally superfluous for standard *nix, ANSI and Posix programming. Other compilers, particularly proprietary compilers (e.g. SGI's MIPSPro) use them more - they may not have more of them, but they sometimes use them instead of compiler options. So whenever I port code from some other system (to gcc) and see a #pragma I can nearly always just delete that line, with no negative effect.
Among GCC's extensions is also 'long long', but that's a 'standard' extension - not what we call a 'GCCism' (nested function calls, on the other hand, is a GCCism). So I have used 'long long' because it's common (although not ANSI, or C89) and it's a 64-bit type on 32- and 64-bit architectures. Then you have 'inline'. It's an extension, but not unique to GCC. I use it in very rare cases (it can easily be made to compile on compilers without them, with a define macro). So yes, I use some of the GCC extensions that are not GCCisms. Among the latter is something that's easy to wish for, if you come from e.g. Turbo Pascal.. case ranges. But that GCCism is designed in an awkward way and in practice it isn't that necessary. So I don't use that one either. I like portability more than any of the features in any case.
Pragmata are wonderful things. With a simple pragma I can get my single threaded code to spread itself out over many processors and get some nice speed gains. For example:
[COLOR=#003366][U]#include <math.h>[/U][/COLOR]
int main[COLOR=#006666]()[/COLOR] [COLOR=#009900]{
[/COLOR] const int size [COLOR=#339900]=[/COLOR] [COLOR=#660099]256[/COLOR][COLOR=#009900];
[/COLOR] double sinTable[COLOR=#009900][[/COLOR]size[COLOR=#009900]];
[/COLOR]
[COLOR=#003366][U]#pragma omp parallel for
[/U][/COLOR] for[COLOR=#006666]([/COLOR]int n[COLOR=#339900]=[/COLOR][COLOR=#660099]0[/COLOR][COLOR=#009900];[/COLOR] n[COLOR=#006666]<[/COLOR]size[COLOR=#009900];[/COLOR] [COLOR=#006666]++[/COLOR]n[COLOR=#006666])
[/COLOR] sinTable[COLOR=#009900][[/COLOR]n[COLOR=#009900]][/COLOR] [COLOR=#339900]=[/COLOR] sin[COLOR=#006666]([/COLOR][COLOR=#660099]2[/COLOR] [COLOR=#006666]*[/COLOR] M_PI [COLOR=#006666]*[/COLOR] n [COLOR=#006666]/[/COLOR] size[COLOR=#006666])[/COLOR][COLOR=#009900];
[/COLOR][COLOR=#CC3333][I] // the table is now initialized[/I][/COLOR]
[COLOR=#009900] }
}
[/COLOR]
Yes, this even works on the Propeller under GCC where my FFT can be spread out over 2 or 4 COGS. Speed gains are not linear with processors of course but I seem to recall 4 COGs gave a speed up of 3 times, not bad.
The magical thing about this is that the same code can be compiled for and run on a single processor machine with no changes whatsoever!
The Parallax Tutorials? Do you mean in Learn? That all seems to validate that GCC works on the Propeller, but it also seems to still be under construction. After two years of this 'under construction', one's attention begins to drift off elsewhere for a more complete solution. IN my case it is K&R's ANSI C, 1988.
I am sorry, but I don't particularly enjoy waiting for the next tutorial to be written. I do realize I am being a bit harsh here. But it is painful to think what is costs Parallax in customers that wander away.
I just noticed a set of links at the bottom of your signature. Maybe I should have been using those instead of Google all along. I suspect that I am getting older, out-dated info from redundant sites that Google points the way to. These all need re-direct instructions as Google won't close them and Google will continue to send people to them.
At some point in the past, I learned that Parallax's Search was not reliable and everyone suggested to use Google Search instead. Where are we now?
The Parallax Tutorials? Do you mean in Learn? That all seems to validate that GCC works on the Propeller, but it also seems to still be under construction. After two years of this 'under construction', ones attention begins to drift off elsewhere for a more complete solution. IN my case it is K&R's ANSI C, 1988.
I am sorry, but I don't particularly enjoy waiting for the next tutorial to be written. I do realize I am being a bit harsh here. But it is painful to thing what is costs Parallax in customers that wander away.
The tutorials are attracting customers. I seriously doubt that your (and others) forum behavior is.
This is pretty revolutionary! How exactly is the algo parceled out among the various cogs?
Oh yeah, it is. I have no idea. I can only barely grasp the concepts of a compiler enough to parse a simple Pascal like language and generate hugely inefficient assempler from it. Never mind auto-parallelize the thing.
Anyway, we can see from the simple example above that OMP is analysing the for loop statement and figuring out that, when the loop iterator is traversing 256 values, 0 to 255, and we have four processors, that can be transformed into four loops over ranges, 0-63, 64-127, 128-191, 192-255 which can all be run in parallel.
There are a bunch more OMP pragmas and clauses to deal with cases where the separate parallel codes need to access shared data structures and so on.
All of this works nicely on the Prop especially if the loops you are parallelizing can be run in COG using FCACHE.
I seem to remember the prop-gcc OMP was a bit buggy, or perhaps showed up bugs in my code that works on every other multi-core machine I run it on. I should try that out again.
Anyway, we can see from the simple example above that OMP is analysing the for loop statement and figuring out that, when the loop iterator is traversing 256 values, 0 to 255, and we have four processors, that can be transformed into four loops over ranges, 0-63, 64-127, 128-191, 192-255 which can all be run in parallel.
Hmmm, interesting. I wonder how it knows that the four groups of iterations can execute independently.
The tutorials are attracting customers. I seriously doubt that your (and others) forum behavior is.
Well, you may be right. Then again, I do spend quite a bit of time helping new users with technical questions on a one-on-one basis about topics other than C and GCC.
But the implication is that I must provide value to Parallax's on-line services or I should go away. That's a bit awkward for me to respond to. I am merely a customer with a customer's viewpoint -- mostly satisfied. But having looked over the 8 Tutorial segments in Learn, the projects cover old ground for me. I don't want to be fooling around with a BOEbot or other such basics. I am trying to learn C in depth.
Retaining customers can be as profitable as attracting new ones.
+++++++++++
Heater's 4 cog Fourier is more interesting than what I said herein.
I am beginning to wonder if I am really too old for C,...
No way. C is easy. Unless you make it hard. Diving in by trying to adapt Arduino code to the Propeller is definitely making a hard start for yourself. Not because of C but because the platforms are so very different.
Forget all that K&R stuff. Nobody programs in K&R C. It's ANSI all the way.
Actually, reading some of the history that has been posted here recently I realize why I had a rough start with C back in the early '80s. All I had was a compiler and the "White Book". Turns out the white book at the time did not accurately describe the C that compilers of the time handled. C was not even standardized yet. What a mess.
...and almost feeling that I am definitely too old for C++.
That is true. No human being will ever live long enough to understand the magnificent but terrifying monstrousness of the entire C++ language and the interactions between all it's parts. Even it's inventor, Bjarne Stroustrup, has lost the thread on that.
Then again, there are millions of Arduino users hacking away on C++ every day...
K&R's 1988 text is the second edition --- ANSI C as of 1989.
I have revised and limited my porting to the GRBL code at this point. It is in C and is GCC for AVR devices, not really Arduino code. And it is generating deeper understanding of what the GCC compiler is doing.
Is it difficult? Well.. yes. But I am not going to learn much by keeping in training wheels. I just find that most of my questions here are met with replies that either go over my head, or direct me to either go to the Learn tutorials or learn GCC on a Linux platform.
It has been a few months of effort now, but it is a rather big reading load when one has to refer to the GCC Manual to try to sort out what compiler errors are trying to say. Spin and PBasic are quite compact in comparison to the formality of C. A short read and then a lot of application of principles. I personally thing that is the charm of learning with the BasicStamp and the Propeller.
Obviously learning GCC is a worthwhile skill for career use. But I am not career oriented. So I would just like to port something that is worthwhile for the Propeller users. GRBL may not be appropriate for the Propeller1, but by the time I get this done there may be a Propeller 2 that it may work nicely with.
Suits me better than watching another blinking LED or rolling a BOEbot across the room.
Arduino users hacking away in C++ is weird. I generally find OOP doctrine one step too far into abstraction. They may be hacking, but are they learning anything? Seems like most of the hard work is hidden from them.
...but it is a rather big reading load when one has to refer to the GCC Manual to try to sort out what compiler errors are trying to say...
Ah, now I see your problem. Don't do that. Manuals and standards documents are not for normal people to read. No, what you do is copy the error message and paste it into Google search. Soon you will find someone who has had this problem before and usually an satisfactory answer. If that fails post the code and error here and hope that ersmith notices
Arduino users hacking away in C++ is weird. I generally find OOP doctrine one step too far into abstraction.
Not really. At the level of OOP that 99% of Arduino code is used at it's pretty much equivalent to writing and using objects in Spin. You get along with Spin just fine I guess.
As for "OOP doctrine" I might agree with you. Many programmers today point out that an inheritance hierarchy is a pretty bad way to organize most programs.
One guy put it something like this: "Using a method in C++ is like taking a banana and then finding you have a gorillas hand holding the banana, and the gorilla, and the entire jungle."
I have revised and limited my porting to the GRBL code at this point. It is in C and is GCC for AVR devices, not really Arduino code. And it is generating deeper understanding of what the GCC compiler is doing.
Loopy, I took a look at the GRBL code, and I wouldn't advise it to someone learning C. It contains many references to AVR I/O registers and has a few interrupt service routines. I think you need to be familiar with C and know both the AVR and the Prop to be able to port this code. It is not a good way to learn how C works. Working on this code is like trying to run before you can walk, or even crawl.
Hi Dave,
I am aware of the problems with interrupts and the AVR i/o. I wouldn't recommend it either. But it is somewhat alluring... like doing Sudoko or Crossword puzzles.
And the issues of AVR i/o and AVR interrupts revive some of the stuff I learned with the SX chips.
================
Besides there are repeated posting from new users that say something like "I have tried an Arduino and learned a bit of C, so now I want to do something on the Propeller in GCC."
Admittedly, that is all a bit naive -- but I might learn something to help out migration from Arduino world to here. GRBL appears to be well-written, reasonably commented, and full-featured CNC. So a valid porting would have value.
Previously, my efforts with Tonkip and Teacup for 3D printing seemed doomed as Tonkip is incomplete, and Teacup is not as well-written or reasonably commented. So I have hopes that GRBL would offer the best solution for porting.
+++++++++++++
Is it too much for me? At times it feels so. I have my bad days and my good days, but am enjoying the struggle. This isn't a do or die issue with me.
just a 2cent statment , I bought 'C Programming Absolute beginners Guide', recommending CODE;BLOCKS IDE. it was fun to work through. Im not so afraid of C anymore !!!!
Comments
The linker "provided" with SimpleIDE is actually the one used by GCC since SimpleIDE acts as a frontend to GCC. While not the most capable linker ever written the linker provided with GCC is actually very good only linking in functions that are actually used and the functions they require.
Of course - but this argument applies to any of the C library function. That doesn't mean you don't include them - especially when they are such a standard part of the language that you can't claim to implement C without them.
Ross.
http://www.embedded.com/design/programming-languages-and-tools/4431133/Go-Forth-?_mc=NL_EMB_EDT_EMB_weekly_20140619&cid=NL_EMB_EDT_EMB_weekly_20140619&elq=f092396de6e9401db95325f04c640309&elqCampaignId=17650
Though I personally doubt it, and during its later heydays I was using Forth a lot, though for the most part my programs never got bigger than a page of text
I'm sorry if I'm starting this thread up again but I found what appears to be the paper in which Dennis Ritche made the comment that is the title of this thread. I was in a paper he wrote about the history of C. It's a very interesting paper to read and not that long. The fascinating part of the paper was where Dennis critiqued the language with (at the time) ~30 of it being out in the wild!
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
Nice read 4x5n, thanks for posting.
C.W.
http://www.i-programmer.info/news/85-humour-/7014-arnold-c-a-schwarzenegger-based-language.html
Stop whining https://www.youtube.com/watch?v=EL8e2ujXe8g and try it yourself http://lhartikk.github.io/ArnoldC/
Wow! ArnoldC even makes Forth look intelligible!
Ross.
Forth is intelligible, and works quite nicely on the Propeller.
Meanwhile GCC has me in a tailspin... multiple files with lots of #include "whatever.h", external and internal variables, possible ANSI C 1999 inclusions, standard libraries and non-standard libraries, and so on. And what is pragma? Where is the pragma?
-Phil
GCC is awash with non-standard pragmas - see here. Also GCC also has another related mechanism you probably need to know about called function attributes.
For a full list of GCC's extensions to the C language, see here.
Ross.
Among GCC's extensions is also 'long long', but that's a 'standard' extension - not what we call a 'GCCism' (nested function calls, on the other hand, is a GCCism). So I have used 'long long' because it's common (although not ANSI, or C89) and it's a 64-bit type on 32- and 64-bit architectures. Then you have 'inline'. It's an extension, but not unique to GCC. I use it in very rare cases (it can easily be made to compile on compilers without them, with a define macro). So yes, I use some of the GCC extensions that are not GCCisms. Among the latter is something that's easy to wish for, if you come from e.g. Turbo Pascal.. case ranges. But that GCCism is designed in an awkward way and in practice it isn't that necessary. So I don't use that one either. I like portability more than any of the features in any case.
-Tor
Pragmata are wonderful things. With a simple pragma I can get my single threaded code to spread itself out over many processors and get some nice speed gains. For example:
[COLOR=#003366][U]#include <math.h>[/U][/COLOR] int main[COLOR=#006666]()[/COLOR] [COLOR=#009900]{ [/COLOR] const int size [COLOR=#339900]=[/COLOR] [COLOR=#660099]256[/COLOR][COLOR=#009900]; [/COLOR] double sinTable[COLOR=#009900][[/COLOR]size[COLOR=#009900]]; [/COLOR] [COLOR=#003366][U]#pragma omp parallel for [/U][/COLOR] for[COLOR=#006666]([/COLOR]int n[COLOR=#339900]=[/COLOR][COLOR=#660099]0[/COLOR][COLOR=#009900];[/COLOR] n[COLOR=#006666]<[/COLOR]size[COLOR=#009900];[/COLOR] [COLOR=#006666]++[/COLOR]n[COLOR=#006666]) [/COLOR] sinTable[COLOR=#009900][[/COLOR]n[COLOR=#009900]][/COLOR] [COLOR=#339900]=[/COLOR] sin[COLOR=#006666]([/COLOR][COLOR=#660099]2[/COLOR] [COLOR=#006666]*[/COLOR] M_PI [COLOR=#006666]*[/COLOR] n [COLOR=#006666]/[/COLOR] size[COLOR=#006666])[/COLOR][COLOR=#009900]; [/COLOR][COLOR=#CC3333][I] // the table is now initialized[/I][/COLOR] [COLOR=#009900] } } [/COLOR]Yes, this even works on the Propeller under GCC where my FFT can be spread out over 2 or 4 COGS. Speed gains are not linear with processors of course but I seem to recall 4 COGs gave a speed up of 3 times, not bad.The magical thing about this is that the same code can be compiled for and run on a single processor machine with no changes whatsoever!
-Tor
-Phil
I will keep trying with the C, but try to ignore C++ for control of the blood pressure. Feeling sorry I ever mentioned pragma.
Have you even tried the Parallax tutorials?
I suspect that you are approaching the whole thing backwards ... that would be the Forthy thing to do of course.
I am sorry, but I don't particularly enjoy waiting for the next tutorial to be written. I do realize I am being a bit harsh here. But it is painful to think what is costs Parallax in customers that wander away.
I just noticed a set of links at the bottom of your signature. Maybe I should have been using those instead of Google all along. I suspect that I am getting older, out-dated info from redundant sites that Google points the way to. These all need re-direct instructions as Google won't close them and Google will continue to send people to them.
At some point in the past, I learned that Parallax's Search was not reliable and everyone suggested to use Google Search instead. Where are we now?
The tutorials are attracting customers. I seriously doubt that your (and others) forum behavior is.
Anyway, we can see from the simple example above that OMP is analysing the for loop statement and figuring out that, when the loop iterator is traversing 256 values, 0 to 255, and we have four processors, that can be transformed into four loops over ranges, 0-63, 64-127, 128-191, 192-255 which can all be run in parallel.
There are a bunch more OMP pragmas and clauses to deal with cases where the separate parallel codes need to access shared data structures and so on.
All of this works nicely on the Prop especially if the loops you are parallelizing can be run in COG using FCACHE.
I seem to remember the prop-gcc OMP was a bit buggy, or perhaps showed up bugs in my code that works on every other multi-core machine I run it on. I should try that out again.
-Phil
Well, you may be right. Then again, I do spend quite a bit of time helping new users with technical questions on a one-on-one basis about topics other than C and GCC.
But the implication is that I must provide value to Parallax's on-line services or I should go away. That's a bit awkward for me to respond to. I am merely a customer with a customer's viewpoint -- mostly satisfied. But having looked over the 8 Tutorial segments in Learn, the projects cover old ground for me. I don't want to be fooling around with a BOEbot or other such basics. I am trying to learn C in depth.
Retaining customers can be as profitable as attracting new ones.
+++++++++++
Heater's 4 cog Fourier is more interesting than what I said herein.
Forget all that K&R stuff. Nobody programs in K&R C. It's ANSI all the way.
Actually, reading some of the history that has been posted here recently I realize why I had a rough start with C back in the early '80s. All I had was a compiler and the "White Book". Turns out the white book at the time did not accurately describe the C that compilers of the time handled. C was not even standardized yet. What a mess. That is true. No human being will ever live long enough to understand the magnificent but terrifying monstrousness of the entire C++ language and the interactions between all it's parts. Even it's inventor, Bjarne Stroustrup, has lost the thread on that.
Then again, there are millions of Arduino users hacking away on C++ every day...
I have revised and limited my porting to the GRBL code at this point. It is in C and is GCC for AVR devices, not really Arduino code. And it is generating deeper understanding of what the GCC compiler is doing.
Is it difficult? Well.. yes. But I am not going to learn much by keeping in training wheels. I just find that most of my questions here are met with replies that either go over my head, or direct me to either go to the Learn tutorials or learn GCC on a Linux platform.
It has been a few months of effort now, but it is a rather big reading load when one has to refer to the GCC Manual to try to sort out what compiler errors are trying to say. Spin and PBasic are quite compact in comparison to the formality of C. A short read and then a lot of application of principles. I personally thing that is the charm of learning with the BasicStamp and the Propeller.
Obviously learning GCC is a worthwhile skill for career use. But I am not career oriented. So I would just like to port something that is worthwhile for the Propeller users. GRBL may not be appropriate for the Propeller1, but by the time I get this done there may be a Propeller 2 that it may work nicely with.
Suits me better than watching another blinking LED or rolling a BOEbot across the room.
Arduino users hacking away in C++ is weird. I generally find OOP doctrine one step too far into abstraction. They may be hacking, but are they learning anything? Seems like most of the hard work is hidden from them.
As for "OOP doctrine" I might agree with you. Many programmers today point out that an inheritance hierarchy is a pretty bad way to organize most programs.
One guy put it something like this: "Using a method in C++ is like taking a banana and then finding you have a gorillas hand holding the banana, and the gorilla, and the entire jungle."
But that is another debate...
I am aware of the problems with interrupts and the AVR i/o. I wouldn't recommend it either. But it is somewhat alluring... like doing Sudoko or Crossword puzzles.
And the issues of AVR i/o and AVR interrupts revive some of the stuff I learned with the SX chips.
================
Besides there are repeated posting from new users that say something like "I have tried an Arduino and learned a bit of C, so now I want to do something on the Propeller in GCC."
Admittedly, that is all a bit naive -- but I might learn something to help out migration from Arduino world to here. GRBL appears to be well-written, reasonably commented, and full-featured CNC. So a valid porting would have value.
Previously, my efforts with Tonkip and Teacup for 3D printing seemed doomed as Tonkip is incomplete, and Teacup is not as well-written or reasonably commented. So I have hopes that GRBL would offer the best solution for porting.
+++++++++++++
Is it too much for me? At times it feels so. I have my bad days and my good days, but am enjoying the struggle. This isn't a do or die issue with me.