Now have another one. Is the terminal used by spin2gui part of fastspin or is it part of the loader?
It's part of loadp2. The division of labor is:
- fastspin takes source code (Spin, PASM, BASIC, C) and turns it into a binary file that the P2 can execute
- loadp2 talks to the P2; it downloads the binary produced by fastspin and then (optionally) listens for serial communication
- spin2gui puts a GUI in front of those two
Because it looks like the terminal is just half-duplex, while receiving characters it does not send any back.
What exactly do you mean? Do you mean that while there are bits being transmitted by the P2 that the PC is not transmitting? It seems like this would be tricky to test with the built in terminal.
I'm pretty sure loadp2 just uses the operating system serial port I/O routines, which should be full duplex (the OS has some kind of buffer, if only one character in the UART hardware).
One other thing you got me with is changing the terminal baud rate from 2_000_000 to 230_400.
Sorry! I forgot to highlight that in the release notes. It's for compatibility with the Mac and with p2gcc.
"half-duplex" was used as a terminal mode that would be selected when the data device would not echo characters back to the terminal. Now it is referred to more appropriately as "echo on".
"half-duplex" was used as a terminal mode that would be selected when the data device would not echo characters back to the terminal. Now it is referred to more appropriately as "echo on".
"half-duplex" was used as a terminal mode that would be selected when the data device would not echo characters back to the terminal. Now it is referred to more appropriately as "echo on".
"half-duplex" was used as a terminal mode that would be selected when the data device would not echo characters back to the terminal. Now it is referred to more appropriately as "echo on".
That may be an informal usage of "half-duplex", but technically "half-duplex" means that the communication channel can transmit in only one direction at a time -- you can send, or you can receive, and you can do each in turn, but you can't do both simultaneously. @msrobots was testing a full duplex serial implementation for P2, so I'm sure he meant the technical definition. As I said, the loadp2 terminal uses the operating system's routines, which as far as I know should support full duplex -- but it'll be hard to actually make the loadp2 terminal do full duplex. Maybe cutting and pasting a bunch of text into the terminal while the P2 is sending would be a good test for that.
"half-duplex" was used as a terminal mode that would be selected when the data device would not echo characters back to the terminal. Now it is referred to more appropriately as "echo on".
@AntoineDoinel : I removed the call to _wfopen_s and just used fopen. This may cause some problems with file names that are encoded in UTF-8 which don't fit in the current Windows code page, but I don't think that's a big issue.
Now it works on the little EeePC too!
Eric, again thanks a lot for looking into this.
Yes, exactly, I am testing full duplex and the terminal does not accept any chars from the user to send to the P2 while the P2 is outputting data to the PC to display. Thus half-duplex.
Last night I spend some time to figure out how to use @Cluso99's con section to calculate the values for clkset() in fastspin.
I got stuck for some moment until I realized that you use OSC
Yes, exactly, I am testing full duplex and the terminal does not accept any chars from the user to send to the P2 while the P2 is outputting data to the PC to display. Thus half-duplex.
Hmmm... I see that the loadp2 code does wait for all characters to be emptied from the serial buffer before trying to read the keyboard. But I think that should happen pretty quickly, at least on a reasonably fast PC. Have you tried a lower baud rate? In principle it should be possible to do full-duplex, but I don't know the Windows serial code well enough to know what kind of timeout is the default.
Last night I spend some time to figure out how to use @Cluso99's con section to calculate the values for clkset() in fastspin.
I got stuck for some moment until I realized that you use OSC
what exacly is the difference there, what would be better and why?
I honestly don't know the difference -- I think I saw in the video thread that people were using OSC, so I used that, but I don't claim to be an expert. There still seems to be an ongoing discussion about which settings are best. Which is one reason I thought we should make clock settings explicit on P2, at least for now.
do you use the constants
_clkfreq = 160_000_000
_clkmode = $010c3f04
somewhere else in the code or would I be fine to use
clkset(_SETFREQ, _CLOCKFREQ)
instead of
clkset(_clkmode, _clkfreq)
Yes, you can use any names you like for the clkset(). Someday _clkfreq and _clkmode will be used for the default clock settings, but it'll always be possible to override them with an explicit clkset(). And of course you can define them any way you like.
@msrobots, I tried the following program using p2gcc, and it seems to work OK.
#include <stdio.h>
#include <propeller.h>
int val = '?';
int stack[100];
void serialin(void *parm)
{
while(1)
val = getch();
}
void main()
{
sleep(1);
cogstart(serialin, NULL, stack, sizeof(stack));
while (1)
{
putch(val);
if (val == '~')
sleep(5);
}
}
Cog 0 prints the value of "val" in a loop, and cog 1 saves the value it reads from the serial port into "val". I can type in characters, and I see the output echoing what I type in. I tried pasting text into the window, and that work also. I added the test for the "~" character so I can pause the output for 5 seconds.
@msrobots, I tried the following program using p2gcc, and it seems to work OK.
#include <stdio.h>
#include <propeller.h>
int val = '?';
int stack[100];
void serialin(void *parm)
{
while(1)
val = getch();
}
void main()
{
sleep(1);
cogstart(serialin, NULL, stack, sizeof(stack));
while (1)
{
putch(val);
if (val == '~')
sleep(5);
}
}
Cog 0 prints the value of "val" in a loop, and cog 1 saves the value it reads from the serial port into "val". I can type in characters, and I see the output echoing what I type in. I tried pasting text into the window, and that work also. I added the test for the "~" character so I can pause the output for 5 seconds.
I will post later today on my full-duplex thread, this is not a fastspin issue, so off topic. But basically my smart pin driver hammers the terminal with output as soon as it can output and the terminal gets no sleep(5) in between. Then it never sends a char back. Putting some waitx in the code did let the terminal finish the transmit and then it send back the user input. I am running some stress tests for the serial driver on other cogs, display the result (constantly) and wait for a key press to stop the test. And if I do not throttle/wait in between my outputs I never get a key press.
Yes, exactly, I am testing full duplex and the terminal does not accept any chars from the user to send to the P2 while the P2 is outputting data to the PC to display. Thus half-duplex.
Hmmm... I see that the loadp2 code does wait for all characters to be emptied from the serial buffer before trying to read the keyboard. But I think that should happen pretty quickly, at least on a reasonably fast PC. Have you tried a lower baud rate? In principle it should be possible to do full-duplex, but I don't know the Windows serial code well enough to know what kind of timeout is the default.
Last night I spend some time to figure out how to use @Cluso99's con section to calculate the values for clkset() in fastspin.
I got stuck for some moment until I realized that you use OSC
what exacly is the difference there, what would be better and why?
I honestly don't know the difference -- I think I saw in the video thread that people were using OSC, so I used that, but I don't claim to be an expert. There still seems to be an ongoing discussion about which settings are best. Which is one reason I thought we should make clock settings explicit on P2, at least for now.
do you use the constants
_clkfreq = 160_000_000
_clkmode = $010c3f04
somewhere else in the code or would I be fine to use
clkset(_SETFREQ, _CLOCKFREQ)
instead of
clkset(_clkmode, _clkfreq)
Yes, you can use any names you like for the clkset(). Someday _clkfreq and _clkmode will be used for the default clock settings, but it'll always be possible to override them with an explicit clkset(). And of course you can define them any way you like.
OK then that is it to calculate both values needed for clkset()
CON
_XTALFREQ = 20_000_000 ' crystal frequency
_XDIV = 4 '\ '\ crystal divider to give 5.0MHz
_XMUL = 64 '| 160MHz '| crystal / div * mul to give 320MHz
_XDIVP = 2 '/ '/ crystal / div * mul /divp to give 160MHz
_XOSC = %01 '15pF ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
_XSEL = %11 'XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms)
_XPPPP = ((_XDIVP>>1) + 15) & $F ' 1->15, 2->0, 4->1, 6->2...30->14
_clkfreq = _XTALFREQ / _XDIV * _XMUL / _XDIVP ' internal clock frequency
_clkmode = 1<<24 + (_XDIV-1)<<18 + (_XMUL-1)<<8 + _XPPPP<<4 + _XOSC<<2 ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_00 ' setup oscillator
_XOSC
This is a hardware option to match the oscillator or crystal used.
If it is a crystal, what loading capacitance is applied by the P2 (off, 15pF or 30pF).
If it is an oscillator, use %01=OSC. This also worked too for a crystal on the P2-ES board.
If you select the wrong capacitance for your crystal, it will most likely still work, just slightly off-frequency.
I will post later today on my full-duplex thread, this is not a fastspin issue, so off topic. But basically my smart pin driver hammers the terminal with output as soon as it can output and the terminal gets no sleep(5) in between. Then it never sends a char back. Putting some waitx in the code did let the terminal finish the transmit and then it send back the user input. I am running some stress tests for the serial driver on other cogs, display the result (constantly) and wait for a key press to stop the test. And if I do not throttle/wait in between my outputs I never get a key press.
The sleep(5) in my program only happens when it receives a "~" character. That's so I can freeze the screen for a few seconds to look at it. If I don't send a "~" then the program hammers the terminal with output similar to yours. However, I don't see a problem with receiving characters. One difference with my setup is that my loadp2 was built using Cygwin, and the one that comes with spin2gui is most likely built under MinGW. I'll try the MinGW version to see if that makes a difference.
EDIT: I tried the MinGW version of loadp2, and seem to work the same as the Cygwin version. I tried increasing the baud rate from 115200 to 1000000, and it worked OK until I pasted in some text. There terminal hung after that. It's may be an issue with the Windows serial driver at high baud rates.
what exacly is the difference there, what would be better and why?
That field sets the Xtal load capacitance, and below are the measured changes in ppm, from an ideal 20.000MHz, on a coolish board.
(A warmer board drops slightly in MHz.)
%CC XI status XO status XI/XO Z XI/XO caps Measures ppm change PLL
%00 ignored float Hi-Z OFF
%01 input 600-ohm drive 1M-ohm OFF -> 1000.1439Hz +144 ppm
%10 input 600-ohm drive 1M-ohm 15pF per pin -> 999.9933Hz -6.700 ppm
%11 input 600-ohm drive 1M-ohm 30pF per pin -> 999.9472Hz -53 ppm
All work, but the best value for the Xtal on the P2-Eval is 15pF, but even 0pF does still oscillate but with the highest error.
0pF would not usually be selected with a Xtal, unless you were testing frequency effects or margins.
You would select 0pF when AC-Coupling a clipped sine (VC) TXCO
There's a new spin2gui release: now with a Lisp interpreter as one of the samples (so in one package you get PASM, Spin, BASIC, C, and Lisp).
To run a lisp program, load up samples/proplisp/lisp.c and compile and run. You'll be presented with a ">" prompt. You can then enter something like:
(while #t (begin (pintoggle 58)(waitms 100)))
to blink pin 58. Press CTRL-B in the terminal to break out of the while loop. There's a bit of documentation in the samples/proplisp/README.md file.
Hello world is:
(print "hello, world" nl)
or even just
"hello, world"
The Lisp interpreter itself is nothing special; it's pretty slow and doesn't have a lot of features. Mainly it's useful because it's written in C and doesn't use much of the standard library, so it was a good platform for testing fastspin's C support and shaking out bugs (which it did a lot of).
There's a new spin2gui release: now with a Lisp interpreter as one of the samples (so in one package you get PASM, Spin, BASIC, C, and Lisp).
...The Lisp interpreter itself is nothing special; it's pretty slow and doesn't have a lot of features. Mainly it's useful because it's written in C and doesn't use much of the standard library, so it was a good platform for testing fastspin's C support and shaking out bugs (which it did a lot of).
Wow, even more impressive !
That means the C support must be moving along quite quickly.
How does it go now compiling the Blockly-generated C code ?
Wow, even more impressive !
That means the C support must be moving along quite quickly.
How does it go now compiling the Blockly-generated C code ?
To be honest, I've never used Blockly in any form -- it's not something that appeals to me personally, and I suspect that there won't be a lot of demand for it among early adopters of the P2. That said, eventually of course I'd like to make sure that fastspin can compile Blockly generated code. It just hasn't been a priority yet.
Wow, even more impressive !
That means the C support must be moving along quite quickly.
How does it go now compiling the Blockly-generated C code ?
To be honest, I've never used Blockly in any form -- it's not something that appeals to me personally, and I suspect that there won't be a lot of demand for it among early adopters of the P2. That said, eventually of course I'd like to make sure that fastspin can compile Blockly generated code. It just hasn't been a priority yet.
I think the Simple Libraries will have to be ported to fastspin before BlocklyProp output will compile.
ersmith,
The BlocklyProp generated code itself is quite simple, I bet your compiler would already handle that part. However, there are a couple of things that will be issues, one is that, like SimpleIDE, it handles all the linking of libraries and multiple c files based on what headers you include, and two, a bunch of the libraries used have spin modules with P1 pasm hooked in via the propgcc mechanism for that. It uses SimpleIDE and the Simple Libraries (Learn folders) to compile the C code generated by the blocks via it's cloud compiler setup.
So, in order to compile BlocklyProp generated code, we'd need all the Simple Libraries ported to P2, and either add in the auto-linking thing, or require manually adding in all the linking information for a given program. If you have the same builtin names as propgcc (I think you do), then a lot of the libraries will likely work as is, just need to sort out the ones that use Spin modules with P1 PASM.
BTW, fantastic work on this compiler/ide so far! I'm thinking we should just all get behind this effort and use it as the "official" one... I'm not sure why I should spend the time to update OpenSpin for P2, when this is already better than that would be.
BTW, fantastic work on this compiler/ide so far! I'm thinking we should just all get behind this effort and use it as the "official" one... I'm not sure why I should spend the time to update OpenSpin for P2, when this is already better than that would be.
I agree that fastspin could be the official Spin native compiler for P2 as well as the official C compiler. However, some people will still want a byte code compiler. At least that is what people here keep saying. If that is true then there is still a place for OpenSpin once Chip gets his Spin2 compiler working to use as a reference. I haven't heard much lately about Chip's compiler. Has he said anything about when it might be available?
Also, I think the new Target thing to compile is MicroPython (or maybe CircuitPython (Adafruit's variant of it)). It's written in C/C++ C99. I know Ken would like that since education seems to love Python now thanks to the BBC micro:bit and other things.
Also, I think the new Target thing to compile is MicroPython (or maybe CircuitPython (Adafruit's variant of it)). It's written in C/C++. I know Ken would like that since education seems to love Python now thanks to the BBC micro:bit and other things.
Hmmm... I don't think Eric intends to implement C++ in fastspin so I guess that means we need GCC after all. It's too bad that there might end up being two C compiler efforts needed. We have few enough tools resources as it is without having to spread them across two similar projects.
David,
Eric has said he intends for his compiler to have a subset of C++ stuff. Might be enough? I have not looked at the MicroPython/CircuitPython code at all, it may not use much C++ at all? I will have to take a look at it and see.
Edit: Just looked at their homepage, and it says MicroPython is written in C99. So I think we may be good.
David,
Eric has said he intends for his compiler to have a subset of C++ stuff. Might be enough? I have not looked at the MicroPython/CircuitPython code at all, it may not use much C++ at all? I will have to take a look at it and see.
Edit: Just looked at their homepage, and it says MicroPython is written in C99. So I think we may be good.
That's encouraging. We just need to check to see if Eric intends to support C99. I'm not sure what C standard he is currently following. In any case, I think fastspin is Parallax's best path to getting C and maybe some C++ for the P2 since Eric is already working on it and has C mostly done. The remainder of the work is implementing or porting the libraries.
.... Mainly it's useful because it's written in C and doesn't use much of the standard library, so it was a good platform for testing fastspin's C support and shaking out bugs (which it did a lot of).
Do you know which C version that Lisp interpreter required ? Maybe that is already a C99 test ?
The BlocklyProp generated code itself is quite simple, I bet your compiler would already handle that part. However, there are a couple of things that will be issues, one is that, like SimpleIDE, it handles all the linking of libraries and multiple c files based on what headers you include,
I think we should be able to handle that. Fastspin currently has a way to specify in a header file that a library file needs to be included, e.g. in time.h there are defines like:
which says that if an unresolved reference to "time" is found then we should load "libc/time/time.c", for "difftime" we load "libc/time/difftime.c", and so on. We still have to see how well this performs for large libraries, but for small ones it seems to work.
and two, a bunch of the libraries used have spin modules with P1 pasm hooked in via the propgcc mechanism for that. It uses SimpleIDE and the Simple Libraries (Learn folders) to compile the C code generated by the blocks via it's cloud compiler setup.
Well, compiling Spin modules with fastspin isn't a problem so if the original Spin code is still available we can use that directly. For example the C code for the Lisp interpreter uses SmartSerial.spin2 via:
BTW, fantastic work on this compiler/ide so far! I'm thinking we should just all get behind this effort and use it as the "official" one...
Thank you very much! It'd be great if some more people could start work on porting libraries to fastspin (and finding bugs in it ). I need to work on some "internals" documentation as well, but there hasn't been time yet .
I agree that fastspin could be the official Spin native compiler for P2 as well as the official C compiler. However, some people will still want a byte code compiler. At least that is what people here keep saying.
There's no reason in principle that fastspin couldn't generate bytecode. I didn't see any point in doing that for P1 (there was already a perfectly good bytecode compiler in the form of openspin), and haven't had time to look at it for P2 yet.
Doing a kind of CMM mode (where we use PASM instructions, but compressed) should be very easy in fastspin; again, I just haven't had time to get to it. That would just be a slight variation of the existing ASM backend. For real bytecode like the Spin2 interpreter we'd want a new backend. I've tried to make the compiler modular enough to make that possible (there are already backends to produce C code and ASM) but I'm sure there will be details that'll need working out.
Edit: Just looked at their homepage, and it says MicroPython is written in C99. So I think we may be good.
That's encouraging. We just need to check to see if Eric intends to support C99.
Yes, I do intend to support C99, and I think it's most of the way there. There are still some significant missing pieces:
- structure assignment / return (this may partially work, but it's definitely not done)
- nested scopes (e.g. "int n" inside an if() block is different from "int n" at the start of the function)
- bitfields
- static functions aren't working properly right now (if there are two static functions in different files with the same name they will conflict). That's more of a bug than missing feature, since the parser handles it and it's supposed to work
- standard library support
- long long support (not strictly required for C99, I think, but a lot of programs use it)
- true double support (right now "double" is treated the same as "float"; we may be able to get away with that in practice, lots of PropGCC programs were compiled with 32 bit doubls)
- many, many bugs I'm sure!
Comments
- fastspin takes source code (Spin, PASM, BASIC, C) and turns it into a binary file that the P2 can execute
- loadp2 talks to the P2; it downloads the binary produced by fastspin and then (optionally) listens for serial communication
- spin2gui puts a GUI in front of those two
What exactly do you mean? Do you mean that while there are bits being transmitted by the P2 that the PC is not transmitting? It seems like this would be tricky to test with the built in terminal.
I'm pretty sure loadp2 just uses the operating system serial port I/O routines, which should be full duplex (the OS has some kind of buffer, if only one character in the UART hardware).
Sorry! I forgot to highlight that in the release notes. It's for compatibility with the Mac and with p2gcc.
Thanks,
Eric
Wow, I'm old
LOL
Let's not get too far off-topic though, please
Sorry. I should be the LAST one to pull OT.
Now it works on the little EeePC too!
Eric, again thanks a lot for looking into this.
Last night I spend some time to figure out how to use @Cluso99's con section to calculate the values for clkset() in fastspin.
I got stuck for some moment until I realized that you use OSC
_XOSC = %01 '15pF ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
while @Cluso99 uses 15pF
_XOSC = %10 '15pF ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
what exacly is the difference there, what would be better and why?
I really like the calculation with constants @Cluso99 did here a copy for reference
using _XOSC = %01
_CLOCKFREQ gives the same value you use as _clkfreq
_SETFREQ gives the same value you use as _clkmode
do you use the constants
_clkfreq = 160_000_000
_clkmode = $010c3f04
somewhere else in the code or would I be fine to use
clkset(_SETFREQ, _CLOCKFREQ)
instead of
clkset(_clkmode, _clkfreq)
and be OK?
Enjoy!
Mike
I honestly don't know the difference -- I think I saw in the video thread that people were using OSC, so I used that, but I don't claim to be an expert. There still seems to be an ongoing discussion about which settings are best. Which is one reason I thought we should make clock settings explicit on P2, at least for now.
Yes, you can use any names you like for the clkset(). Someday _clkfreq and _clkmode will be used for the default clock settings, but it'll always be possible to override them with an explicit clkset(). And of course you can define them any way you like.
#include <stdio.h> #include <propeller.h> int val = '?'; int stack[100]; void serialin(void *parm) { while(1) val = getch(); } void main() { sleep(1); cogstart(serialin, NULL, stack, sizeof(stack)); while (1) { putch(val); if (val == '~') sleep(5); } }Cog 0 prints the value of "val" in a loop, and cog 1 saves the value it reads from the serial port into "val". I can type in characters, and I see the output echoing what I type in. I tried pasting text into the window, and that work also. I added the test for the "~" character so I can pause the output for 5 seconds.I will post later today on my full-duplex thread, this is not a fastspin issue, so off topic. But basically my smart pin driver hammers the terminal with output as soon as it can output and the terminal gets no sleep(5) in between. Then it never sends a char back. Putting some waitx in the code did let the terminal finish the transmit and then it send back the user input. I am running some stress tests for the serial driver on other cogs, display the result (constantly) and wait for a key press to stop the test. And if I do not throttle/wait in between my outputs I never get a key press.
Enjoy!
Mike
OK then that is it to calculate both values needed for clkset()
cool.
Mike
This is a hardware option to match the oscillator or crystal used.
If it is a crystal, what loading capacitance is applied by the P2 (off, 15pF or 30pF).
If it is an oscillator, use %01=OSC. This also worked too for a crystal on the P2-ES board.
If you select the wrong capacitance for your crystal, it will most likely still work, just slightly off-frequency.
EDIT: I tried the MinGW version of loadp2, and seem to work the same as the Cygwin version. I tried increasing the baud rate from 115200 to 1000000, and it worked OK until I pasted in some text. There terminal hung after that. It's may be an issue with the Windows serial driver at high baud rates.
That field sets the Xtal load capacitance, and below are the measured changes in ppm, from an ideal 20.000MHz, on a coolish board.
(A warmer board drops slightly in MHz.)
All work, but the best value for the Xtal on the P2-Eval is 15pF, but even 0pF does still oscillate but with the highest error.
0pF would not usually be selected with a Xtal, unless you were testing frequency effects or margins.
You would select 0pF when AC-Coupling a clipped sine (VC) TXCO
To run a lisp program, load up samples/proplisp/lisp.c and compile and run. You'll be presented with a ">" prompt. You can then enter something like: to blink pin 58. Press CTRL-B in the terminal to break out of the while loop. There's a bit of documentation in the samples/proplisp/README.md file.
Hello world is: or even just
The Lisp interpreter itself is nothing special; it's pretty slow and doesn't have a lot of features. Mainly it's useful because it's written in C and doesn't use much of the standard library, so it was a good platform for testing fastspin's C support and shaking out bugs (which it did a lot of).
Wow, even more impressive !
That means the C support must be moving along quite quickly.
How does it go now compiling the Blockly-generated C code ?
To be honest, I've never used Blockly in any form -- it's not something that appeals to me personally, and I suspect that there won't be a lot of demand for it among early adopters of the P2. That said, eventually of course I'd like to make sure that fastspin can compile Blockly generated code. It just hasn't been a priority yet.
The BlocklyProp generated code itself is quite simple, I bet your compiler would already handle that part. However, there are a couple of things that will be issues, one is that, like SimpleIDE, it handles all the linking of libraries and multiple c files based on what headers you include, and two, a bunch of the libraries used have spin modules with P1 pasm hooked in via the propgcc mechanism for that. It uses SimpleIDE and the Simple Libraries (Learn folders) to compile the C code generated by the blocks via it's cloud compiler setup.
So, in order to compile BlocklyProp generated code, we'd need all the Simple Libraries ported to P2, and either add in the auto-linking thing, or require manually adding in all the linking information for a given program. If you have the same builtin names as propgcc (I think you do), then a lot of the libraries will likely work as is, just need to sort out the ones that use Spin modules with P1 PASM.
BTW, fantastic work on this compiler/ide so far! I'm thinking we should just all get behind this effort and use it as the "official" one... I'm not sure why I should spend the time to update OpenSpin for P2, when this is already better than that would be.
Eric has said he intends for his compiler to have a subset of C++ stuff. Might be enough? I have not looked at the MicroPython/CircuitPython code at all, it may not use much C++ at all? I will have to take a look at it and see.
Edit: Just looked at their homepage, and it says MicroPython is written in C99. So I think we may be good.
Do you know which C version that Lisp interpreter required ? Maybe that is already a C99 test ?
time_t time(time_t *) _IMPL("libc/time/time.c"); double difftime(time_t time2, time_t time1) _IMPL("libc/time/difftime.c");which says that if an unresolved reference to "time" is found then we should load "libc/time/time.c", for "difftime" we load "libc/time/difftime.c", and so on. We still have to see how well this performs for large libraries, but for small ones it seems to work.Well, compiling Spin modules with fastspin isn't a problem
struct __using("PropSerial/SmartSerial.spin2") fds; ... fds.start(63, 62, 0, 23400);Thank you very much! It'd be great if some more people could start work on porting libraries to fastspin (and finding bugs in it
Thanks,
Eric
Doing a kind of CMM mode (where we use PASM instructions, but compressed) should be very easy in fastspin; again, I just haven't had time to get to it. That would just be a slight variation of the existing ASM backend. For real bytecode like the Spin2 interpreter we'd want a new backend. I've tried to make the compiler modular enough to make that possible (there are already backends to produce C code and ASM) but I'm sure there will be details that'll need working out.
- structure assignment / return (this may partially work, but it's definitely not done)
- nested scopes (e.g. "int n" inside an if() block is different from "int n" at the start of the function)
- bitfields
- static functions aren't working properly right now (if there are two static functions in different files with the same name they will conflict). That's more of a bug than missing feature, since the parser handles it and it's supposed to work
- standard library support
- long long support (not strictly required for C99, I think, but a lot of programs use it)
- true double support (right now "double" is treated the same as "float"; we may be able to get away with that in practice, lots of PropGCC programs were compiled with 32 bit doubls)
- many, many bugs I'm sure!