Sapieha said...
Most of C programs are memory hungry, badly structured, Not speed efective.
Most of them are endles loops.
Regards, Christoffer J
Hi Christoffer, I'm not sure how to interpret your comments. They are either sarcastic/silly in intent, or simply ignorant. I don't intend the previous statement as a personal affront.
Technology Review said...
Why is most software so bad?
Bjarne Stroustrup: Some software is actually pretty good by any standards. Think of the Mars Rovers, Google, and the Human Genome Project. That's quality software! Fifteen years ago, most people, and especially most experts, would have said each of those examples was impossible. Our technological civilization depends on software, so if software had been as bad as its worst reputation, most of us would have been dead by now.
@Dave Hein - I know it's an effort, but read Chip's comments. There's a 16 x 16 hardware multiplier that produces its result in one cycle. To do signed arithmetic or a 32 x 32 multiply, you'd have to use multiple instructions. Division would still be software.
heater said...
greitz:
What I meant about the "billions of lines of code not fitting" is that currently all the C compilers we have available for the Prop produce excessively large code (Note 1) . This a result of having to generate 32 bit PASM instructions for their kernels to execute. So size wise C is not a good fit.
My, purchased, ICC-C compiler produces very efficient prop asm code. I've checked it myself and it's usually beats my handwritten asm code every time.
heater said...
...A world away from pthreads or std::thread or whatever.
This is completely untrue. The VxWorks (RTOS) has been shipping with a C/C++ compiler that has supported standard pthreads for over ten years on multiple hardware platforms.
I can verify first hand that there are tons of realtime applications, even faster than 50 ns determinism, running on critical medical devices, military applications, and space applications that are highly multithreaded, use pthreads, or boost::threads (same as C++0x10 std::thread) on what many engineers would incorrectly claim as not doable.
heater said...
Yes there are C/C++ applications that run on ridiculously small amounts of memory in the PIC. But still I think targeting a C compiler at the 496 instruction space we have in the COG is a complete waste of time. By the time C has worked out how to build a stack, do indexed addressing, do byte and word variable access etc it will have used most of the space. Seems others agree. No one has stepped up to target a C compiler at PASM. C is not a good fit. (Note 2)
This perspective may change drastically in the prop2 with more I/O, more memory, and efficient signaling/message passing between cogs than the prop1.
Kindly,
graham
p.s. I love it when these threads get rolling. good stuff.
greitz: I haven't such a good laugh all day, thank you. It's in the second paragraph of the first link in your post:
"C++ remains the archetypal "high level" computer language (that is, one that preserves the features of natural, human language),"
What? natural? human? !!!
Bjarne makes another joke a bit further down:
"Personally, I prefer to know when a system will work, and why it will."
Well maybe it's me but the if you are working on some app in C++ and using a tool kit like Qt the whole thing is so huge and complicated that it has to be an act of faith that it works. Never mind that it sits on top of a huge and complicated operating system.
Even if your tool kit is bug free the thing is so massive that no one has the time comprehend all of it and it's myriad of interactions.
More seriously, for hard real-time applications until such time that the C/C++ compiler can print out a report at the end of compilation telling me exactly when and for how long a particular section of code will run we are far away from knowing when a system will work.
I already had this problem years ago in ADA for an avionics application when none of the software engineers could tell me the maximum execution time of one iteration of the control function (too many conditions and loops to analyse) and testing showed we had already used 90% of the time budget.
Still, Zog will bring C++ to the Prop. (Blows own horn again[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You said "They are either sarcastic/silly in intent, or simply ignorant"
Sarcastic = NO
Silly = Maybe
Simplicity is always needed In Program/Hardware constructions.
BUT I'm mostly iritated ON all discutions " That C is better as others programings languages. "
NO mather at Industry use it - BUT industry not always will have new ideas. If we NOT start work with that ideas THEM never will adopt them.
As I said some time ago on FORUM - C is very old DINOSAURUS --- In my opinion badly at not already gone.
For me this discution are same as on other thread that discusing EXTRA internal Ports.
Why have them. And MY question WHY NOT?
And if all people will think in same way - No new products at ALL will comme on market.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
"My, purchased, ICC-C compiler produces very efficient prop asm code"
No it does not. It produces PASM code to be placed in HUB that has to be run via an LMM kernel running in a COG with a resulting loss of performance (factor of 4 maybe).
I'm familiar with VxWorks. WindRiver used to charge us a fortune for supplying an ancient version of GCC that would not compile half the C++ we threw at it. They never did get their OSPF working properly. We had to ditch all that and get Linux up on those systems in short order. Luckily our real time constraints were not so strict.
What I was getting at with pthreads etc is that running 8 threads under pthreads on an ARM or whatever is never going to do what a Prop can do on 8 COGS. Unless of course the single CPU is much faster.
Yes perspectives will change with Prop II. But if it still only has room for 496 instructions in COG then targeting C at those is pointless. However as the whole thing is faster and HUB memory is bigger the current C solutions look more attractive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
With 1 clock COG instruction and much more memory PropII will be more suitable to "C" and other that types of programing languages.
Not mention as Chip advised posibilitys to suport LMM in COG's instructions.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
heater said...
greitz: I haven't such a good laugh all day, thank you. It's in the second paragraph of the first link in your post:
More seriously, for hard real-time applications until such time that the C/C++ compiler can print out a report at the end of compilation telling me exactly when and for how long a particular section of code will run we are far away from knowing when a system will work.
You must have been out of the RTOS loop for quite some time.
One example that does exactly this are the Windriver Windview and Code Coverage tools. I have been using them on nearly a weekly basis for the last eight years. Also, the improvements during this time frame have been dramatic.
heater said...
I already had this problem years ago in ADA for an avionics application when none of the software engineers could tell me the maximum execution time of one iteration of the control function (too many conditions and loops to analyse) and testing showed we had already used 90% of the time budget.
How long ago was this? If it was over ten years than ok, I can believe that. Any less than ten and I hope that those plains aren't in operation. Trace and code coverage tools are part of any polished RT-embedded engineering department these days.
Sapieha said...
Hi greitz
BUT I'm mostly iritated ON all discutions " That C is better as others programings languages. "
NO mather at Industry use it - BUT industry not always will have new ideas. If we NOT start work with that ideas THEM never will adopt them.
As I said some time ago on FORUM - C is very old DINOSAURUS --- In my opinion badly at not already gone.
Regards, Christoffer J
The intent is to request that, even minimal, industry-standard language support be provided for the prop2, and not that C/C++ are the end-all-be-all languages.
I think you are reacting too sensitively and seeing a religious argument where none exists.
I'm not reacting sensitively Not religious to
BUT many of Yours that talk that much on "C" have it as religion maybe and will not change it.
For me --- I always use what I have --- Totaly Ateist
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
heater said...
greitz: Great conversation going here.
"My, purchased, ICC-C compiler produces very efficient prop asm code"
No it does not. It produces PASM code to be placed in HUB that has to be run via an LMM kernel running in a COG with a resulting loss of performance (factor of 4 maybe).
Yes, excellent conversation. I get concerned that these discussions can be viewed negatively. If you could hear the inflections in my voice and see my body language you would find me quite amiable in nature.
Ok, I still contend that the ICC-C compiler produces efficient code, with consideration that it must be fetched from the HUB. Do you have example C code I can test where the compiled asm code is poorly done? I can be swayed.
heater said...
I'm familiar with VxWorks. WindRiver used to charge us a fortune for supplying an ancient version of GCC that would not compile half the C++ we threw at it. They never did get their OSPF working properly. We had to ditch all that and get Linux up on those systems in short order. Luckily our real time constraints were not so strict.
Yes, very expensive. Our major complaint is not the compiler that ships with VxWorks 6.4, but with the Eclipse ide. It sucks. We can compile the entire boost libraries and use the headers as is with limited code adjustments.
We have also begun migrating to Linux, but for different reasons.
Mike Green said...
@Dave Hein - I know it's an effort, but read Chip's comments. There's a 16 x 16 hardware multiplier that produces its result in one cycle. To do signed arithmetic or a 32 x 32 multiply, you'd have to use multiple instructions. Division would still be software.
Mike,
Thanks for the response.· I'm sure the spec for the Prop 2 is located in the forum somewhere, but I didn't want to wade through all the post, and the search feature isn't very efficient.· A single-cycle 16-bit multiplier will be great!· The Prop 2 should be very useful for DSP applications.· A hardware divider is not as important, but one of the posts mentioned one.· Thanks for clearing that up.
[noparse][[/noparse]Edit]
A modest attempt at a code protection technique wouldn't hurt.
[noparse][[/noparse]/Edit]
That comment makes my skin crawl.
Just look at the security theatre being carried out in airports around the world (TSA I'm looking at you) to see how badly implemented security makes the general public feel warm and fuzzy, yet allows the bad guys to continue to do what they do un-impeded.
Those who don't understand security are doomed to re-invent it, poorly.
You don't "attempt" security. You either do it in a proven and peer reviewed fashion with specific targets, or you don't do it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
[noparse][[/noparse]Edit]
A modest attempt at a code protection technique wouldn't hurt.
[noparse][[/noparse]/Edit]
That comment makes my skin crawl.
Just look at the security theatre being carried out in airports around the world (TSA I'm looking at you) to see how badly implemented security makes the general public feel warm and fuzzy, yet allows the bad guys to continue to do what they do un-impeded.
Those who don't understand security are doomed to re-invent it, poorly.
You don't "attempt" security. You either do it in a proven and peer reviewed fashion with specific targets, or you don't do it.
And that's going to happen with the prop2 architecture? I don't see Chip asking the community to perform a peer review of their code protection technique. Much less do it all.
And that's going to happen with the prop2 architecture? I don't see Chip asking the community to perform a peer review of their code protection technique. Much less do it all.
If you read the long and comprehensive threads on the Prop2 features it would appear that the extent of the security facilities involves a single OTP 32 bit register. You can implement your own code security on top of that. If you have your program stored externally it's pretty difficult to make it secure anyway. If you can't effectively secure it then making feeble attempts is simply a waste of resources destined to leave everyone disappointed.
The prop has some quite unique features. If it's not the right fit for your project, use something that is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I'm not reacting sensitively Not religious to
BUT many of Yours that talk that much on "C" have it as religion maybe and will not change it.
For me --- I always use what I have --- Totaly Ateist
Sapieha,
I think you meant agnostic, unless you don't believe in using any programming language at all.· There was a time that I could toggle the boot program into a DEC mini-computer, but it's not an efficient way to code.
As far as Spin versus C, I didn't understand the reason for inventing a new language.· After spending a few months working with Spin I realized that some parts of Spin translates directly into assembly instructions.· Also, after I looked at the source for the interpreter I realized how Spin was designed so the interpreter could fit in a cog.· I'm now at a point where I can easily switch back and forth between Spin and C.
With that being said, I still prefer programming in C.· It has many useful features that Spin lacks, such as structs and function pointers.· C also has features that help with large projects, such as include file, type checking, module independence, linkable objects, etc.
Dave
Post Edited (Dave Hein) : 2/21/2010 11:43:38 PM GMT
And that's going to happen with the prop2 architecture? I don't see Chip asking the community to perform a peer review of their code protection technique. Much less do it all.
If you read the long and comprehensive threads on the Prop2 features it would appear that the extent of the security facilities involves a single OTP 32 bit register. You can implement your own code security on top of that. If you have your program stored externally it's pretty difficult to make it secure anyway. If you can't effectively secure it then making feeble attempts is simply a waste of resources destined to leave everyone disappointed.
The prop has some quite unique features. If it's not the right fit for your project, use something that is.
Brad, I think you are confusing me with the original poster. I am not particularly interested in code security as a make-or-break feature. Although, a modest attempt such as the one proposed is reasonable and not a waste of resources.
Code security strategies are more akin to having 'The Club' on your steering wheel or an alarm system. It provides some deterrence but if someone really wants your car they will get it. In that respect, we perceive the utility (or not) of them differently.
I don't know how code security works in most processors, but it seems like it could be implemented with AES encryption.· A 128-bit, or larger key could be burned into an internal location in the chip.· Only the programmer would know the key.· It would take a lot of effort and time for someone else to crack the code.· Of course, the biggest problem would be implementing the decryption hardware so addtional instruction pipelines would not be needed.
You said "I think you meant agnostic, unless you don't believe in using any programming language at all."
I Said "I always use what I have"
Not Look at if it not have "C" I can't use it. And that are NOT "agnostic"
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha said...
Not Look at if it not have "C" I can't use it. And that are NOT "agnostic"
Where are you drawing this perspective from?
I go back and forth between spin, C, and pasm often. That there is a preference for C (or C++) is no different than enjoying a good beer over a good wine.
The gist is that the prop2 is likely to become more ubiquitous if it has better support for standard languages like C/C++. That would be a really positive outcome!
It demonstrates a desire to see it's unique architecture mature into new venues. Why horde it all to ourselves?
I use Spin/PASM on Propeller because I like it, and Spin/PASM was designed with Propeller's limits in mind (limits that often make me crazy usually right at 90% of project completion i.e. out of memory ... my fault for over-specifying I guess). Propeller v2 may be a better C host, but I doubt the rest of the C world will embrace Propeller v2. Other platforms have different limits, but they are more compatible with what is available with C. So we can either sit back and enjoy the leisurely ride or abandon ship at Macaw or other ports of call for faster action.
The opinions on this forum are too diverse to attain a consensus on C (or practically anything else for that matter). In that sense alone, C is not a good fit for Propeller if one visits this place too often. Heater's argument that LMM C is too big is correct, but the small alternative does not find general appeal either (to me anyway and well over half of participants in this forum). GNU C through some emulation is much more attractive, but from what I've seen so far, the utility of that will also be limited - perhaps (and I honestly hope) I'll be proven wrong. I guess it is a sign of growth and some maturity at least that there are alternative Propeller C methodologies [noparse]:)[/noparse]
Parallax is a BASIC and Delphi company (and Spin is a very close relative of Pascal if you haven't noticed). Only some contributors on this forum care about C. The very small knowledgeable C minority *here* will never make converts of the rest. I'm also fond of C and have been for a very long time, but to me there are much better platform alternatives for C ... which are usually microprocessors. Take and enjoy what's available or leave it for the rest to wander through.
Cheers.
PS: Please consider that Sapieha has to use a translation of these posts ....
Keep in mind that Parallax has very limited software development resources. It has created the Propeller Tool (and the Stamp Editor). Parallax provides updates for these tools, but not much in the way of fundamental changes. Everything else is provided by the user community or by 3rd party vendors. There will not be fundamental changes (like to C or C++) in the process of developing the Prop 2. Parallax simply does not have the resources and, as jazzed has suggested, no one has made a strong enough case for making the large investment in substantial new resources, particularly when there are forum members willing to do things like Catalina and 3rd parties like ImageCraft are willing to leverage existing C systems to support the Propeller despite poor sales volume.
That's the really telling thing ... ImageCraft's C compiler is very well done, quite efficient as these things go, and inexpensive. Despite that, it's not been heavily used. One would think that if C were that important to the success of the Propeller, you would see higher use of ImageCraft's compiler and clamoring among forum members and commercial users of the Propeller for better support by Parallax. Even with Catalina available for free, there's hardly a mention of it. People are more interested in its use with external memory for dealing with large programs, not for development of native or even main (hub) memory based programs.
You said "I think you meant agnostic, unless you don't believe in using any programming language at all."
I Said "I always use what I have"
Not Look at if it not have "C" I can't use it. And that are NOT "agnostic"
Regards
Sapieha,
I think we are in agreement.· There is a large library of Spin code in the object exchange, and Parallax provides a very nice development environment for programming the Propeller in Spin.· I like the Propeller chip, so I learned to program in Spin.
Dave
There are a few points raised on this thread... Here are my observations and gut thoughts (they could be wrong)...
C compilers
Not having C is perceived to be a major limitation amongst professionals. They do not want to learn a new language and they usually have a library of routines that they regularly use. They do not understand that the prop, in many respects, requires a different approach to coding it due to the multiple cogs. They do not realise that spin is simple, and although not fast compared to pasm, without interrupts most of their code does not require this. Some pasm code is likely for the fast drivers.
Spin
Spin is seen by professionals as another language to learn. They incorrectly presume it is difficult, just like C is to learn. Some may argue that C is not·difficult, but it is compared to Basic, Spin or Pascal. Spin is easy to spawn routines into other cogs (cognew).
It is seen to be slow. Well it is compared to compiled programs. But it is very small. I don't see many clamoring for the faster version of spin that I did (about 25% faster). I don't see many overclocking (25% faster for 100MHz and with the quiet semi-parallax approval). I am using 104MHz (30%) and expect to graduate to 108MHz (35%) shortly. Remember Sapeiha runs 120MHz on my TriBlade (50%).
My spin interpreter (25%) and 100MHz clock will deliver about 56% improvement, 104MHz 62%, 108MHz 69%, 120MHz 87%. I would not promote > 104MHz commercially yet.
The main current RAM and speed issues are mainly from our retro area although operating systems such as SphinxOS and Bill's Largos, etc are pushing into these limitations as well. But these are mainly hobby areas at present.
PASM
Learning another assembler is seen as yet another impediment. Another complex set of instructions to learn. However, most do not realise the simplicity of PASM on the prop. It is easy and efficient and with only a few RISC base instructions. Most instructions run at 20MHz (80MHz/4).
Memory
Many see the prop as only having small memory, but in fact it has 32KB custom programmed ROM, 32KB + 8 * 2KB = 48KB SRAM, and external flash 32KB-128KB standard. What other·chip for < $8 matches this??? Some have > 32KB Flash plus up to 8KB SRAM. This is NOT 48KB SRAM.
Just my thoughts
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso: "Not having C is perceived to be a major limitation amongst professionals"
Yes. and I'll say it again, this is to do with portability, multiple sourcing of MCUs or MCU architectures, protection of one investment in a software development, ease of migration, the confidence in always being able to find a part to run your code, how else do I day it?
It's nothing to do with language merits, the supposed superiority of C, the perceived difficulty of learning Spin/PASM, the lazyness of C developer or any of that language war nonsense.
I believe it's more to do with Parallax as a small company, the Prop as a unique architecture, the confidence potential customers will have in the longevity of that combination. They don't want to risk developing for the Prop in SPIN/PASM, trusting that it does not get discontinued or God forbid Parallax disappears. In which case they have to develop whatever products they created on the Prop all over again.
With "normal" C apps customers don't need that much faith in their MCU supplier, there are any more to choose from.
Personally I'm confident Parallax and the Prop are here for the long haul. This is based on their long track record and Chips vision and apparently doggedly persistent personality[noparse]:)[/noparse]
If I did not have that confidence I would not have been spending so many ours of my life tinkering with the Prop.
How to instil that confidence in large commercial customers is another question.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Jazzed "and Spin is a very close relative of Pascal if you haven't noticed"
No I haven't.
Stepping back and looking at it from a distance it looks like 99% of other block structured languages. These languages have a linage that goes back to ALGOL. They include, C, PASCAL, PL/M, ADA, MODULA, etc etc etc.
So in that respect Spin is a close relative of C.
Spin may look a bit like PASCAL, it for sure does not have the semantics of Pascal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I didn't want to risk diverting this already sidetracked post any further - but I agree 110%. Everything we do to bring mainstream software to the Prop can only enhance things for everybody - hobbyists or professional alike.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
greitz: This somewhat off topic but related to timing determinism etc.
You said "You must have been out of the RTOS loop for quite some time."
Perhaps, but always nearby.
Now I was talking about Bjarne and his statements about knowing if/when code works and C/C++ timing determinism.
Thing is those tools you linked to don't help. The first is basically the well know gcov and the second is the lesser used Linux trace tool kit. Neither of those do what I asked which is for the compiler to "... print out a report at the end of compilation telling me exactly when and for how long a particular section of code will run..."
Those tools are excellent and very useful in code testing/performance analysis but they actually don't answer that question.
The problem is summed up by this statement in your first linked article:
"...a test must be run for an extended amount of time to accurately evaluate the resource utilization..."
You see the problem. You have to run the code to see what happens. The tools tell you what it does "after the event".
They only tell you what happens in those test cases for which you have run the code. They cannot tell you an upper bound on execution time in the general case. And they cannot tell you it from the source you have written, only from the test results you obtain. They cannot even warn you of code constructs that are potential problems timing wise but hard to analyse.
This does not even full fill Bjarne's need to "know when a system will work, and why it will". It's just an automated way of running code and seeing what happens while hoping for the best.
Actually that avionics case I mentioned was about 1996. The tools you presented would not have helped much. Besides we had similar tools in ADA test and such at the time.
Now the reason that case upset me was the company in question had previously built up a very high reputation for high reliability avionics software using their own in house language. That language exactly did what I say. Compile a module and, lo, it emits a report telling exactly how long the worst case execution time is for that module. Build a whole system of modules and, wow, there is a report telling exactly when everything gets run and how much time each part takes. As development progresses you know exactly where you are with your timing budget all the time.
Code test coverage and all that was built into the language, simulator, runtime system.
Then they decided to do a project in ADA. All of a sudden we are in dark re: timing. Not one of the software engineers on that project could make any definitives statements about the execution timing of that code. And not for the lack of coverage/testing tools.
Now the closest I have seen to a solution to this problem in recent times comes from XMOS. They have timing analysis tools for C, C++ and their own XC language that will tell you what timing you have without actually having to run the code and find out. Of course it breaks down with complex loopy code as expected. But at least you are alerted to potential problems and can adapt your programming style accordingly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
You'll find tons of information from here:
www.technologyreview.com/infotech/17831/?a=f
here:
www2.research.att.com/~bs/bs_faq.html
and here:
unthought.net/c++/c_vs_c++.html
That refute your assertion on multiple grounds.
Kindly,
graham
http://forums.parallax.com/showthread.php?p=710900
Regards,
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
'Those who can, do.Those who can’t, teach.'
'Convince a man against his will, he's of the same opinion still.'
·
This is completely untrue. The VxWorks (RTOS) has been shipping with a C/C++ compiler that has supported standard pthreads for over ten years on multiple hardware platforms.
I can verify first hand that there are tons of realtime applications, even faster than 50 ns determinism, running on critical medical devices, military applications, and space applications that are highly multithreaded, use pthreads, or boost::threads (same as C++0x10 std::thread) on what many engineers would incorrectly claim as not doable.
This perspective may change drastically in the prop2 with more I/O, more memory, and efficient signaling/message passing between cogs than the prop1.
Kindly,
graham
p.s. I love it when these threads get rolling. good stuff.
"C++ remains the archetypal "high level" computer language (that is, one that preserves the features of natural, human language),"
What? natural? human? !!!
Bjarne makes another joke a bit further down:
"Personally, I prefer to know when a system will work, and why it will."
Well maybe it's me but the if you are working on some app in C++ and using a tool kit like Qt the whole thing is so huge and complicated that it has to be an act of faith that it works. Never mind that it sits on top of a huge and complicated operating system.
Even if your tool kit is bug free the thing is so massive that no one has the time comprehend all of it and it's myriad of interactions.
More seriously, for hard real-time applications until such time that the C/C++ compiler can print out a report at the end of compilation telling me exactly when and for how long a particular section of code will run we are far away from knowing when a system will work.
I already had this problem years ago in ADA for an avionics application when none of the software engineers could tell me the maximum execution time of one iteration of the control function (too many conditions and loops to analyse) and testing showed we had already used 90% of the time budget.
Still, Zog will bring C++ to the Prop. (Blows own horn again[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You said "They are either sarcastic/silly in intent, or simply ignorant"
Sarcastic = NO
Silly = Maybe
Simplicity is always needed In Program/Hardware constructions.
BUT I'm mostly iritated ON all discutions " That C is better as others programings languages. "
NO mather at Industry use it - BUT industry not always will have new ideas. If we NOT start work with that ideas THEM never will adopt them.
As I said some time ago on FORUM - C is very old DINOSAURUS --- In my opinion badly at not already gone.
For me this discution are same as on other thread that discusing EXTRA internal Ports.
Why have them. And MY question WHY NOT?
And if all people will think in same way - No new products at ALL will comme on market.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
"My, purchased, ICC-C compiler produces very efficient prop asm code"
No it does not. It produces PASM code to be placed in HUB that has to be run via an LMM kernel running in a COG with a resulting loss of performance (factor of 4 maybe).
I'm familiar with VxWorks. WindRiver used to charge us a fortune for supplying an ancient version of GCC that would not compile half the C++ we threw at it. They never did get their OSPF working properly. We had to ditch all that and get Linux up on those systems in short order. Luckily our real time constraints were not so strict.
What I was getting at with pthreads etc is that running 8 threads under pthreads on an ARM or whatever is never going to do what a Prop can do on 8 COGS. Unless of course the single CPU is much faster.
Yes perspectives will change with Prop II. But if it still only has room for 496 instructions in COG then targeting C at those is pointless. However as the whole thing is faster and HUB memory is bigger the current C solutions look more attractive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You are right on PropII.
With 1 clock COG instruction and much more memory PropII will be more suitable to "C" and other that types of programing languages.
Not mention as Chip advised posibilitys to suport LMM in COG's instructions.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
One example that does exactly this are the Windriver Windview and Code Coverage tools. I have been using them on nearly a weekly basis for the last eight years. Also, the improvements during this time frame have been dramatic.
Here some info on their use for Linux:
www.ibm.com/developerworks/linux/library/l-stress/index.html
www.linuxjournal.com/article/3829
How long ago was this? If it was over ten years than ok, I can believe that. Any less than ten and I hope that those plains aren't in operation. Trace and code coverage tools are part of any polished RT-embedded engineering department these days.
graham
I think you are reacting too sensitively and seeing a religious argument where none exists.
Kindly,
graham
I'm not reacting sensitively Not religious to
BUT many of Yours that talk that much on "C" have it as religion maybe and will not change it.
For me --- I always use what I have --- Totaly Ateist
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Ok, I still contend that the ICC-C compiler produces efficient code, with consideration that it must be fetched from the HUB. Do you have example C code I can test where the compiled asm code is poorly done? I can be swayed.
Yes, very expensive. Our major complaint is not the compiler that ships with VxWorks 6.4, but with the Eclipse ide. It sucks. We can compile the entire boost libraries and use the headers as is with limited code adjustments.
We have also begun migrating to Linux, but for different reasons.
Kindly,
graham
Thanks for the response.· I'm sure the spec for the Prop 2 is located in the forum somewhere, but I didn't want to wade through all the post, and the search feature isn't very efficient.· A single-cycle 16-bit multiplier will be great!· The Prop 2 should be very useful for DSP applications.· A hardware divider is not as important, but one of the posts mentioned one.· Thanks for clearing that up.
Dave
That comment makes my skin crawl.
Just look at the security theatre being carried out in airports around the world (TSA I'm looking at you) to see how badly implemented security makes the general public feel warm and fuzzy, yet allows the bad guys to continue to do what they do un-impeded.
Those who don't understand security are doomed to re-invent it, poorly.
You don't "attempt" security. You either do it in a proven and peer reviewed fashion with specific targets, or you don't do it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
In general, I agree completely.
Kindly,
graham
If you read the long and comprehensive threads on the Prop2 features it would appear that the extent of the security facilities involves a single OTP 32 bit register. You can implement your own code security on top of that. If you have your program stored externally it's pretty difficult to make it secure anyway. If you can't effectively secure it then making feeble attempts is simply a waste of resources destined to leave everyone disappointed.
The prop has some quite unique features. If it's not the right fit for your project, use something that is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I think you meant agnostic, unless you don't believe in using any programming language at all.· There was a time that I could toggle the boot program into a DEC mini-computer, but it's not an efficient way to code.
As far as Spin versus C, I didn't understand the reason for inventing a new language.· After spending a few months working with Spin I realized that some parts of Spin translates directly into assembly instructions.· Also, after I looked at the source for the interpreter I realized how Spin was designed so the interpreter could fit in a cog.· I'm now at a point where I can easily switch back and forth between Spin and C.
With that being said, I still prefer programming in C.· It has many useful features that Spin lacks, such as structs and function pointers.· C also has features that help with large projects, such as include file, type checking, module independence, linkable objects, etc.
Dave
Post Edited (Dave Hein) : 2/21/2010 11:43:38 PM GMT
Code security strategies are more akin to having 'The Club' on your steering wheel or an alarm system. It provides some deterrence but if someone really wants your car they will get it. In that respect, we perceive the utility (or not) of them differently.
Kindly,
graham
Post Edited (greitz) : 2/22/2010 12:02:09 AM GMT
Dave
lmgtfy.com/?q=Potting+compound+ [noparse];)[/noparse] [noparse];)[/noparse]
I was just joking that you embed the device in resin to protect the code.
Graham
You said "I think you meant agnostic, unless you don't believe in using any programming language at all."
I Said "I always use what I have"
Not Look at if it not have "C" I can't use it. And that are NOT "agnostic"
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
I go back and forth between spin, C, and pasm often. That there is a preference for C (or C++) is no different than enjoying a good beer over a good wine.
The gist is that the prop2 is likely to become more ubiquitous if it has better support for standard languages like C/C++. That would be a really positive outcome!
It demonstrates a desire to see it's unique architecture mature into new venues. Why horde it all to ourselves?
Kindly,
graham
The opinions on this forum are too diverse to attain a consensus on C (or practically anything else for that matter). In that sense alone, C is not a good fit for Propeller if one visits this place too often. Heater's argument that LMM C is too big is correct, but the small alternative does not find general appeal either (to me anyway and well over half of participants in this forum). GNU C through some emulation is much more attractive, but from what I've seen so far, the utility of that will also be limited - perhaps (and I honestly hope) I'll be proven wrong. I guess it is a sign of growth and some maturity at least that there are alternative Propeller C methodologies [noparse]:)[/noparse]
Parallax is a BASIC and Delphi company (and Spin is a very close relative of Pascal if you haven't noticed). Only some contributors on this forum care about C. The very small knowledgeable C minority *here* will never make converts of the rest. I'm also fond of C and have been for a very long time, but to me there are much better platform alternatives for C ... which are usually microprocessors. Take and enjoy what's available or leave it for the rest to wander through.
Cheers.
PS: Please consider that Sapieha has to use a translation of these posts ....
That's the really telling thing ... ImageCraft's C compiler is very well done, quite efficient as these things go, and inexpensive. Despite that, it's not been heavily used. One would think that if C were that important to the success of the Propeller, you would see higher use of ImageCraft's compiler and clamoring among forum members and commercial users of the Propeller for better support by Parallax. Even with Catalina available for free, there's hardly a mention of it. People are more interested in its use with external memory for dealing with large programs, not for development of native or even main (hub) memory based programs.
I think we are in agreement.· There is a large library of Spin code in the object exchange, and Parallax provides a very nice development environment for programming the Propeller in Spin.· I like the Propeller chip, so I learned to program in Spin.
Dave
C compilers
Not having C is perceived to be a major limitation amongst professionals. They do not want to learn a new language and they usually have a library of routines that they regularly use. They do not understand that the prop, in many respects, requires a different approach to coding it due to the multiple cogs. They do not realise that spin is simple, and although not fast compared to pasm, without interrupts most of their code does not require this. Some pasm code is likely for the fast drivers.
Spin
Spin is seen by professionals as another language to learn. They incorrectly presume it is difficult, just like C is to learn. Some may argue that C is not·difficult, but it is compared to Basic, Spin or Pascal. Spin is easy to spawn routines into other cogs (cognew).
It is seen to be slow. Well it is compared to compiled programs. But it is very small. I don't see many clamoring for the faster version of spin that I did (about 25% faster). I don't see many overclocking (25% faster for 100MHz and with the quiet semi-parallax approval). I am using 104MHz (30%) and expect to graduate to 108MHz (35%) shortly. Remember Sapeiha runs 120MHz on my TriBlade (50%).
My spin interpreter (25%) and 100MHz clock will deliver about 56% improvement, 104MHz 62%, 108MHz 69%, 120MHz 87%. I would not promote > 104MHz commercially yet.
The main current RAM and speed issues are mainly from our retro area although operating systems such as SphinxOS and Bill's Largos, etc are pushing into these limitations as well. But these are mainly hobby areas at present.
PASM
Learning another assembler is seen as yet another impediment. Another complex set of instructions to learn. However, most do not realise the simplicity of PASM on the prop. It is easy and efficient and with only a few RISC base instructions. Most instructions run at 20MHz (80MHz/4).
Memory
Many see the prop as only having small memory, but in fact it has 32KB custom programmed ROM, 32KB + 8 * 2KB = 48KB SRAM, and external flash 32KB-128KB standard. What other·chip for < $8 matches this??? Some have > 32KB Flash plus up to 8KB SRAM. This is NOT 48KB SRAM.
Just my thoughts
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Yes. and I'll say it again, this is to do with portability, multiple sourcing of MCUs or MCU architectures, protection of one investment in a software development, ease of migration, the confidence in always being able to find a part to run your code, how else do I day it?
It's nothing to do with language merits, the supposed superiority of C, the perceived difficulty of learning Spin/PASM, the lazyness of C developer or any of that language war nonsense.
I believe it's more to do with Parallax as a small company, the Prop as a unique architecture, the confidence potential customers will have in the longevity of that combination. They don't want to risk developing for the Prop in SPIN/PASM, trusting that it does not get discontinued or God forbid Parallax disappears. In which case they have to develop whatever products they created on the Prop all over again.
With "normal" C apps customers don't need that much faith in their MCU supplier, there are any more to choose from.
Personally I'm confident Parallax and the Prop are here for the long haul. This is based on their long track record and Chips vision and apparently doggedly persistent personality[noparse]:)[/noparse]
If I did not have that confidence I would not have been spending so many ours of my life tinkering with the Prop.
How to instil that confidence in large commercial customers is another question.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
No I haven't.
Stepping back and looking at it from a distance it looks like 99% of other block structured languages. These languages have a linage that goes back to ALGOL. They include, C, PASCAL, PL/M, ADA, MODULA, etc etc etc.
So in that respect Spin is a close relative of C.
Spin may look a bit like PASCAL, it for sure does not have the semantics of Pascal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I didn't want to risk diverting this already sidetracked post any further - but I agree 110%. Everything we do to bring mainstream software to the Prop can only enhance things for everybody - hobbyists or professional alike.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
You said "You must have been out of the RTOS loop for quite some time."
Perhaps, but always nearby.
Now I was talking about Bjarne and his statements about knowing if/when code works and C/C++ timing determinism.
Thing is those tools you linked to don't help. The first is basically the well know gcov and the second is the lesser used Linux trace tool kit. Neither of those do what I asked which is for the compiler to "... print out a report at the end of compilation telling me exactly when and for how long a particular section of code will run..."
Those tools are excellent and very useful in code testing/performance analysis but they actually don't answer that question.
The problem is summed up by this statement in your first linked article:
"...a test must be run for an extended amount of time to accurately evaluate the resource utilization..."
You see the problem. You have to run the code to see what happens. The tools tell you what it does "after the event".
They only tell you what happens in those test cases for which you have run the code. They cannot tell you an upper bound on execution time in the general case. And they cannot tell you it from the source you have written, only from the test results you obtain. They cannot even warn you of code constructs that are potential problems timing wise but hard to analyse.
This does not even full fill Bjarne's need to "know when a system will work, and why it will". It's just an automated way of running code and seeing what happens while hoping for the best.
Actually that avionics case I mentioned was about 1996. The tools you presented would not have helped much. Besides we had similar tools in ADA test and such at the time.
Now the reason that case upset me was the company in question had previously built up a very high reputation for high reliability avionics software using their own in house language. That language exactly did what I say. Compile a module and, lo, it emits a report telling exactly how long the worst case execution time is for that module. Build a whole system of modules and, wow, there is a report telling exactly when everything gets run and how much time each part takes. As development progresses you know exactly where you are with your timing budget all the time.
Code test coverage and all that was built into the language, simulator, runtime system.
Then they decided to do a project in ADA. All of a sudden we are in dark re: timing. Not one of the software engineers on that project could make any definitives statements about the execution timing of that code. And not for the lack of coverage/testing tools.
Now the closest I have seen to a solution to this problem in recent times comes from XMOS. They have timing analysis tools for C, C++ and their own XC language that will tell you what timing you have without actually having to run the code and find out. Of course it breaks down with complex loopy code as expected. But at least you are alerted to potential problems and can adapt your programming style accordingly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 2/22/2010 8:05:41 AM GMT