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.
You can imagine then the motivation problem those of us who are volunteering our time feel sometimes too . I've been chasing a moving target for years now, and sometimes I really wonder if it's worth it.
I don't see much difference technically between putting the clock info at $10 and at $40. Technically I can live with either. But I've already changed this once after the last discussion (one thread is at https://forums.parallax.com/discussion/169697/rom-changes-for-next-silicon/, I think there are other threads too). You can forgive me if I can't get enthusiastic about changing it yet again, in all of the various tools I support (loadp2, fastspin, riscvp2, micropython, jit toolkit).
If everyone else agrees on a new location and it's not completely unreasonable then I certainly won't stand in the way and I'll be happy to accept pull requests to change it in the various tools. I won't provide any commitment to doing the work myself though, Not to say I won't, just that right now I can't commit to doing that work for free.
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.
I agree, both issues are important, but they are somewhat orthogonal. @Cluso99 , would you be up for starting a new thread to discuss mailboxes? I think it is an important discussion and shouldn't be buried somewhere else.
Eric,
Sure. It may take me a bit before I start the thread as I really need to be on my computer, not my iPad or iPhone. I am currently in the UK visiting our daughter and family so computer time is limited.
I have to say tho, ain’t the internet and phones/tablets great - I can travel half way around the world and still have full communications including remote access to my work and home computer, email and phone
I used to say computers changed the world, but IMHO they have nothing on the Internet!
I think a fixed mailbox area should begin at $00000 and end at either $0003F (1 long each for 16 potential cogs), $0007F (2 longs each), or $000FF (4 longs each).
It's not so much the fact that these addresses can be hard-coded that makes them attractive, as it is they begin at $00000 and can be indexed by cog ID. The need for these is very finite, so starting them at $00000 is convenient and simple. It also allows one-time boot code to clean up after itself and free up its hub memory, even pre-clearing the range to 0's, initializing the mailbox area.
Is one long per cog sufficient, or are two necessary? I think four are probably overkill. One each is nice and clean. Two might provide better full-duplex communications. Maybe one is good because it can just be used to point to a structure with some flexible purpose. I kind of think that would be best. That would take $00000..$0003F. The clock frequency and mode longs could immediately follow. That happens to be how the Spin2 intepreter is currently set up.
I think a fixed mailbox area should begin at $00000 and end at either $0003F (1 long each for 16 potential cogs), $0007F (2 longs each), or $000FF (4 longs each).
It's not so much the fact that these addresses can be hard-coded that makes them attractive, as it is they begin at $00000 and can be indexed by cog ID. The need for these is very finite, so starting them at $00000 is convenient and simple. It also allows one-time boot code to clean up after itself and free up its hub memory, even pre-clearing the range to 0's, initializing the mailbox area.
Is one long per cog sufficient, or are two necessary? I think four are probably overkill. One each is nice and clean. Two might provide better full-duplex communications. Maybe one is good because it can just be used to point to a structure with some flexible purpose. I kind of think that would be best. That would take $00000..$0003F. The clock frequency and mode longs could immediately follow. That happens to be how the Spin2 intepreter is currently set up.
I'm voting for 1 long per cog and if more than 1 long is needed just use as a pointer. I really hope everyone can agree on this since it seems the simplest and most efficient.
I suppose any downloaded TAQOZ code will have a dictionary that is updated by Peter and can be flexible with regards to CLKFREQ and CLKMODE locations. Would you concur, Peter? I think the TAQOZ in ROM is really for trying out TAQOZ, in concept, and for checking hardware functionality. A real mixed-language TAQOZ application would probably not rely on the ROM for anything.
As shown by peter a Mailbox could be used with one long, each word a channel.
But this is not the point here. Currently there is a agreement between all languages usable on the P2 to use those locations and you want to destroy that agreement, because you think mailboxes there would be nice.
Some major flaws in that. You are overwriting your own boot code, so even a soft reset will kill you.
There is no need at all to have mailboxes at 0-16 longs, none. mailboxes can sit (and do) anywhere in HUB you access them with rdlong, wrlong anyways so no need at all to have them in the first $1FF bytes.
Please Chip reconsider your plans.
What you are currently planning is to destroy all work others have done to gain WHAT exactly?
I think a fixed mailbox area should begin at $00000 and end at either $0003F (1 long each for 16 potential cogs), $0007F (2 longs each), or $000FF (4 longs each).
It's not so much the fact that these addresses can be hard-coded that makes them attractive, as it is they begin at $00000 and can be indexed by cog ID. The need for these is very finite, so starting them at $00000 is convenient and simple. It also allows one-time boot code to clean up after itself and free up its hub memory, even pre-clearing the range to 0's, initializing the mailbox area.
Is one long per cog sufficient, or are two necessary? I think four are probably overkill. One each is nice and clean. Two might provide better full-duplex communications. Maybe one is good because it can just be used to point to a structure with some flexible purpose. I kind of think that would be best. That would take $00000..$0003F. The clock frequency and mode longs could immediately follow. That happens to be how the Spin2 intepreter is currently set up.
Personally I'd be happy with your simplest approach, though I know there'll be others that may not. There are other several ways that mailboxes can work with request/reply message blocks etc but for any chance of interoperability I think we need something nailed down and even a single long per COG offers us some hope we can make it work.
We have two options here...either the mailboxes can go in low memory or a pointer to where they are located in memory has to be at some known address somewhere for a convention to apply. Given most low memory is already going to be used up for SPIN2 vectors followed by the SPIN2 interpreter we may wish to try to use the remaining gaps it affords us for storing useful things rather than waste it by leaving only a handful of discontiguous longs free. This includes the CLKFREQ/MODE and any other shared/global P2 state we'd need to track that we can't otherwise query directly from HW. It *could* include the mailbox (doesn't have to) OR at minimum a pointer to where this mailbox is in hub RAM to retain more free low memory for other uses.
Question: How can low memory offer a speed up for accessing the mailboxes? Is there any latency gain there in the code required?
Chip, I think some are overreacting, but all of us are concerned of course. I'm sure as the Beatles said that we can work it out. However, please please avoid location 0 for mailboxes as I need this location for a reset jump which can jump around to where-ever. So perhaps we could work out in the meantime the place for the clock config, frequency, and possibly the baud-rate too. This is part of my listing and really the ID and options area can go and we could move the clock configs up in the first 4 longs and start mailboxes from $10 or $20 even? BTW, location 0 gets corrupted by all kinds of bugs during testing. You never know, I could be sending all the wrong messages
There is another reason for wishing to keep special address 0 free by the way. In C if you have a NULL function pointer, it could jump to an exception handler you install there for this purpose of catching them...
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.
What about a fast booter/loader safely returning the clock mode to 20MHz (%00) on its own steam before it launches the app by doing a 'COGINIT #0,#0' ? Then, there'd be no boot problem, as there's no need for agreement.
What about storing the values like all other do and have the problem solved? The loader will need the old values to switch savely back to RCFAST, that was the reason for the agreement in the first place.
What about storing the values like all other do and have the problem solved? The loader will need the old values to switch back to RCFAST, that is the reason for the agreement.
Mike
But the loader can maintain its own record if it's using the PLL. Once it switches safely back to RCFAST, there's no need to convey the prior setting. At that point, the application program switches to some crystal mode and starts keeping its own record. An RCFAST hand-off doesn't require any last-set mode value.
Mailboxes can be placed anywhere we can agree upon. IIRC 4 longs made the most sense because each cog needs comms both ways. I will check it out next time i am online to my home computer.
While those hub $00-FF locations are fast, there is likely better things to go there! The may not be needed in every set of programs, but they do provide simple access and speed where it counts.
And of course, when not used for these special occasions, can have the $00 = JMP $ safety instruction.
The clockfreq and clockmode need to be in a common agreed location. Clockmode is only needed if the clockfreq needs to be changed. Changing this once set should be rare, if ever.
Clockfreq on the other hand, is used by almost all objects so it needs a fixed agreed location. Is there any place at the very top of hub just below the interrupt vectors???
In hindsight we could have has a special register(s) for this and more, sort of like setqx/getqx. Too late now.
An RCFAST hand-off doesn't require any last-set mode value.
I quite like that idea. Huh, so obvious now. I certainly wasn't happy requiring a convention in the first place.
Many users, I've noted though, having been expecting the loader to preset the sysclock, and using it for such ... but if that abbility was taken away and, maybe with some education, getting each program to always do their own setting might just be the best solution. First timer's don't have to worry about the flaw until they are wanting to readjust the PLL config.
Evan, this doesn’t resolve the fact that almost all apps need to know the clockfreq. Its used for timing etc. P1 programs (objects) get this from hub $0.
There is some thread about it, but I can't find it right now. Maybe @evanh can chime in else I need to call our finding god @Publison who really knows to search this forum.
But basically setting the clock back to RCFAST does not work as it should and one needs the last two bits of clockset or something like this, so the need to have the old values...
Evan, this doesn’t resolve the fact that almost all apps need to know the clockfreq. Its used for timing etc. P1 programs (objects) get this from hub $0.
That's assuming an external progam did the clockfreq setting for it.
But basically setting the clock back to RCFAST does not work as it should and one needs the last two bits of clockset or something like this, so the need to have the old values...
What Chip is saying is the loader can set whatever clockfreq it wants, for a fast loading for example, but just before doing the COGINIT on the loaded binary, switch back to RCFAST using its own internal knowledge.
So convention become: Every program always starts off at RCFAST and has to do its own clockfreq init if it wants different.
Evan, this doesn’t resolve the fact that almost all apps need to know the clockfreq. Its used for timing etc. P1 programs (objects) get this from hub $0.
That's assuming an external progam did the clockfreq setting for it.
No, that is the standard location of clockfreq with all programs you can run on the P1, Does not matter if Pnut, BST, Proptool, SimpleIDE, PropellerIDE, Fastspin, Tachyon, whatever HUB $0 contains clockfreq on a P1 and is used for timing calculations like @Cluso99 stated.
No, that is the standard location of clockfreq with all programs you can run on the P1, Does not matter if Pnut, BST, Proptool, SimpleIDE, PropellerIDE, Fastspin, Tachyon, whatever HUB $0 contains clockfreq on a P1 and is used for timing calculations like @Cluso99 stated.
If a program sets the clockfreq itself, then it happily has no use of that. That was always an optional thing on the prop1.
CPUHZ clock freq value is read by the program to calculate NCO values and delays etc. My XIN parameter is used along with part of the CLKCFG clock config value to calculate a new clock frequency. However most of the time it is simply the CLKCFG value that is used in the hubset sequence.
initsys hubset #0 ' SWITCH TO RCFAST'
mov hr1,_CLKCFG
hubset hr1
waitx ##20_000_000/100 ' wait ~10ms for crystal+PLL to stabilize
or hr1,#xmode ' use PLL bits'
hubset hr1
Since I use serial a lot, I also have a baudrate from which a new smartpin value is calculated in combination with CPUHZ
'SETBAUD ' calculate baud timing at runtime'
rdlong r0,#@_CPUHZ
rdlong r1,#@_BAUD
qdiv r0,r1
getqx r0
shl r0,#16
add r0,#7 ' 8 data bits '
wxpin r0,#rx_pin ' baud 8 data
wxpin r0,#tx_pin ' baud 8 data
What about storing the values like all other do and have the problem solved? The loader will need the old values to switch back to RCFAST, that is the reason for the agreement.
Mike
But the loader can maintain its own record if it's using the PLL. Once it switches safely back to RCFAST, there's no need to convey the prior setting. At that point, the application program switches to some crystal mode and starts keeping its own record. An RCFAST hand-off doesn't require any last-set mode value.
[RANT]
Ok I give you another example.
I mashed TAQOZ and FastSpin together. There is a thread about it. But basically I start TAQOZ in COG0 and a FastSpin compiled Program in COG1 able to talk to TAQOZ via Mailbox. Both Programs agree about the locations in HUB where the clocksettigs are.
I CAN change the clockfreq in my FastSpin program while the TAQOZ COG0 is running. FastSpin program will change the HUB location after changing the freq. And TAQOZ still knows what freq we are running on, still knows to pulse a pin at 1,10 or 100 Hz because it knows the system frequency has changed.
Because both programs agree on that location.
Any P1 Program/Object needing timing relays on having clockfreq at 0. No serial driver would work without it. And the same is with the P2 WE NEED ONE DEFINED LOCATION for that. And we have a agreed one. I really think this 'OH we can address the first 512 longs different, we can use #x and save a long' quite stupid and even IF there is a need to do so, can't we spare those two longs where they are?
Sure we can start a new discussion, make a committee create another horse looking like a camel, and have a 'cleaner' design. HUB 0 jumps to main program, HUB 4-2048 is a potential Jump area, hell lets cut some off the top of the HUB too, like @Cluso99 asked for, lets declare stdin, stdout, stderr, vga and SD as standard at max-HUB - whatever.
Really guys?
The current implemented solution *in FastSpin, P2gcc, Phyton and TAQOZ uses 2 longs in lower HUB. Yes $14 and $18 so we WASTE 20 bytes before that, usable as short addressable HUB memory.
So what?
we are talking here about the first 28 bytes of 512Kb, are you aware of this?
Is it really needed that all tools get rewritten to use other as the agreed upon locations JUST because @cgracey thinks it would be cool to use that area for - undefined purposes -, kind of good to have area to put something not yet written, but - hm- nice to have?
And that -nice to have - can not spare the first 28 bytes? But will need to overwrite its own boot code?
Comments
You can imagine then the motivation problem those of us who are volunteering our time feel sometimes too
I don't see much difference technically between putting the clock info at $10 and at $40. Technically I can live with either. But I've already changed this once after the last discussion (one thread is at https://forums.parallax.com/discussion/169697/rom-changes-for-next-silicon/, I think there are other threads too). You can forgive me if I can't get enthusiastic about changing it yet again, in all of the various tools I support (loadp2, fastspin, riscvp2, micropython, jit toolkit).
If everyone else agrees on a new location and it's not completely unreasonable then I certainly won't stand in the way and I'll be happy to accept pull requests to change it in the various tools. I won't provide any commitment to doing the work myself though, Not to say I won't, just that right now I can't commit to doing that work for free.
I agree, both issues are important, but they are somewhat orthogonal. @Cluso99 , would you be up for starting a new thread to discuss mailboxes? I think it is an important discussion and shouldn't be buried somewhere else.
Sure. It may take me a bit before I start the thread as I really need to be on my computer, not my iPad or iPhone. I am currently in the UK visiting our daughter and family so computer time is limited.
I have to say tho, ain’t the internet and phones/tablets great - I can travel half way around the world and still have full communications including remote access to my work and home computer, email and phone
I used to say computers changed the world, but IMHO they have nothing on the Internet!
It's not so much the fact that these addresses can be hard-coded that makes them attractive, as it is they begin at $00000 and can be indexed by cog ID. The need for these is very finite, so starting them at $00000 is convenient and simple. It also allows one-time boot code to clean up after itself and free up its hub memory, even pre-clearing the range to 0's, initializing the mailbox area.
Is one long per cog sufficient, or are two necessary? I think four are probably overkill. One each is nice and clean. Two might provide better full-duplex communications. Maybe one is good because it can just be used to point to a structure with some flexible purpose. I kind of think that would be best. That would take $00000..$0003F. The clock frequency and mode longs could immediately follow. That happens to be how the Spin2 intepreter is currently set up.
I'm voting for 1 long per cog and if more than 1 long is needed just use as a pointer. I really hope everyone can agree on this since it seems the simplest and most efficient.
But this is not the point here. Currently there is a agreement between all languages usable on the P2 to use those locations and you want to destroy that agreement, because you think mailboxes there would be nice.
Some major flaws in that. You are overwriting your own boot code, so even a soft reset will kill you.
There is no need at all to have mailboxes at 0-16 longs, none. mailboxes can sit (and do) anywhere in HUB you access them with rdlong, wrlong anyways so no need at all to have them in the first $1FF bytes.
Please Chip reconsider your plans.
What you are currently planning is to destroy all work others have done to gain WHAT exactly?
Mailboxes for 16 COGs we do not even have?
Mike
Personally I'd be happy with your simplest approach, though I know there'll be others that may not. There are other several ways that mailboxes can work with request/reply message blocks etc but for any chance of interoperability I think we need something nailed down and even a single long per COG offers us some hope we can make it work.
We have two options here...either the mailboxes can go in low memory or a pointer to where they are located in memory has to be at some known address somewhere for a convention to apply. Given most low memory is already going to be used up for SPIN2 vectors followed by the SPIN2 interpreter we may wish to try to use the remaining gaps it affords us for storing useful things rather than waste it by leaving only a handful of discontiguous longs free. This includes the CLKFREQ/MODE and any other shared/global P2 state we'd need to track that we can't otherwise query directly from HW. It *could* include the mailbox (doesn't have to) OR at minimum a pointer to where this mailbox is in hub RAM to retain more free low memory for other uses.
Question: How can low memory offer a speed up for accessing the mailboxes? Is there any latency gain there in the code required?
DAT ' STAGE 1 - BOOT TIME INITIALIZATION ' 00000 orgh 0 00000 000 org 00000 000 fd80121c jmp #\initsys '**************** configuration block **************** ' '' 00004 001 452d3250 byte "P2-ES " ' 8 character ID' 0000c 003 03 _OPTIONS byte %0000_0011 ' options SD,FLASH 0000d 003 000000 byte 0,0,0 ' *** CLOCK *** ' 00010 004 01312d00 _XIN long XIN ' input freqency' ' $0014: 00014 005 09896800 _CPUHZ long CPUHZ ' final clock ' ' $0018: 00018 006 010007f8 _CLKCFG long CLKCFG ' *** SERIAL/VGA/KEYBOARD *** ' 0001c 007 002dc6c0 _BAUD long baud_rate$10..$13 = CLKFREQ
$14..$17 = CLKMODE
$14..$17= CLKFREQ
$18...$1B = CLKMODE
What about a fast booter/loader safely returning the clock mode to 20MHz (%00) on its own steam before it launches the app by doing a 'COGINIT #0,#0' ? Then, there'd be no boot problem, as there's no need for agreement.
Mike
But the loader can maintain its own record if it's using the PLL. Once it switches safely back to RCFAST, there's no need to convey the prior setting. At that point, the application program switches to some crystal mode and starts keeping its own record. An RCFAST hand-off doesn't require any last-set mode value.
While those hub $00-FF locations are fast, there is likely better things to go there! The may not be needed in every set of programs, but they do provide simple access and speed where it counts.
And of course, when not used for these special occasions, can have the $00 = JMP $ safety instruction.
The clockfreq and clockmode need to be in a common agreed location. Clockmode is only needed if the clockfreq needs to be changed. Changing this once set should be rare, if ever.
Clockfreq on the other hand, is used by almost all objects so it needs a fixed agreed location. Is there any place at the very top of hub just below the interrupt vectors???
In hindsight we could have has a special register(s) for this and more, sort of like setqx/getqx. Too late now.
Many users, I've noted though, having been expecting the loader to preset the sysclock, and using it for such ... but if that abbility was taken away and, maybe with some education, getting each program to always do their own setting might just be the best solution. First timer's don't have to worry about the flaw until they are wanting to readjust the PLL config.
But basically setting the clock back to RCFAST does not work as it should and one needs the last two bits of clockset or something like this, so the need to have the old values...
Mike
So convention become: Every program always starts off at RCFAST and has to do its own clockfreq init if it wants different.
No, that is the standard location of clockfreq with all programs you can run on the P1, Does not matter if Pnut, BST, Proptool, SimpleIDE, PropellerIDE, Fastspin, Tachyon, whatever HUB $0 contains clockfreq on a P1 and is used for timing calculations like @Cluso99 stated.
Mike
Since I use serial a lot, I also have a baudrate from which a new smartpin value is calculated in combination with CPUHZ
The new proposal has a nice short name for easy reference at a later date: RCFAST hand-off
[RANT]
Ok I give you another example.
I mashed TAQOZ and FastSpin together. There is a thread about it. But basically I start TAQOZ in COG0 and a FastSpin compiled Program in COG1 able to talk to TAQOZ via Mailbox. Both Programs agree about the locations in HUB where the clocksettigs are.
I CAN change the clockfreq in my FastSpin program while the TAQOZ COG0 is running. FastSpin program will change the HUB location after changing the freq. And TAQOZ still knows what freq we are running on, still knows to pulse a pin at 1,10 or 100 Hz because it knows the system frequency has changed.
Because both programs agree on that location.
Any P1 Program/Object needing timing relays on having clockfreq at 0. No serial driver would work without it. And the same is with the P2 WE NEED ONE DEFINED LOCATION for that. And we have a agreed one. I really think this 'OH we can address the first 512 longs different, we can use #x and save a long' quite stupid and even IF there is a need to do so, can't we spare those two longs where they are?
Sure we can start a new discussion, make a committee create another horse looking like a camel, and have a 'cleaner' design. HUB 0 jumps to main program, HUB 4-2048 is a potential Jump area, hell lets cut some off the top of the HUB too, like @Cluso99 asked for, lets declare stdin, stdout, stderr, vga and SD as standard at max-HUB - whatever.
Really guys?
The current implemented solution *in FastSpin, P2gcc, Phyton and TAQOZ uses 2 longs in lower HUB. Yes $14 and $18 so we WASTE 20 bytes before that, usable as short addressable HUB memory.
So what?
we are talking here about the first 28 bytes of 512Kb, are you aware of this?
Is it really needed that all tools get rewritten to use other as the agreed upon locations JUST because @cgracey thinks it would be cool to use that area for - undefined purposes -, kind of good to have area to put something not yet written, but - hm- nice to have?
And that -nice to have - can not spare the first 28 bytes? But will need to overwrite its own boot code?
Sorry Chip but this is simply WRONG.
[/RANT]
Mike