Yes but there aren't any byte access instructions for COG RAM are there? Or do you intend to store one byte per long?
A "byte" variant of ALTB would have neat!
Yes!!!!
That can be done, and rather than just modify S, it could modify the N bits for 'GETBYTE D,S,#N'. This will mean that you can do a SETQ+RDLONG and then index through the bytes! That's important for a bytecode interpreter. Another instruction could write bytes sequentially, as well.
I really don't see this derailing the P2 release schedule. Also, it allows Chip to do some lateral thinking and help get him out of any unrecognized ruts he may have been in by working on the underlying P2 architecture for so long. Which is a good thing for all of us, I believe.
I think the Spin effort is largely to make sure the P2 instruction set will efficiently support HLLs.
I think it is Chip's plan to build a Spin2 virtual machine and a compiler that generates byte codes for that VM. While that will certainly exercise the instruction set, I'm not sure it is a good test of what is needed to implement high level languages many of which will likely compile to native code. However, Eric's fastspin might be a good test.
stevemess2004,
None of the interface/inheritance/structure stuff needs to be used at all. It's just available for advanced uses. You will be able to write Spin code that looks just like Spin1 without any of this stuff.
I don't get the moaning about adding this stuff makes Spin more complex, etc. It doesn't change any of the existing simple stuff, it just adds new ways to do things.
Does the fact that your toolset has 100s of tools stop you from understanding how to use the basic hammer, screwdrivers, and wrenches? No.
One problem with allowing an object to implement more than one interface is that you'll essentially have to typecast an object pointer to the desired interface before using it. If there is only one interface then the pointer to the object can be made to be the same as a pointer to that interface.
I don't get the moaning about adding this stuff makes Spin more complex, etc. It doesn't change any of the existing simple stuff, it just adds new ways to do things.
Roy, the main concern I have about adding more stuff to Spin is that this already exists in C/C++. Why re-invent the wheel? I've never liked the idea of creating a proprietary language when existing languages can do the same job. Another concern I have about Spin2 is that it's postponing the date when the P2 will be available. I really think the time would be better spent on just implementing Spin on the P2 so that it's almost identical to that on the P1. I would much rather see more effort going into implementing PropGCC on the P2.
EDIT: On the other hand, I understand that the P1 and P2 are Chip's thing. If he decides to venture off into developing Spin 2 there isn't much that we can do about it. I only hope that the P2 will become a reality some day.
I don't get the moaning about adding this stuff makes Spin more complex, etc. It doesn't change any of the existing simple stuff, it just adds new ways to do things.
Roy, the main concern I have about adding more stuff to Spin is that this already exists in C/C++. Why re-invent the wheel? I've never liked the idea of creating a proprietary language when existing languages can do the same job. Another concern I have about Spin2 is that it's postponing the date when the P2 will be available. I really think the time would be better spent on just implementing Spin on the P2 so that it's almost identical to that on the P1. I would much rather see more effort going into implementing PropGCC on the P2.
EDIT: On the other hand, I understand that the P1 and P2 are Chip's thing. If he decides to venture off into developing Spin 2 there isn't much that we can do about it. I only hope that the P2 will become a reality some day.
There is still also the possibility of adding syntax to C++ to support Spin-like features. It wouldn't be appropriate to introduce block structure by indenting but it might be pretty easy to make a preprocessor that would accept a mixed C++ and PASM file and extract the PASM for separate assembly. Or even just recast it in the ugly GCC inline assembly syntax.
I don't get the moaning about adding this stuff makes Spin more complex, etc. It doesn't change any of the existing simple stuff, it just adds new ways to do things.
Does the fact that your toolset has 100s of tools stop you from understanding how to use the basic hammer, screwdrivers, and wrenches? No.
There speaks a skillful and experienced software engineer.
Thing is skillful and experienced software people will create code using every possible trick in the book, every feature of Spin 2. That code will end up in OBEX or wherever. Then, our green horn, beginner or casual programmer comes to Spin 2 and takes a look at that code in OBEX. BOOM! he is clubbed to death with complexity.
Imagine an Arduino user, who is usefully getting along with C++ in his Arduino projects, takes a look at the source code of the stl !
I don't mind new features being added. As long as they are pretty obvious to understand without having to spend hours stuck in the manual. As long as they are not redundant complexity, cough, ternary operators.
As long as they do not induce seizures like the gigantic tangle that is now C++.
I think everyone here capable of making a C++ compiler knows how it would work on the Prop2, right? I don't get the feeling that there's much to discuss, even. I think all the Prop2 information needed to do such a project exists in the Google Doc and the Google Sheet which covers the instruction set. If I work on Spin for a while, would this stop anyone else from making C++? Is anyone motivated to embark on that?
Heater,
From what I have read on the forums, beginners just use the thing sin the OBEX to get things done. They rarely look at the source to try and understand it. Those that do will see an example of how the new features work and be able to work things out given the manual. I see nothing wrong with that. Heck, many of the drivers on OBEX contain mostly PASM, beginning Spinners must really suffer having to look at that!
Parallax documents and tutorials will take beginners from the ground up.
Mix in a more conversational, as in run it, change it, watch it, approach intended to be possible, and beginners could be exploring more and more quickly too.
Being able to dynamically generate and run code from a SPIN program should make some very interesting things happen to expand on the conversation idea.
I think everyone here capable of making a C++ compiler knows how it would work on the Prop2, right? I don't get the feeling that there's much to discuss, even. I think all the Prop2 information needed to do such a project exists in the Google Doc and the Google Sheet which covers the instruction set. If I work on Spin for a while, would this stop anyone else from making C++? Is anyone motivated to embark on that?
I don't think it prevents anyone starting C++, or any language.
(I know TF2 is running on P2 image, if not with very latest opcode tuning )
Looking at the Google sheet for instructions, I do not see any comments on HW Stacks available, and their sizes ?
Yes, I know. Almost anything can be twisted into incomprehensibility. As you so clearly demonstrate.
C++ is something else altogether. It is a huge and complex language. It has all manner of features that can take a life time to understand how they might all interact with each other. I don't believe there is a single human alive that can fathom it all.
I realized C++ had gone too far when I saw that Bjarne Stroustrup himself was having trouble understanding how new C++ language standard features misbehaved.
As to your example, well davidsaunders' example, it is certainly not easily readable but it is not actually complex. In order to decipher it only a few simple concepts need be understood, variables, operators, assignment, arrays.
I think everyone here capable of making a C++ compiler knows how it would work on the Prop2, right? I don't get the feeling that there's much to discuss, even. I think all the Prop2 information needed to do such a project exists in the Google Doc and the Google Sheet which covers the instruction set. If I work on Spin for a while, would this stop anyone else from making C++? Is anyone motivated to embark on that?
There are only two or three people that I know of on the forum that are experienced with implementing GCC for a processor. Actually, there is only one that I know of for sure, and maybe two others that could learn to do it. I think the thing that is holding back GCC development is a stable chip design and support from Parallax for such a project. There are several people that could help out by porting library code an testing it like we did for the first PropGCC project.
From my view, any work on Spin at this time is delaying the P2 from going into synthesis. Maybe there is other work going on that I'm not aware of, and the design is preparing to go into synthesis in parallel with other activities.
EDIT: I'm guessing that at this point there is not much motivation from the user community to implement C/C++ for the P2. I think once the P2 goes into synthesis the motivation factor will increase. However, it seems like Parallax should be highly motivated to start the development of C/C++. After all, C/C++ will likely become the main language uses for programming the P2. I say this, because I think the P2 will attract a lot of new customers, but only if it has C/C++ support. It is doubtful that new users will be attracted to a processor that only has proprietary language support.
For educational use Spin is a dead-end; there are no jobs advertised for Spin programmers.
That's a total red herring. Learning any programming language for the first time imparts an ability to think algorithmically. It's not about preparing for a particular job; it's about learning to analyze problems and come up with solutions. In my experience teaching robotics with both C and Spin, I found that students were able to concentrate more on the problem at hand, and less on syntax issues, when programming in Spin. As a consequence, learning proceeded at a faster rate.
IOW, it's not about the language. It's about the approach to problem-solving. And once you're adept at one programming language, those skills translate to others quite readily.
I think everyone here capable of making a C++ compiler knows how it would work on the Prop2, right? I don't get the feeling that there's much to discuss, even. I think all the Prop2 information needed to do such a project exists in the Google Doc and the Google Sheet which covers the instruction set. If I work on Spin for a while, would this stop anyone else from making C++? Is anyone motivated to embark on that?
I don't think it prevents anyone starting C++, or any language.
(I know TF2 is running on P2 image, if not with very latest opcode tuning )
Looking at the Google sheet for instructions, I do not see any comments on HW Stacks available, and their sizes ?
Ah, sorry. There is an 8-level 22-bit hardware stack in each cog. It's used by the CALL/RET/PUSH/POP instructions.
While there may be no formal requests for SPIN programming, there are tons of problems to solve and people willing to pay for solutions.
A person who learns about this field could end up doing a lot even before moving out and into the broader programming and technology aspects of it.
That's true. Spin is not that out of the ordinary that skills learned using it wouldn't be applicable with other languages. However, unfortunate though it is, potential employers often want experience using a specific tool and they may be looking for C, C++, Python, JavaScript, etc. They are not likely to be looking for Spin.
There is one in each COG, they are small, 20 bit stacks intended for subroutine call return. I forget the depth. It's not much, 8 levels.
Stacks in HUB or elsewhere can be done in software.
I think the details are as follows:
Hardware stack is:
* 22-bits wide (PC,C,Z)
* 8 levels deep
* No indication full or empty
Hub stack:
* Uses PTRA/PTRB
* Can be used for both calls/returns and data
* Relatively slow for multiple back-to-back stack operations
* If the stack contains calls/returns, only grows upwards in memory
* If the stack contains only data, can grow either upward or downward in memory.
Actually, that last bit for the Hub stack points towards a minor optimization. If CALLA and PUSHA performed a PTRA-- instead, then back-to-back calls will be faster (a couple clock cycles per call).
I don't think it prevents anyone starting C++, or any language.
(I know TF2 is running on P2 image, if not with very latest opcode tuning )
Looking at the Google sheet for instructions, I do not see any comments on HW Stacks available, and their sizes ?
Ah, sorry. There is an 8-level 22-bit hardware stack in each cog. It's used by the CALL/RET/PUSH/POP instructions.
OK, so a Compiler writer is gong to have to choose early on, what stack approach to use.
8 levels (especially with interrupts in the mix) is not easy to manage in a HLL.
What happens on stack overflow/underflow ?
I see there is also a choice for CALLPA, CALLPB, but here, a compiler writer will need to choose one or the other, and that reduces P2 to a single index register ?
In theory, source pragmas could be used to use COG stacks in very special cases, giving back use of 2 index registers, but now the tools have to manage the risks of mixing modes.
Source cannot be allowed to call a library 'compiled the other way'.
However, unfortunate though it is, potential employers often want experience using a specific tool and they may be looking for C, C++, Python, JavaScript, etc. They are not likely to be looking for Spin.
While that may be true, it's very unlikely that students learning C -- or any other language -- at the secondary level will spend enough time with it to acquire market-ready skills. Those skills are almost always honed post-graduation. The important thing at the secondary level is to inculcate a systematic approach to design and problem-solving. Learning Spin can do that at least as well as learning some other language.
However, unfortunate though it is, potential employers often want experience using a specific tool and they may be looking for C, C++, Python, JavaScript, etc. They are not likely to be looking for Spin.
While that may be true, it's very unlikely that students learning C -- or any other language -- at the secondary level will spend enough time with it to acquire market-ready skills. Those skills are almost always honed post-graduation. The important thing at the secondary level is to inculcate a systematic approach to design and problem-solving. Learning Spin can do that at least as well as learning some other language.
-Phil
Good point. My learning 6800 assembler, LISP, and BASIC and various other obscure languages didn't hurt my chances of getting a C programming job but did help me understand computers better.
I think everyone here capable of making a C++ compiler knows how it would work on the Prop2, right? I don't get the feeling that there's much to discuss, even. I think all the Prop2 information needed to do such a project exists in the Google Doc and the Google Sheet which covers the instruction set. If I work on Spin for a while, would this stop anyone else from making C++? Is anyone motivated to embark on that?
There are only two or three people that I know of on the forum that are experienced with implementing GCC for a processor. Actually, there is only one that I know of for sure, and maybe two others that could learn to do it. I think the thing that is holding back GCC development is a stable chip design and support from Parallax for such a project. There are several people that could help out by porting library code an testing it like we did for the first PropGCC project.
Dave,
I keep seeing this perception that the chip design isn't stable, and feel a compulsion to point out its more stable now than ever before
Regarding support for GCC, do you mean financial support? or encouragement? See comments by Ken here
From my view, any work on Spin at this time is delaying the P2 from going into synthesis. Maybe there is other work going on that I'm not aware of, and the design is preparing to go into synthesis in parallel with other activities.
I suspect the software and documentation necessary for a release will take longer to get together than making the chips. If thats the case, synthesizing the chips right now isn't the most critical thing, much as I hate to admit it
It's possible to write illegible code in pretty much any language if you try hard enough, or simply don't take care to write legible code.
Don't look at a poorly constructed building and blame the hammer.
And you use a beutifully constructed line of Spin to demonstrate? I think I know the original author of that, and I see a line of code that is as easy to read as an equation on a chalk board (pretty easy in other words).
Though I guess everyone has there style. Though you left out one character somehow. The original is:
Did not think that a copy paste could omit an '=' character, oh well, though I would have expected you to notice it at a glance for the incorrect operation.
From my view, any work on Spin at this time is delaying the P2 from going into synthesis. Maybe there is other work going on that I'm not aware of, and the design is preparing to go into synthesis in parallel with other activities.
The 'other work that is going on' is proving the latest FPGA build image.
The final decision to pass P2 verilog into physical layout steps, is going to need careful focus on how much testing coverage has been done.
The latest 'release candidate' FPGA image is as yet only very few days old, Feb 25th I think.
Surely you do not expect Chip to take a Verilog compile, as 100% test coverage, & ship ?
I didn't mean to pick on you specifically - I find that code incredibly dense and hard to parse, and I also have difficulty with mathematical notation, so perhaps those are related.
Comments
But you then ignored the sentence immediately after the one you quoted. This effort already resulting in the addition of important instructions:
I really don't see this derailing the P2 release schedule. Also, it allows Chip to do some lateral thinking and help get him out of any unrecognized ruts he may have been in by working on the underlying P2 architecture for so long. Which is a good thing for all of us, I believe.
None of the interface/inheritance/structure stuff needs to be used at all. It's just available for advanced uses. You will be able to write Spin code that looks just like Spin1 without any of this stuff.
I don't get the moaning about adding this stuff makes Spin more complex, etc. It doesn't change any of the existing simple stuff, it just adds new ways to do things.
Does the fact that your toolset has 100s of tools stop you from understanding how to use the basic hammer, screwdrivers, and wrenches? No.
EDIT: On the other hand, I understand that the P1 and P2 are Chip's thing. If he decides to venture off into developing Spin 2 there isn't much that we can do about it. I only hope that the P2 will become a reality some day.
Thing is skillful and experienced software people will create code using every possible trick in the book, every feature of Spin 2. That code will end up in OBEX or wherever. Then, our green horn, beginner or casual programmer comes to Spin 2 and takes a look at that code in OBEX. BOOM! he is clubbed to death with complexity.
Imagine an Arduino user, who is usefully getting along with C++ in his Arduino projects, takes a look at the source code of the stl !
I don't mind new features being added. As long as they are pretty obvious to understand without having to spend hours stuck in the manual. As long as they are not redundant complexity, cough, ternary operators.
As long as they do not induce seizures like the gigantic tangle that is now C++.
Right, because Spin is so much cleaner:
It's possible to write illegible code in pretty much any language if you try hard enough, or simply don't take care to write legible code.
Don't look at a poorly constructed building and blame the hammer.
From what I have read on the forums, beginners just use the thing sin the OBEX to get things done. They rarely look at the source to try and understand it. Those that do will see an example of how the new features work and be able to work things out given the manual. I see nothing wrong with that. Heck, many of the drivers on OBEX contain mostly PASM, beginning Spinners must really suffer having to look at that!
Parallax documents and tutorials will take beginners from the ground up.
Being able to dynamically generate and run code from a SPIN program should make some very interesting things happen to expand on the conversation idea.
(I know TF2 is running on P2 image, if not with very latest opcode tuning )
Looking at the Google sheet for instructions, I do not see any comments on HW Stacks available, and their sizes ?
Stacks in HUB or elsewhere can be done in software.
Yes, I know. Almost anything can be twisted into incomprehensibility. As you so clearly demonstrate.
C++ is something else altogether. It is a huge and complex language. It has all manner of features that can take a life time to understand how they might all interact with each other. I don't believe there is a single human alive that can fathom it all.
I realized C++ had gone too far when I saw that Bjarne Stroustrup himself was having trouble understanding how new C++ language standard features misbehaved.
As to your example, well davidsaunders' example, it is certainly not easily readable but it is not actually complex. In order to decipher it only a few simple concepts need be understood, variables, operators, assignment, arrays.
From my view, any work on Spin at this time is delaying the P2 from going into synthesis. Maybe there is other work going on that I'm not aware of, and the design is preparing to go into synthesis in parallel with other activities.
EDIT: I'm guessing that at this point there is not much motivation from the user community to implement C/C++ for the P2. I think once the P2 goes into synthesis the motivation factor will increase. However, it seems like Parallax should be highly motivated to start the development of C/C++. After all, C/C++ will likely become the main language uses for programming the P2. I say this, because I think the P2 will attract a lot of new customers, but only if it has C/C++ support. It is doubtful that new users will be attracted to a processor that only has proprietary language support.
IOW, it's not about the language. It's about the approach to problem-solving. And once you're adept at one programming language, those skills translate to others quite readily.
-Phil
Ah, sorry. There is an 8-level 22-bit hardware stack in each cog. It's used by the CALL/RET/PUSH/POP instructions.
A person who learns about this field could end up doing a lot even before moving out and into the broader programming and technology aspects of it.
I think the details are as follows:
Hardware stack is:
* 22-bits wide (PC,C,Z)
* 8 levels deep
* No indication full or empty
Hub stack:
* Uses PTRA/PTRB
* Can be used for both calls/returns and data
* Relatively slow for multiple back-to-back stack operations
* If the stack contains calls/returns, only grows upwards in memory
* If the stack contains only data, can grow either upward or downward in memory.
Actually, that last bit for the Hub stack points towards a minor optimization. If CALLA and PUSHA performed a PTRA-- instead, then back-to-back calls will be faster (a couple clock cycles per call).
OK, so a Compiler writer is gong to have to choose early on, what stack approach to use.
8 levels (especially with interrupts in the mix) is not easy to manage in a HLL.
What happens on stack overflow/underflow ?
I see there is also a choice for CALLPA, CALLPB, but here, a compiler writer will need to choose one or the other, and that reduces P2 to a single index register ?
In theory, source pragmas could be used to use COG stacks in very special cases, giving back use of 2 index registers, but now the tools have to manage the risks of mixing modes.
Source cannot be allowed to call a library 'compiled the other way'.
-Phil
Dave,
I keep seeing this perception that the chip design isn't stable, and feel a compulsion to point out its more stable now than ever before
Regarding support for GCC, do you mean financial support? or encouragement? See comments by Ken here
I suspect the software and documentation necessary for a release will take longer to get together than making the chips. If thats the case, synthesizing the chips right now isn't the most critical thing, much as I hate to admit it
Is that in reference to stack support?
Though I guess everyone has there style. Though you left out one character somehow. The original is: Did not think that a copy paste could omit an '=' character, oh well, though I would have expected you to notice it at a glance for the incorrect operation.
The final decision to pass P2 verilog into physical layout steps, is going to need careful focus on how much testing coverage has been done.
The latest 'release candidate' FPGA image is as yet only very few days old, Feb 25th I think.
Surely you do not expect Chip to take a Verilog compile, as 100% test coverage, & ship ?