Slowly this ship turns in the right direction. @ersmith is the fore runner, I fight with TAQOZ to get it cooperative (and finally @"Peter Jakacki" is helping me to do that, what a wonderful thing) Now getting Chip on board, YES the multi language P2.
+ 1, this is looking very promising. Could be a great step forward.
One-time-use boot code is going to be at the very start of memory. I don't think it will ever need to run twice. It might as well clean up after itself (setq+wrlong from cog) and open up a nice little buffer. And it's very convenient if the buffer starts at $00000 and it goes to some 2^n-1 address.
There's no conflict with that idea. These special reserved locations are really only reserved for the boot-up code. After they've served the parameter passing purpose you don't have to keep them reserved.
But they do need to be agreed upon. The earlier, the better.
Not as worried about where the various booters read their arguments once for setting up the initial clkfreq/mode, but after the init is done I do like the end result of keeping the first 64 bytes free for mailbox or other use without having any holes in the middle of that block. 8 COGs * 2 longs/COG for mailbox request/args = 64 bytes like Chip is talking about. It could be nice after bootup to have the "official" CLKFREQ/MODE values get stored at 0x40 and 0x44 to allow this space. Obviously only the SPIN booter should really ever need to clear out this memory once at reset, and we don't want it cleared on any later SPIN invocation by other languages.
Keeping things free higher up in the immediate accessible low memory for vectors above 0x60 (or perhaps it would now be 0x68) allows expansion of the SPIN2 language as well. Chip mentions up to 96 word vectors in his code, consuming memory from 0x40-0xff. I sort of see a possibility for putting in expanded vectors there for putch/getch type operations on stdin/stdout etc, or alternatively use some mailboxes for this - sort of like OS service calls. That may in future allow multiple COGs (potentially running different languages) to share code controlling a common resource like a serial port for debug output for example, or for passing data between them using pipes in shared memory etc, or even for requesting access to SD or FLASH blocks, though there are various ways to achieve this type of thing. We don't want to have to go invent a full OS for doing this right now, but just have the flexibility to support things like that later.
The only downside to doing changes in the vector area is that it might make the SPIN2 implementation a bit of a moving target over time. On the P1 the interpreter was locked into ROM and stayed fixed, but on the P2 it is now RAM based. That could become a problem with incompatibility if some SPIN2 objects depend on different versions/services of the SPIN2 interpreter. We may then need a getVersion() service call. Arrgh...No.
Talking about mailbox space is a red herring to agreeing on the addresses to use for these parameters. The two topics are independent with no conflict.
There's no conflict with that idea. These special reserved locations are really only reserved for the boot-up code. After they've served the parameter passing purpose you don't have to keep them reserved.
But they do need to be agreed upon. The earlier, the better.
The clock frequency and mode need to be in an agreed upon place whenever we hand off between languages, not just at boot time.
I give up. @cgracey will do whatever he wants, and I'll do whatever I want and TAQOZ will do what it always has (since it's in the ROM we can't change that). Interoperability would have been nice, but we had this discussion months ago and I thought we had agreed on a standard. Apparently not. c'est la vie, it's typical of the Propeller world that everyone goes off and does their own thing
I give up. @cgracey will do whatever he wants, and I'll do whatever I want and TAQOZ will do what it always has (since it's in the ROM we can't change that). Interoperability would have been nice, but we had this discussion months ago and I thought we had agreed on a standard. Apparently not. c'est la vie, it's typical of the Propeller world that everyone goes off and does their own thing
I feel your pain.
How many times have people tried to get a consensus on some thing or other- and ended up going their own way!
My guess is that no matter how good the various other tools are most Parallax customers will use what Chip creates. That seems to have been true for P1. We had lots of other tools but most people seemed to stick with the PropTool unless they ran on a platform other than Windows.
Guys, there has to be agreement on this. The flaw in the clock setting hardware means that not following a convention will create intermittent boot failures. There's no other way to head it off.
There's no conflict with that idea. These special reserved locations are really only reserved for the boot-up code. After they've served the parameter passing purpose you don't have to keep them reserved.
But they do need to be agreed upon. The earlier, the better.
The clock frequency and mode need to be in an agreed upon place whenever we hand off between languages, not just at boot time.
I give up. @cgracey will do whatever he wants, and I'll do whatever I want and TAQOZ will do what it always has (since it's in the ROM we can't change that). Interoperability would have been nice, but we had this discussion months ago and I thought we had agreed on a standard. Apparently not. c'est la vie, it's typical of the Propeller world that everyone goes off and does their own thing
No Eric, no, don't give up.
We are getting there. I even got TAQOZ on board. @"Peter Jakacki" is very helpful there and we soon have a 64K image without VGA and a $48800 image with VGA-Buffer included.
I hacked Spin2Gui with some more buttons to make integration painless. will post soon. Basically you will get a object usable from all FastSpin supported languages, gimme a couple of hours, I need to create two new TAQOZ images, Peter was busy.
So as of now, just trying to understand what is already locked into stone and can't possibly be altered to some new clkfreq/clkmode storage convention Chip may use accordingly? Isn't it just the ROM TAQOZ that can't change and uses its own clock setting method from particular addresses in the boot image or is something else as well? Is the problem now just that if ROM TAQOZ tries to exit (without reset) to run code compiled for any new boot standard that does further clock settings using different addresses that might break, or is there something else to this?
What else has been released yet in large volumes that couldn't be patched accordingly before the final P2 is released? It is the inconvenience of all various software changes or is there something else to this?
I do also agree that a convention is required, by the way. Just wondering about real impacts of any changes. Less worried about boot storage for each image (that's more of a tool issue but it would be nice if that was consistent too for something like loadp2), but very interested in a common runtime storage of these values, so code written in various languages could all read the same frequency long etc.
I'm actually quite amenable to making changes to suit. I don't know what the best way to do it is, but the worst way is not to have "a" way. TAQOZ in ROM should be regarded as a different animal though and primarily you can think of it as a hardware debugging tool or a sanity checker. Of course you can develop code for the P2 without any tools other than an editor and a terminal, so in a way it is a fallback.
However the TAQOZ module which is loaded into a corner of RAM is a different story, and while I'm shy to say "it's gotta be done this way", I am quite happy to work in with others. In the case of @msrobots it wasn't until he was wading in the muck that I started to get more involved (you know someone is serious when they get their hands dirty). I really admire the work that you do Eric and would love to help, so just tell me and I will see what I can do.
Debates I stay clear of though.
Aren't the hub read/write instructions limited to an 8-bit immediate address? It's best to stick with $0-$FF for easy and efficient to access locations. I won't give up location 0 though because that is the jump vector which is necessary for when I do a backup image so that when it resets or is powered up, it will just work. I'm not sure what mechanism Chip has for this......
BTW, I don't follow a lot of the discussions too closely otherwise I wouldn't get anything done, so most of the detail is lost on me.
How about $3f0-$3ff? Slot them in snugly right before first hubexec address. That's a little less arbitrary at least.
Another option is to go from 0xF0-0xFF which are immediate addressable. If the vector space then grew downwards from 0xF0 instead of upwards from 0x40 you might keep the maximum contiguous space free from 0x0-0xN for as long as possible. Though the downside is this 0xN value might potentially change over time which isn't good. The 0x40 and up approach does at least guarantee to save you some 64 byte fixed space below it for all time, which could be very good for general mailbox or other uses. Ideally all 256 lowest bytes could be kept free for general purpose use allowing fast complete 8 bit table lookups etc, but that probably does not work out with SPIN interpreter's memory footprint and keeping it all below 4k which is a laudable goal too.
By the way, these 16 bit SPIN vectors imply that any further SPIN language hub extensions can only fit in the lowest 64kB too. Perhaps using a 32 bit address for each was deemed wasteful and would halve the vector space available to 48, but it would at least allow code or custom overrides to be located anywhere in HUB RAM.
Aren't the hub read/write instructions limited to an 8-bit immediate address? It's best to stick with $0-$FF for easy and efficient to access locations.
Good point, bugger.
I won't give up location 0 though because that is the jump vector which is necessary for when I do a backup image so that when it resets or is powered up, it will just work. I'm not sure what mechanism Chip has for this......
Yes, first longword is fixed as the first instruction. Prop_Hex and Prop_Txt both do a COGINIT to #0.
I would have choosen addresses $04-$0f for the parameters myself, but I don't see any good reason to move the parameters away from existing $10-$1f.
Well yes, but I like the idea about keeping runtime frequency/clkmode parameters at well known addresses so that code written in say C as well as code written in SPIN can be written to access the same value after the system is booted. It becomes useful when you have a system that includes code developed using multiple tools/languages, not just SPIN only, or just C only for example. If each language has knowledge of these special locations it will be be simpler to co-ordinate if the values ever have to be changed after bootup.
All this red-herring talk is a red-herring for me too LOL!
I'm actually quite amenable to making changes to suit. I don't know what the best way to do it is, but the worst way is not to have "a" way. TAQOZ in ROM should be regarded as a different animal though and primarily you can think of it as a hardware debugging tool or a sanity checker. Of course you can develop code for the P2 without any tools other than an editor and a terminal, so in a way it is a fallback.
However the TAQOZ module which is loaded into a corner of RAM is a different story, and while I'm shy to say "it's gotta be done this way", I am quite happy to work in with others. In the case of @msrobots it wasn't until he was wading in the muck that I started to get more involved (you know someone is serious when they get their hands dirty). I really admire the work that you do Eric and would love to help, so just tell me and I will see what I can do.
Debates I stay clear of though.
And I did.
And that is EXACTLY a example why chip should stick to it. I currently mash FastSpin and TAQOZ together. And I CAN change the clock speed in FastSpin, while TAQOZ runs in another COG, STILL a 56 BLINK blinks in the same frequency as before. Because they agree about those settings.
Load/boot time is all that really matters. Beyond that is asking way too much of community cohesiveness.
Perhaps you might be right there @evanh with everyone's different opinions, though I'd sort of hope not if now is an opportunity to resolve it.
Seems there are two issues to sort out:
1) where the bootup parameters used for frequency/clock mode are to be written into the image. This impacts tools that generate these images and the values the booter code reads and initializes the HW to.
2) choice of addresses where operational runtime values holding the current frequency/mode are to be kept. This impacts operational code running after initialisation.
Decisions for 1) can make things inconvenient for tools such as loadp2 if such addresses are different and would cause tools to begin to fragment for different images/applications.
Decisions for 2) can hinder interoperability between code written in different languages if they start to use different addresses for holding these values, and potentially cause this clock mode setting problem to happen if one language's code changes the clock state regardless of reading the existing state made by another language's code for example. This becomes an issue when you might want to have SPIN routines called by some C or Python code etc.
Choices for 2) can also impact free memory availability in low memory if these clock settings end up also being stored there somewhere as is being discussed by Chip. Having as much low memory free for other purposes beyond simply storing clock frequencies is a good thing, particularly starting at address zero which is special, either for table use, mailbox use, whatever people may wish to use it for down the line. This is why I've talked about it. And in the worst case if both 1) and 2) somehow end up being maintained at the same addresses it might limit a nice block of contiguous zero-based immediate memory you can rely on having in the P2.
Guys, I don't want to drive any of you to despair. I just need to have the freedom at this stage to sculpt things optimally, in order to maintain sufficient motivation to get Spin2 working. I'm kind of tired at this stage. I think once Spin2 is working, I'll get a burst of energy. I need to get there.
Once Spin2 is working, it can easily be modified and reformed to work in any fashion.
Eric may choose to employ the final Spin2 syntax into his compiler and provide the fastest execution possible. It's up to him. It's harder for me to envision how some compiled language aggregator is going to pull different code together and make it all play. Seems rather O.S.-level. Maybe I can think about that later.
1) The location of the clockfreq and current mode. The first is a requirement by almost every program. Otherwise you cannot do any timing!! The clock mode is required if the clockfreq needs changing. This second part is problematic from the point that all running programs will need to be coded to permit such a change. While this is dangerous, at least knowing the current mode bits permits a change. Without these bits, P2 lockup is likely!!
2) A dedicated mailbox area. This is most definitely not a red-herring and should be agreed sooner rather than later. It is a sort of OS feature. Consider this...
Peter writes a VGA routine for a cog.
Msrobots writes a FullDuplexSerial routine for a cog.
Rayman writes an HDMI routine for a cog.
Gary writes a USB routine for a cog.
Cluso (me) writes a simple OS for a cog.
Fred writes a PS2 Keyboard routine for a cog.
Everyone has a different way of interfacing their object (just like we are proposing now).
How can we use each of these objects together? Without forking each of these objects, we can’t !!!
Now, if we agreed upon a minimum mailbox, all these objects could work together provided they adhered to the mailbox.
This would mean the OS, and other programs could use the mailbox to dynamically use the desired objects.
In my P1 OS, all std I/O goes via the mailbox. The OS always writes to the STDOUT and reads from STDIN. The OS does not need to know if FullDuplexSerial or VGA or TV (composite video) or USB or some new driver is being used as the STDOUT object. Similarly, it takes input from the STDIN mailbox, which could be from FullDuplexSerial or USB or PS2 Keyboard or some future object.
My OS has some additional parameters which do CRLF or just CR, knows the screen size in rows by columns (used for output formatting in a LS or DIR command), ECHO, and a couple of other parameters.
None of this is possible without an agreed mailbox!!! Evan, this is definately not a red-herring. I know, because in P1 I had to fork all those objects that I use to make them work.
Postedit
BTW None of this forces anyone to comply. I would expect commercial P2 users to just do their own thing, like we/they do on P1.
I also use Catalina’s mailboxes to communicate with my objects in a commercial P1 product.
Comments
+ 1, this is looking very promising. Could be a great step forward.
Not as worried about where the various booters read their arguments once for setting up the initial clkfreq/mode, but after the init is done I do like the end result of keeping the first 64 bytes free for mailbox or other use without having any holes in the middle of that block. 8 COGs * 2 longs/COG for mailbox request/args = 64 bytes like Chip is talking about. It could be nice after bootup to have the "official" CLKFREQ/MODE values get stored at 0x40 and 0x44 to allow this space. Obviously only the SPIN booter should really ever need to clear out this memory once at reset, and we don't want it cleared on any later SPIN invocation by other languages.
Keeping things free higher up in the immediate accessible low memory for vectors above 0x60 (or perhaps it would now be 0x68) allows expansion of the SPIN2 language as well. Chip mentions up to 96 word vectors in his code, consuming memory from 0x40-0xff. I sort of see a possibility for putting in expanded vectors there for putch/getch type operations on stdin/stdout etc, or alternatively use some mailboxes for this - sort of like OS service calls. That may in future allow multiple COGs (potentially running different languages) to share code controlling a common resource like a serial port for debug output for example, or for passing data between them using pipes in shared memory etc, or even for requesting access to SD or FLASH blocks, though there are various ways to achieve this type of thing. We don't want to have to go invent a full OS for doing this right now, but just have the flexibility to support things like that later.
The only downside to doing changes in the vector area is that it might make the SPIN2 implementation a bit of a moving target over time. On the P1 the interpreter was locked into ROM and stayed fixed, but on the P2 it is now RAM based. That could become a problem with incompatibility if some SPIN2 objects depend on different versions/services of the SPIN2 interpreter. We may then need a getVersion() service call. Arrgh...No.
The clock frequency and mode need to be in an agreed upon place whenever we hand off between languages, not just at boot time.
I give up. @cgracey will do whatever he wants, and I'll do whatever I want and TAQOZ will do what it always has (since it's in the ROM we can't change that). Interoperability would have been nice, but we had this discussion months ago and I thought we had agreed on a standard. Apparently not. c'est la vie, it's typical of the Propeller world that everyone goes off and does their own thing
I feel your pain.
How many times have people tried to get a consensus on some thing or other- and ended up going their own way!
Must admit- I'm not immune...
Dave
No Eric, no, don't give up.
We are getting there. I even got TAQOZ on board. @"Peter Jakacki" is very helpful there and we soon have a 64K image without VGA and a $48800 image with VGA-Buffer included.
I hacked Spin2Gui with some more buttons to make integration painless. will post soon. Basically you will get a object usable from all FastSpin supported languages, gimme a couple of hours, I need to create two new TAQOZ images, Peter was busy.
Mike
What else has been released yet in large volumes that couldn't be patched accordingly before the final P2 is released? It is the inconvenience of all various software changes or is there something else to this?
I do also agree that a convention is required, by the way. Just wondering about real impacts of any changes. Less worried about boot storage for each image (that's more of a tool issue but it would be nice if that was consistent too for something like loadp2), but very interested in a common runtime storage of these values, so code written in various languages could all read the same frequency long etc.
However the TAQOZ module which is loaded into a corner of RAM is a different story, and while I'm shy to say "it's gotta be done this way", I am quite happy to work in with others. In the case of @msrobots it wasn't until he was wading in the muck that I started to get more involved (you know someone is serious when they get their hands dirty). I really admire the work that you do Eric and would love to help, so just tell me and I will see what I can do.
Debates I stay clear of though.
BTW, I don't follow a lot of the discussions too closely otherwise I wouldn't get anything done, so most of the detail is lost on me.
Another option is to go from 0xF0-0xFF which are immediate addressable. If the vector space then grew downwards from 0xF0 instead of upwards from 0x40 you might keep the maximum contiguous space free from 0x0-0xN for as long as possible. Though the downside is this 0xN value might potentially change over time which isn't good. The 0x40 and up approach does at least guarantee to save you some 64 byte fixed space below it for all time, which could be very good for general mailbox or other uses. Ideally all 256 lowest bytes could be kept free for general purpose use allowing fast complete 8 bit table lookups etc, but that probably does not work out with SPIN interpreter's memory footprint and keeping it all below 4k which is a laudable goal too.
By the way, these 16 bit SPIN vectors imply that any further SPIN language hub extensions can only fit in the lowest 64kB too. Perhaps using a 32 bit address for each was deemed wasteful and would halve the vector space available to 48, but it would at least allow code or custom overrides to be located anywhere in HUB RAM.
Yes, first longword is fixed as the first instruction. Prop_Hex and Prop_Txt both do a COGINIT to #0.
I would have choosen addresses $04-$0f for the parameters myself, but I don't see any good reason to move the parameters away from existing $10-$1f.
By the way I was talking about runtime storage not boot storage, in case we are on different topics.
All this red-herring talk is a red-herring for me too LOL!
And I did.
And that is EXACTLY a example why chip should stick to it. I currently mash FastSpin and TAQOZ together. And I CAN change the clock speed in FastSpin, while TAQOZ runs in another COG, STILL a 56 BLINK blinks in the same frequency as before. Because they agree about those settings.
And @cgracey should too.
Mike
Perhaps you might be right there @evanh with everyone's different opinions, though I'd sort of hope not if now is an opportunity to resolve it.
Seems there are two issues to sort out:
1) where the bootup parameters used for frequency/clock mode are to be written into the image. This impacts tools that generate these images and the values the booter code reads and initializes the HW to.
2) choice of addresses where operational runtime values holding the current frequency/mode are to be kept. This impacts operational code running after initialisation.
Decisions for 1) can make things inconvenient for tools such as loadp2 if such addresses are different and would cause tools to begin to fragment for different images/applications.
Decisions for 2) can hinder interoperability between code written in different languages if they start to use different addresses for holding these values, and potentially cause this clock mode setting problem to happen if one language's code changes the clock state regardless of reading the existing state made by another language's code for example. This becomes an issue when you might want to have SPIN routines called by some C or Python code etc.
Choices for 2) can also impact free memory availability in low memory if these clock settings end up also being stored there somewhere as is being discussed by Chip. Having as much low memory free for other purposes beyond simply storing clock frequencies is a good thing, particularly starting at address zero which is special, either for table use, mailbox use, whatever people may wish to use it for down the line. This is why I've talked about it. And in the worst case if both 1) and 2) somehow end up being maintained at the same addresses it might limit a nice block of contiguous zero-based immediate memory you can rely on having in the P2.
as usual you are right. At this stage all could switch to another agreed standard location, but it should stay there, then.
Mike
Once Spin2 is working, it can easily be modified and reformed to work in any fashion.
Eric may choose to employ the final Spin2 syntax into his compiler and provide the fastest execution possible. It's up to him. It's harder for me to envision how some compiled language aggregator is going to pull different code together and make it all play. Seems rather O.S.-level. Maybe I can think about that later.
1) The location of the clockfreq and current mode. The first is a requirement by almost every program. Otherwise you cannot do any timing!! The clock mode is required if the clockfreq needs changing. This second part is problematic from the point that all running programs will need to be coded to permit such a change. While this is dangerous, at least knowing the current mode bits permits a change. Without these bits, P2 lockup is likely!!
2) A dedicated mailbox area. This is most definitely not a red-herring and should be agreed sooner rather than later. It is a sort of OS feature. Consider this...
Peter writes a VGA routine for a cog.
Msrobots writes a FullDuplexSerial routine for a cog.
Rayman writes an HDMI routine for a cog.
Gary writes a USB routine for a cog.
Cluso (me) writes a simple OS for a cog.
Fred writes a PS2 Keyboard routine for a cog.
Everyone has a different way of interfacing their object (just like we are proposing now).
How can we use each of these objects together? Without forking each of these objects, we can’t !!!
Now, if we agreed upon a minimum mailbox, all these objects could work together provided they adhered to the mailbox.
This would mean the OS, and other programs could use the mailbox to dynamically use the desired objects.
In my P1 OS, all std I/O goes via the mailbox. The OS always writes to the STDOUT and reads from STDIN. The OS does not need to know if FullDuplexSerial or VGA or TV (composite video) or USB or some new driver is being used as the STDOUT object. Similarly, it takes input from the STDIN mailbox, which could be from FullDuplexSerial or USB or PS2 Keyboard or some future object.
My OS has some additional parameters which do CRLF or just CR, knows the screen size in rows by columns (used for output formatting in a LS or DIR command), ECHO, and a couple of other parameters.
None of this is possible without an agreed mailbox!!! Evan, this is definately not a red-herring. I know, because in P1 I had to fork all those objects that I use to make them work.
Postedit
BTW None of this forces anyone to comply. I would expect commercial P2 users to just do their own thing, like we/they do on P1.
I also use Catalina’s mailboxes to communicate with my objects in a commercial P1 product.
Personally I’d like to see the whole 256 bytes reserved, with the mailbox and clock parameters working down from $FF.