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.
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.
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)
@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!
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.
@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 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...
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.
@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!
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?
@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_ 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.
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.
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.
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.
@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....
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]);
Comments
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.
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.
Thanks... okay, yay, that's working!
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.
Ah, in hindsight Pnut is acting differently to -O0 --fcache=128. Pnut should be giving valid results too but is not.
Eric,
One notable difference in the compiled assembly is when
ptr__dat__is changed. In the crashing compiles it is adjusted both before and aftercall #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)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!
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.
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.
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.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...
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.Interesting... I wouldn't have suspected it went back that far. Thanks for helping me find and fix this bug!
In earlier versions, compiler generated
warning: immediate value out of rangefor 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.
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.
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...
Never mind. User error. Somehow a "1" got typed into the code in a bad place.
False alarm...
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.
Thanks, Evan, there was a missing "return" in one case of a for-loop optimization. It should be fixed now.
Thanks.
Eric,
Looks like I've bumped into another compiler bug. In my source code below
jse2 #.retryandjnse1 #.waithave immediate operands but the.p2asmfile is missing the#in front of the labels.LR__0002 dirl #32 dirh #32 LR__0003 jse2 LR__0002 jnse1 LR__0003static 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; }@evanh : Thanks for the bug report! It should be fixed in the github source code now.
Beautiful, thanks Eric.
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:
The
ratioandrlnprinted values should have 6 decimal places each.@ersmith Getting an error with strtok()... Looking at string.h, I think it is not implemented yet. Is that true?
@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....
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...
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?
Got the code to compile, but doesn’t work…. Think I’ll look for a simpler example to start from.