It has been said that if you want to get an idea accepted sometimes all you have to do is give it a different name and re-present it. So here goes...
I'm now thinking PASM is the wrong name for this proposed new Spin section. It's wrong because one can still put PASM code into DAT sections. And the PII will have hub execute and in-line PASM which are different things.
BLOB is also a wrong name. We are writing source code here, it's not a binary blob until it's compiled. The "file" statements deal with blobs in Spin.
I would now suggest the "COG" section.
I was thinking how the COG section actually fits in very neatly with current Spin sections and indeed fills a hole. Consider:
Like most high level languages Spin has different "classes" of data depending on what the data is and/or where it lives (Not C++ type classes). Currently we have:
1) Constants in CON. These definitions have no fixed place in memory but get sprinkled wherever they are used in the compiled code.
2) Instance variables in VAR. These are in a HUB area and duplicated for each instance of an object.
3) Shared variables in DAT. These are shared among all instances of the same object.
4) Public methods in PUB. OK this is code, but code is data right. Only accessible in the object or from it's "owner".
5) Private methods in PRI. As above but only visible to the object itself.
6) Local parameters and variables, only visible within the method.
All these definitions tell what the data is used for, where it might live in the compiled binary and importantly they apply rules as to how they are used by the programmer. Thus we have an orderly high level language.
What's missing?
Oddly one of the most important memory areas of the Propeller is not represented here at all. The COG memory. How did that happen?
The proposed new "COG" section would rectify this omission. It makes clear to the programmer and the reader what that PASM code is for and where it ends up. With the addition of the few simple rules given earlier it offers the community minded programmer the ability to correctly create language neutral PASM code.
When I said "enable" I did not been "force". Except in the sense that we "enable" children to grow up and live in this modern world by "forcing" them to go to school
Perhaps I'm softening my line, DAT would still be there as normal for PASM coders who don't care about sharing.
It has been said that if you want to get an idea accepted sometimes all you have to do is give it a different name and re-present it. So here goes...
I'm now thinking PASM is the wrong name for this proposed new Spin section. It's wrong because one can still put PASM code into DAT sections. And the PII will have hub execute and in-line PASM which are different things.
BLOB is also a wrong name. We are writing source code here, it's not a binary blob until it's compiled. The "file" statements deal with blobs in Spin.
I would now suggest the "COG" section.
I was thinking how the COG section actually fits in very neatly with current Spin sections and indeed fills a hole. Consider:
Like most high level languages Spin has different "classes" of data depending on what the data is and/or where it lives (Not C++ type classes). Currently we have:
1) Constants in CON. These definitions have no fixed place in memory but get sprinkled wherever they are used in the compiled code.
2) Instance variables in VAR. These are in a HUB area and duplicated for each instance of an object.
3) Shared variables in DAT. These are shared among all instances of the same object.
4) Public methods in PUB. OK this is code, but code is data right. Only accessible in the object or from it's "owner".
5) Private methods in PRI. As above but only visible to the object itself.
6) Local parameters and variables, only visible within the method.
All these definitions tell what the data is used for, where it might live in the compiled binary and importantly they apply rules as to how they are used by the programmer. Thus we have an orderly high level language.
What's missing?
Oddly one of the most important memory areas of the Propeller is not represented here at all. The COG memory. How did that happen?
The proposed new "COG" section would rectify this omission. It makes clear to the programmer and the reader what that PASM code is for and where it ends up. With the addition of the few simple rules given earlier it offers the community minded programmer the ability to correctly create language neutral PASM code.
When I said "enable" I did not been "force". Except in the sense that we "enable" children to grow up and live in this modern world by "forcing" them to go to school
Perhaps I'm softening my line, DAT would still be there as normal for PASM coders who don't care about sharing.
So if I'm writing programs that are purely in P2 assembly language and run in HUBEXEC mode in HUBRAM, all their instruction mnemonics and data definitions go into the COG section?
So if I'm writing programs that are purely in P2 assembly language and run in HUBEXEC mode in HUBRAM, all their instruction mnemonics and data definitions go into the COG section?
No, quite the opposite.
The "COG" section announces that the following PASM code and data will end up in COG memory at run time. It also applies a few simple rules about how symbolic linkage between what is in COG and outside COG is not allowed. Thus enforcing the requirements of creation of reusable "blobs" of code that can be used in other languages.
Kind of like how VAR announces that data defined there lives in a unique area per object instance. DAT announces that data defined there is shared among instances. Neither VAR or DAT allow different objects any access. Like how PUB and PRI enforce rules of usage.
I haven't really thought about hubexec or inline PASM. Those are yet another different "classes" of code/data. I have no idea what Chip has in mind for the syntax and semantics of handling those in Spin 2.
But as to your question. If your program is entirely PASM you will no doubt have areas of that PASM which are loaded into and run in COGS. Various drivers and such. Again having "COG" sections to delineate those parts of the code would be useful would it not?
I actually like the idea of a COG section. It's a good trigger and describes what the intent of its content is. I just didn't want HUBEXEC PASM to be forgotten. Just being cantankerous!
Can in line PASM be as simple as adding Pasm and Spin keywords to Spin? You always start in Spin mode so nothing existing breaks and if you want to create inline PASM, you just execute the Pasm keyword (maybe no more than an OpenSpin directive) and then write PASM code with all the Spiiny label and data reference support that exists now. Easy and transparent for the user. Just use the Spin keyword to go back to using Spin.
I don't think we need the a "spin" key word, Spin code is introduced by PUB and PRI already. Spin has block indentation to signify "if", "repeat" etc. So why not just use block indentation to delineate in-line PASM code?
Here is a example of what I mean:
PUB start
repeat
doSomething
PRI doSomething | p, q
a : = b + c
x : doSomethingElse (a)
pasm
MOV p, x
ADD q, a
DADA ...
DADA ...
return p + q
I don't think we need the a "spin" key word, Spin code is introduced by PUB and PRI already. Spin has block indentation to signify "if", "repeat" etc. So why not just use block indentation to delineate in-line PASM code?
Here is a example of what I mean:
PUB start
repeat
doSomething
PRI doSomething | p, q
a : = b + c
x : doSomethingElse (a)
pasm
MOV p, x
ADD q, a
DADA ...
DADA ...
return p + q
Perhaps I'm softening my line, DAT would still be there as normal for PASM coders who don't care about sharing.
Indeed you have. Thanks. That's is our only point of disagreement. Creating a section, and COG is a fine name for it, where we've set things up for reuse is an idea I'm in favor of, and early on, I mentioned we can and should be doing things to help people get reuse done too. Roy suggests tools, which are good, and this section with the rules setup to maximize reuse is another tool. A good one. Arguably a much needed one.
Right now, one of my simple PASM programs uses DAT in the non-reuse way to quickly and easily fire off COGS. It's a specific purpose, unless we think we need a general purpose fractal bitmap graphics generator BLOB. There is no need to keep a COG running in that scenario, plus I was lazy, plus I wanted to fire off a lot of COG start statements for testing, which found a bug. Kind of worked out on a number of fronts.
Now, we've got features where we can jump into a COG, without reloading it's RAM, and we can do so at any address! This COG section might help a lot with managing that, just by way of another reason to use it.
I'm thinking of breaking the screen into regions and firing off COGS to get it done, and as each finishes, it gets launched with another region. Loading them all will take about a third of the screen refresh time, which is a significant amount of time.
Refactoring to the rules of the COG section will enable lots of things. The beauty of it done this way is say somebody knows the general concept, but hasn't really done reuse. They will stumble through the COG section, until it just works, learning and doing, just like they did in DAT to get good enough to actually think about reuse!
This is an example of how people will get there at times, even if the intent isn't reuse to begin with, and mine was not, just hacking around. This stuff is fun, when we let it be.
Now, why wasn't it written that way anyway? Time. That's my primary argument against making the reuse rules universal. There was writing better planned code, and then there was seeing the fast math on the P2 render a fractal... And there was work to pay for me to actually have the time to do either! So there you go, sometimes life sucks. (for me, it's better now, new gig and all that)
We agree otherwise Heater. Name it COG, BLOB, whatever, and it's fine. People will use it, and we will get more reuse from it and that is good.
We might get a whole lot more given some starter material to help it all along too.
Making things harder may well see a higher reuse percentage, but perhaps a lower overall code shared percentage. My view on this is we want the code. Any of us can refactor it when it exists. When it doesn't exist... ???
In a more general sense, DAT needs to operate as it does, due to all these models of execution. Who knows where the optimal paths and tricks are? I think we want to see that happen and rules now may well make those more difficult, or prevent the discovery of something we might all seriously appreciate as much as we did Bill thinking hard to come up with LMM.
So why not just use block indentation to delineate in-line PASM code?
Here is a example of what I mean:
That's precisely what Chip did in an early revision of SPIN 2. That's what I hope we end up with, because then people who want to learn some PASM can do so in what is likely the easiest, lean and most potent way possible. Or, those who just need some can write it while tracking as little additional info as possible, leaving SPIN to manage what are otherwise painful and tedious details, both of which are why most people avoid assembly language in the first place.
Again, I'll cite the BBC Basic as a fine example, only it did not have as clean of syntax. Didn't matter though, the net result was the same. The second easiest way is to have assembly language setup to be easily called from the HLL, and that's what Chip did on P1, due to the COG model and lack of LMM innovation at that time. He hit the sweetest spot possible. Now that we've gone past some of those limits, he can just go for the gold and get it perfect.
Beyond that, we've got the more traditional model where assembly language is really separate and it starts to get thick in the HLL due to directives, etc... needed to get things done in a more robust context. In terms of just getting some assembly done, this is the most difficult.
Really, this is all about getting at the magic in the leanest way possible. That goal is orthogonal to reuse. And that goal being realized in the way it was on P1 is a reason why a lot of us are here. It is for me. And the "magic", being what the hardware really does in assembly language, is what people really want a lot of the time too, arguments for both reuse and accessability.
Once somebody has gotten at the magic a few times, reuse ends up on the table more often than not, and we will have provided for that case nicely with this new section.
...unless we think we need a general purpose fractal bitmap graphics generator BLOB.
Who wouldn't want one? If only as demo to throw into a C program. Especially if you can make it run in parallel.
...have assembly language setup to be easily called from the HLL, and that's what Chip did on P1
I would not refer to what the P1 does with PASM as "call". That rather confuses things because it's not a familiar function call and return as we know from most high level languages. Rather it's starting up a whole new process on a different processor.
Having PASM callable from Spin is one way to go. Problems come with passing parameters to it and getting return values back. These calling conventions can be hard enough to work out in a language like C where parameters and returns can be somewhere on the stack, but where and in what order? etc.
Simple inline PASM bypasses those problems. We should have both styles available though.
Agreed on "call", and I was really drawing comparisons to things that have come before. Though it is on a different processor, the dynamics of it where getting to it and learning about it are similar, which is what made P1 so spiffy in the first place. Was not my intent to water what happens down like that.
Re: General purpose fractal COG.
Well, that's how it starts. I'll end up doing that reuse capable one for the multi-cog capable version. It will be much simpler, and a good chance to try out the start COG, no reload option too.
I don't think our video drivers are all that reusable right now either. Lots of constants, and no driver math to run-time calculate things. We will fix that.
That's due to Chip publishing simple, "make it work" code, and the FPGA image changing enough to warrant not going there at present, also due to NANO users mixing it all together with tasks, etc...
Perhaps this image is largely "done" regarding instructions, etc... Hope so. I was just last night twiddling with things in video land, seriously wanting to make it all parametric. Reuse friendly, in other words.
Have a drop-dead date for the next shuttle run?
Have a "feature freeze" date?
While I like this PASM update, it really seems as though it should wait until USB/SerDes are done deals on Chips part.
The more stuff added to 'the list', the less time there will be for testing.
It'd be a shame if a shuttle run were missed, or comes back negative because of some last minute add/s that cut testing time too short.
Actually, it shouldn't. We've already got some bugs and odd behavior ferreted out. Chip can be doing those things in parallel with all of us exercising the instructions, both of which need to happen.
Ken put up a schedule. So far, we are on track for that.
Earlier in this thread, Heater raised the idea of having a separate COG block added to SPIN, which has additional restrictions over the current DAT block when used to hold PASM code. Basically, I think this is a good idea, although I wouldn't perhaps go quite as far as he suggests on adding restrictions to what can be done within such a block - I think these are better implemented as conventions rather than restrictions. But I could be convinced.
The main point of any such change is that current DAT block is now routinely used to contain not only data and PASM code to be executed within a cog, but it is now being used more and more for PASM code to be executed from hub - but it is not particularly well suited to the latter.
My proposal is to extend Heater's original notion slightly, and to add both a COG and a HUB block to SPIN.
The existing DAT block remains essentially unchanged (except as specified below), and can contain PASM code as now, primarily for backward compatibility and also ongoing use from SPIN. But COG is intended to be better suited for code executed from cog by other languages, and HUB is intended to be better suited for code executed from hub by other languages.
The current CON block will remain essentially unchanged (except as noted below), since they are useful from any language. The current VAR, PRI and PUB blocks also remain unchanged, but these are generally unusable from any languages other than SPIN, so the inclusion of any of these block types will indicate to the compiler that the result is to be treated as a SPIN program.
I'd also like to propose a new LOC directive, similar in some ways to ORG, but which can be used in both COG and HUB blocks to specify an absolute hub starting address for whatever entries follow. I think that with these additions, this modified SPIN can not only be used for all current SPIN programs, but it can also be used as a common assembler to support any other languages, eliminating the need for separate assemblers for each.
Here is a quick summary:
COG blocks
Can include PASM and data elements (like DAT blocks)
Symbols represent cog offsets from ORG 0 (as in DAT blocks).
The @symbol notation returns the absolute HUB address of symbol, even at compile time (this is different to the usage in DAT blocks, where this is true only at run-time).
ORG sets a cog offset (as in DAT blocks) but in addition, LOC can be used to specify an absolute hub address for the following elements. If no LOC is specified the block address will be determined by the compiler.
PASM code or data entries in COG blocks cannot refer to symbols defined in DAT or VAR blocks.
HUB blocks
Can include PASM and data elements (like DAT blocks)
Symbols represent absolute BYTE addresses.
ORG is not supported, but LOC can be used to specify an absolute hub address for the following elements. If no LOC is specified the block address will be determined by the compiler.
The @symbol notation returns hub address of the symbol, even at compile time this is different to the usage in DAT blocks, where this is true only at run-time). Note that for HUB symbols, @symbol == symbol
PASM code or data entries in HUB blocks cannot refer to symbols defined in DAT or VAR blocks.
LOC directive
The LOC directive determines the absolute hub address of the following element in either a COG or HUB block.
All LOC directives are respected, with any resulting space within blocks being zero-filled, but not between blocks.
Any COG or HUB block overlaps that result from LOC directives will result in an error.
Blocks without LOC directives are free to be arranged by the compiler.
If LOC directives leaves space between HUB or COG blocks, the compiler is free to use that space for other blocks.
CON and DAT blocks
No change to existing functionality.
DAT blocks can contain references to symbols in HUB or COG blocks, and @symbol always returns the the absolute hub address of such symbols (not the offset within the object, as is true for symbols in other blocks).
PUB, PRI and VAR blocks
No change to existing functionality.
COGNEW and COGINIT extended to allow use on COG blocks, but not HUB Blocks.
P1/P2 Compilation
Where possible (i.e. in the absence of specific LOC directives to the contrary HUB blocks will be placed before other existing block types (DAT, PUB, PRI, VAR etc) and COG blocks will be placed after.
Programs that contain only CON, COG, HUB and DAT blocks are compilable stand-alone into a .blob output, which has no header or object information added.
On the P1, specifying .eeprom or .binary for compilations containing COG or HUB blocks will cause and error unless there is also at least on SPIN method, in which case the usual header and object information will be added.
On the P2, it may be acceptable to specify .binary or .eeprom as the output format even without any PUB or PRI blocks - the resulting binary will have header information added, and could represent a program whose first 512 longs are loaded into cog 0.
I can see the value of COG sections for language independent PASM.
But I do not see any reason to cripple spin to archive that goal.
As is now we have already the problem that the spin stack is not in Hub anymore. A lot of OBEX objects use Parameter and local vars of SPIN methods as mailbox from spin to pasm and back. Will not work anymore.
Where to put it?
PASM code or data entries in COG blocks cannot refer to symbols defined in DAT or VAR blocks...
PASM code or data entries in HUB blocks cannot refer to symbols defined in DAT or VAR blocks...
So PASM is not allowed to see any Data defined in spin? really?
We can do that better - just do not allow SPIN to have any access to pasm either. brilliant.
HUB ram is still a rare resource. A lot of OBEX objects reuse the space occupied by PASM as buffer after starting the cog. Verboten? (not allowed?)
Yes. I am fine with a COG section. If somebody WANTS to build a language independent COG. But if NOT?
IMHO this is going to far.
The beauty of SPIN/PASM is the way they can interact together. Do not destroy that for the reason of reusing code from other languages.
The same is with GCC/GAS. Them are build to work together. And the PropGCC team is doing a great job there. Does it really make sense to create a BLOB in SPIN/PASM to use it with GCC? Why?
Would not some converter program converting PASM to GAS syntax and vice versa do that job also?
... But I do not see any reason to cripple spin to archive that goal ...
Both SPIN and its existing use of PASM remains unchanged under this proposal. The point is that this proposal allows PASM to also becomes usble as the foundation for other (non-SPIN) languages as well. It "loosens" the tight coupling of PASM from SPIN without actually breaking the linkage - on which SPIN currently depends, and which people rightly point out is one of SPIN's strenghts,
An alternative would be to adopt GAS as the SPIN assembler. I'd be okay with that as a proposal - but you will still need to make most of the other changes I'm proposing, so I don't really see how this helps.
Thanks for thinking about this and coming up with a starting point.
I am personally unable to really comment on the specific details because I don't understand the intricacies of compilers, assemblers, and linkers.
Just saying I appreciate the thought put into this.
As for the needs for access to data in certain places:
I've seen the word EXTERN put on labels, so as to make them exportable. I think this builds a specific link to a specific address, in some directly visible way that the linker uses when it ties everything together.
A language I'm most familiar with uses a VAR_GLOBAL / END_VAR block section to say that these variables inside are to be made accessible from the outside.
Your HUB blocks should be usable from SPIN also. You are decupling too much.
They are usable indirectly. I think you are misunderstanding the intent here. SPIN has no direct HUBEXEC capability (unless this is being added to SPIN2???) so the only reason to allow SPIN to access the HUB blocks would be to read or modify the data in them. But this is precisely the kind of usage that makes code in existing DAT blocks so difficult to re-use from other languages. Also, these new HUB blocks intentionally use a different symbol/address scheme to the existing DAT blocks (one more suited to HUBEXEC, which is the main point of them) so you would just be adding more complexity to the SPIN language for little or no benefit.
However, SPIN can sensibly access COG blocks within from PUB or PRI blocks (i.e. to start a cog!), and those cogs can then use HUBEXEC to access HUB blocks - so the effect of the limitation I have proposed is just to ensure that the method of using these new blocks is consistent across all languages - i.e. essentially limited to a COGNEW or COGINIT, plus parameter passing. I don't want to impose such limits on existing PASM in DAT blocks, but I think it is reasonable for the new blocks, which are not intended to be used directly from SPIN.
So new SPIN programs suffer very little from these limitations, and existing SPIN programs not at all. But they make language independent programming easier.
I was assuming SPIN2 would be based on Open Spin. Is that not the case?
Ross.
Ross, I don't know yet. The first Spin2 will probably work from PNut.exe, and then I'll make it work on the chip, itself. Roy would probably build it into a PC-based, tool, though, which, I assume, would be Open Spin.
I'll just say it this way: If SPIN is broken on a basic level, it will be fixed. DAT, SPIN, PASM, VAR, etc... all need to interact how they do now, and to the logical, unified conclusion possible given how the P2 operates.
Above that, if people think adding some sections specifically to target reuse makes sense, then great! Just don't break the core.
We won't even understand all the optimal ways to use the memory and programming models optimally for some time yet and declaring them all this early very likely means bad tools, and or limits we deal with that don't always make the best sense.
Count me out on all of that.
Much better to get SPIN+PASM done in the style we are familiar with, get the OpenSpin port, and then we can explore options from there, and more importantly, various options may well compete to see what makes the most sense too.
Count me IN on tools to help when reuse is the intent, not the mandated norm.
We didn't go through all this to make a killer PASM chip only to ship it with a hobbled programming environment. SPIN is awesome. Let's preserve the awesome and add things we know can help people reach reuse goals without breaking the awesome.
Reuse is a worthy goal, but it's not always the primary goal, and the core tools should reflect that accordingly.
I'll just say it this way: If SPIN is broken on a basic level, it will be fixed. DAT, SPIN, PASM, VAR, etc... all need to interact how they do now, and to the logical, unified conclusion possible given how the P2 operates.
Above that, if people think adding some sections specifically to target reuse makes sense, then great! Just don't break the core.
That's precisely my suggested approach. I added a note to my original post to make it clearer that the existing functionality of all existing block types (CON, DAT, PUB, PRI) remains the same - just slightly extended in some cases.
Indeed. Thanks to you and Heater for that. Much appreciated.
I get the need to reuse and I agree and support doing it.
Really, the core thing here is to get the SPIN Chip will have made. Having that is important. And we kind of get that now, or we don't. Once the P2 is out, I suspect Chip will go off onto the next thing and probably should!
The reason for getting that core SPIN Chip will end up making is to also get the core on-chip package. This is important to some people, and having it lean, mean, kind of "wild" is where the fun and power will be. Ideally, one can use this with a keyboard, mouse, or terminal and just go, and it can build itself most likely. No dependencies.
A whole lot of people won't care so much about having that that, however they may well and more likely care about reuse, and open tools for their OSes of choice. I myself want to run more Mac OS, maybe Linux in the future, as well as do some on-chip work.
And toward that end, we can and should all build on that core, add to it, hack on it, make tools for it, etc... and it's gonna be great. All of that can happen over whatever time period it happens too. There will be dependencies, but those are desirable in this context, which is why over complicating what is the core SPIN seems like a best fit for OpenSpin.
I'll be more quiet now about it for a while. Maybe a long while, who knows?
Comments
I'm now thinking PASM is the wrong name for this proposed new Spin section. It's wrong because one can still put PASM code into DAT sections. And the PII will have hub execute and in-line PASM which are different things.
BLOB is also a wrong name. We are writing source code here, it's not a binary blob until it's compiled. The "file" statements deal with blobs in Spin.
I would now suggest the "COG" section.
I was thinking how the COG section actually fits in very neatly with current Spin sections and indeed fills a hole. Consider:
Like most high level languages Spin has different "classes" of data depending on what the data is and/or where it lives (Not C++ type classes). Currently we have:
1) Constants in CON. These definitions have no fixed place in memory but get sprinkled wherever they are used in the compiled code.
2) Instance variables in VAR. These are in a HUB area and duplicated for each instance of an object.
3) Shared variables in DAT. These are shared among all instances of the same object.
4) Public methods in PUB. OK this is code, but code is data right. Only accessible in the object or from it's "owner".
5) Private methods in PRI. As above but only visible to the object itself.
6) Local parameters and variables, only visible within the method.
All these definitions tell what the data is used for, where it might live in the compiled binary and importantly they apply rules as to how they are used by the programmer. Thus we have an orderly high level language.
What's missing?
Oddly one of the most important memory areas of the Propeller is not represented here at all. The COG memory. How did that happen?
The proposed new "COG" section would rectify this omission. It makes clear to the programmer and the reader what that PASM code is for and where it ends up. With the addition of the few simple rules given earlier it offers the community minded programmer the ability to correctly create language neutral PASM code.
When I said "enable" I did not been "force". Except in the sense that we "enable" children to grow up and live in this modern world by "forcing" them to go to school
Perhaps I'm softening my line, DAT would still be there as normal for PASM coders who don't care about sharing.
So if I'm writing programs that are purely in P2 assembly language and run in HUBEXEC mode in HUBRAM, all their instruction mnemonics and data definitions go into the COG section?
The "COG" section announces that the following PASM code and data will end up in COG memory at run time. It also applies a few simple rules about how symbolic linkage between what is in COG and outside COG is not allowed. Thus enforcing the requirements of creation of reusable "blobs" of code that can be used in other languages.
Kind of like how VAR announces that data defined there lives in a unique area per object instance. DAT announces that data defined there is shared among instances. Neither VAR or DAT allow different objects any access. Like how PUB and PRI enforce rules of usage.
I haven't really thought about hubexec or inline PASM. Those are yet another different "classes" of code/data. I have no idea what Chip has in mind for the syntax and semantics of handling those in Spin 2.
But as to your question. If your program is entirely PASM you will no doubt have areas of that PASM which are loaded into and run in COGS. Various drivers and such. Again having "COG" sections to delineate those parts of the code would be useful would it not?
Can in line PASM be as simple as adding Pasm and Spin keywords to Spin? You always start in Spin mode so nothing existing breaks and if you want to create inline PASM, you just execute the Pasm keyword (maybe no more than an OpenSpin directive) and then write PASM code with all the Spiiny label and data reference support that exists now. Easy and transparent for the user. Just use the Spin keyword to go back to using Spin.
I don't think we need the a "spin" key word, Spin code is introduced by PUB and PRI already. Spin has block indentation to signify "if", "repeat" etc. So why not just use block indentation to delineate in-line PASM code?
Here is a example of what I mean:
PUB start repeat doSomething PRI doSomething | p, q a : = b + c x : doSomethingElse (a) pasm MOV p, x ADD q, a DADA ... DADA ... return p + qIndeed you have. Thanks. That's is our only point of disagreement. Creating a section, and COG is a fine name for it, where we've set things up for reuse is an idea I'm in favor of, and early on, I mentioned we can and should be doing things to help people get reuse done too. Roy suggests tools, which are good, and this section with the rules setup to maximize reuse is another tool. A good one. Arguably a much needed one.
Right now, one of my simple PASM programs uses DAT in the non-reuse way to quickly and easily fire off COGS. It's a specific purpose, unless we think we need a general purpose fractal bitmap graphics generator BLOB. There is no need to keep a COG running in that scenario, plus I was lazy, plus I wanted to fire off a lot of COG start statements for testing, which found a bug. Kind of worked out on a number of fronts.
Now, we've got features where we can jump into a COG, without reloading it's RAM, and we can do so at any address! This COG section might help a lot with managing that, just by way of another reason to use it.
I'm thinking of breaking the screen into regions and firing off COGS to get it done, and as each finishes, it gets launched with another region. Loading them all will take about a third of the screen refresh time, which is a significant amount of time.
Refactoring to the rules of the COG section will enable lots of things. The beauty of it done this way is say somebody knows the general concept, but hasn't really done reuse. They will stumble through the COG section, until it just works, learning and doing, just like they did in DAT to get good enough to actually think about reuse!
This is an example of how people will get there at times, even if the intent isn't reuse to begin with, and mine was not, just hacking around. This stuff is fun, when we let it be.
Now, why wasn't it written that way anyway? Time. That's my primary argument against making the reuse rules universal. There was writing better planned code, and then there was seeing the fast math on the P2 render a fractal... And there was work to pay for me to actually have the time to do either! So there you go, sometimes life sucks. (for me, it's better now, new gig and all that)
We agree otherwise Heater. Name it COG, BLOB, whatever, and it's fine. People will use it, and we will get more reuse from it and that is good.
We might get a whole lot more given some starter material to help it all along too.
Making things harder may well see a higher reuse percentage, but perhaps a lower overall code shared percentage. My view on this is we want the code. Any of us can refactor it when it exists. When it doesn't exist... ???
In a more general sense, DAT needs to operate as it does, due to all these models of execution. Who knows where the optimal paths and tricks are? I think we want to see that happen and rules now may well make those more difficult, or prevent the discovery of something we might all seriously appreciate as much as we did Bill thinking hard to come up with LMM.
Good reasons for both? I think so.
That's precisely what Chip did in an early revision of SPIN 2. That's what I hope we end up with, because then people who want to learn some PASM can do so in what is likely the easiest, lean and most potent way possible. Or, those who just need some can write it while tracking as little additional info as possible, leaving SPIN to manage what are otherwise painful and tedious details, both of which are why most people avoid assembly language in the first place.
Again, I'll cite the BBC Basic as a fine example, only it did not have as clean of syntax. Didn't matter though, the net result was the same. The second easiest way is to have assembly language setup to be easily called from the HLL, and that's what Chip did on P1, due to the COG model and lack of LMM innovation at that time. He hit the sweetest spot possible. Now that we've gone past some of those limits, he can just go for the gold and get it perfect.
Beyond that, we've got the more traditional model where assembly language is really separate and it starts to get thick in the HLL due to directives, etc... needed to get things done in a more robust context. In terms of just getting some assembly done, this is the most difficult.
Really, this is all about getting at the magic in the leanest way possible. That goal is orthogonal to reuse. And that goal being realized in the way it was on P1 is a reason why a lot of us are here. It is for me. And the "magic", being what the hardware really does in assembly language, is what people really want a lot of the time too, arguments for both reuse and accessability.
Once somebody has gotten at the magic a few times, reuse ends up on the table more often than not, and we will have provided for that case nicely with this new section.
It's a win all around!
Who wouldn't want one?
I would not refer to what the P1 does with PASM as "call". That rather confuses things because it's not a familiar function call and return as we know from most high level languages. Rather it's starting up a whole new process on a different processor.
Having PASM callable from Spin is one way to go. Problems come with passing parameters to it and getting return values back. These calling conventions can be hard enough to work out in a language like C where parameters and returns can be somewhere on the stack, but where and in what order? etc.
Simple inline PASM bypasses those problems. We should have both styles available though.
Re: General purpose fractal COG.
Well, that's how it starts. I'll end up doing that reuse capable one for the multi-cog capable version. It will be much simpler, and a good chance to try out the start COG, no reload option too.
I don't think our video drivers are all that reusable right now either. Lots of constants, and no driver math to run-time calculate things.
That's due to Chip publishing simple, "make it work" code, and the FPGA image changing enough to warrant not going there at present, also due to NANO users mixing it all together with tasks, etc...
Perhaps this image is largely "done" regarding instructions, etc... Hope so. I was just last night twiddling with things in video land, seriously wanting to make it all parametric. Reuse friendly, in other words.
Have a drop-dead date for the next shuttle run?
Have a "feature freeze" date?
While I like this PASM update, it really seems as though it should wait until USB/SerDes are done deals on Chips part.
The more stuff added to 'the list', the less time there will be for testing.
It'd be a shame if a shuttle run were missed, or comes back negative because of some last minute add/s that cut testing time too short.
Ken put up a schedule. So far, we are on track for that.
Would be a shame to have a buggy chip too.
It would be nice to know how close Chip is to freezing the logic for the next shuttle run...
Earlier in this thread, Heater raised the idea of having a separate COG block added to SPIN, which has additional restrictions over the current DAT block when used to hold PASM code. Basically, I think this is a good idea, although I wouldn't perhaps go quite as far as he suggests on adding restrictions to what can be done within such a block - I think these are better implemented as conventions rather than restrictions. But I could be convinced.
The main point of any such change is that current DAT block is now routinely used to contain not only data and PASM code to be executed within a cog, but it is now being used more and more for PASM code to be executed from hub - but it is not particularly well suited to the latter.
My proposal is to extend Heater's original notion slightly, and to add both a COG and a HUB block to SPIN.
The existing DAT block remains essentially unchanged (except as specified below), and can contain PASM code as now, primarily for backward compatibility and also ongoing use from SPIN. But COG is intended to be better suited for code executed from cog by other languages, and HUB is intended to be better suited for code executed from hub by other languages.
The current CON block will remain essentially unchanged (except as noted below), since they are useful from any language. The current VAR, PRI and PUB blocks also remain unchanged, but these are generally unusable from any languages other than SPIN, so the inclusion of any of these block types will indicate to the compiler that the result is to be treated as a SPIN program.
I'd also like to propose a new LOC directive, similar in some ways to ORG, but which can be used in both COG and HUB blocks to specify an absolute hub starting address for whatever entries follow. I think that with these additions, this modified SPIN can not only be used for all current SPIN programs, but it can also be used as a common assembler to support any other languages, eliminating the need for separate assemblers for each.
Here is a quick summary:
COG blocks
- Can include PASM and data elements (like DAT blocks)
- Symbols represent cog offsets from ORG 0 (as in DAT blocks).
- The @symbol notation returns the absolute HUB address of symbol, even at compile time (this is different to the usage in DAT blocks, where this is true only at run-time).
- ORG sets a cog offset (as in DAT blocks) but in addition, LOC can be used to specify an absolute hub address for the following elements. If no LOC is specified the block address will be determined by the compiler.
- PASM code or data entries in COG blocks cannot refer to symbols defined in DAT or VAR blocks.
HUB blocks- Can include PASM and data elements (like DAT blocks)
- Symbols represent absolute BYTE addresses.
- ORG is not supported, but LOC can be used to specify an absolute hub address for the following elements. If no LOC is specified the block address will be determined by the compiler.
- The @symbol notation returns hub address of the symbol, even at compile time this is different to the usage in DAT blocks, where this is true only at run-time). Note that for HUB symbols, @symbol == symbol
- PASM code or data entries in HUB blocks cannot refer to symbols defined in DAT or VAR blocks.
LOC directive- The LOC directive determines the absolute hub address of the following element in either a COG or HUB block.
- All LOC directives are respected, with any resulting space within blocks being zero-filled, but not between blocks.
- Any COG or HUB block overlaps that result from LOC directives will result in an error.
- Blocks without LOC directives are free to be arranged by the compiler.
- If LOC directives leaves space between HUB or COG blocks, the compiler is free to use that space for other blocks.
CON and DAT blocks- No change to existing functionality.
- DAT blocks can contain references to symbols in HUB or COG blocks, and @symbol always returns the the absolute hub address of such symbols (not the offset within the object, as is true for symbols in other blocks).
PUB, PRI and VAR blocks- No change to existing functionality.
- COGNEW and COGINIT extended to allow use on COG blocks, but not HUB Blocks.
P1/P2 Compilation- Where possible (i.e. in the absence of specific LOC directives to the contrary HUB blocks will be placed before other existing block types (DAT, PUB, PRI, VAR etc) and COG blocks will be placed after.
- Programs that contain only CON, COG, HUB and DAT blocks are compilable stand-alone into a .blob output, which has no header or object information added.
- On the P1, specifying .eeprom or .binary for compilations containing COG or HUB blocks will cause and error unless there is also at least on SPIN method, in which case the usual header and object information will be added.
- On the P2, it may be acceptable to specify .binary or .eeprom as the output format even without any PUB or PRI blocks - the resulting binary will have header information added, and could represent a program whose first 512 longs are loaded into cog 0.
Comments?Ross.
But I do not see any reason to cripple spin to archive that goal.
As is now we have already the problem that the spin stack is not in Hub anymore. A lot of OBEX objects use Parameter and local vars of SPIN methods as mailbox from spin to pasm and back. Will not work anymore.
Where to put it?
So PASM is not allowed to see any Data defined in spin? really?
We can do that better - just do not allow SPIN to have any access to pasm either. brilliant.
HUB ram is still a rare resource. A lot of OBEX objects reuse the space occupied by PASM as buffer after starting the cog. Verboten? (not allowed?)
Yes. I am fine with a COG section. If somebody WANTS to build a language independent COG. But if NOT?
IMHO this is going to far.
The beauty of SPIN/PASM is the way they can interact together. Do not destroy that for the reason of reusing code from other languages.
The same is with GCC/GAS. Them are build to work together. And the PropGCC team is doing a great job there. Does it really make sense to create a BLOB in SPIN/PASM to use it with GCC? Why?
Would not some converter program converting PASM to GAS syntax and vice versa do that job also?
Enjoy!
Mike
Both SPIN and its existing use of PASM remains unchanged under this proposal. The point is that this proposal allows PASM to also becomes usble as the foundation for other (non-SPIN) languages as well. It "loosens" the tight coupling of PASM from SPIN without actually breaking the linkage - on which SPIN currently depends, and which people rightly point out is one of SPIN's strenghts,
An alternative would be to adopt GAS as the SPIN assembler. I'd be okay with that as a proposal - but you will still need to make most of the other changes I'm proposing, so I don't really see how this helps.
Ross.
well - not really.
Your HUB blocks should be usable from SPIN also. You are decupling too much.
Enjoy!
Mike
This is not a likely, nor reasonable proposal. If that is desired, do it after we get Open Spin.
Thanks for thinking about this and coming up with a starting point.
I am personally unable to really comment on the specific details because I don't understand the intricacies of compilers, assemblers, and linkers.
Just saying I appreciate the thought put into this.
As for the needs for access to data in certain places:
I've seen the word EXTERN put on labels, so as to make them exportable. I think this builds a specific link to a specific address, in some directly visible way that the linker uses when it ties everything together.
A language I'm most familiar with uses a VAR_GLOBAL / END_VAR block section to say that these variables inside are to be made accessible from the outside.
They are usable indirectly. I think you are misunderstanding the intent here. SPIN has no direct HUBEXEC capability (unless this is being added to SPIN2???) so the only reason to allow SPIN to access the HUB blocks would be to read or modify the data in them. But this is precisely the kind of usage that makes code in existing DAT blocks so difficult to re-use from other languages. Also, these new HUB blocks intentionally use a different symbol/address scheme to the existing DAT blocks (one more suited to HUBEXEC, which is the main point of them) so you would just be adding more complexity to the SPIN language for little or no benefit.
However, SPIN can sensibly access COG blocks within from PUB or PRI blocks (i.e. to start a cog!), and those cogs can then use HUBEXEC to access HUB blocks - so the effect of the limitation I have proposed is just to ensure that the method of using these new blocks is consistent across all languages - i.e. essentially limited to a COGNEW or COGINIT, plus parameter passing. I don't want to impose such limits on existing PASM in DAT blocks, but I think it is reasonable for the new blocks, which are not intended to be used directly from SPIN.
So new SPIN programs suffer very little from these limitations, and existing SPIN programs not at all. But they make language independent programming easier.
Ross.
I was assuming SPIN2 would be based on Open Spin. Is that not the case?
Ross.
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1251927&viewfull=1#post1251927
This fixed the LOCBASE/LOCBYTE/LOCWORD/LOCLONG/LOCINST bug.
'LOCINST D,@address' gets the 16-bit (executable) address of some long in hub memory into D.
Ross, I don't know yet. The first Spin2 will probably work from PNut.exe, and then I'll make it work on the chip, itself. Roy would probably build it into a PC-based, tool, though, which, I assume, would be Open Spin.
Thanks for the fast turnaround Chip!
C.W.
Which reminds me to test out COGx commands for that old COGNEW bug.
Time to reload my DE2...
I'll just say it this way: If SPIN is broken on a basic level, it will be fixed. DAT, SPIN, PASM, VAR, etc... all need to interact how they do now, and to the logical, unified conclusion possible given how the P2 operates.
Above that, if people think adding some sections specifically to target reuse makes sense, then great! Just don't break the core.
We won't even understand all the optimal ways to use the memory and programming models optimally for some time yet and declaring them all this early very likely means bad tools, and or limits we deal with that don't always make the best sense.
Count me out on all of that.
Much better to get SPIN+PASM done in the style we are familiar with, get the OpenSpin port, and then we can explore options from there, and more importantly, various options may well compete to see what makes the most sense too.
Count me IN on tools to help when reuse is the intent, not the mandated norm.
We didn't go through all this to make a killer PASM chip only to ship it with a hobbled programming environment. SPIN is awesome. Let's preserve the awesome and add things we know can help people reach reuse goals without breaking the awesome.
Reuse is a worthy goal, but it's not always the primary goal, and the core tools should reflect that accordingly.
That's precisely my suggested approach. I added a note to my original post to make it clearer that the existing functionality of all existing block types (CON, DAT, PUB, PRI) remains the same - just slightly extended in some cases.
Ross.
I get the need to reuse and I agree and support doing it.
Really, the core thing here is to get the SPIN Chip will have made. Having that is important. And we kind of get that now, or we don't. Once the P2 is out, I suspect Chip will go off onto the next thing and probably should!
The reason for getting that core SPIN Chip will end up making is to also get the core on-chip package. This is important to some people, and having it lean, mean, kind of "wild" is where the fun and power will be. Ideally, one can use this with a keyboard, mouse, or terminal and just go, and it can build itself most likely. No dependencies.
A whole lot of people won't care so much about having that that, however they may well and more likely care about reuse, and open tools for their OSes of choice. I myself want to run more Mac OS, maybe Linux in the future, as well as do some on-chip work.
And toward that end, we can and should all build on that core, add to it, hack on it, make tools for it, etc... and it's gonna be great. All of that can happen over whatever time period it happens too. There will be dependencies, but those are desirable in this context, which is why over complicating what is the core SPIN seems like a best fit for OpenSpin.
I'll be more quiet now about it for a while.
Too early to estimate just yet. Once the features are all ticked off then some speculation can be made.