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

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

1939495969799»

Comments

  • ersmithersmith Posts: 5,404

    @pik33 said:
    This line: (1635)

    buf[ + j] = MULH(t0, win[18 + j]);

    caused a segfault.

    Correcting this to

    buf[ 0 + j] = MULH(t0, win[18 + j]);

    makes segfault disappear

    What is left, the compiler doesn't like these constants at 802-809, but at least it doesn't crash.

    Ah, thanks. I've fixed the segfault in github now. The constants are still a problem, because they're relatively complicated and getting turned into function calls, but I'll work on it.

  • evanhevanh Posts: 13,424
    edited 2022-08-03 00:51

    Apologies Eric,
    I intended to perform much more testing yesterday but got some Smile in me eye that has been a real pain to resolve.

    @ersmith said:

    It heavily relies on Fcache to place the inline Pasm in cogRAM, so I kind of need the optimiser. Or is there a way to specify where the Pasm is placed irrespective of optimiser setting?

    You can turn off the optimizer and turn on just fcache with a command line option of something like -O0 --fcache=128.

    Thanks... okay, yay, that's working! :)

    I don't have the hardware to test this, and I also seem to have an older stdlib.spin2 that's missing some functions you're using, so I can't even compile it :(. But things to try:
    (1) As a sanity check: does this exact code work correctly in PNut / PropTool?
    (2) Does the inline pasm depend on any hard coded registers? It doesn't look like it but it's worth double checking.
    (3) I don't see any printing in the init_smartpins() function. What exactly is getting stuck printing? What's it printing? Is it possible that it's stuck in some kind of reset loop?

    Yes, true, I've been changing me stdlib.spin2. Current edition attached.

    (1) Pnut compiles and runs too. No crashes. Test results aren't valid either but that is probably correct for the state it was in at that point.

    (2) Yes, that was the big change at the time, it attempts to use longwords at cogRAM $1e0 and $1e1. They're supposed to be available. I stopped doing that again soon after.

    (3) Yes, it is restarting the program over and over, even though there is no such path within the source code. Never gets past a certain point before starting over again. An actual reset would just stop and wait for a new program to download.

  • evanhevanh Posts: 13,424

    Ah, in hindsight Pnut is acting differently to -O0 --fcache=128. Pnut should be giving valid results too but is not.

  • evanhevanh Posts: 13,424

    Eric,
    One notable difference in the compiled assembly is when ptr__dat__ is changed. In the crashing compiles it is adjusted both before and after call #FCACHE_LOAD_, whereas the stable compiles does all the adjustments before the Fcache call.

        ...
    '     org
        loc pa, #(@LR__0030-@LR__0024)
        call    #FCACHE_LOAD_
        sub ptr__dat__, #4
    LR__0024
        org 0
        ...
    
  • Huh, that probably shouldn't end up there (between org 0 and FCACHE_LOAD). First suspect would be the "hoist matched add/sub out of loop" optimization I added at some point, but all of that should happen before auto-fcache? And it should be ignoring volatile IR by way of HasSideEffectsOtherThanReg... Obnoxiously there isn't a way to disable just that opt for testing (unless you build from source and comment out the the OptimizeLoopPtrOffset call in optimize_ir.c:4585)

  • ersmithersmith Posts: 5,404

    @evanh said:
    Eric,
    One notable difference in the compiled assembly is when ptr__dat__ is changed. In the crashing compiles it is adjusted both before and after call #FCACHE_LOAD_, whereas the stable compiles does all the adjustments before the Fcache call.

      ...
    '     org
      loc pa, #(@LR__0030-@LR__0024)
      call    #FCACHE_LOAD_
      sub ptr__dat__, #4
    LR__0024
      org 0
      ...
    

    Yep, that's definitely bad. I think the OptimizeIncDec optimization was being too aggressive. I've checked in a small change to dial that back, and that fixes the re-ordering of sub, at least. I hope it'll get you a bit further. Thanks for the bug report!

  • evanhevanh Posts: 13,424
    edited 2022-08-05 15:36

    Sorted, thanks. All the combinations are working. :)
    I suspect that bug had been there for quite a while. I don't know which ones off the top of my head but there was earlier code on other projects that would alternate between good and bad states of this ilk.

    I guess I'd hit the bug far more than others due to my almost constant use of inlined pasm. I haven't written a single program that coginit()'s. Well, not from compiled code at least.

    That's right, the CRC work got completely broadsided by this. It kept throwing me in a tangle trying to make building blocks for implementing full SD protocol with eventual plan to get 4-bit mode operating. It was all in C so I couldn't quickly compare on Pnut. Something to put back on the to-do list. :)

  • ersmithersmith Posts: 5,404

    @ManAtWork said:
    Ok, next problem. I can't find anything in the docs about how DEBUG is supported. It seems to work in Spin, e.g. if I put something like debug ("paintIcon", udec(bg), udec(fg)) into the assembler part in the DAT section inside the Spin2 code and switch on "BRK debug (P2 only)" in the options menu of FlexProp I can see the debug output in the terminal window.

    But if I try the same in the assembler part inside a C file then I get error messages like "unexpected '(' in line..." after the "debug" statement. I think PASM sections should be treated the same no matter if they are in a Spin or C file, shouldn't they.

    In the current github there is some support now for DEBUG inside a C __pasm section (not a plain __asm). It's quite incomplete, but enough to print simple registers.

  • evanhevanh Posts: 13,424
    edited 2022-08-06 05:20

    @evanh said:
    I suspect that bug had been there for quite a while.

    I've gone back to June last year is the oldest edition of the compiler, that I have a build of, that has built-in symbols I'm using: Version 5.5.1-beta-v5.4.3-45-gc4fdeb1d ... and the bug is present there too.

  • @ersmith said:
    In the current github there is some support now for DEBUG inside a C __pasm section (not a plain __asm). It's quite incomplete, but enough to print simple registers.

    Good to know, thanks, Eric. I currently write my low-level code in Propeller tool because there it's easier to debug. When I have finished the driver I'll include it into my C project. It's a bit complicated but saves time, at the moment. But I'm optimistic that I can can go back to using FlexProp for everything, one day...

  • evanhevanh Posts: 13,424

    For me, debug() is completely broken on both platforms because most of the test code I write calls clkset() in an incrementing loop. I rely on send() in Spin and printf() in C.

  • ersmithersmith Posts: 5,404

    @evanh said:

    @evanh said:
    I suspect that bug had been there for quite a while.

    I've gone back to June last year is the oldest edition of the compiler, that I have a build of, that has built-in symbols I'm using: Version 5.5.1-beta-v5.4.3-45-gc4fdeb1d ... and the bug is present there too.

    Interesting... I wouldn't have suspected it went back that far. Thanks for helping me find and fix this bug!

  • TonyB_TonyB_ Posts: 1,953

    In earlier versions, compiler generated warning: immediate value out of range for RDBYTE D,#S when #S = 256-511. Seemed to compile OK despite warning. Same for RDWORD / RDLONG / WRBYTE / WRWORD / WRLONG / WMLONG. Is this a known issue?

  • ersmithersmith Posts: 5,404

    @TonyB_ said:
    In earlier versions, compiler generated warning: immediate value out of range for RDBYTE D,#S when #S = 256-511. Seemed to compile OK despite warning. Same for RDWORD / RDLONG / WRBYTE / WRWORD / WRLONG / WMLONG. Is this a known issue?

    I believe the warning is correct, the immediate range for RDxxx/WRxxx is only 0-255. Immediate values with the high bit set are used for encoding special addressing modes like RDBYTE D, PTRB++. I suppose it probably should be an error rather than a warning, but I left it as a warning in case people are constructing those special addressing modes by hand.

  • TonyB_TonyB_ Posts: 1,953

    @ersmith said:

    @TonyB_ said:
    In earlier versions, compiler generated warning: immediate value out of range for RDBYTE D,#S when #S = 256-511. Seemed to compile OK despite warning. Same for RDWORD / RDLONG / WRBYTE / WRWORD / WRLONG / WMLONG. Is this a known issue?

    I believe the warning is correct, the immediate range for RDxxx/WRxxx is only 0-255. Immediate values with the high bit set are used for encoding special addressing modes like RDBYTE D, PTRB++. I suppose it probably should be an error rather than a warning, but I left it as a warning in case people are constructing those special addressing modes by hand.

    Understood now, it was the "warn but compile anyway" aspect that led to my query.

  • RaymanRayman Posts: 12,734
    edited 2022-08-17 23:52

    Seeing something strange with a CON section giving me an error:
    config.spin2:37: error: syntax error, unexpected number

    This is with NeoYume...

    I added this con section to define uSD pin settings:

    'uSD pins Uncomment for your board
    '{For P2 Eval
    uSD_CLK=59
    uSD_CS= 61
    uSD_MOSI=60
    uSD_MISO=58
    '}
    {For Simple P2 board
    uSD_CLK=53
    uSD_CS= 55
    uSD_MOSI=54
    uSD_MISO=52
    }
    {For P2 board1
    uSD_CLK=59
    uSD_CS= 61
    uSD_MOSI=60
    uSD_MISO=58
    }
    {For P2 Eval
    uSD_CLK=59
    uSD_CS= 61
    uSD_MOSI=60
    uSD_MISO=58
    }  
    

    Top and bottom settings are the same. If I use the top (as shown) , it gives this error. Works if I uncomment the bottom set...

    I attached this file, in case it helps... Can post all of it if needed.

  • RaymanRayman Posts: 12,734

    Gives this error when I remove this whole section and revert uSD code.
    So, guess it's not the code above but something else in the file... strange...

  • RaymanRayman Posts: 12,734

    Never mind. User error. Somehow a "1" got typed into the code in a bad place.
    False alarm...

Sign In or Register to comment.