2) Making PASM code universally usable across all languages as binary blobs no matter if it was written in a Spin object or in GAS or whatever. Does Spin wrap address that ?
Heater,
I missed this bit earlier - I think you have nailed it. One of the main problems with the P1 is that PASM was never quite flexible enough to be used as a stand-alone assembler, and therefore was never quite flexible enough to be used as the basis for languages other than SPIN.
It certainly can be done (as has been demonstrated by Catalina and others), but it requires some extensions to PASM (as implemented in Homespun and BSTC) - and even so it still needs quite a bit of messing about.
If SPIN2 were to extend the PASM part of the language just slightly, then stand-alone PASM could be used not only in SPIN2, but also for portable objects, as well as for implementing higher-level languages that can use those same objects.
And it wouldn't even take much - syntax-wise, PASM2 could be a simple superset of PASM so that P1 PASM code could still compile and run on the P2 (except where instruction semantics or the hardware changes, of course - but these cases can be easily documented, and the language could even warn you automatically of any such cases).
While I think it would be a shame for existing P1 users if Parallax ditched the current PASM syntax and went with GAS, it would at least be workable (provided of course that GAS was also used as the assembler built into SPIN2).
And at least we would all have a common foundation for all future P2 work.
One of the main problems with the P1 is that PASM was never quite flexible enough to be used as a stand-alone assembler, and therefore was never quite flexible enough to be used as the basis for languages other than SPIN.
That's because SPIN + PASM is one unified thing. And doing that is part of the magic which brought many of us here. To be honest, I find the idea of breaking it offensive. There is no way I want GAS mixed in with the core SPIN+PASM implementation.
There is no reason to go breaking SPIN + PASM!
Had something like plugging GAS into SPIN been the setup here when I arrived, I very likely would have moved on.
Know what got me? I downloaded the data sheet and said, "Wow! This is crazy!" After looking around a little, I also thought, "bet it's hard to use too" Let's take a look...
One quick download later and I was looking through the samples in the Prop Tool. What I saw was genius, simple, flexible, and something a person could grok right away. Bought a Demo Board that day. When it arrived, I was stunned at the number of things I really didn't need to know in order to make stuff happen. And all that power in one place. Simple! Just write it, hit F10 and go!
Few things are that simple and powerful. Arduino makes the basics simple, but really doing magic takes considerable effort, and they've done a fine job with it all too. But, it's nothing like SPIN+PASM is. Frankly, nothing else is. Chip took a lot of the hassles out of this stuff, and that makes it fun as well as educational and productive.
But there is more...
C advocates here often ask what the deal is. Discussions like this really don't help the C cause. Not one bit. Ever wonder why people will just author killer things in SPIN+PASM? Did it ever occur to you guys that the reason why we get the contributions we do has something to do with how great, fun, productive, flexible, potent SPIN+PASM really is?
I've gone and advocated we make sure C is excellent, and actually said awesome on the Propeller 2. I want that to be true. Lots of us do. I think it's going to rock hard on P2, and the size and capability of the P2 will make for a great fit. Features were added to the P2, at some significant expense mind you, just to make sure C has a great shot at the awesome.
Going forward, we've all recognized the need for "standard" or "pro" type tools. It's been recognized by Parallax, and very significant efforts are underway to deliver those too. And Ross has done a perfectly fine job with Catalina. Not only do we have one C option, but two! And they are fine options!
What else do you guys really need? How much is enough?
Maybe if we make SPIN+PASM suck more, C might be more attractive?
Nothing wrong with GAS, mind you. It's just not unified with SPIN, and that matters a lot. Ever wonder about the attractiveness of Apple computers? Same deal. They do the whole thing, and they do what it takes to optimize that experience, standard or not too. People pay a lot, sometimes double for the same basic hardware due to that value add, and people have paid a LOT over time to get at the same value associated with the Propeller, and for many of the same kinds of basic reasons.
If "pro" or "standard" tools are needed, those really should be based off of OpenSpin. Leave the core SPIN+PASM as one unified thing. It can be put on chip for a self-hosted environment, it's great for knocking out quick projects, and it's fun as all get out too. Among many other things, like when we get to inline, it will be a simple, lean, common sense syntax that will just work and do the obvious things in the obvious ways...
Just understanding the discussion about how to inline in C takes more time than it took to get going on SPIN+PASM. Same goes for gcc and friends too, and that says a lot.
What it says most is that "pro" or "standard" tools have a lot of options needed for bigger projects, code reuse, integration into other tool chains, and so forth. We need that stuff. None of my comments should be taken as a negative about C and friends, or that we don't need it, etc...
It's not about that at all.
It is all about making sure we get the benefit of one unified design, just like we had with P1.
Like I said, the idea that we need to kill off the excellent SPIN+PASM environment is offensive really. If the one we should have had needs to be written, so be it. Seriously.
What we will and should have is the choices people need to maximize their use of the Propeller chip. That's what we should have.
Let's preserve the awesome, not break it.
Roy has it right. Let's get the core environment done, and likely see Chip port it to the P2 chip for a self-hosted environment. He's gonna get help doing that, because people want that. Done. Once that is done, it's gonna be mostly done and that's because the whole thing is simple to begin with. Lean.
Once Roy gets OpenSpin done, all the C and other HLL efforts can build off of that. And instead of breaking something pretty great, we can author tools to help people, who want to reuse or contribute to reuse, and get that done in ways they find productive and useful.
From there it's center of gravity and here's another basic thing to consider: What Chip did rocks hard. Those of us that like it, grok it, really like it for reasons already given. If all those standard, pro tools really can't compete reasonably, it seems to me that's a problem with those tools, not SPIN+PASM.
Good grief!
There won't be a common foundation because the use cases and motivations are orthoginal. I suppose there might be just one foundation if it gets ugly enough, and then a bunch of people just go away. Unified community at that point. Nice thoughts huh? I sure don't want to think 'em.
And I'll put it another way. When I'm on the free gig, having a good time, learning stuff, building stuff I want to build, you know enjoying how Parallax "powers your genius", SPIN+PASM makes a lot of sense a lot of the time. And it makes sense because of how it was made and why it was made too.
Pay me, and I'll be perfectly happy to deal with the standard, pro tools and write reusable code for you all the time. See how that works?
That's because SPIN + PASM is one unified thing. And doing that is part of the magic which brought many of us here. To be honest, I find the idea of breaking it offensive.
No-one is advocating breaking SPIN + PASM. But neither SPIN nor PASM are usable on the P2 in their current form - so change in this space is both inevitable and necessary.
All I am saying (and I believe Heater is thinking the same way) is that by extending PASM slightly, it can be used not only in SPIN + PASM, but also in C + PASM, BASIC + PASM, FORTH + PASM, etc etc - or just as plain old PASM!
What's notto like about that? It doesn't undermine SPIN at all, as far as I can see.
I don't really understand why this should be such a controversial issue.
I'm totally with you. I love Spin for all the reasons you sited. It's simple and quick to get started with, especially for non-expreience programmers. Having integerated PASM makes transitioning to assembler a doddle. The PASM syntax and P1 architecture are the simplest nicest assembly language programming environment I have ever seen. And so on.
I am not advocating breaking Spin/PASM, especially not for the P1.
So imagine the PII is out for two years and there are now a couple of hundred objects with assembly language drivers in the OBEX and floating around the forum. tens of thousands of man hours of work will have gone into creating them. They will have been written in both Spin and C.
Problem is those juicy assembler language drivers, are not usable between languages. Which seems kind of crazy and wasteful. Getting such code into peoples hands easily is what the Propeller ecosystem thrives on. It should be made friction free.
That is the problem we are discussing here. Perhaps you do not feel that is a problem.
One solution is my proposal for breaking the linkage between PASM and Spin by introducing the "PASM" section and a few simple rules around it. I don't believe this is a big hardship for Spin users. Most new users would probably accept the new syntax and not even notice the semantic differences.
Another solution is Roy's answer, get the tools to do the work. Open spin may be able to expose what linkage there is between PASM and Spin in such a way that C programmers could easily use the PASM binaries extracted from Spin objects.
Does that solution help going the other way? Assembler language drivers written by C programmers migrating to Spin programs ?
My feeling is that the "no-linkage" binary blob approach is the most universal way.
These ideas are worthy of more exploration. Or do we just let the problem persist into the PII world?
I really want to make my own tools function holistically with the hardware, without a bunch of stifling accommodations made for other paradigms.
However, I'm sure a mode of writing Spin and PASM code could be formalized, as has already been brought up here, that would enable inter-operability with C.
I totally agree. No stifling for me. I'm stifled enough already.
But there we have a contradiction, yes a mode of writing Spin and PASM code could be formalized, it would also be totally ignored by those "unstifled" programmers who don't know and/or care why there is such a formalism. We can almost be sure this will happen as such a formalism has been discussed on the P1 forum for years and even documented by RossH. It has all been ignored.
Would the introduction of a "PASM" section be stifling? Or just a neat way to organize code in the spirit of the Spin language?
However, I'm sure a mode of writing Spin and PASM code could be formalized, as has already been brought up here, that would enable inter-operability with C.
Yes, I think so too. But what Heater and I are proposing here is something even simpler - essentially, just "loosening" the tight coupling between SPIN and PASM, to facilitate using PASM either by itself, or in conjunction with languages other than SPIN.
It is already possible to do this - but so difficult that few bother to do so.
Perfectly understandable. I feel the same way myself.
Yes, I think so too. But what Heater and I are proposing here is something even simpler - essentially, just "loosening" the tight coupling between SPIN and PASM, to facilitate using PASM either by itself, or in conjunction with languages other than SPIN.
It is already possible to do this - but so difficult that few bother to do so.
Ross.
But that difficulty is what makes it not so appealing, isn't it?
I know you listed a few things that would have to be done. Would you mind listing them here (again) so that they could be contemplated? I know this stuff exists in another post, or posts. The simpler you can keep the guidelines, the better we can think about it.
I think that to enable Spin programmers to create PASM code that is usable outside of Spin, with C say, would require only slight modification to the Spin language:
1) Introduce a PASM section. This is basically a DAT section with some extra rules...
2) Any PASM code to be launched into a COG has to be in a PASM section.
3) Code in a PASM section cannot access any variables defined in Spin, VAR blocks or DAT sections, by name. This removes dependency of PASM from Spin data layout.
4) Spin code cannot write any locations in a PASM section, at least by name. This prevents initializing of LONGs and such prior to loading to COG. Data that C or other languages would not know about.
5) Due to 4) all parameters passed to PASM prior to launch go through pointers passed via PAR.
6) All communication between a running PASM code and Spin go through shared HUB as normal, using pointers passed through PAR.
The basic idea is to decouple the PASM and Spin. Then the PASM can be compiled and extracted as a usable "binary blob" or "firmware" by openspin or BST etc and used in other language systems.
This is not to onerous is it? It's even good practice, makes for nice clean code. In the same way a Spin object cannot see a sub-objects variables or PRI's.
Note: This works both ways. Such "binary blobs" created by C or whatever can be used in Spin by including them via a file statement. It's a win-win.
Yes discussions in the past got overly complex what with mailboxes, registries, etc. What is proposed here though is dead simple.
RossH has indeed converted drivers, he is not all talk. Others have done so as well. Even I adapted a couple of drivers back in the Zog C days. We don't want to do that again, and again, and again.
I also really don't want PASM and SPIN separate. That is not what is being proposed here.
Gas has nothing to do with this. It's not in the picture. That's for the C guys to suffer
The nice expressive DAT section can remain. The proposed PASM section is a DAT section, all the same expressive cool ways to express data remain in there.
But that difficulty is what makes it not so appealing, isn't it?
I know you listed a few things that would have to be done. Would you mind listing them here (again) so that they could be contemplated? I know this stuff exists in another post, or posts. The simpler you can keep the guidelines, the better we can think about it.
Getting over most of the difficulties and complexities could be done with a few simple conventions, plus a few simple changes or extensions to SPIN/PASM. For instance (this is just the first one that springs to mind) - why does a Spin object have to have at least one PUB segment to compile? All this does is force you to include a dummy method, which generates code that has to later be stripped out when all you want is the compiled PASM.
Heater has already summarized some of the conventions. I'll try and put a few more together this weekend and post them for wider discussion. I'd suggest we start a new thread (perhaps Heater would like to do so, since he started the discussion) so as not to clutter this one unduly.
No, of course not. If you are creating PASM objects that are only intended to operate withing your own SPIN program, or with other SPIN programs, you are free to use whatever conventions you want - and the interface to such objects is generally a set of SPIN methods anyway, with the PASM code nicely encapsulated.
But sometimes you just want to submit a chunk of generally useful PASM code, exposing some other interface - and there is currently no way to do so. You have to wrap it in SPIN because that is currently the only accepted convention - we have no convention to enable that code to be called from any cog, unless that cog is running SPIN. This has nothing to do with C - this code cannot even be called from another cog within the same SPIN program that is running PASM!
For that to be true Ross, we would need to ADD this PASM section and have the rules apply there, but not actually change how DAT works today.
I'm in favor of doing that. Maybe we should just call the new section BLOB. And I'm serious! Leave SPIN as is today and add BLOB to the list of section definitions and behaviors. In the BLOB section, do these reuse things so that we make sure a BLOB works well. That's a good thing!
This:
The whole idea of a binary blob for PASM is obsolete. We have HUBEXEC now.
Does anyone here really want to tell me that my hubexec PASM code is not allowed to see my labels in HUB?
Honestly. This is HUMBUG.
Is true and precisely why DAT and how SPIN+PASM works right now needs to be left alone. A lot of things will be possible, and yes not all that easy to reuse, but again, that's not always the primary case. Frankly, I think Chip has already seen this in that Pnut doesn't currently require any SPIN at all to build. It can assemble only.
Adding BLOB would provide for that intent, and we could very easily publish a lot of good stuff for people to use in the BLOB section when they have the intent to publish for reuse, or where people do conversions. Since the result is MIT, if published for sharing here in the traditional way we've done, doing that stuff is not only encouraged, but expected.
Re: Not all talk.
Heater, of course! Ross has done a fine job as have others. I'm sorry I implied otherwise. Wasn't my intent.
Re: No other convention.
Right now, Pnut works without having a PUB of any kind. Pretty easy to have that continue. And it's got SPIN 2 in there, but it's early and kind of broken at the moment too.
We can make a nice BLOB on P2 right now. If that isn't changed, would it not work for this purpose? One could use DAT in whatever way makes sense, and if Chip sees the core rules for a BLOB section and implements them, wouldn't that more or less reach the goals everyone has here?
Perhaps this discussion is really early, save for the idea of the BLOB section specifically intended for reuse, both directions even. If we do that, we could then package up something in C and bring it over. All good.
Adding something to SPIN for this purpose is good. We need it. Preventing things isn't something I'm a fan of, for reasons already given.
msrobots is right about it too. With HUBEX, making PASM BLOBS is not always going to happen now. And the unified SPIN+PASM is perfect for how HUBEX will end up working. Which, by the way, is precisely why I'm vocal about this right now.
And that means making a BLOB is something people will have a specific intent to do, which makes an addition aimed at making that happen nicely perfectly sensible.
Seriously, how about we work to define BLOB so that it's a total win for the reuse case? Split the middle, so to speak.
CON ' for the BLOB
...
BLOB ' just like DAT, but enforces certain rules... ie no access to labels outside of this BLOB section, but exports 'par' and 'start' as long aligned hub addresses
par LONG ....
' more parameters, each with a label
' BLOB could export:
' - a .h with a struct for C/C++ for accessing the parameters
' - a .spin automatically generated interface (would be nice if Spin supported struct's)
start ' where the cog entry point is
I think that is all we really need.
It could export an object file, with the first long encoding relative par&start in the fashion COGRUN/COGRUNX needs.
NOTE:
Normal current expected Spin/Pasm would not change at all.
I don't know what any of You need possibility of ASSEMBLE without invoke SPIN part.
BUT I need that to that type of programing.
' Portable Low Type Driver
' I don't know what You will call it.
DAT
orgh @XXX
DriveTable
jmp @Init
jmp @SD_read_sector
jmp @SD_read_Dir
jmp @SD_write_sector
jmp @SD_write_Dir
......... and so on
ret ...... end table
Init
xxx xxx,xxx
ret
SD_read_sector
xxx xxx,xxx
ret
SD_read_Dir
xxx xxx,xxx
ret
SD_write_sector
xxx xxx,xxx
ret
SD_write_Dir
xxx xxx,xxx
ret
BTW, when I say leave SPIN as it is today, I don't mean it literally. New things are needed for P2. We discussed object pointers, larger memory space, now BLOB, inline, tasks, etc...
Almost...It's not the PropTool that was born to simple it was the Spin language itself. Spin + included PASM that is.
The structure of which you speak, "spin in one side and pasm in other having a fixed interface" is not a function of the tool used for editing but the very language definition. Don't forget there are many other Spin compilers that do not depend on any GUI tool to use.
Aside: I have noticed many times that users of IDE's, and especially VB, cannot tell the difference between a programming language and the tool they use to edit it.
Now, about those rules or structure...
I think that to get Spin programmers to create PASM code that is usable outside of Spin, with C say, would require only slight modification to the Spin language.
1) Introduce a PASM section. This is basically a DAT section with some extra rules...
2) Make it a requirement that any PASM code to be launched into a COG has to be in a PASM section.
3) Code on a PASM section cannot access any variables defined in Spin VAR blocks or DAT sections by name. This removes dependency of PASM from Spin data layout.
4) Spin code cannot access any locations in a PASM section, at least by name. This prevents initializing of LONGs and such prior to loading to COG. Data that C would not know about.
5) Due to 4) all parameters passed to PASM prior to launch are to go through pointers passed in PAR.
6) All communication between a running PASM code and Spin go through shared HUB as normal, using pointers passed through PAR.
With this in place there is no symbolic linkage between PASM and Spin, except for the starting address which Spin needs. With no linkage the resulting code can be compiled buy tools such as openspin, or BST into a binary blob that is usable by any language.
However, I suspect the Spin community would hate this idea.
Heater, sorry ... I do not agree ... perhaps is due to my lack of knowledge.
Take a class for example. I don' t want to introduce classes/istances as their real meaning, it is only an example of a file that exists in the ide, part of the project.
In classes you declare properties, methods and these are exposed to other part of program. Classes on the development system are files on the filesystem, with a known structure, part of the project.
Now if a pasm section instead of residing in dat will be a class (not in its real meaning, just in the way it is written) some longs can be properties. This mean they will be saved with a known structure. Spin can initialize these longs because they are exposed as properties. The same can happen for C.
A pasm "class" can be imported in a spin project or in a c project.
Perhaps you can even mix all. If you have a pasm class , a spin class a c class perhaps pasm and c can run natively while c-xmm and spin will be executed through their kernel/interpreter in a separate cog and they can communicate to each-other through the exposed properties, well known for everyone of them or better said well known for the ide that have to compile/link/assemble it with the right tools. Inside every single kind of class the rules will pretty remain the same for every single language. The only difference is that one class can be only written in one language.
You can have a project choice (spin/pasm/c) that defines the primary application language. Than classes can be of any choice (spin/pasm/c/forth ...) and everything cooperates.
Why can't this concept work?
Now change the name, don't call it class ... it was to explain the idea with my poor english.
Now we have hubex mode, I was wondering if it might be nice to have a simple hook in the Rom Monitor to jmp/call a user monitor extension in hub.
ozpropdev and I have both been working on p2 debuggers - different but complimentary. I expect theremay be others too later.
What ifthey could be simply hooked (by a single command) into the monitor. This way our code could become extensions to the monitor.
I'm not opposed to it. Actually, maybe it's the right or a very good thing to do.
Seems to me, having the monitor check the very first two longs or maybe even the first one of HUB RAM for a signature and address, a debug package could just be uploaded right through whatever terminal people use. Have it always check this when a command is entered that isn't one of it's own, and if the package is there, pass the current command and address to it, and the user is off to the races.
The upload can be a file copy to the serial port, or a paste through the terminal. Either way, the package can specify those or that long, then any other addresses and data needed to place whatever extension makes sense, where it makes sense.
Early on, I was making heavy use of the copy / paste function to upload lots of data, and it worked very well. The way addresses work is either one specifies an address with a line of data, or a colon ":" and that makes relocating things, or even just specifying where things go super easy. The package would specify the low address long, or longs, then specify a start address, all the data for the package, another start address, all the data, if desired, etc...
A simple copy package.txt > COM8 gets it done! (documented in the monitor PDF, which I will update this time around)
BTW, doing this wouldn't really require HUBEX mode. It's just simpler.
Another thing: If that same check is always done in the monitor, a person who wants the integrated debugger can just include it, parking it at whatever address they feel makes sense given how their program works, then launch the monitor on a COG as part of their ordinary program startup too.
One question: How would an extension understand multiple monitors could be running, and do we care?
Why, because PII will have inline PASM and hub exec PASM which I don't think should be included in this scheme.
So long as the current function of DAT is unchanged, adding the BLOB scheme with the intent of helping to create reusable PASM is good. Otherwise, ALL PASM should remain as is in DAT, including that PASM targeted at a COG.
Comments
Heater,
I missed this bit earlier - I think you have nailed it. One of the main problems with the P1 is that PASM was never quite flexible enough to be used as a stand-alone assembler, and therefore was never quite flexible enough to be used as the basis for languages other than SPIN.
It certainly can be done (as has been demonstrated by Catalina and others), but it requires some extensions to PASM (as implemented in Homespun and BSTC) - and even so it still needs quite a bit of messing about.
If SPIN2 were to extend the PASM part of the language just slightly, then stand-alone PASM could be used not only in SPIN2, but also for portable objects, as well as for implementing higher-level languages that can use those same objects.
And it wouldn't even take much - syntax-wise, PASM2 could be a simple superset of PASM so that P1 PASM code could still compile and run on the P2 (except where instruction semantics or the hardware changes, of course - but these cases can be easily documented, and the language could even warn you automatically of any such cases).
While I think it would be a shame for existing P1 users if Parallax ditched the current PASM syntax and went with GAS, it would at least be workable (provided of course that GAS was also used as the assembler built into SPIN2).
And at least we would all have a common foundation for all future P2 work.
Ross.
That's because SPIN + PASM is one unified thing. And doing that is part of the magic which brought many of us here. To be honest, I find the idea of breaking it offensive. There is no way I want GAS mixed in with the core SPIN+PASM implementation.
There is no reason to go breaking SPIN + PASM!
Had something like plugging GAS into SPIN been the setup here when I arrived, I very likely would have moved on.
Know what got me? I downloaded the data sheet and said, "Wow! This is crazy!" After looking around a little, I also thought, "bet it's hard to use too" Let's take a look...
One quick download later and I was looking through the samples in the Prop Tool. What I saw was genius, simple, flexible, and something a person could grok right away. Bought a Demo Board that day. When it arrived, I was stunned at the number of things I really didn't need to know in order to make stuff happen. And all that power in one place. Simple! Just write it, hit F10 and go!
Few things are that simple and powerful. Arduino makes the basics simple, but really doing magic takes considerable effort, and they've done a fine job with it all too. But, it's nothing like SPIN+PASM is. Frankly, nothing else is. Chip took a lot of the hassles out of this stuff, and that makes it fun as well as educational and productive.
But there is more...
C advocates here often ask what the deal is. Discussions like this really don't help the C cause. Not one bit. Ever wonder why people will just author killer things in SPIN+PASM? Did it ever occur to you guys that the reason why we get the contributions we do has something to do with how great, fun, productive, flexible, potent SPIN+PASM really is?
I've gone and advocated we make sure C is excellent, and actually said awesome on the Propeller 2. I want that to be true. Lots of us do. I think it's going to rock hard on P2, and the size and capability of the P2 will make for a great fit. Features were added to the P2, at some significant expense mind you, just to make sure C has a great shot at the awesome.
Going forward, we've all recognized the need for "standard" or "pro" type tools. It's been recognized by Parallax, and very significant efforts are underway to deliver those too. And Ross has done a perfectly fine job with Catalina. Not only do we have one C option, but two! And they are fine options!
What else do you guys really need? How much is enough?
Maybe if we make SPIN+PASM suck more, C might be more attractive?
Nothing wrong with GAS, mind you. It's just not unified with SPIN, and that matters a lot. Ever wonder about the attractiveness of Apple computers? Same deal. They do the whole thing, and they do what it takes to optimize that experience, standard or not too. People pay a lot, sometimes double for the same basic hardware due to that value add, and people have paid a LOT over time to get at the same value associated with the Propeller, and for many of the same kinds of basic reasons.
If "pro" or "standard" tools are needed, those really should be based off of OpenSpin. Leave the core SPIN+PASM as one unified thing. It can be put on chip for a self-hosted environment, it's great for knocking out quick projects, and it's fun as all get out too. Among many other things, like when we get to inline, it will be a simple, lean, common sense syntax that will just work and do the obvious things in the obvious ways...
Just understanding the discussion about how to inline in C takes more time than it took to get going on SPIN+PASM. Same goes for gcc and friends too, and that says a lot.
What it says most is that "pro" or "standard" tools have a lot of options needed for bigger projects, code reuse, integration into other tool chains, and so forth. We need that stuff. None of my comments should be taken as a negative about C and friends, or that we don't need it, etc...
It's not about that at all.
It is all about making sure we get the benefit of one unified design, just like we had with P1.
Like I said, the idea that we need to kill off the excellent SPIN+PASM environment is offensive really. If the one we should have had needs to be written, so be it. Seriously.
What we will and should have is the choices people need to maximize their use of the Propeller chip. That's what we should have.
Let's preserve the awesome, not break it.
Roy has it right. Let's get the core environment done, and likely see Chip port it to the P2 chip for a self-hosted environment. He's gonna get help doing that, because people want that. Done. Once that is done, it's gonna be mostly done and that's because the whole thing is simple to begin with. Lean.
Once Roy gets OpenSpin done, all the C and other HLL efforts can build off of that. And instead of breaking something pretty great, we can author tools to help people, who want to reuse or contribute to reuse, and get that done in ways they find productive and useful.
From there it's center of gravity and here's another basic thing to consider: What Chip did rocks hard. Those of us that like it, grok it, really like it for reasons already given. If all those standard, pro tools really can't compete reasonably, it seems to me that's a problem with those tools, not SPIN+PASM.
Good grief!
There won't be a common foundation because the use cases and motivations are orthoginal. I suppose there might be just one foundation if it gets ugly enough, and then a bunch of people just go away. Unified community at that point. Nice thoughts huh? I sure don't want to think 'em.
And I'll put it another way. When I'm on the free gig, having a good time, learning stuff, building stuff I want to build, you know enjoying how Parallax "powers your genius", SPIN+PASM makes a lot of sense a lot of the time. And it makes sense because of how it was made and why it was made too.
Pay me, and I'll be perfectly happy to deal with the standard, pro tools and write reusable code for you all the time. See how that works?
No-one is advocating breaking SPIN + PASM. But neither SPIN nor PASM are usable on the P2 in their current form - so change in this space is both inevitable and necessary.
All I am saying (and I believe Heater is thinking the same way) is that by extending PASM slightly, it can be used not only in SPIN + PASM, but also in C + PASM, BASIC + PASM, FORTH + PASM, etc etc - or just as plain old PASM!
What's not to like about that? It doesn't undermine SPIN at all, as far as I can see.
I don't really understand why this should be such a controversial issue.
Ross.
Propeller II Instructions as of 2014/03/20 ---------------------------------------------------------------------------------------------------------------------------- ZCxS Opcode ZC I Cond Dest Source Instr00 01 10 11 Operand(s) Flags ---------------------------------------------------------------------------------------------------------------------------- ZCWS 00000ff ZC I CCCC DDDDDDDDD SSSSSSSSS RDBYTE RDBYTEC RDWORD RDWORDC D,S/PTRA/PTRB ZC ZC ZC ZC ZCWS 00001ff ZC I CCCC DDDDDDDDD SSSSSSSSS RDLONG RDLONGC RDAUX RDAUXR D,S/PTRA/PTRB || D,S/#0..$FF/PTRX/PTRY ZC ZC ZC ZC ZCMS 00010ff ZC I CCCC DDDDDDDDD SSSSSSSSS ISOB NOTB CLRB SETB D,S/# ZC ZC ZC ZC ZCMS 00011ff ZC I CCCC DDDDDDDDD SSSSSSSSS SETBC SETBNC SETBZ SETBNZ D,S/# ZC ZC ZC ZC ZCMS 00100ff ZC I CCCC DDDDDDDDD SSSSSSSSS ANDN AND OR XOR D,S/# ZC ZC ZC ZC ZCMS 00101ff ZC I CCCC DDDDDDDDD SSSSSSSSS MUXC MUXNC MUXZ MUXNZ D,S/# ZC ZC ZC ZC ZCMS 00110ff ZC I CCCC DDDDDDDDD SSSSSSSSS ROR ROL SHR SHL D,S/# ZC ZC ZC ZC ZCMS 00111ff ZC I CCCC DDDDDDDDD SSSSSSSSS RCR RCL SAR REV D,S/# ZC ZC ZC ZC ZCWS 01000ff ZC I CCCC DDDDDDDDD SSSSSSSSS MOV NOT ABS NEG D,S/# ZC ZC ZC ZC ZCWS 01001ff ZC I CCCC DDDDDDDDD SSSSSSSSS NEGC NEGNC NEGZ NEGNZ D,S/# ZC ZC ZC ZC ZCMS 01010ff ZC I CCCC DDDDDDDDD SSSSSSSSS ADD SUB ADDX SUBX D,S/# ZC ZC ZC ZC ZCMS 01011ff ZC I CCCC DDDDDDDDD SSSSSSSSS ADDS SUBS ADDSX SUBSX D,S/# ZC ZC ZC ZC ZCMS 01100ff ZC I CCCC DDDDDDDDD SSSSSSSSS SUMC SUMNC SUMZ SUMNZ D,S/# ZC ZC ZC ZC ZCMS 01101ff ZC I CCCC DDDDDDDDD SSSSSSSSS MIN MAX MINS MAXS D,S/# ZC ZC ZC ZC ZCMS 01110ff ZC I CCCC DDDDDDDDD SSSSSSSSS ADDABS SUBABS INCMOD DECMOD D,S/# ZC ZC ZC ZC ZCMS 01111ff ZC I CCCC DDDDDDDDD SSSSSSSSS CMPSUB SUBR MUL SCL D,S/# ZC ZC ZC ZC ZCWS 10000ff ZC I CCCC DDDDDDDDD SSSSSSSSS DECOD2 DECOD3 DECOD4 DECOD5 D,S/# ZC ZC ZC ZC ---------------------------------------------------------------------------------------------------------------------------- Z-WS 1000100 Zf I CCCC DDDDDDDDD SSSSSSSSS BLSIZE BLMASK D,S/# Z- Z- Z-WS 1000101 Zf I CCCC DDDDDDDDD SSSSSSSSS ONECNT ZERCNT D,S/# Z- Z- ZCWS 1000110 fC I CCCC DDDDDDDDD SSSSSSSSS TOPONE TOPZER D,S/# -C -C ZCWS 1000111 fC I CCCC DDDDDDDDD SSSSSSSSS BOTONE BOTZER D,S/# | D,S/#,#0..7 -C -- --MS 10010nn nf I CCCC DDDDDDDDD SSSSSSSSS GETNIB SETNIB D,S/#,#0..7 -- -- --MS 1001100 nf I CCCC DDDDDDDDD SSSSSSSSS GETWORD SETWORD D,S/#,#0..1 -- -- --MS 1001101 ff I CCCC DDDDDDDDD SSSSSSSSS ROLNIB ROLBYTE ROLWORD SETS D,S/# -- -- -- -- --MS 1001110 ff I CCCC DDDDDDDDD SSSSSSSSS SETD SETCOND SETINST THALT D,S/# -- -- -- -- -CMS 1001111 0C I CCCC DDDDDDDDD SSSSSSSSS WAITCNT D,S/# -C --MS 1001111 10 I CCCC DDDDDDDDD SSSSSSSSS <empty> PICKZC D,S/# -- -- --MS 101000n nf I CCCC DDDDDDDDD SSSSSSSSS GETBYTE SETBYTE D,S/#,#0..3 -- -- --WS 1010010 ff I CCCC DDDDDDDDD SSSSSSSSS SETBYTS MOVBYTS PACKRGB UNPKRGB D,S/# -- -- -- -- --MS 1010011 ff I CCCC DDDDDDDDD SSSSSSSSS ADDPIX MULPIX BLNPIX MIXPIX D,S/# -- -- -- -- ZCMS 1010100 ZC I CCCC DDDDDDDDD SSSSSSSSS JMPSW D,S/@ ZC ZCMS 1010101 ZC I CCCC DDDDDDDDD SSSSSSSSS JMPSWD D,S/@ ZC --MS 1010110 ff I CCCC DDDDDDDDD SSSSSSSSS DJZ DJZD DJNZ DJNZD D,S/@ -- -- -- -- --RS 1010111 ff I CCCC DDDDDDDDD SSSSSSSSS JZ JZD JNZ JNZD D,S/@ -- -- -- -- ZCRS 10110ff ZC I CCCC DDDDDDDDD SSSSSSSSS TESTB TESTN TEST CMP D,S/# ZC ZC ZC ZC ZCRS 10111ff ZC I CCCC DDDDDDDDD SSSSSSSSS CMPX CMPS CMPSX CMPR D,S/# ZC ZC ZC ZC -CRS 11000fn nC I CCCC DDDDDDDDD SSSSSSSSS WAITPEQ WAITPNE D,S/#,#0..3 -C -C ---S 110010f nn I CCCC nnnnnnnnn SSSSSSSSS WAITVID WAITVID #0..$DFF,S/# | D,S/# -- -- --LS 110011f fL I CCCC DDDDDDDDD SSSSSSSSS WRBYTE WRWORD WRLONG WRWIDEM D/#,S/PTRA/PTRB -- -- -- -- --LS 110100f fL I CCCC DDDDDDDDD SSSSSSSSS WRAUX WRAUXR SETACCA SETACCB D/#,S/#0..$FF/PTRX/PTRY || D/#,S/# -- -- -- -- --LS 110101f fL I CCCC DDDDDDDDD SSSSSSSSS MACA MACB MUL32 MUL32U D/#,S/# -- -- -- -- --LS 110110f fL I CCCC DDDDDDDDD SSSSSSSSS DIV32 DIV32U DIV64 DIV64U D/#,S/# -- -- -- -- --LS 110111f fL I CCCC DDDDDDDDD SSSSSSSSS SQRT64 QSINCOS QARCTAN QROTATE D/#,S/# -- -- -- -- --LS 111000n nL I CCCC DDDDDDDDD SSSSSSSSS CFGPINS cfgpins cfgpins SETMAP D/#,S/#,#0..2 ||| D/#,S/# -- -- -- -- --LS 111001f fL I CCCC DDDDDDDDD SSSSSSSSS SETSERA SETSERB SETCTRS SETWAVS D/#,S/# -- -- -- -- --LS 111010f fL I CCCC DDDDDDDDD SSSSSSSSS SETFRQS SETPHSS ADDPHSS SUBPHSS D/#,S/# -- -- -- -- --LS 111011f fL I CCCC DDDDDDDDD SSSSSSSSS SETXFR SETMIX COGRUN COGRUNX D/#,S/# -- -- -- -- --LS 111100f fL I CCCC DDDDDDDDD SSSSSSSSS FRAC LODINDS CIRINDA CIRINDB D/#,S/# -- -- -- -- --LS 111101f fL I CCCC DDDDDDDDD SSSSSSSSS JP JPD JNP JNPD D/#,S/@ -- -- -- -- --WS 111110f ff I CCCC DDDDDDDDD SSSSSSSSS LOCBASE LOCBYTE LOCWORD LOCLONG D,S/@ -- -- -- -- --W- 1111101 00 f CCCC DDDDDDDDD sssssssss LOCINST JMPLIST D,@s -- -- ---- 1111101 01 0 BBAA ddddddddd sssssssss FIXINDA FIX/SET #s|#d|#d,#s -- ---- 1111101 01 1 nnnn nnnnnnnnn nnniiiiii REPS #1..$10000,#1..64 -- ---- 1111101 1f n nnnn nnnnnnnnn nnnnnnnnn AUGS AUGD #23bits -- -- ---- 1111110 00 0 CCCC ff nnnnnn nnnnnnnnn LOCPTRA LOCPTRA LOCPTRB LOCPTRB #abs | @rel | #abs | @rel -- -- -- -- ---- 1111110 00 1 CCCC ff nnnnnn nnnnnnnnn JMP JMP JMPD JMPD #abs | @rel | #abs | @rel -- -- -- -- ---- 1111110 01 0 CCCC ff nnnnnn nnnnnnnnn LINK LINK LINKD LINKD {0} #abs | {0} @rel | {0} #abs | {0} @re -- -- -- -- ---- 1111110 01 1 CCCC ff nnnnnn nnnnnnnnn CALL CALL CALLD CALLD #abs | @rel | #abs | @rel -- -- -- -- ---- 1111110 10 0 CCCC ff nnnnnn nnnnnnnnn CALLA CALLA CALLAD CALLAD #abs | @rel | #abs | @rel -- -- -- -- ---- 1111110 10 1 CCCC ff nnnnnn nnnnnnnnn CALLB CALLB CALLBD CALLBD #abs | @rel | #abs | @rel -- -- -- -- ---- 1111110 11 0 CCCC ff nnnnnn nnnnnnnnn CALLX CALLX CALLXD CALLXD #abs | @rel | #abs | @rel -- -- -- -- ---- 1111110 11 1 CCCC ff nnnnnn nnnnnnnnn CALLY CALLY CALLYD CALLYD #abs | @rel | #abs | @rel -- -- -- -- ---------------------------------------------------------------------------------------------------------------------------- ZCW- 1111111 ZC 0 CCCC DDDDDDDDD 0000000ff COGID TASKID LOCKNEW GETLFSR D ZC ZC ZC ZC ZCW- 1111111 ZC 0 CCCC DDDDDDDDD 0000001ff GETCNT GETCNTX GETACAL GETACAH D ZC ZC ZC ZC ZCW- 1111111 ZC 0 CCCC DDDDDDDDD 0000010ff GETACBL GETACBH GETPTRA GETPTRB D ZC ZC ZC ZC ZCW- 1111111 ZC 0 CCCC DDDDDDDDD 0000011ff GETPTRX GETPTRY SERINA SERINB D ZC ZC ZC ZC ZCW- 1111111 ZC 0 CCCC DDDDDDDDD 0000100ff GETMULL GETMULH GETDIVQ GETDIVR D ZC ZC ZC ZC ZCW- 1111111 ZC 0 CCCC DDDDDDDDD 0000101ff GETSQRT GETQX GETQY GETQZ D ZC ZC ZC ZC ZCW- 1111111 ZC 0 CCCC DDDDDDDDD 0000110ff GETPHSA GETPHZA GETCOSA GETSINA D ZC ZC ZC ZC ZCW- 1111111 ZC 0 CCCC DDDDDDDDD 0000111ff GETPHSB GETPHZB GETCOSB GETSINB D ZC ZC ZC ZC ZCM- 1111111 ZC 0 CCCC DDDDDDDDD 0001000ff PUSHZC POPZC SUBCNT GETPIX D ZC ZC ZC ZC ZCM- 1111111 ZC 0 CCCC DDDDDDDDD 0001001ff BINBCD BCDBIN BINGRY GRYBIN D ZC ZC ZC ZC ZCM- 1111111 ZC 0 CCCC DDDDDDDDD 0001010ff ESWAP4 ESWAP8 SEUSSF SEUSSR D ZC ZC ZC ZC ZCM- 1111111 ZC 0 CCCC DDDDDDDDD 0001011ff SPLITB MERGEB SPLITW MERGEW D ZC ZC ZC ZC ZCM- 1111111 ZC 0 CCCC DDDDDDDDD 0001100ff CHKDEC CHKHEX CHKLET CHKSYM D ZC ZC ZC ZC ZCM- 1111111 ZC 0 CCCC DDDDDDDDD 0001101ff INCD DECD INCDS DECDS D ZC ZC ZC ZC ZCW- 1111111 ZC 0 CCCC DDDDDDDDD 0001110ff POPT0 POPT1 POPT2 POPT3 D ZC ZC ZC ZC ZCW- 1111111 ZC 0 CCCC DDDDDDDDD 0001111ff POP <empty> INCPAT DECPAT D ZC ZC ZC ZC ---------------------------------------------------------------------------------------------------------------------------- --L- 1111111 00 L CCCC DDDDDDDDD 0100000ff CLKSET COGSTOP LOCKSET LOCKCLR D/# -- -- -C -C --L- 1111111 00 L CCCC DDDDDDDDD 0100001ff LOCKRET RDWIDE RDWIDEC RDWIDEQ D/# | D/PTRA/PTRB -- -- -- -- ZCL- 1111111 ZC L CCCC DDDDDDDDD 0100010ff GETP GETNP SEROUTA SEROUTB D/# ZC ZC -C -C -CL- 1111111 0C L CCCC DDDDDDDDD 0100011ff CMPCNT WAITPX WAITPR WAITPF D/# -C -C -C -C --L- 1111111 ZC L CCCC DDDDDDDDD 0100100ff COGNEW COGNEWX SETXCH SETTASK {D} D/# || D/# ZC ZC -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0100101ff SETRACE SARACCA SARACCB SARACCS D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0100110ff SETPTRA SETPTRB ADDPTRA ADDPTRB D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0100111ff SUBPTRA SUBPTRB SETWIDE SETWIDZ D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0101000ff SETPTRX SETPTRY ADDPTRX ADDPTRY D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0101001ff SUBPTRX SUBPTRY PASSCNT WAIT D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0101010ff OFFP NOTP CLRP SETP D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0101011ff SETPC SETPNC SETPZ SETPNZ D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0101100ff DIV64D SQRT32 QLOG QEXP D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0101101ff SETQI SETQZ CFGDACS SETDACS D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0101110ff CFGDAC0 CFGDAC1 CFGDAC2 CFGDAC3 D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0101111ff SETDAC0 SETDAC1 SETDAC2 SETDAC3 D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0110000ff SETCTRA SETWAVA SETFRQA SETPHSA D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0110001ff ADDPHSA SUBPHSA SETVID SETVIDY D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0110010ff SETCTRB SETWAVB SETFRQB SETPHSB D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0110011ff ADDPHSB SUBPHSB SETVIDI SETVIDQ D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0110100ff SETPIX SETPIXZ SETPIXU SETPIXV D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0110101ff SETPIXA SETPIXR SETPIXG SETPIXB D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0110110ff SETPORA SETPORB SETPORC SETPORD D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0110111ff RDWIDEA RDWIDEB WRWIDEA WRWIDEB D/#1..512 -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0111000ff TARGOFF TARG TARGP TARGN D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0111001ff targoff TARGX TARGPX TARGNX D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0111010ff JMPT0 JMPT1 JMPT2 JMPT3 D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0111011ff PUSHT0 PUSHT1 PUSHT2 PUSHT3 D/# -- -- -- -- --L- 1111111 00 L CCCC DDDDDDDDD 0111100ff PUSH SETZC SETLFSR D/# -- ZC -- ---------------------------------------------------------------------------------------------------------------------------- --R- 1111111 00 x CCCC DDDDDDDDD 1000000ff LOCPTRA LOCPTRB JMP JMPD D -- -- ZC ZC --R- 1111111 ZC x CCCC DDDDDDDDD 1000001ff LINK LINKD CALL CALLD {0} D || D ZC ZC ZC ZC --R- 1111111 ZC x CCCC DDDDDDDDD 1000010ff CALLA CALLAD CALLB CALLBD D ZC ZC ZC ZC --R- 1111111 ZC x CCCC DDDDDDDDD 1000011ff CALLX CALLXD CALLY CALLYD D ZC ZC ZC ZC --R- 1111111 00 x CCCC DDDDDDDDD 1000100ff LODINDA LODINDB D -- -- ---------------------------------------------------------------------------------------------------------------------------- ZC-- 1111111 ZC x CCCC xxxxxxxxx 1100000ff RETA RETAD RETB RETBD ZC ZC ZC ZC ZC-- 1111111 ZC x CCCC xxxxxxxxx 1100001ff RETX RETXD RETY RETYD ZC ZC ZC ZC ZC-- 1111111 ZC x CCCC xxxxxxxxx 1100010ff RET RETD POLCTRA POLCTRB ZC ZC ZC ZC ZC-- 1111111 ZC x CCCC xxxxxxxxx 1100011ff POLVID CAPCTRA CAPCTRB CAPCTRS ZC -- -- -- ---- 1111111 00 x CCCC xxxxxxxxx 1100100ff SETPIXW CLRACCA CLRACCB CLRACCS -- -- -- -- ZC-- 1111111 ZC x CCCC xxxxxxxxx 1100101ff CHKPTRX CHKPTRY SYNCTRA SYNCTRB ZC ZC -- -- ---- 1111111 00 x CCCC xxxxxxxxx 1100110ff DCACHEX ICACHEX ICACHEP ICACHEN -- -- -- -- ---- 1111111 00 x 0000 xxxxxxxxx 1100111ff TLOCK TFREE LOADT3 SAVET3 -- -- -- -- ---- 1111111 00 x 0000 xxxxxxxxx 1101000ff TARGOFF TARG TARGP TARGN -- -- -- -- ---- 1111111 00 x 0000 xxxxxxxxx 1101001ff targoff TARGX TARGPX TARGNX -- -- -- -- ---- 1111111 00 x 0000 xxxxxxxxx 1101010ff PASSTXA PASSTXB <empty> <empty> -- -- -- -- ---------------------------------------------------------------------------------------------------------------------------- ---- 0000000 00 0 0000 000000000 000000000 NOP -- ----------------------------------------------------------------------------------------------------------------------------InstructionSummary_20140320.spinI'm totally with you. I love Spin for all the reasons you sited. It's simple and quick to get started with, especially for non-expreience programmers. Having integerated PASM makes transitioning to assembler a doddle. The PASM syntax and P1 architecture are the simplest nicest assembly language programming environment I have ever seen. And so on.
I am not advocating breaking Spin/PASM, especially not for the P1.
So imagine the PII is out for two years and there are now a couple of hundred objects with assembly language drivers in the OBEX and floating around the forum. tens of thousands of man hours of work will have gone into creating them. They will have been written in both Spin and C.
Problem is those juicy assembler language drivers, are not usable between languages. Which seems kind of crazy and wasteful. Getting such code into peoples hands easily is what the Propeller ecosystem thrives on. It should be made friction free.
That is the problem we are discussing here. Perhaps you do not feel that is a problem.
One solution is my proposal for breaking the linkage between PASM and Spin by introducing the "PASM" section and a few simple rules around it. I don't believe this is a big hardship for Spin users. Most new users would probably accept the new syntax and not even notice the semantic differences.
Another solution is Roy's answer, get the tools to do the work. Open spin may be able to expose what linkage there is between PASM and Spin in such a way that C programmers could easily use the PASM binaries extracted from Spin objects.
Does that solution help going the other way? Assembler language drivers written by C programmers migrating to Spin programs ?
My feeling is that the "no-linkage" binary blob approach is the most universal way.
These ideas are worthy of more exploration. Or do we just let the problem persist into the PII world?
However, I'm sure a mode of writing Spin and PASM code could be formalized, as has already been brought up here, that would enable inter-operability with C.
I totally agree. No stifling for me. I'm stifled enough already.
But there we have a contradiction, yes a mode of writing Spin and PASM code could be formalized, it would also be totally ignored by those "unstifled" programmers who don't know and/or care why there is such a formalism. We can almost be sure this will happen as such a formalism has been discussed on the P1 forum for years and even documented by RossH. It has all been ignored.
Would the introduction of a "PASM" section be stifling? Or just a neat way to organize code in the spirit of the Spin language?
It is already possible to do this - but so difficult that few bother to do so.
Ross.
But that difficulty is what makes it not so appealing, isn't it?
I know you listed a few things that would have to be done. Would you mind listing them here (again) so that they could be contemplated? I know this stuff exists in another post, or posts. The simpler you can keep the guidelines, the better we can think about it.
1) Introduce a PASM section. This is basically a DAT section with some extra rules...
2) Any PASM code to be launched into a COG has to be in a PASM section.
3) Code in a PASM section cannot access any variables defined in Spin, VAR blocks or DAT sections, by name. This removes dependency of PASM from Spin data layout.
4) Spin code cannot write any locations in a PASM section, at least by name. This prevents initializing of LONGs and such prior to loading to COG. Data that C or other languages would not know about.
5) Due to 4) all parameters passed to PASM prior to launch go through pointers passed via PAR.
6) All communication between a running PASM code and Spin go through shared HUB as normal, using pointers passed through PAR.
The basic idea is to decouple the PASM and Spin. Then the PASM can be compiled and extracted as a usable "binary blob" or "firmware" by openspin or BST etc and used in other language systems.
This is not to onerous is it? It's even good practice, makes for nice clean code. In the same way a Spin object cannot see a sub-objects variables or PRI's.
Note: This works both ways. Such "binary blobs" created by C or whatever can be used in Spin by including them via a file statement. It's a win-win.
You mean force right?
Yes discussions in the past got overly complex what with mailboxes, registries, etc. What is proposed here though is dead simple.
RossH has indeed converted drivers, he is not all talk. Others have done so as well. Even I adapted a couple of drivers back in the Zog C days. We don't want to do that again, and again, and again.
I also really don't want PASM and SPIN separate. That is not what is being proposed here.
Gas has nothing to do with this. It's not in the picture. That's for the C guys to suffer
The nice expressive DAT section can remain. The proposed PASM section is a DAT section, all the same expressive cool ways to express data remain in there.
Getting over most of the difficulties and complexities could be done with a few simple conventions, plus a few simple changes or extensions to SPIN/PASM. For instance (this is just the first one that springs to mind) - why does a Spin object have to have at least one PUB segment to compile? All this does is force you to include a dummy method, which generates code that has to later be stripped out when all you want is the compiled PASM.
Heater has already summarized some of the conventions. I'll try and put a few more together this weekend and post them for wider discussion. I'd suggest we start a new thread (perhaps Heater would like to do so, since he started the discussion) so as not to clutter this one unduly.
Ross.
The whole idea of a binary blob for PASM is obsolete. We have HUBEXEC now.
Does anyone here really want to tell me that my hubexec PASM code is not allowed to see my labels in HUB?
Honestly. This is HUMBUG.
Enjoy!
Mike
No, of course not. If you are creating PASM objects that are only intended to operate withing your own SPIN program, or with other SPIN programs, you are free to use whatever conventions you want - and the interface to such objects is generally a set of SPIN methods anyway, with the PASM code nicely encapsulated.
But sometimes you just want to submit a chunk of generally useful PASM code, exposing some other interface - and there is currently no way to do so. You have to wrap it in SPIN because that is currently the only accepted convention - we have no convention to enable that code to be called from any cog, unless that cog is running SPIN. This has nothing to do with C - this code cannot even be called from another cog within the same SPIN program that is running PASM!
Ross.
I'm in favor of doing that. Maybe we should just call the new section BLOB. And I'm serious! Leave SPIN as is today and add BLOB to the list of section definitions and behaviors. In the BLOB section, do these reuse things so that we make sure a BLOB works well. That's a good thing!
This:
Is true and precisely why DAT and how SPIN+PASM works right now needs to be left alone. A lot of things will be possible, and yes not all that easy to reuse, but again, that's not always the primary case. Frankly, I think Chip has already seen this in that Pnut doesn't currently require any SPIN at all to build. It can assemble only.
Adding BLOB would provide for that intent, and we could very easily publish a lot of good stuff for people to use in the BLOB section when they have the intent to publish for reuse, or where people do conversions. Since the result is MIT, if published for sharing here in the traditional way we've done, doing that stuff is not only encouraged, but expected.
Re: Not all talk.
Heater, of course! Ross has done a fine job as have others. I'm sorry I implied otherwise. Wasn't my intent.
Re: No other convention.
Right now, Pnut works without having a PUB of any kind. Pretty easy to have that continue. And it's got SPIN 2 in there, but it's early and kind of broken at the moment too.
We can make a nice BLOB on P2 right now. If that isn't changed, would it not work for this purpose? One could use DAT in whatever way makes sense, and if Chip sees the core rules for a BLOB section and implements them, wouldn't that more or less reach the goals everyone has here?
Perhaps this discussion is really early, save for the idea of the BLOB section specifically intended for reuse, both directions even. If we do that, we could then package up something in C and bring it over. All good.
Adding something to SPIN for this purpose is good. We need it. Preventing things isn't something I'm a fan of, for reasons already given.
msrobots is right about it too. With HUBEX, making PASM BLOBS is not always going to happen now. And the unified SPIN+PASM is perfect for how HUBEX will end up working. Which, by the way, is precisely why I'm vocal about this right now.
And that means making a BLOB is something people will have a specific intent to do, which makes an addition aimed at making that happen nicely perfectly sensible.
Seriously, how about we work to define BLOB so that it's a total win for the reuse case? Split the middle, so to speak.
I like the BLOB way
Suggestion:
I think that is all we really need.
It could export an object file, with the first long encoding relative par&start in the fashion COGRUN/COGRUNX needs.
NOTE:
Normal current expected Spin/Pasm would not change at all.
Suggestion:
New Obex category - BLOBS
I don't know what any of You need possibility of ASSEMBLE without invoke SPIN part.
BUT I need that to that type of programing.
' Portable Low Type Driver ' I don't know what You will call it. DAT orgh @XXX DriveTable jmp @Init jmp @SD_read_sector jmp @SD_read_Dir jmp @SD_write_sector jmp @SD_write_Dir ......... and so on ret ...... end table Init xxx xxx,xxx ret SD_read_sector xxx xxx,xxx ret SD_read_Dir xxx xxx,xxx ret SD_write_sector xxx xxx,xxx ret SD_write_Dir xxx xxx,xxx retNope,
BLOB = Binary Large Object
or
BLOB = Blitter Object
http://www.acronymfinder.com/BLOB.html
http://en.wikipedia.org/wiki/Binary_large_object
However I think BLOB is actually a better name for that new Spin section than my suggested PASM.
Why, because PII will have inline PASM and hub exec PASM which I don't think should be included in this scheme.
Parallax would not be the first one to reference loadable... Like you say, it's a good fit anyway.
I mean the basic syntax and how DAT works.
Heater, sorry ... I do not agree ... perhaps is due to my lack of knowledge.
Take a class for example. I don' t want to introduce classes/istances as their real meaning, it is only an example of a file that exists in the ide, part of the project.
In classes you declare properties, methods and these are exposed to other part of program. Classes on the development system are files on the filesystem, with a known structure, part of the project.
Now if a pasm section instead of residing in dat will be a class (not in its real meaning, just in the way it is written) some longs can be properties. This mean they will be saved with a known structure. Spin can initialize these longs because they are exposed as properties. The same can happen for C.
A pasm "class" can be imported in a spin project or in a c project.
Perhaps you can even mix all. If you have a pasm class , a spin class a c class perhaps pasm and c can run natively while c-xmm and spin will be executed through their kernel/interpreter in a separate cog and they can communicate to each-other through the exposed properties, well known for everyone of them or better said well known for the ide that have to compile/link/assemble it with the right tools. Inside every single kind of class the rules will pretty remain the same for every single language. The only difference is that one class can be only written in one language.
You can have a project choice (spin/pasm/c) that defines the primary application language. Than classes can be of any choice (spin/pasm/c/forth ...) and everything cooperates.
Why can't this concept work?
Now change the name, don't call it class ... it was to explain the idea with my poor english.
I have been tiling and painting at my son's house all day
ozpropdev and I have both been working on p2 debuggers - different but complimentary. I expect theremay be others too later.
What ifthey could be simply hooked (by a single command) into the monitor. This way our code could become extensions to the monitor.
Thoughts ?
Seems to me, having the monitor check the very first two longs or maybe even the first one of HUB RAM for a signature and address, a debug package could just be uploaded right through whatever terminal people use. Have it always check this when a command is entered that isn't one of it's own, and if the package is there, pass the current command and address to it, and the user is off to the races.
The upload can be a file copy to the serial port, or a paste through the terminal. Either way, the package can specify those or that long, then any other addresses and data needed to place whatever extension makes sense, where it makes sense.
Early on, I was making heavy use of the copy / paste function to upload lots of data, and it worked very well. The way addresses work is either one specifies an address with a line of data, or a colon ":" and that makes relocating things, or even just specifying where things go super easy. The package would specify the low address long, or longs, then specify a start address, all the data for the package, another start address, all the data, if desired, etc...
A simple copy package.txt > COM8 gets it done! (documented in the monitor PDF, which I will update this time around)
BTW, doing this wouldn't really require HUBEX mode. It's just simpler.
Another thing: If that same check is always done in the monitor, a person who wants the integrated debugger can just include it, parking it at whatever address they feel makes sense given how their program works, then launch the monitor on a COG as part of their ordinary program startup too.
One question: How would an extension understand multiple monitors could be running, and do we care?
Amiga blitter objects was called BOBs.
And this:
So long as the current function of DAT is unchanged, adding the BLOB scheme with the intent of helping to create reusable PASM is good. Otherwise, ALL PASM should remain as is in DAT, including that PASM targeted at a COG.