Shop OBEX P1 Docs P2 Docs Learn Events
flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler - Page 81 — Parallax Forums

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

17879818384116

Comments

  • @evanh said:

    @TonyB_ said:
    I've searched this thread and FlexProp v5.0.2 should support the rev.A. I have no idea what last version of PNut works. Did Spin2 ever work with rev.A?

    Pnut never mixed them. Pre-v33 was revA. v33 onwards is revB/C. Needless to say Chip's Spin2 interpreter never supported revA.

    I've attached a repackaged zip of the final v32j files. The original download contained a lot of FPGA bin files that made it 21 MB. I've stripped all those out.

    EDIT: Corrected from v31 to v32j

    Thanks a lot, Evan. The .spin2 files seem to assume an FPGA.

  • evanhevanh Posts: 15,126

    Yes, they would, revA hadn't shipped. The only silicon that anyone had seen at that stage was a few parts of just the pad-ring and dummy synthesis that Chip used for testing the custom circuits.

  • Cluso99Cluso99 Posts: 18,066

    Only pasm was supported on the FPGA. Spin2 (HLL) was only developed on RevB AFAIK.

  • evanhevanh Posts: 15,126

    I think it came into existence at v34.

  • evanhevanh Posts: 15,126
    edited 2021-02-27 19:40

    Eric,
    I've just had an attempt at using flexspin to build Wuerfel's VJET demo. Using Git master branch (Version 5.2.0 Compiled on: Feb 28 2021), my first bump was I had to move OBJ section ahead of VAR section in top program "p2test.spin2". This eliminated a compile error, eg: "p2test.spin2:34: error: request for member REGION_SIZE in something not an object". It compiled after that.

    Runtime behaviour certainly wasn't right though. It behaved like a bunch of parameters were winding to limits. I'll hassle Wuerfel about that so we can be more specific for you ...

  • @evanh

    Uhh, that should be working, but I admit I never tested the VJET demo in flexspin. The order of the sections should not matter, that seems like a bug. If you have a picture or video of what weirdness is going on, that'd help, too.

  • @Cluso99 said:
    Only pasm was supported on the FPGA. Spin2 (HLL) was only developed on RevB AFAIK.

    Since this is the flexspin thread, I should point out that flexspin (then called fastspin) supported Spin on the FPGA :).

  • @evanh said:
    I've just had an attempt at using flexspin to build Wuerfel's VJET demo. Using Git master branch (Version 5.2.0 Compiled on: Feb 28 2021), my first bump was I had to move OBJ section ahead of VAR section in top program "p2test.spin2". This eliminated a compile error, eg: "p2test.spin2:34: error: request for member REGION_SIZE in something not an object". It compiled after that.

    I think that's a consequence of the change I made in 5.2.0 to create variable declarations in the order they were made, rather than re-arranging them as Spin1 did. Flexspin treats OBJ like any other variable (from the compiler's point of view they are like C structs) and so the ones declared after the VAR section hadn't been created yet. I'll have to add another special pass for OBJs, ugh. For now moving them before the VAR is the correct work-around.

    Runtime behaviour certainly wasn't right though. It behaved like a bunch of parameters were winding to limits. I'll hassle Wuerfel about that so we can be more specific for you ...

    That must be another issue, if you could provide some more details I'll look into it.

  • Hmm, maybe SCAS is not correctly implemented? Both the 3D viewer demo and Spin Hexagon use the Spin1** operator. The latter I just compile through flexspin as-is, but the former has been converted to Spin2 for its P2 version, where SCAS has to be used. It behaves differently, maybe flexspin didn't get the memo.

  • RaymanRayman Posts: 13,797
    edited 2021-04-03 18:40

    Got a question about the use of "const" with FlexSpin C (and C in general I guess...).

    Was just trying to compile this artificial neural network code: https://github.com/codeplea/genann

    FlexSpin C seems to have issue with the use of "const" in lines like this:

    double const *genann_run(genann const *ann, double const *inputs) {
        double const *w = ann->weight;
        double *o = ann->output + ann->inputs;
        double const *i = ann->output;
    

    If the "const" is deleted in the above, FlexSpin seems OK with it.
    Is this the solution, or a mistake?

    Also, a minor question... Thinking about real "doubles" in FlexSpin C?
    I'm hoping this code will work even though Fastspin's doubles are 32 bit. But, it might not...

  • evanhevanh Posts: 15,126

    I'd guess the problem is a warning message. What is the warning message?

  • RaymanRayman Posts: 13,797

    Sorry, should have mentioned.. The errors are like this:

    1>genann.c:180: error: Expecting object for dereference of total_weights
    1>genann.c:180: error: Expecting object for dereference of total_neurons
    1>genann.c:180: error: Expecting object for dereference of total_neurons
    1>genann.c:180: error: Expecting object for dereference of inputs
    1>genann.c:180: error: Method reference on non-class expression
    1>genann.c:180: error: Method reference on non-class expression
    
  • ersmithersmith Posts: 5,900
    edited 2021-04-05 18:45

    @Rayman : It seems like there's a bug in flexspin's handling of const parameters -- specifically it's not parsing "struct foo const" correctly, although it does understand "const struct foo" (which should be the same thing). For now just removing the const is fine. "const" in C just a hint to the compiler that you don't intend to modify the variable.

  • RaymanRayman Posts: 13,797

    Ok, thanks. I'll just do a global delete then, for now...

    Are 64-bit doubles on the horizon, or does that just not make any sense on 32-bit MCU?

  • @Rayman said:
    Ok, thanks. I'll just do a global delete then, for now...

    Are 64-bit doubles on the horizon, or does that just not make any sense on 32-bit MCU?

    64 bit doubles will be a lot of work. Perhaps someday flexspin may have them, but not soon.

  • RaymanRayman Posts: 13,797
    edited 2021-04-05 20:48

    What about 64-bit fixed point? That seems like it should be a lot easier, right?

    I'm not asking for this, btw... Just curious what is possible...

  • Hi @ersmith
    I know FlexSpin can read inline comments on method definition lines to effect some compiler switches, but would it be an easy enough change to ignore empty curly-braces {} in those cases or consider them plain comments? I ask because it seems to have an issue when I use them in conjunction with any preprocessor directives.
    I use empty braces in spin1 method definition code as an easy/quick way to use automated tools to convert to spin2 (e.g., PUB MyMethod{} in spin1 is easy to convert with a simple s/{}/()/g to PUB MyMethod() for the equivalent spin2), but the compiler bombs when it also encounters preprocessor directives in the child:

    ' Parent object
    #include "braces_child.spin"
    
    PUB Main
    
    ' Child object
    PUB Null{}
    ' This is not a top-level object
    #define I_WILL_FAIL_HERE
    
    Press ENTER or type command to continue
    Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc.
    Version 5.3.2 Compiled on: Apr  4 2021
    braces_preproc_test.spin
    braces_child.spin:4: error: syntax error, unexpected '#'
    

    No biggie, if not.

    Cheers

  • @Rayman said:
    What about 64-bit fixed point? That seems like it should be a lot easier, right?

    I'm not asking for this, btw... Just curious what is possible...

    Not much easier, alas. The problem is that internally everything is represented in 32 bits, so 64 bit support needs some re-working of the compiler internals. There are some hacks to partially get things working, but I don't know when actual support will be there.

  • @avsa242 : It seems there's some kind of bug in the parsing of comments so that "{}" causes issues. it's not specifically a problem with method definition lines, I think it could happen anywhere. For now a work-around is to put a space inside the comment "{ }".

  • evanhevanh Posts: 15,126
    edited 2021-04-05 23:50

    Eric,
    Regression with incorrect line numbers of errors/warnings. Latest Flexspin master: 5.3.3-beta-v5.3.2-5-g4a3144d7

    EDIT: Oh, it's reporting the .p2asm file!
    EDIT2: Umm, when it's a pure pasm2 assemble it reports as the .pasm2 filename but the line number is wrong then too.

  • @evanh said:
    Eric,
    Regression with incorrect line numbers of errors/warnings. Latest master: 5.3.3-beta-v5.3.2-5-g4a3144d7

    EDIT: Oh, it's reporting the .p2asm file!

    It would be helpful if you could provide an example...

  • evanhevanh Posts: 15,126
    edited 2021-04-05 23:52

    Typo is on line 36.

    Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc.
    Version 5.3.3-beta-v5.3.2-5-g4a3144d7 Compiled on: Apr  6 2021
    steve_hatch.spin2
    steve_hatch.spin2
    steve_hatch.spin2:39: warning: First operand to dirh is a constant used without #; is this correct? If so, you may suppress this warning by putting -0 after the operand
    steve_hatch.spin2:39: warning: First operand to dirh is a constant used without #; is this correct? If so, you may suppress this warning by putting -0 after the operand
    Done.
    Program size is 140 bytes
    
  • evanhevanh Posts: 15,126
    edited 2021-04-06 00:04

    Typo on line 25 of .spin2. Line 183 of .p2asm is the correct line number. Maybe this is normal, I've not been writing any mixed code myself.

    streamer-basic.spin2
    streamer-basic.p2asm
    streamer-basic.p2asm:183: warning: First operand to dirh is a constant used without #; is this correct? If so, you may suppress this warning by putting -0 after the operand
    streamer-basic.p2asm:183: warning: First operand to dirh is a constant used without #; is this correct? If so, you may suppress this warning by putting -0 after the operand
    Done.
    Program size is 1724 bytes
    
  • Thanks Evan, I'll look into it.

  • JRoarkJRoark Posts: 1,214
    edited 2021-04-06 02:15

    @ersmith I have a really odd one. In FlexBASIC (current version) any strings derived from a cast(string, ubyte array) are correct within the function... but if you try to pass them back they contain garbage or are empty. The code below demonstrates this:

        dim tmp$ as string
        tmp$ = Test$()
        print "Outside TEST$() = ["; tmp$; "]"
        print "Done"
    ' ======================================================================================
    FUNCTION Test$() as string
        dim buff as ubyte(64)   'SEE EDIT NOTE 
        dim p as ulong
        dim t$ as string
    
        for p = 0 to 62
            buff(p) = 88                    'fill BUFF() with 63 "X"s
        next p
        buff(63) = 0                        'append end-of-string char @ last byte position
        t$ = cast(string, buff)     'cast BUFF() to T$
    
        print "Inside TEST$() = ["; t$; "]" 'print T$. THIS WORKS FINE
        return t$                           'return T$  THIS DOESNT RETURN T$. Odd...
    END FUNCTION
    
    

    Edit Note: The workaround is to replace this

        dim buff as ubyte(64)   
    

    with

        dim buff = new ubyte(64)
    
  • @JRoark : any memory declared locally (like the buff array in your test$ function) will stop being valid when the function returns. That means that returning buff or any pointer to buff from the function will not work properly. A string is just a pointer to some memory.

    Probably it would be useful for a warning or error to be printed on the cast to string (since it's a local variable being cast). On the other hand this won't be easy, since actually the cast is perfectly OK as long as the variable isn't returned.

  • JRoarkJRoark Posts: 1,214
    edited 2021-04-06 12:20

    @ersmith At the risk of being obtuse, I’m still confused.

    What is being returned by the TEST$() function in both cases is T$. The source of T$ contents shouldnt matter because after the cast, T$ now holds a copy of whatever came out of that cast. Or is my fundamental error thinking that T$ is a copy when in fact it is just a pointer to whatever was fed to CAST? If that is true, then it would appear the NEW syntax is allocating persistant memory that doesnt get reclaimed when the function ends?

    I’ll re-caffinate and re-read what you wrote more carefully, but its clear I am making some assumptions about strings and memory management that FlexBASIC disagrees with. (I hate it when reality doesnt conform to my entitled expectations! Hehehe.)

    EDIT: The lightbulb in my head just went on. “...OR ANY POINTER TO BUFF...“ T$ isnt a copy. Duh. Now I get it. And you even put it in italics for me...

  • Variables declared in a function are allocated on the stack. Once the function ends that stack space is still valid but other functions down the road will use this same space. Only memory allocate will create space in memory that is not on the stack.

    Mike

  • @iseries said:
    Variables declared in a function are allocated on the stack. Once the function ends that stack space is still valid but other functions down the road will use this same space. Only memory allocate will create space in memory that is not on the stack.

    And that non-stack allocation is what NEW does, correct?

  • @JRoark : Looks like you've figured this out, but yes, non-stack allocation is what NEW does. CASTing from an array to a pointer type (like a string) doesn't do a copy, it just finds the address of the array and puts it into the pointer.

Sign In or Register to comment.