I think the supposition that @@@ is needed might stem from some misunderstaning or even ignorance of what @ does. Minimal conveyance of @ values is required if you understand what's going on and plan things out a little.
Sorry if I sound bitter on the whole triple @ and OpenSpin stuff, it's just that I did a ton of work porting Chip's x86 code and almost no one uses it.
Parallax never found the time or resources to integrate it into PropTool (even though I did all the changes needed to make it fairly easy).
So, like 99% of people just use PropTool for P1, and the rest mostly use something else that's not OpenSpin. There are a few of you, thanks, but the amount of effort that went into it feels wasted to me.
I still don't understand by Parallax didn't just get behind Eric's work and make that the official compiler for both P1 and P2. Just work with and pay him to do a byte code backend variant for Spin2's interpreter. It does Spin, Spin2, C, and BASIC for both P1 and P2. Seems like a really good choice.
I find that the way it works currently in FastSpin is very convenient. I think it took Eric a few days to get it the way it is now...
If it can't or won't be made to work that way in Spin2, that's OK, but just adds some extra work for the programmer...
Eric's compiler produces PASM to be run in hubexec. It's a whole different animal compared to how Chip's compiler works.
I think the supposition that @@@ is needed might stem from some misunderstaning or even ignorance of what @ does. Minimal conveyance of @ values is required if you understand what's going on and plan things out a little.
Sorry Chip and Roy...
But I recall that there was no other way around the problem. I just don't recall the circumstances now, or what program it was. That was a major reason for bst and homespun coming into existence, plus of course conditional compilation and code inclusion. There was a big thread devoted to the discussion and the alternatives were not viable.
bst and homespun implemented conditional compilation in subtle but different ways - IIRC it was the ways a sub-object was passed a conditional parameter. They also implemented file inclusion (ie code included in a file to be used inline within existing pasm) slightly differently.
And sorry Roy, since we had bst and homespun, together with the lack of Parallax backing, OpenSpin never really got used mainstream
As I recall, BST and homespun appeared well before triple @. They added it by request. They were not made to give triple @ as you imply.
Also, if you can't recall what it was used for or why it was needed, that tells me it must not have been that important. There was nothing at all in the entire OBEX that used it when I was using that to test OpenSpin.
I think it was one of the BASIC compilers that produced Spin code as output and then compiled it with BST that used it, but that source was never shared that I know of. Also, it most certainly could have produced different Spin code that didn't need triple @. It was a freaking compiler.
It's ALWAYS possible to calculate the absolute address of something in P1 memory if you know at least it's relative address (which you always do). I think the "no other way" must include a provision that is without having to calculate it at run time (which you can always do).
@@@ does what you expect @ or @@ to do but gets it right. That is is it gives the physical, actual, real HUB address of something. It works when initializing data in DAT sections, unlike the others. It gives the same result no matter where you use it, unlike @.
HomeSpun works on Linux under the mono runtime. It even works on Raspberry Pi and other ARM machines.
So, yeah, it existed first, then added triple @ later. like I said.
Also, you can initialize DAT data at runtime and calculate whatever you need. Nothing said there = "no other way"
It was the false requirement that DATs be initialized at compile time that makes it "no other way"
@@@ operator
A little further research reveals it's use heavily in P1 LMM code to pass the hub address to the calling code. I looks like it was a cornerstone in the LMM as used by PropGCC.
While PropGCC will not need to use LMM as we have hubexec, I would still expect that PropGCC will require the absolute address of code/variables in hub.
It was used in spin2cpp where an example was used in a DAT block listing hub addresses of strings. (spin2cpp-3.6.4 file exec12.spin)
Tachyon at one stage used @@@. Not sure if it does now.
Pullmoll used it in his Nascom video emulator and his VT100 where he used it to find the address of the font tables.
It was used in the SpinLMM Interpreter Version 1.0" (Dave Hein, Tim Moore, Cluso99, Bill Henning, jazzed, Bean)
Typical use...
if_nz jmp #FJMP '!W
long @@@boolnot
jBb if_c rdlong lmm_pc, lmm_pc 'lockclr/lockset?
long @@@jA_lock
rdlong reg12, boot_pc
long @@@muny3a
etc
Also heavily used in Pumllmoll's QZ80 including the io.spin for large lists of hub address pointers
ramaddr_ptr long @@@ramaddr
output_port_ptr long @@@output_port_table ' list of output ports and corresponding function
input_port_ptr long @@@input_port_table ' list of input ports and corresponding function
simh_cmd_ptr long @@@simh_cmd_table
simh_params long @@@simh_params_ ' pointer to the simh io buffer
hdsk_cmd_ptr long @@@hdsk_cmd_table
hdsk_lba_drives long @@@lba_drive_a
hdsk_drive long @@@hdsk_drive_ ' parameters of read/write command
hdsk_sector long @@@hdsk_sector_
hdsk_track long @@@hdsk_track_
hdsk_dma long @@@hdsk_dma_
hdsk_dpb_0 long @@@hdsk_dpb_0_
hdsk_dpb_1 long @@@hdsk_dpb_1_
hdsk_dpb_2 long @@@hdsk_dpb_2_
And heater's ZiCog Z80 emulator again for table lists in hub
dispatch_tab_cb_addr long @@@dispatch_table_cb
dispatch_tab_dd_addr long @@@dispatch_table_dd
dispatch_tab_ddcb_addr long @@@dispatch_table_ddcb
dispatch_tab_ed_addr long @@@dispatch_table_ed
and...
{00}daa_lmm_ long @@@daa_lmm
{01}ldi_lmm_ long @@@ldi_lmm
{02}cpi_lmm_ long @@@cpi_lmm
{03}ini_lmm_ long @@@ini_lmm
{04}outi_lmm_ long @@@outi_lmm
{05}ldd_lmm_ long @@@ldd_lmm
PropGCC doesn't use Spin to compile it's output as far as I know, so I have no idea how it could use @@@. It's compiles to PASM or LMM PASM with a premade PASM kernel. There's no Spin compiler involved, unless maybe they used it to make the kernel blob? I find it hard to believe that could not be made without @@@.
Anyway, being used heavily in a few things doesn't mean it was required and there was no other way. It was available so they sued it. I would argue that because they had it available they designed their stuff around it. if they didn't have it available they would have design it another way.
Still nothing says there was "no other way"
Also, based on what Chip has said about Spin2 and how it works, it sounds like @@@ is counter to that and is probably unlikely to be done in Chip's Spin2 compiler. Just use Fastspin or whatever GCC comes along.
Maybe convince Chip to give you the compiler x86 source so you can figure out a way to put @@@ in there without breaking other things.
Has anybody tried a jump into hubexec code in spin2?
What does the @ operator return in this mode? Maybe it could be made to return absolute addresses in this case?
This is something that did not exist in Spin1...
Yes, regularly in almost every P2 program, but i have done it using an immediate where i defined the address as a constant equate.
I call the ROM (top of hub) serial monitor routines this way. Same for the SD routines.
Short version,
I don't think Chip needs to put triple @ in Spin2. If you really need it and want it, help add it. Or just use FastSpin if it gives you what you need.
(edit, he hasn't shared the compiler source, but I hope he does, so you all can see how it works and it's not like you think it does)
I can imagine, x86 assembler and single letter labels...
So, yeah, it existed first, then added triple @ later. like I said.
Also, you can initialize DAT data at runtime and calculate whatever you need. Nothing said there = "no other way"
It was the false requirement that DATs be initialized at compile time that makes it "no other way"
That was exactly the reason for triple @, else you need to calculate it at runtime and can not initialize DAT data at compile time with a correct HUB address.
so instead of
DAT
ramaddr_ptr long @@@ramaddr
you have to
DAT
ramaddr_ptr long 0
.. somewhere in code
ramaddr_ptr:=@ramaddr
I find that the way it works currently in FastSpin is very convenient. I think it took Eric a few days to get it the way it is now...
If it can't or won't be made to work that way in Spin2, that's OK, but just adds some extra work for the programmer...
Not really OK, it means there are two Spin's out there that are NOT compatible.
That's the kiss of death for commercial usage, if a new and very niche language cannot even adhere to an agreed standard, it will be avoided.
A language written by one person in x86 assembler in 2020, will also raise lifetime eyebrows. and what manager would sign off on that ?
Surely Chip could have written this in Delphi, even if not mainstream ? Chip already knows that, and it is far more portable than x86 asm.
"Kiss of death?" Maybe if they were both called Spin2. But in addition to different names and different authors, they're fundamentally different in how they work. Like Roy said, "Eric's compiler produces PASM to be run in hubexec. It's a whole different animal compared to how Chip's compiler works." To the degree that nifty expressions from each can be incorporated into the other, great. But a world that can't allow both to exist would be silly, and poorer too. Vive la différence.
At this stage, I feel very strongly about there being different tools. It's a good thing. When Chip gets it finalized, perhaps there is a common subset that can be written to more universally.
I like FastSpin a lot. About the only thing I desire, and I understand Eric's objection, is being able to use ORGH to just specify an address explicitly, like to build memory images in advance of runtime. Big deal. It can be done other ways. In all other respects, the approach in FastSpin makes a lot of sense and has multi-language support. I've already used that and it's awesome!
We could call that the advanced, or other named tool and be good to go. Many people will jump in, that will all feel familiar, and no worries. Parallax, given some sales and ability to take on something else financially, could do a number of things, none of which need to be connected to what Chip is doing.
What Chip is doing is a bit different. He's got a specific vision and it's been in his head for a decade or more. Given how awesome Parallax has been, this great adventure, and all that, I also feel Chip needs to just build it.
One outcome of that will be an on-chip, self-hosted system that will very likely feature amazing code density, while also allowing in-line assembly and some new object features people have wanted forever. Another outcome may well be an environment that makes a ton of sense and that blazes some new trails too. Bring it.
The comments about P2 replacing micro-computers are a sort of niche. I share that desire, and do not believe it's necessary for whatever Chip authors to fully comply with that sense of things. And as Roy said, the tools can be modified once they are in whatever mix of SPIN and PASM they end up in too. They will be modified too. Might even be someone new stumbles in and goes to town on some vision they have.
As for "commercial sign offs", it's not like the industry hasn't seen the decade long saga, right? Right.
This chip is a playground. It shines in assembly language. And it's going to take a good long time for a robust set of libraries to expose most of that functionality, and even when they do, this chip just flat out works differently.
The equation on that has always been the same too: When it just works differently, one either goes with that to get the advantages, or passes it all along, and there isn't any real amount of wrapper code and such that will have an impact. Good libraries will, and as I said, those will come, but will also take a while. One reason for that is it will simply take a while to sort out those use cases and how best to do and generalize them enough to make sense!
Finally, on that "commercial sign off", FastSpin isn't written in assembly language, and it can be compiled on a broad enough set of platforms to make total commercial sense. No one going down that road needs to even know or care about anything Chip does. The same can be said for anything Parallax might choose to do.
The way I see it, a lot of money got spent, we all were invited on the ride, treated as peers, valued for our support, suggestions and it lead to real silicon that looks exemplary. Now, it's time to watch Chip do something he wants to do on the P2.
Who knows? You might end up liking it, same as you did the last time he did this kind of thing.
There are some differences right now, but less and less.
for example Chip is using
ORG
END
now for inline-pasm blocks, and added a (internal use) ret.
so it almost looks like
ASM
ENDASM
of fastspin.
still a difference, Chip is running the PASM in a cog in cogexec mode and his org can have a parameter since inline-pasm in spin2 runs in the interpreter Cog at $167 or whatever in opposite to fastspin where it is compiled to hubexec.
ARM Thump Mode has also different instruction as to not compressed.
So compact Spin via fast Spin, Basically the same language, but slightly different when using compact Spin versus fast Spin.
I can live with that, we just need to convince chip to put those #ifdef … things into the proptool/pnut versions, that would help a lot to write code that runs on both platforms.
I can live with that, we just need to convince chip to put those #ifdef … things into the proptool/pnut versions, that would help a lot to write code that runs on both platforms.
Yeah, I agree with that. Would help with the library growth over time.
Maybe, when it's "done", in Prop Tool, a pre-processor of some kind can be bolted on. Also, maybe the self-hosted, PASM + SPIN version won't need to have it, or a similar thing won't be too much of a burden. Or maybe a filter can distill whatever is needed too.
What's the absolute minimum needed? (I'm asking, because I just don't know and wonder what kind of super small, brutally simple thing could do the job here.)
So compact Spin via fast Spin
That is precisely how I see it. Over the years, Chip has returned to code density a lot of times. Witness the spiffy SKIPF, XBYTE and the impact that had on COG and various interpreter code! (novel, and powerful) On P1, the balance was really good. We didn't have HUBEXEC, but everything else worked great. On P2, pure SPIN should compete with and likely exceed P1 PASM.
Given our experiences so far, it's fast and compact spin and FASTersmithSPIN, lol
And it's going to take a good long time for a robust set of libraries to expose most of that functionality...
The longer that takes, the slower sales will be to those who have not used the Propeller. I've met engineers who say a lack of libraries is a deal-breaker and won't even consider a new chip without them, despite interesting features.
Yeah, true enough. Hopefully, people using it now can / will share. That all helps.
And I guess libraries boil down into two rough groups:
One is the standard stuff. Filesystems, I/O, math, etc...
The other would be more specialized things, basically packaging up the more advanced features.
And maybe it won't take as long as we may think. To me, there are things people know need to get done, and they know how to do them. Maybe that doesn't need to be the absolute best case, just working well. The harder ones are where how the chip works needs to play out some as people try things, push it. Once there is resonance on that, libraries can follow reasonably, or the code out there is good enough to work with anyway.
Video / audio might make good examples.
On the standard end: Display a bitmap, allow for various operations, clear, change buffer address, colors, start, stop, mode, resolution, etc... Same for character drivers, and looks like Rayman got a P1 style display done at high resolution. (that display format is super useful) rologh is doing an advanced one.
Audio same: Play sound, bit rate, buffer, start, stop, etc... ahle is doing an advanced one.
More than one way to look at this too.
In the basic sense, just having a lot of standard libraries is pretty awesome on this chip, because they can all work together fairly easily. This is the P1 model with much more capability / flexibility. That all may happen fairly quick. If the main task doesn't take a zillion COGS, using standard libraries will be pretty easy. And that means people get cool stuff done easy.
The advanced things will come, and may end up libraries, may not. Who knows? But as that all progresses, people will get amazingly cool stuff done. Maybe after that, more people get it done easy.
I don't want to come off too grim. In my mind, it's nothing like that. We already have more options than P1 had for a long time. And already we can see the difference. An HDMI bitmap is crazy small PASM.
And not to get off track, but I think Chip can build what he has been noodling on for a decade and not impact all this that much.
And not to get off track, but I think Chip can build what he has been noodling on for a decade and not impact all this that much.
With respect, I think he should focus on library creation. The only way to move lots of chips -- which Parallax needs to do after the cost and length of development -- is to provide the tools that let those new to the Propeller come up to speed and be productive very quickly.
> @JonnyMac said:
> And not to get off track, but I think Chip can build what he has been noodling on for a decade and not impact all this that much.
>
>
>
> With respect, I think he should focus on library creation. The only way to move lots of chips -- which Parallax needs to do after the cost and length of development -- is to provide the tools that let those new to the Propeller come up to speed and be productive very quickly.
I agree. I'm getting the Spin2 compiler tuned up and then I'll work on objects.
Cool. I knocked together a simple (not fds) Spin2 serial object so I can play with the language. I have a lot of catching up to do.
I'll get it all documented soon.
Tonight I'm adding constant-expression resolving into the compiler, so that things like '56 addpins 7' in Spin2 code automatically resolve to a single constant, instead of multiple constants with operators. This is going to make things smaller and faster. In Spin1 we had CONSTANT for forcing this, but now it will always be attempted for all Spin2 expressions.
I've been wanting to do this for a long time, and realized tonight that I had all the pieces in place. I just needed to put them together.
it is nice when finally all comes together. Kind of relaxing to lean back and say - good for now, because it is not finite like your Verilog, you can tweak it later on.
But you are now, like with the P1, the one who has to write the basic objects -especially with that send command, and lay a base of how things work. Leave the high end video stuff to @rogloh, that's covert. @garryj has USB covert.
What is needed is the really basic stuff SPI,I2C,PWM in and out, Quad Encoder, SD, FLASH, HYPERRAM (same sort of file access?) written in Spin, maybe as snippets not full blown objects.
This Goertzel thing needs some object, no other chip I know of has a Goertzel!
And with all the hype, a classic p1 style keyboard would be nice, w/o usb and such.
A good way to go forward would be a deep look into PropTools Libraries. go thru them and make all easy ones them P2 ready.
I mentioned it somewhere else already but if SPIN2 would allow those very useful #ifdef... thingies, one source code could be used for P1 and P2 and Spin2 and FastSpin…
So when upgrading PropTool please think about to integrate a optional preprocessor to allow that.
Re: libraries
This is why I'm a big advocate (well, relatively quietly, so maybe not so much 'advocate' ) for the spin-standard-library that somebody within Parallax...or maybe it was a forum member, not sure, started years ago. From time to time this same topic comes up here or on the P1 forum, "It would be great if there was a gold-standard library of objects", or something to that effect. I agree wholeheartedly. Since discovering it, I've forked it on github and tried over the last few years to maintain it and expand on it with new drivers. I think to have a chance at succeeding, it or something like it really has to be cohesive: interfaces to objects should be largely the same (i.e., every temperature sensor, or display, or ADC, etc should have as much of a common API as possible so it doesn't feel like 1000 different people wrote 1000 different objects 1000 completely different ways, even though they all essentially do the same thing). Even little things like the object file naming. The OBEX is great for finding that object that wrings every last cycle or long out of a cog, but the library ought to be a compromise that has a collection of objects that work consistently, even if they're not necessarily the very fastest or most efficient. It wouldn't stop the more experienced people from going off and doing their own thing - it would just be one more step in making it easier for newcomers to Prop to get started.
Also +1000 on the basic preprocessor - this has been a huge help in OpenSpin and FastSpin!
Comments
Parallax never found the time or resources to integrate it into PropTool (even though I did all the changes needed to make it fairly easy).
So, like 99% of people just use PropTool for P1, and the rest mostly use something else that's not OpenSpin. There are a few of you, thanks, but the amount of effort that went into it feels wasted to me.
I still don't understand by Parallax didn't just get behind Eric's work and make that the official compiler for both P1 and P2. Just work with and pay him to do a byte code backend variant for Spin2's interpreter. It does Spin, Spin2, C, and BASIC for both P1 and P2. Seems like a really good choice.
Eric's compiler produces PASM to be run in hubexec. It's a whole different animal compared to how Chip's compiler works.
Sorry Chip and Roy...
But I recall that there was no other way around the problem. I just don't recall the circumstances now, or what program it was. That was a major reason for bst and homespun coming into existence, plus of course conditional compilation and code inclusion. There was a big thread devoted to the discussion and the alternatives were not viable.
bst and homespun implemented conditional compilation in subtle but different ways - IIRC it was the ways a sub-object was passed a conditional parameter. They also implemented file inclusion (ie code included in a file to be used inline within existing pasm) slightly differently.
And sorry Roy, since we had bst and homespun, together with the lack of Parallax backing, OpenSpin never really got used mainstream
Also, if you can't recall what it was used for or why it was needed, that tells me it must not have been that important. There was nothing at all in the entire OBEX that used it when I was using that to test OpenSpin.
I think it was one of the BASIC compilers that produced Spin code as output and then compiled it with BST that used it, but that source was never shared that I know of. Also, it most certainly could have produced different Spin code that didn't need triple @. It was a freaking compiler.
It's ALWAYS possible to calculate the absolute address of something in P1 memory if you know at least it's relative address (which you always do). I think the "no other way" must include a provision that is without having to calculate it at run time (which you can always do).
Here is a link to what may be the first post of homespun (2008-09-09)
https://forums.parallax.com/discussion/106401/homespun-spin-compiler-0-31-now-open-source
You will note that the first code change listed was "v0.16 added the @@@ operator". Unfortunately the wikispaces link is gone.
And a 2013 post by you following discussion of the @@@ requirement...
https://forums.parallax.com/discussion/comment/1187176/#Comment_1187176 and it's reply
And a post from heater...
Also, you can initialize DAT data at runtime and calculate whatever you need. Nothing said there = "no other way"
It was the false requirement that DATs be initialized at compile time that makes it "no other way"
A little further research reveals it's use heavily in P1 LMM code to pass the hub address to the calling code. I looks like it was a cornerstone in the LMM as used by PropGCC.
While PropGCC will not need to use LMM as we have hubexec, I would still expect that PropGCC will require the absolute address of code/variables in hub.
It was used in spin2cpp where an example was used in a DAT block listing hub addresses of strings. (spin2cpp-3.6.4 file exec12.spin)
Tachyon at one stage used @@@. Not sure if it does now.
Pullmoll used it in his Nascom video emulator and his VT100 where he used it to find the address of the font tables.
It was used in the SpinLMM Interpreter Version 1.0" (Dave Hein, Tim Moore, Cluso99, Bill Henning, jazzed, Bean)
Typical use...
if_nz jmp #FJMP '!W long @@@boolnot jBb if_c rdlong lmm_pc, lmm_pc 'lockclr/lockset? long @@@jA_lock rdlong reg12, boot_pc long @@@muny3a etcAlso heavily used in Pumllmoll's QZ80 including the io.spin for large lists of hub address pointers And heater's ZiCog Z80 emulator again for table lists in hub
dispatch_tab_cb_addr long @@@dispatch_table_cb dispatch_tab_dd_addr long @@@dispatch_table_dd dispatch_tab_ddcb_addr long @@@dispatch_table_ddcb dispatch_tab_ed_addr long @@@dispatch_table_ed and... {00}daa_lmm_ long @@@daa_lmm {01}ldi_lmm_ long @@@ldi_lmm {02}cpi_lmm_ long @@@cpi_lmm {03}ini_lmm_ long @@@ini_lmm {04}outi_lmm_ long @@@outi_lmm {05}ldd_lmm_ long @@@ldd_lmmAnyway, being used heavily in a few things doesn't mean it was required and there was no other way. It was available so they sued it. I would argue that because they had it available they designed their stuff around it. if they didn't have it available they would have design it another way.
Still nothing says there was "no other way"
Also, based on what Chip has said about Spin2 and how it works, it sounds like @@@ is counter to that and is probably unlikely to be done in Chip's Spin2 compiler. Just use Fastspin or whatever GCC comes along.
Maybe convince Chip to give you the compiler x86 source so you can figure out a way to put @@@ in there without breaking other things.
https://github.com/rosco-pc/propeller-wiki/wiki/Homespun-Spin-Compiler
What does the @ operator return in this mode? Maybe it could be made to return absolute addresses in this case?
This is something that did not exist in Spin1...
Yes, regularly in almost every P2 program, but i have done it using an immediate where i defined the address as a constant equate.
I call the ROM (top of hub) serial monitor routines this way. Same for the SD routines.
Of course, we've been doing pure PASM code for a long time...
I can imagine, x86 assembler and single letter labels...
Mike
That was exactly the reason for triple @, else you need to calculate it at runtime and can not initialize DAT data at compile time with a correct HUB address.
so instead of you have to
Mike
Not really OK, it means there are two Spin's out there that are NOT compatible.
That's the kiss of death for commercial usage, if a new and very niche language cannot even adhere to an agreed standard, it will be avoided.
A language written by one person in x86 assembler in 2020, will also raise lifetime eyebrows. and what manager would sign off on that ?
Surely Chip could have written this in Delphi, even if not mainstream ? Chip already knows that, and it is far more portable than x86 asm.
At this stage, I feel very strongly about there being different tools. It's a good thing. When Chip gets it finalized, perhaps there is a common subset that can be written to more universally.
I like FastSpin a lot. About the only thing I desire, and I understand Eric's objection, is being able to use ORGH to just specify an address explicitly, like to build memory images in advance of runtime. Big deal. It can be done other ways. In all other respects, the approach in FastSpin makes a lot of sense and has multi-language support. I've already used that and it's awesome!
We could call that the advanced, or other named tool and be good to go. Many people will jump in, that will all feel familiar, and no worries. Parallax, given some sales and ability to take on something else financially, could do a number of things, none of which need to be connected to what Chip is doing.
What Chip is doing is a bit different. He's got a specific vision and it's been in his head for a decade or more. Given how awesome Parallax has been, this great adventure, and all that, I also feel Chip needs to just build it.
One outcome of that will be an on-chip, self-hosted system that will very likely feature amazing code density, while also allowing in-line assembly and some new object features people have wanted forever. Another outcome may well be an environment that makes a ton of sense and that blazes some new trails too. Bring it.
The comments about P2 replacing micro-computers are a sort of niche. I share that desire, and do not believe it's necessary for whatever Chip authors to fully comply with that sense of things. And as Roy said, the tools can be modified once they are in whatever mix of SPIN and PASM they end up in too. They will be modified too. Might even be someone new stumbles in and goes to town on some vision they have.
As for "commercial sign offs", it's not like the industry hasn't seen the decade long saga, right? Right.
This chip is a playground. It shines in assembly language. And it's going to take a good long time for a robust set of libraries to expose most of that functionality, and even when they do, this chip just flat out works differently.
The equation on that has always been the same too: When it just works differently, one either goes with that to get the advantages, or passes it all along, and there isn't any real amount of wrapper code and such that will have an impact. Good libraries will, and as I said, those will come, but will also take a while. One reason for that is it will simply take a while to sort out those use cases and how best to do and generalize them enough to make sense!
Finally, on that "commercial sign off", FastSpin isn't written in assembly language, and it can be compiled on a broad enough set of platforms to make total commercial sense. No one going down that road needs to even know or care about anything Chip does. The same can be said for anything Parallax might choose to do.
The way I see it, a lot of money got spent, we all were invited on the ride, treated as peers, valued for our support, suggestions and it lead to real silicon that looks exemplary. Now, it's time to watch Chip do something he wants to do on the P2.
Who knows? You might end up liking it, same as you did the last time he did this kind of thing.
for example Chip is using
ORG
END
now for inline-pasm blocks, and added a (internal use) ret.
so it almost looks like
ASM
ENDASM
of fastspin.
still a difference, Chip is running the PASM in a cog in cogexec mode and his org can have a parameter since inline-pasm in spin2 runs in the interpreter Cog at $167 or whatever in opposite to fastspin where it is compiled to hubexec.
ARM Thump Mode has also different instruction as to not compressed.
So compact Spin via fast Spin, Basically the same language, but slightly different when using compact Spin versus fast Spin.
I can live with that, we just need to convince chip to put those #ifdef … things into the proptool/pnut versions, that would help a lot to write code that runs on both platforms.
Mike
Yeah, I agree with that. Would help with the library growth over time.
Maybe, when it's "done", in Prop Tool, a pre-processor of some kind can be bolted on. Also, maybe the self-hosted, PASM + SPIN version won't need to have it, or a similar thing won't be too much of a burden. Or maybe a filter can distill whatever is needed too.
What's the absolute minimum needed? (I'm asking, because I just don't know and wonder what kind of super small, brutally simple thing could do the job here.)
That is precisely how I see it. Over the years, Chip has returned to code density a lot of times. Witness the spiffy SKIPF, XBYTE and the impact that had on COG and various interpreter code! (novel, and powerful) On P1, the balance was really good. We didn't have HUBEXEC, but everything else worked great. On P2, pure SPIN should compete with and likely exceed P1 PASM.
Given our experiences so far, it's fast and compact spin and FASTersmithSPIN, lol
And I guess libraries boil down into two rough groups:
One is the standard stuff. Filesystems, I/O, math, etc...
The other would be more specialized things, basically packaging up the more advanced features.
And maybe it won't take as long as we may think. To me, there are things people know need to get done, and they know how to do them. Maybe that doesn't need to be the absolute best case, just working well. The harder ones are where how the chip works needs to play out some as people try things, push it. Once there is resonance on that, libraries can follow reasonably, or the code out there is good enough to work with anyway.
Video / audio might make good examples.
On the standard end: Display a bitmap, allow for various operations, clear, change buffer address, colors, start, stop, mode, resolution, etc... Same for character drivers, and looks like Rayman got a P1 style display done at high resolution. (that display format is super useful) rologh is doing an advanced one.
Audio same: Play sound, bit rate, buffer, start, stop, etc... ahle is doing an advanced one.
More than one way to look at this too.
In the basic sense, just having a lot of standard libraries is pretty awesome on this chip, because they can all work together fairly easily. This is the P1 model with much more capability / flexibility. That all may happen fairly quick. If the main task doesn't take a zillion COGS, using standard libraries will be pretty easy. And that means people get cool stuff done easy.
The advanced things will come, and may end up libraries, may not. Who knows? But as that all progresses, people will get amazingly cool stuff done. Maybe after that, more people get it done easy.
I don't want to come off too grim. In my mind, it's nothing like that. We already have more options than P1 had for a long time. And already we can see the difference. An HDMI bitmap is crazy small PASM.
And not to get off track, but I think Chip can build what he has been noodling on for a decade and not impact all this that much.
> And not to get off track, but I think Chip can build what he has been noodling on for a decade and not impact all this that much.
>
>
>
> With respect, I think he should focus on library creation. The only way to move lots of chips -- which Parallax needs to do after the cost and length of development -- is to provide the tools that let those new to the Propeller come up to speed and be productive very quickly.
I agree. I'm getting the Spin2 compiler tuned up and then I'll work on objects.
I'll get it all documented soon.
Tonight I'm adding constant-expression resolving into the compiler, so that things like '56 addpins 7' in Spin2 code automatically resolve to a single constant, instead of multiple constants with operators. This is going to make things smaller and faster. In Spin1 we had CONSTANT for forcing this, but now it will always be attempted for all Spin2 expressions.
I've been wanting to do this for a long time, and realized tonight that I had all the pieces in place. I just needed to put them together.
it is nice when finally all comes together. Kind of relaxing to lean back and say - good for now, because it is not finite like your Verilog, you can tweak it later on.
But you are now, like with the P1, the one who has to write the basic objects -especially with that send command, and lay a base of how things work. Leave the high end video stuff to @rogloh, that's covert. @garryj has USB covert.
What is needed is the really basic stuff SPI,I2C,PWM in and out, Quad Encoder, SD, FLASH, HYPERRAM (same sort of file access?) written in Spin, maybe as snippets not full blown objects.
This Goertzel thing needs some object, no other chip I know of has a Goertzel!
And with all the hype, a classic p1 style keyboard would be nice, w/o usb and such.
A good way to go forward would be a deep look into PropTools Libraries. go thru them and make all easy ones them P2 ready.
I mentioned it somewhere else already but if SPIN2 would allow those very useful #ifdef... thingies, one source code could be used for P1 and P2 and Spin2 and FastSpin…
So when upgrading PropTool please think about to integrate a optional preprocessor to allow that.
I did run some tests and SPIN2 rocks!
Mike
This is why I'm a big advocate (well, relatively quietly, so maybe not so much 'advocate'
Also +1000 on the basic preprocessor - this has been a huge help in OpenSpin and FastSpin!
Cheers,
Jesse