Keep that up Sapieha, I have just been porting these instructions in and it's still the first pass and incomplete but you should be in there editing these yourself !!!
If I write badly on forum -- You can always sak ----> If I edit badly on this WEB document -- People that don't know what place to ask will be confused
Keep that up Sapieha, I have just been porting these instructions in and it's still the first pass and incomplete but you should be in there editing these yourself !!!
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.
So, what about the RDxxxx instructions? Based on the "3..10" in your original documentation, does that mean 3 clock cycles, plus up to 7 more if waiting for hub?
For he WRxxxx instructions, I am assuming that the "1..8" indicates that there are no applicable effects (i.e. WZ and WC do not cause Z and C to change, and WR would make it a RDxxxx instruction).
So, what about the RDxxxx instructions? Based on the "3..10" in your original documentation, does that mean 3 clock cycles, plus up to 7 more if waiting for hub?
For he WRxxxx instructions, I am assuming that the "1..8" indicates that there are no applicable effects (i.e. WZ and WC do not cause Z and C to change, and WR would make it a RDxxxx instruction).
Thanks. Also, in the Propeller Reference Manual for WRxxxx, there is the following footnote: The Z flag is set (1) unless the main memory address is on a long boundary.
Is this still true? Or does the forced alignment (e.g. WRLONG uses mask %1_11111111_11110000) make that no longer applicable?
The $00E7F should be above the $00E80 shouldn't it? It is currently smashed on top of APPLICATION RAM.
Weird. I didn't see that issue until I opened it for editing. Anyhow, I have moved it back to its proper location and, while I was making changes, added the internal CLK and LOCK registers.
I've been busy just filling in a lot of P2 details and I have just been going back over the cog diagram trying to put all the details in there including the special function registers which are not part of the memory map. This is a part I would like to fill in with all the detail of the registers. A more complete hub diagram would detail the I/O and CPU etc. Could somebody take a look over it and see if there is something to add or change, thanks.
I've been busy just filling in a lot of P2 details and I have just been going back over the cog diagram trying to put all the details in there including the special function registers which are not part of the memory map. This is a part I would like to fill in with all the detail of the registers. A more complete hub diagram would detail the I/O and CPU etc. Could somebody take a look over it and see if there is something to add or change, thanks.
[B]MULLL/MULLH[/B] 'etc, registers to acces the multiply, divide, SQRT and CORDIC ooperations
[B]DAC0/DAC1/DAC2/DAC3[/B] 'configuration and data for the DACs
[B]LFSR[/B] 'Random number generator
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!
yes, i think widescreen could be used with benefits and we can also print in landscape.
as far as abs goes, i think the various instruction formats can be simplified. we dont require the first 2 because the optional conditions cover this. likewise. the immexiate versions do not require thatthe c flag is unavailablebecause it is in factavailable and usable - it always clears the c flag. that should benoted in the c flagsection - use of # fot the source with wc will always clear the c flag because b31 is implied to be0. I think it could be more beneficial to have a set of note (footnote style) that is common for alll instructions, and is found at the end of theinstruction sets. there are a lot of uses for setting flags like mov $,#0 wz nr 'set z flag and mov $,#1 wz nr 'clr z flag ie not zero.
as far as abs goes, i think the various instruction formats can be simplified. we dont require the first 2 because the optional conditions cover this.
I pondered this "duplication" as well. However, I decided that it was still worthwhile because it shows what the "default" encoding is (i.e. the encoding if no condition or effects is specified).
Yes, as I understand it too, just double-checking.
While doing the pinout table for the P2 it reinforces just how general-purpose the I/O pins are. On any other micro I have multiple functions a pin can perform but you can't really transfer those functions to another pin. With the Prop every I/O pin works the same and is truly general-purpose, or should we say, multi-purpose I/O (MPIO).
EDIT: anyone know what type of SPI Flash the P2 boots from?
I would prefer that they not be included there (or on the PTRA/PTRB) registers. My rationale is that the picture is of the registers, not of the instructions. The pre/post increment/decrement operations are part of the instructions.
Comments
Can You revise this instructions on web page in --->
[h=4]Table 10: Extended Miscellaneous Instructions[/h]
http://forums.parallax.com/showthread.php?144199-Propeller-II-Emulation-of-the-P2-on-DE0-NANO-amp-DE2-115-FPGA-boards&p=1148847&viewfull=1#post1148847
http://forums.parallax.com/showthread.php?144199-Propeller-II-Emulation-of-the-P2-on-DE0-NANO-amp-DE2-115-FPGA-boards&p=1148852&viewfull=1#post1148852
Done. I stated the equivalent expressions a bit different than Dave Hein did.
If I write badly on forum -- You can always sak ----> If I edit badly on this WEB document -- People that don't know what place to ask will be confused
thanks
Can any of You edit HUB MEMORY picture --- It look's badly
So, what about the RDxxxx instructions? Based on the "3..10" in your original documentation, does that mean 3 clock cycles, plus up to 7 more if waiting for hub?
For he WRxxxx instructions, I am assuming that the "1..8" indicates that there are no applicable effects (i.e. WZ and WC do not cause Z and C to change, and WR would make it a RDxxxx instruction).
You're right on both counts.
Thanks. Also, in the Propeller Reference Manual for WRxxxx, there is the following footnote: The Z flag is set (1) unless the main memory address is on a long boundary.
Is this still true? Or does the forced alignment (e.g. WRLONG uses mask %1_11111111_11110000) make that no longer applicable?
The $00E7F should be above the $00E80 shouldn't it? It is currently smashed on top of APPLICATION RAM.
C.W.
Weird. I didn't see that issue until I opened it for editing. Anyhow, I have moved it back to its proper location and, while I was making changes, added the internal CLK and LOCK registers.
Line from my own PDF on CTRA, CTRB.
CTRA/CTRB (FRQ,PHS,SIN,COS) 'Each have FRQ, PHS, SIN and COS register
Little more.
Nice edit so far.
Can You add to Boxes INDA, INDB
++/--
Thanks.
You know that it will now be steal to my PDF ?
No Problems..
My PDF are to out of date --- I generate it every time after I edited TEXT file
Ps. -- NO pictures before end of Work on it
as far as abs goes, i think the various instruction formats can be simplified. we dont require the first 2 because the optional conditions cover this. likewise. the immexiate versions do not require thatthe c flag is unavailablebecause it is in factavailable and usable - it always clears the c flag. that should benoted in the c flagsection - use of # fot the source with wc will always clear the c flag because b31 is implied to be0. I think it could be more beneficial to have a set of note (footnote style) that is common for alll instructions, and is found at the end of theinstruction sets. there are a lot of uses for setting flags like mov $,#0 wz nr 'set z flag and mov $,#1 wz nr 'clr z flag ie not zero.
One more question.
Is it possible have that 64-bit info in that 2 boxes.
I pondered this "duplication" as well. However, I decided that it was still worthwhile because it shows what the "default" encoding is (i.e. the encoding if no condition or effects is specified).
If I understand it correct --- Yes
While doing the pinout table for the P2 it reinforces just how general-purpose the I/O pins are. On any other micro I have multiple functions a pin can perform but you can't really transfer those functions to another pin. With the Prop every I/O pin works the same and is truly general-purpose, or should we say, multi-purpose I/O (MPIO).
EDIT: anyone know what type of SPI Flash the P2 boots from?
I would prefer that they not be included there (or on the PTRA/PTRB) registers. My rationale is that the picture is of the registers, not of the instructions. The pre/post increment/decrement operations are part of the instructions.