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.
Dump listing:
Cheers,
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.