@Rayman said:
Was contemplating writing P1 code in Spin2 and using the external tools feature in Spin Tools to invoke FlexProp to compile it...
Spin2 is way better that Spin1 IMHO and if can program Prop1 with it, want to try...
Mind that it's only fully-ish supported on the ASM backend (which has the usual problem of running out of RAM regardless of what language).
The Bytecode backend has trouble supporting all of the features because the bytecodes are essentially a 1:1 translation of a Spin1 AST into RPN, so any extra features need to be emulated using Spin1. We did some clever stuff to implement method pointers, multi-return, etc.
But feel free to try it.
@Rayman said:
Was contemplating writing P1 code in Spin2 and using the external tools feature in Spin Tools to invoke FlexProp to compile it...
Spin2 is way better that Spin1 IMHO and if can program Prop1 with it, want to try...
Imagining that the main issue is going to be that Spin Tools won't compile when an error is detected. Any way around that?
The internal compiler doesn't generate any binary when there are errors, but you can always launch an external compiler.
However, honestly, what's the point of using Spin Tools to write a source that won't compile and delegate to an external tool ?
You may be better with using Flexprop or VS Code for that, it can edit the source and launch flexspin to compile and run.
Yeah, it's the ASM part that think Spin Tools will flag as errors and rightly so.
PASM is PASM, the p1asm (or p2asm) produced by flexspin is compatible with Spin Tools, I have also added the extensions to load these files in the editor, just in case.
Comments
Was contemplating writing P1 code in Spin2 and using the external tools feature in Spin Tools to invoke FlexProp to compile it...
Spin2 is way better that Spin1 IMHO and if can program Prop1 with it, want to try...
Imagining that the main issue is going to be that Spin Tools won't compile when an error is detected. Any way around that?
Mind that it's only fully-ish supported on the ASM backend (which has the usual problem of running out of RAM regardless of what language).
The Bytecode backend has trouble supporting all of the features because the bytecodes are essentially a 1:1 translation of a Spin1 AST into RPN, so any extra features need to be emulated using Spin1. We did some clever stuff to implement method pointers, multi-return, etc.
But feel free to try it.
Yeah, it's the ASM part that think Spin Tools will flag as errors and rightly so.
The internal compiler will flag errors but the external compiler will still work -- that is my experience with PNut.
The internal compiler doesn't generate any binary when there are errors, but you can always launch an external compiler.
However, honestly, what's the point of using Spin Tools to write a source that won't compile and delegate to an external tool ?
You may be better with using Flexprop or VS Code for that, it can edit the source and launch flexspin to compile and run.
PASM is PASM, the p1asm (or p2asm) produced by flexspin is compatible with Spin Tools, I have also added the extensions to load these files in the editor, just in case.