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

ersmith · 2022-08-02 21:20

@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.

evanh · 2022-08-03 00:42

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.

evanh · 2022-08-03 00:45

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

evanh · 2022-08-03 14:03

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
    ...

Wuerfel_21 · 2022-08-03 14:17

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)

ersmith · 2022-08-05 14:45

@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!

evanh · 2022-08-05 15:07

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.

ersmith · 2022-08-05 23:01

@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.

evanh · 2022-08-06 05:17

@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.

ManAtWork · 2022-08-06 09:10

@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...

evanh · 2022-08-06 10:20

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.

ersmith · 2022-08-06 11:15

@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_ · 2022-08-14 23:37

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?

ersmith · 2022-08-15 11:42

@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_ · 2022-08-15 12:06

@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.

Rayman · 2022-08-17 23:51

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.

Rayman · 2022-08-18 00:40

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...

Rayman · 2022-08-18 00:46

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

evanh · 2022-09-28 06:07

Eric,
Just tried out an -O2 compile and it crashes the compiler to a core dump. Source code attached. What's interesting is when switching to using global variables in the fibo() function it compiles and runs fine.

ersmith · 2022-09-28 12:40

Thanks, Evan, there was a missing "return" in one case of a for-loop optimization. It should be fixed now.

evanh · 2022-09-28 12:49

Thanks.

evanh · 2022-10-01 21:26

Eric,
Looks like I've bumped into another compiler bug. In my source code below jse2 #.retry and jnse1 #.wait have immediate operands but the .p2asm file is missing the # in front of the labels.

LR__0002
    dirl    #32
    dirh    #32
LR__0003
    jse2    LR__0002
    jnse1   LR__0003

static uint32_t  spi_shift_in(uint8_t *addr)
{
    uint32_t  data, count = 0;    // bytes received

    __asm volatile { // no optimising and enforces Fcache use - Needed to free up the FIFO
        setse1  #2<<6 | CS    // falling edge event
        setse2  #3<<6 | CLK    // any edge event
        wrfast  #0, addr    // setup the hubRAM FIFO hardware for sequencial writes
.retry
        dirl    #MOSI    // disable/reset SPI RX smartpin
        dirh    #MOSI    // enable SPI RX smartpin
.wait
        jse2    #.retry
        jnse1   #.wait

        rep @.rend, #0    // loop forever, 14 ticks per loop
        testp   #CS   wz
        testp   #MOSI   wc   // check for completed byte
if_nc_and_z jmp #.rend    // break loop if CS high
    if_c    rdpin   data, #MOSI   // collect the received byte
    if_c    rev data
    if_c    wfbyte  data    // write to FIFO (hubRAM)
    if_c    add count, #1
.rend
        tjz count, #.retry  // try again when CS low glitches without data
    } // Exiting of Fcache/Cogexec triggers an implicit RDFAST - flushing remaining FIFO content to hubRAM

    return count;
}

ersmith · 2022-10-01 23:16

@evanh : Thanks for the bug report! It should be fixed in the github source code now.

evanh · 2022-10-01 23:31

Beautiful, thanks Eric.

evanh · 2022-10-29 09:24

Hehe, got a comical FlexC bug. printf() with %f formatting retains last length specified that is passed to subsequent %f in the same format string.
eg:

        printf( "gio = %d  vio = %d  value = %d  Temperature = %.2f  Ratio = %f  rln = %f\n",
                gio, vio, value, temperature, ratio, log(ratio) );

Produces the following:

gio = 3167  vio = 14001  value = 12843  Temperature = 93.70  Ratio = 0.12  rln = -2.12
gio = 3167  vio = 14001  value = 12841  Temperature = 93.62  Ratio = 0.12  rln = -2.12
gio = 3168  vio = 14000  value = 12840  Temperature = 93.61  Ratio = 0.12  rln = -2.12
gio = 3161  vio = 13995  value = 12836  Temperature = 93.66  Ratio = 0.12  rln = -2.12
gio = 3165  vio = 13997  value = 12836  Temperature = 93.57  Ratio = 0.12  rln = -2.12

The ratio and rln printed values should have 6 decimal places each.

Rayman · 2022-10-29 16:49

@ersmith Getting an error with strtok()... Looking at string.h, I think it is not implemented yet. Is that true?

Rayman · 2022-10-29 17:49

@ersmith Found a my_strtok() on internet and seems to work.
But, now have a bigger problem... Getting this error trying to compile the Wiznet library:
1>EXEC : error : Internal error exceeded local register limit, possibly due to -O2 optimization needing additional registers or code being too complicated

If I comment out the main rountine call in wiznet.c it compiles:
httpServer_run(i);

Maybe it is just to complex to compile, but I'm attaching source, in case you can fix the problem....

Rayman · 2022-10-29 18:06

This seems to be the function that makes it fail:
static void http_process_handler(uint8_t s, st_http_request * p_http_request)

Looks like this is where it actually handles the http request...

Rayman · 2022-10-29 20:43

Think I'm finding a work around in http_process_handler().

But, it was then hanging on this line:
printf(" MAC : %02X:%02X:%02X:%02X:%02X:%02X\n", net_info.mac[0], net_info.mac[1], net_info.mac[2], net_info.mac[3], net_info.mac[4], net_info.mac[5]);

Any idea why?

Rayman · 2022-10-30 00:20

Got the code to compile, but doesn’t work…. Think I’ll look for a simpler example to start from.

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

Comments