What constitutes the end of a debug ISR is 'CALLD anyreg,INB WC,WZ'. So, you could definitely exit via 'CALLD INA,INB WC,WZ' and resume your ISR on the next debug interrupt.
Does this Debug action consume a stack level ?
ie Can you debug a COG, that needs 8 levels of Stack ?
No. It doesn't use any stack. It uses the INA/INB RAM registers with CALLD, which used to be called LINK.
I'm trying to port pfth to the P2, and I ran into a couple of problems. The first issue is with long alignment (or lack of) when using the LONG keyword. Since the P2 doesn't require long alignment it appears that the LONG keyword just continues from the last address and does not pad out with zeroes to align a long variable. The dictionary in pfth requires long alignment, so I had to add extra zero bytes after a BYTE variable to enforce long alignment.
The other issue is that the FILE directive doesn't seem to be implemented. pfth includes several text files using the FILE directive. I will have to insert the text manually to work around this.
I got pfth working on the DE2-115 board with the 10_10_15 FPGA. I had to fix a few more alignment problems, and I inserted the initial Forth code as quoted strings instead of using the FILE directive. When pfth starts up it compiles the embedded Forth code and then prints out "P2 pfth 1.03" when ready. Type "words" to list the words in the dictionary.
Peter, I need to improve the assembler syntax. In your COGINIT, the S is a register. Put a # in front of the @.
But it does, just like the blink example and it seems to execute code but it doesn't seem to work correctly. I've had some sleep too, so I will get back into finding out what's going on.
I got pfth working on the DE2-115 board with the 10_10_15 FPGA. I had to fix a few more alignment problems, and I inserted the initial Forth code as quoted strings instead of using the FILE directive. When pfth starts up it compiles the embedded Forth code and then prints out "P2 pfth 1.03" when ready. Type "words" to list the words in the dictionary.
Great work Dave, I'm still trying to get Tachyon to compile properly under the new version !!
Following on from my post above
Dopping a waitx instead of the loop works too.
waitx ##15_378 'minimum value that works?
Thanks for that, that simple waitx brought everything back to life again, and my sanity too. No hang on a minute, I lost that a long time ago, oh well you have to be crazy to do this stuff I guess
I just updated the doc's (see 1st post in this thread) to cover the hub FIFO interface.
Writing documentation is difficult for me because it's not only a lot work, but I know that whatever I write won't be in the final, proper, context, so I'll have to redo it all before it's "done".
Anyway, I wrote tonight about how RDFAST/WRFAST/FBLOCK work, along with RFBYTE/RFWORD/RFLONG and WFBYTE/WFWORD/WFLONG. This has been a gaping hole in everyone's understanding.
I'm really surprised you guys are able to do all you are doing with so little documentation. Hopefully, I can fill you in before you burn out from the stress of dealing with so much ambiguity.
One thing that is driving everyone nuts is the "@" operator. It was originally used to get the hub address of things. Then, it was used for relative branches. Now, it does both! Branches check for @ at the beginning of the address, and use it to compute relative offsets. If you use '@label' in a non-branch instruction, it means 'the absolute address of in hub memory'. What we need to do is differentiate these two cases of '@' so that one stays '@' and the other becomes some other character, like a back-tick or caret or something - anything else!
One thing that is driving everyone nuts is the "@" operator. It was originally used to get the hub address of things. Then, it was used for relative branches. Now, it does both! Branches check for @ at the beginning of the address, and use it to compute relative offsets. If you use '@label' in a non-branch instruction, it means 'the absolute address of in hub memory'. What we need to do is differentiate these two cases of '@' so that one stays '@' and the other becomes some other character, like a back-tick or caret or something - anything else!
I'm not quite sure I'm following. I get that P1 used @, but let's put that aside for the moment. The address of a label depends on which section it's in (ORG/ORGH). When you have an instruction operand that begins with "@", it means immediate-relative. When it begins with "#" it means immediate-absolute. The one edge case is when you want an ORG label, but with a ORGH address. For that, I believe you have "#@", which is also immediate-absolute.
Is that not enough?
Also, can we get rid of "##" and just go with "#"? The assembler can still implicitly insert an AUGx when the value is greater than $1FF. As it stands right now:
# : Use for 9-bit immediates, or for 20-bit immediates, or in AUGx instructions
## : Use for short-hand to insert AUGx instruction (even if the value is less than $200). Does not apply to instructions with 20-bit immediates.
And I'm suggesting:
# : User for immediates. If a 9-bit immediate is expected and the value is greater than $1FF, an AUGx is inserted.
Does seem like we could use an "align" compiler keyword.
Was just reading new fifo doc and it says data needs to be long aligned for looping. But, there's no way to tell compiler to make a table long aligned now, right?
Yes, an align compiler instruction would be nice. Accessing aligned longs and words is more efficient than unaligned accesses, and it will help in porting existing P1 code that required alignment.
I'm not quite sure I'm following. I get that P1 used @, but let's put that aside for the moment. The address of a label depends on which section it's in (ORG/ORGH). When you have an instruction operand that begins with "@", it means immediate-relative. When it begins with "#" it means immediate-absolute. The one edge case is when you want an ORG label, but with a ORGH address. For that, I believe you have "#@", which is also immediate-absolute.
Is that not enough?
Also, can we get rid of "##" and just go with "#"? The assembler can still implicitly insert an AUGx when the value is greater than $1FF. As it stands right now:
# : Use for 9-bit immediates, or for 20-bit immediates, or in AUGx instructions
## : Use for short-hand to insert AUGx instruction (even if the value is less than $200). Does not apply to instructions with 20-bit immediates.
And I'm suggesting:
# : User for immediates. If a 9-bit immediate is expected and the value is greater than $1FF, an AUGx is inserted.
Actually, if you were to make the change I suggest, we could use ## instead of #@. That way, you would have the following:
# : absolute immediate. In ORGH sections, value is in bytes. In ORG sections, value is in longs/register. If necessary, an AUGx will be inserted.
## : ORGH absolute immediate (regardless of which section the label is defined). If necessary, an AUGx will be inserted.
@ : relative immediate. Follows the same rules as it currently does.
There is no need for an "ORGH relative immediate" because you can't use relative addressing to jump from cog to hub exec mode.
Comments
No. It doesn't use any stack. It uses the INA/INB RAM registers with CALLD, which used to be called LINK.
I think I like how debugging is working out.
Chip,
After you get some well earned sleep, any chance of a DE0-Nano or BeMicroCV (A2) FPGA image (pretty please) ???
Didn't see anything on LED0 until I did this:
Should this be added?
The other issue is that the FILE directive doesn't seem to be implemented. pfth includes several text files using the FILE directive. I will have to insert the text manually to work around this.
That was quick. I looked at porting it with one of the first FPGA images and gave up. It was more clever than I am!
But it does, just like the blink example and it seems to execute code but it doesn't seem to work correctly. I've had some sleep too, so I will get back into finding out what's going on.
Like Peter I am having issues with INB.
I found a work around that might shed a clue as to what is happening. After doing the loop INB seems to work Ok from then on.
Is there a some sort of conflict with the shadow registers?
Great work Dave, I'm still trying to get Tachyon to compile properly under the new version !!
Shouldn't that be 31?
Dopping a waitx instead of the loop works too.
Writing documentation is difficult for me because it's not only a lot work, but I know that whatever I write won't be in the final, proper, context, so I'll have to redo it all before it's "done".
Anyway, I wrote tonight about how RDFAST/WRFAST/FBLOCK work, along with RFBYTE/RFWORD/RFLONG and WFBYTE/WFWORD/WFLONG. This has been a gaping hole in everyone's understanding.
I'm really surprised you guys are able to do all you are doing with so little documentation. Hopefully, I can fill you in before you burn out from the stress of dealing with so much ambiguity.
One thing that is driving everyone nuts is the "@" operator. It was originally used to get the hub address of things. Then, it was used for relative branches. Now, it does both! Branches check for @ at the beginning of the address, and use it to compute relative offsets. If you use '@label' in a non-branch instruction, it means 'the absolute address of in hub memory'. What we need to do is differentiate these two cases of '@' so that one stays '@' and the other becomes some other character, like a back-tick or caret or something - anything else!
Are we using tilde yet? "~"
I'm not quite sure I'm following. I get that P1 used @, but let's put that aside for the moment. The address of a label depends on which section it's in (ORG/ORGH). When you have an instruction operand that begins with "@", it means immediate-relative. When it begins with "#" it means immediate-absolute. The one edge case is when you want an ORG label, but with a ORGH address. For that, I believe you have "#@", which is also immediate-absolute.
Is that not enough?
Also, can we get rid of "##" and just go with "#"? The assembler can still implicitly insert an AUGx when the value is greater than $1FF. As it stands right now:
# : Use for 9-bit immediates, or for 20-bit immediates, or in AUGx instructions
## : Use for short-hand to insert AUGx instruction (even if the value is less than $200). Does not apply to instructions with 20-bit immediates.
And I'm suggesting:
# : User for immediates. If a 9-bit immediate is expected and the value is greater than $1FF, an AUGx is inserted.
How about the grave accent"`". Same key as the tilde but no shift key required, and it's similar to how we spec 7400 series chips.
Thanks. I was using the wrong PNUT and the wrong .rbf file and had to leave in a hurry. Other than that...
Everything is fine now.
Rich
Was just reading new fifo doc and it says data needs to be long aligned for looping. But, there's no way to tell compiler to make a table long aligned now, right?
label long long 0 'should produce long aligned longs!
label byte word 0 'should produce a word aligned byte
dat orgh 0 label1 byte 0 label2 long 0label1 has an address of 0, and label2 has an address of 1.Actually, if you were to make the change I suggest, we could use ## instead of #@. That way, you would have the following:
# : absolute immediate. In ORGH sections, value is in bytes. In ORG sections, value is in longs/register. If necessary, an AUGx will be inserted.
## : ORGH absolute immediate (regardless of which section the label is defined). If necessary, an AUGx will be inserted.
@ : relative immediate. Follows the same rules as it currently does.
There is no need for an "ORGH relative immediate" because you can't use relative addressing to jump from cog to hub exec mode.
How simple is that?