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

pik33

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.

ersmith

@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.

pik33

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.

evanh

Defaults change, and copy-catting occurs:

ersmith

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!)

Greg LaPolla

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...

ersmith

@"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

Greg LaPolla

@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.

ersmith

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

Greg LaPolla

@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!

ersmith

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).

pik33

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)

ersmith

@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?

pik33

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

pik33

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

ersmith

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.

Rayman

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

ersmith

@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).

Rayman

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

Thanks.

pik33

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.

ersmith

@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.

Wuerfel_21

I think you broke the actual optimization though.

ersmith

@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.

Wuerfel_21

@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.

Wuerfel_21

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

Wuerfel_21

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.

ersmith

@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.

Wuerfel_21

@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.

ersmith

@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.

Wuerfel_21

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.