Getting down to the nitty-gritty. You can also send this as text to the monitor.
E80:409A C10D 4A 0004 E000 EC D3 A0 DB 8C 7C 0C
E90:47 FC BF A0925C FC 0C CB 88 FC 0C 0596 FC A0EA0:0D 94 FC 0C 4994 BC 800D 947C 0C 0896 FC F6EB0:B2887C 0C 152C FC 1C 2248 FC 1C 0D 967C 86EC0:1300541C 1942 FC 1C 0A 96 FC A01942 FC 1C
ED0:0E 007C 1C C196 FC 0000967C F81942 FC 1C
EE0:15007C 1C 0196 FC 2C 6997 FC 0C 0D 94 FC 0C
EF0:4894 BC 800D 947C 0C 0196 FC 29 DC 8C 7C 0C
F00:1C 967C FA 00007C 1C 255A FC 1C 2200681C
F10:00007C 1C 809C FC 68179E FC 0E 4E 9E 1486F20:169E D40C A29C 540C 1896 D40C 169C D40C
F30:A29E 540C 00007C 1C 17007C 0E A300 E90C
F40:09 A4 FC A048 A0 BC A401 A0 FC 38338A FC F8F50:0C A0 FC 0C 01 A2 FC 3048 A0 BC 800D A07C 0C
F60:D68A 7C 0D 35 A4 FC F618 A2 FC 28 AB A27C 0C
F70:2E 007C 1C 0D 0A 48656C 6C 6F 2C 2050726F
F80:70656C 6C 6572204949210D 0A 00000000F90:740F 00005B 0000005A 00000000000004FA0:0802000000879303
What I don't understand is the expression $1F6-@reserves. Isn't @reserves the byte address of that label? And $1F6 is the long address of the first register in COG memory. I would think the expression would really have to be something like $1F6 - (@reserves / 4) to get the number of longs between the label "reserves" and the first COG register. What am I missing here?
I think I mentioned this before but I also don't understand why the second line isn't "setinda #reserves".
#$1F6-@reserves ars same as #$1F6-#$1E0 (#$1E0 = addres of reserves NOT real in my example) Give length for clearing space
Yes, I understand that @reserves is the address of the symbol "reserves" but is it a long address or a byte address. When I setup a pointer to my "hello" string it behaves as if it is a byte address. Here it looks like it's being used as a long address. Which is it?
SETINDA is used with two operands according to the Propeller 2 Detailed Preliminary Feature List v2.0:
Setup indirection register address A bottom range and top range where D is the top of the range and S is the bottom range. The indirection register will allow access to cog registers in this range.
And two days after I install it, Altera puts up a new version of Quartus II.:frown:
I think Chip said there was a downloader you could use without having to install the entire Quartus II package. I haven't looked for it myself. Anyone have a link?
I think Chip said there was a downloader you could use without having to install the entire Quartus II package. I haven't looked for it myself. Anyone have a link?
I follow the use of the RDQUAD/WRQUAD using the PTRx's and increment/decrement the PTRx.
But I am a little confused about the mapping of the hidden Quad registers and their use with the SETQUAD D/#n instructions.
Once mapped with the SETQUAD instructions, I presume any operation on these "mapped" cog ram 4xLongs now use the "hidden quad registers"? When initially set with SETQUAD, they may have different values. Does this mean that we are actually using the "hidden quad registers" and the real cog registers will not be altered, or will the cog registers be updated when the hidden quad registers get updated?
I follow the use of the RDQUAD/WRQUAD using the PTRx's and increment/decrement the PTRx.
But I am a little confused about the mapping of the hidden Quad registers and their use with the SETQUAD D/#n instructions.
Once mapped with the SETQUAD instructions, I presume any operation on these "mapped" cog ram 4xLongs now use the "hidden quad registers"? When initially set with SETQUAD, they may have different values. Does this mean that we are actually using the "hidden quad registers" and the real cog registers will not be altered, or will the cog registers be updated when the hidden quad registers get updated?
I need to clarify that in the documentation.
At cog startup, the QUAD registers are hidden and their data are undefined.
When they are mapped somewhere into register space, they appear in lieu of the the four registers that normally occupy that space. When you write to those mapped locations, you write both the QUAD registers and the cog registers. If you do a RDQUAD, the QUAD register is updated, but the background registers stay the same.
Does that clear things up? Thanks for pointing this out.
Sorry if I've had my head down, so much to do. Here's a link.
Here also are the pertinent drivers for windows to support the DE0 NANO "USB Blaster" else you must install Quartus II to get them to use with the above programmer. Using the above combination, up and running on OSX under parallels win7, Pnut, TeraTerm so straight windows should be simple ?
At cog startup, the QUAD registers are hidden and their data are undefined.
When they are mapped somewhere into register space, they appear in lieu of the the four registers that normally occupy that space. When you write to those mapped locations, you write both the QUAD registers and the cog registers. If you do a RDQUAD, the QUAD register is updated, but the background registers stay the same.
Does that clear things up? Thanks for pointing this out.
Thanks Chip.
This means RDQUAD/WRQUAD cannot be used to load a group of quads to/from cog registers to/from hub ram. We can use PTRx for the hub addresses with auto increment/decrement. So to load a block of quads to cog we would do something like...
'setup PTRA to point to some hub location'setup PTRB to point to some cog location
SETQUAD #$1E0'window quad into cog $1E0-$1E3REP #n,#8'repeat 'n' times the next 9 instructions
RDQUAD PTRA++
NOPX #5'wait for the pipemovPTRB++,$1E0'1st quad long windowmovPTRB++,$1E1'2nd quad long windowmovPTRB++,$1E2'3rd quad long windowmovPTRB++,$1E3'4th quad long window
So we can read quads every 2 hub cycles max unless there is another way???
Or might this work???
'setup PTRA to point to some hub location'setup PTRB to point to some cog location
SETQUAD #$1E0'window quad into cog $1E0-$1E3
RDQUAD PTRA++ 'this will get the first quad
Loop:
RDQUAD PTRA++
movPTRB++,$1E0'1st quad long window (these will move the previous rdquad as the above rdquad will not be available for 5 clocks!!!)movPTRB++,$1E1'2nd quad long windowmovPTRB++,$1E2'3rd quad long windowmovPTRB++,$1E3'4th quad long windowdjnz count,#Loop:
movPTRB++,$1E0'1st quad long window (and load the last rdquad)movPTRB++,$1E1'2nd quad long windowmovPTRB++,$1E2'3rd quad long windowmovPTRB++,$1E3'4th quad long window
This means RDQUAD/WRQUAD cannot be used to load a group of quads to/from cog registers to/from hub ram. We can use PTRx for the hub addresses with auto increment/decrement. So to load a block of quads to cog we would do something like...
'setup PTRA to point to some hub location'setup PTRB to point to some cog location
SETQUAD #$1E0'window quad into cog $1E0-$1E3REP #n,#8'repeat 'n' times the next 9 instructions
RDQUAD PTRA++
NOPX #5'wait for the pipemovPTRB++,$1E0'1st quad long windowmovPTRB++,$1E1'2nd quad long windowmovPTRB++,$1E2'3rd quad long windowmovPTRB++,$1E3'4th quad long window
So we can read quads every 2 hub cycles max unless there is another way???
Or might this work???
'setup PTRA to point to some hub location'setup PTRB to point to some cog location
SETQUAD #$1E0'window quad into cog $1E0-$1E3
RDQUAD PTRA++ 'this will get the first quad
Loop:
RDQUAD PTRA++
movPTRB++,$1E0'1st quad long window (these will move the previous rdquad as the above rdquad will not be available for 5 clocks!!!)movPTRB++,$1E1'2nd quad long windowmovPTRB++,$1E2'3rd quad long windowmovPTRB++,$1E3'4th quad long windowdjnz count,#Loop:
movPTRB++,$1E0'1st quad long window (and load the last rdquad)movPTRB++,$1E1'2nd quad long windowmovPTRB++,$1E2'3rd quad long windowmovPTRB++,$1E3'4th quad long window
PTRA and PTRB are only for pointing to hub memory. INDA and INDB are for pointing to cog memory. SPA and SPB are for pointing to stack memory.
If you want to read longs quickly into registers, it's simplest to just do 'RDLONGC INDA++,PTRA++'. Less stuff to think about that way.
I just documented the stack memory (or CLUT) and fixed the omission you found.
Are they still accessible at $1F6 & $1F7 or are they now hidden and only accessible via the special instructions?
Does this mean there are effectively shaddow registers at $1F6 & $1F7?
Is the new manual correct in that COGINIT will load $1F8 longs ($000-$1F7) or will it only load $1F6 longs to ($000-$1F5)?
Initially, $1F6 and $1F7 point only to themselves, so they are more or less regular RAM registers and do get loaded on cog start. When the hardware sees $1F6 or $1F7 for D or S, it substitutes the current pointer value for $1F6/$1F7. The only way you can address the shadow registers is by pointing INDA or INDB at them.
I also realized that stack reads are only one clock, not two.
I guess this document answers my question about why the ROM monitor code uses the syntax:
setinda reserves
This is because the argument to setinda is always an immediate value. If that is the case, I think it would probably be better to use the "#" to indicate that even though no non-immediate mode is available for this instruction. I think it makes it easier to read. Otherwise, it looks like a bug. The way it is currently written makes me think that the contents of the register "reserves" will be used rather than the address of that register. I'd like to suggest that the assembler require this syntax:
I guess this document answers my question about why the ROM monitor code uses the syntax:
setinda reserves
This is because the argument to setinda is always an immediate value. If that is the case, I think it would probably be better to use the "#" to indicate that even though no non-immediate mode is available for this instruction. I think it makes it easier to read. Otherwise, it looks like a bug. The way it is currently written makes me think that the contents of the register "reserves" will be used rather than the address of that register. I'd like to suggest that the assembler require this syntax:
setinda#reserves
Okay, but what about the delta modes where a '+' or '-' must be expressed?
Comments
E80:40 9A C1 0D 4A 00 04 E0 00 EC D3 A0 DB 8C 7C 0C E90:47 FC BF A0 92 5C FC 0C CB 88 FC 0C 05 96 FC A0 EA0:0D 94 FC 0C 49 94 BC 80 0D 94 7C 0C 08 96 FC F6 EB0:B2 88 7C 0C 15 2C FC 1C 22 48 FC 1C 0D 96 7C 86 EC0:13 00 54 1C 19 42 FC 1C 0A 96 FC A0 19 42 FC 1C ED0:0E 00 7C 1C C1 96 FC 00 00 96 7C F8 19 42 FC 1C EE0:15 00 7C 1C 01 96 FC 2C 69 97 FC 0C 0D 94 FC 0C EF0:48 94 BC 80 0D 94 7C 0C 01 96 FC 29 DC 8C 7C 0C F00:1C 96 7C FA 00 00 7C 1C 25 5A FC 1C 22 00 68 1C F10:00 00 7C 1C 80 9C FC 68 17 9E FC 0E 4E 9E 14 86 F20:16 9E D4 0C A2 9C 54 0C 18 96 D4 0C 16 9C D4 0C F30:A2 9E 54 0C 00 00 7C 1C 17 00 7C 0E A3 00 E9 0C F40:09 A4 FC A0 48 A0 BC A4 01 A0 FC 38 33 8A FC F8 F50:0C A0 FC 0C 01 A2 FC 30 48 A0 BC 80 0D A0 7C 0C F60:D6 8A 7C 0D 35 A4 FC F6 18 A2 FC 28 AB A2 7C 0C F70:2E 00 7C 1C 0D 0A 48 65 6C 6C 6F 2C 20 50 72 6F F80:70 65 6C 6C 65 72 20 49 49 21 0D 0A 00 00 00 00 F90:74 0F 00 00 5B 00 00 00 5A 00 00 00 00 00 00 04 FA0:08 02 00 00 00 87 93 03And then...
>0+E80To run David's program in cog zero.
>WE80:9A40 0DC1 004A E004 EC00 A0D3 8CDB 0C7C E90:FC47 A0BF 5C92 0CFC 88CB 0CFC 9605 A0FC EA0:940D 0CFC 9449 80BC 940D 0C7C 9608 F6FC EB0:88B2 0C7C 2C15 1CFC 4822 1CFC 960D 867C EC0:0013 1C54 4219 1CFC 960A A0FC 4219 1CFC ED0:000E 1C7C 96C1 00FC 9600 F87C 4219 1CFC EE0:0015 1C7C 9601 2CFC 9769 0CFC 940D 0CFC EF0:9448 80BC 940D 0C7C 9601 29FC 8CDC 0C7C F00:961C FA7C 0000 1C7C 5A25 1CFC 0022 1C68 F10:0000 1C7C 9C80 68FC 9E17 0EFC 9E4E 8614 F20:9E16 0CD4 9CA2 0C54 9618 0CD4 9C16 0CD4 F30:9EA2 0C54 0000 1C7C 0017 0E7C 00A3 0CE9 F40:A409 A0FC A048 A4BC A001 38FC 8A33 F8FC F50:A00C 0CFC A201 30FC A048 80BC A00D 0C7C F60:8AD6 0D7C A435 F6FC A218 28FC A2AB 0C7C F70:002E 1C7C 0A0D 6548 6C6C 2C6F 5020 6F72 F80:6570 6C6C 7265 4920 2149 0A0D 0000 0000 F90:0F74 0000 005B 0000 005A 0000 0000 0400 FA0:0208 0000 8700 0393and longs...>NE80:0DC19A40 E004004A A0D3EC00 0C7C8CDB E90:A0BFFC47 0CFC5C92 0CFC88CB A0FC9605 EA0:0CFC940D 80BC9449 0C7C940D F6FC9608 EB0:0C7C88B2 1CFC2C15 1CFC4822 867C960D EC0:1C540013 1CFC4219 A0FC960A 1CFC4219 ED0:1C7C000E 00FC96C1 F87C9600 1CFC4219 EE0:1C7C0015 2CFC9601 0CFC9769 0CFC940D EF0:80BC9448 0C7C940D 29FC9601 0C7C8CDC F00:FA7C961C 1C7C0000 1CFC5A25 1C680022 F10:1C7C0000 68FC9C80 0EFC9E17 86149E4E F20:0CD49E16 0C549CA2 0CD49618 0CD49C16 F30:0C549EA2 1C7C0000 0E7C0017 0CE900A3 F40:A0FCA409 A4BCA048 38FCA001 F8FC8A33 F50:0CFCA00C 30FCA201 80BCA048 0C7CA00D F60:0D7C8AD6 F6FCA435 28FCA218 0C7CA2AB F70:1C7C002E 65480A0D 2C6F6C6C 6F725020 F80:6C6C6570 49207265 0A0D2149 00000000 F90:00000F74 0000005B 0000005A 04000000 FA0:00000208 03938700#$1F6-@reserves ars same as #$1F6-#$1E0 (#$1E0 = addres of reserves NOT real in my example) Give length for clearing space
This seems to work for me:
reps #$1F6-(@reserves>>2),#1 'clear reserves setinda reserves mov inda++,#0I still don't understand why the middle line isn't:
setinda #reservesSetup indirection register address A bottom range and top range where D is the top of the range and S is the bottom range. The indirection register will allow access to cog registers in this range.
Has it changed?
https://www.altera.com/download/software/prog-software
I think Peter posted that link previously but I can't find where he posted it. Its more like 150MB than 3800MB for the full package
Cluso, it would be good to add that to your reference first post at the top of this thread
Sorry if I've had my head down, so much to do. Here's a link.
http://forums.parallax.com/showthread.php?144199-Propeller-II-Emulation-of-the-P2-on-DE0-NANO-amp-DE2-115-FPGA-boards&p=1146196&viewfull=1#post1146196
It now covers all the hub instructions (mostly same as Prop1), plus the INDIRECT REGISTERS!!
Same fast as PDF
For them that will have it in that form.
Added one more PDF.
re QUAD instructions and the mapping...
I follow the use of the RDQUAD/WRQUAD using the PTRx's and increment/decrement the PTRx.
But I am a little confused about the mapping of the hidden Quad registers and their use with the SETQUAD D/#n instructions.
Once mapped with the SETQUAD instructions, I presume any operation on these "mapped" cog ram 4xLongs now use the "hidden quad registers"? When initially set with SETQUAD, they may have different values. Does this mean that we are actually using the "hidden quad registers" and the real cog registers will not be altered, or will the cog registers be updated when the hidden quad registers get updated?
I need to clarify that in the documentation.
At cog startup, the QUAD registers are hidden and their data are undefined.
When they are mapped somewhere into register space, they appear in lieu of the the four registers that normally occupy that space. When you write to those mapped locations, you write both the QUAD registers and the cog registers. If you do a RDQUAD, the QUAD register is updated, but the background registers stay the same.
Does that clear things up? Thanks for pointing this out.
Have CLUT instructions changed since last Preliminary document else remain same ?
Here also are the pertinent drivers for windows to support the DE0 NANO "USB Blaster" else you must install Quartus II to get them to use with the above programmer. Using the above combination, up and running on OSX under parallels win7, Pnut, TeraTerm so straight windows should be simple ?
Attachment not found.
Thanks Chip.
This means RDQUAD/WRQUAD cannot be used to load a group of quads to/from cog registers to/from hub ram. We can use PTRx for the hub addresses with auto increment/decrement. So to load a block of quads to cog we would do something like...
'setup PTRA to point to some hub location 'setup PTRB to point to some cog location SETQUAD #$1E0 'window quad into cog $1E0-$1E3 REP #n,#8 'repeat 'n' times the next 9 instructions RDQUAD PTRA++ NOPX #5 'wait for the pipe mov PTRB++,$1E0 '1st quad long window mov PTRB++,$1E1 '2nd quad long window mov PTRB++,$1E2 '3rd quad long window mov PTRB++,$1E3 '4th quad long windowSo we can read quads every 2 hub cycles max unless there is another way???Or might this work???
'setup PTRA to point to some hub location 'setup PTRB to point to some cog location SETQUAD #$1E0 'window quad into cog $1E0-$1E3 RDQUAD PTRA++ 'this will get the first quad Loop: RDQUAD PTRA++ mov PTRB++,$1E0 '1st quad long window (these will move the previous rdquad as the above rdquad will not be available for 5 clocks!!!) mov PTRB++,$1E1 '2nd quad long window mov PTRB++,$1E2 '3rd quad long window mov PTRB++,$1E3 '4th quad long window djnz count,#Loop: mov PTRB++,$1E0 '1st quad long window (and load the last rdquad) mov PTRB++,$1E1 '2nd quad long window mov PTRB++,$1E2 '3rd quad long window mov PTRB++,$1E3 '4th quad long windowPTRA and PTRB are only for pointing to hub memory. INDA and INDB are for pointing to cog memory. SPA and SPB are for pointing to stack memory.
If you want to read longs quickly into registers, it's simplest to just do 'RDLONGC INDA++,PTRA++'. Less stuff to think about that way.
I just documented the stack memory (or CLUT) and fixed the omission you found.
http://forums.parallax.com/showthread.php?144199-Propeller-II-Emulation-of-the-P2-on-DE0-NANO-amp-DE2-115-FPGA-boards&p=1146196&viewfull=1#post1146196
I also realized that stack reads are only one clock, not two.
re INDA & INDB
Are they still accessible at $1F6 & $1F7 or are they now hidden and only accessible via the special instructions?
Does this mean there are effectively shaddow registers at $1F6 & $1F7?
Is the new manual correct in that COGINIT will load $1F8 longs ($000-$1F7) or will it only load $1F6 longs to ($000-$1F5)?
Thanks
Initially, $1F6 and $1F7 point only to themselves, so they are more or less regular RAM registers and do get loaded on cog start. When the hardware sees $1F6 or $1F7 for D or S, it substitutes the current pointer value for $1F6/$1F7. The only way you can address the shadow registers is by pointing INDA or INDB at them.
Once cycle for stack reads is great, as are the CALLD and RETD instructions.
If I read your previous message correctly, then
REP #1,#64 RDLONGC INDA++,PTR++Would load 64 longs from the hub to the cog in eight hub cycles (plus time for loading INDA, PTR, REP, and time to sync to the first hub access)
I guess this document answers my question about why the ROM monitor code uses the syntax:
setinda reservesThis is because the argument to setinda is always an immediate value. If that is the case, I think it would probably be better to use the "#" to indicate that even though no non-immediate mode is available for this instruction. I think it makes it easier to read. Otherwise, it looks like a bug. The way it is currently written makes me think that the contents of the register "reserves" will be used rather than the address of that register. I'd like to suggest that the assembler require this syntax:setinda #reservesOr worse case, permit both, but warn on non-immediate use.
Okay, but what about the delta modes where a '+' or '-' must be expressed?
SETINDA -#5
SETINDA +#5
I don't really like that.
How about this:
SETINDA @5
SETINDA @-5