C with FCACHE support
ImageCraft
Posts: 348
ICC for Propeller V7.02 beta0 is available: http://www.imagecraft.com/pub/iccv7prop_v702_beta0.exe
CHANGE LOGS:
V7.02 August 22nd 2008
IDE and Compiler
- Added support for FCACHE, caching of small code chunks in COG RAM
for fast execution. This is done automatically for loops that fit
into the 32 long instruction cache space.
Not enabled under the 16K non-commercail use license.
IDE
- Added Project->"Clean Output Directory" to delete extraneous files.
*****
As a note, as one of the few commercial 3rd party software partner for the Propeller, we invested a lot of resource in developing a production quality product. As the product is still relatively new from release, I remain cautiously optimistic about the sales potential. However, I can't say it's meeting our projection by any margin at all. As a business person, we make decisions that may or may not panned out and I hate this to be one of them that does not.
// richard
CHANGE LOGS:
V7.02 August 22nd 2008
IDE and Compiler
- Added support for FCACHE, caching of small code chunks in COG RAM
for fast execution. This is done automatically for loops that fit
into the 32 long instruction cache space.
Not enabled under the 16K non-commercail use license.
IDE
- Added Project->"Clean Output Directory" to delete extraneous files.
*****
As a note, as one of the few commercial 3rd party software partner for the Propeller, we invested a lot of resource in developing a production quality product. As the product is still relatively new from release, I remain cautiously optimistic about the sales potential. However, I can't say it's meeting our projection by any margin at all. As a business person, we make decisions that may or may not panned out and I hate this to be one of them that does not.
// richard
Comments
With regard to your 'Note' ... I am pretty sure there will be a substantial take up .. Once enough objects have been ported to C. In terms of exposure the Propeller is still in its infancy .. a well hardened dev. env. and a library of quality objects will ensure this.Personally,when I first decided to use the Propeller in anger,one of the major deciding factors was the availability of objects which far out stripped the initial overhead of learning Spin and the finer points of a the Propeller architecture and its 'modus operandi'. For many, the current lack of components is a drawback - I have no doubt that this will be and is being addressed. I believe that then your projections·will be surpassed.
Regards,
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
I've thought about purchasing, but I thought I'd put it off till debugging and floating point support was included. Otherwise there doesn't seem to be much advantage (at least for me) over SPIN. I guess others may also be waiting. By the way, I'm a bit confused about floating point support. The release notes say it is not included, but the main web page claims to be ANSI C compliant, which I would have thought required floating point.
Also, I thought I'd try out the new version to see how it was going, but after installing it now all I get is "Your temporary key has expired. If you believe this message is in error, please contact the program's author." I don't think I've had it installed for more than 45 days, and even so I thought it was supposed to revert to a code-size limited version, not just refuse to run until I purchase a license.
Ross.
If everyone waits, no new features will be added. It's simple as that. We can't continuously pour development resource into a product unless there is a real actual demand.
No floating point yet. It's not hard, the front end supports it, but I can't imagine that's the reason people are waiting either.
As for license key, please contact me off-list. We are using a new licensing engine release from the vendor and it may be having some issues. richard at imagecraft.com
Regards,
// richard
Does this mean that all future upgrades and any new libraries are secured after initial purchase ?
Seems like the chicken and egg scenario ...
Friend (programmer)once said - 'it's better to have sales and no product than product and no sales'
As we are aware the Propeller is here to stay not hindered by lifetime constraints (within reason) all too familiar with other brands. So any investment in terms of development should yield greater long term returns.
Rgds,
John
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Post Edited (QuattroRS4) : 8/21/2008 11:15:33 AM GMT
Those already using the Propeller were perhaps always going to be a hard to sell to market if they didn't see the buy-in potential or were only interested in free tools.
There did however seem to be another group who indicated they wouldn't use the Propeller, it wasn't credible nor viable without C support, who one would expect to be attracted to the offering.
Could it be that such people weren't that interested anyway and this was nothing other than pretext to bash the Propeller, they're firmly aligned to a competitors camp anyway ? Or perhaps they do want to use Propeller plus C but haven't realised they now can - maybe Propeller C needs more of a marketing push ?
I guess it's pretty hard to discover why people aren't buying a particular product.
I don't know what Propeller chip sales have been, or into which market sectors, but it could be that it hasn't reached critical mass yet, ImageCraft C sales being limited as a consequence.
I think it's always going to be harder to sell tools for a new chip than it is for an existing and already popular one. Hopefully, as Propeller awareness and usage expands, ImageCraft will also reap the rewards and get the return on investment hoped for. At least ImageCraft will be ahead of the competition when demand surges as I'm sure we all hope it will.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Even given the fact that I write my own drivers for sensors and components that I use, I do not see enough appeal in using ICCv7 instead of Spin/PASM. FP support and debugger would tip the scale, though.
Parallax has some desire to enter the "industry professional" market, but is a newcomer relative to their position in the hobby market. For a company like ImageCraft or another 3rd party to have volume sales, the Propeller must have volume sales. How can Parallax grow in the "industry professional" market? Just to begin the discussion ....
1. Definition
For this discussion, let's define the "industry professional" market as an environment where $20M-$200B market capitalization corporations demand products you can supply for assembly in volume product sales.
The primary sales goal then is production design wins at moderate to giant size companies.
The Propeller Forum audience has some professional users, but this is a teeny-weeny-tiny-yes-microscopic slice of participants in that market.
2. Positioning Opportunities
Primary CPU:
Low cost but complicated products
Low power MIPS on demand
...
Secondary CPU:
Moderate speed peripheral devices
Flexible hardware I/O
Video and other I/O "chip-set"
Any non-DMA interface
...
3. Challenges
Perception:
Parallax has a "you mean that Basic Stamp company?" market position. This is a good intangible brand asset (like MacDonalds BigMac). It is, however, something of a distraction in the professional market place. As someone mentioned before, some re-branding or new-branding needs to be done, and positioning as "Parallax Professional" or "Propeller Professional" seems a reasonable way to get there.
What do you mean there are no interrupts? This is a reflex question that will constantly need to be answered.
Mindset:
"Think Different" - think different is nice, but think volume production pays more bills. I won't go into the beanie on the chip thing since it's a brand identity improvement (and really shouldn't be a liability to anyone who is proposing a well conceived solution fit in a product). You might get giggles, but good homework should pay. If you didn't do your homework, the beanie will not be the only problem.
4. Constraints
Performance with 20 MIPS at 80MHz (somewhat less on average) with PASM is competitive with other micro-controllers (~6 MIPS? for uncached C LMM code is less competitive but performance oriented processes or small routines in can be kept in COG PASM, so LMM's limit is not so bad). For applications in the industry professional space as a generic CPU or peripheral, such performance limits applications to moderate speed peripherals.
As shown by Brad, Propeller can be a low-speed USB device with PASM, but not a high-speed device; it can be used for multiple-RS232 ports for example, but use for one or multiple Ethernet switch ports even at 10Mbps may be out of the question (Micah's UDP implementation is promising with external hardware, but 10Mbps alone is unlikely). Having some form of DMA support would make Propeller more viable as a generic CPU or peripheral device.
Memory size is another limiting factor for Propeller. While 32KB is good for many small-scale applications using the Spin byte-code interpreter, it is really too little for the compiled C language binary. A C binary has been shown to be about 3.5 times bigger than the equivalent Spin binary (surprizing that it is not 4+ times bigger - credit ImageCraft on this). There are ways to increase capacity, some have been described, and others are in progress.
5. Requirements
Among the considerations above such as applicability (generic CPU or secondary peripheral), performance measures (speed and memory), products must be built from components sourced by a qualified manufacturer and "fit" with the large company engineering model.
I know for a fact that Parallax meets requirements as a source vendor because I was part of specifying the Basic Stamp in a low volume quick fix project about 6 years ago. It is likely that these bits may pass near a Basic Stamp used for fail-over injection testing before you read them. This project was out of the ordinary by any product measure and if the solution didn't have to be done quickly as possible, it would have involved a different product.
As far as products go that make revenue in the "non-recurring" (ya, right[noparse]:)[/noparse] engineering development/maintenance model, like it or not, C is an "industry professional" requirement. C++ should be considered a requirement also, but it is not as critical. Almost all Computer Science graduates know C (especially the ones in India where people don't complain about things or whatever for fear of losing out to one of the other 10M BSCS graduates).
ImageCraft's ICC as it stands today would be acceptable for production use with some limitations, but some people will cry over not having a debugger. Floating point is optional on data transport performance related products, but can not be taken for granted. It seems floating point libraries could be added as necessary by the user, but a debugger requires compiler support.
All C toolchains require command-line tools and makefile compatability. ICC provides this. Spin can also be used from the command-line and makefiles. IDE are needed for developer convenience, but are not as critical as command-line tools.
Source control is also required for professional use since that is part of corporate intellectual property. Source control is usually a tools group responsibility and not a requirement for the toolchain vendor. Having integrated source control access like provided in the Eclipse IDE is a great value to professional users and a motivation for me to try integration of ICC tools and Eclipse (the only thing I was not able to do with ICC is use an unlimited number of library references as would normally be done in the professional setting).
6. Design Wins
How can Propeller enter the high sales volume professional market?
One place where I have seen an equivalent design win is in a controller for a cryptographic chip, but Propeller would be over-kill. There are 8051 cores in some Cisco routers for backplane communications ... I could see Propeller as a multi-card backplane or multi-bay support processor. Basically anything that needs relatively low speed device interfaces duplicated 6 or 7 times. These are interesting ideas, but without "industry professional" targeted marketing, no one will care.
Marketing can be added to industry journals. Embedded Systems, Network World, EE Times, EDN. Corporate mail rooms still get clogged with this stuff. Ads can be placed anywhere for a price of course [noparse]:)[/noparse] Articles on using Propeller would be great in the journals mentioned.
It seems that Parallax needs a good "industry professional" cheerleader for Propeller. Cheers .....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
In my case the main reason I would use C over SPIN would be to take advantage of the large amount of C library code that already exists. But if I have to manually recode the FP parts (as you have to do in SPIN) then this advantage virtually vanishes.
Ross.
The ICC for Propeller V7.02
Have compliance with standard "C" compiller?
Thank you...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I understand that Imagecraft are small and have limited resources but I expect them to deliver on their commitments!
Alex.
I can refund your license. It would hardly make a difference. Email me offlist.
Ouch!! That's conducive to more sales......
www.elektor.com/news/icc-for-parallax-propeller.630545.lynkx
The code limited version 16K plus, plus 2k for the kernel leaves no headroom to do much. The rest of memory is available for data though
I have been unable to get Tv_text, serial keyboard and SD card code to fit into this limited code size. Whilst it maybe possible there would be nothing left.
C is much faster than spin but the compiled code size is not so compact. For me Forth is very attractive, but of course I am in familiar territory. The C v Forth will no doubt be the subject of a future thread.
My own feelings are that C will find its place in the market with Prop II, but that will be another product line. I guess Richard will have to think about how he is going to deal with that and maybe offer a reduced entry cost into Prop II for current C users.
Ron
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Steve,
I don’t have separate keyboard, I just hacked your serial code and buffered it so that I could decode the 4 sequence arrow keys. (I lost a cog of course) The zip file contains a tiny text editor with 8K buffer, I think its fairly clean now, but decided to start again using my preferred coding tools. The keyboard stuff in bundled with the editor but you easily re-work it. C lib does lack code for buffered serial input.
The Editor was written to get to know a little C. A four week steep climb !!
Ron
Consider this:
http://www.gamasutra.com/view/feature/3766/atari_the_golden_years__a_.php
It's a LONG history of Atari, during the golden years. I'm linking it because of the role that Chris Crawford played in getting the community interested in Atari machines. The problem Imagecraft has right now is a similar thing. For what it's worth, Parallax does not have the same problem as they have a base to power the business right now, and Propeller sales are very longer term things, so it can grow as it grows with few worries.
These two curves don't align very well, and that's the friction seen right now.
My own personal view on this was that getting the environment up and running was key to capturing the greater capability of the next Prop as much as it was getting some sales from existing propeller users.
Why not take a step back and slowly build on the work done now? That's a sunk cost, not coming back. Add things as the business permits, encourage those current users to build stuff and talk about it and perhaps contribute library code and new users will come as the propeller base grows.
I don't see anything that says this base will not grow. It's just too great of a chip for that to not happen!
...but it's really different too, meaning it's gotta sink in.
And that's where the evangelist comes into play.
I've been talking up the chip since I purchased one on a lark. A friend evangalized it to me, and pointed out how it aligned well with stuff I wanted to do. Got me hooked straight away. This would never have happened, had I not had that recommendation in the first place.
The traditional Parallax model, from what I can tell, is to let customers do this and work through school education programs. Both solid, no worries there. I think it's smart and totally well aligned with the engineering and education focus Parallax has.
On the other hand, this dynamic isn't gonna work so well for partner efforts. One thing is the engineering! Imagecraft and Parallax actually compete on that basis! SPIN + PASM have gotta be good, or their model does not work, meaning if Parallax does their job well, C might not be the draw it otherwise would be!
When I first saw this project announcement, I also had been following the LMM discussions with great interest. Saw the two as a perfect third option for those wanting larger programs that could run faster than SPIN. Mission accomplished.
At that time, the discussion for LMM was WHY?
The answer was, given the current RAM and speed of the existing Prop, the number of users who would require that third option was small. This remains true today and is the source of the low sales.
Grow the prop and you will grow C. You can also just work on growing C, but I think that's early given the dynamics in play right now. Better to just grow the prop and take C along for the ride.
Prop II, with it's larger memory base and greater number of COG's will provide an environment where the scope of possible tasks will warrant a C environment far more than the current one will.
So then, is is possible to maintain what has happened, capture those sales possible and build for Prop II, where it's really gonna shine a lot brighter?
You will get me on the thing somewhere in there, BTW! I like C and am interested in building some objects. I just gotta deal with life, or I already would.
I appreciate the efforts, BTW. I also think they will pay off, but it will be in the mid to longer term.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
No matter what evangelism there is for Propeller and ICC there are legitimate, technical, counters when it comes to the Propeller I which aren't there for the Propeller II. Equally there are some criticisms of the Propeller itself which will be addressed in Propeller II.
Maybe ICC sales are in the doldrums because it's ahead of the curve, perfectly suited to what will come, but not so ideal with what there presently is ?
I don't know how true that is, or how one could fix the situation, or even if it's worth fixing rather than riding out the still water. I'm sure that ICC will have attractiveness and sales in the future but with limited sales now it must feel like doing anything could be throwing more good money after bad.
We've discussed the merits of C on the Propeller I and debated what its goal and aims should be so perhaps its worth revisiting that to assess what would make ICC more attractive to Propeller users now as distinct to those in the future ?
If limited resources of the Propeller I compounded by code density of ICC is the problem it may be worth addressing that although the advantage of speed could be reduced. Had ICC come out when Propeller I and II were in production I think it would have felt natural to take a perfectly good compiler for the II and optimise it for the less capable I even with a loss of performance. Is that the way forwards ? I don't know; there may be other reasons beyond what I see as limiting take-up.
For all I've said I've never wanted ICC to fail. I believe it will succeed with the Propeller II and I can even see myself singing its praises, it's just in an awkward position at the moment which must be quite depressing for all concerned.
Just to make it clear that we are not giving up, because we really think Propeller is a great chip with a great future, we will definitely add Floating Point support in. It will be done by end of Nov. This will be IEEE 32 bit format. There will not be 64 bit double precision FP support until may be PropII as there is not enough legroom on PropI to support it. Then again, it is very rare that embedded users would really *need* 64 bits FP.
One thing I'd say, the phrase evangelism came up a few times: please think about how ICC for Propeller is generally a good thing for Propeller. If you have concrete suggestions on how we can improve the products, I welcome your comments and suggestions.
Thanks
// richard
OK, I'll give ICC serious thought in a few weeks, and hopefully make a purchase (if FP upgrade is free?).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
I'm sure that (as Proeller users) everyone here understands the frustration of being "ahead of the curve". Don't give up! It seems apparent that there will be considerable interest in ICC when floating point is added (including from me!). Perhaps ImageCraft's only mistake was in trying to be too helpful by releasing the compiler a bit too early.
Ross.
This may be so. Our past experience fails us in that sense. We have often released our "first release" compiler for our other products without floating point first, just to get the products out so people can start writing real code. This strategy has not failed us before, and I think it is because for those products, there are real pent up demand for people to write production code. Then we release FP in a few month's time and everyone is happy. And truth be told, most people do not use FP on the microcontroller anyway.
However, on the Propeller, since it is still a relatively new chip, I am guessing that most people are just kicking the tire right now. Since there is the luxury of waiting, the lack of certain feature that people may actually not need becomes a bigger missing feature that it should be.
Of course I could be wrong yet again and may be really floating point is just very important for the Propeller usage. We will see.
You have made no mistakes, neither in development or nor marketing.
The C compiler is an excellent initial offering. Give it time.
If you included the callback hooks for debugging, then the majority would welcome this feature above all others.
Otherwise, relax. You have a fine product that will only grow in importance with time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
In the company, in which I work, we use primarily chips of Renesas (e.g. M16C) or Microchip (PIC24 ...) and we program, because of the portability, exclusively in C.
Establishing a new programming language would be to time- and cost-intensive. Especially if you can use it only for one special chip(like Spin for the propeller).
So with ICC the first step is done.
FCACHE also offers the possibility for small code chunks to be fast.
But this is not sufficient in my opinion. It would be better if I could compile e.g. a whole file (a driver or something else)for the use in "COG" without overhead of LMM.
It would be possible to load this assembler code then also from an external memory (e.g.SD-card) what frees up some memory in HUB.
The memory size Of the propeller is anyway the biggest handicap.
Absolutely right!
Right. I think everyone who tested Spin, realized that Spin is really not bad. But If you come from C, its really hard to get used to it. Especially if you have to switch between both. At least I have problems with it. And then for the fast parts you need assembler. I don't want to program at such a low level. For professional use it is no option anyway.
@richard
Maybe I am stupid, but I didn`t get it worked to put a whole function in fcache.
Can you tell me the right syntax for fcache.