@ersmith I cant really call this a bug, but here goes. In 5.0.3, if a function is defined to return string, but no return value ever gets assigned prior to exiting the function, the function returns garbage instead of an empty string. This demonstrates it.
print "["; BadFunc$(); "]"
FUNCTION BadFunc$() as string
' nothing here.
END FUNCTION
From a C point of view, this is a natural expectation when you don't specify a return value, but in BASIC the mantra is "all strings get initialized to an empty string". Is there any way to change this behavior so that a "safe" default return value (empty string) gets set up by the compiler automatically?
Edit: FWIW, the return value of an empty function that returns an integer or float correctly returns zero, so it is only the string-type functions that return uninitialized data.
Eric,
When using spin2, I note that flexprop (v5.0.3) does not set the hub locations $44 and $40 for clkfreq and clkmode, but it does indeed load correct values when clkfreq and clkmode is used.
@ersmith I cant really call this a bug, but here goes. In 5.0.3, if a function is defined to return string, but no return value ever gets assigned prior to exiting the function, the function returns garbage instead of an empty string.
Actually it always returns a NULL pointer (0). It's the printing function that's going "wrong", printing garbage (whatever happens to be at memory location 0) rather than something else. This patch causes it to print nothing instead:
Eric,
When using spin2, I note that flexprop (v5.0.3) does not set the hub locations $44 and $40 for clkfreq and clkmode, but it does indeed load correct values when clkfreq and clkmode is used.
FlexProp, like Tachyon, p2gcc, riscvp2, MicroPython, and I believe Catalina, uses locations $14 and $18 for these. It's Spin2 that's the odd one out, but Chip decided to go his own way.
Eric,
When using spin2, I note that flexprop (v5.0.3) does not set the hub locations $44 and $40 for clkfreq and clkmode, but it does indeed load correct values when clkfreq and clkmode is used.
FlexProp, like Tachyon, p2gcc, riscvp2, MicroPython, and I believe Catalina, uses locations $14 and $18 for these. It's Spin2 that's the odd one out, but Chip decided to go his own way.
@ersmith Flex V5.0.3: I found a case where the compiler throws a "fatal" error, but the compiler will still finish the compile and download it anyway. This code shows it:
dim i as long
dim x as long
for i = 1 to 10
x += 1
next x '<-- note x instead of i
The code outputs the appropriate compiler error: Wrong variable in next: expected i, saw x but this does not trigger the compiler to abort. If you're not watching the compiler output pane in FlexGUI, you'll miss it, and the code loads and runs, albeit with potentially odd results.
error: Internal error exceeded local register limit
Means the code needs more local variables than can fit into cog RAM. In my experience, disabling the CSE optimization pass ("-O2,~cse") fixes it. The GUI doesn't really have an option for this other than to go down to -O1 ("Default Optimization")
@ersmith Flex V5.0.3: I found a case where the compiler throws a "fatal" error, but the compiler will still finish the compile and download it anyway. This code shows it:
dim i as long
dim x as long
for i = 1 to 10
x += 1
next x '<-- note x instead of i
The code outputs the appropriate compiler error: Wrong variable in next: expected i, saw x but this does not trigger the compiler to abort. If you're not watching the compiler output pane in FlexGUI, you'll miss it, and the code loads and runs, albeit with potentially odd results.
Ah, interesting -- that one was a special case error that doesn't go through the normal error routines, and I forgot to flag it. Thanks for the bug report!
error: Internal error exceeded local register limit
Means the code needs more local variables than can fit into cog RAM. In my experience, disabling the CSE optimization pass ("-O2,~cse") fixes it. The GUI doesn't really have an option for this other than to go down to -O1 ("Default Optimization")
Yes, @Wuerfel_21 has good advice here. The other possible source of the problem is a function that is just too complicated to compile, but that's much rarer.
What causes this message? I assume something to do with fopen()... Code appears to work though...
1>Done.
1>Program size is 70980 bytes
1>The filename, directory name, or volume label syntax is incorrect.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
That's very bizarre. I don't even know what program is printing that. Did you run flexspin from make or something? Perhaps your make program doesn't like the file name you used -- does it have spaces in it or something? As near as I can see flexspin itself shouldn't print anything after the "Program size is xxx bytes".
I thought those threads settled things too and that we had all agreed on $14 and $18 for the clock frequency locations. Apparently only "almost" all of us agreed . I do wish Spin2 would use the same convention as everyone else though.
@Wuerfel_21 and @ersmith: Good input. Thank you both. Backing down the optimization level to "default optimization" fixes it. (FWIW, the code is something on the order of 10K lines once you count all the libs in, so it may be approaching the "too complicated" limit. Dunno!).
@Wuerfel_21 and @ersmith: Good input. Thank you both. Backing down the optimization level to "default optimization" fixes it. (FWIW, the code is something on the order of 10K lines once you count all the libs in, so it may be approaching the "too complicated" limit. Dunno!).
FWIW, the "too complicated" limit is per-function, so breaking up large functions into smaller ones may help.
Could it be that the built-in symbols for events and interrupt sources are not implemented in FlexSpin? (for example, EVENT_SE1) All the other predefined symbols for smart pins (P_PWM_SAWTOOTH, P_OE, P_ADC, ADDPINS...) seem to work. Ok, I know, in C I have to #include propeller2.h but in spin2 files the symbols should be there without special actions, shouldn't they.
Is there a simple way to tell the size of a file when using Plan 9?
That FSEEK way doesn't seem to work...
That's a bug then, and I'll try to fix it.
Another way to check the size of a file is with the stat() function:
#include <stdio.h>
#include <sys/stat.h>
int main()
{
int r;
struct stat s;
mount("/files", _vfs_open_host());
chdir("/files");
r = stat("filesize.c", &s);
if (r) {
perror("Unable to stat file");
return 1;
}
printf("size of file: %ld\n", s.st_size);
return 0;
}
I just noticed a strange behaviour of the compiler. I hope it's not one of my stupid mistakes, again...
This is inside a DAT section of a spin2 file:
rdlong theta,ptra ' works as expected
rdlong theta,ptrs ' typo, correctly throws an error, ptrs is undefined
rdlong theta,ptrs[4] ' does NOT throw an error!
rdlong theta,foo[4] ' any symbol seems to be ignored, foo is undefined
rdlong theta,foo[0] ' bad constant expression ???
I just noticed a strange behaviour of the compiler. I hope it's not one of my stupid mistakes, again...
This is inside a DAT section of a spin2 file:
rdlong theta,ptra ' works as expected
rdlong theta,ptrs ' typo, correctly throws an error, ptrs is undefined
rdlong theta,ptrs[4] ' does NOT throw an error!
rdlong theta,foo[4] ' any symbol seems to be ignored, foo is undefined
rdlong theta,foo[0] ' bad constant expression ???
There was a bug in the parsing of ptrx[n] type operands that caused errors not to be detected. Thanks for noticing this, it should be fixed now in github.
Are you saying using any long filenames will break the boot from sd process?
Or, that people are trying to boot from files with long filenames and it doesn't work?
Comments
Edit: FWIW, the return value of an empty function that returns an integer or float correctly returns zero, so it is only the string-type functions that return uninitialized data.
When using spin2, I note that flexprop (v5.0.3) does not set the hub locations $44 and $40 for clkfreq and clkmode, but it does indeed load correct values when clkfreq and clkmode is used.
FlexProp, like Tachyon, p2gcc, riscvp2, MicroPython, and I believe Catalina, uses locations $14 and $18 for these. It's Spin2 that's the odd one out, but Chip decided to go his own way.
typical
and https://forums.parallax.com/discussion/comment/1475446/#Comment_1475446
Means the code needs more local variables than can fit into cog RAM. In my experience, disabling the CSE optimization pass ("-O2,~cse") fixes it. The GUI doesn't really have an option for this other than to go down to -O1 ("Default Optimization")
Ah, interesting -- that one was a special case error that doesn't go through the normal error routines, and I forgot to flag it. Thanks for the bug report!
Yes, @Wuerfel_21 has good advice here. The other possible source of the problem is a function that is just too complicated to compile, but that's much rarer.
That's very bizarre. I don't even know what program is printing that. Did you run flexspin from make or something? Perhaps your make program doesn't like the file name you used -- does it have spaces in it or something? As near as I can see flexspin itself shouldn't print anything after the "Program size is xxx bytes".
I thought those threads settled things too and that we had all agreed on $14 and $18 for the clock frequency locations. Apparently only "almost" all of us agreed . I do wish Spin2 would use the same convention as everyone else though.
Tried to use "//" instead of "REM"...
FWIW, the "too complicated" limit is per-function, so breaking up large functions into smaller ones may help.
Yes, they're missing in 5.0.4. I'll add them in 5.0.5, thanks for pointing this out.
That FSEEK way doesn't seem to work...
That's a bug then, and I'll try to fix it.
Another way to check the size of a file is with the stat() function:
stat() is a standard file system call and should work with all file systems.
This is inside a DAT section of a spin2 file:
There was a bug in the parsing of ptrx[n] type operands that caused errors not to be detected. Thanks for noticing this, it should be fixed now in github.
Or, is it already there?
Also, is there a way to change which pins are assigned to the uSD card?
Or, that people are trying to boot from files with long filenames and it doesn't work?