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

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

1353638404154

Comments

  • I've released 5.9.18 beta on Patreon. I think this is pretty close to the final release. There are a few bug fixes, and many improvements to the P2 bytecode ("nucode") generator. The generated code is now pretty small (often smaller than PNut's) and performance is improving, although still not quite up to PNut's yet. I plan eventually to add a JIT compilation module for inner loops that should dramatically improve that, but that will take a while.

  • @ersmith said:
    performance is improving, although still not quite up to PNut's yet.

    What benchmark are you using for that?

  • @Wuerfel_21 said:

    @ersmith said:
    performance is improving, although still not quite up to PNut's yet.

    What benchmark are you using for that?

    A few; fibo, toggle, and xxtea. For example, for the xxtea decompressor PNut gives a 6784 byte binary that runs in 155816 cycles, whereas flexspin -2nu -O2 gives a 3296 byte binary that runs in 200672 cycles. For recursive fibo(12) PNut is 6388 bytes / 237400 cycles and flexspin is 4348 bytes / 283528 cycles.

  • Cool.

    Tried how the density scales on bigger programs? With programs this small PNut obviously looses to interpreter bloat.

  • ersmithersmith Posts: 5,900
    edited 2022-10-05 19:21

    I don't have a lot of big Spin2 programs, but my VGA demo is 16348 bytes for PNut and 13436 bytes for flexspin -2nu, so flexspin is still competitive at that size of program. I'm not sure how much of the difference is due to unused method removal, though.

  • Yea, I don't have any Spin-heavy program that actually works on PropTool/PNut, either. Flexspin filesystem/sprintf/whatever is too good (though bloat from these two in particular is mildly painful)

  • JRoarkJRoark Posts: 1,214
    edited 2022-10-09 15:57

    @ersmith I have another oddity. (It takes one to know one, amiright?).

    Something seems to have changed with the way string handling/garbage collection is done. What I am seeing is that GC works fine until you start passing strings to a device driver via its handle, at which time the passed string never seems to be GC'd. This code using your VGA driver will show it nicely:

    #define VGA_BASE_PIN 48
    CONST _CLOCKFREQ = 160_000_000
    CONST HEAPSIZE = 8000
    
        dim vga as class using "ansi.spin2"
        dim n as uinteger
        dim a$ as string
    
        vga.start(VGA_BASE_PIN)
        open SendRecvDevice(@vga.tx, nil, @vga.stop) as #2
    
        for n = 1 to 125
            a$ = "01234567889 abcdefghijklmnopqrstuvwxyz 01234567889 ABCDEFGHIJKLMNOPQRSTUVWXYZ " + chr$(13)
            'print #2, n; "-"; a$
            print n; "-"; a$
            'delete a$
        next n
    

    As shown, the code works fine. But change that loop to print to the handle (#2) returned by SendRecvDevice() and it blows-up about halfway through the 125 iterations. If you uncomment the DELETE A$, that gets you back to working... for a while... but if you increase the loop iterations to 1000 or so it blows it up again.

    So I'm thinking either GC as it relates to strings passed to a device driver are not being GC'd at all, and/or the GC that is happening isn't cleaning up completely.

    FWIW, changing the HEAPSIZE (even to very large numbers, 32k, 64k) just kicks the can down the road until it eventually fails again. So to my mind there is definitely something odd about how GC and device drivers interact. Over to you... :)

    ADDIT: On a separate issue #DEFINE must not have a tab char in front of it or it causes an error. A quick note to that effect in the docs might be in order.

  • evanhevanh Posts: 15,126

    @JRoark said:
    ... (It takes one to know one, amiright?).

    What? You're a compiler?

  • @evanh said:
    What? You're a compiler?

    Of bad Dad-jokes, YES!

  • @JRoark said:
    @ersmith I have another oddity. (It takes one to know one, amiright?).

    Something seems to have changed with the way string handling/garbage collection is done. What I am seeing is that GC works fine until you start passing strings to a device driver via its handle, at which time the passed string never seems to be GC'd. This code using your VGA driver will show it nicely:

    No, alas, it does not show it -- that code works fine for me when I uncomment the print #2 and even when I increased the loop count to 999 :(. I'm using FlexProp 5.9.18-beta.

    My guess is that there may be a bug in the VGA code you're using? I'm not sure which copy of ansi.spin2 / vga_tile_driver / etc. you're using. I used the one that is packaged in samples/vga in the flexprop 5.9.18 beta. Note that this has changed "recently", so it may not match yours. Also not sure what resolution you're using; I've tried the default 800x600 with full color (CELL_SIZE=8) and also 1024x768 with monochrome (CELL_SIZE=1), both of which worked at the default clock frequency. 1024x768 worked with CELL_SIZE=8, but I had to increase the clock frequency to 200_000_000 by adding

    const _CLKFREQ = 200_000_000
    

    to the program. I notice you have a _CLOCKFREQ constant defined; that doesn't have any default meaning, did you misspell _CLKFREQ?

    Anyway, if none of this helps you, could you zip up a complete project (including your VGA driver) and also give me the command line you're using (or that FlexProp displays during compilation). I've tried various combinations of optimizations but they all seem to work for me.

  • I've released FlexProp 5.9.19 on both Patreon and github. There are a lot of bug fixes in this version, including:

    • Added a warning for mixing tabs and spaces in Spin code
    • Added strtok() function to C library
    • Fixed some incorrect C array declarations
    • Fixed precision not being reset in printf
    • Fixed incorrect leaf function analysis in Spin functions using floats
    • Fixed lut function bug that crept in when memory was reserved at start of LUT
    • Fixed padding while initializing structures
    • Implemented -E and -H flags for nu bytecode
    • Implemented SPR[] in bytecode (thanks to Ada Gottensträter)
    • Improved register allocation in leaf functions (thanks Ada)
    • Improved optimization for small wait loops (also thanks to Ada)
    • Made SPR[] work more like Spin1 (thanks Ada)
    • Reduced register usage in local array initialization
    • Reimplemented TYPEOF to be more useful

    Also note that I've signed up for github sponsorship, as an alternate way of supporting FlexProp financially for those who prefer not to use PayPal.

  • FlexProp version 5.9.20 is available now. It has a lot of bug fixes, so I recommend updating to it. The compiler changes include:

    - Added a new pass to re-calculate object sizes after symbol resolution (fixes some problems with memory overruns in C code used as Spin object)
    - Added STRCOPY Spin2 function
    - Fixed a crash when trivial C programs are submitted
    - Fixed swapping 64 bit variables
    - Fixed failure to change arrays to pointers in some C expressions
    - Fixed 64 bit integer preincrement
    - Fixed initializing local reference variables
    - Fixed += and similar operators when used with references
    - Implemented object constant overrides (object parameters) for Spin
    - Implemented ... line continuation for Spin
    - Inline assembly can now access multiple longs of large local variables.
    - More fixes to C struct initialization
    - Made debug output and C library output work better together
    - Made repeat loops in Spin2 finish with the same value as in PNut
    - Optimized initializers of large local variables
    - Optimized long fills on P2 with SETQ (thanks to Ada Gottensträter again!)
    - Remove unused methods even at -O0 optimization
    - Relax type checking in C for pointer/integer conversion
    

    Also, there's one small change to the GUI: the Help menu now includes a link to @Wuerfel_21 's great P2 documentation.

  • pik33pik33 Posts: 2,347

    includes a link to @Wuerfel_21 's great P2 documentation.

    It would be good if it was pinned somewhere in the forum, but having it in Flexprop is even better.

  • "HyperJump" is cool AF :+1:

  • Switching from 5.9.16 to 5.9.20 and I get the following:

    Switched back to 16 and everything is fine :/

    Craig

  • The Spin2 language has changed (again) and now FIELD is a reserved word. I'm sure @JonnyMac will have an updated version of jmfullduplexserial soon, or you can just do a search and replace and change every occurence of the variable field to something else (like fieldval).

  • @ersmith
    Many thanks Eric :+1:

    Was thinking of hacking it anyway. Awful lot of stuff I don't need. Buffering was the main reason to start using JM_FDS :smile:

  • @ersmith said:
    The Spin2 language has changed (again) and now FIELD is a reserved word. I'm sure @JonnyMac will have an updated version of jmfullduplexserial soon, or you can just do a search and replace and change every occurence of the variable field to something else (like fieldval).

    Thanks for pointing that out -- I will fix it today. These changes would be less bothersome if Chip would work on things we really need (e.g., a Spin2-compable uSD driver that works cleanly).

  • @ersmith
    in FlexBasic I am having trouble passing an array to a subroutine.

    Depending on how I declare array m() in the subroutine, I get either:

    Sub MultiplyMatrixVector3 (i As vec3d, o As vec3d, m(3,3) As Single)
    error: syntax error, unexpected integer number, expecting ')'

    or

    Sub MultiplyMatrixVector3 (i As vec3d, o As vec3d, m() As Single)
    error: Array dereferences on non-array ((float **)m)

    I've attached the code, look at about line 143

  • jrullanjrullan Posts: 159
    edited 2022-11-29 02:08

    Noobie question here... I'm totally new in FlexProp and I'm trying to migrate a project from Prop Tool. Upon trying to compile it for the first time I got a syntax error on a call to a method pointer that works in Prop Tool, see screenshot

    To troubleshoot I created this program that illustrates the problem:

    Apparently FlexSpin doesn't recognize the method pointer using the syntax methods[0](1,2). Is this expected?

  • @whicker said:
    @ersmith
    in FlexBasic I am having trouble passing an array to a subroutine.

    Multi-dimensional arrays aren't really supported very well in FlexBasic, unfortunately. I'll try to improve this in the future, but for now your best bet is to instead use structs, arrays of structs, or arrays of arrays. For example, you could declare a mat3d type similar to the vec3d. Or, you could do:

    Sub MultiplyMatrixVector3(i As vec3d, o As vec3d, m() as Single(3))
    
  • @jrullan said:
    Noobie question here... I'm totally new in FlexProp and I'm trying to migrate a project from Prop Tool. Upon trying to compile it for the first time I got a syntax error on a call to a method pointer that works in Prop Tool, see screenshot

    Apparently FlexSpin doesn't recognize the method pointer using the syntax methods[0](1,2). Is this expected?

    Not really "expected", but it is happening -- method pointers were only really tested with simple variables, not with arrays, so the array syntax isn't supported in this version. I hope that will be fixed soon. The work-around for now is to use a local variable and load the desired method pointer into that variable, and call through that. Thanks for the bug report,

  • @whicker and @jrullan : The most recent code (source in github) has fixes for the BASIC multi-dimensional array and Spin2 method pointer bugs you found. There's a binary on my Patreon page too. Thanks for your bug reports!

  • @ersmith said:
    @whicker and @jrullan : The most recent code (source in github) has fixes for the BASIC multi-dimensional array and Spin2 method pointer bugs you found. There's a binary on my Patreon page too. Thanks for your bug reports!

    Thanks! @ersmith

  • jrullanjrullan Posts: 159
    edited 2022-11-30 17:03

    @ersmith I opened another issue on Github. Do you prefer to be alerted of issues here or on the Github repo?

  • @jrullan said:
    @ersmith I opened another issue on Github. Do you prefer to be alerted of issues here or on the Github repo?

    I'll look into it, thank you. The Github repo is good because it keeps track of outstanding bugs, but feel free to report here instead or as well if that's convenient for you.

  • @ersmith
    Does anyone have a direct link to the latest flexprop. The github does not show a zip file and the patreon wants me to pay. I am confused about the patreon link. Is flexprop no longer free?
    Thank you in advance.
    Martin

  • @pilot0315 said:
    @ersmith
    Does anyone have a direct link to the latest flexprop. The github does not show a zip file and the patreon wants me to pay. I am confused about the patreon link. Is flexprop no longer free?
    Thank you in advance.
    Martin

    I believe when he initially releases an update it is only available to patron’s initially and then is available for free to everyone else a bit later. I know I get an email whenever he releases a new version. I thought the older versions stayed available for download also.

  • @DiverBob

    Thanks.
    I have been trying the github where @ersmith told me there is a drop down that says assets. Every time I click on it it just goes in circles. Hope to get it soon.
    Martin

Sign In or Register to comment.