I'm not sure if document size is the issue in this case, but spliting it up might be a good idea.
I was hoping to make a template for the new instruction description format and populate it very quickly using VBA, but pasting the tables back from Word 2010 doesn't get the formatting correct.
I tried saving the Google Docs document to HTML and opening the HTML in Chrome, then cutting and pasting from that document back to Google Docs, the formatting gets messed up that way as well.
Other than plain text Google Docs seems to like to only cut/paste with itself...
If I have time this weekend I though I might see if making tables using very simple HTML with inline styles might work as a way to build content and then paste it in.
I loath manual typing when it's something where I should be able to let the computer do the work.
Could part of the problem be that our document has become too large for google to work efficiently???
Maybe we need to split the document???
I was thinking it wouldn't hurt to split it, at least move the detailed assembly language reference to another section. The table of contents would not be so cluttered then and the the assembly section can have it's own heading styles. I use Chrome for Google docs but sometimes as the docs become sluggish I just need to restart the program, so Google docs is certainly not perfect, there are limitations but it provides that interactive environment where we can see, comment, edit, even as we type.
I'm not sure if document size is the issue in this case, but spliting it up might be a good idea.
I was hoping to make a template for the new instruction description format and populate it very quickly using VBA, but pasting the tables back from Word 2010 doesn't get the formatting correct.
I tried saving the Google Docs document to HTML and opening the HTML in Chrome, then cutting and pasting from that document back to Google Docs, the formatting gets messed up that way as well.
Other than plain text Google Docs seems to like to only cut/paste with itself...
If I have time this weekend I though I might see if making tables using very simple HTML with inline styles might work as a way to build content and then paste it in.
I loath manual typing when it's something where I should be able to let the computer do the work.
C.W.
I agree - I did the reformatting and dividing into columns using Excel formulae, and then copying the resultant values.
I think the new instruction format you have devised should also be a separate document, so maybe again, do it offline. If anyone volunteers to help you can send them the template in word and discuss what instructions they will do.
It is my private version of Instructions PDF.
Only first 2 pages are end coloured as I still work on base text to it so no need every time colour Test.pdf
Look in attachment
Ps. For my eyes it is simpler to distingush what is important
I agree - I did the reformatting and dividing into columns using Excel formulae, and then copying the resultant values.
I think the new instruction format you have devised should also be a separate document, so maybe again, do it offline. If anyone volunteers to help you can send them the template in word and discuss what instructions they will do.
Here is the latest spreadsheet with the P2 instruction summary. There are a few that still need a proper description and the Z/C/R?/Clocks/Delayed are not correct yet. ANd of course I have not verified the bit patterns that I copied. However, it is getting there as I have spent quite a bit of time on it.
Here is the latest spreadsheet with the P2 instruction summary. There are a few that still need a proper description and the Z/C/R?/Clocks/Delayed are not correct yet. ANd of course I have not verified the bit patterns that I copied. However, it is getting there as I have spent quite a bit of time on it.
Thanks Peter. For now it is easier to edit in Excel as there is still a bit to do.
BTW I noticed it did leading zero supression.
I opened up the xlsx spreadsheet in LibreOffice on my Linux computer which must do something to the zeros I guess, at least it has conversion utilities from one format to another. The whole world has not yet been assimilated by the proprietary MSO with their free 60 day trial.
EDIT: Looks like a Google docs thing, there is no where I can tell it to keep leading zeros so I just went and put a % sign in front plus the zeros so it would always treat it as text.
In another thread (I can't find it right now), Chip said that he got REPS/REPD to work with multi-tasking. But only a single task can use it at a time.
In another thread (I can't find it right now), Chip said that he got REPS/REPD to work with multi-tasking. But only a single task can use it at a time.
From Chip "I got the REPS/REPD working with multitasking now. Any task can use it, but only one task at a time."
Bean
Thanks Bean, well that makes sense I guess and we can work that into the docs, especially the assembler reference doc which looks like Seairth is taking a break from at the moment but hopefully he will come back to continue chipping away at it soon
If anyone feels competent to add a few more instructions in the same style then have a practice in the training doc perhaps and if it looks good we can include it in the main document.
The only thing new in it is the field mover description:
BYTE/WORD FIELD MOVER
---------------------
Each cog has a field mover that can move a byte or word from any field in S into any field in D. To use
the field mover, you must first configure it using SETF. Then, you can use MOVF to perform the moves.
SETF uses a 9-bit value to configure the field mover:
%W_DDdd_SSss
W = 1 for word mode, 0 for byte mode
DD = D field mode: %00 = D field pointer stays same after MOVF
%01 = D field pointer stays same after MOVF, D rotates left by byte/word
%10 = D field pointer increments after MOVF
%11 = D field pointer decrements after MOVF
dd = D field pointer: %00 = byte 0 / word 0
%01 = byte 1 / word 0
%10 = byte 2 / word 1
%11 = byte 3 / word 1
SS = S field mode: %0x = S field pointer stays same after MOVF
%10 = S field pointer increments after MOVF
%11 = S field pointer decrements after MOVF
ss = S field pointer: %00 = byte 0 / word 0
%01 = byte 1 / word 0
%10 = byte 2 / word 1
%11 = byte 3 / word 1
On cog startup, SETF is initialized to %0_0100_0000, so that MOVF will rotate D left by 8 bits and
then fill the bottom byte with the lower byte in S.
instructions clocks
-------------------------------------------------------------------------------------------------
000011 000 1 CCCC DDDDDDDDD 011001010 SETF D 'Configure field mover with D 1
000011 001 1 CCCC nnnnnnnnn 011001010 SETF #n 'Configure field mover with 0..511 1
000101 000 0 CCCC DDDDDDDDD SSSSSSSSS MOVF D,S 'Move field from S into D 1
000101 000 1 CCCC DDDDDDDDD nnnnnnnnn MOVF D,#n 'Move field from 0..511 into D 1
-------------------------------------------------------------------------------------------------
The only thing new in it is the field mover description:
BYTE/WORD FIELD MOVER
---------------------
Each cog has a field mover that can move a byte or word from any field in S into any field in D. To use
the field mover, you must first configure it using SETF. Then, you can use MOVF to perform the moves.
SETF uses a 9-bit value to configure the field mover:
%W_DDdd_SSss
W = 1 for word mode, 0 for byte mode
DD = D field mode: %00 = D field pointer stays same after MOVF
%01 = D field pointer stays same after MOVF, D rotates left by byte/word
%10 = D field pointer increments after MOVF
%11 = D field pointer decrements after MOVF
dd = D field pointer: %00 = byte 0 / word 0
%01 = byte 1 / word 0
%10 = byte 2 / word 1
%11 = byte 3 / word 1
SS = S field mode: %0x = S field pointer stays same after MOVF
%10 = S field pointer increments after MOVF
%11 = S field pointer decrements after MOVF
ss = S field pointer: %00 = byte 0 / word 0
%01 = byte 1 / word 0
%10 = byte 2 / word 1
%11 = byte 3 / word 1
On cog startup, SETF is initialized to %0_0100_0000, so that MOVF will rotate D left by 8 bits and
then fill the bottom byte with the lower byte in S.
instructions clocks
-------------------------------------------------------------------------------------------------
000011 000 1 CCCC DDDDDDDDD 011001010 SETF D 'Configure field mover with D 1
000011 001 1 CCCC nnnnnnnnn 011001010 SETF #n 'Configure field mover with 0..511 1
000101 000 0 CCCC DDDDDDDDD SSSSSSSSS MOVF D,S 'Move field from S into D 1
000101 000 1 CCCC DDDDDDDDD nnnnnnnnn MOVF D,#n 'Move field from 0..511 into D 1
-------------------------------------------------------------------------------------------------
The only thing new in it is the field mover description:
BYTE/WORD FIELD MOVER
---------------------
Each cog has a field mover that can move a byte or word from any field in S into any field in D. To use
the field mover, you must first configure it using SETF. Then, you can use MOVF to perform the moves.
SETF uses a 9-bit value to configure the field mover:
%W_DDdd_SSss
W = 1 for word mode, 0 for byte mode
DD = D field mode: %00 = D field pointer stays same after MOVF
%01 = D field pointer stays same after MOVF, D rotates left by byte/word
%10 = D field pointer increments after MOVF
%11 = D field pointer decrements after MOVF
dd = D field pointer: %00 = byte 0 / word 0
%01 = byte 1 / word 0
%10 = byte 2 / word 1
%11 = byte 3 / word 1
SS = S field mode: %0x = S field pointer stays same after MOVF
%10 = S field pointer increments after MOVF
%11 = S field pointer decrements after MOVF
ss = S field pointer: %00 = byte 0 / word 0
%01 = byte 1 / word 0
%10 = byte 2 / word 1
%11 = byte 3 / word 1
On cog startup, SETF is initialized to %0_0100_0000, so that MOVF will rotate D left by 8 bits and
then fill the bottom byte with the lower byte in S.
instructions clocks
-------------------------------------------------------------------------------------------------
000011 000 1 CCCC DDDDDDDDD 011001010 SETF D 'Configure field mover with D 1
000011 001 1 CCCC nnnnnnnnn 011001010 SETF #n 'Configure field mover with 0..511 1
000101 000 0 CCCC DDDDDDDDD SSSSSSSSS MOVF D,S 'Move field from S into D 1
000101 000 1 CCCC DDDDDDDDD nnnnnnnnn MOVF D,#n 'Move field from 0..511 into D 1
-------------------------------------------------------------------------------------------------
I've updated the document and put the configurations bits and instructions into tables. Here's a forum preview which looks similar to the document except the lines don't seem to show up.
Byte/Word Field Mover
<forum> Each cog has a field mover that can move a byte or word from any field in S into any field in D. To use the field mover, you must first configure it using SETF. Then, you can use MOVF to perform the moves.
SETF uses a 9-bit value %W_DDdd_SSss to configure the field mover: Table: Field mover configuration bits
W word/byte DD D field mode dd D field pointer SS S field mode ss S field pointer
0 byte mode %00 D field pointer stays same after MOVF %00 byte 0 / word 0 %00 S field pointer stays same after MOVF %00 byte 0 / word 0
1 word mode %01 D field pointer stays same after MOVF, D rotates left by byte/word %01 byte 1 / word 0 %01 S field pointer stays same after MOVF %01 byte 1 / word 0
%10 byte 2 / word 1 %10 S field pointer increments after MOVF %10 byte 2 / word 1
%11 byte 3 / word 1 %11 S field pointer deccrements after MOVF %11 byte 3 / word 1
On cog startup, SETF is initialized to %0_0100_0000, so that MOVF will rotate D left by 8 bits and then fill the bottom byte with the lower byte in S.
Yes, these registers are not part of the cog memory registers but hidden like SPA and PTR etc that are only accessed via their special instruction.
BTW Chip, well thought out relegating all these registers plus the new ones to special instructions which frees up the precious cog memory.
Yes, these registers are not part of the cog memory registers but hidden like SPA and PTR etc that are only accessed via their special instruction.
BTW Chip, well thought out relegating all these registers plus the new ones to special instructions which frees up the precious cog memory.
It became apparent early on that if every special function register were mapped into register space, they would eat way too many registers. Only the pin registers have crucial need to be addressable.
INSTRUCTION-BLOCK REPEATING
---------------------------
Each cog has an instruction-block repeater that can variably repeat up to 64 instructions without
any clock-cycle overhead.
REPD and REPS are used to initiate block repeats. These instructions specify how many times the
trailing instruction block will be executed and how many instructions are in the block:
REPD #i - execute 1..64 instructions infinitely, requires 3 spacer instructions *
REPD D,#i - execute 1..64 instructions D+1 times, requires 3 spacer instructions *
REPD #n,#i - execute 1..64 instructions 1..512 times, requires 3 spacer instructions *
REPS #n,#i - execute 1..64 instructions 1..16384 times, requires 1 spacer instruction *
REPS differs from REPD by executing at the 2nd stage of the pipeline, instead of the 4th. By
executing two stages early, it needs only one spacer instruction *. Because of its earliness,
no conditional execution is possible, so it always executes, allowing the CCCC bits to be
repurposed, along with Z, to provide a 14-bit constant for the repeat count.
The instruction-block repeater will quit repeating the block if a branch instruction executes
within the block. This rule does not currently apply to a JMPTASK which affects the task using the
repeater - this will be fixed at the earliest opportunity.
* Spacer instructions are required in 1-task applications to allow the pipeline to prime before
repeating can commence. If REPD is used by a task that uses no more than every 4th time slot, no
spacers are needed, as three intervening instructions will be provided by the other task(s). If
REPS is used by a task that uses no more than every 2nd time slot, no spacers are needed.
Example (1-task):
REPD D,#1 'execute 1 instruction D+1 times
NOP '3 spacer instructions needed (could do something useful)
NOP
NOP
NOTP #0 'toggle P0, block repeats every 1 clock
Example (1-task):
REPS #20_000,#4 'execute 4 instructions 20,000 times
NOP '1 spacer instruction needed (make the most of it)
NOTP #0 'toggle P0
NOTP #1 'toggle P1
NOTP #2 'toggle P2
NOTP #3 'toggle P3, block repeats every 4 clocks
Example (4-task, SETTASK #%%3210 timing):
task0 REPD #1 'task0 will own the block repeater (no need for spacers)
NOTP #0 'toggle P0 every 4 clocks
task1 NOTP #1 'toggle P1 every 8 clocks
JMP #task1
task2 NOTP #2 'toggle P2 every 8 clocks
JMP #task2
task3 NOTP #3 'toggle P3 every 8 clocks
JMP #task3
instructions (iiiiii = #i-1, nnnnnnnnn/n___nnnn_nnnnnnnnn = #n-1) clocks
-------------------------------------------------------------------------------------------------
000011 000 1 CCCC 111111111 001iiiiii REPD #i 'execute 1..64 inst's infintely 1
000011 000 1 CCCC nnnnnnnnn 001iiiiii REPD D,#i 'execute 1..64 inst's D+1 times 1
000011 001 1 CCCC nnnnnnnnn 001iiiiii REPD #n,#i 'execute 1..64 inst's 1x..512x 1
000011 n11 1 nnnn nnnnnnnnn 001iiiiii REPS #n,#i 'execute 1..64 inst's 1x..16384x 1
-------------------------------------------------------------------------------------------------
Note that the %iiiiii field represents 1..64 instructions, not the encoded 0..63. The %nnnnnnnnn/
%n___nnnn_nnnnnnnnn fields are +1-based, too.
At this time, 'REPD #i' must be typed as 'REPD $1FF,#i', since the assembler in PNUT isn't handling this shorthand syntax yet. I'll have it added in a day, or two.
Thanks Chip, the REP instruction was one piece of information that I was looking for a bit more information on myself. So slowly but inexorably the documentation progresses as I proceed to add this bit of information as well. I would rather spend time with my DE2 testing my code but alas, there is only so much time in a day. Now if only I could employ the REP instruction to get through some things faster....
Comments
Maybe we need to split the document???
I'm not sure if document size is the issue in this case, but spliting it up might be a good idea.
I was hoping to make a template for the new instruction description format and populate it very quickly using VBA, but pasting the tables back from Word 2010 doesn't get the formatting correct.
I tried saving the Google Docs document to HTML and opening the HTML in Chrome, then cutting and pasting from that document back to Google Docs, the formatting gets messed up that way as well.
Other than plain text Google Docs seems to like to only cut/paste with itself...
If I have time this weekend I though I might see if making tables using very simple HTML with inline styles might work as a way to build content and then paste it in.
I loath manual typing when it's something where I should be able to let the computer do the work.
C.W.
I think the new instruction format you have devised should also be a separate document, so maybe again, do it offline. If anyone volunteers to help you can send them the template in word and discuss what instructions they will do.
It is my private version of Instructions PDF.
Only first 2 pages are end coloured as I still work on base text to it so no need every time colour Test.pdf
Look in attachment
Ps. For my eyes it is simpler to distingush what is important
The main section still has all the other assembler instruction tables.
P2_Instructions(5).zip
In section
[h=3]Table: Pin Definitions.[/h]
PWR name
shall be
Core PWR
BTW I noticed it did leading zero supression.
EDIT: Looks like a Google docs thing, there is no where I can tell it to keep leading zeros so I just went and put a % sign in front plus the zeros so it would always treat it as text.
P.S. Found it ! Post #150 in this thread http://forums.parallax.com/showthread.php?144478-LMM2-Propeller-2-LMM-experiments-(50-80-LMM2-MIPS-160MHz)/page8
From Chip "I got the REPS/REPD working with multitasking now. Any task can use it, but only one task at a time."
Bean
If anyone feels competent to add a few more instructions in the same style then have a practice in the training doc perhaps and if it looks good we can include it in the main document.
Prop2_Docs.txt
The only thing new in it is the field mover description:
BYTE/WORD FIELD MOVER --------------------- Each cog has a field mover that can move a byte or word from any field in S into any field in D. To use the field mover, you must first configure it using SETF. Then, you can use MOVF to perform the moves. SETF uses a 9-bit value to configure the field mover: %W_DDdd_SSss W = 1 for word mode, 0 for byte mode DD = D field mode: %00 = D field pointer stays same after MOVF %01 = D field pointer stays same after MOVF, D rotates left by byte/word %10 = D field pointer increments after MOVF %11 = D field pointer decrements after MOVF dd = D field pointer: %00 = byte 0 / word 0 %01 = byte 1 / word 0 %10 = byte 2 / word 1 %11 = byte 3 / word 1 SS = S field mode: %0x = S field pointer stays same after MOVF %10 = S field pointer increments after MOVF %11 = S field pointer decrements after MOVF ss = S field pointer: %00 = byte 0 / word 0 %01 = byte 1 / word 0 %10 = byte 2 / word 1 %11 = byte 3 / word 1 On cog startup, SETF is initialized to %0_0100_0000, so that MOVF will rotate D left by 8 bits and then fill the bottom byte with the lower byte in S. instructions clocks ------------------------------------------------------------------------------------------------- 000011 000 1 CCCC DDDDDDDDD 011001010 SETF D 'Configure field mover with D 1 000011 001 1 CCCC nnnnnnnnn 011001010 SETF #n 'Configure field mover with 0..511 1 000101 000 0 CCCC DDDDDDDDD SSSSSSSSS MOVF D,S 'Move field from S into D 1 000101 000 1 CCCC DDDDDDDDD nnnnnnnnn MOVF D,#n 'Move field from 0..511 into D 1 -------------------------------------------------------------------------------------------------Exactly what I needed for an experiment tomorrow - MUCH appreciated.
Thanks for that instructions
BTW, does this mean that each cog has a field pointer register as well that I can include in the diagram?
P2_Instructions(6).zip
Every cog has its own SETF/MOVF mechanism.
Byte/Word Field Mover
<forum>
Each cog has a field mover that can move a byte or word from any field in S into any field in D. To use the field mover, you must first configure it using SETF. Then, you can use MOVF to perform the moves.
SETF uses a 9-bit value %W_DDdd_SSss to configure the field mover:
Table: Field mover configuration bits
W
word/byte
DD
D field mode
dd
D field pointer
SS
S field mode
ss
S field pointer
0
byte mode
%00
D field pointer stays same after MOVF
%00
byte 0 / word 0
%00
S field pointer stays same after MOVF
%00
byte 0 / word 0
1
word mode
%01
D field pointer stays same after MOVF,
D rotates left by byte/word
%01
byte 1 / word 0
%01
S field pointer stays same after MOVF
%01
byte 1 / word 0
%10
byte 2 / word 1
%10
S field pointer increments after MOVF
%10
byte 2 / word 1
%11
byte 3 / word 1
%11
S field pointer deccrements after MOVF
%11
byte 3 / word 1
On cog startup, SETF is initialized to %0_0100_0000, so that MOVF will rotate D left by 8 bits and then fill the bottom byte with the lower byte in S.
Table: Byte/Word Field Mover Instructions
Machine Code
Mnemonic
Operand
Operation
Clocks
00011 000 1 CCCC DDDDDDDDD 011001010
SETF
Configure field mover with D
1
000011 001 1 CCCC nnnnnnnnn 011001010
SETF
Configure field mover with 0..511
1
000101 000 0 CCCC DDDDDDDDD SSSSSSSSS
MOVF
Move field from S into D
1
000101 000 1 CCCC DDDDDDDDD nnnnnnnnn
MOVF
Move field from 0..511 into D
1
The only way to set them is via SETF. MOVF might inc or dec either pointer, depending on what was set up with SETF.
BTW Chip, well thought out relegating all these registers plus the new ones to special instructions which frees up the precious cog memory.
It became apparent early on that if every special function register were mapped into register space, they would eat way too many registers. Only the pin registers have crucial need to be addressable.
Prop2_Docs.txt
Here's the new part:
INSTRUCTION-BLOCK REPEATING --------------------------- Each cog has an instruction-block repeater that can variably repeat up to 64 instructions without any clock-cycle overhead. REPD and REPS are used to initiate block repeats. These instructions specify how many times the trailing instruction block will be executed and how many instructions are in the block: REPD #i - execute 1..64 instructions infinitely, requires 3 spacer instructions * REPD D,#i - execute 1..64 instructions D+1 times, requires 3 spacer instructions * REPD #n,#i - execute 1..64 instructions 1..512 times, requires 3 spacer instructions * REPS #n,#i - execute 1..64 instructions 1..16384 times, requires 1 spacer instruction * REPS differs from REPD by executing at the 2nd stage of the pipeline, instead of the 4th. By executing two stages early, it needs only one spacer instruction *. Because of its earliness, no conditional execution is possible, so it always executes, allowing the CCCC bits to be repurposed, along with Z, to provide a 14-bit constant for the repeat count. The instruction-block repeater will quit repeating the block if a branch instruction executes within the block. This rule does not currently apply to a JMPTASK which affects the task using the repeater - this will be fixed at the earliest opportunity. * Spacer instructions are required in 1-task applications to allow the pipeline to prime before repeating can commence. If REPD is used by a task that uses no more than every 4th time slot, no spacers are needed, as three intervening instructions will be provided by the other task(s). If REPS is used by a task that uses no more than every 2nd time slot, no spacers are needed. Example (1-task): REPD D,#1 'execute 1 instruction D+1 times NOP '3 spacer instructions needed (could do something useful) NOP NOP NOTP #0 'toggle P0, block repeats every 1 clock Example (1-task): REPS #20_000,#4 'execute 4 instructions 20,000 times NOP '1 spacer instruction needed (make the most of it) NOTP #0 'toggle P0 NOTP #1 'toggle P1 NOTP #2 'toggle P2 NOTP #3 'toggle P3, block repeats every 4 clocks Example (4-task, SETTASK #%%3210 timing): task0 REPD #1 'task0 will own the block repeater (no need for spacers) NOTP #0 'toggle P0 every 4 clocks task1 NOTP #1 'toggle P1 every 8 clocks JMP #task1 task2 NOTP #2 'toggle P2 every 8 clocks JMP #task2 task3 NOTP #3 'toggle P3 every 8 clocks JMP #task3 instructions (iiiiii = #i-1, nnnnnnnnn/n___nnnn_nnnnnnnnn = #n-1) clocks ------------------------------------------------------------------------------------------------- 000011 000 1 CCCC 111111111 001iiiiii REPD #i 'execute 1..64 inst's infintely 1 000011 000 1 CCCC nnnnnnnnn 001iiiiii REPD D,#i 'execute 1..64 inst's D+1 times 1 000011 001 1 CCCC nnnnnnnnn 001iiiiii REPD #n,#i 'execute 1..64 inst's 1x..512x 1 000011 n11 1 nnnn nnnnnnnnn 001iiiiii REPS #n,#i 'execute 1..64 inst's 1x..16384x 1 ------------------------------------------------------------------------------------------------- Note that the %iiiiii field represents 1..64 instructions, not the encoded 0..63. The %nnnnnnnnn/ %n___nnnn_nnnnnnnnn fields are +1-based, too.At this time, 'REPD #i' must be typed as 'REPD $1FF,#i', since the assembler in PNUT isn't handling this shorthand syntax yet. I'll have it added in a day, or two.
See http://forums.parallax.com/showthread.php?144478-LMM2-Propeller-2-LMM-experiments-(50-80-LMM2-MIPS-160MHz)&p=1150320&viewfull=1#post1150320
BTW what is the op code bits for SETCOG? I cannot find it in the google docs.
Here's the current instruction set: