Cluso99 said...
@Ross: How many cog locations does the LMM interpreter require?
That's a difficult question to answer. It can be anywhere from 5 instructions to 496. It entirely depends on how fast you want your LMM applications to execute. When using LMM on the Propeller, "off-cog" operations are hideously expensive, so you naturally try and do as much within the cog as you can - this generally means as many LMM primitives as you can fit in. The LMM FCACHE option (which Catalina does not currently use) takes a slightly different approach to the same problem, reserving some of the on-cog space for a PASM instruction cache - but it is difficult for a compiler to use this effectively except in trivial "text book" type cases that rarely occur in the real world.
Catalina's "alternate" LMM kernel (the smallest, since it excludes floating point and XMM support) comes in around 400 longs. There are some inefficiencies in the kernel that I keep for selfish reasons (i.e. they simplify my life when debugging) such as the jump table. Eliminating these would save about 50 longs.
This kernel implements a set of primitives that is designed specifically to support an ANSI C compiler such as LCC. For any other application you would probably make completely different design decisions, and end up with a completely different kernel. I would include more "on cog" operations if I could, but I need the other 100 longs to implement floating point and XMM support - my XMM kernel actually uses slightly more than 496 longs on some platforms (it steals a few longs out of the special register space).
BTW, this is the reason why (despite many people calling for it) there will probably never be a "standard" LMM kernel. If you do so, your kernel would not be optimal for most applications - and the speed differences can be dramatic.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
1) I hope you are not taking the jealousy comment seriously. My apologies.
2) Please be clear that Zog is not an emulator. No more than one would call a Java virtual machine an emulator. Zog implements the ZPU virtual machine as designed by Zylin Inc. Also it has nothing at all to do with the Z80.
What Zog is is a way to run C code compiled with GCC on the Propeller. It does what PMC is proposed to do all be it with a different byte codes whilst supporting standards compliant C, C++ and FORTRAN. With a bit more tweaking and a following wind it will be almost up to the speed of Spin. Not bad compared to the PMC concept I would say. Well actually, I'd say it's better[noparse]:)[/noparse]
3) >> "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."
I agree. None of those will help much. However in my mind I include LMM kernels in the category of "virtual machines" and conclude that none of the available C compilers will help much.
Things will look different on the Prop II with lots more LMM space and LMM speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
tmaynard said...
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.
<=second time I've used an emoticon! It's a round-the-clock venture, to be honest. Work is well underway in Asia during as evening progresses in California, and if you stay up late enough our friends in Europe are ready to talk. We'll get our breaks for dinner and family, but chances are several of us will be right back at work (or fun, depending on the task).
Just wanted to check in to let you know that we're all reading this thread and considering parts of it for our next steps. And we'll come back with some details on those steps shortly, if you allow us a bit of time. We recognize the importance of tool contributions by our forum members and appreciate the detailed comments received on the Propeller IDE. We'll be putting these priorities in order and sharing them with you. Hopefully by tomorrow afternoon, too. I know you've had to wait before for other promises from us (I assume the guys in the Sandbox who want to buy the LED tape I found in Shenzhen component markets can wait a few more days in consideration of the Propeller's future). We need to make extra certain that our software developers support the plan.
We're not too corporate around here, as you know, but also very serious about planning the future of the Propeller.
Thank goodness you're still here! It's like one of those B-grade movies where despite the fact that everyone knows there's a monster lurking outside, they STILL insist on leaving the room one by one - until there's only two people left ...
Cluso?
Cluso?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I'm a little late to the party and I haven't read the whole thread, but I agree with Phil's comment back on the first page. I'd rather not see Parallax spend its precious resources making a C-like language. I'd rather see a fully-featured, multi-platform Propeller Tool. I'm grateful for bst, but it would be preferable to have that functionality come directly from Parallax.
An open-source Propeller Tool would be dreamy. Then Parallax' cadre of dedicated users could contribute to the product.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
@SSteve, regarding your last point [noparse][[/noparse]cut me a bit of slack here - I'm a bit of a mouthpiece unless Jeff joins the discussion]. We can open-source our current IDE, but it comes with burdens that render it not very "open". It has two licensed 3rd party components that can't be released as source and some assembler that only Chip understands. We've discussed a complete re-write in an open-source environment which would address many of the Prop IDE deficiencies identified in this forum, but it means waiting a lot longer to get some basic improvements. Many of the improvements (i.e., identifying sub-directories in the OBJ section) could be done in our current Delphi environment.
What would you like more - a question for anybody who wants to answer -
(a) professional Propeller IDE done in our current environment that includes the improvements you want, one at a time, or
(b) a stop to the progress as we re-write the whole IDE open-source in a development environment people can use, and eventually pick up where we are today with the features you request. This would include incorporating the greater team of developers. . . people on this forum.
I think you'd rather have (a) considering (b) really involves a reset to our efforts. Am I right? All of this open-source stuff is interesting, but I suspect most customers would simply prefer that we continue to develop our tools to be professional, even if they don't get the source (but as mentioned, we can release MOST of the source or our current IDE except for two licensed parts).
<pokes head round door> For goodness sake Ross. GET OUT OF THERE!!!
Why would Parallax want C on the propeller? To increase sales of the chip? But we already have C on the Propeller, in at least three or four different ways.
Perhaps it begs another question. My kids are teenagers and recently one has come home with a an electronics project. He didn't know what chip it was using but with some quick detective work looking at the pinout and chip number it was clear it was a Picaxe. Schools have limited budgets and if you want Basic on a chip for 30 kids you might choose a Picaxe. If you want C, probably an Arduino. The realities of the classroom are that one or two of those chips won't survive the lesson so cost per unit is important. And, as happened to my wife who is a teacher, there will always be one kid that sticks the wires in the power point and shuts down the school's electrical supply, blowing up the chip in the process.
Why isn't the Propeller in schools? I suspect it is because the Propeller hasn't yet made it into the many electronics print magazines that teachers and educators read. That can change and maybe one can think about a 'killer app' for a writeup in a magazine? I would be sure it would not be the emulations - they are for the true nerdy propellerheads. It probably is robotics and games. But before you can do that, you need to flash a led. From a teacher's point of view, you give the kids some boards and chips and instructions and if the instructions are clear you might get some flashing leds by the end of the 40 minute lesson. But the teacher might have to write the manual themselves, because reading the propeller manual, you have to get to page one hundred and eleven before you can flash that led.
For me, the strength of the propeller is not really the parallel nature of the chip, nor is it the simplicity of spin, nor the speed of pasm, nor the beauty of 32 bit instructions, nor Basic or C. No, the best bit is the code already written in the Obex. Think about the things the prop can do that users of other micros keep asking for? SD card access. VGA display. Keyboard. Multiple serial ports with buffers. Audio synthesis.
I have been pondering a propeller sales pitch to someone who writes magazine articles (the same person who is writing up the RF modules that do my inter-propeller file transfers). I think an article would not be about spin or pasm (or C or Basic for that matter). I think it would be about how to glue together the objects in the Obex. How do you read a byte from a serial port, put it on a screen, open a file, save it to an sd card and close the file. That might only be 10 lines of actual code.
The next question - what language would you write those 10 lines in? I think it would be a backwards step to not be able to drop in any/all obex code, as I think this is the main strength of the propeller. But Spin is a new language - would that put people off reading any further? I don't know - maybe this thought process leads to a glue language that could be C or could be Basic or it could be Spin. The compiler would sort out := vs == vs =
C on the propeller is part of the equation but given it already exists, I think the issue is to package it up right rather than reinvent it.
I'm not sure I have all the answers here, but as an aside I'm thinking about ways to get Prop articles in the print media and onto sites like Instructables/Make magazine etc.
For dev tools, open source is only a benefit if we don't get all the features we want and have to add them ourselves. But each such customization renders any code written for the new tool incompatible with the official tool chain and unfit for inclusion in the OBEX. So I would say that the benefits of a complete, professional-level, albeit closed-source tool suite, far outweigh any that might be conferred by an open-source approach. It's important that there be a lingua franca version of Spin and assembly and that this be as complete and professional as possible. Throwing the dev tools out to the masses for customization will not accomplish this objective.
Open source needs the formality that has been established in the Linux community.
Just because programs are available to modify does not mean that every new idea
is as brilliant, insightful or useful as it's creator thinks.
The community here tends to play rather fast and loose, and that is a //good// great thing.
The possibility of creeping feature-itis would also take from the lean and mean tools
we currently have and bloat them until they appear to be Linux kernels.
This will lead to creative and insightful programmers being alienated because
their latest/greatest insight is not adopted. We need their whack ideas.
Open source would need very careful handling around here and special rules greater than the obex.
Yes, the tools need some expansion for platforms and features, but where to stop ?
heater said...
I...
2) Please be clear that Zog is not an emulator. No more than one would call a Java virtual machine an emulator. Zog implements the ZPU virtual machine as designed by Zylin Inc. Also it has nothing at all to do with the Z80.
What Zog is is a way to run C code compiled with GCC on the Propeller. It does what PMC is proposed to do all be it with a different byte codes whilst supporting standards compliant C, C++ and FORTRAN. With a bit more tweaking and a following wind it will be almost up to the speed of Spin. Not bad compared to the PMC concept I would say. Well actually, I'd say it's better[noparse]:)[/noparse]
...
I know ZOG is not Z80, but it emulates another CPU. You can split hair and say LMM is an interpreter or a VM but the truth of the matter is that ZOG is not designed, a priori, as a VM to support a language. It's designed as a CPU. It just so happened that one can realize an implementation of it in software, and in this case, Propeller PASM. It also happens to address one perceived need: the availability of GCC/G++.
LMM C is different. The goal for Propeller C and Catalina C was to get a C as native as possible to the Propeller. The semantic gap between LMM and PASM is far smaller than Propeller and ZOG.
If you have designed a CPU that closer match the Propeller's capability and then port GCC to that, that would be different in my mind.
Why does it matter? Consider the two positions that a Propeller evangelist can make:
1) "Oh yes, you can run FULL GCC/G++/GANT/... on the Propeller! Yes, you run it on top the ZOG virtual machine... ZOG? Oh, that's a CPU but I get it to run as a VM..." vs.
2) "Oh yes, you can run FULL GCC/G++/GANT/... on the Propeller. I have written a VM optimized for Propeller and ported GCC to that..."
The difference is subtle but the marketing presentation difference is immense. The former is a convenience of available resources.
I learn from comments on the open-source subject. My post may not be very professional, but neither are some of the OS (edited April 20th for clarity: OS is an acronym·I've incorrectly used·for open-source) releases I've seen. Some open-source claims feel like a cheese grater on my forehead. Our Prop IDE isn't totally "open" due to the environment and licensed components used to develop it. At this moment an OS release just doesn't do much to support developers - they can get what they need from us by asking or poking around on this forum (free on any legal stuff). A release of it only delays the improvements you want to the Prop IDE.
Thanks to BST and the developers on this forum we've got Mac, Linux and C too. The multi-platform/multi-language support for the Propeller is stable and improving every day. The end result gives people a number of choices.
I realize nobody is claiming we haven't shared anything in the past, but Parallax has shared long before it was fashionable. Andy spends years writing certain books, and they're useful for all kinds of processors beyond our own. The PDFs have always been free and Word docs are shared with translators. Our SX-Key was opened up upon request, and the SX Blitz protocol was published in full. The PBASIC tokenizer supported development of MacBS2 thanks to M. Konar.
Parallax will be making a number of OS releases and they shall be *complete* (BOMs with mfg/supplier sources, editable PCB files, source code, drawings). This is the only way we'd be proud of releasing any of our products under a Creative Commons license - in full. How can anybody actually build their own design from a portion of what they need? We'll share the whole package, and I'll make sure it's right. David Carrier is working through a list of 50+ products.
Back to the Prop IDE: I advocate first making our Prop IDE complete and professional with our current dev tools. . .and releasing it open-source at some point as long as it doesn't delay feature improvement. The OS release will be of limited value, but we'll do it anyway. Our top priority is a professional tool.
We will be posting our plan for Prop IDE improvements.
Thanks for reading, Ken
P.S. to Phil Pilgrim - you are welcome to post the PDF document you sent me on these forums. You may feel that you've already made your points here without it, too.
I think the thing holding up a wider acceptance of the Propeller is actually Spin itself. It's just too focused a language with _no_ applicability beyond the Propeller.
I think the Propeller could still make a bigger dent in the educational market. I personally would 1) promote PropBASIC, since it's very similar to PBasic (BS1/2 series), 2) come out with a Propeller-based HomeWork board (same form factor, maybe add more I/O headers, or not), and 3) come out with a version of "What's a Microcontroller" based on these this board. Then at least students would have a more linear growth progression, and learn/be taught a language that has some portability.
As for C on the Propeller, I would leave it as is and wait for the Prop2 if it will really add that much more functionality. There will just be more/better options available.
As for open sourcing everything? I don't know. I would, however, like to see the various compiler/loader/etc. tools released in commandline versions that would allow the use of whatever editor/ide I choose. It's already being done with Textpad/PropBASIC/Propellant over in the PropBASIC thread.
Ken Gracdy said...
P.S. to Phil Pilgrim - you are welcome to post the PDF document you sent me on these forums. You may feel that you've already made your points here without it, too.
Ken, thanks, but I think it would be redundant at this point. The forumistas are, by now, well-acquainted with my point of view -- all too acquainted, perhaps.
Wow, am I glad you guys are back! Did you just see a 1,000 foot tall ... ice-covered ... monst ... Oh, never mind!
The recent posts by Richard and Heater have raised an interesting point that is probably worth discussing while we're discussing C. Does anyone seriously believe there a particular need for GCC on the Propeller? I mean, GCC as distinct from any other C compiler. If so, why?
The reasons for ANSI C have been well explored, in this thread and others. Whether you agree with them or not, the reasons themselves are clear - compatibility with an existing code base, lots of code available (e.g. in text books, on the internet), no need to learn a new langauge, future-proof (C has been around for 40 years - what makes you think it's going to go away soon?) etc etc.
But GCC? The only reason I can think of for specifically wanting GCC over other C compilers is that if you have GCC you stand a chance of running Linux. This is because GCC incorporates non-standard extensions to the C language that are specifically required to compile Linux.
I know this is one of Heater's goals, and jazzed is a strong supporter of GCC as well (to be fair, I also would love to see it - but only because I'm a geek who loves that kind of thing!)
But is it a realistic goal? More importantly, is it a goal that Parallax should be putting money behind? We (we in these forums, I mean) might want to see it - but what about Parallax's real customers (I mean the the ones who will buy Propellers by the thousands, the tens of thousands, or the hundreds of thousands)? Do they want it? Would they pay extra for it?
The answer of course is a resounding NO!. Linux is a minority operating system in embedded applications. The majority operating system for any microcontroller is ... of course ... NO operating system at all! In any case, even on the Prop II Linux would be desperately short of RAM (actually, you couldn't run Linux - no MMU - but you might be able to run uClinux - I believe that on some platforms, a minimal uClinux system weighs in around 300kb). But there are other chips on which Linux can already be run - and run faster than the Prop II will be able to - even with all its cogs dedicated to the O/S and spinning madly. The Propeller architecture is just not geared (excuse the pun!) for this type of thing.
I would make a similar argument about C++, Java, Fortran, Ada, Objective-C and all the other things that come along with GCC. Yes, they would come - but they would all run equally badly. In fact, they would all run so badly that they would make the Propeller itself look bad.
I hear what you're thinking - this is a very similar argument to that which others use agianst C. "The prop architecture is not suited for it" etc etc. But there are (at least) two differences:
(1) We KNOW the mainstream embedded market wants C. But it does not want C++. It does not want Java. It does not want Linux. It does not want GCC at all - it just wants C.
(2) C is perfectly at home on the Prop - it runs quite happily on the Prop I, and will run even better on the Prop II - provided we don't cripple it by insisting it only runs at SPIN speeds or slower.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
>>> (1) We KNOW the mainstream embedded market wants C. But it does not want C++. It does not want Java. It does not want Linux. It does not want GCC at all - it just wants C. <<<
I think this only holds for some definitions of "embedded".
Parallax should make the PropTool more open, but not in the sense of OpenSource.
What I like to see is a form of PlugIns, so we can expand the PropTool without changing the soource code and recompiling.
What it needs:
1) Make the syntax highlighting scheme editable for every file extension.
2) Allow to pass the source thru an external preprocessor before starting the (internal) Spin compiler.
3) Allow to replace the internal Spin compiler with an external compiler (C, Basic, XSpin...).
4) Define an interface how errors of an external Preprocessor or compiler are feed back to the
IDE to open the right file and place the cursor at the error position.
5) Allow to use an external Propeller-Loader instead of the internal.
Your PMC then would just be integrated as an external preprocessor.
I've pleaded and cajoled for that kind of extensibility for a couple years now. But I haven't mentioned it lately, because I'm not so sure the community as a whole would benefit. It all comes down to what Standard Spin (the kind that gets into the OBEX) is supposed to look like. Obviously, every archive could include every preprocessor that is needed to compile the code. But that would get unwieldy in a hurry, since there's no end to what it might have to encompass: e.g. batch files, .exes, references to other preprocessors, or even Python interpreters. OTOH, one could submit only code that's already been run through the preprocessor. But that code is less likely to convey the programmer's thought processes and insight in creating it, which is important for those who want to modify the code. By contrast, macros and INCLUDE files have a pre-defined syntax and can be bundled in an archive without adding to confusion or glut. That's not to say that a macro processor built-into the IDE can't be a really powerful one. But I'm beginning to believe that it should be part of the tool itself, rather than something someone else adds on -- as much as I'd like for that someone to be me on occasion.
RossH: Is C++ really all that far removed from C? I mean seriously, when it comes down to the nuts and bolts of it (as in what actually ends up being spit out the backend) the main difference is some indirection tables. The only other things that truly involve significantly different output code are exception handling and RTTI. Most of C++ is just shorthand ways of doing things you can do in C with a lot more typing, and most of that is handled by the frontend of the compiler. I guess the real issue is that it's easier to write code that results in larger backend output. Not really because it's less efficient, but because it's actually doing more. Anyway, I for one would be happy to have a C++ compiler for my embedded stuff. [noparse]:)[/noparse] I realize that's impractical for the Prop1, but I expect I will get C++ on the Prop2.
Ken: I like the approach that it sounds like you are planning, where you continue to improve the existing tool and eventually release what you can to Open Source. I must add that I would love to take a stab at figuring out that assembly code "that only Chip understands". I've done a fair bit of figuring out assembly code that was lacking in any documentation or comments and was less than straight forward. [noparse]:)[/noparse]
Also, I like Ariba's suggestion of adding a plugin setup to the PropTool. It's kind of a "best of both" type thing. You guys have the official professional tool, and we get to add all our weird/cool stuff via plugins. [noparse]:)[/noparse] Plus if you like a particular plugin you could work out an arrangement to include it with the PropTool, so you gain features from the community in a way that doesn't impact you as much.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Kevin Wood said...
>>> (1) We KNOW the mainstream embedded market wants C. But it does not want C++. It does not want Java. It does not want Linux. It does not want GCC at all - it just wants C. <<<
I think this only holds for some definitions of "embedded".
It holds for a definition of embedded that Propeller would fit in
OK, lets say Parallax goes after the embedded market? Its direct competitors will be the like of PIC, CPU12, AVR, MSP430, very low end ARM and Cotex (most have much more memory than the Prop). All of which are (99%?) programmed in either C or asm.
The problem with ZOG or anything that want to jack up a Propeller to run Linux etc. is that you can buy a complete single board Linux server for $60-$150, with 2 megabytes or more of flash and gobs of RAM. That runs at 50 native megahertz or higher. Why would Propeller be interesting in that space? We sold a boatload of Fox boards a couple years ago with that spec. and the whole board is credit card size.
I still think a Standard C bytecode environment is the way to go. Heck, make it a C interpreter and you have even the best of both worlds. Will we do it? Probably not. May be even we make tons of money on PropII, then we can contemplate it to do it for PropI. Unless of course, someone else runs with the idea.
Kevin Wood said...
I think this only holds for some definitions of "embedded".
Yes, that's true. I'm talking overall volume here. Of course there are particular sections of the embedded market - say 20% - that DO use Linux. But Parallax will never make inroads into that particular part of the market with the Propeller. There are already many chipsets better suited to addressing that particular space - and they already fight over it.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
ImageCraft: I must insist. ZOG is not an emulator.
How can you emulate something that does not exist? There is not and has never been a ZPU processor that you can buy.
One would not think to call the Java virtual machine an "emulator". In both cases an instruction set architecture, and a compiler were designed and created hand in hand. All be it that in the case of the Java system a whole new language and compiler was designed whilst for the ZPU only the back end of an existing compiler was built.
In both cases, and in others like the PASCAL p-code system, there need not ever be any real hardware that directly implements the instruction set architecture.
Similarly the Spin byte code interpreter would not be called an "emulator".
Your comment that "ZOG is not designed, a priori, as a VM to support a language." Is simply not true. The ZPU architecture was designed, by Zylin Inc, precisely to be a 32 bit processor supporting C (primarily).
One of main goals was to be implementable in FPGA using as few logic blocks as possible. Hence it's simplicity. Performance was not a main goal of the ZPU design because it is targeted at management tasks in FPGA designs where the high speed, real-time work is done by other logic blocks on the FPGA design. The same thinking can be applied to the Propeller don't you think?
There are many incarnations of the ZPU, in Java, in C++, in VHDL and Verlog. Now in C and PASM. If you like you can make an FPGA design from it or use it on your Propeller. But IT does not exist.
Therefore ZOG is not an emulator.
>> "LMM C is different." Yes it is. But it's the same[noparse]:)[/noparse]
Correct me if I'm wrong but both ICC and Catalina are based on the idea of building a kernel that executes on the Prop that then executes the output of C compilers. In both cases the compilers are existing C compilers that have had there code generation back ends modified to emit code for the kernels that have been created.
Sounds the same as ZPU to me.
Of course LMM kernels and their "instruction sets" are Prop specific and designed for speed verses ZPU VMs which was originally designed for minimal size.
So your two options come down to:
1) "Oh yes, you can run FULL GCC/G++/GANT/... on the Propeller!
It runs slowly under a virtual machine similar to Spin. With Spin like performance.
2) "Oh yes, you can run FULL GCC/G++/GANT/... on the Propeller!
It runs slowly under a virtual machine. The VM makes good use of the Propeller instruction set so it's faster that 1)
Sadly, I think most professional shops would not be so happy with eiter option.
P.S. I know we are quibbling and mincing words here and at the end of the day there is a lot of lee way between "simulator", "emulator", "virtual machine", "interpreter" etc, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I agree with Phil here. I like the OBEX, and the trade-off with that is some level of control and compromise. Right now, it's really easy. You get the tool, and you do your stuff, and you can grab lots of objects to build with. Combining those is pretty darn easy. That's a big deal.
If some directives were added to SPIN, and I mean the absolute minimum, such that the more common problems of targeting multiple hardware configurations gets easy, I'm 100 percent for that being in the tool, and the tool being released some day, just as it is. I'm a big open computing advocate, but I have absolutely no worries over the state of things. If the Prop tool works as it does now, and has things added, that's a good thing. One thing about open computing is people will build tools, just because they want the tools!! That's what open computing is all about. There isn't anything about SPIN that isn't just golden. Really it's just needing a few extra things. That's a compliment and recognition for a great effort. (I wouldn't be here, if that effort didn't play out, and neither would a lot of people)
Not everybody is at that level, and I think I'm safe to add that not everybody who is at that level wants to be there. Sometimes easy is just easy.
I also strongly advocate some level of partnership. It can be very simple --handshake almost, where the more complex stuff gets some attention for those that need / want it. Some really great dev tools are part of the Propeller tool box, but one might not know that, or if they do, maybe it's just not "blessed", and that's a problem. I don't know.
What I do know is the design idea that the thing can be built in ways that keep people out of trouble is a damn good one. That's gonna irritate those that know enough to not require that idea be in place, but then again, being there means they are big kids and can do their own thing easily enough.
If keeping the core design idea of keeping it simple and clear, means some lesser C, frankly, I'm all for that. Having considered what I have read here (and you all are a perfectly fine bunch, brilliant and you need to know lots of people learn more than you will know reading and sometimes participating in your rantings), a partnership where "that other environment" can be built makes more sense now, as the core conflict can be managed that way. All Parallax needs to do is the very basic, enabling things and do so with the core philosophy in mind, letting the partner deal with things at a higher level.
Give that some thought. I think it makes a whole ton of sense, given the tensions all around. (and those are good tensions that come from passionate, articulate, and smart people getting after solutions, nothing more) Applying the Parallax "secret sauce" to SPIN + PASM is home turf. That's where the magic is, and it's a damn good thing. A few bits added / changed, will open the door for all sorts of other avenues and that puts all participants in a position of strength.
If it were me, that's how I would prefer to operate, because the boundary issues are clear, and where those are clear, the cost of navigating them is significantly less.
Whatever is done, give Prop II serious consideration. There will be two levels to the return. One is expanding the use of Prop I, and the other is building on that and expanding with Prop II. Because Prop I isn't going away, I'm giving serious weight to the idea of a partner arrangement, where the core things needed get done on Prop I, in a way that will be simple, clear and effective for Prop II. Only Parallax can do that, because the darn thing isn't done yet!
So then, Prop I is where the enabling solution is done. Add to SPIN, and make developing C possible and practical (such as it is on Prop I), and figure out the boundaries, and who will be helping with that.
It all gets done, some buzz happens (ideally), and it starts to take off. When Prop II hits, the C will shine for those willing and able to exploit it, while no harm is done to SPIN + PASM, each blown wide open with Prop II.
(goes to bed now, after prepping for some ugly systems software installation / configuration tomorrow, wishing I was hammering on the prop I brought with me for tomorrow night!!)
@Ken and others: Honest communication is always preferred to some expectation of "professional" communication, where the affair is so managed as to prevent screw ups. This is good, but there is a cost... That cost is building the relationships among the participants such that real value comes from it over the longer term. Yes, that's a wordy way of saying, "Don't change a thing!!". I've executed in similar fashion over the years, and I would not trade those relationships for anything.
@RossH: No I don't believe there is any pressing need for GCC as such.
What's all this talk of Linux here? If Linux/uCLinux ever runs on the Prop (or Prop II for that matter) it will ocupy the same space as CP/M on the Prop does now. An interesting curiosity, an academic exercise but basically useless.
@Roy Eltham: Strangely enough I have been compiling C++ to run under Zog on the Prop. Not sure how practical it might ever be but it does show it can be done. Just now I don't have the libs to go with it. Like not even string.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm aware of this proplem.
More open means always more diversification.
But the same problem comes also when the PropTool is OpenSource and there are modified versions of the PropTool.
Also now we have Spin code for BST or Homespun which not compiles on the PropTool because it uses expansions of this
compilers.
heater said...
What's all this talk of Linux here? If Linux/uCLinux ever runs on the Prop (or Prop II for that matter) it will ocupy the same space as CP/M on the Prop does now. An interesting curiosity, an academic exercise but basically useless.
Exactly this is it. If anyone thinks I did the Z80 emulation under the impression to use it for serious Propeller project development, you got me wrong. I did it to get acquainted with the Propeller itself and to test its capability and limits. Whenever I would begin a new project, I would of course use Spin (because I'm forced to use it) and PASM (as much as possible/useful), and I would suggest the same for anyone else. Emulation is a nice hobby, has a certain Aha-factor and that's about it.
Comments
That's a difficult question to answer. It can be anywhere from 5 instructions to 496. It entirely depends on how fast you want your LMM applications to execute. When using LMM on the Propeller, "off-cog" operations are hideously expensive, so you naturally try and do as much within the cog as you can - this generally means as many LMM primitives as you can fit in. The LMM FCACHE option (which Catalina does not currently use) takes a slightly different approach to the same problem, reserving some of the on-cog space for a PASM instruction cache - but it is difficult for a compiler to use this effectively except in trivial "text book" type cases that rarely occur in the real world.
Catalina's "alternate" LMM kernel (the smallest, since it excludes floating point and XMM support) comes in around 400 longs. There are some inefficiencies in the kernel that I keep for selfish reasons (i.e. they simplify my life when debugging) such as the jump table. Eliminating these would save about 50 longs.
This kernel implements a set of primitives that is designed specifically to support an ANSI C compiler such as LCC. For any other application you would probably make completely different design decisions, and end up with a completely different kernel. I would include more "on cog" operations if I could, but I need the other 100 longs to implement floating point and XMM support - my XMM kernel actually uses slightly more than 496 longs on some platforms (it steals a few longs out of the special register space).
BTW, this is the reason why (despite many people calling for it) there will probably never be a "standard" LMM kernel. If you do so, your kernel would not be optimal for most applications - and the speed differences can be dramatic.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
1) I hope you are not taking the jealousy comment seriously. My apologies.
2) Please be clear that Zog is not an emulator. No more than one would call a Java virtual machine an emulator. Zog implements the ZPU virtual machine as designed by Zylin Inc. Also it has nothing at all to do with the Z80.
What Zog is is a way to run C code compiled with GCC on the Propeller. It does what PMC is proposed to do all be it with a different byte codes whilst supporting standards compliant C, C++ and FORTRAN. With a bit more tweaking and a following wind it will be almost up to the speed of Spin. Not bad compared to the PMC concept I would say. Well actually, I'd say it's better[noparse]:)[/noparse]
3) >> "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."
I agree. None of those will help much. However in my mind I include LMM kernels in the category of "virtual machines" and conclude that none of the available C compilers will help much.
Things will look different on the Prop II with lots more LMM space and LMM speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just because you have a 1,000 foot ice-monster on your side doesn't mean you can be mean to the other children in the playground!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 4/20/2010 1:55:57 AM GMT
Just wanted to check in to let you know that we're all reading this thread and considering parts of it for our next steps. And we'll come back with some details on those steps shortly, if you allow us a bit of time. We recognize the importance of tool contributions by our forum members and appreciate the detailed comments received on the Propeller IDE. We'll be putting these priorities in order and sharing them with you. Hopefully by tomorrow afternoon, too. I know you've had to wait before for other promises from us (I assume the guys in the Sandbox who want to buy the LED tape I found in Shenzhen component markets can wait a few more days in consideration of the Propeller's future). We need to make extra certain that our software developers support the plan.
We're not too corporate around here, as you know, but also very serious about planning the future of the Propeller.
Thanks, Ken
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ken Gracey
Parallax Inc.
Follow me at http://twitter.com/ParallaxKen for some insider news.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Hmmm. One or the other of us seems to have brought this previously animated discussion to a grinding halt.
I wonder which of us it was? Do you think it might have been my mentioning Zog that scared everyone away?
HEY EVERYONE - COME BACK! ZOG IS NOT REAL - HE'S ONLY A COMIC BOOK CHARACTER! AND WHY ARE YOU ALL POINTING BEHIND ME?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Thank goodness you're still here! It's like one of those B-grade movies where despite the fact that everyone knows there's a monster lurking outside, they STILL insist on leaving the room one by one - until there's only two people left ...
Cluso?
Cluso?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
An open-source Propeller Tool would be dreamy. Then Parallax' cadre of dedicated users could contribute to the product.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
links:
My band's website
Our album on the iTunes Music Store
What would you like more - a question for anybody who wants to answer -
(a) professional Propeller IDE done in our current environment that includes the improvements you want, one at a time, or
(b) a stop to the progress as we re-write the whole IDE open-source in a development environment people can use, and eventually pick up where we are today with the features you request. This would include incorporating the greater team of developers. . . people on this forum.
I think you'd rather have (a) considering (b) really involves a reset to our efforts. Am I right? All of this open-source stuff is interesting, but I suspect most customers would simply prefer that we continue to develop our tools to be professional, even if they don't get the source (but as mentioned, we can release MOST of the source or our current IDE except for two licensed parts).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ken Gracey
Parallax Inc.
Follow me at http://twitter.com/ParallaxKen for some insider news.
Why would Parallax want C on the propeller? To increase sales of the chip? But we already have C on the Propeller, in at least three or four different ways.
Perhaps it begs another question. My kids are teenagers and recently one has come home with a an electronics project. He didn't know what chip it was using but with some quick detective work looking at the pinout and chip number it was clear it was a Picaxe. Schools have limited budgets and if you want Basic on a chip for 30 kids you might choose a Picaxe. If you want C, probably an Arduino. The realities of the classroom are that one or two of those chips won't survive the lesson so cost per unit is important. And, as happened to my wife who is a teacher, there will always be one kid that sticks the wires in the power point and shuts down the school's electrical supply, blowing up the chip in the process.
Why isn't the Propeller in schools? I suspect it is because the Propeller hasn't yet made it into the many electronics print magazines that teachers and educators read. That can change and maybe one can think about a 'killer app' for a writeup in a magazine? I would be sure it would not be the emulations - they are for the true nerdy propellerheads. It probably is robotics and games. But before you can do that, you need to flash a led. From a teacher's point of view, you give the kids some boards and chips and instructions and if the instructions are clear you might get some flashing leds by the end of the 40 minute lesson. But the teacher might have to write the manual themselves, because reading the propeller manual, you have to get to page one hundred and eleven before you can flash that led.
For me, the strength of the propeller is not really the parallel nature of the chip, nor is it the simplicity of spin, nor the speed of pasm, nor the beauty of 32 bit instructions, nor Basic or C. No, the best bit is the code already written in the Obex. Think about the things the prop can do that users of other micros keep asking for? SD card access. VGA display. Keyboard. Multiple serial ports with buffers. Audio synthesis.
I have been pondering a propeller sales pitch to someone who writes magazine articles (the same person who is writing up the RF modules that do my inter-propeller file transfers). I think an article would not be about spin or pasm (or C or Basic for that matter). I think it would be about how to glue together the objects in the Obex. How do you read a byte from a serial port, put it on a screen, open a file, save it to an sd card and close the file. That might only be 10 lines of actual code.
The next question - what language would you write those 10 lines in? I think it would be a backwards step to not be able to drop in any/all obex code, as I think this is the main strength of the propeller. But Spin is a new language - would that put people off reading any further? I don't know - maybe this thought process leads to a glue language that could be C or could be Basic or it could be Spin. The compiler would sort out := vs == vs =
C on the propeller is part of the equation but given it already exists, I think the issue is to package it up right rather than reinvent it.
I'm not sure I have all the answers here, but as an aside I'm thinking about ways to get Prop articles in the print media and onto sites like Instructables/Make magazine etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
-Phil
Be careful what you wish for, you might get it.
Open source needs the formality that has been established in the Linux community.
Just because programs are available to modify does not mean that every new idea
is as brilliant, insightful or useful as it's creator thinks.
The community here tends to play rather fast and loose, and that is a //good// great thing.
The possibility of creeping feature-itis would also take from the lean and mean tools
we currently have and bloat them until they appear to be Linux kernels.
This will lead to creative and insightful programmers being alienated because
their latest/greatest insight is not adopted. We need their whack ideas.
Open source would need very careful handling around here and special rules greater than the obex.
Yes, the tools need some expansion for platforms and features, but where to stop ?
Probably this side of lean and mean.
Thanks, Ken, for the reassurance and balance.
jack
I know ZOG is not Z80, but it emulates another CPU. You can split hair and say LMM is an interpreter or a VM but the truth of the matter is that ZOG is not designed, a priori, as a VM to support a language. It's designed as a CPU. It just so happened that one can realize an implementation of it in software, and in this case, Propeller PASM. It also happens to address one perceived need: the availability of GCC/G++.
LMM C is different. The goal for Propeller C and Catalina C was to get a C as native as possible to the Propeller. The semantic gap between LMM and PASM is far smaller than Propeller and ZOG.
If you have designed a CPU that closer match the Propeller's capability and then port GCC to that, that would be different in my mind.
Why does it matter? Consider the two positions that a Propeller evangelist can make:
1) "Oh yes, you can run FULL GCC/G++/GANT/... on the Propeller! Yes, you run it on top the ZOG virtual machine... ZOG? Oh, that's a CPU but I get it to run as a VM..." vs.
2) "Oh yes, you can run FULL GCC/G++/GANT/... on the Propeller. I have written a VM optimized for Propeller and ported GCC to that..."
The difference is subtle but the marketing presentation difference is immense. The former is a convenience of available resources.
Thanks to BST and the developers on this forum we've got Mac, Linux and C too. The multi-platform/multi-language support for the Propeller is stable and improving every day. The end result gives people a number of choices.
I realize nobody is claiming we haven't shared anything in the past, but Parallax has shared long before it was fashionable. Andy spends years writing certain books, and they're useful for all kinds of processors beyond our own. The PDFs have always been free and Word docs are shared with translators. Our SX-Key was opened up upon request, and the SX Blitz protocol was published in full. The PBASIC tokenizer supported development of MacBS2 thanks to M. Konar.
Parallax will be making a number of OS releases and they shall be *complete* (BOMs with mfg/supplier sources, editable PCB files, source code, drawings). This is the only way we'd be proud of releasing any of our products under a Creative Commons license - in full. How can anybody actually build their own design from a portion of what they need? We'll share the whole package, and I'll make sure it's right. David Carrier is working through a list of 50+ products.
Back to the Prop IDE: I advocate first making our Prop IDE complete and professional with our current dev tools. . .and releasing it open-source at some point as long as it doesn't delay feature improvement. The OS release will be of limited value, but we'll do it anyway. Our top priority is a professional tool.
We will be posting our plan for Prop IDE improvements.
Thanks for reading, Ken
P.S. to Phil Pilgrim - you are welcome to post the PDF document you sent me on these forums. You may feel that you've already made your points here without it, too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ken Gracey
Parallax Inc.
Follow me at http://twitter.com/ParallaxKen for some insider news.
Post Edited (Ken Gracey (Parallax)) : 4/20/2010 1:05:48 PM GMT
I think the Propeller could still make a bigger dent in the educational market. I personally would 1) promote PropBASIC, since it's very similar to PBasic (BS1/2 series), 2) come out with a Propeller-based HomeWork board (same form factor, maybe add more I/O headers, or not), and 3) come out with a version of "What's a Microcontroller" based on these this board. Then at least students would have a more linear growth progression, and learn/be taught a language that has some portability.
As for C on the Propeller, I would leave it as is and wait for the Prop2 if it will really add that much more functionality. There will just be more/better options available.
As for open sourcing everything? I don't know. I would, however, like to see the various compiler/loader/etc. tools released in commandline versions that would allow the use of whatever editor/ide I choose. It's already being done with Textpad/PropBASIC/Propellant over in the PropBASIC thread.
-Phil
Wow, am I glad you guys are back! Did you just see a 1,000 foot tall ... ice-covered ... monst ... Oh, never mind!
The recent posts by Richard and Heater have raised an interesting point that is probably worth discussing while we're discussing C. Does anyone seriously believe there a particular need for GCC on the Propeller? I mean, GCC as distinct from any other C compiler. If so, why?
The reasons for ANSI C have been well explored, in this thread and others. Whether you agree with them or not, the reasons themselves are clear - compatibility with an existing code base, lots of code available (e.g. in text books, on the internet), no need to learn a new langauge, future-proof (C has been around for 40 years - what makes you think it's going to go away soon?) etc etc.
But GCC? The only reason I can think of for specifically wanting GCC over other C compilers is that if you have GCC you stand a chance of running Linux. This is because GCC incorporates non-standard extensions to the C language that are specifically required to compile Linux.
I know this is one of Heater's goals, and jazzed is a strong supporter of GCC as well (to be fair, I also would love to see it - but only because I'm a geek who loves that kind of thing!)
But is it a realistic goal? More importantly, is it a goal that Parallax should be putting money behind? We (we in these forums, I mean) might want to see it - but what about Parallax's real customers (I mean the the ones who will buy Propellers by the thousands, the tens of thousands, or the hundreds of thousands)? Do they want it? Would they pay extra for it?
The answer of course is a resounding NO!. Linux is a minority operating system in embedded applications. The majority operating system for any microcontroller is ... of course ... NO operating system at all! In any case, even on the Prop II Linux would be desperately short of RAM (actually, you couldn't run Linux - no MMU - but you might be able to run uClinux - I believe that on some platforms, a minimal uClinux system weighs in around 300kb). But there are other chips on which Linux can already be run - and run faster than the Prop II will be able to - even with all its cogs dedicated to the O/S and spinning madly. The Propeller architecture is just not geared (excuse the pun!) for this type of thing.
I would make a similar argument about C++, Java, Fortran, Ada, Objective-C and all the other things that come along with GCC. Yes, they would come - but they would all run equally badly. In fact, they would all run so badly that they would make the Propeller itself look bad.
I hear what you're thinking - this is a very similar argument to that which others use agianst C. "The prop architecture is not suited for it" etc etc. But there are (at least) two differences:
(1) We KNOW the mainstream embedded market wants C. But it does not want C++. It does not want Java. It does not want Linux. It does not want GCC at all - it just wants C.
(2) C is perfectly at home on the Prop - it runs quite happily on the Prop I, and will run even better on the Prop II - provided we don't cripple it by insisting it only runs at SPIN speeds or slower.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 4/20/2010 6:59:07 AM GMT
I think this only holds for some definitions of "embedded".
What I like to see is a form of PlugIns, so we can expand the PropTool without changing the soource code and recompiling.
What it needs:
1) Make the syntax highlighting scheme editable for every file extension.
2) Allow to pass the source thru an external preprocessor before starting the (internal) Spin compiler.
3) Allow to replace the internal Spin compiler with an external compiler (C, Basic, XSpin...).
4) Define an interface how errors of an external Preprocessor or compiler are feed back to the
IDE to open the right file and place the cursor at the error position.
5) Allow to use an external Propeller-Loader instead of the internal.
Your PMC then would just be integrated as an external preprocessor.
Andy
I've pleaded and cajoled for that kind of extensibility for a couple years now. But I haven't mentioned it lately, because I'm not so sure the community as a whole would benefit. It all comes down to what Standard Spin (the kind that gets into the OBEX) is supposed to look like. Obviously, every archive could include every preprocessor that is needed to compile the code. But that would get unwieldy in a hurry, since there's no end to what it might have to encompass: e.g. batch files, .exes, references to other preprocessors, or even Python interpreters. OTOH, one could submit only code that's already been run through the preprocessor. But that code is less likely to convey the programmer's thought processes and insight in creating it, which is important for those who want to modify the code. By contrast, macros and INCLUDE files have a pre-defined syntax and can be bundled in an archive without adding to confusion or glut. That's not to say that a macro processor built-into the IDE can't be a really powerful one. But I'm beginning to believe that it should be part of the tool itself, rather than something someone else adds on -- as much as I'd like for that someone to be me on occasion.
-Phil
Ken: I like the approach that it sounds like you are planning, where you continue to improve the existing tool and eventually release what you can to Open Source. I must add that I would love to take a stab at figuring out that assembly code "that only Chip understands". I've done a fair bit of figuring out assembly code that was lacking in any documentation or comments and was less than straight forward. [noparse]:)[/noparse]
Also, I like Ariba's suggestion of adding a plugin setup to the PropTool. It's kind of a "best of both" type thing. You guys have the official professional tool, and we get to add all our weird/cool stuff via plugins. [noparse]:)[/noparse] Plus if you like a particular plugin you could work out an arrangement to include it with the PropTool, so you gain features from the community in a way that doesn't impact you as much.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
It holds for a definition of embedded that Propeller would fit in
OK, lets say Parallax goes after the embedded market? Its direct competitors will be the like of PIC, CPU12, AVR, MSP430, very low end ARM and Cotex (most have much more memory than the Prop). All of which are (99%?) programmed in either C or asm.
The problem with ZOG or anything that want to jack up a Propeller to run Linux etc. is that you can buy a complete single board Linux server for $60-$150, with 2 megabytes or more of flash and gobs of RAM. That runs at 50 native megahertz or higher. Why would Propeller be interesting in that space? We sold a boatload of Fox boards a couple years ago with that spec. and the whole board is credit card size.
I still think a Standard C bytecode environment is the way to go. Heck, make it a C interpreter and you have even the best of both worlds. Will we do it? Probably not. May be even we make tons of money on PropII, then we can contemplate it to do it for PropI. Unless of course, someone else runs with the idea.
Yes, that's true. I'm talking overall volume here. Of course there are particular sections of the embedded market - say 20% - that DO use Linux. But Parallax will never make inroads into that particular part of the market with the Propeller. There are already many chipsets better suited to addressing that particular space - and they already fight over it.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
How can you emulate something that does not exist? There is not and has never been a ZPU processor that you can buy.
One would not think to call the Java virtual machine an "emulator". In both cases an instruction set architecture, and a compiler were designed and created hand in hand. All be it that in the case of the Java system a whole new language and compiler was designed whilst for the ZPU only the back end of an existing compiler was built.
In both cases, and in others like the PASCAL p-code system, there need not ever be any real hardware that directly implements the instruction set architecture.
Similarly the Spin byte code interpreter would not be called an "emulator".
Your comment that "ZOG is not designed, a priori, as a VM to support a language." Is simply not true. The ZPU architecture was designed, by Zylin Inc, precisely to be a 32 bit processor supporting C (primarily).
One of main goals was to be implementable in FPGA using as few logic blocks as possible. Hence it's simplicity. Performance was not a main goal of the ZPU design because it is targeted at management tasks in FPGA designs where the high speed, real-time work is done by other logic blocks on the FPGA design. The same thinking can be applied to the Propeller don't you think?
There are many incarnations of the ZPU, in Java, in C++, in VHDL and Verlog. Now in C and PASM. If you like you can make an FPGA design from it or use it on your Propeller. But IT does not exist.
Therefore ZOG is not an emulator.
>> "LMM C is different." Yes it is. But it's the same[noparse]:)[/noparse]
Correct me if I'm wrong but both ICC and Catalina are based on the idea of building a kernel that executes on the Prop that then executes the output of C compilers. In both cases the compilers are existing C compilers that have had there code generation back ends modified to emit code for the kernels that have been created.
Sounds the same as ZPU to me.
Of course LMM kernels and their "instruction sets" are Prop specific and designed for speed verses ZPU VMs which was originally designed for minimal size.
So your two options come down to:
1) "Oh yes, you can run FULL GCC/G++/GANT/... on the Propeller!
It runs slowly under a virtual machine similar to Spin. With Spin like performance.
2) "Oh yes, you can run FULL GCC/G++/GANT/... on the Propeller!
It runs slowly under a virtual machine. The VM makes good use of the Propeller instruction set so it's faster that 1)
Sadly, I think most professional shops would not be so happy with eiter option.
P.S. I know we are quibbling and mincing words here and at the end of the day there is a lot of lee way between "simulator", "emulator", "virtual machine", "interpreter" etc, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If some directives were added to SPIN, and I mean the absolute minimum, such that the more common problems of targeting multiple hardware configurations gets easy, I'm 100 percent for that being in the tool, and the tool being released some day, just as it is. I'm a big open computing advocate, but I have absolutely no worries over the state of things. If the Prop tool works as it does now, and has things added, that's a good thing. One thing about open computing is people will build tools, just because they want the tools!! That's what open computing is all about. There isn't anything about SPIN that isn't just golden. Really it's just needing a few extra things. That's a compliment and recognition for a great effort. (I wouldn't be here, if that effort didn't play out, and neither would a lot of people)
Not everybody is at that level, and I think I'm safe to add that not everybody who is at that level wants to be there. Sometimes easy is just easy.
I also strongly advocate some level of partnership. It can be very simple --handshake almost, where the more complex stuff gets some attention for those that need / want it. Some really great dev tools are part of the Propeller tool box, but one might not know that, or if they do, maybe it's just not "blessed", and that's a problem. I don't know.
What I do know is the design idea that the thing can be built in ways that keep people out of trouble is a damn good one. That's gonna irritate those that know enough to not require that idea be in place, but then again, being there means they are big kids and can do their own thing easily enough.
If keeping the core design idea of keeping it simple and clear, means some lesser C, frankly, I'm all for that. Having considered what I have read here (and you all are a perfectly fine bunch, brilliant and you need to know lots of people learn more than you will know reading and sometimes participating in your rantings), a partnership where "that other environment" can be built makes more sense now, as the core conflict can be managed that way. All Parallax needs to do is the very basic, enabling things and do so with the core philosophy in mind, letting the partner deal with things at a higher level.
Give that some thought. I think it makes a whole ton of sense, given the tensions all around. (and those are good tensions that come from passionate, articulate, and smart people getting after solutions, nothing more) Applying the Parallax "secret sauce" to SPIN + PASM is home turf. That's where the magic is, and it's a damn good thing. A few bits added / changed, will open the door for all sorts of other avenues and that puts all participants in a position of strength.
If it were me, that's how I would prefer to operate, because the boundary issues are clear, and where those are clear, the cost of navigating them is significantly less.
Whatever is done, give Prop II serious consideration. There will be two levels to the return. One is expanding the use of Prop I, and the other is building on that and expanding with Prop II. Because Prop I isn't going away, I'm giving serious weight to the idea of a partner arrangement, where the core things needed get done on Prop I, in a way that will be simple, clear and effective for Prop II. Only Parallax can do that, because the darn thing isn't done yet!
So then, Prop I is where the enabling solution is done. Add to SPIN, and make developing C possible and practical (such as it is on Prop I), and figure out the boundaries, and who will be helping with that.
It all gets done, some buzz happens (ideally), and it starts to take off. When Prop II hits, the C will shine for those willing and able to exploit it, while no harm is done to SPIN + PASM, each blown wide open with Prop II.
(goes to bed now, after prepping for some ugly systems software installation / configuration tomorrow, wishing I was hammering on the prop I brought with me for tomorrow night!!)
@Ken and others: Honest communication is always preferred to some expectation of "professional" communication, where the affair is so managed as to prevent screw ups. This is good, but there is a cost... That cost is building the relationships among the participants such that real value comes from it over the longer term. Yes, that's a wordy way of saying, "Don't change a thing!!". I've executed in similar fashion over the years, and I would not trade those relationships for anything.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 4/20/2010 8:35:28 AM GMT
What's all this talk of Linux here? If Linux/uCLinux ever runs on the Prop (or Prop II for that matter) it will ocupy the same space as CP/M on the Prop does now. An interesting curiosity, an academic exercise but basically useless.
@Roy Eltham: Strangely enough I have been compiling C++ to run under Zog on the Prop. Not sure how practical it might ever be but it does show it can be done. Just now I don't have the libs to go with it. Like not even string.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
I'm aware of this proplem.
More open means always more diversification.
But the same problem comes also when the PropTool is OpenSource and there are modified versions of the PropTool.
Also now we have Spin code for BST or Homespun which not compiles on the PropTool because it uses expansions of this
compilers.
Andy
Exactly this is it. If anyone thinks I did the Z80 emulation under the impression to use it for serious Propeller project development, you got me wrong. I did it to get acquainted with the Propeller itself and to test its capability and limits. Whenever I would begin a new project, I would of course use Spin (because I'm forced to use it) and PASM (as much as possible/useful), and I would suggest the same for anyone else. Emulation is a nice hobby, has a certain Aha-factor and that's about it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects