In particular, I'm genuinely curious as to where Chip has arrived on LMM and threading on Prop II. IMHO, that realization being known for Prop II is a big step up. It would be great to get the summary of that interaction posted somewhere, if interested onlookers can't listen in! (And yes, I would love to participate to listen and learn, and won't be trouble.)
One suggestion: No matter what path is taken, please insure that the full functionality is supported old school command line, STDOUT, STDIN, STDERR used as intended. All output needed for a GUI to interact with the system can be sent through those channels, allowing "GUI as wrapper" kind of development, which will enable those that prefer this and that to do what they will with no real worries. If desired, one GUI / IDE can be supported. Once the core tools are done, support would likely move up the chain some, dealing with changes at the higher level of abstraction. There are strong benefits to that as well, with a primary one being the support at the higher levels of abstraction being smaller in scope, because the tool chain build process is compartmentalized. In the SGI case, it was often that a revision to the overall environment did not ever touch the core tools. Naturally, that would be useful in this space, due to the wide variety of approaches. This would be a very positive differentiator, IMHO. Very easily positioned as open, as well as accessable, and practical, stable.
SGI, for one example, did this on nearly all of their OS tools, providing a verbose (-v), and in some cases really verbose (-vv) options that would stream the input and output needed for GUI interaction. A few other cases might require a input mode or two be specified as well. Everything done that way is scriptable, and "packagable" for the most part, and by nature, cross platform, as windows32/64, Linux, Unix all do the STDIN, STDOUT, STDERR thing nicely enough. All the basic OS functions, pipes, redirection, work well too.
If the core dev tool chain is done this way, it will serve as a foundation for whatever GUI / IDE type projects make sense, including this one. Most importantly, it will also make small, dedicated build environments possible and practical as well. Could use DOS, if one wanted, or perhaps a stripped down single-user Linux, just by way of two examples.
IMHO, that's "pro" quality stuff. I've sure been around a lot of OSes, and core tools built that way never gave me one lick of trouble, because I always had options, and the building of things needed for automation was accessable, even to people of moderate skill. Please consider it.
If what I wrote is not clear, I am perfectly happy to work to convey this better.
I to am intrigued by what may be coming with respect to threading on Prop II.
My understanding from previous posts by Chip and all is that threads on COGs would allow a COG to more easily perform more than one time critical function at a time so as to avoid having to dedicate whole COGs to small functions. Perhaps you are wanting to combine a UART and a some other bit banging in a single COG say.
I got the impression that due to the way the Prop pipelines instructions it would be possible to interleave the instructions of at least two threads without slowing either one down.
Don't worry about the dev tools and the command line. If Parallax adopts GCC the compiler and other utilities are command line tools and are used in IDEs like Eclipse in just the way you describe.
I did mention earlier that perhaps they should look at LLVM as the tool chain instead of GCC. Now I don't know squat about either but one of the motivations behind LLVM is to have a compilation system that is easier to integrate into an IDE. I get the impressin that LLVM will overtake GCC at some point. There is a lot of enthusiasm for it in the compiler builder community.
What will happen to the Prop Tool and Spin is another matter. Will there be a command line, cross-platform, open source Spin compiler?
I did mention earlier that perhaps they should look at LLVM as the tool chain instead of GCC. Now I don't know squat about either but one of the motivations behind LLVM is to have a compilation system that is easier to integrate into an IDE. I get the impressin that LLVM will overtake GCC at some point. There is a lot of enthusiasm for it in the compiler builder community.
I think that looking at LLVM is definitely a good idea. It would be good to find someone with some experience creating backends for LLVM though. Do you know of anyone?
I don't think Ken was asking for a debate on languages and developer environments (although that is certainly in the scope of the forum). The implication of a LMM IDE that supports C, SPIN and other stuff has profound implications for the success of the new chip (especially if objects work across languages).
It seems to me that they have already made the important decisions. They have chosen languages and an environment and are seeking people to help them develop it.
Parallax wants to put on its suit and tie, polish its shoes and address the large scale commercial market. A move that I totally applaud. To that end Parallax will soon have a very competitive chip to offer in the Prop II.
As part of that strategy Parallax also needs to satisfy the "professional" developer whom it seems is incapable of living without C. This did not make much sense for the Prop I but is practical an essential for the Prop II and its successors. Also Parallax needs to offer a more professional IDE to accompany that C compiler. Note that the compiler and the IDE are separate items unlike the situation with the Prop Tool IDE and compiler combined.
For the compiler it makes sense to adopt an existing industrial strength compiler like GCC and adapt its back end code generation to the Propeller. Almost certainly generating LMM PASM code.
Again for the IDE it makes sense to adopt an existing industrial strength IDE like Eclipse.
It is essential that both compiler and IDE are open source and cross-platform at least Windows, Mac and Linux.
GCC is the obvious choice for the compiler. GCC already supports a myriad of devices: Intel, ARM, MIPs, PowerPC, AVR, ZPU etc etc etc.
Eclipse is a good choice for the IDE. It's big and bloated and slow but it is well received in the industry.
My only observation is that perhaps now is the time to look at LLVM as the C compiler which by all accounts is:
1) Easier to integrate with an IDE.
2) Easier to adapt for new targets like the Propeller
3) In some circles said to be the successor to GCC.
Now, I'm no compiler developer, that's just what are hear around.
So, to answer David Betz, no I do not really know anyone with LLVM experience except...Currently we run GCC compiled code on the Propeller using a ZPU processor simulator. That ZPU target for GCC was create by Zylin Inc. Zylin is in the process of switching to LLVM rather than redo their GCC work for the current version of GCC. As a small consultancy perhaps ZyLin might be interested in working with Parallax on LLVM for the Propeller.
That's why Microchip chose it over Eclipse, and to differentiate them from the competition which mainly uses Eclipse. They also got a great deal of support from Oracle. The current version of NetBeans needed some hacking to make it suitable for MCU development, so it would involve a lot of work for Parallax. The next version should work "out of the box", though. The user interface is much "cleaner" than Eclipse, making it easier to use.
Do you know which version Microchip used, and where on the time-line the MCU changes are ?
1) There seems to be a growing movement among open source compiler developers to move away from GCC and replace it with the Clang compiler front end and the LLVM (Low Level Virtual Machine) back end. Both of which are now included in the LLVM releases which are sponsored by Apple and released under a free software license. Of course the final generated code in the Propeller target would be real LMM PASM.
A good place to start researching Clang/LLVM is the wikipedia article where we read:
A quick glance at this, is interesting.
Some positives : Languages like Haskell are mentioned, and the idea of LLVM could suit Propellor nicely.
( Especially if Prop II allows HW support for QuadSPI memory access )
The thread has been moving to wrong direction from the very beginning. The very first thing to talk about is how to do C/C++ compilation for Propeller. Create a backend aiming bare Propeller from ground up? Not realistic, I think, due to architecture. Use another processor emulator, and use GCC for that processor? That sounds more realistic. Which processor? One of existing, or design a completely new one, optimized for higher performance when running in Propeller *MM mode? Or maybe, as already said, look at LLVM? I think these are the questions, not GUI, C#, Java, bells, whistles and other tambourines.
I think we may be confusing several issues here, and thereby risk jumping to incorrect conclusions. It's not clear to me that we even understand Ken's original post correctly yet. Ken's reference to GCC & Eclipse is leading us to make certain assumptions - but Ken himself admits his knowledge in this area is rudimentary.
Here are some questions I think it is worth exploring a bit more deeply before we go too much further:
1. Does Parallax want a single compiler suite to handle multiple languages, or do they just want a single development environment that can do so? The two are quite different, and it is not really clear from Ken's original post what is wanted. If the answer is the former, then GCC may be the logical choice. But if it is the latter, then Eclipse may still be a good choice, but GCC just becomes one of a number of compiler choices, alongside the current crop of SPIN and C compilers.
2. Do the languages supported have to include interpreted SPIN? If so, then again Eclipse may be a good choice - but does it make sense to try and compile SPIN with GCC? While it would certainly be possible to do so, we already have several perfectly capable SPIN compilers, so it seems a bit unnecessary. Developing a SPIN compiler in GCC would take more time than doing a simple C port, since you need a new front-end as well as a new back-end. To do both would require the development of (essentially) two different toolchains - i.e. SPIN currently compiles to SPIN byte codes, whereas C/C++ etc would have to compile to LMM PASM. This means you not only need two different front-ends but two different back-ends as well. The two could not even make much use of commonality in the middle-end (i.e. at the GIMPLE level) since it is not (in general) possible to link the two types of object. Given the overheads involved, it really makes very little sense to allow other languages to call SPIN (or vice versa) anyway. This kind of thing would make more sense if Parallax intends to offer compiled SPIN alongside (or in place of) the current interpreted SPIN. Or perhaps interpreted SPIN on the Propeller 1 and compiled SPIN on the Propeller 2?
3. So are there always going to to be two separate development toolchains? This is certainly implied by Ken's post, where he indicates that the Windows Propeller tool will be developed anyway. Perhaps the idea is to offer SPIN for hobbyist use and GCC / Eclipse for professional use?
4. What other languages (other than C, SPIN and PASM) does Parallax want to offer? C++? Objective-C? Java? Fortran? Ada? If the answer is 'yes' to any of these, then GCC may be a good choice. But who would be the intended users of these languages? It would certainly not be the professional users that Parallax Semiconductor needs to attract - they will generally only be interested in C (and PASM). They certainly won't want SPIN. Some of the other languages I mentioned may appeal to the customers of Parallax (like us!) but they will probably not appeal to the customers of Parallax Semiconductor (who are the people this new toolset is supposed to be aimed at).
5. Is Parallax prepared to face the inevitable direct comparison with various microprocessors (rather than microcontrollers)? Let's face it - all stack-oriented languages (including SPIN) will perform poorly on the Propeller 1 and 2 microcontrollers when compared with just about any single core microprocessor costing about the same. In some ways, adding more languages just gives people more opportunity to do very simple benchmarks that will apparently show the Prop up poorly - because this is not what the Propeller was designed for, and none of these languages are designed to take advantage of the Propeller's unique features. I'm not suggesting Parallax should abandon the idea of supporting other languages - I'm a strong supporter of the idea, since SPIN is never going to gain widespread acceptance. What I'm suggesting is that while Parallax has to offer C, they don't have to offer anything else to be taken seriously in the professional semiconductor market. If (for example) they offer the full suite of languages supported by GCC then the first thing that will happen is that users will try loading Java or C++ programs that make extensive use of the bloated language libaries, and complain when they can't fit the resulting binary into the on-board 128k. Or they will try to add a GB or two of XMM RAM and port Linux, then complain when it takes 15 minutes to boot (Actually, it probably won't be professional users who do this - they would have more sense - it is more likely to be us! ). Perhaps Parallax should instead concentrate specifically on offering a version of C that fully inter-operates with SPIN and which encourages users to take full advantage of the unique capabilities of the Propeller. Then the Propeller will shine in any comparison with its competitors, rather than ending up looking like a bit of an 'odd duck'.
If we could get some clarity on these points, then perhaps we can have a more informed debate about the various merits of particular compilers and development environments.
Perhaps the idea is to offer SPIN for hobbyist use and GCC / Eclipse for professional use?
That would be a tragic mistake. It's fine to lure the corporate customer in with C or its variants. But Spin will always be the language of choice for RAD (Rapid Application Development). Once a customer has been hooked with C, reeled in to the boat, and netted, they can be persuaded that their time-to-market will be minimized by committing their resources to (an improved version of ) Spin.
I agree the thread has gotten off base.
I think all Ken is looking for is some individuals who have knowledge in GCC / Eclipse to
start brainstorming what, how and if a proptool II using that would be a good choice.
Instead everyone seems to want to turn Prop into a microcomputer and compete with Intel processors
running things that do not fit the architecture of Prop I or II.
It even sounded for awhile where running the many megabyte dot net run time in each of the 8 cogs by paging it
in was desired. I can guess how slow that would be LOL.
I can see a C syntax language but not even the entire standard C lib. I like curly brackets instead of indentation.
It is a microcontroller.
I restate my comment that a propellent.dll and propellent.exe for Prop II are the way to go and give everyone something
to wrap a proptool around. Dot net whatever would be good at that. Add a version of each of those that understands C
syntax instead of Spin would also be good. I am not even sure you would need obj and lib files either just keep it simple.
I think the programming principle of KISS needs to be followed, Keep It Simple Stupid.
Get Prop II off the ground with a basic editor using a propellent.dll or exe which contains the compiler and assembler.
One that Parallax controls and trusts.
Also I think Ken would be interested in another thread on just what other than editing,compiling and downloading would
be desired in a new IDE. Then people can brainstorm if implementing a given idea is even possible.
If we could get some clarity on these points, then perhaps we can have a more informed debate about the various merits of particular compilers and development environments.
All of this will be hashed out over the coming weeks I'm sure.
Posts like yours and others here are very helpful for talking points.
I don't plan to say much in this thread/forum as this is part of my "humble service" to Parallax Semiconductor. Lots of things need to be discussed in a private setting with the principal stake holders (Parallax) and those of us they have called upon to participate (including distant on-line contributors).
I will say that it is a very positive step that Ken and others in Parallax understand the need to step up to expectations beyond that of small developers/business owners and hobbyists. This is intended as a solutions oriented statement because Propeller revenue growth depends on larger customers adopting the technology. As someone once said "A rising tide lifts all boats." Hopefully Parallax Semiconductor can attract enough customers to make the tide rise.
a) I read one branch as 'Adding GCC' - which ~means "swallow most C libraries" that are out there.
It may be that C# is a better 'fit', but embedded developers are mostly glued to C.
On the Prop, this will be a challenge, given the memory splits chosen. Classic printf spaggeti, is not going to make sense.
So this may split into two further branches: What I will call COG Ram compiler, and Interpreted Compiler.
One is very limited, but a common syntax at least make moving between the two easier, and code easier to maintain.
For the simplest (most code constrained) cores, I like the HLA concept. This extends Assembler with Block structures, so you
shift from 'label soup', to more conventional HLL looking source, but are still working at ASM level. http://en.wikipedia.org/wiki/High_Level_Assembly
b) I also read it as the other branch being 'Adding Debug', which is a quite different problem.
You can craft debug support to be almost language agnostic (and for the Prop, that is likely a good idea).
We created a file format, that made Debug totally Language agnostic, by massaging the Source(s), Linker MAP info, and the Object File Line#info, and creating a new 'Source file', with absolute addresses in the first columns in hex. This file is also a great project report, as it has the source, and the memory map in one file It is self documenting, and can easily support mixed languages.
(0123) This line is Starts at Abs Address 0123
(----) This line has No Associated Address
Then, during STEP/BREAK etc, the Debug IDE, looks for the nearest address before the known disASM address.
Watch variables, are extracted from the preamble MAP listing, and the Debug IDE gives a choice of watch formats, but always ALL memory is 'inspectable'.
The challenges with any debug, are getting enough bandwidth into the Silicon, and making the Debug Stub as invisible as possible to the users code.
That is why silicon support is very important, as it can make a huge difference to both 'invisible' and bandwidth.
I think all Ken is looking for is some individuals who have knowledge in GCC / Eclipse to start brainstorming what, how and if a proptool II using that would be a good choice.
All this talk of C# and .NET has made for a stressful weekend, so I sincerely hope you're right. Unfortunately, this thread seems to have unleashed a pent-up appetite in quarters that are more comfortable with mega-source-line PC projects to chain Prop family dev tools to big-iron frameworks. My gut fear is that that the lean elegance of the Prop's architecture and its capacity for rapid application development will be subsumed by a briar patch of unnecessary complexity. I desperately want to be proven wrong before the sheer joy of programming the Propeller is sacrificed to ambitions that could ultimately be detrimental to its success.
As a disclaimer, I have to stress, as I've said for years: I do want Spin to be a better language, and I do want a better IDE. But I think Parallax needs to cast a wider net before the forces manifest in this thread are given full rein to create our next dev tool chain.
All this talk of C# and .NET has made for a stressful weekend
I think you can at least rest easy on that score, Phil.
It seems very unlikely that C# and .NET will ever run on the Propeller - Microsoft's .NET Micro Framework (NETMF) requires more than twice as much RAM as the Prop 2 is expected to have, and even so it does not support the whole of the C# language (this is very analogous to the Arduino claims to support C++ but only implemening a subset - and likely for very similar reasons). See http://thing1.windowsfordevices.com/articles/AT9185657281.html for more details on NETMF. Also note that NETMF is neither real-time nor deterministic (which makes you wonder what the heck it is intended for???).
It must blow these guys away when they see what we can already do on a Prop I with only 32k of RAM (let alone what we will be able to do with the Prop II !)
I think you must misunderstand my intentions. My primary goal would be to make the official Prop Tool Parallax provides be better and cross platform. My favored method is .NET, but if that's not how they want to go then fine. However, I think for most customers hobby or pro, a .NET solution works well. The reality is that the percentage of people that want linux or mac support is small, and most of them are fully capable and willing to do a minor extra install (if they haven't already) to get it working.
I'm not really a fan of getting yet another C/C++ working on the Prop 1, there are already solutions available. I know Parallax want it for the "professional" arena, and I support them with that. However, I will continue to use Spin & PASM on the Prop 1.
Maybe I'm stupid. I thought Kens objective statement was very clear. Parallax wants to target GCC at the Propeller and adopt Eclipse as the IDE.
To me "target" in this case means PASM Large Memory Model (LMM) as is the case for Catalina and ICC. Is there any way to do it that is not slower?
I simply suggested the LLVM C compiler may be a better candidate to create a PASM LMM target for. For reasons I have stated above.
NOTE: LLVM is not a virtual machine to run on the Prop or other CPU it generate real machine instructions.
Whilst the compiler is called Low Level Virtual Machine (LLVM) that is not to say that the generated code is intended to be run on a Virtual Machine interpreter like Java or C# on the target. No, LLVM is the intermediate form of the compiled C, C++ , ADA, etc etc code that is then used to generate real machine instructions from.
All this talk of C# .NET whatever on the Prop is gibberish. The run time is obviously too big, too slow, too abstracted from the hardware. We have Java run time on the Prop that demonstrates that already.
Parallax Semiconductor is interested in assembling a small team of developers familiar with the GCC compiler suite and perhaps the Eclipse plug-in. The objective is create an open-source cross-platform compatible compiler suite for Propeller 2 (code name) supporting Spin, C/C++ and possibly other languages. A GUI such as Eclipse would be customized to make use of the GCC optimizer.
There are several possible ways to interpret this pararaph - especially as Ken himself says later that his knowledge in this area is limited. Your interpretation is certainly possible, but is it likely, given that SPIN is mentioned in the above paragraph? It makes little sense to expend the effort required to make GCC compile SPIN, given that (a) there are already at least three good SPIN compilers available, and (b) the intended users of the proposed new toolchain probably won't be interested in SPIN anyway. This is why I think it is quite plausible to interpret this paragraph to mean that Parallax want a multi-language IDE (perhaps based on Eclipse) to replace the Parallax SPIN Tool, and are also considering GCC as one of the compilers that this IDE may invoke "behind the scenes". An existing SPIN compiler could be another. Existing C, Basic or Forth compilers could be invoked as well.
Of course, it would make sense to use a common compiler if all the languages shared a common back-end target (i.e. either LMM PASM or SPIN VM).
Hence my questions seeking to clarify these points.
Ken does mention LMM later in his post - but merely as being "encouraging". He does not say that LMM PASM is the intended target of the C/C++ compiler, or the SPIN compiler. It actually makes more sense to assume that Parallax is hoping to use GCC to generate SPIN VM byte codes for all the languages Ken mentions - which would be in keeping with the original "Parallax Micro C" proposal.
To me, Ken's post is as clear as mud, and we are all (including me) reading it coloured by our own preconceptions. I hope Ken clarifies it before we all go jumping off in different directions.
All this talk of C# .NET whatever on the Prop is gibberish. The run time is obviously too big, too slow, too abstracted from the hardware. We have Java run time on the Prop that demonstrates that already.
Hey! PropellerJVM running from EEPROM is faster than ZOG in some tests
Still running some kind of C# on Propeller is most likely impossible anyway.
I'm sure Ken will be happy to clarify his intentions, but it's obvious to me.
The way I see it is this for big time commercial users:
1) Create a GCC target for LMM PASM
2) Use Eclipse as the IDE for that.
3) Who cares what happens with Spin in this new "professional" world. Although perhaps Eclipse can also be adopted as the IDE for Spin programming.
Pretty much any other option does not make any sense to me which is why I thought the opening objective statement was clear.
The other options you have considered don't look attractive as you say:
A Spin byte code target for GCC is pointless, to slow. It's only advantage is perhaps that it becomes easier to link Spin and C. Who wants to do that?
Compiling Spin to LMM makes no sense. Spin is all about getting the most functionality into the smallest space. LMM will not do that.
Hmmm...What might a "professional" want to do in this Eclipse IDE?
1) Must be able to write code in C or even C++. The Arduino and my experiments show that C++ is quite a reasonable option if one uses it in a way appropriate for small systems. C++ has the massive advantage that it becomes possible to work in the same object based way as you do in Spin.
Note: "Object based" not "object oriented" I'm sure you know why.
Looks like LMM is the only way to do this with any speed.
2) Must be able to write PASM for high speed code loaded into COGS.
3) Must be able to work with that PASM code from C. Sorting out the loading and communication through HUB.
4) Must be able to make use of existing PASM "cogjects" that will have C/C++ wrappers to access them and just be pulled in from a library like any other C stuff.
Sounds like all that stuff you have tackled in Catalina already does it not? And in my small way with Zog where I have some "cogjects" with C++ wrappers.
5) Optional: If you really want to mix up Spin code with your C think about this:
To run Spin code you fire up a Spin interpreter in a COG. That is just the same as firing up one of those "cogjects" mentioned above.
That interpreter needs some byte code to run. Well that's just some data sitting in HUB that the interpreter cogject needs.
That bytecode needs some stack and data space to work in. Well that just part of the data are mentioned above.
So to run Spin code in your C program just compile the Spin to byte codes and have those byte codes turned into a blob suitable for linking in with your C. Just like any other data you might use in C. Perhaps the bytecodes are just turned into C source code as a constant array.
Now just fire up the interpreter cogject and point it at the byte code data.
BINGO you run Spin the same way as you run any other PASM object.
So perhaps the Eclipse IDE also needs to be able to edit and compile Spin programs whilst you are actually working on a C/C++ project. Using a different (existing) compiler NOT GCC.
I think Ken/Parallax want a professional toolchain that is cross platform and supports doing Spin/PASM and C code. They are wanting to appeal to professional embedded developers. I think that is why they mentioned (chose?) Eclipse/GCC. If there are other better/easier/preferred options I think they would be open to them. LLVM looks interesting, Netbeans seems to be another IDE option (that some may like better). Perhaps Ken has spoken with some of their larger business customers and gotten feedback from them which is influencing the Eclipse/GCC choice?
I think if they had a toolchain (command line compilers, etc.) that was cross platform and then provided configurations for Eclipse (and/or other IDEs), that would be probably the most appealing to the most users. Then the Prop Tool could be changed to use that toolchain and provide the easy user experience that exists with the Prop Tool now.
Also, I don't think it's unreasonable to think that a Prop 2 board with external SDRAM could run a .NET CLR. Although, I am not really sure how useful it would really be.
I think Ken/Parallax want a professional toolchain that is cross platform and supports doing Spin/PASM and C code.
Hi Roy,
Yes, it's fairly clear that that's what Parallax wants. But that doesn't make it sensible - or even feasible. And I think that's part of what we're supposed to discuss.
It's the inclusion of the word Spin that makes the whole thing uncertain. Take that word out and I would tend to agree with Heater's interpretation. Leave that word in, and I no longer agree - then, the most appropriate solution becomes a GCC toolchain that complies all languages to a common set of SPIN/C byte codes.
Yes, it's fairly clear that that's what Parallax wants. But that doesn't make it sensible - or even feasible. And I think that's part of what we're supposed to discuss.
It's the inclusion of the word Spin that makes the whole thing uncertain. Take that word out and I would tend to agree with Heater's interpretation. Leave that word in, and I no longer agree - then, the most appropriate solution becomes a GCC toolchain that complies all languages to a common set of SPIN/C byte codes.
I'm sure Ken will clarify eventually.
Ross.
I have a rather radical idea of how Spin could be included. Just like it is possible to retarget GCC to a new processor by writing a new backend code generator it is also possible to add a new frontend to support a different language. It is concievable that a Spin frontend could be written for GCC that would take Spin source code and compile it down into the intermediate language that drivers the GCC optimizer and backend. If a compatible ABI is chosen for Spin, that might make it possible to call Spin code from C or vice-versa. However, while I know people who have worked on GCC backends, I don't know anyone who has written a new language frontend and I don't know how well that process is documented. I'm sure it's possible though since the GNU Compiler Collection contains many different languages already.
then, the most appropriate solution becomes a GCC toolchain that complies all languages to a common set of SPIN/C byte codes.
I have to disagree. Compiling C down to Spin bytecodes is just going to be slow and horrible. A terrible price to pay for easy linkage between Spin and C modules. Didn't we learn that from the Zog VM for zpu-gcc?:)
The C compiler should compile to LMM PASM like Catalina and ICC for speed. It should also be able to make use of code in external RAM (XMM) which will be much easier to connect to Prop II and faster.
In future Props there will be even more HUB RAM or even better external RAM interfaces. LMM PASM will serve those future devices well.
In this scenario I want one to imagine that Spin becomes a so called "embedded language". Not to be confused with "embedded systems". That is to say that is a language that one can embed in ones C applications. A good example of such a language is Lua. Which is often used to give user scripting abilities to programs otherwise written in C/C++.
Here a Spin byte code interpreter is used from a C app to run a Spin byte code program in some kind of "context" (Basically some memory the bytecodes and data live in with an interface API to let the C code manipulate and interact with it.
I have a rather radical idea of how Spin could be included. Just like it is possible to retarget GCC to a new processor by writing a new backend code generator it is also possible to add a new frontend to support a different language. It is concievable that a Spin frontend could be written for GCC that would take Spin source code and compile it down into the intermediate language that drivers the GCC optimizer and backend. If a compatible ABI is chosen for Spin, that might make it possible to call Spin code from C or vice-versa. However, while I know people who have worked on GCC backends, I don't know anyone who has written a new language frontend and I don't know how well that process is documented. I'm sure it's possible though since the GNU Compiler Collection contains many different languages already.
Hi David,
I considered this in my post #70. As you say, retargetting the back-end of GCC is a well worn path that has been followed many times - but writing a new front-end is a whole 'nother ball game.
However, while I'm sure it's possible (and would certainly assist in the sharing of data and name spaces between the two languages), is it practical? It seems unlikley that it would greatly simplify the process of C calling interpreted Spin (or vice-versa). These two languages will most probably use different (and incompatible) back-ends, different virtual machinery and different calling conventions.
The problem is analogous to being able to call SPIN functions from PASM and vice-versa - i.e. it's possible to simulate this and make it appear to the user that this is what's happening, but the cost is so high it is barely worthwhile and would hardly ever be useful in practice. It would (of course) be much simpler if SPIN were to be compiled to LMM PASM, but it is not clear that this is the intention.
And compiling Spin to LMM PASM is nuts as the whole point of the Spin/bytecode/interpreter set up is to pack functionality into a small space. Not to mention enabling one of the simplest programming environments since BASIC on 8 bit machines. Piling the weight of GCC and all the associated complexity onto that kind of defeats the point for no useful gain.
I have to disagree. Compiling C down to Spin bytecodes is just going to be slow and horrible. A terrible price to pay for easy linkage between Spin and C modules. Didn't we learn that from the Zog VM for zpu-gcc?:)
In general, I would agree - but we have the opportunity here to rewrite the Spin VM, to come up with one more suitable for C than the current one is (but which can also be used for Spin). The current Spin VM is a marvel of functionality - but who needs all that complexity? The Catalina VM is much simpler and also much faster for most operations - the main reason for this is that it doesn't try to conserve space, and also that it doesn't try to build all the necessary functionality into the VM itself (if you want more complex processing than the kernel offers, do it in a library function!)
The C compiler should compile to LMM PASM like Catalina and ICC for speed. It should also be able to make use of code in external RAM (XMM) which will be much easier to connect to Prop II and faster.
Again, in general I would agree - but it's your assumption that speed is an important criteria here - Parallax has never even hinted as much.
In future Props there will be even more HUB RAM or even better external RAM interfaces. LMM PASM will serve those future devices well.
Who says we can't execute byte codes from external RAM? In fact, I though for a while that Zog would have an advantage here because in many cases you only have to fetch a byte to get the next instruction, whereas Catalina always has to fetch 4 bytes. A clever byte encoding might win out here.
In this scenario I want one to imagine that Spin becomes a so called "embedded language". Not to be confused with "embedded systems". That is to say that is a language that one can embed in ones C applications. A good example of such a language is Lua. Which is often used to give user scripting abilities to programs otherwise written in C/C++.
Yes, I see that. But (see my post above to David Betz) making this work in practice is unlikely to be worthwhile.
Here a Spin byte code interpreter is used from a C app to run a Spin byte code program in some kind of "context" (Basically some memory the bytecodes and data live in with an interface API to let the C code manipulate and interact with it.
We could do this now without too much trouble - we don't need GCC or anything like it.
But who would actually use it?
Ross.
EDIT: We cross-posted - but I think I addressed your space issue as well. Yes, Spin was designed to save space, which was necessary when you only had 32k. But with 128k, and better access to XMM, this doesn't any longer seem so critical.
Comments
In particular, I'm genuinely curious as to where Chip has arrived on LMM and threading on Prop II. IMHO, that realization being known for Prop II is a big step up. It would be great to get the summary of that interaction posted somewhere, if interested onlookers can't listen in! (And yes, I would love to participate to listen and learn, and won't be trouble.)
One suggestion: No matter what path is taken, please insure that the full functionality is supported old school command line, STDOUT, STDIN, STDERR used as intended. All output needed for a GUI to interact with the system can be sent through those channels, allowing "GUI as wrapper" kind of development, which will enable those that prefer this and that to do what they will with no real worries. If desired, one GUI / IDE can be supported. Once the core tools are done, support would likely move up the chain some, dealing with changes at the higher level of abstraction. There are strong benefits to that as well, with a primary one being the support at the higher levels of abstraction being smaller in scope, because the tool chain build process is compartmentalized. In the SGI case, it was often that a revision to the overall environment did not ever touch the core tools. Naturally, that would be useful in this space, due to the wide variety of approaches. This would be a very positive differentiator, IMHO. Very easily positioned as open, as well as accessable, and practical, stable.
SGI, for one example, did this on nearly all of their OS tools, providing a verbose (-v), and in some cases really verbose (-vv) options that would stream the input and output needed for GUI interaction. A few other cases might require a input mode or two be specified as well. Everything done that way is scriptable, and "packagable" for the most part, and by nature, cross platform, as windows32/64, Linux, Unix all do the STDIN, STDOUT, STDERR thing nicely enough. All the basic OS functions, pipes, redirection, work well too.
If the core dev tool chain is done this way, it will serve as a foundation for whatever GUI / IDE type projects make sense, including this one. Most importantly, it will also make small, dedicated build environments possible and practical as well. Could use DOS, if one wanted, or perhaps a stripped down single-user Linux, just by way of two examples.
IMHO, that's "pro" quality stuff. I've sure been around a lot of OSes, and core tools built that way never gave me one lick of trouble, because I always had options, and the building of things needed for automation was accessable, even to people of moderate skill. Please consider it.
If what I wrote is not clear, I am perfectly happy to work to convey this better.
I to am intrigued by what may be coming with respect to threading on Prop II.
My understanding from previous posts by Chip and all is that threads on COGs would allow a COG to more easily perform more than one time critical function at a time so as to avoid having to dedicate whole COGs to small functions. Perhaps you are wanting to combine a UART and a some other bit banging in a single COG say.
I got the impression that due to the way the Prop pipelines instructions it would be possible to interleave the instructions of at least two threads without slowing either one down.
Don't worry about the dev tools and the command line. If Parallax adopts GCC the compiler and other utilities are command line tools and are used in IDEs like Eclipse in just the way you describe.
I did mention earlier that perhaps they should look at LLVM as the tool chain instead of GCC. Now I don't know squat about either but one of the motivations behind LLVM is to have a compilation system that is easier to integrate into an IDE. I get the impressin that LLVM will overtake GCC at some point. There is a lot of enthusiasm for it in the compiler builder community.
What will happen to the Prop Tool and Spin is another matter. Will there be a command line, cross-platform, open source Spin compiler?
I don't think Ken was asking for a debate on languages and developer environments (although that is certainly in the scope of the forum). The implication of a LMM IDE that supports C, SPIN and other stuff has profound implications for the success of the new chip (especially if objects work across languages).
It seems to me that they have already made the important decisions. They have chosen languages and an environment and are seeking people to help them develop it.
As part of that strategy Parallax also needs to satisfy the "professional" developer whom it seems is incapable of living without C. This did not make much sense for the Prop I but is practical an essential for the Prop II and its successors. Also Parallax needs to offer a more professional IDE to accompany that C compiler. Note that the compiler and the IDE are separate items unlike the situation with the Prop Tool IDE and compiler combined.
For the compiler it makes sense to adopt an existing industrial strength compiler like GCC and adapt its back end code generation to the Propeller. Almost certainly generating LMM PASM code.
Again for the IDE it makes sense to adopt an existing industrial strength IDE like Eclipse.
It is essential that both compiler and IDE are open source and cross-platform at least Windows, Mac and Linux.
GCC is the obvious choice for the compiler. GCC already supports a myriad of devices: Intel, ARM, MIPs, PowerPC, AVR, ZPU etc etc etc.
Eclipse is a good choice for the IDE. It's big and bloated and slow but it is well received in the industry.
My only observation is that perhaps now is the time to look at LLVM as the C compiler which by all accounts is:
1) Easier to integrate with an IDE.
2) Easier to adapt for new targets like the Propeller
3) In some circles said to be the successor to GCC.
Now, I'm no compiler developer, that's just what are hear around.
So, to answer David Betz, no I do not really know anyone with LLVM experience except...Currently we run GCC compiled code on the Propeller using a ZPU processor simulator. That ZPU target for GCC was create by Zylin Inc. Zylin is in the process of switching to LLVM rather than redo their GCC work for the current version of GCC. As a small consultancy perhaps ZyLin might be interested in working with Parallax on LLVM for the Propeller.
Do you know which version Microchip used, and where on the time-line the MCU changes are ?
I did find this on the NetBeans site
The TI msp430 microcontroller toolchain.
http://plugins.netbeans.org/plugin/27033/msp430-toolchain
Added: 2010-03-28 Downloaded: 210 times
and this discussion was interesting at the detail level :
http://netbeans.org/bugzilla/show_bug.cgi?id=156201
and general chatter here
http://mightyohm.com/blog/2009/05/avr-eclipse-and-the-mac/
Sounds like it is 'somewhat real' on small MCUs, so the step would be to actually launch, and try real world use.
I'd tend to side with Microchip, and they do have that vital 'critical mass'!!.
A quick glance at this, is interesting.
Some positives : Languages like Haskell are mentioned, and the idea of LLVM could suit Propellor nicely.
( Especially if Prop II allows HW support for QuadSPI memory access )
Some negatives: The Debug angle of this, is very 'green'
http://blog.llvm.org/search/label/LLDB
which means a distinct lack of 'working examples'. I'd put it in the 'worth tracking' basket ?
I think we may be confusing several issues here, and thereby risk jumping to incorrect conclusions. It's not clear to me that we even understand Ken's original post correctly yet. Ken's reference to GCC & Eclipse is leading us to make certain assumptions - but Ken himself admits his knowledge in this area is rudimentary.
Here are some questions I think it is worth exploring a bit more deeply before we go too much further:
1. Does Parallax want a single compiler suite to handle multiple languages, or do they just want a single development environment that can do so? The two are quite different, and it is not really clear from Ken's original post what is wanted. If the answer is the former, then GCC may be the logical choice. But if it is the latter, then Eclipse may still be a good choice, but GCC just becomes one of a number of compiler choices, alongside the current crop of SPIN and C compilers.
2. Do the languages supported have to include interpreted SPIN? If so, then again Eclipse may be a good choice - but does it make sense to try and compile SPIN with GCC? While it would certainly be possible to do so, we already have several perfectly capable SPIN compilers, so it seems a bit unnecessary. Developing a SPIN compiler in GCC would take more time than doing a simple C port, since you need a new front-end as well as a new back-end. To do both would require the development of (essentially) two different toolchains - i.e. SPIN currently compiles to SPIN byte codes, whereas C/C++ etc would have to compile to LMM PASM. This means you not only need two different front-ends but two different back-ends as well. The two could not even make much use of commonality in the middle-end (i.e. at the GIMPLE level) since it is not (in general) possible to link the two types of object. Given the overheads involved, it really makes very little sense to allow other languages to call SPIN (or vice versa) anyway. This kind of thing would make more sense if Parallax intends to offer compiled SPIN alongside (or in place of) the current interpreted SPIN. Or perhaps interpreted SPIN on the Propeller 1 and compiled SPIN on the Propeller 2?
3. So are there always going to to be two separate development toolchains? This is certainly implied by Ken's post, where he indicates that the Windows Propeller tool will be developed anyway. Perhaps the idea is to offer SPIN for hobbyist use and GCC / Eclipse for professional use?
4. What other languages (other than C, SPIN and PASM) does Parallax want to offer? C++? Objective-C? Java? Fortran? Ada? If the answer is 'yes' to any of these, then GCC may be a good choice. But who would be the intended users of these languages? It would certainly not be the professional users that Parallax Semiconductor needs to attract - they will generally only be interested in C (and PASM). They certainly won't want SPIN. Some of the other languages I mentioned may appeal to the customers of Parallax (like us!) but they will probably not appeal to the customers of Parallax Semiconductor (who are the people this new toolset is supposed to be aimed at).
5. Is Parallax prepared to face the inevitable direct comparison with various microprocessors (rather than microcontrollers)? Let's face it - all stack-oriented languages (including SPIN) will perform poorly on the Propeller 1 and 2 microcontrollers when compared with just about any single core microprocessor costing about the same. In some ways, adding more languages just gives people more opportunity to do very simple benchmarks that will apparently show the Prop up poorly - because this is not what the Propeller was designed for, and none of these languages are designed to take advantage of the Propeller's unique features. I'm not suggesting Parallax should abandon the idea of supporting other languages - I'm a strong supporter of the idea, since SPIN is never going to gain widespread acceptance. What I'm suggesting is that while Parallax has to offer C, they don't have to offer anything else to be taken seriously in the professional semiconductor market. If (for example) they offer the full suite of languages supported by GCC then the first thing that will happen is that users will try loading Java or C++ programs that make extensive use of the bloated language libaries, and complain when they can't fit the resulting binary into the on-board 128k. Or they will try to add a GB or two of XMM RAM and port Linux, then complain when it takes 15 minutes to boot (Actually, it probably won't be professional users who do this - they would have more sense - it is more likely to be us!
If we could get some clarity on these points, then perhaps we can have a more informed debate about the various merits of particular compilers and development environments.
Ross.
-Phil
I think all Ken is looking for is some individuals who have knowledge in GCC / Eclipse to
start brainstorming what, how and if a proptool II using that would be a good choice.
Instead everyone seems to want to turn Prop into a microcomputer and compete with Intel processors
running things that do not fit the architecture of Prop I or II.
It even sounded for awhile where running the many megabyte dot net run time in each of the 8 cogs by paging it
in was desired. I can guess how slow that would be LOL.
I can see a C syntax language but not even the entire standard C lib. I like curly brackets instead of indentation.
It is a microcontroller.
I restate my comment that a propellent.dll and propellent.exe for Prop II are the way to go and give everyone something
to wrap a proptool around. Dot net whatever would be good at that. Add a version of each of those that understands C
syntax instead of Spin would also be good. I am not even sure you would need obj and lib files either just keep it simple.
I think the programming principle of KISS needs to be followed, Keep It Simple Stupid.
Get Prop II off the ground with a basic editor using a propellent.dll or exe which contains the compiler and assembler.
One that Parallax controls and trusts.
Also I think Ken would be interested in another thread on just what other than editing,compiling and downloading would
be desired in a new IDE. Then people can brainstorm if implementing a given idea is even possible.
Tom
Posts like yours and others here are very helpful for talking points.
I don't plan to say much in this thread/forum as this is part of my "humble service" to Parallax Semiconductor. Lots of things need to be discussed in a private setting with the principal stake holders (Parallax) and those of us they have called upon to participate (including distant on-line contributors).
I will say that it is a very positive step that Ken and others in Parallax understand the need to step up to expectations beyond that of small developers/business owners and hobbyists. This is intended as a solutions oriented statement because Propeller revenue growth depends on larger customers adopting the technology. As someone once said "A rising tide lifts all boats." Hopefully Parallax Semiconductor can attract enough customers to make the tide rise.
a) I read one branch as 'Adding GCC' - which ~means "swallow most C libraries" that are out there.
It may be that C# is a better 'fit', but embedded developers are mostly glued to C.
On the Prop, this will be a challenge, given the memory splits chosen. Classic printf spaggeti, is not going to make sense.
So this may split into two further branches: What I will call COG Ram compiler, and Interpreted Compiler.
One is very limited, but a common syntax at least make moving between the two easier, and code easier to maintain.
For the simplest (most code constrained) cores, I like the HLA concept. This extends Assembler with Block structures, so you
shift from 'label soup', to more conventional HLL looking source, but are still working at ASM level.
http://en.wikipedia.org/wiki/High_Level_Assembly
b) I also read it as the other branch being 'Adding Debug', which is a quite different problem.
You can craft debug support to be almost language agnostic (and for the Prop, that is likely a good idea).
We created a file format, that made Debug totally Language agnostic, by massaging the Source(s), Linker MAP info, and the Object File Line#info, and creating a new 'Source file', with absolute addresses in the first columns in hex. This file is also a great project report, as it has the source, and the memory map in one file It is self documenting, and can easily support mixed languages.
(0123) This line is Starts at Abs Address 0123
(----) This line has No Associated Address
Then, during STEP/BREAK etc, the Debug IDE, looks for the nearest address before the known disASM address.
Watch variables, are extracted from the preamble MAP listing, and the Debug IDE gives a choice of watch formats, but always ALL memory is 'inspectable'.
The challenges with any debug, are getting enough bandwidth into the Silicon, and making the Debug Stub as invisible as possible to the users code.
That is why silicon support is very important, as it can make a huge difference to both 'invisible' and bandwidth.
As a disclaimer, I have to stress, as I've said for years: I do want Spin to be a better language, and I do want a better IDE. But I think Parallax needs to cast a wider net before the forces manifest in this thread are given full rein to create our next dev tool chain.
-Phil
I think you can at least rest easy on that score, Phil.
It seems very unlikely that C# and .NET will ever run on the Propeller - Microsoft's .NET Micro Framework (NETMF) requires more than twice as much RAM as the Prop 2 is expected to have, and even so it does not support the whole of the C# language (this is very analogous to the Arduino claims to support C++ but only implemening a subset - and likely for very similar reasons). See http://thing1.windowsfordevices.com/articles/AT9185657281.html for more details on NETMF. Also note that NETMF is neither real-time nor deterministic (which makes you wonder what the heck it is intended for???).
It must blow these guys away when they see what we can already do on a Prop I with only 32k of RAM (let alone what we will be able to do with the Prop II !)
Ross.
I think you must misunderstand my intentions. My primary goal would be to make the official Prop Tool Parallax provides be better and cross platform. My favored method is .NET, but if that's not how they want to go then fine. However, I think for most customers hobby or pro, a .NET solution works well. The reality is that the percentage of people that want linux or mac support is small, and most of them are fully capable and willing to do a minor extra install (if they haven't already) to get it working.
I'm not really a fan of getting yet another C/C++ working on the Prop 1, there are already solutions available. I know Parallax want it for the "professional" arena, and I support them with that. However, I will continue to use Spin & PASM on the Prop 1.
To me "target" in this case means PASM Large Memory Model (LMM) as is the case for Catalina and ICC. Is there any way to do it that is not slower?
I simply suggested the LLVM C compiler may be a better candidate to create a PASM LMM target for. For reasons I have stated above.
NOTE: LLVM is not a virtual machine to run on the Prop or other CPU it generate real machine instructions.
Whilst the compiler is called Low Level Virtual Machine (LLVM) that is not to say that the generated code is intended to be run on a Virtual Machine interpreter like Java or C# on the target. No, LLVM is the intermediate form of the compiled C, C++ , ADA, etc etc code that is then used to generate real machine instructions from.
All this talk of C# .NET whatever on the Prop is gibberish. The run time is obviously too big, too slow, too abstracted from the hardware. We have Java run time on the Prop that demonstrates that already.
No, you're not stupid - but neither was Ken's statement very clear. He has not yet clarified his original post, which says ...
There are several possible ways to interpret this pararaph - especially as Ken himself says later that his knowledge in this area is limited. Your interpretation is certainly possible, but is it likely, given that SPIN is mentioned in the above paragraph? It makes little sense to expend the effort required to make GCC compile SPIN, given that (a) there are already at least three good SPIN compilers available, and (b) the intended users of the proposed new toolchain probably won't be interested in SPIN anyway. This is why I think it is quite plausible to interpret this paragraph to mean that Parallax want a multi-language IDE (perhaps based on Eclipse) to replace the Parallax SPIN Tool, and are also considering GCC as one of the compilers that this IDE may invoke "behind the scenes". An existing SPIN compiler could be another. Existing C, Basic or Forth compilers could be invoked as well.
Of course, it would make sense to use a common compiler if all the languages shared a common back-end target (i.e. either LMM PASM or SPIN VM).
Hence my questions seeking to clarify these points.
Ken does mention LMM later in his post - but merely as being "encouraging". He does not say that LMM PASM is the intended target of the C/C++ compiler, or the SPIN compiler. It actually makes more sense to assume that Parallax is hoping to use GCC to generate SPIN VM byte codes for all the languages Ken mentions - which would be in keeping with the original "Parallax Micro C" proposal.
To me, Ken's post is as clear as mud, and we are all (including me) reading it coloured by our own preconceptions. I hope Ken clarifies it before we all go jumping off in different directions.
Ross.
Still running some kind of C# on Propeller is most likely impossible anyway.
I'm sure Ken will be happy to clarify his intentions, but it's obvious to me.
The way I see it is this for big time commercial users:
1) Create a GCC target for LMM PASM
2) Use Eclipse as the IDE for that.
3) Who cares what happens with Spin in this new "professional" world. Although perhaps Eclipse can also be adopted as the IDE for Spin programming.
Pretty much any other option does not make any sense to me which is why I thought the opening objective statement was clear.
The other options you have considered don't look attractive as you say:
A Spin byte code target for GCC is pointless, to slow. It's only advantage is perhaps that it becomes easier to link Spin and C. Who wants to do that?
Compiling Spin to LMM makes no sense. Spin is all about getting the most functionality into the smallest space. LMM will not do that.
Hmmm...What might a "professional" want to do in this Eclipse IDE?
1) Must be able to write code in C or even C++. The Arduino and my experiments show that C++ is quite a reasonable option if one uses it in a way appropriate for small systems. C++ has the massive advantage that it becomes possible to work in the same object based way as you do in Spin.
Note: "Object based" not "object oriented" I'm sure you know why.
Looks like LMM is the only way to do this with any speed.
2) Must be able to write PASM for high speed code loaded into COGS.
3) Must be able to work with that PASM code from C. Sorting out the loading and communication through HUB.
4) Must be able to make use of existing PASM "cogjects" that will have C/C++ wrappers to access them and just be pulled in from a library like any other C stuff.
Sounds like all that stuff you have tackled in Catalina already does it not? And in my small way with Zog where I have some "cogjects" with C++ wrappers.
5) Optional: If you really want to mix up Spin code with your C think about this:
To run Spin code you fire up a Spin interpreter in a COG. That is just the same as firing up one of those "cogjects" mentioned above.
That interpreter needs some byte code to run. Well that's just some data sitting in HUB that the interpreter cogject needs.
That bytecode needs some stack and data space to work in. Well that just part of the data are mentioned above.
So to run Spin code in your C program just compile the Spin to byte codes and have those byte codes turned into a blob suitable for linking in with your C. Just like any other data you might use in C. Perhaps the bytecodes are just turned into C source code as a constant array.
Now just fire up the interpreter cogject and point it at the byte code data.
BINGO you run Spin the same way as you run any other PASM object.
So perhaps the Eclipse IDE also needs to be able to edit and compile Spin programs whilst you are actually working on a C/C++ project. Using a different (existing) compiler NOT GCC.
I was trying very hard to refrain from mentioning Zog on this thread. Thank you for doing that for me:)
Sorry yes, PropellerJVM is up there with Zog. Or is it "down there"
I think if they had a toolchain (command line compilers, etc.) that was cross platform and then provided configurations for Eclipse (and/or other IDEs), that would be probably the most appealing to the most users. Then the Prop Tool could be changed to use that toolchain and provide the easy user experience that exists with the Prop Tool now.
Also, I don't think it's unreasonable to think that a Prop 2 board with external SDRAM could run a .NET CLR. Although, I am not really sure how useful it would really be.
Hi Roy,
Yes, it's fairly clear that that's what Parallax wants. But that doesn't make it sensible - or even feasible. And I think that's part of what we're supposed to discuss.
It's the inclusion of the word Spin that makes the whole thing uncertain. Take that word out and I would tend to agree with Heater's interpretation. Leave that word in, and I no longer agree - then, the most appropriate solution becomes a GCC toolchain that complies all languages to a common set of SPIN/C byte codes.
I'm sure Ken will clarify eventually.
Ross.
Hi William di Malaysia mesti ada bahasa melayu lah:)
I have a rather radical idea of how Spin could be included. Just like it is possible to retarget GCC to a new processor by writing a new backend code generator it is also possible to add a new frontend to support a different language. It is concievable that a Spin frontend could be written for GCC that would take Spin source code and compile it down into the intermediate language that drivers the GCC optimizer and backend. If a compatible ABI is chosen for Spin, that might make it possible to call Spin code from C or vice-versa. However, while I know people who have worked on GCC backends, I don't know anyone who has written a new language frontend and I don't know how well that process is documented. I'm sure it's possible though since the GNU Compiler Collection contains many different languages already.
I have to disagree. Compiling C down to Spin bytecodes is just going to be slow and horrible. A terrible price to pay for easy linkage between Spin and C modules. Didn't we learn that from the Zog VM for zpu-gcc?:)
The C compiler should compile to LMM PASM like Catalina and ICC for speed. It should also be able to make use of code in external RAM (XMM) which will be much easier to connect to Prop II and faster.
In future Props there will be even more HUB RAM or even better external RAM interfaces. LMM PASM will serve those future devices well.
In this scenario I want one to imagine that Spin becomes a so called "embedded language". Not to be confused with "embedded systems". That is to say that is a language that one can embed in ones C applications. A good example of such a language is Lua. Which is often used to give user scripting abilities to programs otherwise written in C/C++.
Here a Spin byte code interpreter is used from a C app to run a Spin byte code program in some kind of "context" (Basically some memory the bytecodes and data live in with an interface API to let the C code manipulate and interact with it.
I considered this in my post #70. As you say, retargetting the back-end of GCC is a well worn path that has been followed many times - but writing a new front-end is a whole 'nother ball game.
However, while I'm sure it's possible (and would certainly assist in the sharing of data and name spaces between the two languages), is it practical? It seems unlikley that it would greatly simplify the process of C calling interpreted Spin (or vice-versa). These two languages will most probably use different (and incompatible) back-ends, different virtual machinery and different calling conventions.
The problem is analogous to being able to call SPIN functions from PASM and vice-versa - i.e. it's possible to simulate this and make it appear to the user that this is what's happening, but the cost is so high it is barely worthwhile and would hardly ever be useful in practice. It would (of course) be much simpler if SPIN were to be compiled to LMM PASM, but it is not clear that this is the intention.
Ross.
But who would actually use it?
Ross.
EDIT: We cross-posted - but I think I addressed your space issue as well. Yes, Spin was designed to save space, which was necessary when you only had 32k. But with 128k, and better access to XMM, this doesn't any longer seem so critical.