IIRC the 256 long stack/fifo can also be accessed indirectly as well as push/pop instructions. Seeing these now, its a shame we dont have 2 special move instructions to move a long into/out of the fifo by using an immediate fifo address (best not tell Chip as we dont want to delay P2 any more).
BTW I can understand Chip just wants/needs to churn out the info at this point in time He doesn't have the time to pretty it up like you have done. Others can do that - lets just get the info from him.
The stack in each cog can only be accessed by PUSH's and POP's using the SPA and SPB pointers. That's it.
While I like the idea of well-formatted documentation, it takes me too much time to write it like that. All that formatting just gets me into trouble, as I start obsessing about the look of things and get distracted from the contents. Text files are limiting, but they put an early cap on how mired in complexity I can become while trying to get the job done.
While I like the idea of well-formatted documentation, it takes me too much time to write it like that. All that formatting just gets me into trouble, as I start obsessing about the look of things and get distracted from the contents. Text files are limiting, but they put an early cap on how mired in complexity I can become while trying to get the job done.
That's fine, I think the community is doing a fine job by formatting your plain text documentation
Chip, I totally agree. You need to keep it lean and mean. Plain text works great. We all can and will add to it considerably. No worries. Frankly, I like it that way, because as we all get bootstrapped onto the P2, lots of good stuff will happen, and we are all more than happy to share it.
**Finally get to power up today! You all have no idea how annoying this week was. Sometimes we all dread the day job.
While I like the idea of well-formatted documentation, it takes me too much time to write it like that. All that formatting just gets me into trouble, as I start obsessing about the look of things and get distracted from the contents. Text files are limiting, but they put an early cap on how mired in complexity I can become while trying to get the job done.
Chip, we are *expecting* you to post just plain text. In fact, we *want* you to, because it's the fastest way you'll get all the content out to us. As FredBlais and others have stated, we will take care of the formatting. I would ask one favor, though. Instead of modifying the same post (in the other thread), could you post each new section as a separate post (in the other thread is still fine)? If you will do that, I will make sure to add an appendix to the unofficial document to reference each of the posts as a way to consolidate them.
What would you all say to the idea of re-organizing the document to mirror the current Propeller Reference Manual (version 1.2, I believe)? Obviously, it's not going to be a one-to-one match, but I think it would be helpful for the following reasons:
1. We are all familiar with that layout
2. It gives all of us a general guideline where to put new material and how to format it (to the extent possible with Google Docs).
3. With Parallax's blessing, we might even be able to copy some of the existing documentation for instructions that haven't changed (except possibly their bit patterns).
4. Parallax might find the final product a good basis for their official documentation.
What would you all say to the idea of re-organizing the document to mirror the current Propeller Reference Manual (version 1.2, I believe)? Obviously, it's not going to be a one-to-one match, but I think it would be helpful for the following reasons:
1. We are all familiar with that layout
2. It gives all of us a general guideline where to put new material and how to format it (to the extent possible with Google Docs).
3. With Parallax's blessing, we might even be able to copy some of the existing documentation for instructions that haven't changed (except possibly their bit patterns).
4. Parallax might find the final product a good basis for their official documentation.
Chip, we are *expecting* you to post just plain text. In fact, we *want* you to, because it's the fastest way you'll get all the content out to us. As FredBlais and others have stated, we will take care of the formatting. I would ask one favor, though. Instead of modifying the same post (in the other thread), could you post each new section as a separate post (in the other thread is still fine)? If you will do that, I will make sure to add an appendix to the unofficial document to reference each of the posts as a way to consolidate them.
Okay. That sounds great. I'll post each new entry into this thread, since its title relates best to the content.
And feel free, you guys, to arrange things however you think is best. There's no hard reason to do anything the way it was done before.
I have had PMs with Chip explaining what we would like him to do which I thought I made clear but obviously not. Perhaps I should have used plain English rather than Forthspeak No, we don't expect him to do anything but plain text, however it would be a big help if changes were apparent and not buried in the same post which is buried in the thread, however that is his prerogative . Of course we can go through with a text comparator to pick out the changes if we really need to. Ideally however, Chip could just add the plain text to the unofficial P2 document itself after which us clamoring seagulls would pounce on the "chip" and do what we do.
I have had PMs with Chip explaining what we would like him to do which I thought I made clear but obviously not. Perhaps I should have used plain English rather than Forthspeak No, we don't expect him to do anything but plain text, however it would be a big help if changes were apparent and not buried in the same post which is buried in the thread, however that is his prerogative . Of course we can go through with a text comparator to pick out the changes if we really need to. Ideally however, Chip could just add the plain text to the unofficial P2 document itself after which us clamoring seagulls would pounce on the "chip" and do what we do.
EDIT: Just saw your message Chip, thanks.
The trouble is, I keep making minor refinements to parts that are "done", so there are changes strewn throughout, at every iteration. I don't mean to cause anyone frustration.
The trouble is, I keep making minor refinements to parts that are "done", so there are changes strewn throughout, at every iteration. I don't mean to cause anyone frustration.
The trouble is, I keep making minor refinements to parts that are "done", so there are changes strewn throughout, at every iteration. I don't mean to cause anyone frustration.
No frustration here. Actually, I was thinking of incorporating some of the original Propeller instructions that the preliminary detailed instruction document states as unchanged. That should keep me (us?) busy while you do your part. We'll take the new bits when we get it. Also, don't be too concerned about getting it "just right" before posting it. As you are well aware, no matter what you post, there will be at least three different interpretations. Better to work that out with the rough draft than to put in the extra effort and then still have to work it out! In the end, though, do whatever is comfortable for you.
Thanks!!! to Chip for the info and updates and all those participating in the formatting. I read it on a Samsung Galaxy note 10.1 Tablet just using the Web browser and I really like the formatting and the color.
I started coding the P2 Interpreter (using my faster posted version) and came up with a few questions to do with the P2 hardware...
The Interpreter sets the lower hub bytes, in particular the clkfreq at hub $0000(4 bytes) and clkmode at hub $0004(1 byte). What is your plan for these locations or are there hub windows for these locations? If it is too early to answer, just say so.
BTW there were only a couple of compile problems...
wrlong x,#0000
wrbyte x,#$0004
tjz wc
coginit (of course)
par (of course) - will the PARA value be identical to PAR (remember we had to <<2 to pass parameters - is this the same?)
I started coding the P2 Interpreter (using my faster posted version) and came up with a few questions to do with the P2 hardware...
The Interpreter sets the lower hub bytes, in particular the clkfreq at hub $0000(4 bytes) and clkmode at hub $0004(1 byte). What is your plan for these locations or are there hub windows for these locations? If it is too early to answer, just say so.
BTW there were only a couple of compile problems...
wrlong x,#0000
wrbyte x,#$0004
tjz wc
coginit (of course)
par (of course) - will the PARA value be identical to PAR (remember we had to <<2 to pass parameters - is this the same?)
I don't know yet where I'd put the clkfreq and clkmode - maybe $E80 and $E84.
The thing that makes the original spin byte codes not work so well in the P2 is that they used words for addresses. Now, we need 17 bits, and even more for any LMM Spin. You might make a working Spin before I do.
I don't know what the PARA value is. On the Prop2, PTRA gets the address parameter, since there's no more PAR register.
Thanks Chip.
Since you haven't put a hole into the hub ram to keep it at the old location, I will make it relocatable for now. Currently I don't have the DE0-nano so I can only check that it compiled for now. At least I am starting to think about it while I complete other things. I will be ordering my DE0 shortly, along with other parts.
I don't know yet where I'd put the clkfreq and clkmode - maybe $E80 and $E84.
The thing that makes the original spin byte codes not work so well in the P2 is that they used words for addresses. Now, we need 17 bits, and even more for any LMM Spin. You might make a working Spin before I do.
I don't know what the PARA value is. On the Prop2, PTRA gets the address parameter, since there's no more PAR register.
1..8: one-clock instruction, plus up to seven clocks waiting for hub access
2..9: two-clock instruction, plus up to seven clocks waiting for hub access
1..9: ???-clock instruction, plus up to seven clocks waiting for hub access
My question is about the third group, particularly the "???" part. Is this group correct or a documentation error? And if correct, what are the circumstances for the one-clock or two-clock timings?
Seairth,
The 3rd catagory is the cached read instructions (RDxxxxC), they will only take 1 clock if they can be satisfied by the contents of the QUAD registers, otherwise they will take 2+ clocks.
For example if you are using RDBYTEC and assuming the QUAD registers are "cleared" or invalidated. The first RDBYTEC will take the longer time, subsequent RDBYTECs will take 1 clock if they are in the same 4 QUAD block that the first RDBYTEC was in. If you do sequential RDBYTECs then you will get 1x long read, then 15x 1 cycle reads before the next long read.
I'm not talking about the cached instructions. Specifically, the instructions in the third category are COGINIT, LOCKSET, and LOCKCLR. I suspect that these are documentation errors.
I'm not talking about the cached instructions. Specifically, the instructions in the third category are COGINIT, LOCKSET, and LOCKCLR. I suspect that these are documentation errors.
Ah! I thought Roy answered your question, but now I understand you were talking about something different.
The hub instructions: CLKSET/COGID/COGINIT/COGSTOP/LOCKxxx will take 1..8 clocks if their Z/C/R bits are all 0, meaning they don't have to wait for anything back from the hub (no Z, C, or D result). If they are going to receive some result back, they must wait for the next cycle to receive it. Hence, those instructions which get results back take 2..9 clocks.
P.S. Sorry I haven't posted any more doc's lately, but I'll have more tomorrow afternoon.
Hey Chip, you deserve some time off.
We are having fun exploring the possibilities. I think you are giving us just the right amount of time to digest each set of instructions before we get the next installment.
Since we have "carte blanche" for the look and feel of the unofficial document, I started tweaking the instruction page layout in a way that I think might be more informative. But I would like some feedback before going further with it. So, towards the end of the document, take a look at the COGID instruction. The first version you encounter pretty much mirrors the format found in the Propeller Reference Manual. The second version is my modified take. Thoughts?
Seairth: Yes, the new format is much better (describing the wz/wc/nr effects and the clocks as separate tables). Short examples will be a help as well (some instructions already have these on the P1. However, some require further examples). Way to go
There's really only Seairth and myself working on this and we could really do with a helping hand, even if you just tackle a small section. I have been porting the Propeller 2 Detailed Preliminary Feature List over starting with all the hardware and now down into the miscellaneous instructions while Seairth has been doing the Assembly Language Reference in the new format.
So what do you say? At least request edit permissions to be in a position to contribute would be good for a start.
Seairth: Yes, the new format is much better (describing the wz/wc/nr effects and the clocks as separate tables). Short examples will be a help as well (some instructions already have these on the P1. However, some require further examples). Way to go
Hah. That's good enough for me. I made one tweak to the encoding table that I think will make more sense. Otherwise, I think I'm good with it for this go.
Hah. That's good enough for me. I made one tweak to the encoding table that I think will make more sense. Otherwise, I think I'm good with it for this go.
Okay. I couldn't leave well enough alone. Take a look at the ABS instruction. It has all of the same information, but I have formatted it for the landscape layout of the page. In case you are wondering about the landscape layout, I asked Peter about this choice. He pointed out that it's better suited for widescreen monitors. Quite right!
Comments
The stack in each cog can only be accessed by PUSH's and POP's using the SPA and SPB pointers. That's it.
That's fine, I think the community is doing a fine job by formatting your plain text documentation
**Finally get to power up today! You all have no idea how annoying this week was. Sometimes we all dread the day job.
Answer to Yours Questin
http://forums.parallax.com/showthread.php?144199-Propeller-II-Emulation-of-the-P2-on-DE0-NANO-amp-DE2-115-FPGA-boards&p=1148526&viewfull=1#post1148526
Yep, thanks.
\
Looks like Peter and Seairth have it spot on already. Mode excellent.
Chip, we are *expecting* you to post just plain text. In fact, we *want* you to, because it's the fastest way you'll get all the content out to us. As FredBlais and others have stated, we will take care of the formatting. I would ask one favor, though. Instead of modifying the same post (in the other thread), could you post each new section as a separate post (in the other thread is still fine)? If you will do that, I will make sure to add an appendix to the unofficial document to reference each of the posts as a way to consolidate them.
1. We are all familiar with that layout
2. It gives all of us a general guideline where to put new material and how to format it (to the extent possible with Google Docs).
3. With Parallax's blessing, we might even be able to copy some of the existing documentation for instructions that haven't changed (except possibly their bit patterns).
4. Parallax might find the final product a good basis for their official documentation.
Last one was v2
Okay. That sounds great. I'll post each new entry into this thread, since its title relates best to the content.
And feel free, you guys, to arrange things however you think is best. There's no hard reason to do anything the way it was done before.
EDIT: Just saw your message Chip, thanks.
The trouble is, I keep making minor refinements to parts that are "done", so there are changes strewn throughout, at every iteration. I don't mean to cause anyone frustration.
For my needs I made my own PDF.
and that don't disturb me if You post changes as separate post's.
Simpler to find what changed. No need to regenerate entire PDF.
.
No frustration here. Actually, I was thinking of incorporating some of the original Propeller instructions that the preliminary detailed instruction document states as unchanged. That should keep me (us?) busy while you do your part. We'll take the new bits when we get it. Also, don't be too concerned about getting it "just right" before posting it. As you are well aware, no matter what you post, there will be at least three different interpretations.
I started coding the P2 Interpreter (using my faster posted version) and came up with a few questions to do with the P2 hardware...
The Interpreter sets the lower hub bytes, in particular the clkfreq at hub $0000(4 bytes) and clkmode at hub $0004(1 byte). What is your plan for these locations or are there hub windows for these locations? If it is too early to answer, just say so.
BTW there were only a couple of compile problems...
wrlong x,#0000
wrbyte x,#$0004
tjz wc
coginit (of course)
par (of course) - will the PARA value be identical to PAR (remember we had to <<2 to pass parameters - is this the same?)
I don't know yet where I'd put the clkfreq and clkmode - maybe $E80 and $E84.
The thing that makes the original spin byte codes not work so well in the P2 is that they used words for addresses. Now, we need 17 bits, and even more for any LMM Spin. You might make a working Spin before I do.
I don't know what the PARA value is. On the Prop2, PTRA gets the address parameter, since there's no more PAR register.
Since you haven't put a hole into the hub ram to keep it at the old location, I will make it relocatable for now. Currently I don't have the DE0-nano so I can only check that it compiled for now. At least I am starting to think about it while I complete other things. I will be ordering my DE0 shortly, along with other parts.
In some of post's them discussed Mail BOX.
Maybe in that area.--- That give compatibility with all types of Programming
SPIN -- GCC and others
will post link as fast I find it
http://forums.parallax.com/showthread.php?144199-Propeller-II-Emulation-of-the-P2-on-DE0-NANO-amp-DE2-115-FPGA-boards&p=1147465&viewfull=1#post1147465
In your original post of the hub documentation (see http://forums.parallax.com/showthread.php?144199-Propeller-II-Emulation-of-the-P2-on-DE0-NANO-amp-DE2-115-FPGA-boards&p=1146196#post1146196), the hub instruction timing falls into one of three groups:
1..8: one-clock instruction, plus up to seven clocks waiting for hub access
2..9: two-clock instruction, plus up to seven clocks waiting for hub access
1..9: ???-clock instruction, plus up to seven clocks waiting for hub access
My question is about the third group, particularly the "???" part. Is this group correct or a documentation error? And if correct, what are the circumstances for the one-clock or two-clock timings?
The 3rd catagory is the cached read instructions (RDxxxxC), they will only take 1 clock if they can be satisfied by the contents of the QUAD registers, otherwise they will take 2+ clocks.
For example if you are using RDBYTEC and assuming the QUAD registers are "cleared" or invalidated. The first RDBYTEC will take the longer time, subsequent RDBYTECs will take 1 clock if they are in the same 4 QUAD block that the first RDBYTEC was in. If you do sequential RDBYTECs then you will get 1x long read, then 15x 1 cycle reads before the next long read.
Ah! I thought Roy answered your question, but now I understand you were talking about something different.
The hub instructions: CLKSET/COGID/COGINIT/COGSTOP/LOCKxxx will take 1..8 clocks if their Z/C/R bits are all 0, meaning they don't have to wait for anything back from the hub (no Z, C, or D result). If they are going to receive some result back, they must wait for the next cycle to receive it. Hence, those instructions which get results back take 2..9 clocks.
P.S. Sorry I haven't posted any more doc's lately, but I'll have more tomorrow afternoon.
We are having fun exploring the possibilities. I think you are giving us just the right amount of time to digest each set of instructions before we get the next installment.
More tid-bits from Chip...
Also the READQUAD window can be set anywhere in cog ram and can then be executed in the window. http://forums.parallax.com/showthread.php?144478-LMM2-Propeller-2-LMM-experiments-(50-80-LMM2-MIPS-160MHz)&p=1148796&viewfull=1#post1148796
Since we have "carte blanche" for the look and feel of the unofficial document, I started tweaking the instruction page layout in a way that I think might be more informative. But I would like some feedback before going further with it. So, towards the end of the document, take a look at the COGID instruction. The first version you encounter pretty much mirrors the format found in the Propeller Reference Manual. The second version is my modified take. Thoughts?
So what do you say? At least request edit permissions to be in a position to contribute would be good for a start.
Hah. That's good enough for me. I made one tweak to the encoding table that I think will make more sense. Otherwise, I think I'm good with it for this go.
Okay. I couldn't leave well enough alone. Take a look at the ABS instruction. It has all of the same information, but I have formatted it for the landscape layout of the page. In case you are wondering about the landscape layout, I asked Peter about this choice. He pointed out that it's better suited for widescreen monitors. Quite right!