Wow - I stay away for a couple of days and come back to another language war - I love these things!
However, instead of contributing to this one, and rehashing all over again why I believe C is not only desirable, but also necessary on the Prop, I'll simply submit one argument:
Catalina C beta 5 now has a FAT32 file system
Did I write this file system myself? No - I couldn't possibly do so (I know very little about file systems, and am certainly not interested in exporing the internal workings of FAT32) - Instead, I simply found an ANSI C file system implementation on the internet (dosfs), and plugged it in. Adding file system support to Catalina didn't require a single source code change to dosfs - because it's also written in ANSI C.
Don't misunderstand me - I'm not knocking SPIN. And before anyone points this out, yes I know SPIN has an SD Card file system (albeit a very limited one which does not support FAT32) - that's all beside the point. which is ...
How many places can I go to find a complex algorithm implemented in SPIN when I need it?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
> People who mention that SPIN lacks things like Structures are TOTALLY missing the point of what a
> microcontroller is used for..................microcontrollers are not meant to be a replacement for a
> Computer like the PC or Mac
Then you completely missed the point about structures. COMPLETELY. And this for someone who says he's been programming for 35(?) years.
What has a structure to do with the size and complexity of a program? Or with the OS? Or the processor or µC?
It's a language-element for structuring and hiding information. And SPIN is completely missing it. Just have a look at *ANY* interface to PASM and you'll discover that either space is wasted by using 4 bytes for parameters where 1 or 2 bytes would be enough or how people mask, shift and patch bytes into longs.
In C, you'd only pass a structure with all the elements in the right size. And for example an 'assert(sizeof(theStructure) == 4)' helps avoiding slips during development.
Or as an other example:
In Mike Greens i2c/sdi - routines, he's using a control-block of 2 longs. You hust have to provide it to the routines. "Needs to be 2 longs", and if you slip to observe that, you might have lost and needlessly chase errors for hours. In C, just make a typedef of the structure and require that type as parameter. No chance to make it wrong. No extra code generated for typedef 'cause its a compile-time check.
I'm really astonished how an experienced programmer can make such a statement!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
In Mike Greens i2c/sdi - routines, he's using a control-block of 2 longs. You hust have to provide it to the routines. "Needs to be 2 longs", and if you slip to observe that, you might have lost and needlessly chase errors for hours. In C, just make a typedef of the structure and require that type as parameter. No chance to make it wrong. No extra code generated for typedef 'cause its a compile-time check.
So you are telling me C is not error prone...... Could one not overflow a pointer and end up chasing a bug for Months????? That is if he is lucky to
discover the error before shipping the product.....
If you are going to tell me that experienced programmers do not make such mistakes with C then the thousands of programmers
at Microsoft and IBM and and and are all lesser programmers than you allmighty Nick......
> So you are telling me C is not error prone......
I said it once, I say it twice: There are tools, libraries and techniques to avoid -or at least reduce- them. Obviously, you've never heard of them. Or you wouldn't repeat that over and over again.
And then, in a next sentence you say that a language for a µC needs to offer lowest level access.
Now what you you really want?
A language that is always safe, one that can be safe, or one that doesn't even offer the lowest level of language-elements for checks/safetiness?
> Could one not overflow a pointer and end up chasing a bug for Months?????
Yes, you *can*, if you *want* to. But better: see above.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
Nick Mueller said...
> So you are telling me C is not error prone......
I said it once, I say it twice: There are tools, libraries and techniques to avoid -or at least reduce- them. Obviously, you've never heard of them. Or you wouldn't repeat that over and over again.
And then, in a next sentence you say that a language for a µC needs to offer lowest level access.
Now what you you really want?
A language that is always safe, one that can be safe, or one that doesn't even offer the lowest level of language-elements for checks/safetiness?
> Could one not overflow a pointer and end up chasing a bug for Months?????
Yes, you *can*, if you *want* to. But better: see above.
Nick
I am dismayed that Bill Gates has never hired you.....with your wisdom and abilities we won't have to have an endless daily upgrade for Windows and the plethora of softwares that are plagued with a myriad of errors. · Nick, I think you should go and reeducate the lowly programmers at all these inferior programming houses that keep churning out error ridden software written in C and C++ the language that you obviously have figured out how to make error free..............you will make millions.......... · If only all those lowly programmers who obviously do not have your skill could join in this forum and read your gems of wisdom about how to make C an error free language.
And oh thank you for enlightening me about the libraries in C ..... I have never heard of them before since my programs are only a few hundreds of thousands of lines I never saw the need for libraries or tools before...... ·
Post Edited (SamMishal) : 7/5/2009 12:59:32 PM GMT
On the other hand, I've been happily running a Linux only PC for 10 years or more, most of the software I use has been written in C or C++ from the kernel to the web browser. Mostly it works just fine. Not sure where Bill Gate's crew went wrong.
I think it was RossH who came up with the answer to this debate. He mused over the idea of an Ada compiler for the Propeller!! That would give you all the type checking, range checking etc safety and security you could dream of.
Trouble is, it seemed to me, that not many programmers liked to work in that straight jacket for some reason.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
> Nick, I think you should go and reeducate the lowly programmers ...
They are called coding-cowboys, not programmers!
And if they are interested, they can reeducate themselves. By reading some good books, and not just MS-gazettes.
But as long as they are not interested and only live by kLOC, they keep on reporting over and over again from their little world that they think is the garden of Eden.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
[color=black]I think the problem is that some people are not able to distinguish between a [/color][color=black]microcontroller [/color]
[color=black]and a computer. And the propeller being such a wonderful and powerful chip [/color][color=black]is partly to blame....[/color]
[color=black][color=black][b]it is not helping since its capability and power is in a way blurring the [/b][/color][b][color=black]delineation between the two[/color][/b][color=black]............[/color]
[/color]
This is an interesting observation.· Whether the prop is a "computer" depends a lot on historical context.· The most popular computing platform in history only had 64K RAM and no standard mass storage.· I know people who ran businesses for years with Commodore 64's.· I/O and memory wise a C64 looks an awful lot like a Propeller Demo Board, except that it had only one 8-bit 2 MHz CPU instead of 8 80 MHz cores.· Considering all the things people did with C64's I think it would be quite a stretch, even today, to say that a C64 "isn't a computer."· It was after all more powerful and faster than the DEC PDP-11, the machine we have to blame for UNIX and C.
Another commonality between those computers and the prop is that much programming was real-time and involved cycle counting the instructions.· Anybody remember using the vertical interrupt to get the display to do impossible things?· You absolutely cannot do that kind of programming in anything other than assembly language, but I don't recall anybody suggesting that the C64 wasn't a real computer because such programming was so common.· In fact, I remember a long conversation with a big iron hacker about how similar techniques were useful in some of the stuff he was doing on mainframes, where tight management of the memory paging and·could come in useful.
The fact that we now all have machines sitting on our desktops and embedded in our TV sets and our cars and doorbells that could cheat a C64 at poker and talk it into voting Republican does not mean that those older platforms weren't or aren't useful, and much of the charm of the prop is that it invites us to go back to that mindset; with its unexpandable 32K and clock-rigid timing it's like the modern incarnation of a C64, only it costs $12 instead of $300 (and that in 1982).· It can also go into ridiculously low power modes when appropriate, another trick most "real computers" don't know.
But modern computing techniques can't be·used on limited platforms; all that wonderful abstraction costs RAM and CPU cycles which you inevitably need for your actual application.· If you want the quintessential high level language for this kind of programming, it's the "write-only" language FORTH.· And if you look under the hood, the first thing you notice about Spin is that its byte code is incredibly FORTH like.
So what I guess I'm getting around to is this:· Saying C is necessary for the prop is like saying Visual Basic is necessary for the C64.· Yes you could build something like that but mostly you wouldn't want to use it because you need the RAM and efficiency for your application.· (And before you say the comparison is ridiculous, look up GEOS.· That's right, there WAS a visual IDE for the C64, and it was quite popular; but it was used mostly for its bundled functions, and not many commercial applications used it.)· The situation with the prop is similar.· You could build something that general-purpose, and several people have taken stabs at it; but it keeps coming back to Spin and pasm because those are the tightest solutions for memory efficiency and speed, respectively.·
As for the prop needing C, I'd say that if you want to use the prop you will learn Spin and pasm or you'll find another chip; there's no shortage of other chips, most of which were actually designed with C in mind.··But if you want what the prop can do for the prop's price point, you'll learn Spin and pasm so you can use it.
> Saying C is necessary for the prop is like saying Visual Basic is necessary for the C64.
This was a better shot, but still missed.
Problem: You mixed the language and its implementation. Like almost all posters in the thread did.
Think of an C-frontend that only tokenizes and downloads the result to the Prop for interpreting.
Win 1: Not fully interpreted, because the time-expensive part of tokenizing (that would have been to be made over and over and over again) is missing.
Win 2: All compile-time checking (and thats all the checking C offers) is done on the PC
Win 3: Code should be more compact then pure ASM
Or a C-compiler that generates code for a virtual machine (p-code, p-machine). Then you should be quite close to SPIN size-wise and speed-wise. And now if that compiler supports a "#pragma _native", you could wind out the time-critical parts in PASM.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
@Nick -- #pragma _native will not work on the prop because if you are compiling to byte code, the cog running the code is running the byte code interpreter, and you can't add more pasm and make a call to it; you must start a new cog and create a way to communicate to it what it's supposed to do and how to return any results to your mainline code.
There are really only a very limited number of ways a C compiler could work on the prop, just about all of which have been explored:
1. You can compile to byte code. Congratulations, you have invented a version of Spin which Parallax doesn't support.
2. You can compile to the LMM. This will be more memory bloaty than #1 and therefore not suitable for apps that are tight on memory (which will be nearly all of them), and considerably slower than #3 and therefore not as suitable for high speed I/O controls.
3. You can compile to pasm, in which case you are compiling to cog, not hub RAM limits and no native stack. You could probably create a version of C crippled enough to run in a cog but it would be extremely limited, nonstandard, and inferior to pasm for real work.
The most practical approach would probably be #1 compiling to Spin byte code, but using C syntax and adding some of the C struct stuff, conditional compilation, compiler checks and so on that Spin lacks. The Spin interpreter implements the stack, which you need for any recognizable implementation of C. But if you want to add functionality, you will need to write your own interpreter instead of using the native one (buh-bye, 4K of RAM) and any tradeoffs you make for added functionality will probably be paid for in slower execution.
Nick: Whilst you are right, time critical parts get done in PASM, no matter if you are working in Spin or C or whatever. I don't think we will ever see the #pragma_native on the Prop.
Reason is that no one is going to write a C compiler that generates native PASM, it just does not make sense, the COG space is too small and the instruction set just does not suit. Therefore the concept of in-line PASM in C (Or othr HLL) does not make a lot of sense. What should it do? Stop the current byte code interpreter on LMM kernel and load the COG with the in-line PASM, run that and then stop the COG and restart the interpreter/kernel at the appropriate point in the code. Or should it fire up a new COG to run the PASM and wait for the results? All or which demolishes the speed gains of any PASM fragments that are in-line.
No reason we could not have in-line LMM code or byte codes I guess but that's not giving us the full steam ahead speed we want either.
No, I think we will continue to see hand coded PASM tasks running in COGS and communicating with Spin/C/languageX through messages in HUB RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
> @Nick -- #pragma _native will not work on the prop because if you are compiling to byte code,
Sorry, you are right! I thought about generating code for LMM (or such) when I wrote that.
I'm aware of cog and hub and such.
Edit:
And no, I do not think it makes sense to generate code to run completely in one COG from a high-level language. Thats where ASM shines. Interfacing that to any language is not complicated when you pick that scheme with an communication area.
Edit 2:
What I like so much about the Propeller are the 8 cogs. One is running a master/scheduler/supervisor/arbiter in an high-level language, and the rest is busyly doing the hard work. Either in ASM or in some cases in a high-level language.
Its a waste of resources to let run only one cog doing a high level-program, while the rest is sitting there doing nothing. Propeller is such a wonderful parallel-processing world.
When I was younger, I couldn't afford to buy some Transputer-boards for playing around. Just had the money for the book about Occam.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
Post Edited (Nick Mueller) : 7/5/2009 4:13:07 PM GMT
I guess He understood that it is not necessary to have "C" language to program Propeller.
In my opinion no matter what language is used only at that language does this job.
And as You said PASM in first place SPIN in most casses and other languages if them can fully suport PROPELLER's unique architecture.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
I guess He understood that it is not necessary to have "C" language to program Propeller.
In my opinion no matter what language is used only at that language does this job.
And as You said PASM in first place SPIN in most casses and other languages if them can fully suport PROPELLER's unique architecture.
Ah.....but is he put off by the fact that PASM does not have structures and libraries of tools that Nick has
imagined would stop him from making errors????
Also PASM not having #pragma_native and other directives is such a bummer that Markuster must be lamenting all his
dashed hopes·for pogramming the Propeller to be an $8 replacement for Linux and Windows machines and perhaps
even the System 360......
But I am sure SUPER NICK would find a way to overcome these microcontroller limitations just like he found
a way of making C error free............. I am Looking forward to the day that Mighty Nick comes out with the next
version of Linux that runs on the Propeller.....
Is it that what you tell your boss when your programs crash "Hey boss, not my fault! C is not error free!".
Your arguments are getting more and more funny.
First you said, that structures are not for µC, but only for computers. Then it was, that you *can* have overrunning pointers and now it's the **language** that is not error-free.
Do you work at MS?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
As for the prop needing C, I'd say that if you want to use the prop you will learn Spin and pasm or you'll find another chip; there's no shortage of other chips, most of which were actually designed with C in mind.··But if you want what the prop can do for the prop's price point, you'll learn Spin and pasm so you can use it.
Absolutely.................................that is all I am trying to say………… · and us "coding-cowboys" are able to learn other languages and can live with the fact that we need to read the manual so that we reduce errors without resorting to libraries and tools that are in themselves full of errors since they were programmed by other coding-cowboys. · Yeehaa.......Rolling Rolling Rolling........(I am sure 90% of people on this forum do not know what this refers to). · · Sam ·
> and us "coding-cowboys" are able to learn other languages and can live with the fact that
> we need to read the manual so that we reduce errors without resorting to libraries and tools
> that are in themselves full of errors since they were programmed by other coding-cowboys.
Ah! Now I understand your point. You aren't actually programming anything. You just think about possibly programming. Maybe.
Because there could be an error -no, there **MUST** be an error in SPIN. So ASM is the one and only language even for complex programs.
But wait ... what about the errors in PASM?
You'd better stay away from computers, they are full of tons and tons of errors.
Blues brothers!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
What we are talking about, at the bottom line, is arranging a bunch of transistors to be on or off such that the circuit they sit in does what we want. If you get what you (or your boss/customer) wants then you win if not you lose.
How you do that is up to you. You can do it with toggle switches, you can be sophisticated and use tools to do it in hex, or asm, or C, or ADA or whatever you like. The choice is yours.
All those sophisticated tools are just a figment of someone's imagination.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I want to buy the Propeller but I don't want to buy the C compiler.
I saw that the trial version is 45 days. After 45 days the the code is reduced to 2k.
But I would like to know if there is an other difference with the commercial edition.
Thanks, Mark.
Hi Mark,
The memory limit is one difference. Another difference is you get access to most of the ICC library source.
Richard ImageCraft might have more to add .... Best of luck.
Keep them doggies rollin' ... 60's TV uugh ... at least it was better than most of the news.
Comments
Wow - I stay away for a couple of days and come back to another language war - I love these things!
However, instead of contributing to this one, and rehashing all over again why I believe C is not only desirable, but also necessary on the Prop, I'll simply submit one argument:
Catalina C beta 5 now has a FAT32 file system
Did I write this file system myself? No - I couldn't possibly do so (I know very little about file systems, and am certainly not interested in exporing the internal workings of FAT32) - Instead, I simply found an ANSI C file system implementation on the internet (dosfs), and plugged it in. Adding file system support to Catalina didn't require a single source code change to dosfs - because it's also written in ANSI C.
Don't misunderstand me - I'm not knocking SPIN. And before anyone points this out, yes I know SPIN has an SD Card file system (albeit a very limited one which does not support FAT32) - that's all beside the point. which is ...
How many places can I go to find a complex algorithm implemented in SPIN when I need it?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
> microcontroller is used for..................microcontrollers are not meant to be a replacement for a
> Computer like the PC or Mac
Then you completely missed the point about structures. COMPLETELY. And this for someone who says he's been programming for 35(?) years.
What has a structure to do with the size and complexity of a program? Or with the OS? Or the processor or µC?
It's a language-element for structuring and hiding information. And SPIN is completely missing it. Just have a look at *ANY* interface to PASM and you'll discover that either space is wasted by using 4 bytes for parameters where 1 or 2 bytes would be enough or how people mask, shift and patch bytes into longs.
In C, you'd only pass a structure with all the elements in the right size. And for example an 'assert(sizeof(theStructure) == 4)' helps avoiding slips during development.
Or as an other example:
In Mike Greens i2c/sdi - routines, he's using a control-block of 2 longs. You hust have to provide it to the routines. "Needs to be 2 longs", and if you slip to observe that, you might have lost and needlessly chase errors for hours. In C, just make a typedef of the structure and require that type as parameter. No chance to make it wrong. No extra code generated for typedef 'cause its a compile-time check.
I'm really astonished how an experienced programmer can make such a statement!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
discover the error before shipping the product.....
If you are going to tell me that experienced programmers do not make such mistakes with C then the thousands of programmers
at Microsoft and IBM and and and are all lesser programmers than you allmighty Nick......
Sam
·
I said it once, I say it twice: There are tools, libraries and techniques to avoid -or at least reduce- them. Obviously, you've never heard of them. Or you wouldn't repeat that over and over again.
And then, in a next sentence you say that a language for a µC needs to offer lowest level access.
Now what you you really want?
A language that is always safe, one that can be safe, or one that doesn't even offer the lowest level of language-elements for checks/safetiness?
> Could one not overflow a pointer and end up chasing a bug for Months?????
Yes, you *can*, if you *want* to. But better: see above.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
have to have an endless daily upgrade for Windows and the plethora of softwares that are plagued with
a myriad of errors.
·
Nick, I think you should go and reeducate the lowly programmers at all these inferior programming
houses that keep churning out error ridden software written in C and C++ the language that you
obviously have figured out how to make error free..............you will make millions..........
·
If only all those lowly programmers who obviously do not have your skill could join in this forum and
read your gems of wisdom about how to make C an error free language.
And oh thank you for enlightening me about the libraries in C ..... I have never heard of them before
since my programs are only a few hundreds of thousands of lines I never saw the need for libraries
or tools before......
·
Post Edited (SamMishal) : 7/5/2009 12:59:32 PM GMT
I think it was RossH who came up with the answer to this debate. He mused over the idea of an Ada compiler for the Propeller!! That would give you all the type checking, range checking etc safety and security you could dream of.
Trouble is, it seemed to me, that not many programmers liked to work in that straight jacket for some reason.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
They are called coding-cowboys, not programmers!
And if they are interested, they can reeducate themselves. By reading some good books, and not just MS-gazettes.
But as long as they are not interested and only live by kLOC, they keep on reporting over and over again from their little world that they think is the garden of Eden.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
This is an interesting observation.· Whether the prop is a "computer" depends a lot on historical context.· The most popular computing platform in history only had 64K RAM and no standard mass storage.· I know people who ran businesses for years with Commodore 64's.· I/O and memory wise a C64 looks an awful lot like a Propeller Demo Board, except that it had only one 8-bit 2 MHz CPU instead of 8 80 MHz cores.· Considering all the things people did with C64's I think it would be quite a stretch, even today, to say that a C64 "isn't a computer."· It was after all more powerful and faster than the DEC PDP-11, the machine we have to blame for UNIX and C.
Another commonality between those computers and the prop is that much programming was real-time and involved cycle counting the instructions.· Anybody remember using the vertical interrupt to get the display to do impossible things?· You absolutely cannot do that kind of programming in anything other than assembly language, but I don't recall anybody suggesting that the C64 wasn't a real computer because such programming was so common.· In fact, I remember a long conversation with a big iron hacker about how similar techniques were useful in some of the stuff he was doing on mainframes, where tight management of the memory paging and·could come in useful.
The fact that we now all have machines sitting on our desktops and embedded in our TV sets and our cars and doorbells that could cheat a C64 at poker and talk it into voting Republican does not mean that those older platforms weren't or aren't useful, and much of the charm of the prop is that it invites us to go back to that mindset; with its unexpandable 32K and clock-rigid timing it's like the modern incarnation of a C64, only it costs $12 instead of $300 (and that in 1982).· It can also go into ridiculously low power modes when appropriate, another trick most "real computers" don't know.
But modern computing techniques can't be·used on limited platforms; all that wonderful abstraction costs RAM and CPU cycles which you inevitably need for your actual application.· If you want the quintessential high level language for this kind of programming, it's the "write-only" language FORTH.· And if you look under the hood, the first thing you notice about Spin is that its byte code is incredibly FORTH like.
So what I guess I'm getting around to is this:· Saying C is necessary for the prop is like saying Visual Basic is necessary for the C64.· Yes you could build something like that but mostly you wouldn't want to use it because you need the RAM and efficiency for your application.· (And before you say the comparison is ridiculous, look up GEOS.· That's right, there WAS a visual IDE for the C64, and it was quite popular; but it was used mostly for its bundled functions, and not many commercial applications used it.)· The situation with the prop is similar.· You could build something that general-purpose, and several people have taken stabs at it; but it keeps coming back to Spin and pasm because those are the tightest solutions for memory efficiency and speed, respectively.·
As for the prop needing C, I'd say that if you want to use the prop you will learn Spin and pasm or you'll find another chip; there's no shortage of other chips, most of which were actually designed with C in mind.··But if you want what the prop can do for the prop's price point, you'll learn Spin and pasm so you can use it.
This was a better shot, but still missed.
Problem: You mixed the language and its implementation. Like almost all posters in the thread did.
Think of an C-frontend that only tokenizes and downloads the result to the Prop for interpreting.
Win 1: Not fully interpreted, because the time-expensive part of tokenizing (that would have been to be made over and over and over again) is missing.
Win 2: All compile-time checking (and thats all the checking C offers) is done on the PC
Win 3: Code should be more compact then pure ASM
Or a C-compiler that generates code for a virtual machine (p-code, p-machine). Then you should be quite close to SPIN size-wise and speed-wise. And now if that compiler supports a "#pragma _native", you could wind out the time-critical parts in PASM.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
There are really only a very limited number of ways a C compiler could work on the prop, just about all of which have been explored:
1. You can compile to byte code. Congratulations, you have invented a version of Spin which Parallax doesn't support.
2. You can compile to the LMM. This will be more memory bloaty than #1 and therefore not suitable for apps that are tight on memory (which will be nearly all of them), and considerably slower than #3 and therefore not as suitable for high speed I/O controls.
3. You can compile to pasm, in which case you are compiling to cog, not hub RAM limits and no native stack. You could probably create a version of C crippled enough to run in a cog but it would be extremely limited, nonstandard, and inferior to pasm for real work.
The most practical approach would probably be #1 compiling to Spin byte code, but using C syntax and adding some of the C struct stuff, conditional compilation, compiler checks and so on that Spin lacks. The Spin interpreter implements the stack, which you need for any recognizable implementation of C. But if you want to add functionality, you will need to write your own interpreter instead of using the native one (buh-bye, 4K of RAM) and any tradeoffs you make for added functionality will probably be paid for in slower execution.
Reason is that no one is going to write a C compiler that generates native PASM, it just does not make sense, the COG space is too small and the instruction set just does not suit. Therefore the concept of in-line PASM in C (Or othr HLL) does not make a lot of sense. What should it do? Stop the current byte code interpreter on LMM kernel and load the COG with the in-line PASM, run that and then stop the COG and restart the interpreter/kernel at the appropriate point in the code. Or should it fire up a new COG to run the PASM and wait for the results? All or which demolishes the speed gains of any PASM fragments that are in-line.
No reason we could not have in-line LMM code or byte codes I guess but that's not giving us the full steam ahead speed we want either.
No, I think we will continue to see hand coded PASM tasks running in COGS and communicating with Spin/C/languageX through messages in HUB RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Sorry, you are right! I thought about generating code for LMM (or such) when I wrote that.
I'm aware of cog and hub and such.
Edit:
And no, I do not think it makes sense to generate code to run completely in one COG from a high-level language. Thats where ASM shines. Interfacing that to any language is not complicated when you pick that scheme with an communication area.
Edit 2:
What I like so much about the Propeller are the 8 cogs. One is running a master/scheduler/supervisor/arbiter in an high-level language, and the rest is busyly doing the hard work. Either in ASM or in some cases in a high-level language.
Its a waste of resources to let run only one cog doing a high level-program, while the rest is sitting there doing nothing. Propeller is such a wonderful parallel-processing world.
When I was younger, I couldn't afford to buy some Transputer-boards for playing around. Just had the money for the book about Occam.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Post Edited (Nick Mueller) : 7/5/2009 4:13:07 PM GMT
I guess He understood that it is not necessary to have "C" language to program Propeller.
In my opinion no matter what language is used only at that language does this job.
And as You said PASM in first place SPIN in most casses and other languages if them can fully suport PROPELLER's unique architecture.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 7/5/2009 4:24:38 PM GMT
imagined would stop him from making errors????
Also PASM not having #pragma_native and other directives is such a bummer that Markuster must be lamenting all his
dashed hopes·for pogramming the Propeller to be an $8 replacement for Linux and Windows machines and perhaps
even the System 360......
But I am sure SUPER NICK would find a way to overcome these microcontroller limitations just like he found
a way of making C error free............. I am Looking forward to the day that Mighty Nick comes out with the next
version of Linux that runs on the Propeller.....
Sam
·
Is it that what you tell your boss when your programs crash "Hey boss, not my fault! C is not error free!".
Your arguments are getting more and more funny.
First you said, that structures are not for µC, but only for computers. Then it was, that you *can* have overrunning pointers and now it's the **language** that is not error-free.
Do you work at MS?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
·
and us "coding-cowboys" are able to learn other languages and can live with the fact that we
need to read the manual so that we reduce errors without resorting to libraries and tools
that are in themselves full of errors since they were programmed by other coding-cowboys.
·
Yeehaa.......Rolling Rolling Rolling........(I am sure 90% of people on this forum do not know what this refers to).
·
·
Sam
·
> we need to read the manual so that we reduce errors without resorting to libraries and tools
> that are in themselves full of errors since they were programmed by other coding-cowboys.
Ah! Now I understand your point. You aren't actually programming anything. You just think about possibly programming. Maybe.
Because there could be an error -no, there **MUST** be an error in SPIN. So ASM is the one and only language even for complex programs.
But wait ... what about the errors in PASM?
You'd better stay away from computers, they are full of tons and tons of errors.
Blues brothers!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Sam and Nick: the way you're bashing each other, I'll bet you both will soon have " Raw Hides "
<rimshot>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sam
·
What we are talking about, at the bottom line, is arranging a bunch of transistors to be on or off such that the circuit they sit in does what we want. If you get what you (or your boss/customer) wants then you win if not you lose.
How you do that is up to you. You can do it with toggle switches, you can be sophisticated and use tools to do it in hex, or asm, or C, or ADA or whatever you like. The choice is yours.
All those sophisticated tools are just a figment of someone's imagination.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hi Mark,
The memory limit is one difference. Another difference is you get access to most of the ICC library source.
Richard ImageCraft might have more to add .... Best of luck.
Keep them doggies rollin' ... 60's TV uugh
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230