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-$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 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++
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 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-$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 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++
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 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
And then...
To run David's program in cog zero.
and longs...
#$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:
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.
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... So we can read quads every 2 hub cycles max unless there is another way???
Or might this work???
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.
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: 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:
Or 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