flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler

1293032343570

Comments

  • Is the problem above because there is another label in between the rep and the rep destination?
  • Yep.
  • rogloh wrote: »
    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.
  • I just read the Propeller Manual on this subject and it doesn't say this, although I think it's true for the Propeller Tool too.

    It also mentions "global" labels, preceded by an underscore.
    I don't think I've ever used these...
  • 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.
  • potatohead wrote: »
    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".

    So I'd probably avoid that construct...
  • I think in spin1 you had to do
    LONG
    BYTE 1,2,3
    
    putting the LONG on a separate line. In SPIN2 we seem to have alignl.

    Mike
  • Indeed, I just checked myself. I know that has been done in the past though. I ran into a need myself and appear to have just misremembered.

    Looks like msrobots has it though. Long needs to be on it's own line.

    Prop Tool compiled this correctly:
    DAT
    
    Byte Long 00, 00, 00
    Word long 00, 11, 22
    Long long 22, 33, 00
    
    long
    byte $EE
    long
    byte $EE
    long
    byte $EE
    
    Pub Dummy
    

  • You can do that, but it wastes bytes in cog memory...
    The whole point of that P1 jump table in bytes or words was to save memory...
  • Then why were we discussing alignment? Somehow I got the bytes at long boundaries out of that.

    Weird.

  • I was trying to convert a P1 driver to P2. It gave an error on the jump table. PNut doesn't give the error...
  • Rayman wrote: »
    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.
    1157 x 373 - 85K
    1017 x 1770 - 498K
  • rogloh wrote: »
    ... t's really weird. My code runs but is not doing the right thing ...
    I'm guessing it's something like the displayed picture goes out of wack - horizontal misalignment or missing portion or duplication.

  • roglohrogloh Posts: 2,806
    edited 2019-12-07 - 02:21:14
    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.
  • The timing of hub RAM accesses changes depending on the memory alignment. Maybe that's the issue.
  • roglohrogloh Posts: 2,806
    edited 2019-12-07 - 02:29:19
    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.
  • roglohrogloh Posts: 2,806
    edited 2019-12-08 - 00:47:40
    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.
  • JRoak, what optimization level are you using, and did you keep it the same throughout your tests?
  • I’m using the default level of optimization.
  • 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.
  • ersmith wrote: »
    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.

  • Just looking at converting some spin1 code...

    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...
  • Yes, the argument to coginit/cognew is in ptra, and the address of the code being executed is in ptrb.
  • What is ptrb useful for, in this context?
  • It's just what the COGINIT instruction does with the newly started cog. You get told where in hubRAM your code was acquired from.
  • I'm just wondering in what scenario is this useful...
  • I've not used it.
Sign In or Register to comment.