Shop Learn
flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler - Page 91 — Parallax Forums

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

1858687888991»

Comments

  • evanhevanh Posts: 11,685

    :) Not long ago I had an unrelated weird compile error after a git pull update. The error went after Eric suggest I try a make clean.

  • bigtreemanbigtreeman Posts: 32
    edited 2021-09-19 00:54

    I'm using flexprop v5.9.2 to compile taqoz v2.8 210401-1230.
    I have changed the clock routines to use spin2 methods described in parallax spin2 v35m doc pg 40-41

    start of code

    CON
    _xtlfreq    = 25_000_000
    _clkfreq    = 150_000_000
    

    associated taqoz-spin2 code

    '' clkset ( newclckmode newclkfreq -- )
    'clkset     clkset a,b
    '       jmp     #DROP2
    ' rdmode ( -- m )
    rdmode  rdlong  x,#@clkmode
            jmp     #pushx
    ' wrmode ( m -- )
    wrmode  wrlong  a,#@clkmode
            jmp     #drop
    ' rdfreq ( -- f )
    rdfreq  rdlong  x,#@clkfreq
            jmp     #pushx
    ' wrfreq ( f -- )
    wrfreq  wrlong  a,#@clkfreq
            jmp     #drop
    '' rderr ( -- f )
    'rderr  rdlong  x,#@errfreq
    '       jmp     #pushx
    '' wrerr ( f -- )
    'wrerr  wrlong  a,#@errfreq
    '       jmp     #drop
    

    clkset doesn't compile in flexprop,
    errfreq isn't available for read/write with running code

    first code executed in initsys

    hubset  ##clkmode_ & !%11    'start crystal/PLL, stay in RCFAST
    waitx   ##25_000_000/100   'wait 10ms
    hubset  ##clkmode_  | %11    'switch to crystal/PLL
    

    compile and run from flexprop

      *Cold start*  
    -------------------------------------------------------------------------------
      Parallax P2  *TAQOZ RELOADED SIDE*  V2.8 'CHIP' Prop_Ver G 150MHz 210401-1230
    -------------------------------------------------------------------------------
    TAQOZ# rdmode .bin --- %00000001000000000000010111111000 ok
    

    appears to be pll,150mhz,15pF,rcfast
    I can manually change to pll with

    rdmode 
    %11 or 
    dup
    wrmode 
    hubset
    

    Where am I going wrong ??

  • ersmithersmith Posts: 5,034

    @bigtreeman said:
    I'm using flexprop v5.9.2 to compile taqoz v2.8 210401-1230.
    I have changed the clock routines to use spin2 methods described in parallax spin2 v35m doc pg 40-41

    I thought taqoz is written in assembly? If so then you cannot directly use any Spin2 methods from within it. Spin2 can call assembly, the the reverse (assembly calling Spin2) is not supported.

  • @evanh said:
    :) Not long ago I had an unrelated weird compile error after a git pull update. The error went after Eric suggest I try a make clean.

    Yup. A fresh install cured everything for me too. Amazing how bit-gremlins form over time.

  • Ah, thanks,
    I'll define clkset and errfreq in assembler for use in taqoz,
    looking through the compiler code to see how it is all done,
    so far -

    '' clkset ( newclckmode newclkfreq -- )
    '' and fix baud rate
    clkset  hubset  ##clkmode_ & !%11    'RCFAST mode
            wrlong  a,#@clkfreq
            wrlong  b,#@clkmode
            waitx   ##25_000_000/100     'allow 10ms for external clock to stabilize
            hubset  ##clkmode_
            call    #SETBAUD
            jmp     #drop2
    
  • evanhevanh Posts: 11,685
    edited 2021-09-20 05:35

    Bigtree,
    That's a compile-time version. It makes the assumption of RCFAST hand-over. You'll want to do a run-time version that uses the clkmode variable instead ...

    PS: And clkfreq too I guess.

    Anyway, it would start with the critical clean switch back to RCFAST:

            rdlong  a, #@clkmode
            andn    a, #%11
            hubset  a
    
  • evanhevanh Posts: 11,685
    edited 2021-09-21 04:11

    Eric,
    Another bug. Tested in C but presumably is across the board for the optimiser. I got this:

    0099c     D1 BE 01 FB |     rdlong  local03, ptr__dat__
    009a0     68 BE 61 FD |     xoro32  local03
    009a4     D1 BE 61 FC |     wrlong  local03, ptr__dat__
    

    From this:

    static uint32_t  xoro_test( uint32_t *stateptr )
    {
        uint32_t  r, s;
    
        s = *stateptr;
    
        __asm {
            xoro32  s
            mov r, 0-0
        }
    
        *stateptr = s;
    
        return  r;
    }
    

    The XORO32 can't prefix a WRLONG like that. It'll even be corrupting hubRAM as a result.

    PS: I petitioned Chip, at a late stage, to have XORO32, and SCA and others, operate on the D operand just so this sort of combo could be done. It wasn't deemed important enough, I think revB sign-off was too close for design changes. Only bug fixes by then.

    PPS: Well, "can't" is maybe too strong a word there. If one was wanting to pepper hubRAM in a random address order then that would be ideal solution. ;)

  • ersmithersmith Posts: 5,034
    edited 2021-09-21 12:01

    Thanks @evanh, that's fixed in the latest github. I think you're building from source, but for those who aren't a work-around is to write "__asm const" to tell the optimizer not to mess with the contents of the __asm.

  • evanhevanh Posts: 11,685

    Thanks Eric. Yep, looks good now.

    I am also getting a warning for each 0-0, telling me to add a -0 funnily. This was happening before too.

  • evanhevanh Posts: 11,685
    edited 2021-09-22 04:57

    Eric,
    There's no user reservable cogRAM is there? I can't say I want to keep the state variable for XORO32 stored in cogRAM permanently can I? I'm thinking of "static" declarations, btw.

  • ersmithersmith Posts: 5,034

    @evanh said:
    Eric,
    There's no user reservable cogRAM is there? I can't say I want to keep the state variable for XORO32 stored in cogRAM permanently can I? I'm thinking of "static" declarations, btw.

    No, there is no way to force a variable to be in COG ram. The best way to "persuade" it to be there is to always pass it as a parameter and return it from a function, something like:

    #include <stdio.h>
    #include <stdint.h>
    
    typedef struct xoroState {
        uint32_t state;
        uint32_t randVal;
    } XoroState;
    
    XoroState xoro_test(XoroState xs) {
        uint32_t r, s;
        s = xs.state;
        __asm {
            xoro32 s;
            mov    r, 0-0;
        }
        xs.state = s;
        xs.randVal = r;
        return xs;
    }
    
    int main() {
        int i;
        XoroState xs;
    
        xs.state = 0xdeadbeef;
    
        for (i = 0; i < 10; i++) {
            xs = xoro_test(xs);
            printf("xoro %d = 0x%08x\n", i, xs.randVal);
        }
        return 0;
    }
    
  • evanhevanh Posts: 11,685

    Oh, is that how you've handled Spin's multiple return values?

  • ersmithersmith Posts: 5,034

    @evanh said:
    Oh, is that how you've handled Spin's multiple return values?

    Well, that's the only way to return multiple values in C. It is a bit simpler and cleaner in Spin2 (or BASIC).

  • ersmithersmith Posts: 5,034

    @Rayman said:
    I guess passing arguments by reference is another way:
    https://www.geeksforgeeks.org/how-to-return-multiple-values-from-a-function-in-c-or-cpp/

    Passing by reference passes a pointer, so while it does accomplish allowing a function to have multiple results, it doesn't compile to multiple return values like Spin2 functions do.

  • Very valuable insight on the nucode backend: Still can build Spin Hexagon, lol.

    Chokes on the unimplemented AST_POSTSET and then segfaults.

  • ersmithersmith Posts: 5,034

    @Wuerfel_21 said:
    Very valuable insight on the nucode backend: Still can build Spin Hexagon, lol.

    Chokes on the unimplemented AST_POSTSET and then segfaults.

    It's getting closer, but still not quite there yet. I've implemented the AST_POSTSET and fixed the segfault (infinite recursion blowing up the stack), but there are still a few things missing from nucode. It's definitely not ready for real use yet!

  • @ersmith said:

    @Wuerfel_21 said:
    Very valuable insight on the nucode backend: Still can build Spin Hexagon, lol.

    Chokes on the unimplemented AST_POSTSET and then segfaults.

    It's getting closer, but still not quite there yet. I've implemented the AST_POSTSET and fixed the segfault (infinite recursion blowing up the stack), but there are still a few things missing from nucode. It's definitely not ready for real use yet!

    Well this turned interesting:

    It now builds, but for some reason only if I run it in GDB, crashes otherwise (that seems like a great issue to debug).
    If load that build, it does infact boot up and you can get to the stage select screen just fine, working audio and all. But when you actually start a game it hangs on the white screen. Odd.

  • Actually, it seems that crashing is just a thing that happens now even when compiling something less complex to PASM (read: the QuadView test program I just posted in another thread)

    This one I've been able to catch in GDB

    Reading symbols from C:\zeug\fastspin\flexspin.exe...done.
    (gdb) run -2 quadview_test.spin2
    Starting program: C:\zeug\fastspin/flexspin.exe -2 quadview_test.spin2
    [New Thread 30328.0xb1a0]
    Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc.
    Version 5.9.3-beta-v5.9.2-33-g35412c83 Compiled on: Sep 25 2021
    quadview_test.spin2
    |-QuadView.spin2
    quadview_test.p2asm
    
    Program received signal SIGSEGV, Segmentation fault.
    0x0040b6e7 in MarkStaticFunctionPointers (list=0x53001e0) at spinc.c:852
    852             MarkStaticFunctionPointers(list->left);
    (gdb)
    

    Very funny recursion bug, it seems (bt makes the terminal explode).

  • ersmithersmith Posts: 5,034

    @Wuerfel_21 : For some reason gcc isn't doing tail call optimization on MarkStaticFunctionPointers. Actually I guess that's not so mysterious after all, there are no optimizations enabled in the default makefile. Anyway, the stack size on Windows is relatively small, and hence the overflow.

    I've modified MarkStaticFunctionPointers to loop instead of recurse at the top level, and also added -Og to the make flags, so that particular problem should be fixed now.

Sign In or Register to comment.