I think this could save a few longs of cog and make parameter passing simpler as the interface address could be hard coded before launching the cog instead of the more complicated way it is now...
It's 2 in the morning here so I'm a little fuzzy but what instruction do we have to read indexed cog memory? In the P1 we would do a movs to change the source field of a mov instruction to read a long from cog. I'm sure we have a much better method now but I can't seem to find it.
It's 2 in the morning here so I'm a little fuzzy but what instruction do we have to read indexed cog memory? In the P1 we would do a movs to change the source field of a mov instruction to read a long from cog. I'm sure we have a much better method now but I can't seem to find it.
I think this involves using ALTS to modify the source address in the following instruction.
There's no ALTS although there is the ALTDS but I found a SETS which seems to do what I want.
Sorry. As you can tell, I haven't been reading these posts all that closely either. I'm kind of waiting for things to settle down. I thought that would happen when the FPGA image was released but it seems it just started a new flurry of suggestions and changes.
There's no ALTS although there is the ALTDS but I found a SETS which seems to do what I want.
Sorry. As you can tell, I haven't been reading these posts all that closely either. I'm kind of waiting for things to settle down. I thought that would happen when the FPGA image was released but it seems it just started a new flurry of suggestions and changes.
I don't think any big changes are on the table. We are just refining what are more-or-less ergonomic issues that affect the user's experience.
There's no ALTS although there is the ALTDS but I found a SETS which seems to do what I want.
Sorry. As you can tell, I haven't been reading these posts all that closely either. I'm kind of waiting for things to settle down. I thought that would happen when the FPGA image was released but it seems it just started a new flurry of suggestions and changes.
There's no ALTS although there is the ALTDS but I found a SETS which seems to do what I want.
In case you want to read more about ALTDS, you can see Chip's comments here.
Thanks for that link, I was looking at documenting the new P2 but I'd rather just write code for it but to do that I need documentation. Ah, the quandary. However I am in the process of overhauling the old unofficial P2 document and links like these are very useful.
Getting back to where I left off I had some weird results with using SETS or maybe it's something else. This was in a cog memory dump routine I am using for debug and instead of dumping from address 0 it seemed to be offset by 1 long as if it started at -1. This revised bit of code that directly increments the source address works and I have the first 16 cog longs reserved then I use a DEADBEEF long as a marker followed by the code. BTW, I'm not trying to use any of the newer P2 features if I don't have to yet, I just want it functional for debugging purposes first.
So why didn't the version that "sets dmx,r1" work, I even inserted extra nops for the pipeline etc.
So with moving special registers to the bottom (or not), will we now still have an interrupt triggered on a hubwrite at each cog's special low address zonezone ?
So with moving special registers to the bottom (or not), will we now still have an interrupt triggered on a hubwrite at each cog's special low address zonezone ?
Cheers,
Peter (pjv)
Of course! That was implemented when we last spoke.
So why didn't the version that "sets dmx,r1" work, I even inserted extra nops for the pipeline etc.
Peter,
I'd like to follow up on this but please start a new topic, or continue in that ALTDS topic, and also post more detail like both versions of source - that work and don't work.
Guys, sorry it's taking me so long to get the new FPGA images out. Everything has been very tedious, it seems.
I spent quite a bit of time today working with Daniel on the Prop123-A9 board revisions. We got rid of the PCI connector and put a 16M x 16 SDRAM directly onto the board. Also, all of the P0..P63 I/0's are now 3.3V, instead of the latter half being 2.5V. We also added some integrators and a header for delta-sigma A/D using the FPGA pins.
Hopefully, I'll have the new FPGA files out tomorrow.
I added a bit (D[5]) to the COGINIT instruction. If that bit is low, it loads the cog registers from the start address and then jumps to $000. Otherwise, it doesn't load anything and just jumps to PTRB (S operand of COGINIT).
I've been detoured a little bit, also, thinking about how to establish debugging in cogs without them needing to add any debug code. I think I have it figured out. Too tired to explain much right now, so I'm going to get some sleep.
Whew! I got it working again after moving the registers around and adding auto-loading, so we can load up cogs on COGINIT (like Prop1), and not have to go straight into hub exec. Initial hub exec is just an option now via D[5] on 'COGINIT D/#,S/#'. I had to do a lot of work on the assembler to get everything in proper order. Anyway, it's alive, but I need to get this debug interrupt hook implemented and tested before I can get new images out. It's not complicated. The hard part is already behind me.
I'm excited to get the debugging fully implemented with startup hooks in hub RAM. All cogs will begin in single-step mode, stopped right before the initial instruction of the program. From there, you can selectively single step main/int1/int2/int3 code, set an address breakpoint, enable async break from another cog, or just immediately release and run full speed by leaving the RETI0 at $400+cogid*4. The only thing you have to do to debug a cog is replace its RETI0 in hub with a JMP to your debug handler. No modification to the cog program needs to be made. I'm anxious to see this work. It's going to open a huge door into seeing what your code is up to.
Comments
If compilers are going to start putting code at $400 and RDxxx/WRxxx have immediate values of 0..255...
Doesn't this make the lower 256 bytes of HUB RAM prime real estate for hard coded addresses to exchange info between cogs?
1SUPNNNNN PTR expression ------------------------------------------------------------------------------ 100000000 PTRA 'use PTRA 110000000 PTRB 'use PTRB 101100001 PTRA++ 'use PTRA, PTRA += SCALE 111100001 PTRB++ 'use PTRB, PTRB += SCALE 101111111 PTRA-- 'use PTRA, PTRA -= SCALE 111111111 PTRB-- 'use PTRB, PTRB -= SCALE 101000001 ++PTRA 'use PTRA + SCALE, PTRA += SCALE 111000001 ++PTRB 'use PTRB + SCALE, PTRB += SCALE 101011111 --PTRA 'use PTRA - SCALE, PTRA -= SCALE 111011111 --PTRB 'use PTRB - SCALE, PTRB -= SCALE 1000NNNNN PTRA[INDEX] 'use PTRA + INDEX*SCALE 1100NNNNN PTRB[INDEX] 'use PTRB + INDEX*SCALE 1011NNNNN PTRA++[INDEX] 'use PTRA, PTRA += INDEX*SCALE 1111NNNNN PTRB++[INDEX] 'use PTRB, PTRB += INDEX*SCALE 1011nnnnn PTRA--[INDEX] 'use PTRA, PTRA -= INDEX*SCALE 1111nnnnn PTRB--[INDEX] 'use PTRB, PTRB -= INDEX*SCALE 1010NNNNN ++PTRA[INDEX] 'use PTRA + INDEX*SCALE, PTRA += INDEX*SCALE 1110NNNNN ++PTRB[INDEX] 'use PTRB + INDEX*SCALE, PTRB += INDEX*SCALE 1010nnnnn --PTRA[INDEX] 'use PTRA - INDEX*SCALE, PTRA -= INDEX*SCALE 1110nnnnn --PTRB[INDEX] 'use PTRB - INDEX*SCALE, PTRB -= INDEX*SCALEBTW: Is there a maintained link for that in the stickies or something?
The quick answer will be a yes, that is kind of another zero-page situation.
In case you want to read more about ALTDS, you can see Chip's comments here.
Sorry. As you can tell, I haven't been reading these posts all that closely either. I'm kind of waiting for things to settle down. I thought that would happen when the FPGA image was released but it seems it just started a new flurry of suggestions and changes.
I don't think any big changes are on the table. We are just refining what are more-or-less ergonomic issues that affect the user's experience.
And that is the beauty of it.
Thanks for that link, I was looking at documenting the new P2 but I'd rather just write code for it but to do that I need documentation. Ah, the quandary. However I am in the process of overhauling the old unofficial P2 document and links like these are very useful.
So why didn't the version that "sets dmx,r1" work, I even inserted extra nops for the pipeline etc.
' cog dump dump mov r1,#0 sets dmx,#0 mov r2,#$0100 dlp mov X,dmx and X,#$07 wz if_nz jmp #dm1 call #newline mov X,r1 call #prthex mov dx,#":" call @send ' call @space dm1 'sets dmx,r1 add r1,#1 dmx mov X,0 add dmx,#1 call #prthex call #space djnz r2,@dlp retDump listing:
00000000:FFFFFFFF FC010000 00000000 40000000 00000000 40000000 00000000 00000001 00000008:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000010:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000018:DEADBEEF F605002A FDA0024C FD800148 F464063E F4640A3E FA6C023F 5D800078 00000020:F6050054 FDA0024C F6050046 FDA0024C F6050032 FDA0024C FDA00240 FDA002D4 00000028:FDA00240 FF000001 F6050D09 FDA00240 F6010E06 FDA00274 FB010A86 F6010E85 00000030:FDA002A8 F1150C01 FAA00085 FDA00194 FDA00194 FDA00194 F5850E01 FAA00082 00000038:F9E11882 F6010E8C FDA001C8 FAA00082 F6010E8D FD8000E8 F6010E8E FD8000E8 00000040:F6010E8F FD8000E8 F601008C FD612629 FD8000D4 F661188C F1111A8C FD8000D4 00000048:FA349001 F3851801 FAA00082 FA349601 FDA00188 F3810C87 FAA00082 FDA00178 00000050:FDA00178 FDA00178 FDA00178 FDA001C4 FAA00082 33151621 33151611 33151609 00000058:33151605 33151603 33151602 33151604 F1851601 FD80014C FDA00188 F0651608 00000060:F5411687 FD60002D FB010E86 F1050C01 FD60002D F6010E8C F601188D F6011A8E 00000068:F6011C8F F9E10870 F1850804 FA0D080F AD60002D F6011083 F1011084 FB411E88 00000070:FD60002D F6010E8B F6051600 F2150810 F9E50603 F6011083 F1011084 3C611E88 00000078:F6011E8E F6011C8D F6011A8C F6011887 F1050804 FD60002D 000001B2 74AE6101 00000080:00000000 00000000 000000AC 00000000 00000000 00000000 00000309 00000007 00000088:00000000 0000008A 00000076 00000000 00000000 00000000 00000000 00000000 00000090:F605000D FDB00004 F605000A F4650008 F0650001 FD60FE1A FCDC080A FA6D0000 00000098:F4E4063E FA80FE7E FD601223 F0450001 FD60002D F6050208 F6010087 F045001C 000000A0:F21D0009 11050037 E1050030 FDBFFFBC F0650E04 F9CD03F8 FD60002D F6050020 000000A8:FDBFFFA8 FD60002D FDBFFFF0 F6010087 F0450004 FDA002BC F6010087 F525000F 000000B0:F21D0009 11050037 E1050030 FDBFFF7C FD60002D F6051200 F9B58200 F6051500 000000B8:F6010EC1 F52D0E07 5D800300 FDA00240 F6010E89 FDA00274 F605003A FDBFFF4C 000000C0:F1051201 F6010EC1 F1058201 FDA00274 FDA0029C F9CD15F2 FD60002D 42392119 000000C8:00054B49 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000D0:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000D8:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000E0:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000E8:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000F0:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000F8:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000Cheers,
Peter (pjv)
Of course! That was implemented when we last spoke.
With all these changes being considered, I'm rather befuddled as to what's happening.
Surely it will all get worked out, and we all will be happy!
Cheers,
Peter (pjv)
My feeling is that it's getting tidied up now.
Peter,
I'd like to follow up on this but please start a new topic, or continue in that ALTDS topic, and also post more detail like both versions of source - that work and don't work.
I spent quite a bit of time today working with Daniel on the Prop123-A9 board revisions. We got rid of the PCI connector and put a 16M x 16 SDRAM directly onto the board. Also, all of the P0..P63 I/0's are now 3.3V, instead of the latter half being 2.5V. We also added some integrators and a header for delta-sigma A/D using the FPGA pins.
Hopefully, I'll have the new FPGA files out tomorrow.
I added a bit (D[5]) to the COGINIT instruction. If that bit is low, it loads the cog registers from the start address and then jumps to $000. Otherwise, it doesn't load anything and just jumps to PTRB (S operand of COGINIT).
I've been detoured a little bit, also, thinking about how to establish debugging in cogs without them needing to add any debug code. I think I have it figured out. Too tired to explain much right now, so I'm going to get some sleep.
The new A9 board should be a winner!
I was playing with COGINIT lately. Being able to control loading the cog is a sweet feature!
Go, Chip, go!!
Ditto. You've created a masterpiece. Enjoy the last few strokes.
We will wait patiently until you get the next FPGA release done.
... I lied - not so "patiently", but happy to wait
I'm excited to get the debugging fully implemented with startup hooks in hub RAM. All cogs will begin in single-step mode, stopped right before the initial instruction of the program. From there, you can selectively single step main/int1/int2/int3 code, set an address breakpoint, enable async break from another cog, or just immediately release and run full speed by leaving the RETI0 at $400+cogid*4. The only thing you have to do to debug a cog is replace its RETI0 in hub with a JMP to your debug handler. No modification to the cog program needs to be made. I'm anxious to see this work. It's going to open a huge door into seeing what your code is up to.