I guess I don't understand debugging/interrupts...
What happens if I fail to set the interrupt vectors?

When a cog starts executing user code, a debug interrupt immediately occurs and the cog jumps to where its INA's shadow register points. The tiny cog-startup ROM in the cog sets that pointer to $400+cogid*4. There needs to be some instruction there to receive the branch. If you want to debug, make it a JMP to somewhere. If you want it to immediately release and not come back, make it an RETI0.

These 16 debug interrupt instructions at $400 allow for NSA-style complete interdiction of all cog execution. It's scary! It has a price, though: Your freedom to do whatever you want with hub memory. This is the debug solution for our brave new world. We could make it work on a per-cog basis, but why bother? That'd be like getting warrants, or something. What do you guys want? Are you willing to give up a little freedom here? Are you wondering if you even have a choice?

These 16 debug interrupt instructions at $400 allow for NSA-style complete interdiction of all cog execution. It's scary! It has a price, though: Your freedom to do whatever you want with hub memory. This is the debug solution for our brave new world. We could make it work on a per-cog basis, but why bother? That'd be like getting warrants, or something. What do you guys want? Are willing to give up a little freedom here? Are you wondering if you even have a choice?

Well, here's the thing. If I wanted to debug code loaded in the cog, couldn't I get the same effect by defining a debug_start routine in hub memory that would:

Then, whenever I want to debug a cog, I coginit cog_num, @debug_start. Wouldn't this give me the same result as what you have? Similarly, if I want to debug hub code, wouldn't the process be the same as above, except step 1?

(note: yes, I would somehow need to pass the start address, but I could use the same registers you are using in your scheme. only, in my case, I can organize those wherever I want. Or use a stack. Or whatever.)

These 16 debug interrupt instructions at $400 allow for NSA-style complete interdiction of all cog execution. It's scary! It has a price, though: Your freedom to do whatever you want with hub memory. This is the debug solution for our brave new world. We could make it work on a per-cog basis, but why bother? That'd be like getting warrants, or something. What do you guys want? Are willing to give up a little freedom here? Are you wondering if you even have a choice?

Well, here's the thing. If I wanted to debug code loaded in the cog, couldn't I get the same effect by defining a debug_start routine in hub memory that would:

Then, whenever I want to debug a cog, I coginit cog_num, @debug_start. Wouldn't this give me the same result as what you have? Similarly, if I want to debug hub code, wouldn't the process be the same as above, except step 1?

(note: yes, I would somehow need to pass the start address, but I could use the same registers you are using in your scheme. only, in my case, I can organize those wherever I want. Or use a stack. Or whatever.)

That would work, of course. It would necessitate changing the code, though.

The way it is now with these vectors, you could debug whatever cog you wanted, without needing to get deep into what might be some indirect COGINIT setup. All you'd need to know is the cog number, and you could do it. It might be an interesting way to trap all kinds of profiling data with no cog being the wiser. It's really like the NSA now.

What if you make the debug interrupt global to all cogs? Then there would be only one long lost of hubram, and maybe it could be moved out of hubram into some global hub register. If you want debug only some cogs, then your debug handler could just immediately RETI0 when it gets run on cogs you don't want to debug.

Another big advantage of this is that you won't have to tell coginit which cog to use if you want to use debugging - you can let it start whichever cog it likes via D[4], and then have the debug interrupt handler look at ptrb and see whether or not the code should be debugged or if it should just immediately RETI0.

It would mean that the debug ISR would have to determine which cog he is and branch, again, to the appropriate handler.

I've just been playing around with this tonight and it is very powerful. It really is like the NSA. You can trap every cog starting up, and maintain a little database of what cog was started when, at what address, and then poll them to find out what they are doing, later. Imagine being able to just get a snapshot of any cog, at any time, with no setup, aside from the code monkeying with the vectors and some debug workspace. It's pretty wild! No need to plant hooks in your code, either. It just works.

It would mean that the debug ISR would have to determine which cog he is and branch, again, to the appropriate handler.

