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

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

1161719212255

Comments

  • @ersmith That makes sense. I also wasnt seeing the distinction between an “error” (handled by GETERR) and “exception” (catch/try). Words have meaning! And I see you posted some fresh code, so thank you!

  • There's a new version of FlexProp (version 5.4.3) available now, with a number of bug fixes and some minor improvements (e.g. the P2 command line shell now supports the "type" command to display files from the SD card or host).

  • @ersmith said:
    If there's no sd card then the mount would fail. I don't think there's any other reliable way, and indeed I removed sdmmc_is_present() from the file system code a while back because it didn't always work (there may still be a copy in loadp2, but if so you could probably ignore it).

    @ersmith Re: Flex 5.4.3
    I can confirm that the "bugginess" with a successful OPEN returning an error is cured in 5.4.3.
    Interestingly, if no SD card is installed, MOUNT doesn't throw an error or an exception. It simply chugs along and reports back as "OK". The exception (error 12, "I/O Error") only gets thrown when you try to do an OPEN after the MOUNT. This code shows it:

        dim myerr as long
        try
            print "Attempting MOUNT"
            mount "/sd", _vfs_open_sdcard()
            print "MOUNT returned: ";strerror$(geterr())
            print "Attempting OPEN"
            open "/sd/testfile.log" for append as #3
            print "OPEN returned: "; strerror$(geterr())
        catch myerr
            print "Whoops: ";myerr; " aka: "; strerror$(myerr)
        end try
    

    I report this only because the MOUNT behavior is different than what you expressed above as the expected behavior. From where I'm sitting, this isn't a bug since it is just as easy to trap the error at the OPEN phase.

  • @ersmith said:
    There's a new version of FlexProp (version 5.4.3) available now, with a number of bug fixes and some minor improvements (e.g. the P2 command line shell now supports the "type" command to display files from the SD card or host).

    Oh, there is indeed. I think you may have forgotten to put it on the spin2cpp releases page.

  • JRoarkJRoark Posts: 1,215
    edited 2021-05-09 15:18

    @Wuerfel_21 I note (goodnaturedly, and with tongue planted firmly in cheek) that it's on his Patreon page.
    Nudge-nudge. Wink-wink.
    Support your local genius. (You need a Patreon page, btw!)

  • I know that it's there early, but it is on the FlexProp github already, but not on the spin2cpp one.

    I don't really care for myself, anyways (I only need the CLI tools, which I could compile myself (but in practice I just pull the CI artifacts)), but I hate releasing code that requires a compiler version that doesn't quite exist yet. (Because as I like to jokingly say, I usually find 1 flexspin bug each day I use it...)

  • @Wuerfel_21 said:

    @ersmith said:
    There's a new version of FlexProp (version 5.4.3) available now, with a number of bug fixes and some minor improvements (e.g. the P2 command line shell now supports the "type" command to display files from the SD card or host).

    Oh, there is indeed. I think you may have forgotten to put it on the spin2cpp releases page.

    The last spin2cpp release was downloaded by a grand total of two (2) people. The one before that got 3 downloads. I don't think it's worth providing binary releases any more.

  • Wuerfel_21Wuerfel_21 Posts: 5,091
    edited 2021-05-09 19:17

    Well, I guess most people that use the command line tools alone compile them from source...

    I myself generally only update to whatever git revision that fixes the showstopping bug of the day, so I myself rarely use the proper releases.

    I guess there's still the ability to download CI artifacts or rip the binaries out of a FlexProp release.

  • JRoarkJRoark Posts: 1,215
    edited 2021-05-16 21:54

    @ersmith I seem to have found an error in multi-value returns from functions in FlexBASIC V5.4.3. This code throws "error: Not enough elements on right hand side of assignment"

    dim A,B as ubyte
    A,B = SomeFunc()
    print A,B
    
    FUNCTION SomeFunc() as ubyte, ubyte
        dim Y as ubyte
        dim Z as ubyte
        Y = &hFF 
        Z = &h00 
        return Y, Z
    END FUNCTION
    

    But if we change all the UBYTEs to ULONGs, it works fine:

    dim A,B as ulong
    A,B = SomeFunc()
    print A,B
    
    FUNCTION SomeFunc() as ulong, ulong
        dim Y as ulong
        dim Z as ulong
        Y = &hFF 
        Z = &h00 
        return Y, Z
    END FUNCTION
    

    So the short story seems to be that returning multiple UBYTE values from a function is broken. Any thoughts?

    EDITED TO ADD: I posted that right as you released 5.5.0-Beta. Running the same code under 5.5.0-Beta gives the same error as above but also adds: "warning: Internal assert failure: func numresults inconsistent for function SomeFunc"

  • Thanks for the bug report @JRoark . Yes, BASIC isn't handling multiple return values that are smaller than 4 bytes correctly. It should be fixed in the next release.

  • Cluso99Cluso99 Posts: 18,069
    edited 2021-05-18 04:18

    Eric,
    I cannot see the fit command in the listing. Is it supposed to be there?
    The program is OS243.spin2 and the fit command is in SD_DRIV.spin2 line 1762.
    flexprop v5.4.3

    Thanks for a great compiler :smiley:

  • Ray: Listing files are based on the generated code, so things like FIT and RES that don't generate any code don't always show up, particularly in sub-objects (the top level object is handled a bit differently). I will try to add some special cases for FIT and RES so that they will show in the next version.

    Thanks,
    Eric

  • Cluso99Cluso99 Posts: 18,069

    Thanks Eric. I looked to see how close to the limit I was in an object so I searched for the fit line. I found others (I think they may have been internallly generated) but not the one I wanted.
    So thought I would report it but it's certainly not a requirement.

    I don't use the listing often, but when you need it - it's brilliant :smiley:

  • There's a new version of FlexProp, 5.5.0, available at the usual places (see the first post or my signature for links). Changes to the compiler in this version include:

    - Added warning for modifying ptra in inline assembly
    - Added throwifcaught command for BASIC
    - Allowed '$' in inline assembly in C
    - Fixed a problem with large ranges in lookup/lookdown
    - Fixed a preprocessor bug which sometimes caused failure to recognize comments
    - Fixed a bug in handling multiple return values that are less than long sized
    - If -Wall is given, warn about uninitialized local variables
    - Implemented "public" and "private" in C++ classes
    - Improved listing file output by adding RES and FIT entries
    
  • @ersmith said:

    • Improved listing file output by adding RES and FIT entries

    Speaking of fit, seems that it doesn't support the limit value specified on the org line, like this:

    DAT             org     $000, $1F0
    

    Would be possible to add ?

    Another question: it is possible to generate spin bytecode like Propeller Tool instead of the 'fast' code ? I'm looking at a Linux alternative to Propeller Tool but would like to generate the same binaries.

  • ersmithersmith Posts: 6,064
    edited 2021-05-23 19:23

    @macca said:
    Speaking of fit, seems that it doesn't support the limit value specified on the org line, like this:

    DAT             org     $000, $1F0
    

    Would be possible to add ?

    I'll look into this.

    Another question: it is possible to generate spin bytecode like Propeller Tool instead of the 'fast' code ? I'm looking at a Linux alternative to Propeller Tool but would like to generate the same binaries.

    This would be a lot of work, requiring:

    • Reverse engineering of the meaning of all the spin bytecodes from the interpreter
    • Implementation of a compiler backend to emit these spin bytecodes
    • Integration of inline assembly
    • All of the above done twice, once for P2 and once for P1, since the byte code is different between them

    Unless some benefactor decides to hire me to do that work (or a whole lot more people decide to sign up for my Patreon) I doubt I will be able to find the time for this :(.

  • @ersmith said:

    • Reverse engineering of the meaning of all the spin bytecodes from the interpreter

    Parts of this already exists as code in Spinix's Spin compiler, Sphinxcompiler, Homespun and OpenSpin. Spinix has a Spin bytecode assembler, that may be a start. Or had? In some versions only?

    But sure documenting the bytecode should have been done at it's original source. Maybe there even exists some forgotten documentation?

  • @ersmith said:

    @macca said:
    Speaking of fit, seems that it doesn't support the limit value specified on the org line, like this:

    DAT             org     $000, $1F0
    

    Would be possible to add ?

    I'll look into this.

    Another question: it is possible to generate spin bytecode like Propeller Tool instead of the 'fast' code ? I'm looking at a Linux alternative to Propeller Tool but would like to generate the same binaries.

    This would be a lot of work, requiring:

    • Reverse engineering of the meaning of all the spin bytecodes from the interpreter
    • Implementation of a compiler backend to emit these spin bytecodes
    • Integration of inline assembly
    • All of the above done twice, once for P2 and once for P1, since the byte code is different between them

    Unless some benefactor decides to hire me to do that work (or a whole lot more people decide to sign up for my Patreon) I doubt I will be able to find the time for this :(.

    Not sure about Spin2, but compiling Spin1 from an AST is not very difficult. I've read a good bit of the homespun source and it really just walks down the AST, emitting corrosponding bytecode along the way (though there is a bit context to it, such as QUIT mapping to a different opcode in a REPEAT N type loop (this was the source of one of the bugs I fixed in homespun, that bit of context didn't get restored after leaving a loop)). From a casual look, it would though seem to be difficult to hook it all up to the existing framework.

  • @yeti said:

    @ersmith said:

    • Reverse engineering of the meaning of all the spin bytecodes from the interpreter

    Parts of this already exists as code in Spinix's Spin compiler, Sphinxcompiler, Homespun and OpenSpin. Spinix has a Spin bytecode assembler, that may be a start. Or had? In some versions only?

    But sure documenting the bytecode should have been done at it's original source. Maybe there even exists some forgotten documentation?

    Uhh, the Spin1 bytecodes are documented right in the interpreter source

  • The interpreter source does document the bytecodes, but you have to search around to locate specific bytecodes. It takes a bit of reverse engineering to figure it out, but it is doable from the source code. I wrote a bytecode assembler call spasm that runs under spinix. There were never any official names assigned to the bytecodes, so I created some names to use with spasm. The documentation for the spasm assembler is in the attached text file.

  • RaymanRayman Posts: 14,709

    @ersmith Would it be difficult to build flexspin.exe as a 64-bit app?

  • ersmithersmith Posts: 6,064
    edited 2021-05-23 23:55

    I was really thinking more of Spin2 as the difficult bytecode set to reverse engineer. I'm aware that there has been previous work to document the Spin1 bytecode set. Of course Spin1 bytecode has its own set of problems when it comes to implementing flexspin/basic/c, such as lack of support for unsigned operations and no way to escape to assembly code.

    I really don't think I will be able to implement bytecode any time soon, so this is probably moot. Although I'm always happy to receive pull requests for flexspin, should someone else want to take the task on!

  • @Rayman said:
    @ersmith Would it be difficult to build flexspin.exe as a 64-bit app?

    Probably not, but I don't see a lot of benefit to it -- as long as some people are still using 32 bit Windows it seems safer to distribute it as a 32 bit binary that works under both environments.

  • Eric, just want to say you're doing a great job. Your work needs to be celebrated for what it does. It stands on its own as the only useful cross-platform multiple programming language compiler for the Propeller 2.

    It's flexible, fast, and well documented. And for years now you've been very responsive with bug fixes and clarifications.

    I too wish more people would sign up with Patreon. Not only for the hopes of further development and features, but to pay you back for the functionality you've created here and now.

    When one does sign up for a monthly contribution, just think of Patreon acting as a kind of software delivery service where one can receive emails to go download the latest updates.

  • @ersmith said:

    @Rayman said:
    @ersmith Would it be difficult to build flexspin.exe as a 64-bit app?

    Probably not, but I don't see a lot of benefit to it -- as long as some people are still using 32 bit Windows it seems safer to distribute it as a 32 bit binary that works under both environments.

    Most applications make both 32 & 64 bit flavors available nowadays. Maybe something to consider?

  • @ersmith said:
    I really don't think I will be able to implement bytecode any time soon, so this is probably moot. Although I'm always happy to receive pull requests for flexspin, should someone else want to take the task on!

    I think I'll give it a shot. First goal would be to produce unoptimized Spin1 binaries identical to other Spin compilers and then go from there. Implementation will probably suck, lol.

  • @Wuerfel_21 said:

    @ersmith said:
    I really don't think I will be able to implement bytecode any time soon, so this is probably moot. Although I'm always happy to receive pull requests for flexspin, should someone else want to take the task on!

    I think I'll give it a shot. First goal would be to produce unoptimized Spin1 binaries identical to other Spin compilers and then go from there. Implementation will probably suck, lol.

    Just committed some initial bytecode work. Is mostly going as easy as I thought it'd be, though I did overengineer some system to figure out ideal jump sizes. Probably was not necessary. Shouldn't bee too difficult to get it to something useable.

  • \o/   What a towelday!   \o/

    ;-D

  • Wuerfel_21Wuerfel_21 Posts: 5,091
    edited 2021-05-28 16:32

    Something neat I implemented while working on the bytecode stuff: Colored error messages.

    https://github.com/totalspectrum/spin2cpp/pull/135

  • nice

Sign In or Register to comment.