Naturally, you could implement C in 3 bytecoded instructions (which I think may be the minimum required to implement a simple univeral turing machine). But if you had nimble fingers you could probably implement C faster on an abacus. The more bytecoded instructions you have, the more "efficient" your implementation is. To implement SPIN efficiently requires a whole cog. To implement a complete set of primitives required by C - at speeds approaching SPIN speeds - I believe you would need two cogs - plus a genius like Chip to program them!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Like all engineering problems there are trade offs to be made. I'm sure Chip wanted a high level language for the Prop and that he intentionally limited the solution to using just one Cog for the interpreter. The result being Spin, its byte codes, and it's one COG interpreter.
I would imagine if C was a design goal at the outset an interpreter could have been devised that would accommodate C more efficiently that the ZPU architecture of Zog but which still fits in one COG. The resulting interpreter may not have been up to the speed of current Spin for either C or Spin.
We will assume a constant supply of Chip genius...although I hope he has his head down working on PropII and is not distractd by all this C fluff.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@Ross: I mean C to Spin Bytecode. I had not thought about any other bytecode.
However, if the Spin Interpreter needs to be expanded, that can be done, or indeed a new bytecode and interpreter if required. A different bytecode does not necessarily mean we cannot use existing objects although I agree it becomes messy.
@heater: A new or extended interpreter does not need to live in ROM. When the need is there, the upper half of a 64KB eeprom (or larger) will get used and the code will get done. There are already partial solutions now.
You have proved it can be done with ZOG, so it certainly can be done faster without ZOG.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
When we first designed Propeller C, we made the decision to go with a LMM implementation since it gives us the speed we thought would be important.
On hindsight, may be it would have been better if we design our bytecode interpreter instead.
Ross mentioned that he didn't realize how much work it is to (paraphrase) to make a product vs. just a compiler. It's true, any computer science grad can probably write an OK compiler, but it takes time and effort and experience to make a product. We didn't just spend a couple weeks writing a backend, we wrote our AVR compiler backend 3 times, each time adding more and more optimizations. Our compiler/asm/linker are quite portable. Target specific code account for may be 10% in asm/linker and 20% in the backend, but we do register allocation, register history, peephole optimization, and even machine independent optimizations. These are not the things one can do in two weeks. The so called Whitesmith Style? Yup, I was there, at Whitesmiths from 1985 until it was sold. Experience counts.
However, we didn't realize how hampered we would be by the 32K hubram limit. We sell a decent number of Propeller C, especially thanks to Parallax for promoting it. However, look at this forum, no offense to anyone, but the most threads are on how to port a XYZ emulator. I may be wrong, but I don't think Parallax can be successful selling Propeller to people who want to run CPM programs.
Can Propeller be successful in educational market like the Stamp was/is? I doubt it. Arduino and other micros are a big factor. You can argue all you like, but C is what they teach at embedded system classes. I know, we sold 300+ licenses to DeVry, and to Stanford, Tidewater Community College, PSU etc. etc.
Can Propeller compete in the general microcontroller market? I think so, otherwise I wouldn't have spent the effort to write Propeller C.
Free C for Propeller? Sure, it would be lousy for us, but would be good for Parallax. PMC, as spec'ed, is a waste of time. When I was working at places like HP, we would call it Empire Building.
Imagecraft said...
On hindsight, may be it would have been better if we design our bytecode interpreter instead.
No, you made the right (and in fact the only possible) decision.
Parallax may choose to implement PMC for various reasons - e.g. to grab some of the "educational" market - but it will have nothing to do with C very little to offer C professionals.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
So what we need is a somewhat enhanced Spin byte code interpreter that will also more efficiently support standard C.
You have been working on the interpreter, can it be enhanced and still fit a COG? Perhaps with dispatch table in HUB or whatever. As you say it can be bootstrapped from the existing interpreter.
Then we need someone to create the C compiler for that. This is getting perhaps to be too much effort for what we get out of it.
ImageCraft: In hind-hindsight you may be happy you used LMM. When the prop II comes your compiler and Catalina will be very happy there.
"Can Propeller be successful in educational market ..."
Whilst I applaud Parallax's work in the hobby and educational area, the idea that products of the scale of PMC should be developed solely to support what goes on in education kind of worries me. If that were always true we would never make any progress. In my case the Prop would only support a limited BASIC and CG319. What is CG319? That's a pseudo instruction set of a non existent machine used to teach assembly language back in the day I was in technical school.
Looks like running CP/M has stimulated a few Prop sales[noparse]:)[/noparse] All of which was a big surprise to me when I started that off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
ImageCraft: Richard, LMM will be the right decision when PropII arrives although I think a bytecode form will have it's place too.
Richard, you are right to say "the most threads are on how to port a XYZ emulator". I actually didn't build TriBlade or RamBlade for ZiCog or CPM. It just turned out that way as the other pieces to the puzzle are still not quite there yet. SphinxOS is close and we have a prop compiler (Sphinx) and SD access routines. The enthusiasm for ZiCog & CPM shows me that an OS is required. A proper OS will allow us to switch in and out of ZiCog/CPM to get the best of both worlds. IMHO we will end up using 2 props for this even tho' RamBlade & DracBlade will do it standalone. IMHO this should then open up other markets for Parallax. This is of course a seperate use for the Prop than the C question although there will no doubt be benefits flowing back into these projects from the likes of ImageC and Catalina and any other C running with XMM (external memory).
heater: My version of Chip's Spin Interpreter does use a hub despatch table (that is what I developed it for, and the fast overlay although I didn't need it in the end). I have space in the cog and I was getting >20-25% improvement. But, it uses 4KB hub (or 2KB if the interpreter is loaded from upper eeprom.
OT - Educational Market
I think we already have agreed educators want C for whatever the reason.So, the question is more about what would students like to program? I asked my nephews (early teens)
* Games
* Robotics
Is Arduino, etc gaining a foothold in the education market? What can Parallax and the Prop do?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Why not add an LMM interpreter to the Spin interpreter?· This would be able to execute spin bytecodes as well as LMM PASM.··A spin method could call a C function, which could call a PropBASIC routine.· All we need is a·standard way to call routines and pass arguments on the stack.
Dave: This is off-topic but the debugger I built to debug spin and pasm is an LMM style (the debug code resides in hub and is LMM) and it is actually loaded into the spin interpreter I did at $1F0-$1F3 (shaddow ram) so it takes zero footprint. I have not looked at the actual LMM handler routines being used but they must be quite similar. Mine is a 4 instruction loop. If you want to continue this discussion I suggest you post to the thread http://forums.parallax.com/forums/default.aspx?f=25&m=273607
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
There's not enough space to put an LMM interpeter in the SPIN cog, and putting it in a different cog becomes expensive in both time AND space. Both the inter-cog communications mechanisms available on the Prop, and the memory management available in SPIN are quite rudimentary. They are not really geared towards supporting multiple language environments. This is not a criticism of either the Propeller or SPIN - which is after all only a microcontroller! - who woud have ever thought it needed sophisticated internal communications paths and memory management?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I wasn't thinking of using more than one cog for the interpreter.· The Spin interpreter would be expanded into hub memory.· We would take the least used part of the Spin language and move the interpreter for those spin codebytes out to hub memory.· This would open up room in the cog for the LMM interpreter, plus some spare registers plus some overlay space for tight loops to run efficiently.
Let's say the LMM interpreter requires 64 longs in the cog.· We would need to move 64 longs from the current Spin interpreter out to hub RAM.· The trick is to identify spin bytecodes that use up a lot of cog memory, but are rarely used.· In addition to being able to run LMM code we could also add extensions to the Spin language in the future.· This might be a good approach for Parallax to take on the Prop II.
Post Edited (Dave Hein) : 4/19/2010 2:18:31 PM GMT
Re Imagecraft However, we didn't realize how hampered we would be by the 32K hubram limit. We sell a decent number of Propeller C, especially thanks to Parallax for promoting it. However, look at this forum, no offense to anyone, but the most threads are on how to port a XYZ emulator. I may be wrong, but I don't think Parallax can be successful selling Propeller to people who want to run CPM programs.
That is very true. 32k is very limiting. I started off coding network boards in Picaxe and Arduino and found only a few kilobytes extremely limiting. I moved to a real Z80 with the N8VEM but found the need for multiple uarts and no buffered I/O just as limiting. So I moved to the Propeller but still it wasn't enough ram. So I copied what others were doing and added a ram chip. Now, finally, there is enough ram to do some serious programming without always worrying about running out of memory. As for CP/M, I couldn't imagine a more boring operating system. But CP/M leads to MP/M and with MP/M it is possible to have up to 8 programs in C all running at the same time, each with at least 50k of code space. That starts to become useful.
There are probably minimal sales with CP/M or MP/M on the propeller.
But I think there are potential sales with "Hello World" in C on the propeller. Even if that is just something to get people in and then they realise that PASM and Spin and the Obex are better ways to use the chip.
I see at least 4 individuals who have all the pieces of the jigsaw already done. I guess for Parallax, the question might be whether it is cheaper to replicate in-house the work of those individuals over (probably) several years, or to work out what that would cost and start working out some sort of arrangement with incorporating work that has already been done.
@Ross: How many cog locations does the LMM interpreter require?
BTW: LMM can be done in the spin cog but I suspect you mean the other variables required.
@Dave: Code profiling is easy to do with what I did to the Interpreter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Imagecraft said...
However, look at this forum, no offense to anyone, but the most threads are on how to port a XYZ emulator.
Statistically, we forumistas are but a tiny sample of Parallax's customer base and, I would guess, atypical users as well. Commercial users, for example, might not even post at all, if they don't want anybody to know what they're working on. So, I would not make any market generalizations based solely on a thread count from the forum.
Phil: re: ImageCraft re: "...the most threads are on how to port a XYZ emulator."
I don't think that statement is even anywhere near true.
Seems to me most threads are generated by a wide assortment of people popping up and asking quite reasonable questions about how the Propeller works, where to find info, how to approach such and such a problem with the Prop and so on.
These questions get resolved pretty quickly and the poster moves on, solution in hand [noparse][[/noparse]see joke below]. The thread stops there.
There are a few abnormally long lived and long winded threads that never seem to die. I'm guilty of that myself with ZiCog. Sorry, it takes me a long time to move my hobby projects along and who knows who pops up and wants to join in. It was a surprise to me when they did, as I have said before.
The other long threads we have here are about such things as BradC's BST. Well why not? He's only one guy doing a fabulous job that is/was/will not going to be "done" in a week. Same applies to Catalina and such.
Is Imagecraft Jealous that no one is talking about ICC here?
Joke: Confucius says, "Young man who goes to sleep with problem on mind, wakes up with solution in hand."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Phil: re: ImageCraft re: "...the most threads are on how to port a XYZ emulator."
I don't think that statement is even anywhere near true.
Nor do I. Based on a quick scan of the Propeller Forum's front page, it can be easy to get that impression, though. And some of the longest threads are about emulators. But the vast majoprity of threads hang around only until a certain problem gets solved, then drop off the front page into obscurity.
"Is Imagecraft Jealous that no one is talking about ICC here?", I do not think that is the case at all. There isn't that much talk about about Catalina C either, other than what RossH provides. I find that there just isn't that much talk about C, for the Propeller, and that is the concern. I remember back a few years ago, just after the Prop was introduced, there were quite a few posts asking why there was no C for the Prop. I thought for sure that once C was provided, all those posters would be back in force. Even the thread that I had going for awhile, back a few months ago, did not get that many new responders.
From my perspective I fall in the category, if you are doing the C thing, do it right, use a real C/C++ version, and not a "sort of looks like C" version. If you want to do a "sort of looks like C" version, than create something like Spin# or Spin@, and preface with, "has the look and feel of C", and then you can do whatever you want with it, but I believe it will become a novelty item.
This is a tough assignment for marketing, you want to get the Prop into the educational field, but you do not have a processor that will do the job the way it's supposed to, using C. Maybe marketing should be pushing for a PropC processor with ImageCraft C suite, to really push the chip to its full potential. With that combination, all the criticism should be silenced, the schools, and companies will be ordering them by the truck loads.
This thread has wandered OT .... what else is new [noparse]:)[/noparse].
Regarding long threads: maybe the topic and the threads should be moved.
* I honestly believe there should be a special Emulation Forum for all those projects. There should be a Projects Forum for all the other projects. By doing that, the original Propeller Forum can once again become a support forum.
* When the Javelin Propeller has a good version, I will move it to the Javelin forum where it belongs so I don't have to feel bad about wasting uninterested visitors' band-width. Here are a few reasons why:
When I was working with Peter on "JVM for Propeller" which turned into a 13 page thread, I started having deep reservations about using the forum as a two person communications tool and my guilty feeling was relieved when it stopped. There were few visiting posters to the original thread. When I revived a PASM version a year later, there was little interest so I stopped. This year I revived the thread again and there has been some discussion, but only a few people really care about it. Now that Javelin has officially reached end of life in it's stamp form, getting something equivalent running on the Propeller seems useful to at least preserve the volume of work that was done with Javelin.
This is all I'll say about project threads here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Rsadeika: "...I thought for sure that once C was provided, all those posters would be back in force."
Perhaps, just perhaps, all those poster originally clamouring for C on the Prop eventually realized that C on the Prop is just not a very good idea. (Ducks head whilst RossH and ImageCraft take aim with the big rocks). They have either satisfied their C lust with some other micro or realized they can get the project done on the Prop more easily without it.
Still, that's not going to stop me dinking with Zog/ZPU and fully standards compliant C courtesy of GCC.
What Parallax marketing seem to want to satisfy the perceived demand in education is a Prop with a new byte code interpreter in ROM tailored for C. Together with a new Prop tool that does pretty much what the current Spin tool does but with C and PASM.
Jazzed: I have often thought about the fact that ZiCog, for example, maybe taking an unresonable amount of space on this forum and should maybe be farmed out to an "emulation" forum or whatever.
However, it turns out that much of the discussion on those threads is not about emulation or Z80 but rather about general Prop things, serial ports for consoles, SD card interfacing, long discussions about attaching external RAM etc etc etc.
So I conclude it's best for the threads to stay where they are. Except possibly in the extreame where one ends up with a two man conversation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@heater: Why do you keep insisting that the Prop has to have a new ROM? A C bytecode interpreter can just as easily be loaded from hub or with a little more effort, directly from the upper 64KB in eeprom (presuming a 64KB eeprom which is quite common I think).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
@Cluso: I'm not really insisting, more like fantasizing. I know it will never happen. It would be ready made, ready out of the box (well chip) just like Spin is now.
I'm sure you are right, it could be bootstrapped from the upper 32K of an EEPROM or such.
What I have in mind is a set up where ones entire application is written in C and PASM without ever having to see one line of Spin in the applications source code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Phil: re: ImageCraft re: "...the most threads are on how to port a XYZ emulator."
I don't think that statement is even anywhere near true.
Seems to me most threads are generated by a wide assortment of people popping up and asking quite reasonable questions about how the Propeller works, where to find info, how to approach such and such a problem with the Prop and so on.
These questions get resolved pretty quickly and the poster moves on, solution in hand [noparse][[/noparse]see joke below]. The thread stops there.
There are a few abnormally long lived and long winded threads that never seem to die. I'm guilty of that myself with ZiCog. Sorry, it takes me a long time to move my hobby projects along and who knows who pops up and wants to join in. It was a surprise to me when they did, as I have said before.
The other long threads we have here are about such things as BradC's BST. Well why not? He's only one guy doing a fabulous job that is/was/will not going to be "done" in a week. Same applies to Catalina and such.
Is Imagecraft Jealous that no one is talking about ICC here?
Joke: Confucius says, "Young man who goes to sleep with problem on mind, wakes up with solution in hand."
It is this lurker's opinion that the best content on the propeller forum are the long threads. They are interesting in the here-and-now and are also historically significant in that they enable late arrivals like me to come up to speed without asking the same questions all over again. At times a conversation may be between just two individuals (or even sequential posts from the same person), but it is obvious by the view stats that very many more are tuning in.
I never miss a Zog installment because it's a fascinating, evolving story. Same with pullmoll's many adventures. What would the forum be without these interesting, inspiring, ongoing sagas?
K2 said...
I never miss a Zog installment because it's a fascinating, evolving story.
Actually, I'm a fan of Zog too. Really! Zog allows my favorite world class GNU C/C++ tool set on Propeller in a reasonable way. Such tools allow things to grow in productive ways despite the objections of all the loyal BASIC fans. And ... Zog is not Z80 as heater points out.
Sadly, CPM running on the Z80 emulator offers a pre ANSI C89 compiler although if I really had to use it I could since I have a copy of the original K&R book that specifies it, and have programmed with it long ago when I had no choice (system bugs, kernel core dumps, and all the rest).
But more than the tools available, I'm not inclined to go that far back in time when WordStar was the dominant consumer word processor ... ya I used that too. I love Vi which has been around even longer, but it is a programmer's editor, and it has matured like good Cabernet rather than Thunderbird or MD 20/20. I do love Marlborough Sauvignon Blanc though; it is a timely fresh product.
Actually, If parallax gave the Z80/CPM emulators their own forum, that would promote them in a way that would draw even more like-minded people and further propagate something for which I have no use [noparse]:)[/noparse] Then all the Z80 CP/M fans could all subscribe to that forum and not be bothered by "why is my program broke?" posts. It would also be great marketing for Parallax I think ... especially if someone was able to emulate and atMega16 for example which may be difficult, but it would add more impact to the Propeller value proposition.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
I only mention the ZOG/Z80/etc. emulator a commentary of the potential markets for the Propeller. Obviously I am not telling anyone to work on this and not that, but just an observation.
The truth is no matter how fast the Prop can run Z80/ZOG/VM instructions, it is not going to make much difference in Parallax's bottom line. Parallax makes, I don't know, $5 per chip sold, what the heck, a nice figure. You count how many people working for Parallax, plus marketing, plus R&D, and it's going to be a lot of Propeller needed to make that happen.
Obviously Parallax's strength has been in the educational market.
Obviously Parallax thinks about PMC will get them into the edu market with the Propeller.
I am of the opinion that the general embedded market is a bigger market.
However, neither PMC, or my side comment about the emulators, help in either case of the edu market or the embedded market.
Again, I am not telling people not to work on emulators, but just saying things as I see them.
While it may be a little late by now, as I have not seen anyone from Parallax in this thread for several page now, I can't resist but to post..
I don't really understand where Parallax is coming up with the lack of C support on the Prop is hurting their share in the education market. Not only are there two C compilers, but there's also CSpin - which seems to be exactly what Parallax is suggesting, just more hampered. To reinvent the wheel is not just a waste of money, but time as well.
If I had to make an educated guess on why the Propeller might have a bit of a hard time gaining traction in the education market, it would have more to due with how unconventional it is, rather than it's lack of C support. It has a significantly different architecture than the most common microcontrollers, which might make using it as a learning tool a bit hard to justify to educators. If there is any market the Propeller should be targeting, it should be the professional market - engineers with experience. If only more developers really knew how much easier it is to implement certain functionality in the Prop over more typical MCUs, and exploit it's use in the consumer electronics arena for marketing purposes, I think the Prop, and Parallax would be in a better position today.
It's after 18:00 Central time as I type -- Parallax corporate has probably concluded business operations for the day. [noparse][[/noparse]Oops: my math was flawed -- it's only 16:00 in CA. I'm sure they work until 17:00, at least!] Today was the day for the "big meeting" to assess the PMC project status.
What happened? What is the new, internal posture on PMC? Which direction will the project take?
You asked for input ... and you certainly got it! Again, as I type there are 9 pages in this thread, ranging all over the project-space map. I, for one, am surprisingly curious what the internal outcome of all of this hullaballoo is.
Please share.
t++
[noparse][[/noparse]Edited to fix the time stamps]
Post Edited (tmaynard) : 4/19/2010 11:33:19 PM GMT
My two (Euro) cents of opinion:
Writing a (subset of) C to Spin translator is probably worthless for a) reasons of execution speed and b) not allowing to easily port existing C source to that limited subset.
I'd rather see a Catalina like approach or Catalina itself integrated into the Propeller tool as an alternative to generate PASM object code in either the small memory model (cog only code) or large memory, i.e. LMM method. That way a costumer would get what he expects from writing code in C: decent speed. PASM should be possible as inline assembler code for the cases where it needs the maximum possible speed.
You could even support Spin with C source code in the DAT section that way, allowing customers to write faster code without having to learn PASM first.
The compiler should be accompanied by a library with (most important) code to interface Spin or external PASM methods. That would most probably involve setting up a stack frame for the call somewhere in hub RAM. A function similar to execve(2) should be made available to call methods in an object. This way also something like a libc with standard i/o functions could be supplied and linked into code that requests it.
If you would then open source the compiler, some people might look into it and spend time on trying to optimize the compiler itself as well as the code it emits. This would benefit all users.
Comments
Maybe I should add the word "efficiently".
Naturally, you could implement C in 3 bytecoded instructions (which I think may be the minimum required to implement a simple univeral turing machine). But if you had nimble fingers you could probably implement C faster on an abacus. The more bytecoded instructions you have, the more "efficient" your implementation is. To implement SPIN efficiently requires a whole cog. To implement a complete set of primitives required by C - at speeds approaching SPIN speeds - I believe you would need two cogs - plus a genius like Chip to program them!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Like all engineering problems there are trade offs to be made. I'm sure Chip wanted a high level language for the Prop and that he intentionally limited the solution to using just one Cog for the interpreter. The result being Spin, its byte codes, and it's one COG interpreter.
I would imagine if C was a design goal at the outset an interpreter could have been devised that would accommodate C more efficiently that the ZPU architecture of Zog but which still fits in one COG. The resulting interpreter may not have been up to the speed of current Spin for either C or Spin.
We will assume a constant supply of Chip genius...although I hope he has his head down working on PropII and is not distractd by all this C fluff.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1 11 1111 111 11 11 11 111111 1111 11 1 11111 11111 11111 111 11111111 111 1 1 111 11 1 1 1 11 11*
Ross.
* translated means ("agreed!")
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
However, if the Spin Interpreter needs to be expanded, that can be done, or indeed a new bytecode and interpreter if required. A different bytecode does not necessarily mean we cannot use existing objects although I agree it becomes messy.
@heater: A new or extended interpreter does not need to live in ROM. When the need is there, the upper half of a 64KB eeprom (or larger) will get used and the code will get done. There are already partial solutions now.
You have proved it can be done with ZOG, so it certainly can be done faster without ZOG.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
On hindsight, may be it would have been better if we design our bytecode interpreter instead.
Ross mentioned that he didn't realize how much work it is to (paraphrase) to make a product vs. just a compiler. It's true, any computer science grad can probably write an OK compiler, but it takes time and effort and experience to make a product. We didn't just spend a couple weeks writing a backend, we wrote our AVR compiler backend 3 times, each time adding more and more optimizations. Our compiler/asm/linker are quite portable. Target specific code account for may be 10% in asm/linker and 20% in the backend, but we do register allocation, register history, peephole optimization, and even machine independent optimizations. These are not the things one can do in two weeks. The so called Whitesmith Style? Yup, I was there, at Whitesmiths from 1985 until it was sold. Experience counts.
However, we didn't realize how hampered we would be by the 32K hubram limit. We sell a decent number of Propeller C, especially thanks to Parallax for promoting it. However, look at this forum, no offense to anyone, but the most threads are on how to port a XYZ emulator. I may be wrong, but I don't think Parallax can be successful selling Propeller to people who want to run CPM programs.
Can Propeller be successful in educational market like the Stamp was/is? I doubt it. Arduino and other micros are a big factor. You can argue all you like, but C is what they teach at embedded system classes. I know, we sold 300+ licenses to DeVry, and to Stanford, Tidewater Community College, PSU etc. etc.
Can Propeller compete in the general microcontroller market? I think so, otherwise I wouldn't have spent the effort to write Propeller C.
Free C for Propeller? Sure, it would be lousy for us, but would be good for Parallax. PMC, as spec'ed, is a waste of time. When I was working at places like HP, we would call it Empire Building.
Parallax may choose to implement PMC for various reasons - e.g. to grab some of the "educational" market - but it will have nothing to do with C very little to offer C professionals.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 4/19/2010 11:39:00 AM GMT
So what we need is a somewhat enhanced Spin byte code interpreter that will also more efficiently support standard C.
You have been working on the interpreter, can it be enhanced and still fit a COG? Perhaps with dispatch table in HUB or whatever. As you say it can be bootstrapped from the existing interpreter.
Then we need someone to create the C compiler for that. This is getting perhaps to be too much effort for what we get out of it.
ImageCraft: In hind-hindsight you may be happy you used LMM. When the prop II comes your compiler and Catalina will be very happy there.
"Can Propeller be successful in educational market ..."
Whilst I applaud Parallax's work in the hobby and educational area, the idea that products of the scale of PMC should be developed solely to support what goes on in education kind of worries me. If that were always true we would never make any progress. In my case the Prop would only support a limited BASIC and CG319. What is CG319? That's a pseudo instruction set of a non existent machine used to teach assembly language back in the day I was in technical school.
Looks like running CP/M has stimulated a few Prop sales[noparse]:)[/noparse] All of which was a big surprise to me when I started that off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Richard, you are right to say "the most threads are on how to port a XYZ emulator". I actually didn't build TriBlade or RamBlade for ZiCog or CPM. It just turned out that way as the other pieces to the puzzle are still not quite there yet. SphinxOS is close and we have a prop compiler (Sphinx) and SD access routines. The enthusiasm for ZiCog & CPM shows me that an OS is required. A proper OS will allow us to switch in and out of ZiCog/CPM to get the best of both worlds. IMHO we will end up using 2 props for this even tho' RamBlade & DracBlade will do it standalone. IMHO this should then open up other markets for Parallax. This is of course a seperate use for the Prop than the C question although there will no doubt be benefits flowing back into these projects from the likes of ImageC and Catalina and any other C running with XMM (external memory).
heater: My version of Chip's Spin Interpreter does use a hub despatch table (that is what I developed it for, and the fast overlay although I didn't need it in the end). I have space in the cog and I was getting >20-25% improvement. But, it uses 4KB hub (or 2KB if the interpreter is loaded from upper eeprom.
OT - Educational Market
I think we already have agreed educators want C for whatever the reason.So, the question is more about what would students like to program? I asked my nephews (early teens)
* Games
* Robotics
Is Arduino, etc gaining a foothold in the education market? What can Parallax and the Prop do?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
There's not enough space to put an LMM interpeter in the SPIN cog, and putting it in a different cog becomes expensive in both time AND space. Both the inter-cog communications mechanisms available on the Prop, and the memory management available in SPIN are quite rudimentary. They are not really geared towards supporting multiple language environments. This is not a criticism of either the Propeller or SPIN - which is after all only a microcontroller! - who woud have ever thought it needed sophisticated internal communications paths and memory management?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Let's say the LMM interpreter requires 64 longs in the cog.· We would need to move 64 longs from the current Spin interpreter out to hub RAM.· The trick is to identify spin bytecodes that use up a lot of cog memory, but are rarely used.· In addition to being able to run LMM code we could also add extensions to the Spin language in the future.· This might be a good approach for Parallax to take on the Prop II.
Post Edited (Dave Hein) : 4/19/2010 2:18:31 PM GMT
That is very true. 32k is very limiting. I started off coding network boards in Picaxe and Arduino and found only a few kilobytes extremely limiting. I moved to a real Z80 with the N8VEM but found the need for multiple uarts and no buffered I/O just as limiting. So I moved to the Propeller but still it wasn't enough ram. So I copied what others were doing and added a ram chip. Now, finally, there is enough ram to do some serious programming without always worrying about running out of memory. As for CP/M, I couldn't imagine a more boring operating system. But CP/M leads to MP/M and with MP/M it is possible to have up to 8 programs in C all running at the same time, each with at least 50k of code space. That starts to become useful.
There are probably minimal sales with CP/M or MP/M on the propeller.
But I think there are potential sales with "Hello World" in C on the propeller. Even if that is just something to get people in and then they realise that PASM and Spin and the Obex are better ways to use the chip.
I see at least 4 individuals who have all the pieces of the jigsaw already done. I guess for Parallax, the question might be whether it is cheaper to replicate in-house the work of those individuals over (probably) several years, or to work out what that would cost and start working out some sort of arrangement with incorporating work that has already been done.
Just my $0.02 worth, anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
BTW: LMM can be done in the spin cog but I suspect you mean the other variables required.
@Dave: Code profiling is easy to do with what I did to the Interpreter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
-Phil
I don't think that statement is even anywhere near true.
Seems to me most threads are generated by a wide assortment of people popping up and asking quite reasonable questions about how the Propeller works, where to find info, how to approach such and such a problem with the Prop and so on.
These questions get resolved pretty quickly and the poster moves on, solution in hand [noparse][[/noparse]see joke below]. The thread stops there.
There are a few abnormally long lived and long winded threads that never seem to die. I'm guilty of that myself with ZiCog. Sorry, it takes me a long time to move my hobby projects along and who knows who pops up and wants to join in. It was a surprise to me when they did, as I have said before.
The other long threads we have here are about such things as BradC's BST. Well why not? He's only one guy doing a fabulous job that is/was/will not going to be "done" in a week. Same applies to Catalina and such.
Is Imagecraft Jealous that no one is talking about ICC here?
Joke: Confucius says, "Young man who goes to sleep with problem on mind, wakes up with solution in hand."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
-Phil
From my perspective I fall in the category, if you are doing the C thing, do it right, use a real C/C++ version, and not a "sort of looks like C" version. If you want to do a "sort of looks like C" version, than create something like Spin# or Spin@, and preface with, "has the look and feel of C", and then you can do whatever you want with it, but I believe it will become a novelty item.
This is a tough assignment for marketing, you want to get the Prop into the educational field, but you do not have a processor that will do the job the way it's supposed to, using C. Maybe marketing should be pushing for a PropC processor with ImageCraft C suite, to really push the chip to its full potential. With that combination, all the criticism should be silenced, the schools, and companies will be ordering them by the truck loads.
Regarding long threads: maybe the topic and the threads should be moved.
* I honestly believe there should be a special Emulation Forum for all those projects. There should be a Projects Forum for all the other projects. By doing that, the original Propeller Forum can once again become a support forum.
* When the Javelin Propeller has a good version, I will move it to the Javelin forum where it belongs so I don't have to feel bad about wasting uninterested visitors' band-width. Here are a few reasons why:
When I was working with Peter on "JVM for Propeller" which turned into a 13 page thread, I started having deep reservations about using the forum as a two person communications tool and my guilty feeling was relieved when it stopped. There were few visiting posters to the original thread. When I revived a PASM version a year later, there was little interest so I stopped. This year I revived the thread again and there has been some discussion, but only a few people really care about it. Now that Javelin has officially reached end of life in it's stamp form, getting something equivalent running on the Propeller seems useful to at least preserve the volume of work that was done with Javelin.
This is all I'll say about project threads here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Perhaps, just perhaps, all those poster originally clamouring for C on the Prop eventually realized that C on the Prop is just not a very good idea. (Ducks head whilst RossH and ImageCraft take aim with the big rocks). They have either satisfied their C lust with some other micro or realized they can get the project done on the Prop more easily without it.
Still, that's not going to stop me dinking with Zog/ZPU and fully standards compliant C courtesy of GCC.
What Parallax marketing seem to want to satisfy the perceived demand in education is a Prop with a new byte code interpreter in ROM tailored for C. Together with a new Prop tool that does pretty much what the current Spin tool does but with C and PASM.
Jazzed: I have often thought about the fact that ZiCog, for example, maybe taking an unresonable amount of space on this forum and should maybe be farmed out to an "emulation" forum or whatever.
However, it turns out that much of the discussion on those threads is not about emulation or Z80 but rather about general Prop things, serial ports for consoles, SD card interfacing, long discussions about attaching external RAM etc etc etc.
So I conclude it's best for the threads to stay where they are. Except possibly in the extreame where one ends up with a two man conversation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 4/19/2010 5:17:47 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I'm sure you are right, it could be bootstrapped from the upper 32K of an EEPROM or such.
What I have in mind is a set up where ones entire application is written in C and PASM without ever having to see one line of Spin in the applications source code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Jealous?
It is this lurker's opinion that the best content on the propeller forum are the long threads. They are interesting in the here-and-now and are also historically significant in that they enable late arrivals like me to come up to speed without asking the same questions all over again. At times a conversation may be between just two individuals (or even sequential posts from the same person), but it is obvious by the view stats that very many more are tuning in.
I never miss a Zog installment because it's a fascinating, evolving story. Same with pullmoll's many adventures. What would the forum be without these interesting, inspiring, ongoing sagas?
[noparse][[/noparse]Edited for readability]
Post Edited (K2) : 4/20/2010 4:25:39 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Sadly, CPM running on the Z80 emulator offers a pre ANSI C89 compiler although if I really had to use it I could since I have a copy of the original K&R book that specifies it, and have programmed with it long ago when I had no choice (system bugs, kernel core dumps, and all the rest).
But more than the tools available, I'm not inclined to go that far back in time when WordStar was the dominant consumer word processor ... ya I used that too. I love Vi which has been around even longer, but it is a programmer's editor, and it has matured like good Cabernet rather than Thunderbird or MD 20/20. I do love Marlborough Sauvignon Blanc though; it is a timely fresh product.
Actually, If parallax gave the Z80/CPM emulators their own forum, that would promote them in a way that would draw even more like-minded people and further propagate something for which I have no use [noparse]:)[/noparse] Then all the Z80 CP/M fans could all subscribe to that forum and not be bothered by "why is my program broke?" posts. It would also be great marketing for Parallax I think ... especially if someone was able to emulate and atMega16 for example which may be difficult, but it would add more impact to the Propeller value proposition.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
The truth is no matter how fast the Prop can run Z80/ZOG/VM instructions, it is not going to make much difference in Parallax's bottom line. Parallax makes, I don't know, $5 per chip sold, what the heck, a nice figure. You count how many people working for Parallax, plus marketing, plus R&D, and it's going to be a lot of Propeller needed to make that happen.
Obviously Parallax's strength has been in the educational market.
Obviously Parallax thinks about PMC will get them into the edu market with the Propeller.
I am of the opinion that the general embedded market is a bigger market.
However, neither PMC, or my side comment about the emulators, help in either case of the edu market or the embedded market.
Again, I am not telling people not to work on emulators, but just saying things as I see them.
I don't really understand where Parallax is coming up with the lack of C support on the Prop is hurting their share in the education market. Not only are there two C compilers, but there's also CSpin - which seems to be exactly what Parallax is suggesting, just more hampered. To reinvent the wheel is not just a waste of money, but time as well.
If I had to make an educated guess on why the Propeller might have a bit of a hard time gaining traction in the education market, it would have more to due with how unconventional it is, rather than it's lack of C support. It has a significantly different architecture than the most common microcontrollers, which might make using it as a learning tool a bit hard to justify to educators. If there is any market the Propeller should be targeting, it should be the professional market - engineers with experience. If only more developers really knew how much easier it is to implement certain functionality in the Prop over more typical MCUs, and exploit it's use in the consumer electronics arena for marketing purposes, I think the Prop, and Parallax would be in a better position today.
What happened? What is the new, internal posture on PMC? Which direction will the project take?
You asked for input ... and you certainly got it! Again, as I type there are 9 pages in this thread, ranging all over the project-space map. I, for one, am surprisingly curious what the internal outcome of all of this hullaballoo is.
Please share.
t++
[noparse][[/noparse]Edited to fix the time stamps]
Post Edited (tmaynard) : 4/19/2010 11:33:19 PM GMT
Writing a (subset of) C to Spin translator is probably worthless for a) reasons of execution speed and b) not allowing to easily port existing C source to that limited subset.
I'd rather see a Catalina like approach or Catalina itself integrated into the Propeller tool as an alternative to generate PASM object code in either the small memory model (cog only code) or large memory, i.e. LMM method. That way a costumer would get what he expects from writing code in C: decent speed. PASM should be possible as inline assembler code for the cases where it needs the maximum possible speed.
You could even support Spin with C source code in the DAT section that way, allowing customers to write faster code without having to learn PASM first.
The compiler should be accompanied by a library with (most important) code to interface Spin or external PASM methods. That would most probably involve setting up a stack frame for the call somewhere in hub RAM. A function similar to execve(2) should be made available to call methods in an object. This way also something like a libc with standard i/o functions could be supplied and linked into code that requests it.
If you would then open source the compiler, some people might look into it and spend time on trying to optimize the compiler itself as well as the code it emits. This would benefit all users.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects