"and the only thing I have against PropGCC is that some people seem to believe it is a magical pathway to making C++, Fortran and Java practical on the Propeller. It isn't."
Clearly your answers prove Rays point that you have animosity towards GCC which is an effort I'm responsible for and by extension animosity towards me.
We talked about languages. Parallax wants C/C++. The other languages are possible, but not specified for this project. The other languages were not requested by Parallax and are not in the requirements. We are providing what GCC provides as specified for C/C++. I'm delivering what Parallax wants. Can you?
Please stop spewing arguments and manipulative propaganda. It's not doing anyone any good.
Jazzed, I'm really getting lost here. What are you talking about? I was discussing languages. Specifically, whether the Propeller will ever fully support any of the GCC languages other than C.
Here is a summary of my opinion on that subject:
C is practical on the Propeller, and you don't need to limit yourself to a subset of the language. This has been shown.
C++ is not practical on the Propeller unless you limit yourself to a subset. A subset may be practical on the Propeller, just as it is on the Arduino.
Java, Fortran, Ada and all the other languages GCC supports are not at all practical on the Propeller.
You are entitled to disagree with these opinions - but I don't see anything in there that is negative about either you or GCC.
However, I do have a problem with some of the misunderstandings and misconceptions about GCC that seem to exist on these forums. The main misconception is that the other languages that GCC offers come "for free" once you have C. Of course they don't - the easiest case to illustrate this is Ada. Yes, GCC can compile Ada code - but this doesn't mean you can actually run any Ada programs. You also need support from the GNARL Ada runtime package - and this package depends on services provided by an operating system. Specifically, it needs a POSIX operating system including pthreads. If you don't have those (and of course we don't on the Propeller) then you can still run Ada programs - if you provide your own equivalent. Java and Fortran are similar, but probably not quite as extreme in their demands on an underlying runtime. C++ is slightly different - the main problem here is not the runtime (it shares most of that with C) - it is specific language features such as exceptions, templates and the Standard Library, which are just too expensive to run on an microcontroller like the Propeller. I know others (such as Heater) hotly dispute this last bit - and I'm sure we all look forward to finding out one way or another as a result of the PropGCC project.
I obviously have a problem with the Project Manager of the Propeller GCC project. Ross obvioulsy has a problem with the Project Manager of the Propeller GCC project.
Perhaps it is myself and Ross that are the problems... but then again perhaps it's the Project Manager???
I obviously have a problem with the Project Manager of the Propeller GCC project. Ross obvioulsy has a problem with the Project Manager of the Propeller GCC project.
Perhaps it is myself and Ross that are the problems... but then again perhaps it's the Project Manager???
Cluso, Jazzed - I think it best we all move on. I am all for strongly argued technical opinions, but this thread is coming perilously close to descending into a personal slanging match - which would rapidly turn these forums toxic!
I did the optimization, but from my measurements it's not worth the hassle.
While with that changes I gain a round 20% performance on my board, that is true only in uncached mode.
With 8KB cache the difference is under 1% (just like Ross told us ).
Furthermore it comes with the risk of not working on all boards (i.e. I have only one delay instruction between enable and read, same for write gate).
So I'd suggest David to start with the original driver.
The existing PropGCC DracBlade cache driver is already based on code I got from Dr_Acula. I assume it's the original code you mention. Also, this is exactly the same cache driver that I wrote for ZOG and was also used in xbasic.
It is only a good thing to have the development efforts we do. As a Prop user, I am pleased by the effort to bring serious tools to a great chip. These efforts are non-trivial, and are very valuable for the current chip, and the future ones. Basic work done now is going to pay off big, and I think everybody either knows that, or has reason to do that work regardless.
This friction is decidedly uncomfortable. I don't know how else to put it.
From where I stand, a bar has been set. We have working stuff. From here, we simply get more working stuff. There isn't anything beyond that, is there? Where there is more working stuff, there is the potential for more people, unless said stuff is decidedly poor.
Does anyone honestly believe either of these two efforts would be characterized as poor? I sure don't. In fact, what I see is great work that will either open up, or has opened up doors long closed to us. Love it. Seriously.
And there are principles in play too. Strong ones, forged from many experiences, knowledge, wisdom and skill. These can co-exist. Frankly, they have to co-exist, or we are all going to lose. Mind share is a fickle thing, and often ONE impression is the determining factor. We want the mind share, right?
I sure do. I do, because this device inspires me. So do the people involved. And "those people", myself included, come from a wide variety of backgrounds and have a wide variety of goals. There simply isn't going to be the one true path. Won't happen. Ever.
Long ago I worked with some pool sharks essentially. There was a lot of debate as to how to approach the game of nine ball. (which is a fantastic game, BTW --my personal favorite) Lots of talk about this and that, combined with various skill levels proved very interesting to me personally. Of course, my skill at that time was moderate, learning each day from giants. --we played for cokes, more often than not, and I used to stock up on the sales to keep my debt low, and yes, they took it very serious.
It turns out the "one true path" was to work hard to understand personal limits, set realistic goals, manage risk and pay attention throughout. I went from a poor player to a fairly competitive one over the course of a year. That's 2 - 4 hundred matches, played out over lunch and breaks. (and a hell of a lot of Cokes)
Had there not actually been the Cokes in play, I probably would not have paid attention, improving only marginally as a player, but those Cokes tended to focus things in very good ways.
What I am trying to say here is the idea of wanting to "do it right" or "better", "more efficiently", "flexibly", "easy" is the right idea. The code is out there, the ideas are out there, and it all can be built on with no real worries, other than building badly. Everybody wants this, because we all want to do things we find interesting, and become better "players"
Instead of Cokes, we have potential new comers. Everybody wants those too, because we are a nice group, but could be a much larger group. Again, good for everybody.
We also have bragging rights, whatever those may be. To some of us, that might just mean blinking a few lights at once, to others it means advanced code doing difficult things quickly, or in the HUB. Does it matter past that? As people, are we actually less for those differences, given our range of backgrounds, employment, interests?
No. There just isn't.
Those sharks I played the game with pestered me constantly! I sucked. But, as people we all had a good time, respected one another, and they helped me learn to win my share of the Cokes and then some. Bragging rights kick a lot of *** too! That's why we played, that and working in a regressive, somewhat crappy manufacturing shop.
Now, I was hired there to improve their processes. The sharks were all 40 - 50 somethings, and here I was the 20 something supposed to basically out-do them, and I got paid more too! (and yes, that did not go well) What got us through that was the pool games. Huge friction at first. They hated me, and we clashed on everything, basic ideologies just in bitter conflict. I was new school, they were old and honestly, uninformed.
Then we played pool one day, and that all changed. There was a healthy exchange of things all around, and most importantly, "outs" for people to have some pride and success somewhere, and it didn't hurt that I bought one hell of a lot of Cokes learning to play nine ball either! In the end, we had a lot of fun, and that crappy old shop, with it's old gear ended up producing just as well as any other one did.
I am sorry to just drop this long winded story here, but I feel compelled to.
The moral of the story here is that we are all good people. Seriously, we just are. Can't we take pride in some basic things; our numbers here, if nothing else?
And can't we go for the bragging rights in that great fun way?
That's all fun, and seriously productive, and catchy too. Remember mind-share. That is, in the end, what a lot of the efforts are about, just as much as it is realizing our personal goals, whatever they are.
I see I am not the only one noticing a significant degeneration of the usual spirit of these forums. Personally, I don't really understand the reasons for any of it. In just about every processor family and OS on the planet, there are multiple versions of compilers, whether C(++), cobol, fortran, AI based systems, etc. whose purpose is to turn high-level constructs into machine code as efficiently as possible. The more choices the better, and as the products evolve, they should achieve some reasonable level of perfection. That includes the two compilers at issue here. I can not really say when or if one author has disrespected the other, but the appearance has seemed to be spreading out through perception of third party commenters lining up one way or the other.
It is not Microsoft vs. Linux or even remotely close to that sort of thing. Personally I wish there were a couple more PASMs out there, a couple more C's and all with (name your favorite IDE and eclipse(mine). To tell the truth (and maybe expose some ignorance on my part), what I want from the C choices that are now out and may be available in the future are ones where there is no tie-in to any platform. NONE. I would rather see an API of sorts that is well documented, modifiable and adaptable to ANY platform that may come along, not one size fits some more than others. As to what Parallax will support, that will of course be a financially driven business decision. But the better open and documented the C interfaces are, the less we need rely on Parallax or a handful of experts. Same for driver authors.
The above reflects only my view of the issues that seem about to boil over for no beneficial reasons whatsoever. Time for all to dial it back, regain objectivity and get good projects out with the best tools we can beg, buy, or build rather than scaring/driving off other potential personal or commercial users of the prop chip by cratering one of the foremost resources available to us (and selfishly enough nearly noob, me).
For what it's worth,
Frank Freedman
*Asbestos undies rated for 8hr min at 25x Phoenix summer average temps..........
(don't worry, I can still sue the asbestos mfrs later...)
The existing PropGCC DracBlade cache driver is already based on code I got from Dr_Acula. I assume it's the original code you mention. Also, this is exactly the same cache driver that I wrote for ZOG and was also used in xbasic.
Many thanks - it sounds like you have this all in hand. And thanks for doing this.
As an aside I have a range of Gadget Gangster boards on the way including the Dracblade so hopefully I can build something in the next few weeks that is much more compact than the previous Dracblades, and also which can be added to the existing GG motherboards. Am hoping to get the cost under $10.
Many thanks - it sounds like you have this all in hand. And thanks for doing this.
As an aside I have a range of Gadget Gangster boards on the way including the Dracblade so hopefully I can build something in the next few weeks that is much more compact than the previous Dracblades, and also which can be added to the existing GG motherboards. Am hoping to get the cost under $10.
I've been hearing and reading a lot about a dracblade and was wondering where I could get one. Any idea of when I can expect to get it from GG?
I've been hearing and reading a lot about a dracblade and was wondering where I could get one. Any idea of when I can expect to get it from GG?
Yes, that is my fault <puts trumpet away in case>.
I have some old boards but I took my e-store offline last month in anticipation of moving over to the GG format. So right now I don't have anything except a prototype on a breadboard and boards currently somewhere in the air between the USA and Australia.
But in a way, with caching, the actual hardware may not be so important now.
Taking the original propeller demoboard as a starting point, some things have become semi-standardised. Serial port on pin 30,31, eeprom 28,29, mouse and keyboard 24-27. Then VGA pins 16-23. I deviate from the demoboard by also putting TV on pins 16-21 as I figure you would not want TV and VGA at the same time. Then SD card on pins 12-15. (or P0-P3)
And then you can do whatever you want with the other 12 pins P0-P11. The dracblade uses those for memory but more recently with caching, I wonder if less of those pins could be used eg use just 4 pins for an SPI 32k external ram chip (or more) and leave other pins uncommitted.
Gadget Gangster format adds a lot of flexibility as you could mix and match different external ram solutions.
I totally agree. 8 ball is a very relaxing game, and one I enjoy when the point of the game is more social. If it's gonna get down and dirty, 9 ball it is! (old school rules too, given who I learned from, that's no surprise)
Fortran could actually be possible.. it's quite different from Ada, Java and C++ in that respect. It's an old language with roots in systems that didn't have much memory. The Fortran compiler I use on an old 16-bit architecture is itself small, and creates small, efficient code.
No, the problem with Fortran is rather that the Propeller isn't good for what you would presumably use Fortran for.. the traditional number crunching and the like.
The Atmel Dataflash AT45DB*** solution is a fair suggestion, but may have to wait for a volunteer.
I installed "linux-x86-32-propgcc_v0_1_2" yesterday, I compiled a small program and successfully program the Propeller.
Understood that the C3 board has a memory Flash, so perhaps not too difficult to use an Atmel AT45DB321.
Any information, code, just ask.
Notes:
- The file "INSTALL.txt" contains an error in line 15 "Propeler".
- After programming the Propeller, it was necessary to press CTRL + C to return to the command line.
Glad you have something working. The posted linux package is for Debian/Ubuntu. I've successfully used it on Fedora too (aside from version warnings).
Thanks for your notes on problems. Please report further issues in the Alpha test forum if you can. Today you can use either Ctrl-C or ESC to exit the propeller-load terminal.
Yes, C3 uses Flash. Adding support for AT45DB parts sounds like a great Alpha project to me - most likely it would be a simple copy/paste edit from the existing c3_cache.spin driver and adding 12 lines of board type to the loader config file.
The only barrier to adding your own external memory design with GCC now is documentation - code infrastructure changes are not required. The process is fairly simple, but instructions are not ready yet.
I installed "linux-x86-32-propgcc_v0_1_2" yesterday, I compiled a small program and successfully program the Propeller.
Understood that the C3 board has a memory Flash, so perhaps not too difficult to use an Atmel AT45DB321.
Any information, code, just ask.
Notes:
- The file "INSTALL.txt" contains an error in line 15 "Propeler".
- After programming the Propeller, it was necessary to press CTRL + C to return to the command line.
Comments
Jazzed, I'm really getting lost here. What are you talking about? I was discussing languages. Specifically, whether the Propeller will ever fully support any of the GCC languages other than C.
Here is a summary of my opinion on that subject:
- C is practical on the Propeller, and you don't need to limit yourself to a subset of the language. This has been shown.
- C++ is not practical on the Propeller unless you limit yourself to a subset. A subset may be practical on the Propeller, just as it is on the Arduino.
- Java, Fortran, Ada and all the other languages GCC supports are not at all practical on the Propeller.
You are entitled to disagree with these opinions - but I don't see anything in there that is negative about either you or GCC.However, I do have a problem with some of the misunderstandings and misconceptions about GCC that seem to exist on these forums. The main misconception is that the other languages that GCC offers come "for free" once you have C. Of course they don't - the easiest case to illustrate this is Ada. Yes, GCC can compile Ada code - but this doesn't mean you can actually run any Ada programs. You also need support from the GNARL Ada runtime package - and this package depends on services provided by an operating system. Specifically, it needs a POSIX operating system including pthreads. If you don't have those (and of course we don't on the Propeller) then you can still run Ada programs - if you provide your own equivalent. Java and Fortran are similar, but probably not quite as extreme in their demands on an underlying runtime. C++ is slightly different - the main problem here is not the runtime (it shares most of that with C) - it is specific language features such as exceptions, templates and the Standard Library, which are just too expensive to run on an microcontroller like the Propeller. I know others (such as Heater) hotly dispute this last bit - and I'm sure we all look forward to finding out one way or another as a result of the PropGCC project.
Ross.
Perhaps it is myself and Ross that are the problems... but then again perhaps it's the Project Manager???
Cluso, Jazzed - I think it best we all move on. I am all for strongly argued technical opinions, but this thread is coming perilously close to descending into a personal slanging match - which would rapidly turn these forums toxic!
Ross.
It is only a good thing to have the development efforts we do. As a Prop user, I am pleased by the effort to bring serious tools to a great chip. These efforts are non-trivial, and are very valuable for the current chip, and the future ones. Basic work done now is going to pay off big, and I think everybody either knows that, or has reason to do that work regardless.
This friction is decidedly uncomfortable. I don't know how else to put it.
From where I stand, a bar has been set. We have working stuff. From here, we simply get more working stuff. There isn't anything beyond that, is there? Where there is more working stuff, there is the potential for more people, unless said stuff is decidedly poor.
Does anyone honestly believe either of these two efforts would be characterized as poor? I sure don't. In fact, what I see is great work that will either open up, or has opened up doors long closed to us. Love it. Seriously.
And there are principles in play too. Strong ones, forged from many experiences, knowledge, wisdom and skill. These can co-exist. Frankly, they have to co-exist, or we are all going to lose. Mind share is a fickle thing, and often ONE impression is the determining factor. We want the mind share, right?
I sure do. I do, because this device inspires me. So do the people involved. And "those people", myself included, come from a wide variety of backgrounds and have a wide variety of goals. There simply isn't going to be the one true path. Won't happen. Ever.
Long ago I worked with some pool sharks essentially. There was a lot of debate as to how to approach the game of nine ball. (which is a fantastic game, BTW --my personal favorite) Lots of talk about this and that, combined with various skill levels proved very interesting to me personally. Of course, my skill at that time was moderate, learning each day from giants. --we played for cokes, more often than not, and I used to stock up on the sales to keep my debt low, and yes, they took it very serious.
It turns out the "one true path" was to work hard to understand personal limits, set realistic goals, manage risk and pay attention throughout. I went from a poor player to a fairly competitive one over the course of a year. That's 2 - 4 hundred matches, played out over lunch and breaks. (and a hell of a lot of Cokes)
Had there not actually been the Cokes in play, I probably would not have paid attention, improving only marginally as a player, but those Cokes tended to focus things in very good ways.
What I am trying to say here is the idea of wanting to "do it right" or "better", "more efficiently", "flexibly", "easy" is the right idea. The code is out there, the ideas are out there, and it all can be built on with no real worries, other than building badly. Everybody wants this, because we all want to do things we find interesting, and become better "players"
Instead of Cokes, we have potential new comers. Everybody wants those too, because we are a nice group, but could be a much larger group. Again, good for everybody.
We also have bragging rights, whatever those may be. To some of us, that might just mean blinking a few lights at once, to others it means advanced code doing difficult things quickly, or in the HUB. Does it matter past that? As people, are we actually less for those differences, given our range of backgrounds, employment, interests?
No. There just isn't.
Those sharks I played the game with pestered me constantly! I sucked. But, as people we all had a good time, respected one another, and they helped me learn to win my share of the Cokes and then some. Bragging rights kick a lot of *** too! That's why we played, that and working in a regressive, somewhat crappy manufacturing shop.
Now, I was hired there to improve their processes. The sharks were all 40 - 50 somethings, and here I was the 20 something supposed to basically out-do them, and I got paid more too! (and yes, that did not go well) What got us through that was the pool games. Huge friction at first. They hated me, and we clashed on everything, basic ideologies just in bitter conflict. I was new school, they were old and honestly, uninformed.
Then we played pool one day, and that all changed. There was a healthy exchange of things all around, and most importantly, "outs" for people to have some pride and success somewhere, and it didn't hurt that I bought one hell of a lot of Cokes learning to play nine ball either! In the end, we had a lot of fun, and that crappy old shop, with it's old gear ended up producing just as well as any other one did.
I am sorry to just drop this long winded story here, but I feel compelled to.
The moral of the story here is that we are all good people. Seriously, we just are. Can't we take pride in some basic things; our numbers here, if nothing else?
And can't we go for the bragging rights in that great fun way?
That's all fun, and seriously productive, and catchy too. Remember mind-share. That is, in the end, what a lot of the efforts are about, just as much as it is realizing our personal goals, whatever they are.
It is not Microsoft vs. Linux or even remotely close to that sort of thing. Personally I wish there were a couple more PASMs out there, a couple more C's and all with (name your favorite IDE and eclipse(mine). To tell the truth (and maybe expose some ignorance on my part), what I want from the C choices that are now out and may be available in the future are ones where there is no tie-in to any platform. NONE. I would rather see an API of sorts that is well documented, modifiable and adaptable to ANY platform that may come along, not one size fits some more than others. As to what Parallax will support, that will of course be a financially driven business decision. But the better open and documented the C interfaces are, the less we need rely on Parallax or a handful of experts. Same for driver authors.
The above reflects only my view of the issues that seem about to boil over for no beneficial reasons whatsoever. Time for all to dial it back, regain objectivity and get good projects out with the best tools we can beg, buy, or build rather than scaring/driving off other potential personal or commercial users of the prop chip by cratering one of the foremost resources available to us (and selfishly enough nearly noob, me).
For what it's worth,
Frank Freedman
*Asbestos undies rated for 8hr min at 25x Phoenix summer average temps..........
(don't worry, I can still sue the asbestos mfrs later...)
Many thanks - it sounds like you have this all in hand. And thanks for doing this.
As an aside I have a range of Gadget Gangster boards on the way including the Dracblade so hopefully I can build something in the next few weeks that is much more compact than the previous Dracblades, and also which can be added to the existing GG motherboards. Am hoping to get the cost under $10.
I've been hearing and reading a lot about a dracblade and was wondering where I could get one. Any idea of when I can expect to get it from GG?
Doug, I also play 9-ball, but I find bar-room style 8-ball more relaxing.
Yes, that is my fault <puts trumpet away in case>.
I have some old boards but I took my e-store offline last month in anticipation of moving over to the GG format. So right now I don't have anything except a prototype on a breadboard and boards currently somewhere in the air between the USA and Australia.
But in a way, with caching, the actual hardware may not be so important now.
Taking the original propeller demoboard as a starting point, some things have become semi-standardised. Serial port on pin 30,31, eeprom 28,29, mouse and keyboard 24-27. Then VGA pins 16-23. I deviate from the demoboard by also putting TV on pins 16-21 as I figure you would not want TV and VGA at the same time. Then SD card on pins 12-15. (or P0-P3)
And then you can do whatever you want with the other 12 pins P0-P11. The dracblade uses those for memory but more recently with caching, I wonder if less of those pins could be used eg use just 4 pins for an SPI 32k external ram chip (or more) and leave other pins uncommitted.
Gadget Gangster format adds a lot of flexibility as you could mix and match different external ram solutions.
jazzed has a 32mb solution which is pretty nifty.
No, the problem with Fortran is rather that the Propeller isn't good for what you would presumably use Fortran for.. the traditional number crunching and the like.
-Tor
I installed "linux-x86-32-propgcc_v0_1_2" yesterday, I compiled a small program and successfully program the Propeller.
Understood that the C3 board has a memory Flash, so perhaps not too difficult to use an Atmel AT45DB321.
Any information, code, just ask.
Notes:
- The file "INSTALL.txt" contains an error in line 15 "Propeler".
- After programming the Propeller, it was necessary to press CTRL + C to return to the command line.
Thank you.
Glad you have something working. The posted linux package is for Debian/Ubuntu. I've successfully used it on Fedora too (aside from version warnings).
Thanks for your notes on problems. Please report further issues in the Alpha test forum if you can. Today you can use either Ctrl-C or ESC to exit the propeller-load terminal.
Yes, C3 uses Flash. Adding support for AT45DB parts sounds like a great Alpha project to me - most likely it would be a simple copy/paste edit from the existing c3_cache.spin driver and adding 12 lines of board type to the loader config file.
The only barrier to adding your own external memory design with GCC now is documentation - code infrastructure changes are not required. The process is fairly simple, but instructions are not ready yet.
Thanks,
--Steve