I've just been playing around with this tonight and it is very powerful. It really is like the NSA. You can trap every cog starting up, and maintain a little database of what cog was started when, at what address, and then poll them to find out what they are doing, later. Imagine being able to just get a snapshot of any cog, at any time, with no setup, aside from the code monkeying with the vectors and some debug workspace. It's pretty wild! No need to plant hooks in your code, either. It just works.

You sound pretty excited about this Chip so I am certainly intrigued enough to start playing with it as soon as I'm done with getting my software back to the point it was with the previous FPGA. Once I have an interactive environment running I will start to have some fun with this "debug" method.

Chip
I'm still getting the same error as above with the "B" version of Pnut.

I just downloaded from the new link and it is the new version. I verified I can do @ branches in hub space.

Are you sure you didn't mix up the old and new files, somehow?

Chip
I thought I made the mistake of running the old version but I am running the correct version.
I think Pnut is Ok now.
I am getting the same error but this time they are "real" and I am changing some of my relative jumps to absolute.
My code doesn't work anymore so it needs some tweaks to fit the new changes.

On the subject of Pnut version and FPGA image version, is it possible for the info dialog in pnut to reflect its real version and the required matching FPGA image version. The info dialog is the same as it was in all the P2-Hot pnut versions.

As this code is... cogs 2 and 3 blink at one hz and cog0 lights up but doesn't blink, but if I uncomment the ' djnz cognum,@:loop, it blinks at the same rate as cogs 2 and 3. So, if the djnz is in there, the cog0 falls through, but if there is no djnz, it doesn't?

Looks like you posted the wrong code as there isn't anything in :loop. However you need djns so that when there is a coginit in the loop it also executes for cog 0 which is also the one running the loop so that finally it never exits the djns loop since it has been coginit'd. Otherwise your code is falling through to the cognum as if it were an instruction. I think that's correct.

Chip
I'm still getting the same error as above with the "B" version of Pnut.

I just downloaded from the new link and it is the new version. I verified I can do @ branches in hub space.

Are you sure you didn't mix up the old and new files, somehow?

Chip
I thought I made the mistake of running the old version but I am running the correct version.
I think Pnut is Ok now.
I am getting the same error but this time they are "real" and I am changing some of my relative jumps to absolute.
My code doesn't work anymore so it needs some tweaks to fit the new changes.

On the subject of Pnut version and FPGA image version, is it possible for the info dialog in pnut to reflect its real version and the required matching FPGA image version. The info dialog is the same as it was in all the P2-Hot pnut versions.

Could you post a snippet of code that is failing?

Good idea about starting to use version numbers. I'll do that.

P.S. I understand now that PNut is okay, after all. I just didn't read carefully enough the first time.

I am trying to get Tachyon to compile and work properly but so far no joy. The compiler is touchy about the position of the intvecs, as it often says "Hub origin already exceeds target" or I get an error on coginit source of "constant must be from 0 to 511". I guess I am not quite fully understanding all the orgs and orghs and how they affect the compiler itself. I chopped out most of the code but unless I have a small program I get an error.

Can you confirm that the special registers are back at the top of cog ram.

The reason that 2nd ORG wasn't working was because it was only setting the cog origin, and not advancing within the hub image. use ORGF $100 to fill to cog $100, so that things are properly positioned.

There is another problem that I totally didn't anticipate. When you get to $100 in your cog image, beginning from hub $00000, you are already at $400! We need to change some things around.

Having these debug hooks SOMEWHERE provides a lot of surprising capabilities. It almost seems like cog exec and lut exec space should move to the END of hub RAM, as that will be where data wants to live, normally, trailing all executable code. Nobody will be inclined to put code there, I think, so it's useful for cog/lut exec space.

I don't how to make this look pretty, but there may be a simple way. Actually ORG would take care of this.

Importantly, this makes all lower memory just RAM, with the first 32 longs serving some fixed purposes. This moves cog/lut exec addresses to the hinterlands, where nobody probably cares about placing code, as it is the domain of large data buffers. This makes a lot of sense, I think.