Shop Learn P1 Docs P2 Docs Events
FlexProp: a complete programming system for P2 (and P1) - Page 34 — Parallax Forums

FlexProp: a complete programming system for P2 (and P1)

1313234363741

Comments

  • pik33pik33 Posts: 1,844

    I downloaded a Windows version of 5.9.10 to test. There are 2 main differences from the Linux environment:

    (1) The internal terminal window gets focus on mouse over (you don't need to click it)
    (2) Use "compile and run" the first time, it works. The second time:

    Could not find a P2 on port \\.\COM3                                            
    Press enter to continue... 
    

    Then, the next "compile and run" works - every second one works.

  • @pik33 said:
    I downloaded a Windows version of 5.9.10 to test. There are 2 main differences from the Linux environment:

    (1) The internal terminal window gets focus on mouse over (you don't need to click it)
    (2) Use "compile and run" the first time, it works. The second time:

    Could not find a P2 on port \\.\COM3                                            
    Press enter to continue... 
    

    Then, the next "compile and run" works - every second one works.

    I don't see that at all on my Windows system. Do you have something programmed in the flash? Perhaps that's causing a timeout on every second run. You could try changing the DIP switches on the P2 board to skip flash booting.

  • pik33pik33 Posts: 1,844

    Yes, there is a flashed program always there :) but Linux version doesn't do this (=every compile+run works) using the same PC and P2 Eval board.
    After upgrading Xubuntu to 22.02 the audio subsystem works and I am now on Linux again (this not working audio made me to temporarily switch to Windows, but now it is solved)

    And now I discovered Linux version also switches the focus on the terminal window mouse over so there is no difference between versions.

  • evanhevanh Posts: 14,024

    Defaults change, and copy-catting occurs:

  • I've uploaded FlexProp 5.9.11 to Patreon and github. This version has a number of bug fixes, and is signed with a new Windows code signing certificate which may reduce the number of warnings from anti-virus programs (the old one had expired and I hadn't noticed!)

  • Eric,

    Latest from git on my mac has issues with the loader.

    Also from terminal cmd-c and cmd-a doesn't work but right click copy does

    ERROR: timeout waiting for initial checksum: got -1
    Try increasing the FIFO setting if not large enough for your setup
    Press enter to continue...

  • @"Greg LaPolla" said:
    Latest from git on my mac has issues with the loader.
    ERROR: timeout waiting for initial checksum: got -1
    Try increasing the FIFO setting if not large enough for your setup
    Press enter to continue...

    Does this happen all the time or just sometimes? Is it new behavior? If you replace the loadp2.mac file from an older release, does it start working again?

    I did make one small change in the most recent git (to increase the FIFO setting slightly) which should have made that problem less likely to occur rather than more, so any additional information you could give would be helpful.

    Thanks,
    Eric

  • @ersmith said:

    Does this happen all the time or just sometimes? Is it new behavior? If you replace the loadp2.mac file from an older release, does it start working again?

    I did make one small change in the most recent git (to increase the FIFO setting slightly) which should have made that problem less likely to occur rather than more, so any additional information you could give would be helpful.

    Thanks,
    Eric

    It happens all the time. I restored 5.9.10 from time machine and it was able to upload without any issues.

    My mac is a 2019 macbook pro 16 inch. Intel Proc.

    I also tried to set the fifo higher and it didn't make any difference.

  • @"Greg LaPolla" : I've reverted the FIFO size change in the FlexProp repository; I hope this will fix the problem on your mac.

  • @ersmith said:
    @"Greg LaPolla" : I've reverted the FIFO size change in the FlexProp repository; I hope this will fix the problem on your mac.

    Thanks Eric. The issue is fixed on my end now!

  • I've uploaded FlexProp 5.9.12, which contains a number of bug fixes and enhancements, some of which are pretty useful for NeoYume.

    The signed binaries are available from my Patreon and from github (see my signature for details).

  • pik33pik33 Posts: 1,844

    Changes I can notice with the Prop2Play:

    Prop2Play doesn't compile any more with standard optimization:

    /home/pik33/Programowanie/P2-retromachine/Propeller/P2P16/player29.p2asm:55552: error: fit 480 failed: pc is 608
    

    However, there is a new "size optimization" which works,

    but "full optimization" does not work with the player. Instead, it hangs up theflexprop which stops responding at all. Flexspin has to be killed from a command line. (Ubuntu Studio 22.02)

  • @pik33 said:
    Changes I can notice with the Prop2Play:

    Prop2Play doesn't compile any more with standard optimization:

    /home/pik33/Programowanie/P2-retromachine/Propeller/P2P16/player29.p2asm:55552: error: fit 480 failed: pc is 608
    

    However, there is a new "size optimization" which works,

    but "full optimization" does not work with the player. Instead, it hangs up theflexprop which stops responding at all. Flexspin has to be killed from a command line. (Ubuntu Studio 22.02)

    I'm not able to reproduce this with the code from https://gitlab.com/pik33/P2-retromachine:

    $ flexspin -2 -O1 player29.bas
    Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2022 Total Spectrum Software Inc.
    Version 5.9.12 Compiled on: Jun 16 2022
    player29.bas
    |-hg008.spin2
    |-|-psram.spin2
    |-|-|-psram16drv.spin2
    |-retrocog.spin2
    |-trackerplayer.spin2
    |-audio093b-8-sc.spin2
    |-sidcog8.spin2
    |-psram.spin2
    |-spccog.spin2
    |-a6502-1.spin2
    readdata.spin
    _mount.c
    fmt.c
    strings.bas
    dir.bas
    errno.c
    vfs.c
    posixio.c
    fatfs_vfs.c
    |-fatfs.cc
    bufio.c
    stat.c
    strncpy.c
    strncat.c
    strncmp.c
    basic_dir.c
    memcmp.c
    strchr.c
    sdmm.cc
    time.c
    localtim.c
    stat.c
    malloc.c
    opendir.c
    ioctl.c
    opendir.c
    posixio.c
    ioctl.c
    getenv.c
    gettimeofday.c
    remove.c
    rename.c
    ctype.c
    malloc.c
    strncmp.c
    bufio.c
    player29.p2asm
    Done.
    Program size is 252756 bytes
    

    Do you have local changes that you haven't pushed to the repo yet? If so, could you send those to me?

  • pik33pik33 Posts: 1,844
    edited 2022-06-16 16:33

    It seems I have no local changes, the repo is up to date. However, I use -DFF_USE_LFN. If I switched it off, the flexprop didn't crash with -O2, but instead it gave me this:

    "/home/pik33/Programy/flexprop/bin/flexspin" -2 -l --tabs=8 -D_BAUD=230400 -O2    --charset=utf8 -I "/home/pik33/Programy/flexprop/include"  "/home/pik33/Programowanie/P2-retromachine/Propeller/P2P16/player29.bas"
    Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2022 Total Spectrum Software Inc.
    Version 5.9.12-HEAD-v5.9.11-29-gbe0da837 Compiled on: Jun 16 2022
    error: Internal error exceeded local register limit, possibly due to -O2 optimization needing additional registers or code being too complicated
    (.... 164 lines of this which I deleted to fit the post in the forum limit) 
    error: Internal error exceeded local register limit, possibly due to -O2 optimization needing additional registers or code being too complicated
    player29.bas
    |-hg008.spin2
    |-|-psram.spin2
    |-|-|-psram16drv.spin2
    |-retrocog.spin2
    |-trackerplayer.spin2
    |-audio093b-8-sc.spin2
    |-sidcog8.spin2
    |-psram.spin2
    |-spccog.spin2
    |-a6502-1.spin2
    readdata.spin
    _mount.c
    fmt.c
    strings.bas
    dir.bas
    errno.c
    vfs.c
    posixio.c
    fatfs_vfs.c
    |-fatfs.cc
    bufio.c
    stat.c
    strncpy.c
    strncat.c
    strncmp.c
    basic_dir.c
    memcmp.c
    strchr.c
    sdmm.cc
    time.c
    localtim.c
    stat.c
    malloc.c
    opendir.c
    ioctl.c
    opendir.c
    posixio.c
    ioctl.c
    getenv.c
    gettimeofday.c
    remove.c
    rename.c
    ctype.c
    malloc.c
    strncmp.c
    bufio.c
    child process exited abnormally
    Finished at Thu Jun 16 18:24:37 2022
    
  • pik33pik33 Posts: 1,844
    edited 2022-06-16 16:36

    .. and yes, it is DFF_USE_LFN that causes pc is 608 error with standard optimization. Without LFN, it compiles

  • I've fixed a few optimizer problems that were causing issues with -DFF_USE_LFN. It still doesn't work with -O2, but the error messages do indicate that -O2 is the issue.

  • RaymanRayman Posts: 12,967

    FlexProp gui just started acting up on me... Won't let me quit... Have to go into Windows Task Manager to kill it...

    589 x 365 - 19K
  • @Rayman : It looks like you're using an old version of FlexProp. I think if you upgrade you won't get stuck like this any more, although you will probably have some other troubles (because for some reason the directory you're using isn't writable).

  • RaymanRayman Posts: 12,967
    edited 2022-06-26 21:26

    I have the latest version but must be that Windows decided to run an old version from start menu…

    Thanks.

  • pik33pik33 Posts: 1,844
    edited 2022-07-09 20:37

    There is something wrong with floats and size optimization

    Version 5.9.12-HEAD-v5.9.11-29-gbe0da837 Compiled on: Jun 16 2022

    I encountered wrong working of something which will be a FM synth in the future :) I managed to isolate a simple code to catch the problem:

    let slider1=0
    let slider2=0
    let slider3=0
    let slider4=0
    
    let  r1=round(61*exp(slider1/10.0)) 
    let  r2=round(61*exp(slider2/10.0))
    let  r3=round(61*exp(slider3/10.0))
    let  r4=round(61*exp(slider4/10.0)) 
    
    print slider1,hex$(r1,8),slider4,hex$(r4,8)  
    

    Now, when standard O1, the result is

    0       0000003D        0       0000003D      
    

    as expected. But with size optimization the result is simply wrong:

    0       0000003D        0       00000000     
    

    Edit: Full optimization gives the good result here.

  • @pik33 : Thank you for the bug report. One -Os optimization (converting branches to conditionals) was not checking some conditions properly, causing some undefined behavior. It is fixed in github now.

  • I think you broke the actual optimization though.

  • @Wuerfel_21 said:
    I think you broke the actual optimization though.

    No, just made it apply less often. The problem is that if a flag is set conditionally we can't then use it later as a condition for an instruction, because we don't know the state. It often happens to work, but in some cases it'll fail if the flag was left in the wrong state by some previous instruction. That's what was happening in the example that @pik33 posted.

    My fix is probably sub-optimal, but I'd rather have sub-optimal code generated than incorrect code.

  • @ersmith said:

    @Wuerfel_21 said:
    I think you broke the actual optimization though.

    No, just made it apply less often. The problem is that if a flag is set conditionally we can't then use it later as a condition for an instruction, because we don't know the state. It often happens to work, but in some cases it'll fail if the flag was left in the wrong state by some previous instruction. That's what was happening in the example that @pik33 posted.

    It should work like that, as long as the condition of the instruction using the flag is a subset of the condition of the instruction that sets the flag. Or something to that extent.

    My fix is probably sub-optimal, but I'd rather have sub-optimal code generated than incorrect code.

    Will see if I can find a proper fix.

  • @ersmith your commit creates a massive diff on pik's example (basic bloat lmao), can you tell me where the issue happens?

  • Wuerfel_21Wuerfel_21 Posts: 3,400
    edited 2022-07-11 17:51

    This is the topmost one, but I'm pretty sure that one is correct. The if_nc_or_z section can only be reached with unknown Z if the condition is satisfied with NC, anyways

    EDIT: oop, forgot to enable -Os. Off to retest.

  • @Wuerfel_21 said:
    @ersmith your commit creates a massive diff on pik's example (basic bloat lmao), can you tell me where the issue happens?

    Actually I think the bug is there in Test/stest162.c. The generated sequence now is something like:

    _blah
        cmp arg01, #99 wz
     if_ne  jmp #LR__0001
        cmps    arg02, #0 wc
     if_b   jmp #LR__0002
    LR__0001
        mov arg02, #0
    LR__0002
        mov result1, arg02
    _blah_ret
        ret
    

    That was being optimized to:

    _blah
           cmp     arg01, #99 wz
     if_e  cmps    arg02, #0 wc
     if_nc_or_nz   mov     arg02, #0
    ...
    

    which is wrong because we don't know the state of wc at the "if_nc_or_nz" condition.

  • @ersmith said:

    @Wuerfel_21 said:
    @ersmith your commit creates a massive diff on pik's example (basic bloat lmao), can you tell me where the issue happens?

    Actually I think the bug is there in Test/stest162.c. The generated sequence now is something like:

    _blah
      cmp arg01, #99 wz
     if_ne    jmp #LR__0001
      cmps    arg02, #0 wc
     if_b jmp #LR__0002
    LR__0001
      mov arg02, #0
    LR__0002
      mov result1, arg02
    _blah_ret
      ret
    

    That was being optimized to:

    _blah
           cmp     arg01, #99 wz
     if_e  cmps    arg02, #0 wc
     if_nc_or_nz   mov     arg02, #0
    ...
    

    which is wrong because we don't know the state of wc at the "if_nc_or_nz" condition.

    But we do know that either Z=0 (condition satisfied regardless of C) or Z=1 and C is known. This one is correct.

  • @Wuerfel_21 said:

    That was being optimized to:

    _blah
           cmp     arg01, #99 wz
     if_e  cmps    arg02, #0 wc
     if_nc_or_nz   mov     arg02, #0
    ...
    

    which is wrong because we don't know the state of wc at the "if_nc_or_nz" condition.

    But we do know that either Z=0 (condition satisfied regardless of C) or Z=1 and C is known. This one is correct.

    Hmmm... I'll have to look at it again, but something like that was cropping up in pik33's code.

  • I think it may be easier to understand these if we switch from printing if_ae etc to if_nc, though that's a tradeoff I guess.

Sign In or Register to comment.