I think PropGCC will be able to serve a small niche in Prop2 development. It would probably be nice to have C++, error checking, floating point, pthreads and a few other things that GCC provides.
Well, to be fair, some of that stuff like pthreads is provided by libraries not by GCC itself. I suspect you could use the library that comes with PropGCC with your compiler if you flesh out the rest of the features. However, I guess the lack of floating point will prevent you from building the whole library. Do you have plans to add floating point?
Yes, I'll probably add floating point, but it's at the bottom of the list of features I want to add. Oh, another feature that GCC has is an excellent optimizer. The code produced by taz is similar to code produced by GCC with -O0. I plan on adding an optimizer utility between taz and qasm, but it will be quite simple.
Yes, I'll probably add floating point, but it's at the bottom of the list of features I want to add. Oh, another feature that GCC has is an excellent optimizer. The code produced by taz is similar to code produced by GCC with -O0. I plan on adding an optimizer utility between taz and qasm, but it will be quite simple.
All sounding quite impressive.
The optimizer utility is a little less important, if you have smooth in-line assembler, where the output of the compiler can be pasted back edited for tighter loops.
Things like DJNZ tend to not generate well from compilers, but are more natural in ASM, and REP will be similar.
Places where you actually need to do this, are not that many in most projects.
No optimization will appeal to Spin programmers. They don't want to have to deal with keywords like "volatile" that turn off compiler optimizations when accessing shared variables. Talk to Parallax. Maybe they'll be interested in adopting this instead of GCC. They don't seem to have much interest in C++.
This SPIN programmer evaluates the return / investment ratio and puts it in terms of scale.
Gcc on P1 often feels like bringing a tank to a go kart race. Gcc on P2 is going to present quite differently.
So there is that. Ignoring it doesn't get us to better places. Just saying...
I am interested in Dave's effort because it has the potential to self host. Having a tiny or low complexity C as a self host option is as compelling as SPIN and PASM are. That is a new case, not a universal one. Just another great choice people will have.
On thing of value may be to pick up older, smaller C code and use it to build that bench computer use case. A P2 with SD, maybe even two SD connections may well make a potent little embedded workstation or development environment.
Peter has shown us a lot of how that can work today. FORTH is capable and small enough for it to make sense too.
We know SPIN and PASM along with BASIC can make similar sorts of sense.
Why not C?
Indeed!
When C gets nice and lean, it becomes possible to write useful and fast programs on 8 bit machines. While that is dated and limited today, I do not see the same dynamics in play on a small 32 bit multiprocessor. It looks like speed, overall memory and capability will make the lean and mean kinds of options compelling, not just retro.
I, for one, am very eager to see that all play out for lots of reasons.
Now, to the issue of "volitile", there are various schools of thought. If one were to assign portability a low priority, inline and or encapsulated assembly can make a ton of sense, as can factoring the code in various ways to limit or design away from the need fo those things.
So then, what is worth what?
Do I get a better return by learning all about a massive and complex compilier, or by exercising the CPU more directly?
When portability is a high priority, the compiler directives and pragmas make more sense. When portability is less of a priority or thing of value, other means may get it done in a more lean way, which also has value.
C was designed in the days of single CPU machines. Quite rightly it's optimisers assume that there is but one CPU running the code and accessing the variables.
Put two processors together operating on the same data, or even an interrupt in one processor, and all of a sudden those assumptions used by the optimizers are broken. The compiled code misbehaves.
Hence the need for kludges like "volatile", so the programmer can tell the optimiser what is going on in reality.
What this points to is that programming languages for multi-processor machines should have that multi-processing built into their very syntax and semantics.
Some have bent the C style languages into that multi-processor paradigm, a moder day example is XC from XMOS.
If Taz could lean in that direction that would be great.
Hence the need for kludges like "volatile", so the programmer can tell the optimiser what is going on in reality.
Yes, the "volatile" kludge earns a double wry smile, as the semantics are bass-ackwards.
Other tools chose better words like "keep" for stuff they did not want the tools to fiddle with, aka make vanish.
I don't know, "volatile" is very descriptive of the situation.
It's like that sticky gelignite you leave on the shelf whist turning around to do something else. Before you turn back the shelf, the wall and the entire house are blown away because someone else bumped it!
That kind of "volatile"
But, yeah, more seriously, C has no concepts of multi-tasking, concurrent execution, process isolation, process communication etc, etc, built into it's syntax/semantics. It's all a bolt on kludge of pragmas and libraries and junk.
I don't know, "volatile" is very descriptive of the situation.
It's like that sticky gelignite you leave on the shelf whist turning around to do something else. Before you turn back the shelf, the wall and the entire house are blown away because someone else bumped it!
That kind of "volatile"
Hehe, yes, one on many choices of definition
2. tending or threatening to break out into open violence; explosive:
however there is also 1. evaporating rapidly; passing off readily in the form of vapor:
3. changeable; mercurial; flighty:
5. fleeting; transient:
and even, in computing itself 6. Computers. of or relating to storage that does not retain data when electrical power is turned off or fails.
ie Volatile is something more likely to go away, and not be there, when you expect it to be....
Volatile is closer in semantics to temporary, than it is to permanent.
Sadly, a directive chosen by someone with a limited vocabulary, and the rest is history....
I seriously doubt the creators of C have a limited vocabulary.
There is no doubt - Their poor choice of word proves they had limited English Vocabulary.
That said, of course English Vocabulary is not what they are hired for.
Perhaps, a variable directive that simply describes what it actually does ?
If I want something kept or preserved, or not touched by optimizers, there are a great many better words to choose.
Have you ever listened to or read the writings of Brian Kernighan and Dennis Ritchie? I would not dare to say they had a limited command of English. Unix people were very literate.
"kept" or "preserved" does not accurately describe the situation at all. Kept or preserved by whom? In fact it's the opposite of "volatile". Do you want to have to write "kept" or "preserved" on all your global variables? As it happens that is the default assumption of the language it need not be spelled out.
I'm sure the original need for this keyword comes from the idea that some machine hardware can change the value in some register at any time. This needs to be spelled out to our compiler that otherwise assumes it has sole control over memory.
Hence "volatile". It's perfect.
Happens this also works well for describing what happens when other processors or interrupt routines can change memory at any time.
A word like "shared" might have done just as well I guess
No optimization will appeal to Spin programmers. They don't want to have to deal with keywords like "volatile" that turn off compiler optimizations when accessing shared variables.
No complex variable optimization helps keep things simple, but there can still be quite a few other optimization steps, in even a simple compiler/linker.
Unused code removal is one, as is tail-folding etc
Talk to Parallax. Maybe they'll be interested in adopting this instead of GCC. They don't seem to have much interest in C++.
I think they do have an interest in C, but GCC has quite a lot of inertia, and that makes it less ideal as a focused solution.
Certainly GCC's in-line asm handling is quite 'ropey', but fixing that inside GCC is non-trivial, as they support a great many MCUs.
A simpler C, that is more transparent with in-line asm, and generates output that is designed to allow paste-back for those cases where manual optimize is desired, also gives a great way to learn Prop2 ASM.
Inline, done with a dead simple syntax, is a great option for learning PASM as well as a nice option for applying it more broadly. Last time we discussed SPIN, adding this was on the table. P2 HUBEXEC will make doing that a doddle. Simple, fast, etc...
As for C++ it's not really on Parallax. They have their education business and in that space, it's best to deliver what they ask for. If nobody is really asking, the opportunity cost on new coursework is very, very high. I've done a lot of targeted education in my life so far. A lot of the potential revenue is driven by the customer. Going against the grain must be carefully considered. It can pay off too, but the more likely outcome is a nice, big, sunk cost.
In terms of users, Parallax did the work needed for gcc on P1. They may leave P2 as a community project, or they may do that work again. Nobody knows right now. Education will likely drive and fund what happens.
From there, it's on us!
I've written many times before, people use what they use and they share what they share. C++ users now, who want to see more C++ users need to share and advocate and support.
Where that gets done, there will be a productive center of gravity that will attract users. If it's not done, there won't be. Simple as that.
Look no farther than Peter for a stellar example of how that is done, and is being done with FORTH too. Impressive! If you have even an inkling to explore Forth, he's right there. I consider this generous and the mark of a high quality person willing to share how they are having success.
Further, picking up Tachyon means getting a very nice tool kit. One can commit to giving it a go because there is a lot there. SPIN has this in the OBEX, forum support, and a pile of code to exploit.
C is getting there! It can use PASM blobs, there are at least two libraries, and there are people sharing and supporting too.
I don't see much C++ activity, though I do see users mentioning it and success together. More is better here.
If it were me, I would do a game, or some other impressive demo to show people what can be done. The more the merrier.
Take the brackets and semicolons away, and that's mostly SPIN syntax.
That kind of thing is ideal. All the labels, vars, etc... are common, maybe just to a given function, etc... And on the P2, maybe they want to use the CORDIC, or do something with the streamer. A simple, lean, inline facility makes doing any of that no harder than using one of the core language keywords.
If vars and such are a bother, it's going to see less use. If the syntax is a bother, or not just typing PASM lines nice and easy, it's going to see less use, etc...
Honestly, a whole lot of this is driven by how much people have to know to make it work, and how much they must keep track of too. More is more powerful, portable, etc... but it's not favorable to adoption.
Either way, having a center of gravity out there helps to suck people in. Once they are there, they will often advance. Having easy options makes sense. Crawl, walk, run!
On this thought:
A simple, lean, inline facility makes doing any of that no harder than using one of the core language keywords.
The more I consider it, the more important I think it is!
P2 has smart pins and lots of spiffy hardware modes and options, CORDIC, STREAMER, etc...
So, I'm thinking about both C and P2 SPIN here. Developing SPIN fully, with keywords and such for all those things is going to take a while! Maybe don't even do it!
Take the P1 spin, strip out the P1 keywords that map to PASM, like WAITVID, etc... and what's left is a nice, clean, language. It has variables, constants, data, operators, expressions, program flow, boolean comparisons, etc... one needs to do a lot of stuff!
If that simple, inline syntax above, minus the bracket as SPIN doesn't delimit with brackets, were the norm, then suddenly, SPIN and C look a lot alike! Not the syntax so much as what the language offers, with C offering more on pointers and such.
All the special stuff is done in PASM from day one! Either one is small enough to self-host, and the basic optimizations would all apply. People can write fairly sophisticated programs and get the speed benefit of PASM while also having the program structure and control benefit of SPIN and or C. (they choose, based on what makes sense for them, but the PASM is common)
Additionally, a lot of the PASM goodies in the P2 won't be portable, so why even bother?
The answer, of course, is some people will need to bother due to some requirements they work with, or they have well established toolchains they want to continue using, etc... All good. Something like GCC will get them there with the common gnu tools, syntax, etc... All that stuff will get done anyway, meaning it will be there for those who need it. Not a worry.
Otherwise, it's simple, lean, fast!
People could be using PASM almost from day one and hardly even notice! They might do it an instruction or two at a time, just to make use of a Smart Pin, or stream, whatever. If the syntax is lean and mean, this won't be any harder than learning all the specialized SPIN keywords and syntax associated with them anyway.
P1 had to have those things because SPIN compiled to bytecode, and due to how the COG works. We didn't even know what LMM was, until Bill figured it out. (I think doing bytecode should still be an option on P2, but I digress...)
P2 doesn't have to have those things because it does HUBEXEC, and it's not like the bytecode can't have PASM instructions right in it anyway, if that route is taken. The non-aligned PASM instructions allow for that case too.
Maybe P2 doesn't need all those extras defined and packaged up in it's SPIN or C language support either, so long as inline PASM is dead simple and easy. Or, maybe a lot of it can be done as pre-cooked functions and or library code too. We ship the core P2 SPIN, and example library support for a few common things, and over time, just keep adding to the library / program snippet collections, many of which are just a couple of PASM instructions wrapped in a function, or simple, "copy / paste" block.
I keep thinking back to that compiled BASIC I was telling you guys about. The syntax above is how inline assembly was done. And it was super simple to use, due to all the variable names and such working just fine for inline code, no hassles. The result of it was ordinary, non programmer types, actually writing 6502 assembly when they needed to!
Here is a code snippet:
r = t / 2
q = a[r]
q = q & $f0
asm ; replace q = q * 16 + 5 with faster inline assembly
lda q ; load accumulator with contents of variable q
clc
lsr ; multiply to compute screen position
lsr
lsr
lsr
adc #5 ; add offset for visible
sta q ; all done, update variable
if (q > 13) then x = 3...
No multiply instruction on 6502, and that little multiply inline is a lot faster than the general case one the language offers. In this case, people start out writing easy expressions, find out it's too slow, and start using ASM to speed up the program, or they write little bits to make the special hardware functions do their thing. It's too easy.
In that example, more could be done, and if the need is there, all the user needs to do is revisit it, and inline more things, until it's all assembly, if they want / need to.
And that's a compiled BASIC, with inline assembly, useful on a machine with 128 BYTES of RAM too. The author of that compiled basic was told doing it was both impossible and impractical. Since that time, thousands of game programs have been written, by a few hundred people, many of whom have little to no real programming experience. I know this author personally, he lives here in Portland, Oregon. He changed how home brew retro gaming was done with this type of language thinking. It went from some esoteric thing to something an ordinary person can do for fun. Some of these programs ended up commercial quality too. One of those was written by a kid in Salem, Oregon. A kid who literally knew nothing about programming initially.
Pretty amazing, if you ask me. Fast and useful too.
That same kind of thinking on this chip will pay off big. It's a PASM playground, and it has a lot of spiffy hardware to exploit. A lean SPIN, intended to help with program flow, etc... or a lean C setup the same way, is not hard to write in. People take in little bits, and soon they are writing pretty fast, lean, useful programs.
In our case with P2, people would write all the basics in the high level, and inline special goodies. Might just be one instruction or a few in most cases too.
To me, having people able to get going quickly and get the benefit of PASM while doing it, is worth some, "why not do the work to help people exploit it directly in PASM?" thought.
What we get for doing it this way is lean and mean language support early on. People have all they need to really do stuff right away.
Over time, maybe add higher level support for all the goodies, with the benefit of all the use cases that will be out there in the wild. Those higher level things will be targeted for a PC and will include much more sophisticated language support (C++, etc...), and will generally be a super-set of the core tools shipped on chip, or that load on SD card, for use on the chip. Whatever.
Maybe this "self hosting" business has merits beyond not needing anything else besides the chip to write programs.
It may make a TON of sense to target the self-hosting as a constraint to insure the language support provided at release time is lean, mean, functional and complete enough for people to use without delay.
And that is what interests me about Dave's effort here. It's a perfect compliment to SPIN, and it's C! We get the basics for both camps, potentially on chip*! What's not to like about that?
A more "proper", big SPIN and C / C++ happens later, after P2 release. And gcc might be there anyway, depending. In either case, I think a big SPIN, feature complete at the higher level, is going to take some time. And it should take that time too. Rushing it won't make any sense.
*I don't know what actually will exist on the chip, in ROM. Maybe that's just monitor, editor, assembler, crypt, booter, loader. 16K probably will hold those. If monitor and assembler were one thing maybe, with hooks inserted for additional language support, perhaps "small" SPIN and or C can be loaded from SD card and would just be available as an additional command or few when present.
Doing something like that means we can get the chip done, and it ships with useful PASM, and while we wait for fab, the other "on chip" loadable tools get done too. At release time, we've got the basics for people ready to go.
Dave: How close is your syntax to a full implementation of one of the more recent ANSI C specifications? I think it will probably be important to be able to compile stuff like newlib or even the PropGCC library as well as lots of open source C code. Will that require much more beyond what you already have?
I would be very happy if Taz was never a full C language compiler. As long as the subset of C it implements is also compilable with GCC or Clang or whatever on my PC for testing purposes.
On the other hand ... this is a chance to go a bit wild:
void myCogProcess1(param1, param2)
{
// Do something
}
void myCogProcess2(param1, param2)
{
// Do something
}
int main ()
{
par
{
myCogProcess1(param1, param2);
myCogProcess2(param3, param4);
}
}
Build the multi-processor nature of the Prop into the language. Perhaps with "channels" to communicate between COGs.
Dave: How close is your syntax to a full implementation of one of the more recent ANSI C specifications? I think it will probably be important to be able to compile stuff like newlib or even the PropGCC library as well as lots of open source C code. Will that require much more beyond what you already have?
I think that is done with the (future?) extra layer mentioned ?
This does bring us to Debug support, which is where many-layers of code can fall over.
SDCC manages this with special syntax comment tags in the created ASM (and any intermediate files), which allows a debugger to find the source file, and line #, and also find declaration of the variable.
Those tags can also give a choice of HLL step, or ASM step debug.
That can work well, but it adds (considerable) visual clutter to the ASM, and for the copy/paste pathways, it may pay to create two ASM files :
ie One with the debug tags, and a cleaner one for human use (scan/copy/paste into in-line ASM)?
The actual ASM code would assemble the same, from either.
Dave: How close is your syntax to a full implementation of one of the more recent ANSI C specifications? I think it will probably be important to be able to compile stuff like newlib or even the PropGCC library as well as lots of open source C code. Will that require much more beyond what you already have?
I think that is done with the (future?) extra layer mentioned ?
This does bring us to Debug support, which is where many-layers of code can fall over.
SDCC manages this with special syntax comment tags in the created ASM (and any intermediate files), which allows a debugger to find the source file, and line #, and also find declaration of the variable.
Those tags can also give a choice of HLL step, or ASM step debug.
That can work well, but it adds (considerable) visual clutter to the ASM, and for the copy/paste pathways, it may pay to create two ASM files :
ie One with the debug tags, and a cleaner one for human use (scan/copy/paste into in-line ASM)?
The actual ASM code would assemble the same, from either.
I'd like this to be able to replace PropGCC. Otherwise, it will fracture the Propeller C community even more than it is now especially if this new compiler gets used by the Parallax Education people for their Learn material. The Propeller community is already tiny and the C users in that community are a small percentage of the Propeller users. To have two or even three C compilers if Catalina gets ported to the P2 will likely result in less than critical mass for all of them. The only one that will have a chance is the one that Parallax uses for its education efforts. Let's figure out which one is best for that and put all of our efforts into that one.
They are quite different in approach, Taz C as I understand it, is smaller and more nimble, but does not cover as many bases. Subset-C at this stage.
GCC is large, and rather locked into a register subset mapping, that flows from ARM et al code generation.
It also has poor in-line asm, that makes me shudder.
I would venture there is no point in cloning that detail.
Long term, they should be able to compile the same clean C sources (ie no in line asm, or maybe, Taz C can tolerate GCC's approach, but GCC has no support for cleaner ASM.)
They are quite different in approach, Taz C as I understand it, is smaller and more nimble, but does not cover as many bases. Subset-C at this stage.
GCC is large, and rather locked into a register subset mapping, that flows from ARM et al code generation.
It also has poor in-line asm, that makes me shudder.
I would venture there is no point in cloning that detail.
Long term, they should be able to compile the same clean C sources (ie no in line asm, or maybe, Taz C can tolerate GCC's approach, but GCC has no support for cleaner ASM.)
In my opinion, it should be possible to write almost all code in C and very little or none in PASM. That seems to be the opposite of what is being proposed here, writing code in C or Spin and slowly migrating more and more of it to PASM.
Comments
All sounding quite impressive.
The optimizer utility is a little less important, if you have smooth in-line assembler, where the output of the compiler can be pasted back edited for tighter loops.
Things like DJNZ tend to not generate well from compilers, but are more natural in ASM, and REP will be similar.
Places where you actually need to do this, are not that many in most projects.
This SPIN programmer evaluates the return / investment ratio and puts it in terms of scale.
Gcc on P1 often feels like bringing a tank to a go kart race. Gcc on P2 is going to present quite differently.
So there is that. Ignoring it doesn't get us to better places. Just saying...
I am interested in Dave's effort because it has the potential to self host. Having a tiny or low complexity C as a self host option is as compelling as SPIN and PASM are. That is a new case, not a universal one. Just another great choice people will have.
On thing of value may be to pick up older, smaller C code and use it to build that bench computer use case. A P2 with SD, maybe even two SD connections may well make a potent little embedded workstation or development environment.
Peter has shown us a lot of how that can work today. FORTH is capable and small enough for it to make sense too.
We know SPIN and PASM along with BASIC can make similar sorts of sense.
Why not C?
Indeed!
When C gets nice and lean, it becomes possible to write useful and fast programs on 8 bit machines. While that is dated and limited today, I do not see the same dynamics in play on a small 32 bit multiprocessor. It looks like speed, overall memory and capability will make the lean and mean kinds of options compelling, not just retro.
I, for one, am very eager to see that all play out for lots of reasons.
Now, to the issue of "volitile", there are various schools of thought. If one were to assign portability a low priority, inline and or encapsulated assembly can make a ton of sense, as can factoring the code in various ways to limit or design away from the need fo those things.
So then, what is worth what?
Do I get a better return by learning all about a massive and complex compilier, or by exercising the CPU more directly?
When portability is a high priority, the compiler directives and pragmas make more sense. When portability is less of a priority or thing of value, other means may get it done in a more lean way, which also has value.
Does that also have to mean discontinuing SPIN, for adoption?
Right now, people have great choices. SPIN, BASIC, C, PASM.
And on this P2, it appears they will also have similar choices.
What else has to happen here?
C was designed in the days of single CPU machines. Quite rightly it's optimisers assume that there is but one CPU running the code and accessing the variables.
Put two processors together operating on the same data, or even an interrupt in one processor, and all of a sudden those assumptions used by the optimizers are broken. The compiled code misbehaves.
Hence the need for kludges like "volatile", so the programmer can tell the optimiser what is going on in reality.
What this points to is that programming languages for multi-processor machines should have that multi-processing built into their very syntax and semantics.
Some have bent the C style languages into that multi-processor paradigm, a moder day example is XC from XMOS.
If Taz could lean in that direction that would be great.
Yes, the "volatile" kludge earns a double wry smile, as the semantics are bass-ackwards.
Other tools chose better words like "keep" for stuff they did not want the tools to fiddle with, aka make vanish.
It's like that sticky gelignite you leave on the shelf whist turning around to do something else. Before you turn back the shelf, the wall and the entire house are blown away because someone else bumped it!
That kind of "volatile"
But, yeah, more seriously, C has no concepts of multi-tasking, concurrent execution, process isolation, process communication etc, etc, built into it's syntax/semantics. It's all a bolt on kludge of pragmas and libraries and junk.
C++ does little better.
2. tending or threatening to break out into open violence; explosive:
however there is also
1. evaporating rapidly; passing off readily in the form of vapor:
3. changeable; mercurial; flighty:
5. fleeting; transient:
and even, in computing itself
6. Computers. of or relating to storage that does not retain data when electrical power is turned off or fails.
ie Volatile is something more likely to go away, and not be there, when you expect it to be....
Volatile is closer in semantics to temporary, than it is to permanent.
Sadly, a directive chosen by someone with a limited vocabulary, and the rest is history....
As I said, "volatile" describes the situation very well.
As you point out "volatile" = changeable; mercurial; flighty; fleeting; transient;
Which describes very well the situation of an interrupt handler or other process or even hardware updating something.
What more do you want?
That said, of course English Vocabulary is not what they are hired for.
Perhaps, a variable directive that simply describes what it actually does ?
If I want something kept or preserved, or not touched by optimizers, there are a great many better words to choose.
The optimizer is going to be brutal, as it should be.
Normal, inert code benefits from this.
Volitile code does not.
Of course, one does ask how we can either avoid volitile, or the brutal optimization too.
For larger scale tasks, there are the steady stream of attempts to design volitile away, rust, go, etc...
For smaller ones? SPIN and PASM? Inline or more low level approaches? Something else?
At present, there is no one size fits all.
Have you ever listened to or read the writings of Brian Kernighan and Dennis Ritchie? I would not dare to say they had a limited command of English. Unix people were very literate.
"kept" or "preserved" does not accurately describe the situation at all. Kept or preserved by whom? In fact it's the opposite of "volatile". Do you want to have to write "kept" or "preserved" on all your global variables? As it happens that is the default assumption of the language it need not be spelled out.
I'm sure the original need for this keyword comes from the idea that some machine hardware can change the value in some register at any time. This needs to be spelled out to our compiler that otherwise assumes it has sole control over memory.
Hence "volatile". It's perfect.
Happens this also works well for describing what happens when other processors or interrupt routines can change memory at any time.
A word like "shared" might have done just as well I guess
Yes and guy like me would be able to understand it easier. And being able to write it without misspelling.
Enjoy!
Mike
Unused code removal is one, as is tail-folding etc
I think they do have an interest in C, but GCC has quite a lot of inertia, and that makes it less ideal as a focused solution.
Certainly GCC's in-line asm handling is quite 'ropey', but fixing that inside GCC is non-trivial, as they support a great many MCUs.
A simpler C, that is more transparent with in-line asm, and generates output that is designed to allow paste-back for those cases where manual optimize is desired, also gives a great way to learn Prop2 ASM.
Inline, done with a dead simple syntax, is a great option for learning PASM as well as a nice option for applying it more broadly. Last time we discussed SPIN, adding this was on the table. P2 HUBEXEC will make doing that a doddle. Simple, fast, etc...
As for C++ it's not really on Parallax. They have their education business and in that space, it's best to deliver what they ask for. If nobody is really asking, the opportunity cost on new coursework is very, very high. I've done a lot of targeted education in my life so far. A lot of the potential revenue is driven by the customer. Going against the grain must be carefully considered. It can pay off too, but the more likely outcome is a nice, big, sunk cost.
In terms of users, Parallax did the work needed for gcc on P1. They may leave P2 as a community project, or they may do that work again. Nobody knows right now. Education will likely drive and fund what happens.
From there, it's on us!
I've written many times before, people use what they use and they share what they share. C++ users now, who want to see more C++ users need to share and advocate and support.
Where that gets done, there will be a productive center of gravity that will attract users. If it's not done, there won't be. Simple as that.
Look no farther than Peter for a stellar example of how that is done, and is being done with FORTH too. Impressive! If you have even an inkling to explore Forth, he's right there. I consider this generous and the mark of a high quality person willing to share how they are having success.
Further, picking up Tachyon means getting a very nice tool kit. One can commit to giving it a go because there is a lot there. SPIN has this in the OBEX, forum support, and a pile of code to exploit.
C is getting there! It can use PASM blobs, there are at least two libraries, and there are people sharing and supporting too.
I don't see much C++ activity, though I do see users mentioning it and success together. More is better here.
If it were me, I would do a game, or some other impressive demo to show people what can be done. The more the merrier.
C could look simple, like this:
x=5; y=0; ASM { mov y, x } z=y*x;Take the brackets and semicolons away, and that's mostly SPIN syntax.
That kind of thing is ideal. All the labels, vars, etc... are common, maybe just to a given function, etc... And on the P2, maybe they want to use the CORDIC, or do something with the streamer. A simple, lean, inline facility makes doing any of that no harder than using one of the core language keywords.
If vars and such are a bother, it's going to see less use. If the syntax is a bother, or not just typing PASM lines nice and easy, it's going to see less use, etc...
Honestly, a whole lot of this is driven by how much people have to know to make it work, and how much they must keep track of too. More is more powerful, portable, etc... but it's not favorable to adoption.
Either way, having a center of gravity out there helps to suck people in. Once they are there, they will often advance. Having easy options makes sense. Crawl, walk, run!
A simple, lean, inline facility makes doing any of that no harder than using one of the core language keywords.
The more I consider it, the more important I think it is!
P2 has smart pins and lots of spiffy hardware modes and options, CORDIC, STREAMER, etc...
So, I'm thinking about both C and P2 SPIN here. Developing SPIN fully, with keywords and such for all those things is going to take a while! Maybe don't even do it!
Take the P1 spin, strip out the P1 keywords that map to PASM, like WAITVID, etc... and what's left is a nice, clean, language. It has variables, constants, data, operators, expressions, program flow, boolean comparisons, etc... one needs to do a lot of stuff!
If that simple, inline syntax above, minus the bracket as SPIN doesn't delimit with brackets, were the norm, then suddenly, SPIN and C look a lot alike! Not the syntax so much as what the language offers, with C offering more on pointers and such.
All the special stuff is done in PASM from day one! Either one is small enough to self-host, and the basic optimizations would all apply. People can write fairly sophisticated programs and get the speed benefit of PASM while also having the program structure and control benefit of SPIN and or C. (they choose, based on what makes sense for them, but the PASM is common)
Additionally, a lot of the PASM goodies in the P2 won't be portable, so why even bother?
The answer, of course, is some people will need to bother due to some requirements they work with, or they have well established toolchains they want to continue using, etc... All good. Something like GCC will get them there with the common gnu tools, syntax, etc... All that stuff will get done anyway, meaning it will be there for those who need it. Not a worry.
Otherwise, it's simple, lean, fast!
People could be using PASM almost from day one and hardly even notice! They might do it an instruction or two at a time, just to make use of a Smart Pin, or stream, whatever. If the syntax is lean and mean, this won't be any harder than learning all the specialized SPIN keywords and syntax associated with them anyway.
P1 had to have those things because SPIN compiled to bytecode, and due to how the COG works. We didn't even know what LMM was, until Bill figured it out. (I think doing bytecode should still be an option on P2, but I digress...)
P2 doesn't have to have those things because it does HUBEXEC, and it's not like the bytecode can't have PASM instructions right in it anyway, if that route is taken. The non-aligned PASM instructions allow for that case too.
Maybe P2 doesn't need all those extras defined and packaged up in it's SPIN or C language support either, so long as inline PASM is dead simple and easy. Or, maybe a lot of it can be done as pre-cooked functions and or library code too. We ship the core P2 SPIN, and example library support for a few common things, and over time, just keep adding to the library / program snippet collections, many of which are just a couple of PASM instructions wrapped in a function, or simple, "copy / paste" block.
I keep thinking back to that compiled BASIC I was telling you guys about. The syntax above is how inline assembly was done. And it was super simple to use, due to all the variable names and such working just fine for inline code, no hassles. The result of it was ordinary, non programmer types, actually writing 6502 assembly when they needed to!
Here is a code snippet:
No multiply instruction on 6502, and that little multiply inline is a lot faster than the general case one the language offers. In this case, people start out writing easy expressions, find out it's too slow, and start using ASM to speed up the program, or they write little bits to make the special hardware functions do their thing. It's too easy.
In that example, more could be done, and if the need is there, all the user needs to do is revisit it, and inline more things, until it's all assembly, if they want / need to.
And that's a compiled BASIC, with inline assembly, useful on a machine with 128 BYTES of RAM too. The author of that compiled basic was told doing it was both impossible and impractical. Since that time, thousands of game programs have been written, by a few hundred people, many of whom have little to no real programming experience. I know this author personally, he lives here in Portland, Oregon. He changed how home brew retro gaming was done with this type of language thinking. It went from some esoteric thing to something an ordinary person can do for fun. Some of these programs ended up commercial quality too. One of those was written by a kid in Salem, Oregon. A kid who literally knew nothing about programming initially.
Pretty amazing, if you ask me. Fast and useful too.
That same kind of thinking on this chip will pay off big. It's a PASM playground, and it has a lot of spiffy hardware to exploit. A lean SPIN, intended to help with program flow, etc... or a lean C setup the same way, is not hard to write in. People take in little bits, and soon they are writing pretty fast, lean, useful programs.
In our case with P2, people would write all the basics in the high level, and inline special goodies. Might just be one instruction or a few in most cases too.
To me, having people able to get going quickly and get the benefit of PASM while doing it, is worth some, "why not do the work to help people exploit it directly in PASM?" thought.
What we get for doing it this way is lean and mean language support early on. People have all they need to really do stuff right away.
Over time, maybe add higher level support for all the goodies, with the benefit of all the use cases that will be out there in the wild. Those higher level things will be targeted for a PC and will include much more sophisticated language support (C++, etc...), and will generally be a super-set of the core tools shipped on chip, or that load on SD card, for use on the chip. Whatever.
Maybe this "self hosting" business has merits beyond not needing anything else besides the chip to write programs.
It may make a TON of sense to target the self-hosting as a constraint to insure the language support provided at release time is lean, mean, functional and complete enough for people to use without delay.
And that is what interests me about Dave's effort here. It's a perfect compliment to SPIN, and it's C! We get the basics for both camps, potentially on chip*! What's not to like about that?
A more "proper", big SPIN and C / C++ happens later, after P2 release. And gcc might be there anyway, depending. In either case, I think a big SPIN, feature complete at the higher level, is going to take some time. And it should take that time too. Rushing it won't make any sense.
*I don't know what actually will exist on the chip, in ROM. Maybe that's just monitor, editor, assembler, crypt, booter, loader. 16K probably will hold those. If monitor and assembler were one thing maybe, with hooks inserted for additional language support, perhaps "small" SPIN and or C can be loaded from SD card and would just be available as an additional command or few when present.
Doing something like that means we can get the chip done, and it ships with useful PASM, and while we wait for fab, the other "on chip" loadable tools get done too. At release time, we've got the basics for people ready to go.
On the other hand ... this is a chance to go a bit wild:
void myCogProcess1(param1, param2) { // Do something } void myCogProcess2(param1, param2) { // Do something } int main () { par { myCogProcess1(param1, param2); myCogProcess2(param3, param4); } }Build the multi-processor nature of the Prop into the language. Perhaps with "channels" to communicate between COGs.
I think that is done with the (future?) extra layer mentioned ?
This does bring us to Debug support, which is where many-layers of code can fall over.
SDCC manages this with special syntax comment tags in the created ASM (and any intermediate files), which allows a debugger to find the source file, and line #, and also find declaration of the variable.
Those tags can also give a choice of HLL step, or ASM step debug.
That can work well, but it adds (considerable) visual clutter to the ASM, and for the copy/paste pathways, it may pay to create two ASM files :
ie One with the debug tags, and a cleaner one for human use (scan/copy/paste into in-line ASM)?
The actual ASM code would assemble the same, from either.
To do that would require a full clone of GCC ?
They are quite different in approach, Taz C as I understand it, is smaller and more nimble, but does not cover as many bases. Subset-C at this stage.
GCC is large, and rather locked into a register subset mapping, that flows from ARM et al code generation.
It also has poor in-line asm, that makes me shudder.
I would venture there is no point in cloning that detail.
Long term, they should be able to compile the same clean C sources (ie no in line asm, or maybe, Taz C can tolerate GCC's approach, but GCC has no support for cleaner ASM.)
Should Taz implement OMP and C++ ?
When the first P2 design failed, they took off on GCC for P1...
At least, that's how I remember it...
Also, C++ for P1 is a bit crazy due to the limited memory.
But, on P2 it should be great.