@TonyB_ said:
I've searched this thread and FlexProp v5.0.2 should support the rev.A. I have no idea what last version of PNut works. Did Spin2 ever work with rev.A?
Pnut never mixed them. Pre-v33 was revA. v33 onwards is revB/C. Needless to say Chip's Spin2 interpreter never supported revA.
I've attached a repackaged zip of the final v32j files. The original download contained a lot of FPGA bin files that made it 21 MB. I've stripped all those out.
EDIT: Corrected from v31 to v32j
Thanks a lot, Evan. The .spin2 files seem to assume an FPGA.
Yes, they would, revA hadn't shipped. The only silicon that anyone had seen at that stage was a few parts of just the pad-ring and dummy synthesis that Chip used for testing the custom circuits.
Eric,
I've just had an attempt at using flexspin to build Wuerfel's VJET demo. Using Git master branch (Version 5.2.0 Compiled on: Feb 28 2021), my first bump was I had to move OBJ section ahead of VAR section in top program "p2test.spin2". This eliminated a compile error, eg: "p2test.spin2:34: error: request for member REGION_SIZE in something not an object". It compiled after that.
Runtime behaviour certainly wasn't right though. It behaved like a bunch of parameters were winding to limits. I'll hassle Wuerfel about that so we can be more specific for you ...
Uhh, that should be working, but I admit I never tested the VJET demo in flexspin. The order of the sections should not matter, that seems like a bug. If you have a picture or video of what weirdness is going on, that'd help, too.
@evanh said:
I've just had an attempt at using flexspin to build Wuerfel's VJET demo. Using Git master branch (Version 5.2.0 Compiled on: Feb 28 2021), my first bump was I had to move OBJ section ahead of VAR section in top program "p2test.spin2". This eliminated a compile error, eg: "p2test.spin2:34: error: request for member REGION_SIZE in something not an object". It compiled after that.
I think that's a consequence of the change I made in 5.2.0 to create variable declarations in the order they were made, rather than re-arranging them as Spin1 did. Flexspin treats OBJ like any other variable (from the compiler's point of view they are like C structs) and so the ones declared after the VAR section hadn't been created yet. I'll have to add another special pass for OBJs, ugh. For now moving them before the VAR is the correct work-around.
Runtime behaviour certainly wasn't right though. It behaved like a bunch of parameters were winding to limits. I'll hassle Wuerfel about that so we can be more specific for you ...
That must be another issue, if you could provide some more details I'll look into it.
Hmm, maybe SCAS is not correctly implemented? Both the 3D viewer demo and Spin Hexagon use the Spin1** operator. The latter I just compile through flexspin as-is, but the former has been converted to Spin2 for its P2 version, where SCAS has to be used. It behaves differently, maybe flexspin didn't get the memo.
If the "const" is deleted in the above, FlexSpin seems OK with it.
Is this the solution, or a mistake?
Also, a minor question... Thinking about real "doubles" in FlexSpin C?
I'm hoping this code will work even though Fastspin's doubles are 32 bit. But, it might not...
Sorry, should have mentioned.. The errors are like this:
1>genann.c:180: error: Expecting object for dereference of total_weights
1>genann.c:180: error: Expecting object for dereference of total_neurons
1>genann.c:180: error: Expecting object for dereference of total_neurons
1>genann.c:180: error: Expecting object for dereference of inputs
1>genann.c:180: error: Method reference on non-class expression
1>genann.c:180: error: Method reference on non-class expression
@Rayman : It seems like there's a bug in flexspin's handling of const parameters -- specifically it's not parsing "struct foo const" correctly, although it does understand "const struct foo" (which should be the same thing). For now just removing the const is fine. "const" in C just a hint to the compiler that you don't intend to modify the variable.
Hi @ersmith
I know FlexSpin can read inline comments on method definition lines to effect some compiler switches, but would it be an easy enough change to ignore empty curly-braces {} in those cases or consider them plain comments? I ask because it seems to have an issue when I use them in conjunction with any preprocessor directives.
I use empty braces in spin1 method definition code as an easy/quick way to use automated tools to convert to spin2 (e.g., PUB MyMethod{} in spin1 is easy to convert with a simple s/{}/()/g to PUB MyMethod() for the equivalent spin2), but the compiler bombs when it also encounters preprocessor directives in the child:
' Parent object
#include "braces_child.spin"
PUB Main
' Child object
PUB Null{}
' This is not a top-level object
#define I_WILL_FAIL_HERE
Press ENTER or type command to continue
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc.
Version 5.3.2 Compiled on: Apr 4 2021
braces_preproc_test.spin
braces_child.spin:4: error: syntax error, unexpected '#'
@Rayman said:
What about 64-bit fixed point? That seems like it should be a lot easier, right?
I'm not asking for this, btw... Just curious what is possible...
Not much easier, alas. The problem is that internally everything is represented in 32 bits, so 64 bit support needs some re-working of the compiler internals. There are some hacks to partially get things working, but I don't know when actual support will be there.
@avsa242 : It seems there's some kind of bug in the parsing of comments so that "{}" causes issues. it's not specifically a problem with method definition lines, I think it could happen anywhere. For now a work-around is to put a space inside the comment "{ }".
Eric,
Regression with incorrect line numbers of errors/warnings. Latest Flexspin master: 5.3.3-beta-v5.3.2-5-g4a3144d7
EDIT: Oh, it's reporting the .p2asm file!
EDIT2: Umm, when it's a pure pasm2 assemble it reports as the .pasm2 filename but the line number is wrong then too.
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc.
Version 5.3.3-beta-v5.3.2-5-g4a3144d7 Compiled on: Apr 6 2021
steve_hatch.spin2
steve_hatch.spin2
steve_hatch.spin2:39: warning: First operand to dirh is a constant used without #; is this correct? If so, you may suppress this warning by putting -0 after the operand
steve_hatch.spin2:39: warning: First operand to dirh is a constant used without #; is this correct? If so, you may suppress this warning by putting -0 after the operand
Done.
Program size is 140 bytes
Typo on line 25 of .spin2. Line 183 of .p2asm is the correct line number. Maybe this is normal, I've not been writing any mixed code myself.
streamer-basic.spin2
streamer-basic.p2asm
streamer-basic.p2asm:183: warning: First operand to dirh is a constant used without #; is this correct? If so, you may suppress this warning by putting -0 after the operand
streamer-basic.p2asm:183: warning: First operand to dirh is a constant used without #; is this correct? If so, you may suppress this warning by putting -0 after the operand
Done.
Program size is 1724 bytes
@ersmith I have a really odd one. In FlexBASIC (current version) any strings derived from a cast(string, ubyte array) are correct within the function... but if you try to pass them back they contain garbage or are empty. The code below demonstrates this:
dim tmp$ as string
tmp$ = Test$()
print "Outside TEST$() = ["; tmp$; "]"
print "Done"
' ======================================================================================
FUNCTION Test$() as string
dim buff as ubyte(64) 'SEE EDIT NOTE
dim p as ulong
dim t$ as string
for p = 0 to 62
buff(p) = 88 'fill BUFF() with 63 "X"s
next p
buff(63) = 0 'append end-of-string char @ last byte position
t$ = cast(string, buff) 'cast BUFF() to T$
print "Inside TEST$() = ["; t$; "]" 'print T$. THIS WORKS FINE
return t$ 'return T$ THIS DOESNT RETURN T$. Odd...
END FUNCTION
@JRoark : any memory declared locally (like the buff array in your test$ function) will stop being valid when the function returns. That means that returning buff or any pointer to buff from the function will not work properly. A string is just a pointer to some memory.
Probably it would be useful for a warning or error to be printed on the cast to string (since it's a local variable being cast). On the other hand this won't be easy, since actually the cast is perfectly OK as long as the variable isn't returned.
@ersmith At the risk of being obtuse, I’m still confused.
What is being returned by the TEST$() function in both cases is T$. The source of T$ contents shouldnt matter because after the cast, T$ now holds a copy of whatever came out of that cast. Or is my fundamental error thinking that T$ is a copy when in fact it is just a pointer to whatever was fed to CAST? If that is true, then it would appear the NEW syntax is allocating persistant memory that doesnt get reclaimed when the function ends?
I’ll re-caffinate and re-read what you wrote more carefully, but its clear I am making some assumptions about strings and memory management that FlexBASIC disagrees with. (I hate it when reality doesnt conform to my entitled expectations! Hehehe.)
EDIT: The lightbulb in my head just went on. “...OR ANY POINTER TO BUFF...“ T$ isnt a copy. Duh. Now I get it. And you even put it in italics for me...
Variables declared in a function are allocated on the stack. Once the function ends that stack space is still valid but other functions down the road will use this same space. Only memory allocate will create space in memory that is not on the stack.
@iseries said:
Variables declared in a function are allocated on the stack. Once the function ends that stack space is still valid but other functions down the road will use this same space. Only memory allocate will create space in memory that is not on the stack.
And that non-stack allocation is what NEW does, correct?
@JRoark : Looks like you've figured this out, but yes, non-stack allocation is what NEW does. CASTing from an array to a pointer type (like a string) doesn't do a copy, it just finds the address of the array and puts it into the pointer.
Comments
Thanks a lot, Evan. The .spin2 files seem to assume an FPGA.
Yes, they would, revA hadn't shipped. The only silicon that anyone had seen at that stage was a few parts of just the pad-ring and dummy synthesis that Chip used for testing the custom circuits.
Only pasm was supported on the FPGA. Spin2 (HLL) was only developed on RevB AFAIK.
I think it came into existence at v34.
Eric,
I've just had an attempt at using flexspin to build Wuerfel's VJET demo. Using Git master branch (Version 5.2.0 Compiled on: Feb 28 2021), my first bump was I had to move OBJ section ahead of VAR section in top program "p2test.spin2". This eliminated a compile error, eg: "p2test.spin2:34: error: request for member REGION_SIZE in something not an object". It compiled after that.
Runtime behaviour certainly wasn't right though. It behaved like a bunch of parameters were winding to limits. I'll hassle Wuerfel about that so we can be more specific for you ...
@evanh
Uhh, that should be working, but I admit I never tested the VJET demo in flexspin. The order of the sections should not matter, that seems like a bug. If you have a picture or video of what weirdness is going on, that'd help, too.
Since this is the flexspin thread, I should point out that flexspin (then called fastspin) supported Spin on the FPGA
.
I think that's a consequence of the change I made in 5.2.0 to create variable declarations in the order they were made, rather than re-arranging them as Spin1 did. Flexspin treats OBJ like any other variable (from the compiler's point of view they are like C structs) and so the ones declared after the VAR section hadn't been created yet. I'll have to add another special pass for OBJs, ugh. For now moving them before the VAR is the correct work-around.
That must be another issue, if you could provide some more details I'll look into it.
Hmm, maybe
SCASis not correctly implemented? Both the 3D viewer demo and Spin Hexagon use the Spin1**operator. The latter I just compile through flexspin as-is, but the former has been converted to Spin2 for its P2 version, where SCAS has to be used. It behaves differently, maybe flexspin didn't get the memo.Got a question about the use of "const" with FlexSpin C (and C in general I guess...).
Was just trying to compile this artificial neural network code: https://github.com/codeplea/genann
FlexSpin C seems to have issue with the use of "const" in lines like this:
double const *genann_run(genann const *ann, double const *inputs) { double const *w = ann->weight; double *o = ann->output + ann->inputs; double const *i = ann->output;If the "const" is deleted in the above, FlexSpin seems OK with it.
Is this the solution, or a mistake?
Also, a minor question... Thinking about real "doubles" in FlexSpin C?
I'm hoping this code will work even though Fastspin's doubles are 32 bit. But, it might not...
I'd guess the problem is a warning message. What is the warning message?
Sorry, should have mentioned.. The errors are like this:
@Rayman : It seems like there's a bug in flexspin's handling of const parameters -- specifically it's not parsing "struct foo const" correctly, although it does understand "const struct foo" (which should be the same thing). For now just removing the const is fine. "const" in C just a hint to the compiler that you don't intend to modify the variable.
Ok, thanks. I'll just do a global delete then, for now...
Are 64-bit doubles on the horizon, or does that just not make any sense on 32-bit MCU?
64 bit doubles will be a lot of work. Perhaps someday flexspin may have them, but not soon.
What about 64-bit fixed point? That seems like it should be a lot easier, right?
I'm not asking for this, btw... Just curious what is possible...
Hi @ersmith
I know FlexSpin can read inline comments on method definition lines to effect some compiler switches, but would it be an easy enough change to ignore empty curly-braces {} in those cases or consider them plain comments? I ask because it seems to have an issue when I use them in conjunction with any preprocessor directives.
I use empty braces in spin1 method definition code as an easy/quick way to use automated tools to convert to spin2 (e.g.,
PUB MyMethod{}in spin1 is easy to convert with a simples/{}/()/gtoPUB MyMethod()for the equivalent spin2), but the compiler bombs when it also encounters preprocessor directives in the child:' Child object PUB Null{} ' This is not a top-level object #define I_WILL_FAIL_HERENo biggie, if not.
Cheers
Not much easier, alas. The problem is that internally everything is represented in 32 bits, so 64 bit support needs some re-working of the compiler internals. There are some hacks to partially get things working, but I don't know when actual support will be there.
@avsa242 : It seems there's some kind of bug in the parsing of comments so that "{}" causes issues. it's not specifically a problem with method definition lines, I think it could happen anywhere. For now a work-around is to put a space inside the comment "{ }".
Eric,
Regression with incorrect line numbers of errors/warnings. Latest Flexspin master: 5.3.3-beta-v5.3.2-5-g4a3144d7
EDIT: Oh, it's reporting the .p2asm file!
EDIT2: Umm, when it's a pure pasm2 assemble it reports as the .pasm2 filename but the line number is wrong then too.
It would be helpful if you could provide an example...
Typo is on line 36.
Typo on line 25 of .spin2. Line 183 of .p2asm is the correct line number. Maybe this is normal, I've not been writing any mixed code myself.
Thanks Evan, I'll look into it.
@ersmith I have a really odd one. In FlexBASIC (current version) any strings derived from a cast(string, ubyte array) are correct within the function... but if you try to pass them back they contain garbage or are empty. The code below demonstrates this:
dim tmp$ as string tmp$ = Test$() print "Outside TEST$() = ["; tmp$; "]" print "Done" ' ====================================================================================== FUNCTION Test$() as string dim buff as ubyte(64) 'SEE EDIT NOTE dim p as ulong dim t$ as string for p = 0 to 62 buff(p) = 88 'fill BUFF() with 63 "X"s next p buff(63) = 0 'append end-of-string char @ last byte position t$ = cast(string, buff) 'cast BUFF() to T$ print "Inside TEST$() = ["; t$; "]" 'print T$. THIS WORKS FINE return t$ 'return T$ THIS DOESNT RETURN T$. Odd... END FUNCTIONEdit Note: The workaround is to replace this
with
@JRoark : any memory declared locally (like the buff array in your test$ function) will stop being valid when the function returns. That means that returning buff or any pointer to buff from the function will not work properly. A string is just a pointer to some memory.
Probably it would be useful for a warning or error to be printed on the cast to string (since it's a local variable being cast). On the other hand this won't be easy, since actually the cast is perfectly OK as long as the variable isn't returned.
@ersmith At the risk of being obtuse, I’m still confused.
What is being returned by the TEST$() function in both cases is T$. The source of T$ contents shouldnt matter because after the cast, T$ now holds a copy of whatever came out of that cast. Or is my fundamental error thinking that T$ is a copy when in fact it is just a pointer to whatever was fed to CAST? If that is true, then it would appear the NEW syntax is allocating persistant memory that doesnt get reclaimed when the function ends?
I’ll re-caffinate and re-read what you wrote more carefully, but its clear I am making some assumptions about strings and memory management that FlexBASIC disagrees with. (I hate it when reality doesnt conform to my entitled expectations! Hehehe.)
EDIT: The lightbulb in my head just went on. “...OR ANY POINTER TO BUFF...“ T$ isnt a copy. Duh. Now I get it. And you even put it in italics for me...
Variables declared in a function are allocated on the stack. Once the function ends that stack space is still valid but other functions down the road will use this same space. Only memory allocate will create space in memory that is not on the stack.
Mike
And that non-stack allocation is what NEW does, correct?
@JRoark : Looks like you've figured this out, but yes, non-stack allocation is what NEW does. CASTing from an array to a pointer type (like a string) doesn't do a copy, it just finds the address of the array and puts it into the pointer.