Regarding gets() being slow... Did some testing and it seems specific to one of my custom boards with a P2 Edge module on it... Something strange must be going on there... Maybe the FTDI chip needs different programming settings or something...
@TonyB_ said:
Can't TJNS D,#S branch from cog to LUT RAM, e.g. a short forward jump from $1DE to $200? FlexSpin gives an error for this and similarly for CALLPB.
Is that legal? I thought relative branches have to stay inside the same RAM. Does PNut let you try this? And if so, does it actually work?
@TonyB_ said:
Can't TJNS D,#S branch from cog to LUT RAM, e.g. a short forward jump from $1DE to $200? FlexSpin gives an error for this and similarly for CALLPB.
Is that legal? I thought relative branches have to stay inside the same RAM. Does PNut let you try this? And if so, does it actually work?
I think it is legal, but I can't use PNut to confirm.
The BRANCH ADDRESSING section of the doc discusses DJxx, IJxx, TJxx, CALLPx and a few others. It states that "their immediate range is -256 to +255 instructions, relative to the instruction after the branch."
I guess that a forward jump from the top of LUT RAM wraps around to the bottom of cog RAM for these call or jump to S** instructions.
I tested the hardware ages back but can't quite remember the details. I think COGRAM<->LUTRAM worked fine but I'm not certain now. LUTRAM to HUBRAM was a bit screwy but did work with an offset calculation. Going back to LUTRAM was different but I've forgotten in what way. HUBRAM wrapping back to COGRAM at the zero boundary was super screwy in that it would fetch from COGRAM but the PC was above 1 MB. Which caused some predictably weird behaviour.
@evanh said:
I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.
PS: I had to hand code the machine code in Flexspin. The assembler gave me invalid offset ... as well as the error message.
Thanks, Evan. FlexSpin seems to get encoding right currently apart from incorrect S field = $1FF. Branch from ~$180 to $202 works. Next logical test would be ~$380 to $002.
Testing that it seems to be precisely scaled as longwords below $400 and bytes from $400 up. Which makes sense given that is the documented addressing. So a relative branch of $100 from $380 in lutRAM will land at $480 in hubRAM.
On the other hand, if there is no branch and you execute off the end of lutRAM it will wrap back to cogRAM, albeit with the program counter ticking along above $400, because hubexec will only trigger on a branch.
@evanh said:
Testing that it seems to be precisely scaled as longwords below $400 and bytes from $400 up. Which makes sense given that is the documented addressing. So a relative branch of $100 from $380 in lutRAM will land at $480 in hubRAM.
@evanh said:
On the other hand, if there is no branch and you execute off the end of lutRAM it will wrap back to cogRAM, albeit with the program counter ticking along above $400, because hubexec will only trigger on a branch.
Thanks for the extra testing, Evan.
I think there might be something else apart from PC that wraps around from end of LUT RAM to start of cog RAM, from a discussion a few months ago.
@evanh said:
A regression - Binary inversion operator gets following error: spin-compile-test.spin2:6: error: assignment to constantTEST_CONSTANT'`
con
TEST_CONSTANT = 10
PUB begin()
waitms( ~TEST_CONSTANT )
No, the previous behavior was the incorrect one (unfortunately). "~" is documented to modify its operand, so it cannot be applied to a constant. I've verified this with openspin.
Incidentally, ~x is not the binary inversion operator: it sign extends x from bit 7. Binary inversion would be !x
Huh, okay, I admit I assumed it's function. I don't really know Spin all the well. I struck the error when compiling Roger's video driver. I guess it's time to clarify with Roger what his intent is.
EDIT: Duh! Of course Roger has already fixed it, and is now using the ! operator, with the newest release. Didn't think to check until I went hunting for the driver topic. O_o
@evanh said:
I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.
Thanks for checking this. I'll disable the error in flexspin then.
You better look over my testing example too. That result was for the hardware with the appropriate machine code, not Flexspin. The assembler also needs fixed.
@evanh said:
I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.
Thanks for checking this. I'll disable the error in flexspin then.
You better look over my testing example too. That result was for the hardware with the appropriate machine code, not Flexspin. The assembler also needs fixed.
No, the bad code was just because a dummy address was inserted at the point of the error to stop the error from appearing again. Now that the error is disabled the assembler is generating the same bytes as the original LONG did (this is with the github version of flexspin).
@evanh said:
I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.
Thanks for checking this. I'll disable the error in flexspin then.
You better look over my testing example too. That result was for the hardware with the appropriate machine code, not Flexspin. The assembler also needs fixed.
No, the bad code was just because a dummy address was inserted at the point of the error to stop the error from appearing again. Now that the error is disabled the assembler is generating the same bytes as the original LONG did (this is with the github version of flexspin).
Where exactly is the new flexspin.exe?
flexprop5.5.1.zip is the same as before with bad code.
@evanh said:
I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.
Thanks for checking this. I'll disable the error in flexspin then.
You better look over my testing example too. That result was for the hardware with the appropriate machine code, not Flexspin. The assembler also needs fixed.
No, the bad code was just because a dummy address was inserted at the point of the error to stop the error from appearing again. Now that the error is disabled the assembler is generating the same bytes as the original LONG did (this is with the github version of flexspin).
Where exactly is the new flexspin.exe?
flexprop5.5.1.zip is the same as before with bad code.
@evanh said:
I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.
Thanks for checking this. I'll disable the error in flexspin then.
You better look over my testing example too. That result was for the hardware with the appropriate machine code, not Flexspin. The assembler also needs fixed.
No, the bad code was just because a dummy address was inserted at the point of the error to stop the error from appearing again. Now that the error is disabled the assembler is generating the same bytes as the original LONG did (this is with the github version of flexspin).
Where exactly is the new flexspin.exe?
flexprop5.5.1.zip is the same as before with bad code.
It's the checked in source version. There hasn't been a new binary release (and likely won't be for a little while).
Comments
Regarding gets() being slow... Did some testing and it seems specific to one of my custom boards with a P2 Edge module on it... Something strange must be going on there... Maybe the FTDI chip needs different programming settings or something...
Solved now, thanks, too many late nights recently.
Can't
TJNS D,#Sbranch from cog to LUT RAM, e.g. a short forward jump from $1DE to $200? FlexSpin gives an error for this and similarly forCALLPB.Is that legal? I thought relative branches have to stay inside the same RAM. Does PNut let you try this? And if so, does it actually work?
I think it is legal, but I can't use PNut to confirm.
The BRANCH ADDRESSING section of the doc discusses DJxx, IJxx, TJxx, CALLPx and a few others. It states that "their immediate range is -256 to +255 instructions, relative to the instruction after the branch."
I guess that a forward jump from the top of LUT RAM wraps around to the bottom of cog RAM for these call or jump to S** instructions.
I tested the hardware ages back but can't quite remember the details. I think COGRAM<->LUTRAM worked fine but I'm not certain now. LUTRAM to HUBRAM was a bit screwy but did work with an offset calculation. Going back to LUTRAM was different but I've forgotten in what way. HUBRAM wrapping back to COGRAM at the zero boundary was super screwy in that it would fetch from COGRAM but the PC was above 1 MB. Which caused some predictably weird behaviour.
Oh, it only works if branching. You can't walk from LUTRAM to HUBRAM with sequential fetches. Don't remember for COGRAM to LUTRAM but likely the same.
I remember that boundary crossing needs to be absolute addressed not relative.
Not sure from where I got that.
Mike
Jumping to and from hub RAM is not relevant to the suspected FlexSpin problem with the S** group of instructions.
I wasn't testing the assemblers. I was testing the hardware. But my memory is not clear on which test was what any longer ...
deleted
I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.
PS: I had to hand code the machine code in Flexspin. The assembler gave me invalid offset ... as well as the error message.
Tidied it up. Requires flexspin, the attached wrapper, and open terminal (I use loadp2) for reporting:
CON XTALFREQ = 20_000_000 'PLL stage 0: crystal frequency XDIV = 2 'PLL stage 1: crystal divider (1..64) XMUL = 10 'PLL stage 2: crystal / div * mul (1..1024) XDIVP = 4 'PLL stage 3: crystal / div * mul / divp (1,2,4,6..30) LUT_reserved = 8 DAT 'not Spin code ORG 0 '****************************************************************************** msec jmp #_diaginit xtalmul long XMUL hw_rev long 0 'hubRAM addr $010 - unused reserved parameter - using to hold revA/B clk_freq long 25_000_000 'hubRAM addr $014 - sysclock frequency, integer frequency in hertz clk_mode long 0 'hubRAM addr $018 - clock mode config word, used directly in HUBSET asyn_baud long 230_400 'hubRAM addr $01c - comport baud rate, integer baud in hertz '-------------------------------------------------------- _main mov bcdlen, #8 setq2 #(lut4 - lut1 - 1) rdlong 0, ##@lut1 'copy into lutRAM at $200 setq #(cog5 - cog3 - 1) rdlong cog3, ##@cog3 'copy into cogRAM at $180 setq #(cog2 - cog1 - 1) rdlong 0, ##@cog1 'copy into cogRAM at $0 jmp #cog4 report pop pa call #itoh mov pa, ptra call #puts jmp #$ ORG 0 cog1 loc ptra, #msg_fail call #\report 'has to be absolute encoded branch address cog2 ORG $180 cog3 loc ptra, #msg_fail call #\report 'has to be absolute encoded branch address cog4 loc pa, #msg_start call #puts mov pa, #100 ' djnf pa, #lut3 '7c Ec 7F FB long $fb7fec7c loc ptra, #msg_fail call #\report 'has to be absolute encoded branch address cog5 ORG $200 lut1 loc ptra, #msg_fail call #\report 'has to be absolute encoded branch address lut3 loc ptra, #msg_lut call #\report 'has to be absolute encoded branch address lut4 ORGH $400 loc ptra, #msg_fail call #\report 'has to be absolute encoded branch address msg_start byte "Start ... ",0 msg_hub byte " in hubRAM",13,10,0 msg_lut byte " in lutRAM",13,10,0 msg_cog byte " in cogRAM",13,10,0 msg_fail byte " fail :-(",13,10,0 '****************************************************************************** ' Subroutines '****************************************************************************** #include "init-diag.spin2"EDIT: Typos
A regression - Binary inversion operator gets following error:
spin-compile-test.spin2:6: error: assignment to constantTEST_CONSTANT'`con TEST_CONSTANT = 10 PUB begin() waitms( ~TEST_CONSTANT )Thanks, Evan. FlexSpin seems to get encoding right currently apart from incorrect S field = $1FF. Branch from ~$180 to $202 works. Next logical test would be ~$380 to $002.
Relative positive branch from $380 will land in hubRAM. Triggering hubexec and the FIFO.
Testing that it seems to be precisely scaled as longwords below $400 and bytes from $400 up. Which makes sense given that is the documented addressing. So a relative branch of $100 from $380 in lutRAM will land at $480 in hubRAM.
On the other hand, if there is no branch and you execute off the end of lutRAM it will wrap back to cogRAM, albeit with the program counter ticking along above $400, because hubexec will only trigger on a branch.
And you can't walk off the end of cogRAM because the special purpose registers at the end of cogRAM will crash your code.
Thanks for the extra testing, Evan.
I think there might be something else apart from PC that wraps around from end of LUT RAM to start of cog RAM, from a discussion a few months ago.
Thanks for checking this. I'll disable the error in flexspin then.
No, the previous behavior was the incorrect one (unfortunately). "~" is documented to modify its operand, so it cannot be applied to a constant. I've verified this with openspin.
Incidentally,
~xis not the binary inversion operator: it sign extendsxfrom bit 7. Binary inversion would be!xHuh, okay, I admit I assumed it's function. I don't really know Spin all the well. I struck the error when compiling Roger's video driver. I guess it's time to clarify with Roger what his intent is.
EDIT: Duh! Of course Roger has already fixed it, and is now using the ! operator, with the newest release. Didn't think to check until I went hunting for the driver topic. O_o
You better look over my testing example too. That result was for the hardware with the appropriate machine code, not Flexspin. The assembler also needs fixed.
No, the bad code was just because a dummy address was inserted at the point of the error to stop the error from appearing again. Now that the error is disabled the assembler is generating the same bytes as the original LONG did (this is with the github version of flexspin).
Oh, thanks for the info.
Where exactly is the new flexspin.exe?
flexprop5.5.1.zip is the same as before with bad code.
Where exactly is the new flexspin.exe?
flexprop5.5.1.zip is the same as before with bad code.
It's the checked in source version. There hasn't been a new binary release (and likely won't be for a little while).
aaaw! didn't do lut<->hub