I've fixed the object reference bug, as well as several other bugs, and added CALL and REG builtins. All of that is in the github source code, for those of you who are building it from source. I've also put a binary release of the beta up on my Patreon page.
Assuming no more big bugs are found, I hope to release a final binary in the next few days.
I've fixed the object reference bug, as well as several other bugs, and added CALL and REG builtins. All of that is in the github source code, for those of you who are building it from source. I've also put a binary release of the beta up on my Patreon page.
Assuming no more big bugs are found, I hope to release a final binary in the next few days.
Thanks, Eric! You provide phenomenal support for your tools!
Here's the latest version of FemtoBasic for P2 and FastSpin. I've incorporated the FSRW routines from another thread and will see if I can get that working. I've had some flakiness from FastSpin where things that worked earlier stopped working as I added or changed code distant from the buggy stuff, then worked again later for some unknown reason. Some of this has improved with later FastSpin versions. LOOKUPZ was one such weird bug ... now I've gone to using a table to find the characters for hex digits.
What works: Most of the stuff from the P1 version except for I/O like OPEN, CLOSE, READ, WRITE, SAVE, LOAD. There's a new construct for named constants, mostly for smart pin control. You can say: PRINT `P_TRUE_B and the name `P_TRUE_B will be replaced with the equivalent constant value. Lower and upper case are interchangable except in strings.
Here's the latest version of FemtoBasic for P2 and FastSpin. I've incorporated the FSRW routines from another thread and will see if I can get that working. I've had some flakiness from FastSpin where things that worked earlier stopped working as I added or changed code distant from the buggy stuff, then worked again later for some unknown reason. Some of this has improved with later FastSpin versions. LOOKUPZ was one such weird bug ... now I've gone to using a table to find the characters for hex digits.
Mike: if you find something that doesn't work, could you please post an example? I really want to fix bugs. I have used LOOKUPZ successfully, so I'd be curious to see what in your code environment causes it not to work.
Eric, I will post examples when I can find them. In this case, the consoleHex method around line 260 produced what seemed to be spaces after it had been working nearly forever. At that time, the last line of the method was:
I made some unrelated changes near the end of the program and this worked again. After different changes near the middle of the program, it failed again. I decided to change from using a LOOKUPZ to an initialized byte array and that now has worked.
Is there a way of easily calling a Spin2 functions from PASM (in an interrupt service routine)? Or do I have to know everything about the calling conventions and internal workings of FastSpin?
Surac,
PNut is the current "official" compiler system for the P2 and is being developed by Chip Gracey who also developed the P2 with a lot of input from forum members. It accepts Spin and assembly language and the Spin is compiled to an interpretive code with the interpreter packaged along with the interpretive code and any assembler output. The compiler only runs under Windows
FastSpin is a package containing an editor, several frontends including C, Basic, and Spin, an assembler, and backends for both the P1 and P2. It is built to run under Windows, MacOS X, and Linux. FlexGUI is an integrated development environment with an editor and essentially FastSpin.
I have a Mac, so I'm biased towards using FastSpin although I can run Windows on the Mac and have tried PNut.
FlexGui is the graphical front end for FastSpin, both written by @ersmith.
Not official, not from Parallax.
Fastspin compiles Basic, C, Spin1 and Spin2 for the P1 and the P2 and creates binaries in native machine language.
Pnut is the current official compiler from Parallax for the P2, PropTool is the current official compiler from Parallax for the P1. Both are windows programs, but also run on Linux if you have Wine or something alike that.
PropTool will be extended to support the P2 as soon as Chip will finalize the Spin2 language.
Pnut and PropTool compile Spin code into some bytecode which is then interpreted by a bytecode interpreter written in the native machine language.
The basic idea here is that the byte code is smaller then native PASM, so a Spin program compiled with Pnut/PropTool is smaller (in byte size/memory footprint) as compiled with FastSpin, but also slower.
Currently Chip is rewriting his compiler in Spin to be able to run the compiler on the P2 itself, so the language is not finalized yet, but Eric (@ersmith) is following everything Chip does and does a wonderful job there.
Then we have Catalina, a C compiler for P1 and P2 written by @RossH, completely independent of Spin, also compiling to native machine language. Not official Parallax.
And finally there is TAQOZ which is a FORTH running on the P2 and is in the ROM of the P2, there is also TACHION as a FORTH for the P1, both written by @"Peter Jakacki" not by Parallax.
There is also a (very old) version of GCC called PropGcc compiling C and C++ for the P1, but Parallax does not have the funds currently to port GCC to the P2.
So Eric did some other funny project and build a RISC V emulator for the P2, so you can use the standard GCC for RISC V to compile c and c++ for the P2.
And finally there is TAQOZ which is a FORTH running on the P2 and is in the ROM of the P2, there is also TACHION as a FORTH for the P1, both written by @"Peter Jakacki" not by Parallax.
I guess you could argue that TAQOZ is "from Parallax" since they put it in the P2 ROM. It's more "official" than some of the other options even though it wasn't written by a Parallax employee.
At the moment, Wine does not work with the current (10.15.4) MacOS X version, so you can't use PropTool on a current (or future) Mac without changes to Wine. There are other Windows emulators like Parallels Desktop that can be used, but they're not free.
At the moment, Wine does not work with the current (10.15.4) MacOS X version, so you can't use PropTool on a current (or future) Mac without changes to Wine. There are other Windows emulators like Parallels Desktop that can be used, but they're not free.
Try VirtualBox. It's free and it worked well when I used it a while ago. I guess I'm not certain it works with the latest OS X though.
Is there a way of easily calling a Spin2 functions from PASM (in an interrupt service routine)? Or do I have to know everything about the calling conventions and internal workings of FastSpin?
It's probably not easy to call high level functions from an ISR, because there could be nasty conflicts with register usage (the compiler uses some fixed registers like muldiva and muldivb for some operations, and leaf functions (ones that don't call others) don't save any registers. So I don't think it's practical to use ISRs with the high level languages right now.
There are a variety of approaches that P2 languages use:
(1) PNut, TAQOZ, micropython, and junkbasic use bytecodes of one sort or another
(2) fastspin, p2gcc, and Catalina generate native machine language
(3) riscvp2 generates RISC-V instructions which are then compiled to P2 instructions at run time (JIT)
(4) proplisp interprets its own internal data structures; I think FemtoBASIC does that too?
Is there a way of easily calling a Spin2 functions from PASM (in an interrupt service routine)? Or do I have to know everything about the calling conventions and internal workings of FastSpin?
/Johannes
You would need to have the spin interpreter loaded and initialised, so you would have needed to call pasm from spin.
Don't forget that since spin is interpreted it will be much slower than pasm so it's not ideal.
Having said that, IIRC Chip said spin can run interrupt code, so it's very possible.
Is there a way of easily calling a Spin2 functions from PASM (in an interrupt service routine)? Or do I have to know everything about the calling conventions and internal workings of FastSpin?
/Johannes
You would need to have the spin interpreter loaded and initialised, so you would have needed to call pasm from spin.
Don't forget that since spin is interpreted it will be much slower than pasm so it's not ideal.
@Ahle2 is using fastspin, so no need for the spin2 interpreter -- fastspin compiles Spin and Spin2 to machine code directly.
In general calling back to Spin2 from PASM in fastspin can be accomplished most easily via a function pointer. If "myobj.foo" is a method, then "@myobj.foo" is a 32 bit pointer to two 32 bit values: the first is a pointer to the "myobj" object data, and the second is a pointer to the function to call. So you can do something like:
' call via function pointer currently in pb
' pb points to (object, method) pair
wrlong objptr, ptra++ ' push current object pointer
rdlong objptr, pb ' fetch new object pointer
add pb, #4
rdlong pb, pb ' fetch function pointer
calla pb ' call function
sub ptra, #4
rdlong ptra, objptr ' restore object pointer
This won't always be safe in an ISR though because the code fastspin generates isn't re-entrant.
What is the memory map used by fastspin? Where is code loaded? Where is the stack placed? How can I know what memory is still available after loading a program?
There is a command line switch (-H) to specify the starting address, but the default is 0. First comes whatever COG code is needed (very little for the P2, just enough to bootstrap). Then comes the hubexec code. Then comes the data (including all variables). The heap (the size of which is given by HEAPSIZE) is part of that data. After that comes the stack, which grows upwards towards the end of memory. You can access the stack pointer by the variable "sp" in inline assembly, or by calling __getsp() in a high level language. The stuff above that is "free" (as long as you don't need a deeper stack, of course).
What is the prototype for _getsp() and what header file should I include to use it? I tried this code but got an error:
There's no header file for _getsp(), it's a built in Spin function (so it has no type, it returns a raw 32 bit value). You'll probably want to just cast its return value to whatever type you want.
There's no header file for _getsp(), it's a built in Spin function (so it has no type, it returns a raw 32 bit value). You'll probably want to just cast its return value to whatever type you want.
I tried casting it and got this:
/Users/dbetz/Dropbox/work/junkbasic/osint_posix.c:36: error: unknown identifier _getsp used in function call
/Users/dbetz/Dropbox/work/junkbasic/osint_posix.c:36: error: Unknown symbol _getsp
Sorry, the function has two underscores at the beginning: __getsp().
Having said that, on P2 the stack pointer is just ptra, so it's easy enough to get the value using inline assembly. For example you could write your own version of getsp like:
Sorry, the function has two underscores at the beginning: __getsp().
Having said that, on P2 the stack pointer is just ptra, so it's easy enough to get the value using inline assembly. For example you could write your own version of getsp like:
Thanks! Adding the extra underscore worked fine. How big is the default HEAPSIZE? I assume I need a heap since I'm calling fopen but how big a one is necessary to use the filesystem code? I don't ever call malloc or calloc myself.
Comments
Assuming no more big bugs are found, I hope to release a final binary in the next few days.
What works: Most of the stuff from the P1 version except for I/O like OPEN, CLOSE, READ, WRITE, SAVE, LOAD. There's a new construct for named constants, mostly for smart pin control. You can say: PRINT `P_TRUE_B and the name `P_TRUE_B will be replaced with the equivalent constant value. Lower and upper case are interchangable except in strings.
Mike: if you find something that doesn't work, could you please post an example? I really want to fix bugs. I have used LOOKUPZ successfully, so I'd be curious to see what in your code environment causes it not to work.
Thanks,
Eric
consoleOut(lookupz((v ROL= 4) & $F : "0".."9", "A".."F"))
I made some unrelated changes near the end of the program and this worked again. After different changes near the middle of the program, it failed again. I decided to change from using a LOOKUPZ to an initialized byte array and that now has worked.
This sort of thing is terrible to try to find.
Is there a way of easily calling a Spin2 functions from PASM (in an interrupt service routine)? Or do I have to know everything about the calling conventions and internal workings of FastSpin?
/Johannes
please help me to understand the programming options for P2.
There is the Fastspin compiler system
There is the FlexGui compiler system
There is the Pnut compiler system
- are this different frontends for the same compiler?
- do the all create equal assembler code?
- is any of this compiler seen to be the official one?
Sry for asking this question, but im a bit confused. most µC come with only one compiler
PNut is the current "official" compiler system for the P2 and is being developed by Chip Gracey who also developed the P2 with a lot of input from forum members. It accepts Spin and assembly language and the Spin is compiled to an interpretive code with the interpreter packaged along with the interpretive code and any assembler output. The compiler only runs under Windows
FastSpin is a package containing an editor, several frontends including C, Basic, and Spin, an assembler, and backends for both the P1 and P2. It is built to run under Windows, MacOS X, and Linux. FlexGUI is an integrated development environment with an editor and essentially FastSpin.
I have a Mac, so I'm biased towards using FastSpin although I can run Windows on the Mac and have tried PNut.
Not official, not from Parallax.
Fastspin compiles Basic, C, Spin1 and Spin2 for the P1 and the P2 and creates binaries in native machine language.
Pnut is the current official compiler from Parallax for the P2, PropTool is the current official compiler from Parallax for the P1. Both are windows programs, but also run on Linux if you have Wine or something alike that.
PropTool will be extended to support the P2 as soon as Chip will finalize the Spin2 language.
Pnut and PropTool compile Spin code into some bytecode which is then interpreted by a bytecode interpreter written in the native machine language.
The basic idea here is that the byte code is smaller then native PASM, so a Spin program compiled with Pnut/PropTool is smaller (in byte size/memory footprint) as compiled with FastSpin, but also slower.
Currently Chip is rewriting his compiler in Spin to be able to run the compiler on the P2 itself, so the language is not finalized yet, but Eric (@ersmith) is following everything Chip does and does a wonderful job there.
Then we have Catalina, a C compiler for P1 and P2 written by @RossH, completely independent of Spin, also compiling to native machine language. Not official Parallax.
And finally there is TAQOZ which is a FORTH running on the P2 and is in the ROM of the P2, there is also TACHION as a FORTH for the P1, both written by @"Peter Jakacki" not by Parallax.
There is also a (very old) version of GCC called PropGcc compiling C and C++ for the P1, but Parallax does not have the funds currently to port GCC to the P2.
So Eric did some other funny project and build a RISC V emulator for the P2, so you can use the standard GCC for RISC V to compile c and c++ for the P2.
So, sorry for confusing you even more...
Mike
It's probably not easy to call high level functions from an ISR, because there could be nasty conflicts with register usage (the compiler uses some fixed registers like muldiva and muldivb for some operations, and leaf functions (ones that don't call others) don't save any registers. So I don't think it's practical to use ISRs with the high level languages right now.
I appreciate all the effort for making the p2 such an amazing product (silicon AND compilers)
So only PNut uses the spin to bytecode at the moment. All other compilers directly use machine language?
(1) PNut, TAQOZ, micropython, and junkbasic use bytecodes of one sort or another
(2) fastspin, p2gcc, and Catalina generate native machine language
(3) riscvp2 generates RISC-V instructions which are then compiled to P2 instructions at run time (JIT)
(4) proplisp interprets its own internal data structures; I think FemtoBASIC does that too?
You would need to have the spin interpreter loaded and initialised, so you would have needed to call pasm from spin.
Don't forget that since spin is interpreted it will be much slower than pasm so it's not ideal.
Having said that, IIRC Chip said spin can run interrupt code, so it's very possible.
@Ahle2 is using fastspin, so no need for the spin2 interpreter -- fastspin compiles Spin and Spin2 to machine code directly.
In general calling back to Spin2 from PASM in fastspin can be accomplished most easily via a function pointer. If "myobj.foo" is a method, then "@myobj.foo" is a 32 bit pointer to two 32 bit values: the first is a pointer to the "myobj" object data, and the second is a pointer to the function to call. So you can do something like:
' call via function pointer currently in pb ' pb points to (object, method) pair wrlong objptr, ptra++ ' push current object pointer rdlong objptr, pb ' fetch new object pointer add pb, #4 rdlong pb, pb ' fetch function pointer calla pb ' call function sub ptra, #4 rdlong ptra, objptr ' restore object pointerThis won't always be safe in an ISR though because the code fastspin generates isn't re-entrant.#define STACK_SIZE (32 * 1024) ... uint8_t *workspace = _getsp() + STACK_SIZE;I got this error:Having said that, on P2 the stack pointer is just ptra, so it's easy enough to get the value using inline assembly. For example you could write your own version of getsp like:
unsigned char *mygetsp() { unsigned char *r; __asm { mov r, ptra } return r; }I think VirtualBox can also run Windows on Mac and it's free (but not quite as nice). I didn't know about Wine not working anymore...