localroger said...
I'd like to mention something about targets for the "it has to be faster than Spin" crowd. Firstly, C is faster than other languages mostly because it is a crappy language that doesn't do memory management, array bound checking, type checking, or a lot of other stuff you can take for granted in a real high level language; it's basically short-form PDP-11 assembly language with a lot of braces and parentheses. So on most micros it generates code that is extremely small and efficient because it isn't bloated up with all kinds of convenience features like buffer overrun protection.
Much of this is incorrect. C very early on became a platform independent language, and is now the language most widely implemented on any platform. It was specifically designed to implement things that required speed - like operating systems and device drivers - without having to resort to assembler. It is still widely used for this.
Anecdotally, it is always claimed that there are some C operators (like ++) that derived from the original PDP-11 arhitecture and instruction set - I don't know if this is true or not. Nor does it matter - the reason these operators persist is that they also map directly to many, many other instruction sets. Which is one reason C remains the most efficient language choice on so many platforms.
There are implementations of C that include buffer overun protection, just as there are memory management libraries that will do garbage collection for you - I can't see how this can be construed as an argument either for or against C itself. In any case, these things are most often used only during the early stages of development, and they would nearly always be turned off for production code - because of the need for speed.
The very complaints that localroger makes against C (e.g.. no bounds checking, no memory management) are in fact precisely the reasons why C is still so widely used in embedded environments, where such things are both unnecessary and undesirable.
I have already said that without it's speed advantage, C would not be a language of choice for many applications. And I agree with localroger that there is no "ideal" fit for C on the Prop I (on the Prop II, however, the answer is obvious - increased speed would be far preferrable to any space saving).
Fortunately, this is not really an "either-or" argument. If PMC were ANSI C compliant, it could be used to satisfy the teaching requirements. A massive investment in time and money (trust me on this!) but technically feasible.
To answer the professional requirement, when this discussion has died down there will still be Catalina and ICC.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
@Ross, there are two reasons I wrote several pages back that I hate C with the fury of a thousand supernovae.
(1) I hate the syntax. Really hate it. Really, really, really hate it. I hate the way it uses every possible kind of enclosure punctuation, I hate that it totally ignores line breaks, and I hate the godd*** semicolons. It makes my eyes bleed. I hate the fact that it is even possible to have such a thing as an "obfuscation contest" based on it. And the fact that every other wanna-be serious language feels it has to emulate this ca. 1974 "my parser has to fit in 2K of RAM" look just rubs salt in that.
(2) I would agree with you that C it is the language of choice (or would be if the syntax didn't make my eyes bleed) for things like device drivers where you have the wiggle room not to need ASM. Spin itself has many of the same limitations because you can't afford those luxuries in a 32K workspace. My problem is that this close, efficient, fast, dangerous, hard to read language is then used to write billions of lines of business logic that could and should be written in a much safer, more readable but not so efficient language.
I believe C is nothing more than a universal assembler. Any processor with a C implementation is expected to generate ASM without the learning curve of the processor. So any version that doesn't generate native ASM for the target processor is academic. And it sounds like that is exactly what Parallax is looking for with its PMC experiment.
You know, I'm beginning to suspect that you might have a mild antipathy towards C!
@Sapieha,
I can't argue with you on the drawbacks of C - they are well known.
However, I'm not sure it's true that micro manufacturers tailored their instruction sets specifically for C - after all, C does not require anything that any other procedural language would not also require - as can be seen by the fact that C is fairly readily implemented even on rather unusual architectures like the Propeller.
C itself is only one member of the ALGOL family of languages (which include C, Pascal, Modula-2, Simula, Ada, and many others). It would probably be correct to say that hardware manufacturers saw the need to improve support for all procedural languages. If they did anything specifically for C, it is likely to be mainly because they wanted to be "the fastest kid on the block" in the most popular language, and also because they saw the writing on the wall for those who did not at least offer reasonable support for C, even while they tried very hard to sell their own proprietary language (which many did!).
I think your point about modern instruction sets being too simplistic is not so much about C per se - it is more about RISC vs CISC architectures, and the difficulty of writing efficient compilers for any high-level language when the target platform is a CISC architecture. There is also the fact that on any processor, 90% of the processor's time is spent executing about 10% of the instruction set. Some instructions on CISC architectures are so complex (I'm thinking VAX here, but it may also apply to Intel) that I suspect they were never ever used!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
RossH said...
There is also the fact that on any processor, 90% of the processor's time is spent executing about 10% of the instruction set.
For many architectures, I would argue that 90% of the time is spent waiting for memory.·On modern Intel/AMD CPUs, hitting L1 cache is a few cycles, missing that and hitting L2 cache is an order of magnitude worse at 15-30 cycles, missing that and hitting memory is another order of magnitude worse at 200+ (sometimes at long as 400-500) cycles. This kind of progression holds true for a lot of different architectures.· It doesn't matter much if it's CISC or RISC, of course, both Intel and AMD have their CISC setup built on top of what is essentially a RISC core.
The Propeller is·operating on registers (cog memory) and L1·cache (hub) all the time, unless you implement external memory. So largely the main thing you are waiting for is external hardware that's connected to the data pins. Which I guess fits exactly what you said above. [noparse]:)[/noparse]
As for the C syntax, I don't mind it at all, but maybe that is just that I have been using it for 25+ years and it's just automatic for me (both in typing and reading).· Probably 90% of my compile errors in the Proptool are because I typed a semicolon on the end of a line or used some other C syntax.
So, I guess I wouldn't mind having a variant of Spin that used c-like syntax, which is what PMC sounds like so far. I just wouldn't try to call it C in any way shapre or form. Just call that Spin with c-like syntax.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Dave has concisely summarised it to 7 points. Excellent. Most of these are already covered. Let me add 8.
8. PropTool. This IS THE MOST IMPORTANT ***** and everyone seems to be in agreement.
But 8 is already done. Maybe a few more improvements BUT..
#Define and #ifdef, #elseif, etc - done
Compiler warnings - done
Inbuilt Terminal program and it automatically runs after a valid download - done
Works on windows, *nix, mac (most operating systems) - done
PropBasic uses it (somehow).
Needs #include (to allow source includes)
Add C to bytecode
and Brad is so quick with any bug fixes and excellent responses with requests.
So, this issue is easily solved - Parallax, make Brad an offer he cannot refuse, preferably keeping him to mantain it. If you like some features of the PropTool, give him the source and pay him to add them to bst.
Now for the other 7 points..
7. PropBasic - it works now, thanks to Bean.
3,4,5 - C to PASM (various flavours) - it works now - Catalina & ImageC.
6. Extended Spin - Keep for a later discussion. Sure there are some additions and improvements, but let us see where the C thing goes.
That leaves 1 & 2...
1. C to Spin (source) - we have one or two doing this but there seems to me that this is a kludge and has no real benefit in the long term. It has been a great idea to allow C to progress without access to the spin compiler, but it's just that.
2. C to bytecodes (Standard C to spin bytecodes)
This is an excellent idea and should be the way to go (after PropTool of course).
BTW: I hate C with a vengence, but it IS required.
It must be standard C (discussed above and I have to leave this to the experts.
It should also be part of the compiler (propTool). I would like to see it co-exist with Spin in the same source, just like PASM. I am not sure if this is feasible, but it would make the most sense. So you could just have
#include <stdio> '-> object
VAR
.....
OBJ
.....
PUB
.....
PRI
.....
DAT
.....
void main()
{
tv.out( getc() );
putc( kb.getkey() );
myfunction1();
for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2); completely understandable LOL!!!
}
Advantages..
C, spin, pasm·all co-exist giving access to the objects already done.
Small bytecode = larger programs possible
Disadvantages..
Slower than C to Pasm/LMM
Now, slower is most likely not an issue for·schools. It may not be an issue for commercial programmers with the mix of pasm objects. Spin is not an issue for a large part of the code we currently use. If it is an issue, then use Catalina or ImageC. Of course, with the PropII, speed should not be a problem, but I guess memory will still be a problem even with the extra we will get, just because we will use the PropII to get more elaborate hardware.
Could Parallax use the front-end of Catalina and output bytecode instead??? Ask Ross. This way we could have identical source code???
To summarise,
Solve PropTool (bst?)
Develop Standard C to bytecode
I am going to suggest you make some offers to the community to help develop Standard C to bytecode. Parallax resources are already stretched and as has been pointed out, a howto for PASM is required and this is not likely to be done by the forum. Use the forum for what they are interested in doing and do the stuff they aren't interested in·inhouse.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Could Parallax use the front-end of Catalina and output bytecode instead??? Ask Ross. This way we could have identical source code???
Yes, this is possible. But I'm not curently inclined to do it - for two reasons:
1. I originally abandoned SPIN in favor of C because SPIN was to slow to do what I wanted to do with the Propeller. I started work on Catalina only because I then discovered how little support there was for C on the Propeller. SPIN was too slow and PMC would be even slower.
2. I NOW know just how much work is required to get a complete compiler and development environment up and running - if I had known this when I started, I probably wouldn't have done it. The code generator is less than 5% of the job. I got Catalina's original code generator working in a couple of weeks, and it has required very few changes since that very first version (although it could certainly do with some optimization!). But it has taken almost exactly a year's worth of effort after that to then get Catalina to the level where it is now - i.e. a completely self-contained and platform independent development environment for the Propeller - one which does not depend on any Parallax products, either to compile, load or (with the latest release) debug C code.
I'm not sure I want to spend another year on this - this time for a version that I would never even be able to use! Of course, anyone else is welcome to have a go at this - Catalina is fully GPL-ed.
Phil said...
The AVR architecture is claimed by Atmel to have been optimized for C: ...
Interesting - I suspect this is largely marketing hype (we use AVR micros where I work, and as far as I can tell, their architecture doesn't appear to be optimized for just about anything! EDIT: actually, that's not quite true - they are very good at implementing low power modes - which is the main reason we use them in preference to other micros for our applications).
However, if true it does highlight that AVR believe C support is critical to their business, and also that it must be high performance support.
EDIT: Dang! sorry about editing my own post so many times. I'm not sure what keeps happening to my edits!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Ross: Thanks. Catalina is & was the right tool. We now have it, thanks. However, I do see a position for tight slower code which is why I suggested C to bytecode.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I think one of the problems with C in this context is that people seem to want a do-all replacement for both Spin and assembly -- or at least can't make up their minds which one to replace. But each member of this tag-team duo has it's place in the Propeller architecture: Spin as the rapid-dev glue code and assembly as the turbocharged engine running under the hood. Given the Propller's underlying architecture, it's difficult for me to accept C as being a good fit for either. If Parallax did produce a C compiler, developers may well get what they think they want but will be denying themselves what they really need. As a result, their apps may perform anemically in comparison with what they could have accomplished with Spin and assembly. I doubt that the Propeller's reputation would be enhanced as a result.
I fail to understand how C building to byte codes, coupled with both direct PASM blocks of assembly, and C compiled to assembly as an option, would perform considerably less than spin would.
With me, I don't really want it. SPIN + PASM kicks a lot of ***. I'm happy. But, if one wants C, and if one needs C, then a C that is built to use the byte codes, and that can directly build in PASM and or compile to PASM is gonna rock pretty hard, just like SPIN + PASM will, so why not do that?
It's going to be able to use a lot of PASM code already written. That's a plus. It's also going to make good use of the on chip intrepeter, just like SPIN does, and that's great too! Truth is, the C environment will permit the kinds of hacks needed to do all sorts of things that SPIN gets in the way of, so why not empower those people that would do those things?
I'll ask again. Is it the idea of actually competing with SPIN + PASM that's at issue? If so, let's have that discussion. It's necessary. If not, then where are the downsides?
So, I guess I wouldn't mind having a variant of Spin that used c-like syntax, which is what PMC sounds like so far. I just wouldn't try to call it C in any way shapre or form. Just call that Spin with c-like syntax.
@Cluso99 don't feel bad. All the other times over the years that C compiled to spin byte code was mentioned invoked the same reaction from Ross. That's Ok though, it's his nickel.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
I agree with you 100% - C should not be seen as a replacement for either SPIN or PASM. It is a different tool for a different job. After all, how many toolkits contain only two tools? (Apart from BradC's, of course!). I also agree that C does not fit particularly well on the architecture of the Prop I (but it will be a different story on the Prop II).
But C on the Prop I is an alternative to both SPIN and PASM which many users would choose because:
While it is not as fast as PASM, it is much faster than SPIN.
You can write much larger programs than you can with PASM (or with SPIN, if you use XMM!)
You can re-use zillions of lines of existing C source code.
My main point in this thread remains that PMC (as it is currently specified) does not really satisfy its stated goals, and is more likely to damage Parallax's reputation than enhance it. In particular, if it makes people believe it is somehow C compatible (which it will) but it cannot successfuly compile existing C software (which it won't) then users would be quite right to become a little annoyed when they find this out.
If PMC were to be made ANSI C compliant then my major criticism would vanish. Many users still wouldn't use it because it would be too slow for their purposes, but some users would. If Parallax decides there are enough such users to justify such a tool then they should invest in it by all means. It won't occupy the same niche as Catalina - but even if it did, so what? - there are already two compilers occupying that particular niche anyway, just as there are three or four alternative SPIN compilers. Most processors have many alternative compilers - it's a good sign, because it means the processor is attracting real interest.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
We live in a different day and age. There is a mass of people that want to program in the language they are familiar with. There are thousands of languages and you cannot please everyone. However, it would be reasonable to keep the big 5. IMO, that would include a Propeller Software Tool that can handle PASM, SPIN, EXTENDED BASIC, C and one new language. I propose a new language called PARALLEL. That's because all the other languages are written for single processors. But the Propeller is a Parallel processor and can be used in parallel ways which can gain from a parallel-capable language with parallel algorithms. The next time you want to program 8 Propeller cogs or connect multiple Propeller chips, think about usefulness of programming in a more conducive way.
Sapieha: "IT was very bad decisions from manufacturers side to give "C" that position"
Why do you blame C?
Yes, modern processors have been designed in such a way as to make life easier for C compilers. But surely the features required to do that are of general benefit to a broad range of high level languages, ADA, Pascal, whatever.
Just happens that C has been the most popular but things like a flat memory space and efficient stack operation are required for most high level block structured languages. Not to mention standardizing on 8 bit bytes 16 bit words 32 bit longs, signed and unsigned etc is just generally useful all around. Sounds obvious but historically not all processors have had such regularity which makes software portability a pain if not down right impossible.
P.S. Given how much of processor design "common wisdom" has been ignored in coming up with the Prop. I'm surprised Chip did not go for, say, 40 bit wide longs in the COGs thus allowing 16 times the amount of COG code in Prop II.
P.P.S. I'm very happy that a lot of that "common wisdom" is missing from the Prop by the way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If you were an ardent C programmer and the Prop chip was all you had. And for some strange reason you had never seen or heard of Spin and the Prop tools. What would you do?
I believe you would study the Prop architecture, discover the COGs and HUB, discover the existence of the byte code interpreter in ROM that runs at start up. Then you would sit down and create a C compiler that targets those byte codes. Realising that compiling to PASM is a lot of hard work for almost no benefit. Given that you are programmer and therefore very lazy you would probably create a back end for an existing compiler like GCC to do this.
You would create an assembler for your PASM code to run in COGs because you really want to create UARTs and video drivers etc but realizing you cannot call PASM in COG directly from your compiled C code you would emit those PASM blobs into a different space than the 32K HUB image in ROM.
Lets say you put the PASM blobs into the upper half of those 64K EEPROMs you have.
Now you are happy, you have 32K of code space for your C code (minus a 2K working buffer for COG loading) and 32K of space for your COG blobs.
Via some sneaky library you would arrange that the equivalent of COGNEW in your C code fetches the appropriate PASM blob from the upper 32K of EEPROM and starts a COG with it.
P.S. Shouldn't Parallax direct their energies into enabling the Prop tool to do what I describe in Spin, thus saving a lot of valuable and wasted HUB space that currently holds COG blobs in most peoples applications. This would be adding value to the Prop/Prop Tool sytem where as YANCC (Yet Another Not C Compiler) does not.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1) PMC which translates to Spin. This is the choice if it should be full compatible with existing and future Spin objects. And also Spin must be able to use PMC objects without changing. But this can only support a subset of C.
2) Catalina or ICC which compiles to LMM. This is the choice if you want Standard C and a higher speed.
Compiling to Bytecode is either the same as translating to Spin, or it is no more compatible to Spin's object concept.
I hate C as much as others here, and I really don't want to be forced to write the whole code in C only because a cool object
is only available in a not compatible PMC version.
The simplest solution for Parallax will be to support Catalina how it is, with Tutorials and documents. No integration in PropTool.
Just show in this tutorials how much easier the same could be done in Spin. So the teachers which start with C automatically
switches to Spin for more complicated projects, and then they are caught...
Clusso: As you see we are in agreement - Standard C compiled to byte code + PASM is the way to go.
"Would we use it?"
Undoubtedly yes.
If at the outset I had the choice of using C plus PASM rather than Spin + PASM I would have definitely gone for C. I would have been quite happy with a command line C to byte code compiler with a command line PASM assembler. Together with a command line tool that packaged those up into a 64K EEPROM image and downloaded to the Prop. Put it all together with a Make file and I'm set.
An IDE I don't need. There are many already. Synax highlighting for EMACS, VIM, whatever editor would be a bonus.
That is what the mystical "professional" developers are looking for.
Reason for all this is that I've worked in more languages than I can remember in my career. There was a time were pretty much every project I was part of as a freelancer was in a different language. For sure I did not want to be bothered with "yet another block structured, son of ALGOL, like language". So I would have passed by Spin.
Having said that I'm glad I was forced to use Spin. I've said it before but the Propeller + Spin + PASM + Prop Tool is a wonderful example of elegant simplicity. It takes a genius to come up with such simplicity.
Adding a NOT C cludge on top of that seems to be such a horrible insult to that elegance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That kind of capability, however ugly it may appear (and I do think it's rather ugly compared to SPIN+PASM), is why C continues to see very broad use today.
Heater: Exactly! That's the kind of thing people will do given the tools. It's gonna compete with SPIN + PASM, and I don't think that's a bad thing at all. Tons of people are going to see SPIN + PASM, know it rocks, and get their stuff done. Others, fighting that, would jump on C. IMHO, this is a win, win all around.
"C to SPIN bytecode" is very different from "C to bytecode".
PMC is currently "C to SPIN bytecode". But this approach cannot be ANSI C compliant because there are many required operations missing from the set of SPIN bytecodes - and there is no room in the current SPIN bytecode interpreter to add more. Simulating the missing operations using only the available SPIN bytecodes would be appallingly slow.
If PMC were just "C to bytecode" instead, it could be both space-efficient and maybe about the same speed as SPIN - but it would not be interoperable with the current SPIN bytecodes (i.e. you could not call current SPIN objects). Also, I'm not entirely convinced all the necessary bytecodes to implement PMC would fit in one cog anyway - I think you're more likely to need two.
To make it possible to do both - i.e. execute both SPIN and PMC bytecodes, I think you will need at least 3 cogs - one dedicated to SPIN, one (at least) dedicated to PMC, and one to coordinate between them. There is no way you are going to achieve SPIN speeds with a setup like this. PMC/SPIN interactions (e.g. calling SPIN functions from C) in particular would be terribly slow, due to the inter-cog coordination required.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
RossH: "C to SPIN bytecode" is very different from "C to bytecode".
Good point. I had not really divined that it was limitations in the current Spin byte codes that made C such a challenge.
RossH: "Also, I'm not entirely convinced all the necessary byte codes to implement PMC would fit in one cog anyway"
The Zog project proves that it is possible to put a byte code interpreter into a single COG that supports fully standard C. In fact GCC compiling C, C++ and FORTRAN at the moment.
Currently Zog uses about 40% more time to do anything (Well FIBO anyway) compared to Spin. I'm sure someone could come up with a more efficient byte code for C on the COG.
Inventing a new byte code and C compiler for it does not make much sense, too much work, unless you are going to make an entirely new Prop chip with that interpreter in ROM instead.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
Much of this is incorrect. C very early on became a platform independent language, and is now the language most widely implemented on any platform. It was specifically designed to implement things that required speed - like operating systems and device drivers - without having to resort to assembler. It is still widely used for this.
Anecdotally, it is always claimed that there are some C operators (like ++) that derived from the original PDP-11 arhitecture and instruction set - I don't know if this is true or not. Nor does it matter - the reason these operators persist is that they also map directly to many, many other instruction sets. Which is one reason C remains the most efficient language choice on so many platforms.
There are implementations of C that include buffer overun protection, just as there are memory management libraries that will do garbage collection for you - I can't see how this can be construed as an argument either for or against C itself. In any case, these things are most often used only during the early stages of development, and they would nearly always be turned off for production code - because of the need for speed.
The very complaints that localroger makes against C (e.g.. no bounds checking, no memory management) are in fact precisely the reasons why C is still so widely used in embedded environments, where such things are both unnecessary and undesirable.
I have already said that without it's speed advantage, C would not be a language of choice for many applications. And I agree with localroger that there is no "ideal" fit for C on the Prop I (on the Prop II, however, the answer is obvious - increased speed would be far preferrable to any space saving).
Fortunately, this is not really an "either-or" argument. If PMC were ANSI C compliant, it could be used to satisfy the teaching requirements. A massive investment in time and money (trust me on this!) but technically feasible.
To answer the professional requirement, when this discussion has died down there will still be Catalina and ICC.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
(1) I hate the syntax. Really hate it. Really, really, really hate it. I hate the way it uses every possible kind of enclosure punctuation, I hate that it totally ignores line breaks, and I hate the godd*** semicolons. It makes my eyes bleed. I hate the fact that it is even possible to have such a thing as an "obfuscation contest" based on it. And the fact that every other wanna-be serious language feels it has to emulate this ca. 1974 "my parser has to fit in 2K of RAM" look just rubs salt in that.
(2) I would agree with you that C it is the language of choice (or would be if the syntax didn't make my eyes bleed) for things like device drivers where you have the wiggle room not to need ASM. Spin itself has many of the same limitations because you can't afford those luxuries in a 32K workspace. My problem is that this close, efficient, fast, dangerous, hard to read language is then used to write billions of lines of business logic that could and should be written in a much safer, more readable but not so efficient language.
--Steve
You know, I'm beginning to suspect that you might have a mild antipathy towards C!
@Sapieha,
I can't argue with you on the drawbacks of C - they are well known.
However, I'm not sure it's true that micro manufacturers tailored their instruction sets specifically for C - after all, C does not require anything that any other procedural language would not also require - as can be seen by the fact that C is fairly readily implemented even on rather unusual architectures like the Propeller.
C itself is only one member of the ALGOL family of languages (which include C, Pascal, Modula-2, Simula, Ada, and many others). It would probably be correct to say that hardware manufacturers saw the need to improve support for all procedural languages. If they did anything specifically for C, it is likely to be mainly because they wanted to be "the fastest kid on the block" in the most popular language, and also because they saw the writing on the wall for those who did not at least offer reasonable support for C, even while they tried very hard to sell their own proprietary language (which many did!).
I think your point about modern instruction sets being too simplistic is not so much about C per se - it is more about RISC vs CISC architectures, and the difficulty of writing efficient compilers for any high-level language when the target platform is a CISC architecture. There is also the fact that on any processor, 90% of the processor's time is spent executing about 10% of the instruction set. Some instructions on CISC architectures are so complex (I'm thinking VAX here, but it may also apply to Intel) that I suspect they were never ever used!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
The Propeller is·operating on registers (cog memory) and L1·cache (hub) all the time, unless you implement external memory. So largely the main thing you are waiting for is external hardware that's connected to the data pins. Which I guess fits exactly what you said above. [noparse]:)[/noparse]
As for the C syntax, I don't mind it at all, but maybe that is just that I have been using it for 25+ years and it's just automatic for me (both in typing and reading).· Probably 90% of my compile errors in the Proptool are because I typed a semicolon on the end of a line or used some other C syntax.
So, I guess I wouldn't mind having a variant of Spin that used c-like syntax, which is what PMC sounds like so far. I just wouldn't try to call it C in any way shapre or form. Just call that Spin with c-like syntax.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Ok - that would explain it.
BTW, is your avatar a photo of you - 'cause it looks a lot like Charles Forbin from "Colossus:The Forbin Project" here - cool!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
8. PropTool. This IS THE MOST IMPORTANT ***** and everyone seems to be in agreement.
But 8 is already done. Maybe a few more improvements BUT..
and Brad is so quick with any bug fixes and excellent responses with requests.
So, this issue is easily solved - Parallax, make Brad an offer he cannot refuse, preferably keeping him to mantain it. If you like some features of the PropTool, give him the source and pay him to add them to bst.
Now for the other 7 points..
7. PropBasic - it works now, thanks to Bean.
3,4,5 - C to PASM (various flavours) - it works now - Catalina & ImageC.
6. Extended Spin - Keep for a later discussion. Sure there are some additions and improvements, but let us see where the C thing goes.
That leaves 1 & 2...
1. C to Spin (source) - we have one or two doing this but there seems to me that this is a kludge and has no real benefit in the long term. It has been a great idea to allow C to progress without access to the spin compiler, but it's just that.
2. C to bytecodes (Standard C to spin bytecodes)
This is an excellent idea and should be the way to go (after PropTool of course).
BTW: I hate C with a vengence, but it IS required.
It must be standard C (discussed above and I have to leave this to the experts.
It should also be part of the compiler (propTool). I would like to see it co-exist with Spin in the same source, just like PASM. I am not sure if this is feasible, but it would make the most sense. So you could just have
#include <stdio> '-> object VAR ..... OBJ ..... PUB ..... PRI ..... DAT ..... void main() { tv.out( getc() ); putc( kb.getkey() ); myfunction1(); for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2); completely understandable LOL!!! }Advantages..
Disadvantages..
Now, slower is most likely not an issue for·schools. It may not be an issue for commercial programmers with the mix of pasm objects. Spin is not an issue for a large part of the code we currently use. If it is an issue, then use Catalina or ImageC. Of course, with the PropII, speed should not be a problem, but I guess memory will still be a problem even with the extra we will get, just because we will use the PropII to get more elaborate hardware.
Could Parallax use the front-end of Catalina and output bytecode instead??? Ask Ross. This way we could have identical source code???
To summarise,
I am going to suggest you make some offers to the community to help develop Standard C to bytecode. Parallax resources are already stretched and as has been pointed out, a howto for PASM is required and this is not likely to be done by the forum. Use the forum for what they are interested in doing and do the stuff they aren't interested in·inhouse.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
-Phil
Yes, this is possible. But I'm not curently inclined to do it - for two reasons:
1. I originally abandoned SPIN in favor of C because SPIN was to slow to do what I wanted to do with the Propeller. I started work on Catalina only because I then discovered how little support there was for C on the Propeller. SPIN was too slow and PMC would be even slower.
2. I NOW know just how much work is required to get a complete compiler and development environment up and running - if I had known this when I started, I probably wouldn't have done it. The code generator is less than 5% of the job. I got Catalina's original code generator working in a couple of weeks, and it has required very few changes since that very first version (although it could certainly do with some optimization!). But it has taken almost exactly a year's worth of effort after that to then get Catalina to the level where it is now - i.e. a completely self-contained and platform independent development environment for the Propeller - one which does not depend on any Parallax products, either to compile, load or (with the latest release) debug C code.
I'm not sure I want to spend another year on this - this time for a version that I would never even be able to use! Of course, anyone else is welcome to have a go at this - Catalina is fully GPL-ed.
Interesting - I suspect this is largely marketing hype (we use AVR micros where I work, and as far as I can tell, their architecture doesn't appear to be optimized for just about anything! EDIT: actually, that's not quite true - they are very good at implementing low power modes - which is the main reason we use them in preference to other micros for our applications).
However, if true it does highlight that AVR believe C support is critical to their business, and also that it must be high performance support.
EDIT: Dang! sorry about editing my own post so many times. I'm not sure what keeps happening to my edits!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 4/19/2010 2:24:17 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
-Phil
With me, I don't really want it. SPIN + PASM kicks a lot of ***. I'm happy. But, if one wants C, and if one needs C, then a C that is built to use the byte codes, and that can directly build in PASM and or compile to PASM is gonna rock pretty hard, just like SPIN + PASM will, so why not do that?
It's going to be able to use a lot of PASM code already written. That's a plus. It's also going to make good use of the on chip intrepeter, just like SPIN does, and that's great too! Truth is, the C environment will permit the kinds of hacks needed to do all sorts of things that SPIN gets in the way of, so why not empower those people that would do those things?
I'll ask again. Is it the idea of actually competing with SPIN + PASM that's at issue? If so, let's have that discussion. It's necessary. If not, then where are the downsides?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/19/2010 4:42:33 AM GMT
Spin++ [noparse]:)[/noparse]
@Cluso99 don't feel bad. All the other times over the years that C compiled to spin byte code was mentioned invoked the same reaction from Ross. That's Ok though, it's his nickel.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
I agree with you 100% - C should not be seen as a replacement for either SPIN or PASM. It is a different tool for a different job. After all, how many toolkits contain only two tools? (Apart from BradC's, of course!). I also agree that C does not fit particularly well on the architecture of the Prop I (but it will be a different story on the Prop II).
But C on the Prop I is an alternative to both SPIN and PASM which many users would choose because:
- While it is not as fast as PASM, it is much faster than SPIN.
- You can write much larger programs than you can with PASM (or with SPIN, if you use XMM!)
- You can re-use zillions of lines of existing C source code.
My main point in this thread remains that PMC (as it is currently specified) does not really satisfy its stated goals, and is more likely to damage Parallax's reputation than enhance it. In particular, if it makes people believe it is somehow C compatible (which it will) but it cannot successfuly compile existing C software (which it won't) then users would be quite right to become a little annoyed when they find this out.If PMC were to be made ANSI C compliant then my major criticism would vanish. Many users still wouldn't use it because it would be too slow for their purposes, but some users would. If Parallax decides there are enough such users to justify such a tool then they should invest in it by all means. It won't occupy the same niche as Catalina - but even if it did, so what? - there are already two compilers occupying that particular niche anyway, just as there are three or four alternative SPIN compilers. Most processors have many alternative compilers - it's a good sign, because it means the processor is attracting real interest.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
humanoido
Why do you blame C?
Yes, modern processors have been designed in such a way as to make life easier for C compilers. But surely the features required to do that are of general benefit to a broad range of high level languages, ADA, Pascal, whatever.
Just happens that C has been the most popular but things like a flat memory space and efficient stack operation are required for most high level block structured languages. Not to mention standardizing on 8 bit bytes 16 bit words 32 bit longs, signed and unsigned etc is just generally useful all around. Sounds obvious but historically not all processors have had such regularity which makes software portability a pain if not down right impossible.
P.S. Given how much of processor design "common wisdom" has been ignored in coming up with the Prop. I'm surprised Chip did not go for, say, 40 bit wide longs in the COGs thus allowing 16 times the amount of COG code in Prop II.
P.P.S. I'm very happy that a lot of that "common wisdom" is missing from the Prop by the way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 4/19/2010 5:49:24 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Yeow! I have a 5 pound mallet and a 12" flat blade Stanley screwdriver. What more do you need?!?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
So you have four tools: Duct Tape, WD40, Mallet and Screwdriver.
Hmmm ... the only think I can think of that you're missing would be a bottle opener.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
BradC: "I have a 5 pound mallet and a 12" flat blade Stanley screwdriver." I thought you had Duct Tape & WD40 ??? LOL
Back to topic...
However, if we get C will we use it?? I probably won't. Would I have if given the choice between spin and C? I don't know.
I still like the·C to bytecode option.. why?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I believe you would study the Prop architecture, discover the COGs and HUB, discover the existence of the byte code interpreter in ROM that runs at start up. Then you would sit down and create a C compiler that targets those byte codes. Realising that compiling to PASM is a lot of hard work for almost no benefit. Given that you are programmer and therefore very lazy you would probably create a back end for an existing compiler like GCC to do this.
You would create an assembler for your PASM code to run in COGs because you really want to create UARTs and video drivers etc but realizing you cannot call PASM in COG directly from your compiled C code you would emit those PASM blobs into a different space than the 32K HUB image in ROM.
Lets say you put the PASM blobs into the upper half of those 64K EEPROMs you have.
Now you are happy, you have 32K of code space for your C code (minus a 2K working buffer for COG loading) and 32K of space for your COG blobs.
Via some sneaky library you would arrange that the equivalent of COGNEW in your C code fetches the appropriate PASM blob from the upper 32K of EEPROM and starts a COG with it.
P.S. Shouldn't Parallax direct their energies into enabling the Prop tool to do what I describe in Spin, thus saving a lot of valuable and wasted HUB space that currently holds COG blobs in most peoples applications. This would be adding value to the Prop/Prop Tool sytem where as YANCC (Yet Another Not C Compiler) does not.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1) PMC which translates to Spin. This is the choice if it should be full compatible with existing and future Spin objects. And also Spin must be able to use PMC objects without changing. But this can only support a subset of C.
2) Catalina or ICC which compiles to LMM. This is the choice if you want Standard C and a higher speed.
Compiling to Bytecode is either the same as translating to Spin, or it is no more compatible to Spin's object concept.
I hate C as much as others here, and I really don't want to be forced to write the whole code in C only because a cool object
is only available in a not compatible PMC version.
The simplest solution for Parallax will be to support Catalina how it is, with Tutorials and documents. No integration in PropTool.
Just show in this tutorials how much easier the same could be done in Spin. So the teachers which start with C automatically
switches to Spin for more complicated projects, and then they are caught...
Andy
"Would we use it?"
Undoubtedly yes.
If at the outset I had the choice of using C plus PASM rather than Spin + PASM I would have definitely gone for C. I would have been quite happy with a command line C to byte code compiler with a command line PASM assembler. Together with a command line tool that packaged those up into a 64K EEPROM image and downloaded to the Prop. Put it all together with a Make file and I'm set.
An IDE I don't need. There are many already. Synax highlighting for EMACS, VIM, whatever editor would be a bonus.
That is what the mystical "professional" developers are looking for.
Reason for all this is that I've worked in more languages than I can remember in my career. There was a time were pretty much every project I was part of as a freelancer was in a different language. For sure I did not want to be bothered with "yet another block structured, son of ALGOL, like language". So I would have passed by Spin.
Having said that I'm glad I was forced to use Spin. I've said it before but the Propeller + Spin + PASM + Prop Tool is a wonderful example of elegant simplicity. It takes a genius to come up with such simplicity.
Adding a NOT C cludge on top of that seems to be such a horrible insult to that elegance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater: Exactly! That's the kind of thing people will do given the tools. It's gonna compete with SPIN + PASM, and I don't think that's a bad thing at all. Tons of people are going to see SPIN + PASM, know it rocks, and get their stuff done. Others, fighting that, would jump on C. IMHO, this is a win, win all around.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
"C to SPIN bytecode" is very different from "C to bytecode".
PMC is currently "C to SPIN bytecode". But this approach cannot be ANSI C compliant because there are many required operations missing from the set of SPIN bytecodes - and there is no room in the current SPIN bytecode interpreter to add more. Simulating the missing operations using only the available SPIN bytecodes would be appallingly slow.
If PMC were just "C to bytecode" instead, it could be both space-efficient and maybe about the same speed as SPIN - but it would not be interoperable with the current SPIN bytecodes (i.e. you could not call current SPIN objects). Also, I'm not entirely convinced all the necessary bytecodes to implement PMC would fit in one cog anyway - I think you're more likely to need two.
To make it possible to do both - i.e. execute both SPIN and PMC bytecodes, I think you will need at least 3 cogs - one dedicated to SPIN, one (at least) dedicated to PMC, and one to coordinate between them. There is no way you are going to achieve SPIN speeds with a setup like this. PMC/SPIN interactions (e.g. calling SPIN functions from C) in particular would be terribly slow, due to the inter-cog coordination required.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Exactly!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Good point. I had not really divined that it was limitations in the current Spin byte codes that made C such a challenge.
RossH: "Also, I'm not entirely convinced all the necessary byte codes to implement PMC would fit in one cog anyway"
The Zog project proves that it is possible to put a byte code interpreter into a single COG that supports fully standard C. In fact GCC compiling C, C++ and FORTRAN at the moment.
Currently Zog uses about 40% more time to do anything (Well FIBO anyway) compared to Spin. I'm sure someone could come up with a more efficient byte code for C on the COG.
Inventing a new byte code and C compiler for it does not make much sense, too much work, unless you are going to make an entirely new Prop chip with that interpreter in ROM instead.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.