Is the problem above because there is another label in between the rep and the rep destination?
The problem is that any dot label only is valid until the next non-dot label. So if you use ".endnormal" for the rep destination, don't put non-dot labels inside the rep loop.
In Spin 2, the most likely way to insure alignment would be (bytes, long aligned example)
Long byte 00, 10, 12....
That would place each byte at a long boundary.
Spin 1 supports this now.
That doesn't seem to work:
dat
long byte 00, 10, 12
pub dummy
produces "foo.spin(3:10) : error : Size override must be larger" in both bstc and openspin.
which is interesting; it means you can do:
dat
byte long 00, 10, 12
to get byte-aligned long words. But bstc and openspin handle these differently. bstc apparently only treats the first 00 as a long, with the 10 and 12 coming out as bytes. openspin treats them all as longs.
PNut_v34L reports an error ("Expected a constant, unary operator, or "(") at the "long".
I was trying to convert a P1 driver to P2. It gave an error on the jump table. PNut doesn't give the error...
And just to clarify it wasn't the jump table itself that was a problem, it was the stuff after it (because the jump table was made of bytes it left the PC unaligned). I've changed fastspin so that it will automatically align instructions in COG mode (like PNut does) but for now you can work around the problem by putting "alignl" after the jump table.
Speaking of alignment I am seeing some sensitivity in my fastspin compiled code to alignment. I have built images that vary the amount of zero padding at the end and see a problem repeating on 8 long boundaries. Initially I had this problem when I changed the code size, and I've since isolated it to simply varying padding right at the end of the image to trigger the issue.
So the only difference now between good and bad operation is the number of longs at the end of the fastspin image before its "objmem" and "stackspace" variables. It's really weird. My code runs but is not doing the right thing and perhaps some memory is being corrupted somewhere to trigger its bad behaviour but it possibly might still be a bug in my own code, though I don't know where. Still trying to isolate and track it down and collect more information. Not all my images show this behaviour, but they can access memory differently and that may be part of it.
Funny thing I noticed was that the fastspin binary output seems to be the same file size for both the good and bad images even though one pads with more longs in the listing file. Is there file rounding/truncation going on somewhere in fastspin? Or perhaps this is also occurring in the loader that downloads the image?
None of the address parameters in my PASM driver code seem to be sensitive to varying start addresses which was a performance concern of mine. I've varied the font/screen/linebuffer/palette etc over all 8 sequential long address boundaries without issues, and in theory they don't change anyway with the zero padding I am doing at the end. So it's just the zero padding right at the end that is different between good and bad images, plus the objptr and ptr_stackspace_ values that are different in the diffs below. These are likely critical parameters for fastspin to keep running correctly.
I've attached the two screencaptures of the only diff's in the good vs bad images. The good case is larger in output in the listing, though if I add 8 longs to the bad case it would then fail. It appears to be repeating, apparently on a egg-beater boundary, somewhere at the end of the image that is contributing to this problem.
Binary output file size for both cases was 27040 bytes (0x69A0) even though they are different in the listing files. All file diffs between good/bad images are shown below.
It's actually composite sync pulses remaining active but no image data portion present (seems like it's CY argument is stuck at zero or something). Monitor won't then sync to it in the bad case. It reliably happens when I alter the amount of long padding be some multiple of 8. I think 4 of the 8 pad values work, and the other 4 don't work but need to verify that for sure.
Yeah sure enough, pad it with long counts from 1-4 it fails, pad from 5-8 is okay, pad from 9-12 fails etc. Definitely some hub pattern. Funny thing is my code is getting the same buffer addresses. Perhaps the spin setup code passing arguments doesn't like reading data pointers on the stack from different hub boundaries? That's what could be changing with this padding.
I'm not sure it is a PASM driver issue, but haven't been able to rule it out yet either.
It does, but the weird thing is that this change I am making should not even be modifying the addresses being fed into my driver. It's just padding at the end before the Fastspin stack and other objmem stuff. My various static buffer spaces are still at the same addresses I would expect.
I've found through adding debug printing of the addresses of my key data structures, that by padding with longs at the end of the fastspin image, only the VAR structures in memory I pass into my driver get moved around, but the runtime buffers used remain at the same locations (as I expected). So it appears something is being messed up upon startup of my driver. I imagine the wrong parameters must be being read in. I need to dump out to memory what I read in from my driver at startup to see why this is happening. It would appear to be more SPIN oriented right now unless I do something weird with the addresses I read from at the start of my code.
Update: Looking like it may possibly be some type of bug in my code...this code doesn't loop correctly when reading its parameters from certain egg beater offset addresses for some reason and appears to stay in some inner loop sending sync pulses. Very weird. Might be a setq+rdlong type of problem somewhere, still homing in, or perhaps it gets a 0 somewhere and this effectively loops infinitely in a rep/djnz loop.
Update2: will continue any further discussion of this issue in my main driver thread so as not to pollute this thread any more unless it comes back to fastspin which at this point looks like it may not...I have found an infinite loop candidate in one case but don't quite yet know how it comes to be from parameter address offsets.
When using FlexGUI 4.0.4, under Win10 and coding in BASIC for the P2-EVAL rev B board:
@ersmith It appears the FlexBASIC PauseMS() and OUTPUT() functions are misbehaving. Their performance seems to be strangely intertwined with the PRINT statement. This is really bizarre. Check this out:
_setbaud(230400)
pauseMS(50)
direction(0) = output
print "Here we go..." '<---- commenting this out changes speed in loop below
do
PauseMS(10) '<-- see below
output(0) = 0
PauseMS(10) '<-- see below
output(0) = 1
loop
Run the snippet above verbatim with Pin 0 hooked to a scope or freq counter. With the PRINT statement active, the resulting waveform is ~50 hz. That's about what we expect. But if we comment-out the PRINT statement, the output waveform freq jumps to ~21.280 khz. The print statement before the loop changes the loop timing.
It gets wierder: Comment-out the PRINT statement and also both of the PAUSEMS() statements. The waveform freq jumps to ~1.02 MHZ. Now leave the PAUSEMS() statements commented-out and uncomment the PRINT statement and the output freq jumps to ~6.66 mhz.
The answer is that the print statement sets the clock to 160 MHz if it isn't already set. That's not a good way to do it, I plan to change it eventually, but for now if you explicitly call clkset() you can avoid the mysterious behavior.
The answer is that the print statement sets the clock to 160 MHz if it isn't already set. That's not a good way to do it, I plan to change it eventually, but for now if you explicitly call clkset() you can avoid the mysterious behavior.
That makes perfect sense, Eric. Thanks for the quick response.
Comments
The problem is that any dot label only is valid until the next non-dot label. So if you use ".endnormal" for the rep destination, don't put non-dot labels inside the rep loop.
It also mentions "global" labels, preceded by an underscore.
I don't think I've ever used these...
Long byte 00, 10, 12....
That would place each byte at a long boundary.
Spin 1 supports this now.
That doesn't seem to work: produces "foo.spin(3:10) : error : Size override must be larger" in both bstc and openspin.
which is interesting; it means you can do: to get byte-aligned long words. But bstc and openspin handle these differently. bstc apparently only treats the first 00 as a long, with the 10 and 12 coming out as bytes. openspin treats them all as longs.
PNut_v34L reports an error ("Expected a constant, unary operator, or "(") at the "long".
So I'd probably avoid that construct...
Mike
Looks like msrobots has it though. Long needs to be on it's own line.
Prop Tool compiled this correctly:
The whole point of that P1 jump table in bytes or words was to save memory...
Weird.
And just to clarify it wasn't the jump table itself that was a problem, it was the stuff after it (because the jump table was made of bytes it left the PC unaligned). I've changed fastspin so that it will automatically align instructions in COG mode (like PNut does) but for now you can work around the problem by putting "alignl" after the jump table.
So the only difference now between good and bad operation is the number of longs at the end of the fastspin image before its "objmem" and "stackspace" variables. It's really weird. My code runs but is not doing the right thing and perhaps some memory is being corrupted somewhere to trigger its bad behaviour but it possibly might still be a bug in my own code, though I don't know where. Still trying to isolate and track it down and collect more information. Not all my images show this behaviour, but they can access memory differently and that may be part of it.
Funny thing I noticed was that the fastspin binary output seems to be the same file size for both the good and bad images even though one pads with more longs in the listing file. Is there file rounding/truncation going on somewhere in fastspin? Or perhaps this is also occurring in the loader that downloads the image?
None of the address parameters in my PASM driver code seem to be sensitive to varying start addresses which was a performance concern of mine. I've varied the font/screen/linebuffer/palette etc over all 8 sequential long address boundaries without issues, and in theory they don't change anyway with the zero padding I am doing at the end. So it's just the zero padding right at the end that is different between good and bad images, plus the objptr and ptr_stackspace_ values that are different in the diffs below. These are likely critical parameters for fastspin to keep running correctly.
I've attached the two screencaptures of the only diff's in the good vs bad images. The good case is larger in output in the listing, though if I add 8 longs to the bad case it would then fail. It appears to be repeating, apparently on a egg-beater boundary, somewhere at the end of the image that is contributing to this problem.
Binary output file size for both cases was 27040 bytes (0x69A0) even though they are different in the listing files. All file diffs between good/bad images are shown below.
I'm not sure it is a PASM driver issue, but haven't been able to rule it out yet either.
Update: Looking like it may possibly be some type of bug in my code...this code doesn't loop correctly when reading its parameters from certain egg beater offset addresses for some reason and appears to stay in some inner loop sending sync pulses. Very weird. Might be a setq+rdlong type of problem somewhere, still homing in, or perhaps it gets a 0 somewhere and this effectively loops infinitely in a rep/djnz loop.
Update2: will continue any further discussion of this issue in my main driver thread so as not to pollute this thread any more unless it comes back to fastspin which at this point looks like it may not...I have found an infinite loop candidate in one case but don't quite yet know how it comes to be from parameter address offsets.
@ersmith It appears the FlexBASIC PauseMS() and OUTPUT() functions are misbehaving. Their performance seems to be strangely intertwined with the PRINT statement. This is really bizarre. Check this out: Run the snippet above verbatim with Pin 0 hooked to a scope or freq counter. With the PRINT statement active, the resulting waveform is ~50 hz. That's about what we expect. But if we comment-out the PRINT statement, the output waveform freq jumps to ~21.280 khz. The print statement before the loop changes the loop timing.
It gets wierder: Comment-out the PRINT statement and also both of the PAUSEMS() statements. The waveform freq jumps to ~1.02 MHZ. Now leave the PAUSEMS() statements commented-out and uncomment the PRINT statement and the output freq jumps to ~6.66 mhz.
That makes perfect sense, Eric. Thanks for the quick response.
Looks like the Spin cognew puts the second argument into PTRA, where P1 it went to PAR.
Am I seeing this right?
What gets put in the PTRB? Looks like this is where PASM2 coginit loads with the source...