Quite so PullMoll. Spin works, PASM works. The whole system including the: Prop, Spin, PASM, Prop Tool and OBEX is a wonderful, simple to use and productive thing.
Why do we want to muddy it up with "not C".
Use what we have and get those emulators built, err no, I mean get on with your projects. In this compatible, sharing and harmonious Propeller environment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Roy Eltham said...
Is C++ really all that far removed from C? I mean seriously, when it comes down to the nuts and bolts of it (as in what actually ends up being spit out the backend) the main difference is some indirection tables. The only other things that truly involve significantly different output code are exception handling and RTTI. Most of C++ is just shorthand ways of doing things you can do in C with a lot more typing, and most of that is handled by the frontend of the compiler. I guess the real issue is that it's easier to write code that results in larger backend output. Not really because it's less efficient, but because it's actually doing more. Anyway, I for one would be happy to have a C++ compiler for my embedded stuff. [noparse]:)[/noparse] I realize that's impractical for the Prop1, but I expect I will get C++ on the Prop2.
I honestly hope C++ never raises its ugly head on the Prop II - but I expect it will.
C++ is completely impractical in embedded environments. It is silly to even contemplate putting C++ on a microcontroller constrained to 32kb, and is only slighly less silly to contemplate putting it on one constrained to only 300kb. Better minds than mine have taken C++ and tried to remove some of the functionality that is so detrimental in embedded applications - and ended up with an awful shambles of a language called EC++ (see here).
C - for all it's drawbacks - shares with SPIN an elegant and orthogonal simplicity. C++ has most of the drawbacks of C, but then goes and adds a truckload more all of its own.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
This is short... I will add a longer post later (lost a big one I prepared).
I think an OS will rock on the Prop II, and will live on the Prop I. But it will not be *nix nor CPM (although I expect CPM will be able to be called from it).
I expect it will be a simple CPM/DOS style so we can edit and compile (albeit possibly slow for larger programs) on the prop (i.e. Self-hosting). Why do I think this? I have a vision of a small self-contained pcb in a case with some mix of keyboard, mouse TV, VGA, sound, game controllers, microSD, LAN, USB OTG, and WiFi. The Prop I or II is ideally suited to this and would be a complete and cheap learning tool. It certainly does not want the complexity of *nix systems. The keyboards, TVs, etc are already plentiful these days.
I am keen to add my input to the PropTool debate including open source (to come later tonight maybe).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Ken Gracey (Parallax) said...
I learn from comments on the open-source subject. My post may not be very professional, but neither are some of the OS releases I've seen.
Just a nit-pick, but I had to read this a number of times to parse it. I don't think I've ever seen "OS" used to shorten open-source. It's mostly used to represent "Operating System" or "Over Seas".
I spent a number of cycles trying to figure out which operating systems you'd been looking at that were un-professional.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
heater said...
ImageCraft: I must insist. ZOG is not an emulator.
.
Fine, whatever, I am not here to argue the exact semantics of words, but the idea.
I stated my case, C executing on LMM C is fundamentally different in philosophy than porting a virtual CPU. You may argue with the semantic, but the difference is real.
Don't think as a hobbyist, think of it as a company selling a product.
Any flaws with LMM C is not because of the LMM, but the memory limitation of the Propeller. We, as a commercial compiler provider, can proudly sell Propeller C.
However, if we port ZOG, solely because it is there, and it has GCC, and try to sell GCC on Propeller based on that architecture, that's a failing business model.
I'm done with this thread. Mincing words is not my interest.
heater said...
Correct me if I'm wrong but both ICC and Catalina are based on the idea of building a kernel that executes on the Prop that then executes the output of C compilers. In both cases the compilers are existing C compilers that have had there code generation back ends modified to emit code for the kernels that have been created.
I hate to call down the curses of Zog on my head (again!) but I think I have to agree with Imagecraft on this one.
I don't pretend to know much about ICC, but there is a fundamental difference between Catalina and Zog. Catalina produces PASM - pure and simple PASM - which could be executed directly on a cog if that cog had enough RAM. Actually, I seem to remember jazzed saying that the ICC compiler can in fact do this - but it seems a rather pointless feature because there isn't a whole lot of C you can fit in the few hundred instructions (some cog space would necessarily lost to housekeeping and overhead) which you probably wouldn't be better off hand-coding in PASM in the first place!
Anyway, the point is that you can think of LMM as implementing a "virtual" cog, in much the same way that virtual memory extends the physical memory of other processors. LMM does not change the machine in any material way. It does not change the architecture. It does not add new functionality. It's really just a way of "extending" the physical address space.
Also, if you think about it, normal PASM programs routinely employ the tricks employed by an LMM kernel in any case - code overlays are a fairly common technique in PASM - just because they are called FCACHEs in LMM doesn't make them anything new. In fact, you can think of the whole LMM "loop" as just a bunch of single instruction overlays. Or you can think of it as a tight loop of self-modifying code - another very common PASM technique (due to the lack of indirect addressing on the Prop).
Yes, the Catalina LMM implements "primitives" that make it easier to generate code for stack/frame based procedural languages - but this is no different from many other compilers on many other architectures. It's only recently that most microcomputers come with specific stack and frame manipulation instructions anyway. The early IBM minicomputer architectures had no specific stack pointer - you just used any ordinary register, and incremented and decremented it youself. And saved your own registers on entry to a subroutine, and restored them before you exited. Often, you wrote simple library functions to manage all this for you - exactly what Catalina does in its LMM primitves.
On the Prop II, I think this technique will fit so naturally that people will be wondering what all the fuss was about.
Ross.
P.S. My, but this thread seems to have diverged from it's original intent. I was really interested in hearing Parallax's response to our comments. Maybe they've been a bit nonplussed by the intensity of reaction their document has generated!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Ken Gracey (Parallax) said...
I learn from comments on the open-source subject. My post may not be very professional, but neither are some of the OS releases I've seen.
Just a nit-pick, but I had to read this a number of times to parse it. I don't think I've ever seen "OS" used to shorten open-source.
Sure you have, it's just that it was inside "FOSS"
If I take a junk of Catalina binary and throw it into a COG it ain't going to run as I expect a junk of normal PASM to run. Not with out the VM kernel to support it.
If I take that junk of binary and throw it at an ICC kernel it ain't going to run either. Wrong Virtual Machine. And vice versa.
So yes LMM uses native instructions of the Prop, yes the difference is real, as can be seen by the performance gap between ICC, Catalina and poor old Zog. But it's all a VM anyway in my mind.
Let's agree to disagree on the terminology here, I think we all know what we mean any way, and get back to the topic. What should Parallax do about C on the Prop?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Okay - If you promise to put Zog back in his ice block, we can get back to the topic in hand.
I'm a bit concerned that we are losing sight of the original thread. The trouble is that we've all trotted out our usual arguments - without actually changing anybody else's minds - and now we're just meandering off while we wait for more input. Perhaps this was a deliberate tactic by Parallax to just let us waffle on till we ran out of steam?
If so, it worked - I'm off to bed!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
"Perhaps this was a deliberate tactic by Parallax to just let us waffle on till we ran out of steam?"
This was done before, anybody remember the 'Open Sourcing of Propeller IDE' thread that was started by Chip? That also was a very long thread where everybody expressed their feelings about 'OpenSource'. Did we ever see an answer to that, from Parallax? I am not complaining, just would like to know if any of our input was used.
Ken had me going with the "os" thing also, I started to think that Parallax was going to be presenting an Operating System (OS,os) for the Propeller. I guess we will have to quit using abbreviations, this is leading to some confusion.
Has anybody kept a tally of the people for PMC, and those against? Or is the answer, "Who cares!".
@Ray, my prior acroynym "OS" was short for open-sourced (not operating system). I'll be really careful in the future, as I see the confusion. I created this one my own. I've edited my post for clarity.
I attempted to summarize the options that people have proposed on page 6 of this thread.· This list is shown below with some modifications.
1. C to Spin - Standard C converted to the Spin language, compatible with current Spin Objects
2. C to bytecodes - Standard C converted to Spin bytecodes, compatible with current Spin Objects
3. C to LMM PASM - C compiler using the large memory model within the Prop's 32K RAM 4. C to PASM within a COG - C compiler using the COGs memory for program and variables
5. C to XMM PASM - C compiler uses additional RAM through I/O port
6. Extended Spin - Spin language and tool enhancements including a pre-processor and new instructions
7. Basic - Basic compiler that compiles to PASM (and maybe spincodes)
I removed option 4, which was the ability to compile·high level·code·into PASM that would run directly within a COG.· I think all of the options should have this capability, including options 6 and 7, which would generate PASM directly from Spin or Basic.· As far as I know, Bean's PropBASIC already has this feature, but I may be mistaken.· All of the options should allow for native·PASM instructions, similar to the current Spin compiler.
I did not include emulators, such as the Z80 emulators because (donning flame retardant suit) I don't think they are viable alternatives.
Somewhere in the previous·10 pages I proposed adding a LMM interpreter to the Spin interpreter.· If there is a way to "patch" the Spin interpreter after it is loaded, then this can be done dynamically by the program.· Otherwise, a new interpreter would have to be loaded and started.· This would allow all of the options to co-exist in the same program.
Ken, I don't think anyone will argue for restarting Propeller Tool development with an open source version over continuing development on the current version. Not even us non-Windows users. I almost didn't add the open source remark and now I guess I'm sorry I did. I didn't mean to send the thread careening down a different track. And I certainly didn't intend to imply that Parallax isn't an "open" company. All of the books you publish as free PDFs are an incredible resource.
You have good reasons for not making the Propeller Tool open source so I withdraw that part of my comment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
RossH said...
The recent posts by Richard and Heater have raised an interesting point that is probably worth discussing while we're discussing C. Does anyone seriously believe there a particular need for GCC on the Propeller? I mean, GCC as distinct from any other C compiler. If so, why?,
Just some reasons:
GNU C provides "inline" functions that are more convenient and fool-proof than #define macros.
GNU C allows dynamic sized arrays (something I've warmed to working with B-trees).
GNU C actually defines using // for comment ... it is in violation of ANSI C89 to use it.
GNU C glibc library provides definitions for snprintf, and other string buffer bounds protection methods.
GNU provides C++ for those who want to use a broadly established (but dang ugly) OOP.
GNU has been constantly improved over the years where generic LCC has not.
GNU has a great tool-chain.
There are no statistics that I can find that separate the popularity of C into GNU or other compilers. Maybe someone else has a source. Until someone can prove otherwise, I'll assert that GNU provides the most popular C for any platform, and you can assert that ICC or XYZ provides the most popular C for any platform. Without good evidence, we'll never know.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
jazzed, I am almost afraid to bring this up in this crowd, but Microsoft Visual C/C++ is probably up there near the top when it comes to number of users. At least in the professional programming side of things. You can hate them all you want, but I have yet to find a debugger that is even close to as good, and their compiler these days is really top notch in performance and compliance.
Of course, sadly, the number of VB programmers in the world likely dwarfs the rest combined....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
@Roy: Yes but. For embedded targets Visual C/C++ does not exist and that is the space under discussion. As for VB programmers, since I started programming in 1984 I don't think I've met more that two or three.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Roy Eltham said...
jazzed, I am almost afraid to bring this up in this crowd, but Microsoft Visual C/C++ is probably up there near the top when it comes to number of users. At least in the professional programming side of things. You can hate them all you want, but I have yet to find a debugger that is even close to as good, and their compiler these days is really top notch in performance and compliance.
Of course, sadly, the number of VB programmers in the world likely dwarfs the rest combined....
I totally agree with you Roy. Too bad their C library doesn't support bounds checking functions like snprintf [noparse]:)[/noparse] Of course only Microsoft could port their product to Propeller, but that happening would be a miracle.
@heater ...
Ever heard of Windows CE? My phone is an embedded device for example. As someone correctly asserted before not all embedded devices are micro-controllers like it or not. I fail to understand what being embedded has to do with C language variation popularity though ... it's just a device being used to skew the argument and is irrelevant. VB is what made Windows so popular, so there are plenty of them left alive that you haven't met, and two of them are your good friends on this forum [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
jazzed, they actually do have bounds checking / "safe" versions of stuff like gets, strcpy, and so on. They are all gets_s, strcpy_s, and son on. It's something they started with VS2005. With default compile options it has warnings about using the old "unsafe" variants. Also, I would never even consider thinking about Microsoft supporting the Propeller with their compiler, it's really just not an option.
heater, most of the VB programmers are in corperate environments and often don't act like or even mingle with the typical programmer types. C# has picked up a lot of momentum though so it's catching up to VB.
There was a time not too long ago when you could open up the LA Times classifieds section and find something like 20 to 1 programming jobs looking for VB verses any other language. It's sad really, and I'm glad it's change. VB (at least prior to .net) was a horrible blight on the programming landscape. [noparse]:D[/noparse]
Anyway, it sure would be nice to have a IDE and debugger as nice as Visual Studio's for doing Propeller or other small microcontroller coding.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Never seen anyone use a Wince phone and there are precious few in the shops. But then I do live in the land of Nokia[noparse]:)[/noparse]
I might argue that a phone is not an embedded device. It used to be said that an embedded computer was one that was buried away in some other device controlling it's functioning without the user being aware that it's there.
A modern phone is anything but that, it's computing is not "buried", it's in you face (literally[noparse]:)[/noparse]). It has a rich user interface. The user can load it up with new apps to run. Keen users can create their own apps to run on it, as you point out. It's a fully fledged computer with a phone embedded somewhere[noparse]:)[/noparse]
Anyway I won't argue that, I've already been reprimanded for mincing words once today already.
Aside: I recently spent a week at the Intertraffic Exhibition in Amsterdam. In that huge international show were hundreds of companies from all around the world presenting traffic controllers, all kinds of vehicle detector systems, controllers for motorway signs etc etc etc. In all of that I came across one device based on Wince.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Roy Eltham said...
jazzed, they actually do have bounds checking / "safe" versions of stuff like gets, strcpy, and so on. They are all gets_s, strcpy_s, and son on. It's something they started with VS2005. With default compile options it has warnings about using the old "unsafe" variants. Also, I would never even consider thinking about Microsoft supporting the Propeller with their compiler, it's really just not an option.
Yup, I've dealt with the Microsoft VC++ method of doing things and their safe warnings. I'll never understand why they couldn't have just been cooperative with the rest of the industry in the first place .... Of course the number of ensuing overrun hacked viruses finally convinced them they were fundamentally wrong to ignore it in the beginning whether they admitted it or not In the end, it's less convenient, but it is a reasonable protection and "notice" for less informed programmers ....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
If I know correctly It is not invented by "MicroSoft" to - BUT them use it and say - that it is theirs design
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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 said...
If I know correctly It is not invented by "MicroSoft" to - BUT them use it and say - that it is theirs design
Just to drag this thread completely off topic I may add: Steve Jobs saw the Xerox Alto GUI at PARC, who had no problem showing others what they did, and later Bill Gates saw what Steve Jobs did with the Mac. The only thin relation to this thread is that B(CPL) ran on the Xerox Alto, and B is the predecessor of C. No, I don't want B for the Propeller
I will polemise IF it is of topic.
We have SPIN that are good to have on Propeller for its design. BUT many of people will steal Badly fitted "C" only that it is theirs "church".
As I said to Bill Henning on chat - "mig: For me it Like Catholics church - Every pastor spoke on theirs version of religion".
and "mig: ok
All of them talk on "C" - but none of them define what it is !!" - Every one talk on another derivate on IT !!
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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 said...
If I know correctly It is not invented by "MicroSoft" to - BUT them use it and say - that it is theirs design
Just to drag this thread completely off topic I may add: Steve Jobs saw the Xerox Alto GUI at PARC, who had no problem showing others what they did, and later Bill Gates saw what Steve Jobs did with the Mac. The only thin relation to this thread is that B(CPL) ran on the Xerox Alto, and B is the predecessor of C. No, I don't want B for the Propeller
Yes, I'm aware of all this. I live down the street from where it was invented ... and it ain't Europe [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Comments
Why do we want to muddy it up with "not C".
Use what we have and get those emulators built, err no, I mean get on with your projects. In this compatible, sharing and harmonious Propeller environment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I honestly hope C++ never raises its ugly head on the Prop II - but I expect it will.
C++ is completely impractical in embedded environments. It is silly to even contemplate putting C++ on a microcontroller constrained to 32kb, and is only slighly less silly to contemplate putting it on one constrained to only 300kb. Better minds than mine have taken C++ and tried to remove some of the functionality that is so detrimental in embedded applications - and ended up with an awful shambles of a language called EC++ (see here).
C - for all it's drawbacks - shares with SPIN an elegant and orthogonal simplicity. C++ has most of the drawbacks of C, but then goes and adds a truckload more all of its own.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 4/20/2010 10:23:03 AM GMT
I think an OS will rock on the Prop II, and will live on the Prop I. But it will not be *nix nor CPM (although I expect CPM will be able to be called from it).
I expect it will be a simple CPM/DOS style so we can edit and compile (albeit possibly slow for larger programs) on the prop (i.e. Self-hosting). Why do I think this? I have a vision of a small self-contained pcb in a case with some mix of keyboard, mouse TV, VGA, sound, game controllers, microSD, LAN, USB OTG, and WiFi. The Prop I or II is ideally suited to this and would be a complete and cheap learning tool. It certainly does not want the complexity of *nix systems. The keyboards, TVs, etc are already plentiful these days.
I am keen to add my input to the PropTool debate including open source (to come later tonight maybe).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Just a nit-pick, but I had to read this a number of times to parse it. I don't think I've ever seen "OS" used to shorten open-source. It's mostly used to represent "Operating System" or "Over Seas".
I spent a number of cycles trying to figure out which operating systems you'd been looking at that were un-professional.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Fine, whatever, I am not here to argue the exact semantics of words, but the idea.
I stated my case, C executing on LMM C is fundamentally different in philosophy than porting a virtual CPU. You may argue with the semantic, but the difference is real.
Don't think as a hobbyist, think of it as a company selling a product.
Any flaws with LMM C is not because of the LMM, but the memory limitation of the Propeller. We, as a commercial compiler provider, can proudly sell Propeller C.
However, if we port ZOG, solely because it is there, and it has GCC, and try to sell GCC on Propeller based on that architecture, that's a failing business model.
I'm done with this thread. Mincing words is not my interest.
Glad to see I'm not the only one. I think Cluso also misread it.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I hate to call down the curses of Zog on my head (again!) but I think I have to agree with Imagecraft on this one.
I don't pretend to know much about ICC, but there is a fundamental difference between Catalina and Zog. Catalina produces PASM - pure and simple PASM - which could be executed directly on a cog if that cog had enough RAM. Actually, I seem to remember jazzed saying that the ICC compiler can in fact do this - but it seems a rather pointless feature because there isn't a whole lot of C you can fit in the few hundred instructions (some cog space would necessarily lost to housekeeping and overhead) which you probably wouldn't be better off hand-coding in PASM in the first place!
Anyway, the point is that you can think of LMM as implementing a "virtual" cog, in much the same way that virtual memory extends the physical memory of other processors. LMM does not change the machine in any material way. It does not change the architecture. It does not add new functionality. It's really just a way of "extending" the physical address space.
Also, if you think about it, normal PASM programs routinely employ the tricks employed by an LMM kernel in any case - code overlays are a fairly common technique in PASM - just because they are called FCACHEs in LMM doesn't make them anything new. In fact, you can think of the whole LMM "loop" as just a bunch of single instruction overlays. Or you can think of it as a tight loop of self-modifying code - another very common PASM technique (due to the lack of indirect addressing on the Prop).
Yes, the Catalina LMM implements "primitives" that make it easier to generate code for stack/frame based procedural languages - but this is no different from many other compilers on many other architectures. It's only recently that most microcomputers come with specific stack and frame manipulation instructions anyway. The early IBM minicomputer architectures had no specific stack pointer - you just used any ordinary register, and incremented and decremented it youself. And saved your own registers on entry to a subroutine, and restored them before you exited. Often, you wrote simple library functions to manage all this for you - exactly what Catalina does in its LMM primitves.
On the Prop II, I think this technique will fit so naturally that people will be wondering what all the fuss was about.
Ross.
P.S. My, but this thread seems to have diverged from it's original intent. I was really interested in hearing Parallax's response to our comments. Maybe they've been a bit nonplussed by the intensity of reaction their document has generated!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Sure you have, it's just that it was inside "FOSS"
I stand (sit) corrected again [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
If I take a junk of Catalina binary and throw it into a COG it ain't going to run as I expect a junk of normal PASM to run. Not with out the VM kernel to support it.
If I take that junk of binary and throw it at an ICC kernel it ain't going to run either. Wrong Virtual Machine. And vice versa.
So yes LMM uses native instructions of the Prop, yes the difference is real, as can be seen by the performance gap between ICC, Catalina and poor old Zog. But it's all a VM anyway in my mind.
Let's agree to disagree on the terminology here, I think we all know what we mean any way, and get back to the topic. What should Parallax do about C on the Prop?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Okay - If you promise to put Zog back in his ice block, we can get back to the topic in hand.
I'm a bit concerned that we are losing sight of the original thread. The trouble is that we've all trotted out our usual arguments - without actually changing anybody else's minds - and now we're just meandering off while we wait for more input. Perhaps this was a deliberate tactic by Parallax to just let us waffle on till we ran out of steam?
If so, it worked - I'm off to bed!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
This was done before, anybody remember the 'Open Sourcing of Propeller IDE' thread that was started by Chip? That also was a very long thread where everybody expressed their feelings about 'OpenSource'. Did we ever see an answer to that, from Parallax? I am not complaining, just would like to know if any of our input was used.
Ken had me going with the "os" thing also, I started to think that Parallax was going to be presenting an Operating System (OS,os) for the Propeller. I guess we will have to quit using abbreviations, this is leading to some confusion.
Has anybody kept a tally of the people for PMC, and those against? Or is the answer, "Who cares!".
Ray
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ken Gracey
Parallax Inc.
Follow me at http://twitter.com/ParallaxKen for some insider news.
In fact it is so common that typing "OSS" into Google just now gets you this as the first hit: en.wikipedia.org/wiki/Open-source_software
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1. C to Spin - Standard C converted to the Spin language, compatible with current Spin Objects
2. C to bytecodes - Standard C converted to Spin bytecodes, compatible with current Spin Objects
3. C to LMM PASM - C compiler using the large memory model within the Prop's 32K RAM
4. C to PASM within a COG - C compiler using the COGs memory for program and variables
5. C to XMM PASM - C compiler uses additional RAM through I/O port
6. Extended Spin - Spin language and tool enhancements including a pre-processor and new instructions
7. Basic - Basic compiler that compiles to PASM (and maybe spincodes)
I removed option 4, which was the ability to compile·high level·code·into PASM that would run directly within a COG.· I think all of the options should have this capability, including options 6 and 7, which would generate PASM directly from Spin or Basic.· As far as I know, Bean's PropBASIC already has this feature, but I may be mistaken.· All of the options should allow for native·PASM instructions, similar to the current Spin compiler.
I did not include emulators, such as the Z80 emulators because (donning flame retardant suit) I don't think they are viable alternatives.
Somewhere in the previous·10 pages I proposed adding a LMM interpreter to the Spin interpreter.· If there is a way to "patch" the Spin interpreter after it is loaded, then this can be done dynamically by the program.· Otherwise, a new interpreter would have to be loaded and started.· This would allow all of the options to co-exist in the same program.
Dave
You have good reasons for not making the Propeller Tool open source so I withdraw that part of my comment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
links:
My band's website
Our album on the iTunes Music Store
GNU C provides "inline" functions that are more convenient and fool-proof than #define macros. GNU C allows dynamic sized arrays (something I've warmed to working with B-trees). GNU C actually defines using // for comment ... it is in violation of ANSI C89 to use it. GNU C glibc library provides definitions for snprintf, and other string buffer bounds protection methods. GNU provides C++ for those who want to use a broadly established (but dang ugly) OOP. GNU has been constantly improved over the years where generic LCC has not. GNU has a great tool-chain.
There are no statistics that I can find that separate the popularity of C into GNU or other compilers. Maybe someone else has a source. Until someone can prove otherwise, I'll assert that GNU provides the most popular C for any platform, and you can assert that ICC or XYZ provides the most popular C for any platform. Without good evidence, we'll never know.▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Of course, sadly, the number of VB programmers in the world likely dwarfs the rest combined....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@heater ...
Ever heard of Windows CE? My phone is an embedded device for example. As someone correctly asserted before not all embedded devices are micro-controllers like it or not. I fail to understand what being embedded has to do with C language variation popularity though ... it's just a device being used to skew the argument and is irrelevant. VB is what made Windows so popular, so there are plenty of them left alive that you haven't met, and two of them are your good friends on this forum [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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've written several programs in Wince for my phone...
These days, you use the same IDE as for Windows C++ apps and just change the target to WinCE...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
heater, most of the VB programmers are in corperate environments and often don't act like or even mingle with the typical programmer types. C# has picked up a lot of momentum though so it's catching up to VB.
There was a time not too long ago when you could open up the LA Times classifieds section and find something like 20 to 1 programming jobs looking for VB verses any other language. It's sad really, and I'm glad it's change. VB (at least prior to .net) was a horrible blight on the programming landscape. [noparse]:D[/noparse]
Anyway, it sure would be nice to have a IDE and debugger as nice as Visual Studio's for doing Propeller or other small microcontroller coding.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
I might argue that a phone is not an embedded device. It used to be said that an embedded computer was one that was buried away in some other device controlling it's functioning without the user being aware that it's there.
A modern phone is anything but that, it's computing is not "buried", it's in you face (literally[noparse]:)[/noparse]). It has a rich user interface. The user can load it up with new apps to run. Keen users can create their own apps to run on it, as you point out. It's a fully fledged computer with a phone embedded somewhere[noparse]:)[/noparse]
Anyway I won't argue that, I've already been reprimanded for mincing words once today already.
Aside: I recently spent a week at the Intertraffic Exhibition in Amsterdam. In that huge international show were hundreds of companies from all around the world presenting traffic controllers, all kinds of vehicle detector systems, controllers for motorway signs etc etc etc. In all of that I came across one device based on Wince.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
If I know correctly It is not invented by "MicroSoft" to - BUT them use it and say - that it is theirs design
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Just to drag this thread completely off topic I may add: Steve Jobs saw the Xerox Alto GUI at PARC, who had no problem showing others what they did, and later Bill Gates saw what Steve Jobs did with the Mac. The only thin relation to this thread is that B(CPL) ran on the Xerox Alto, and B is the predecessor of C. No, I don't want B for the Propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/20/2010 6:55:14 PM GMT
I will polemise IF it is of topic.
We have SPIN that are good to have on Propeller for its design. BUT many of people will steal Badly fitted "C" only that it is theirs "church".
As I said to Bill Henning on chat - "mig: For me it Like Catholics church - Every pastor spoke on theirs version of religion".
and "mig: ok
All of them talk on "C" - but none of them define what it is !!" - Every one talk on another derivate on IT !!
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.