Sapieha & ozpropdev,
There is an opcode map posted by Chip a few pages back - dated 12 March - I posted a summary yesterday that excludes the new RESxx instructions.
I wonder why instructions with the same function must have different mnemonics on the Prop1 and the Prop2.
Would it not be much easier for Prop1 users to make the transition to Prop2 if instructions that exist on both have the same mnemonics?
Also if you often switch between Prop1 and Prop2 programming (like I do at the moment) the mess in the brain is inevitable.
Some post's back I posted to You --- That Yours sumary are missing some instructions
Sorry -yes thats what started this. AFAIK i have copied all instructions from Chips list of 12 March. FIXINDA/B/S and SETINDA/B/S are probably the same as beforeand sharethe sameopcode.
I removed SETZC and replaced it with PICKZCbecause that is what Chip did.I added Another ( see above). Ineed to check WAITCNT as I am away till tomorrow night late.
I wonder why instructions with the same function must have different mnemonics on the Prop1 and the Prop2.
Would it not be much easier for Prop1 users to make the transition to Prop2 if instructions that exist on both have the same mnemonics?
Also if you often switch between Prop1 and Prop2 programming (like I do at the moment) the mess in the brain is inevitable.
Sorry -yes thats what started this. AFAIK i have copied all instructions from Chips list of 12 March. FIXINDA/B/S and SETINDA/B/S are probably the same as beforeand sharethe sameopcode.
I removed SETZC and replaced it with PICKZCbecause that is what Chip did.I added Another ( see above). Ineed to check WAITCNT as I am away till tomorrow night late.
NOP was missing from Chip's list. I noticed it when I was writing my NOP/NOP/WAIT question. There may be others. We've been throwing things at Chip at such a fast pace and he's been cranking out instructions so quickly. There are bound to be things that need to be reconciled between lists our memories and what Chip actually implemented.
What I should do is write a program that parses Chip's instruction list and automatically generates an assembler to match.
What if pnut had a flag that would dump out its internal symbol table + encodings in a regular form? Not sure how Chip has organized pnut but it might help external tool developers to track releases. There'd still be some gaps to close each time, though.
What if pnut had a flag that would dump out its internal symbol table + encodings in a regular form? Not sure how Chip has organized pnut but it might help external tool developers to track releases. There'd still be some gaps to close each time, though.
That might be helpful. My spinwrap utility uses symbol information produced by OpenSpin (thanks Roy!). I'm really surprised that PNut isn't based on OpenSpin. Now that Parallax has an open source high level language portable implementation of Spin I would have thought that would become the reference implementation and the basis for Spin2. Now we have another x86 assember based Spin compiler/assembler that will have to be ported all over again to make OpenSpin2. Seems like it would have been better to just start with OpenSpin to create Spin2.
That might be helpful. My spinwrap utility uses symbol information produced by OpenSpin (thanks Roy!). I'm really surprised that PNut isn't based on OpenSpin. Now that Parallax has an open source high level language portable implementation of Spin I would have thought that would become the reference implementation and the basis for Spin2. Now we have another x86 assember based Spin compiler/assembler that will have to be ported all over again to make OpenSpin2. Seems like it would have been better to just start with OpenSpin to create Spin2.
I think PNUT has been with Chip a long time and he can easily change it to do his bidding as he makes changes and does testing. OpenSpin2 will come along once things are settled and Roy has an instruction set to work with. PNUT also has any P2 loader needs taken care of.
It would be nice to have OpenSpin2 keeping pace with P2 developments, though. Especially now with PropellerIDE coming along so well.
mindrobots has it right. pnut is Chip's long time dev tool. Part of it is the x86 code, of which the older version is what I used to make OpenSpin. It's much faster for Chip to work with pnut to implement the stuff he needs for working with the FPGA.
Yeah, it does mean that there will be more work involved in porting Chip's x86 code again to make OpenSpin2 (?), but I don't think it was feasible to have Chip updating OpenSpin, or rely on me to keep up the pace and spend the time needed to do so (which I did not have). I don't think it'll be that bad though, I already have OpenSpin, and big chunks of the x86 will be the same or very close to the same, so It won't be too terrible.
We should also remember how Chip often thinks. The assembly language Pnut is bot familiar and resonant in terms of how he sees various things play out. Low level thinking in a number of directions at once.
Pnut is highly likely to end up on the P2 itself, and this was hinted at when we expanded to HUBEX and the much improved tasking. Doing that in PASM will make a lot of sense to Chip.
Then we end up with the higher level OpenSpin, and the basic Pnut, self-hosted environment. From there both camps do their thing...
I was taken aback at that as well. But then I immediately realized why it is so.
It's much quicker and easier for Chip to change his x86 assembler code than the C++ version.
One could say the x86 is the source language and it gets "compiled" into C++ by Roy.
Weird ain't it?
This tells me that either Chip is an ACE assembler programmer or C++ is just to hard to pick up in a hurry.
I suspect it's both
If the goal is to eventually do development directly on the Propeller, it seems like the most sensible approach would be to write the tools in C so they can be recompiled to run on the Propeller. Writing in x86 ASM means they have to be compietely rewritten from scratch (in PASM?) to move them to the Propeller. And then you have to maintain two separate code bases so improving the tools becomes more difficult.
Yep, from a purely software engineering approach that is what we might expect. Whist we are at it let's:
1) Rigorously specify and document the P1 instruction set and Spin byte codes.
2) Rigorously specify the Spin language. BNF and all that.
3) Create a Spin compiler from those specs. In C/C++.
4) Rinse and repeat for the P2.
Result, a Spin compiler that can be run on any platform including the PII with propgcc.
However this is Parallaxia and what we have is a chip architecture evolving as we speak and the corresponding assembler morphing along with it.
mindrobots is right. I suspect Chip can work faster in x86 assembler than he could if he took up learning C++. I also suspect Chip has no interest in learning that monstrous disaster of a language, who could blame him for that?
I do worry that openspin was created by reverse engineering the original x86 code. It ends up reflecting that original implementation rather than being a nice clean design derived from the language specification. However I trust that Roy can pull it into shape with time.
mindrobots is right. I suspect Chip can work faster in x86 assembler than he could if he took up learning C++. I also suspect Chip has no interest in learning that monstrous disaster of a language, who could blame him for that?
Chip is a really smart guy! I'm sure he could learn C++ if he wanted to. :-)
I haven't looked that closely at the source for OpenSpin. Does it really use much of C++? I'm still surprised that Chip doesn't like C since it is a fairly minimal language that matches low-level CPU architectures fairly well. I know it has some syntacitic features that some don't like llike having to write prototypes for functions but that doesn't really get in the way of its usefulness. Anyway, things obviously aren't going to change so I should stop talking about this. :-)
openspin does not use much of C++. It defines 10 or so classes. For symbols and tables and such. Luckily it is not using STL. That might have totally scuppered the idea of openspin.js in the browser.
Chip is a really smart guy, perhaps too smart to waste time on C++
openspin does not use much of C++. It defines 10 or so classes. For symbols and tables and such. Luckily it is not using STL. That might have totally scuppered the idea of openspin.js in the browser.
Chip is a really smart guy, perhaps too smart to waste time on C++
Well, I wouldn't be surprised if he didn't like C++. I'm on the fence about it myself although I think it can be used effectively with care. I suspect that's what Roy did in OpenSpin. C is certainly a simpler but adequate language if not elegant. Anyway, it is what it is now and nothing I say will change it.
IMHO, Chip needs to do it the Chip way. We all know it's effective, and so that is where we are. No worries really.
Once we get "it done" whatever "it" finally ends up being, we will get a C port, tools, etc...
At that point, a few things will happen:
1. P3 development, or P2 variants will start. Who knows? But it will be exciting, and I'm as eager to see that as I am a P2 chip, so that I can start making some stuff I want to make. Others have their stuff, and we need to be making more than baking sooner rather than later.
2. C based tools, and I'm basically lumping C / C++ into just C, though I know that's too coarse for some people, I think it's OK, because the intent is to get things into a higher level where the work here can join and leverage the large body of open code out there. We need this, and it's a good thing. That camp will take off and lots of good things will happen. Libraries, projects, drivers, tools, and all the other things we like to see will build up. We will get portability and interoperability from this activity, and we need that too. All of that leads to familiar and worthy ends, but...
3. SPIN, which really is SPIN+PASM will happen too. Chip did something with P1 I found particularly notable. And that is SPIN really is SPIN+PASM, and it's just one unified thing! It very strongly reminds me of the BBC Basic, and other similar kinds of environments seen in 8 bit computing, where using assembly language was so necessary to realize acceptable performance and even just accomplishing some tasks is concerned! On those machines, a killer text editor is assembly language out of necessity! Games, graphics, tricks, mostly required it too.
The melding of the two so closely is an approach that isn't portable, though it can be interoperable. So here's the thing about that:
Both have their merits. It's my strong desire to see both #2 and #3 compete here, not to realize which one is "better" or "right" That's getting into religious wars, and those are a lot of fun sometimes, but not really an end goal worth our time as a means to some end. So, it's just not about that.
It's about enabling people to get stuff done. Some of us want to do that in the context of the greater body of code and hardware and knowledge out there, and that means C and other languages potentially (Heater and his JS advocacy is relevant to the P2, because we've made it potent enough for that now), to take advantage of open code, tools, libraries, and all that is good in open code land. It's my opinion, P1 and C got there. Some of us are doing cool things! And it's good to see, but it's tough to do on P1. This isn't a knock on C, but just a reality of the design. Nothing more.
On P2, the overall speed, scale, etc... are such that C is going to shine, IMHO! If you go back and look at 8 bit computing, it was a very similar dynamic. At that time, I was making things happen on 8 bit computers, as many of us were. I had a C for Apple ][. Aztec C, I believe. Had a Forth too, but never did much with it. There was PASCAL, which actually worked well too. All of those environments brought higher level capabilities, but they came at a price, and the price generally was making it tough to really push the machine, but the reward was being able to do higher level things more easily too. We saw Appleworks, for example, the first integrated Office type environment. That was awesome! But we also saw things like spiffy games, multi-channel music, and other types of tasks get done, and the approaches were very different.
I could go and link some other similar kinds of things, but I won't due to length. Just note when we entered 16 bit computing, things got big enough and fast enough for C and other HLL environments began to make great sense. We are experiencing this very same dynamic with P1 and P2.
Also note, PoP would never, ever have happened without a killer assembler. Merlin was made for the Apple ][, and it does some odd things for an assembler, but it maximized the Apple 2. Appleworks type applications (and I don't recall what Appleworks was authored in at the moment) would not have happened without HLL development maximizing the machine in other ways. The end result being we got one heck of a lot more out of the Apple ][ for both types of environments being present than we would have otherwise, and it's the same story for the P2.
The other basic point I'm making is this, to support why that is:
SPIN (SPIN+PASM) centers on performance, lean programming, assembly, maximizing the capability of the hardware and maximizing the direct accessibility of the hardware. As Chip puts it, "getting right on the clock edge" kinds of things. On the P1, we did video tricks, which are now possible in C, in PASM back then, and it was fairly easy, and definitely lean. I could go and learn SPIN, by inference understand a lot of PASM, and make a video driver do something new in a day or two. Amazing. And that's cold, just jumping in from ordering a Demo Board after seeing a few things online. It would take me the same couple of days to grok all the directives, pragmas and other things needed to instruct C in ways that I can just write in PASM. Again, not one better than the other, just different.
Go and look at BBC Basic and the impact that had on a lot of people. Frankly, it's the same kind of vision SPIN+PASM has today, and it has it's merits. Frankly, I don't think anyone else designing this kind of stuff even thinks that way, and so those of us who recognize those merits are wanting to make sure we see it, because it's quite frankly, brilliant!
We are better off having both of these exist, even if that means some difficulty sharing code, interoperating, whatever. In the mid to longer term, it won't matter at all. We will have many kinds of great happening.
4. Hardware is going to get made. IMHO, some really cool stuff! And again, we are going to see a couple of basic paths taken. Some are going to want to self-host development, or maybe just run lean with SPIN, and that will compete with and balance out those who are going to want to attempt bigger things, different things and do so in C.
One vision Chip has for the P2 is to get interactive. Again, there is a parallel in computing. Remember the Amiga vs the PC? The P2 is Amiga like, in that the hardware centers on a few basic ideas, and it's real time nature and focus on graphics, sound, robust I/O, and now tasks means being able to do a lot of things that would normally be done with an OS, sans that OS. I think this will be very significant. It will be significant in the way the Amiga, which also had a hardware focus on specifics was significant.
Some of us see it differently, and want the packaged up capabilities to make leveraging other code out there, along with code we write, easier and maybe perform better in some ways. I'm in this camp too, thinking I will be able to combine some lower level driver code with C code I see out there and use it in ways very similar to how I used SPIN objects.
To sum up: Doing is this way is going to have some benefits. It's a bit more work, but we get the advantages of both in the end, and I have to tell you, I wouldn't be here if it were not for SPIN+PASM being what it is on P1. Now, having been here, I've wanted to do things in C or sometimes just larger things than I find possible now, and some of us have worked to make that happen. Look at Dr_A over the years, along with others, Heater, SRLM, David and the GCC team, Ross, et al. C works now!
All that tells me is there is plenty of demand for both basic paths, and we need to maximize those and not worry about having the one unified way. The only way we are going to see that magic is to enable Chip to do what he does and when it's done, we've got it. This time, because of all we know and have learned on P1, we can take the best of that, and know we are on a bigger, more capable chip designed with C in mind, and then build up C to the point where it's magic too.
So, it's not about wasting time on C++ and it's not about C being better or worse, or right or wrong. It's about realizing SPIN, and the way that happens is Chip builds it the way he builds it. And we need that to exist. I want it to exist. C and other higher level friends, and even things like other kinds of assemblers, JS, who knows will happen too, and we need those to exist, and I want those to exist.
But SPIN can't exist, unless it's built as is being done right now, so it's gotta be done right now, how it's done as one holistic package. P2 chip, SPIN+PASM, etc...
The moment we can solidify the design enough to start other development efforts, those can and ideally will kick off the same way and everybody is happy, doing things they want to do.
***FWIW, this is precisely why some of us object to "standard assembler", etc... comments being made. SPIN+PASM is one thing really, and that has implications that when ignored make SPIN less of a beautiful and effective thing than it otherwise would be.
Let's maximize it, and the moment we can, let's maximize C and friends too. This should not be a disappointment, but instead a celebration! The P2 is going to kick a lot of Smile on both fronts, and that's nothing but good.
I wonder why instructions with the same function must have different mnemonics on the Prop1 and the Prop2.
Would it not be much easier for Prop1 users to make the transition to Prop2 if instructions that exist on both have the same mnemonics?
Also if you often switch between Prop1 and Prop2 programming (like I do at the moment) the mess in the brain is inevitable.
Andy
Perhaps a switch setting to use the new P2 instructions or the old P1 ones, or accept both as long as the P1 mnemonics are not used for something else on the P2.
I wonder why instructions with the same function must have different mnemonics on the Prop1 and the Prop2.
Would it not be much easier for Prop1 users to make the transition to Prop2 if instructions that exist on both have the same mnemonics?
Also if you often switch between Prop1 and Prop2 programming (like I do at the moment) the mess in the brain is inevitable.
Agreed, but the key is instructions with the same function
ie they need to be identical opcodes. IIRC Chip mentioned something a while ago about JNZ is not quite the same as TJNZ, as one alters the flags, the other does not ? (both jump on non zero)
If the opcodes are exact clones, then this makes sense, and the choices are
a) A simple alias, allowing either
b) A switch option
SPIN (SPIN+PASM) centers on performance, lean programming, assembly, maximizing the capability of the hardware and maximizing the direct accessibility of the hardware.
It's interesting that you mention performance. Unless Chip is going to do something significantly different with Spin2 than he did with Spin, the performance of Spin2 won't be all that stellar. Of course, PASM2 performance will be excellent but would be true no matter which high level language PASM is married to. Well written assembly language will always be faster than compiled high-level code. Anyway, if you want the best performance in high-level code, I suspect you'll have to use C not Spin. This is certainly true on P1 anyway.
It's interesting that you mention performance. Unless Chip is going to do something significantly different with Spin2 than he did with Spin, the performance of Spin2 won't be all that stellar. Of course, PASM2 performance will be excellent but would be true no matter which high level language PASM is married to. Well written assembly language will always be faster than compiled high-level code. Anyway, if you want the best performance in high-level code, I suspect you'll have to use C not Spin. This is certainly true on P1 anyway.
No surprises there. C was originally intended as a slightly higher level assembly language replacement. The nice thing is that with assembler, C, and Spin we now have three choices of speed vs ease of programming.
I'm are big fan of 68000 CPU programing on Aple and Atari and others.
BUT for simple conversion of 68000 ASM code to P2 needs one instruction that can simulate TRAP instruction in them.
In 68000 it is an Interrupt instruction ---- BUT that said ALL interrupt instructions in 68000 are SHORT hand for CALL X,index.
I postulated for that one but as I know we will not have that one
No surprises there. C was originally intended as a slightly higher level assembly language replacement. The nice thing is that with assembler, C, and Spin we now have three choices of speed vs ease of programming.
Performance comes down to the marriage between the two. The only lament I have on P1 is we didn't get in-line PASM, and we didn't get it back then, because it took Bill's LMM insight to even have it make sense. So we packed things into COGS and let the COGS be available for a SPIN program to make use of them. It's still brilliant, and fast to develop, and it performs quickly.
If you go back and look at things like BBC Basic, the same performance argument was made, despite a BASIC not being all that fast relative to a compiled or even some other byte code environments, like PASCAL.
The performance came from being able to use assembly language where needed, and where the two can be freely mixed, performance becomes easier to realize while keeping all the benefits of a HLL in the first place. What ends up happening is pure assembly gets used to maximize something, and back then as well as today on P1, that might mean getting more colors on the screen, or making sounds, or driving a motor, whatever. Then, there are those things that require moderate performance, and back then it was a mix, and on P1, that ended up being LMM. Finally, there is the supervisor or very higher level code, which doesn't need to go that fast at all.
SPIN performs as fast as most 8 bit assembly language does. Well, 8 bitters running at a few Mhz. Once, I wrote similar things in SPIN and assembly on the Apple and Atari machines I have. Was gonna do the 6809 CoCo, but didn't. Anyway, SPIN compared favorably, and was faster in some instances, not much slower in others.
Now, performance is relative. Relative to what?
That is task dependent. Say you want to do a game, or manage a GUI, or provide some logic that augments some lower level needs, like actually displaying things, motors, etc... SPIN relative to the task of providing user interaction is very fast. Plenty, with room to spare. Heck, SPIN is fast enough to chase the beam on a TV screen too, able to respond to some mid-screen event, get something done, and continue on. Now, when writing more of the program in SPIN, performance becomes an issue, precisely where C picks up the ball to provide more. Great! I would argue the scope of possible tasks on P1 just doesn't get big enough often enough to push people off SPIN, particularly with PASM so easy. On P2, that's not gonna be true, and I suspect a compiled SPIN to PASM may well be better than byte code, and C will shine for sure.
One interesting metric is P2 SPIN as byte code is likely to perform on par with P1 PASM. Seems to me, that's quick. Not best, but when looking at an environment that is optimized along a number of fronts, that trade-off makes sense, particularly given a clean, lean, easy, accessible PASM is right there.
And I have to say, few things have been as easy as SPIN+PASM where using assembly and a HLL are concerned. Nothing ever was as lean as SPIN+PASM is. Brilliant! I really want that for P2, because it's a nice to have and it will shine for those so inclined.
Seems to me, that's good performance, and because SPIN is basically one with PASM, where more is needed, we can simply do that, and that's lean, and it carries through to maximizing the direct access to the hardware too.
I fully expect C to significantly outperform SPIN, unless Chip decides to compile to PASM this time. Then it may be much closer, and I think C will likely have the edge, but less of one. That's all just thumb in the wind, of course. It's too early.
So let's talk about that marriage a little.
Inline assembly can be complicated, or simple, and on P1, we didn't get inline, just COG. But it was pretty simple. On P2, we are definitely going to get inline, and it's likely to be simple like BBC Basic and other kinds of environments are simple. Doing that in C is a bit more involved, and nothing wrong with that. The "more involved" part has to do with higher level concepts, and the capability of the compiler, different environments, things like encapsulation, etc... All good.
But it's not as lean as an environment specifically targeted to the chip is. The cost is portability, and an increased difficulty with interoperability. Some people will pay that, others won't, and that's really the primary reason why I and others want SPIN+PASM to exist. On P1, it was one holistic effort, which made for a very sweet and productive environment. On P2, it is highly likely to be the same way.
I can jump into a SPIN and really I'm talking SPIN+PASM, environment, knock something I want out and really need to know very little, track very little to just make it go. With C, there is more involved. Now, if I want to do some planning and build something bigger, those things in C which get in the way of lean, just write it, run it, go, type efforts, pay off on the larger ones. It's this dynamic I see playing out on P2 because it's big enough to warrant having those things because P2 is big enough for people to attempt big enough things for it all to pay off!
Re: Hand assembly vs compiled.
Yeah. Totally, particularly on this playground of a chip. Frankly, that's the number one argument for making sure we get a SPIN designed in the way we did for P1. We will want those goodies exposed in ways that are lean and accessable just like they were on P1. People can jump in, do amazing things, and move on to whatever else they are wanting to do. Hand PASM will matter on the P2, but not too much, because it's going to perform well on compiled, because we've taken time to help that along.
A lot of people won't care too. And that's the strongest argument for C and friends on the P2.
BTW: If somebody out there makes in-line easier, less verbose, etc... in C, I'll be very happy, and I really don't care what it breaks. "WHAT??" you say? And rightfully so, I would agree with you, which is precisely why SPIN needs to exist, put another simple way. Some of us are selfish, don't care, greedy, whatever, and we just want to write it, see the magic happen and move on, caring very little about anything else. SPIN helps that along, and there is no big harm in having it that way. Just choices. Valid ones, if incompatable. Others of us dislike that kind of thing, and there are other choices. If we can maximize those, we win!
For me personally, I really enjoy assembly language programming, but I don't enjoy making larger assembly language programs. That's what the HLL is for! Secondly, I like middle sized programs to be lean, and so "basic" like HLL's are attractive, because I can get in, do it, get out, and not worry too much. There is a clear niche there shared by many similar minded people who maybe want to see or do something, but not get too deep into the software engineering side of things. That's SPIN.
Others are going to want to get into it on that level, and or do bigger projects. That's very likely C. Maybe C with some PASM magic sprinkled in here and there. All good. Encapsulate it, and you even have a shot at it being portable, though I have no idea to what. Another day.
Anyway, I like to write the program, bump into a performance point, and just write that PASM, and then continue on with as few worries as I can manage. That's often SPIN, though it may well be C for me too. Don't know yet. I do know I want to do some C programming on the P2, and I want to be able to use code I see out there, etc...
No surprises there. C was originally intended as a slightly higher level assembly language replacement. The nice thing is that with assembler, C, and Spin we now have three choices of speed vs ease of programming.
I'm are big fan of 68000 CPU programing on Aple and Atari and others.
BUT for simple conversion of 68000 ASM code to P2 needs one instruction that can simulate TRAP instruction in them.
In 68000 it is an Interrupt instruction ---- BUT that said ALL interrupt instructions in 68000 are SHORT hand for CALL X,index.
I postulated for that one but as I know we will not have that one
Yeah I hear that. Honestly, I think we've got lots of niche instructions now, and the balance is good. Seems to me, there are answers for that case. It just takes a little more.
Amiga, Atari ST, BBC, Acorn, had BASIC HLL environments with super easy in-line assembly language capabilities. Some of those could be compiled too, which rocked pretty hard. Build it interactive, adding inline where needed, and then compile the whole works to make it sing!
Maybe SPIN can work both ways too. Offer byte-code for best case size, compile for best case speed, and inline PASM to drop the 'magic' in where appropriate and necessary. Could be good times man!
Yeah I hear that. Honestly, I think we've got lots of niche instructions now, and the balance is good. Seems to me, there are answers for that case. It just takes a little more.
Amiga, Atari ST, BBC, Acorn, had BASIC HLL environments with super easy in-line assembly language capabilities. Some of those could be compiled too, which rocked pretty hard. Build it interactive, adding inline where needed, and then compile the whole works to make it sing!
Maybe SPIN can work both ways too. Offer byte-code for best case size, compile for best case speed, and inline PASM to drop the 'magic' in where appropriate and necessary. Could be good times man!
There are at least two levels of questions mixed up here in recent posts:
1) What languages we want for Propeller development? Well, there will be Spin and C/C++. Both are great and both have their place and their followers. And yes others will come up with BASIC and 20 different versions of Forth etc.
2) The other level is, what languages should these Propeller language tools be developed in?
Ultimately they will be available in C/C++. Propggc of course is anyway. Openspin is C++ and will support P2 at some point.
The only little fly in the ointment just now is that Chip's PNUT is in x86 assembler and only available for Windows. A bit of an annoyance for those of of us who don't run legacy operating systems. A total no-go for users of ARM machines.
All in all the situation is good and will get much better. Life is good.
P.S. Some may think I make contradictory statements about C++. So I do. I love it really. It's just that it is a fractal of infinite complexity that no human can understand any more.
Comments
Some post's back I posted to You --- That Yours sumary are missing some instructions
Would it not be much easier for Prop1 users to make the transition to Prop2 if instructions that exist on both have the same mnemonics?
Also if you often switch between Prop1 and Prop2 programming (like I do at the moment) the mess in the brain is inevitable.
Andy
I removed SETZC and replaced it with PICKZCbecause that is what Chip did.I added Another ( see above). Ineed to check WAITCNT as I am away till tomorrow night late.
+1 anyplace this can happen surely helps!!
NOP was missing from Chip's list. I noticed it when I was writing my NOP/NOP/WAIT question. There may be others. We've been throwing things at Chip at such a fast pace and he's been cranking out instructions so quickly. There are bound to be things that need to be reconciled between lists our memories and what Chip actually implemented.
What if pnut had a flag that would dump out its internal symbol table + encodings in a regular form? Not sure how Chip has organized pnut but it might help external tool developers to track releases. There'd still be some gaps to close each time, though.
I think PNUT has been with Chip a long time and he can easily change it to do his bidding as he makes changes and does testing. OpenSpin2 will come along once things are settled and Roy has an instruction set to work with. PNUT also has any P2 loader needs taken care of.
It would be nice to have OpenSpin2 keeping pace with P2 developments, though. Especially now with PropellerIDE coming along so well.
Yeah, it does mean that there will be more work involved in porting Chip's x86 code again to make OpenSpin2 (?), but I don't think it was feasible to have Chip updating OpenSpin, or rely on me to keep up the pace and spend the time needed to do so (which I did not have). I don't think it'll be that bad though, I already have OpenSpin, and big chunks of the x86 will be the same or very close to the same, so It won't be too terrible.
Pnut is highly likely to end up on the P2 itself, and this was hinted at when we expanded to HUBEX and the much improved tasking. Doing that in PASM will make a lot of sense to Chip.
Then we end up with the higher level OpenSpin, and the basic Pnut, self-hosted environment. From there both camps do their thing...
It's much quicker and easier for Chip to change his x86 assembler code than the C++ version.
One could say the x86 is the source language and it gets "compiled" into C++ by Roy.
Weird ain't it?
This tells me that either Chip is an ACE assembler programmer or C++ is just to hard to pick up in a hurry.
I suspect it's both
I don't think that is a hard question for anyone to answer.
Yep, from a purely software engineering approach that is what we might expect. Whist we are at it let's:
1) Rigorously specify and document the P1 instruction set and Spin byte codes.
2) Rigorously specify the Spin language. BNF and all that.
3) Create a Spin compiler from those specs. In C/C++.
4) Rinse and repeat for the P2.
Result, a Spin compiler that can be run on any platform including the PII with propgcc.
However this is Parallaxia and what we have is a chip architecture evolving as we speak and the corresponding assembler morphing along with it.
mindrobots is right. I suspect Chip can work faster in x86 assembler than he could if he took up learning C++. I also suspect Chip has no interest in learning that monstrous disaster of a language, who could blame him for that?
I do worry that openspin was created by reverse engineering the original x86 code. It ends up reflecting that original implementation rather than being a nice clean design derived from the language specification. However I trust that Roy can pull it into shape with time.
I haven't looked that closely at the source for OpenSpin. Does it really use much of C++? I'm still surprised that Chip doesn't like C since it is a fairly minimal language that matches low-level CPU architectures fairly well. I know it has some syntacitic features that some don't like llike having to write prototypes for functions but that doesn't really get in the way of its usefulness. Anyway, things obviously aren't going to change so I should stop talking about this. :-)
Chip is a really smart guy, perhaps too smart to waste time on C++
Once we get "it done" whatever "it" finally ends up being, we will get a C port, tools, etc...
At that point, a few things will happen:
1. P3 development, or P2 variants will start. Who knows? But it will be exciting, and I'm as eager to see that as I am a P2 chip, so that I can start making some stuff I want to make. Others have their stuff, and we need to be making more than baking sooner rather than later.
2. C based tools, and I'm basically lumping C / C++ into just C, though I know that's too coarse for some people, I think it's OK, because the intent is to get things into a higher level where the work here can join and leverage the large body of open code out there. We need this, and it's a good thing. That camp will take off and lots of good things will happen. Libraries, projects, drivers, tools, and all the other things we like to see will build up. We will get portability and interoperability from this activity, and we need that too. All of that leads to familiar and worthy ends, but...
3. SPIN, which really is SPIN+PASM will happen too. Chip did something with P1 I found particularly notable. And that is SPIN really is SPIN+PASM, and it's just one unified thing! It very strongly reminds me of the BBC Basic, and other similar kinds of environments seen in 8 bit computing, where using assembly language was so necessary to realize acceptable performance and even just accomplishing some tasks is concerned! On those machines, a killer text editor is assembly language out of necessity! Games, graphics, tricks, mostly required it too.
The melding of the two so closely is an approach that isn't portable, though it can be interoperable. So here's the thing about that:
Both have their merits. It's my strong desire to see both #2 and #3 compete here, not to realize which one is "better" or "right" That's getting into religious wars, and those are a lot of fun sometimes, but not really an end goal worth our time as a means to some end. So, it's just not about that.
It's about enabling people to get stuff done. Some of us want to do that in the context of the greater body of code and hardware and knowledge out there, and that means C and other languages potentially (Heater and his JS advocacy is relevant to the P2, because we've made it potent enough for that now), to take advantage of open code, tools, libraries, and all that is good in open code land. It's my opinion, P1 and C got there. Some of us are doing cool things! And it's good to see, but it's tough to do on P1. This isn't a knock on C, but just a reality of the design. Nothing more.
On P2, the overall speed, scale, etc... are such that C is going to shine, IMHO! If you go back and look at 8 bit computing, it was a very similar dynamic. At that time, I was making things happen on 8 bit computers, as many of us were. I had a C for Apple ][. Aztec C, I believe. Had a Forth too, but never did much with it. There was PASCAL, which actually worked well too. All of those environments brought higher level capabilities, but they came at a price, and the price generally was making it tough to really push the machine, but the reward was being able to do higher level things more easily too. We saw Appleworks, for example, the first integrated Office type environment. That was awesome! But we also saw things like spiffy games, multi-channel music, and other types of tasks get done, and the approaches were very different.
Ever go and look at "Prince of Persia?" You should, and in fact, here's a link: http://youtu.be/o7NOf-aTCfw
And here is Appleworks: http://www.youtube.com/watch?v=sJdUcbdj7eo
I could go and link some other similar kinds of things, but I won't due to length. Just note when we entered 16 bit computing, things got big enough and fast enough for C and other HLL environments began to make great sense. We are experiencing this very same dynamic with P1 and P2.
Also note, PoP would never, ever have happened without a killer assembler. Merlin was made for the Apple ][, and it does some odd things for an assembler, but it maximized the Apple 2. Appleworks type applications (and I don't recall what Appleworks was authored in at the moment) would not have happened without HLL development maximizing the machine in other ways. The end result being we got one heck of a lot more out of the Apple ][ for both types of environments being present than we would have otherwise, and it's the same story for the P2.
The other basic point I'm making is this, to support why that is:
SPIN (SPIN+PASM) centers on performance, lean programming, assembly, maximizing the capability of the hardware and maximizing the direct accessibility of the hardware. As Chip puts it, "getting right on the clock edge" kinds of things. On the P1, we did video tricks, which are now possible in C, in PASM back then, and it was fairly easy, and definitely lean. I could go and learn SPIN, by inference understand a lot of PASM, and make a video driver do something new in a day or two. Amazing. And that's cold, just jumping in from ordering a Demo Board after seeing a few things online. It would take me the same couple of days to grok all the directives, pragmas and other things needed to instruct C in ways that I can just write in PASM. Again, not one better than the other, just different.
Go and look at BBC Basic and the impact that had on a lot of people. Frankly, it's the same kind of vision SPIN+PASM has today, and it has it's merits. Frankly, I don't think anyone else designing this kind of stuff even thinks that way, and so those of us who recognize those merits are wanting to make sure we see it, because it's quite frankly, brilliant!
We are better off having both of these exist, even if that means some difficulty sharing code, interoperating, whatever. In the mid to longer term, it won't matter at all. We will have many kinds of great happening.
4. Hardware is going to get made. IMHO, some really cool stuff! And again, we are going to see a couple of basic paths taken. Some are going to want to self-host development, or maybe just run lean with SPIN, and that will compete with and balance out those who are going to want to attempt bigger things, different things and do so in C.
One vision Chip has for the P2 is to get interactive. Again, there is a parallel in computing. Remember the Amiga vs the PC? The P2 is Amiga like, in that the hardware centers on a few basic ideas, and it's real time nature and focus on graphics, sound, robust I/O, and now tasks means being able to do a lot of things that would normally be done with an OS, sans that OS. I think this will be very significant. It will be significant in the way the Amiga, which also had a hardware focus on specifics was significant.
Some of us see it differently, and want the packaged up capabilities to make leveraging other code out there, along with code we write, easier and maybe perform better in some ways. I'm in this camp too, thinking I will be able to combine some lower level driver code with C code I see out there and use it in ways very similar to how I used SPIN objects.
To sum up: Doing is this way is going to have some benefits. It's a bit more work, but we get the advantages of both in the end, and I have to tell you, I wouldn't be here if it were not for SPIN+PASM being what it is on P1. Now, having been here, I've wanted to do things in C or sometimes just larger things than I find possible now, and some of us have worked to make that happen. Look at Dr_A over the years, along with others, Heater, SRLM, David and the GCC team, Ross, et al. C works now!
All that tells me is there is plenty of demand for both basic paths, and we need to maximize those and not worry about having the one unified way. The only way we are going to see that magic is to enable Chip to do what he does and when it's done, we've got it. This time, because of all we know and have learned on P1, we can take the best of that, and know we are on a bigger, more capable chip designed with C in mind, and then build up C to the point where it's magic too.
So, it's not about wasting time on C++ and it's not about C being better or worse, or right or wrong. It's about realizing SPIN, and the way that happens is Chip builds it the way he builds it. And we need that to exist. I want it to exist. C and other higher level friends, and even things like other kinds of assemblers, JS, who knows will happen too, and we need those to exist, and I want those to exist.
But SPIN can't exist, unless it's built as is being done right now, so it's gotta be done right now, how it's done as one holistic package. P2 chip, SPIN+PASM, etc...
The moment we can solidify the design enough to start other development efforts, those can and ideally will kick off the same way and everybody is happy, doing things they want to do.
***FWIW, this is precisely why some of us object to "standard assembler", etc... comments being made. SPIN+PASM is one thing really, and that has implications that when ignored make SPIN less of a beautiful and effective thing than it otherwise would be.
Let's maximize it, and the moment we can, let's maximize C and friends too. This should not be a disappointment, but instead a celebration! The P2 is going to kick a lot of Smile on both fronts, and that's nothing but good.
Seriously.
Perhaps a switch setting to use the new P2 instructions or the old P1 ones, or accept both as long as the P1 mnemonics are not used for something else on the P2.
Agreed, but the key is instructions with the same function
ie they need to be identical opcodes. IIRC Chip mentioned something a while ago about JNZ is not quite the same as TJNZ, as one alters the flags, the other does not ? (both jump on non zero)
If the opcodes are exact clones, then this makes sense, and the choices are
a) A simple alias, allowing either
b) A switch option
No surprises there. C was originally intended as a slightly higher level assembly language replacement. The nice thing is that with assembler, C, and Spin we now have three choices of speed vs ease of programming.
I'm are big fan of 68000 CPU programing on Aple and Atari and others.
BUT for simple conversion of 68000 ASM code to P2 needs one instruction that can simulate TRAP instruction in them.
In 68000 it is an Interrupt instruction ---- BUT that said ALL interrupt instructions in 68000 are SHORT hand for CALL X,index.
I postulated for that one but as I know we will not have that one
If you go back and look at things like BBC Basic, the same performance argument was made, despite a BASIC not being all that fast relative to a compiled or even some other byte code environments, like PASCAL.
The performance came from being able to use assembly language where needed, and where the two can be freely mixed, performance becomes easier to realize while keeping all the benefits of a HLL in the first place. What ends up happening is pure assembly gets used to maximize something, and back then as well as today on P1, that might mean getting more colors on the screen, or making sounds, or driving a motor, whatever. Then, there are those things that require moderate performance, and back then it was a mix, and on P1, that ended up being LMM. Finally, there is the supervisor or very higher level code, which doesn't need to go that fast at all.
SPIN performs as fast as most 8 bit assembly language does. Well, 8 bitters running at a few Mhz. Once, I wrote similar things in SPIN and assembly on the Apple and Atari machines I have. Was gonna do the 6809 CoCo, but didn't. Anyway, SPIN compared favorably, and was faster in some instances, not much slower in others.
Now, performance is relative. Relative to what?
That is task dependent. Say you want to do a game, or manage a GUI, or provide some logic that augments some lower level needs, like actually displaying things, motors, etc... SPIN relative to the task of providing user interaction is very fast. Plenty, with room to spare. Heck, SPIN is fast enough to chase the beam on a TV screen too, able to respond to some mid-screen event, get something done, and continue on. Now, when writing more of the program in SPIN, performance becomes an issue, precisely where C picks up the ball to provide more. Great! I would argue the scope of possible tasks on P1 just doesn't get big enough often enough to push people off SPIN, particularly with PASM so easy. On P2, that's not gonna be true, and I suspect a compiled SPIN to PASM may well be better than byte code, and C will shine for sure.
One interesting metric is P2 SPIN as byte code is likely to perform on par with P1 PASM. Seems to me, that's quick. Not best, but when looking at an environment that is optimized along a number of fronts, that trade-off makes sense, particularly given a clean, lean, easy, accessible PASM is right there.
And I have to say, few things have been as easy as SPIN+PASM where using assembly and a HLL are concerned. Nothing ever was as lean as SPIN+PASM is. Brilliant! I really want that for P2, because it's a nice to have and it will shine for those so inclined.
Seems to me, that's good performance, and because SPIN is basically one with PASM, where more is needed, we can simply do that, and that's lean, and it carries through to maximizing the direct access to the hardware too.
I fully expect C to significantly outperform SPIN, unless Chip decides to compile to PASM this time. Then it may be much closer, and I think C will likely have the edge, but less of one. That's all just thumb in the wind, of course. It's too early.
So let's talk about that marriage a little.
Inline assembly can be complicated, or simple, and on P1, we didn't get inline, just COG. But it was pretty simple. On P2, we are definitely going to get inline, and it's likely to be simple like BBC Basic and other kinds of environments are simple. Doing that in C is a bit more involved, and nothing wrong with that. The "more involved" part has to do with higher level concepts, and the capability of the compiler, different environments, things like encapsulation, etc... All good.
But it's not as lean as an environment specifically targeted to the chip is. The cost is portability, and an increased difficulty with interoperability. Some people will pay that, others won't, and that's really the primary reason why I and others want SPIN+PASM to exist. On P1, it was one holistic effort, which made for a very sweet and productive environment. On P2, it is highly likely to be the same way.
I can jump into a SPIN and really I'm talking SPIN+PASM, environment, knock something I want out and really need to know very little, track very little to just make it go. With C, there is more involved. Now, if I want to do some planning and build something bigger, those things in C which get in the way of lean, just write it, run it, go, type efforts, pay off on the larger ones. It's this dynamic I see playing out on P2 because it's big enough to warrant having those things because P2 is big enough for people to attempt big enough things for it all to pay off!
Re: Hand assembly vs compiled.
Yeah. Totally, particularly on this playground of a chip. Frankly, that's the number one argument for making sure we get a SPIN designed in the way we did for P1. We will want those goodies exposed in ways that are lean and accessable just like they were on P1. People can jump in, do amazing things, and move on to whatever else they are wanting to do. Hand PASM will matter on the P2, but not too much, because it's going to perform well on compiled, because we've taken time to help that along.
A lot of people won't care too. And that's the strongest argument for C and friends on the P2.
BTW: If somebody out there makes in-line easier, less verbose, etc... in C, I'll be very happy, and I really don't care what it breaks. "WHAT??" you say? And rightfully so, I would agree with you, which is precisely why SPIN needs to exist, put another simple way. Some of us are selfish, don't care, greedy, whatever, and we just want to write it, see the magic happen and move on, caring very little about anything else. SPIN helps that along, and there is no big harm in having it that way. Just choices. Valid ones, if incompatable. Others of us dislike that kind of thing, and there are other choices. If we can maximize those, we win!
For me personally, I really enjoy assembly language programming, but I don't enjoy making larger assembly language programs. That's what the HLL is for! Secondly, I like middle sized programs to be lean, and so "basic" like HLL's are attractive, because I can get in, do it, get out, and not worry too much. There is a clear niche there shared by many similar minded people who maybe want to see or do something, but not get too deep into the software engineering side of things. That's SPIN.
Others are going to want to get into it on that level, and or do bigger projects. That's very likely C. Maybe C with some PASM magic sprinkled in here and there. All good. Encapsulate it, and you even have a shot at it being portable, though I have no idea to what. Another day.
Anyway, I like to write the program, bump into a performance point, and just write that PASM, and then continue on with as few worries as I can manage. That's often SPIN, though it may well be C for me too. Don't know yet. I do know I want to do some C programming on the P2, and I want to be able to use code I see out there, etc...
Precisely.
Yeah I hear that. Honestly, I think we've got lots of niche instructions now, and the balance is good. Seems to me, there are answers for that case. It just takes a little more.
Amiga, Atari ST, BBC, Acorn, had BASIC HLL environments with super easy in-line assembly language capabilities. Some of those could be compiled too, which rocked pretty hard. Build it interactive, adding inline where needed, and then compile the whole works to make it sing!
Maybe SPIN can work both ways too. Offer byte-code for best case size, compile for best case speed, and inline PASM to drop the 'magic' in where appropriate and necessary. Could be good times man!
After I write this post to You.
I have thinking and re-thinking --- And now I see that it NOT need new CALL instruction in hardware.
BUT one more possibility in PNut how CALL instruction can be invoked
>
As it is now --- It is CALL D
For that simple convert to TRAP type instruction PNut need understand
>
CALL D, #index --- where index 0 to x ---
0 same as CALL D
1 CALL D + next table
table:
JMP X0
JMP X1
JMP X2
........ and so on
1) What languages we want for Propeller development? Well, there will be Spin and C/C++. Both are great and both have their place and their followers. And yes others will come up with BASIC and 20 different versions of Forth etc.
2) The other level is, what languages should these Propeller language tools be developed in?
Ultimately they will be available in C/C++. Propggc of course is anyway. Openspin is C++ and will support P2 at some point.
The only little fly in the ointment just now is that Chip's PNUT is in x86 assembler and only available for Windows. A bit of an annoyance for those of of us who don't run legacy operating systems. A total no-go for users of ARM machines.
All in all the situation is good and will get much better. Life is good.
P.S. Some may think I make contradictory statements about C++. So I do. I love it really. It's just that it is a fractal of infinite complexity that no human can understand any more.