The BlocklyProp C code generator also generates calls to some Simple Libraries functions so those would have to be ported for it to work with any of the P2 C compiler solutions.
Those P1 Simple Libraries could use the same porting path that P1-asm to p2-asm uses, in the short term ?
The reasons I asked about ' BlocklyProp C " are
a) Parallax already have educational customers using this, and they are a significant customer base.
As soon as P2 becomes widely public, those customers will be asking about P2 versions
b) The level of C support needed to compile this generated code, is likely simpler/smaller than a full-release C, and so could prove a useful development stepping stone.
The BlocklyProp C code generator also generates calls to some Simple Libraries functions so those would have to be ported for it to work with any of the P2 C compiler solutions.
Those P1 Simple Libraries could use the same porting path that P1-asm to p2-asm uses, in the short term ?
The reasons I asked about ' BlocklyProp C " are
a) Parallax already have educational customers using this, and they are a significant customer base.
As soon as P2 becomes widely public, those customers will be asking about P2 versions
b) The level of C support needed to compile this generated code, is likely simpler/smaller than a full-release C, and so could prove a useful development stepping stone.
At one point Roy Eltham was working on porting Simple Libraries I think. I'm not sure how far he got but Parallax was quite interested.
I think that is viable, but the issues I see around CPU emulation are less to do with language, and more related to the usage details
I think this emulation path means listing files and map files show RISV V based memory maps, not native P2 memory maps.
I made it so they use the same memory map, that is RISC-V addresses and P2 addresses are the same. This make sharing data between the C code and PASM code running in other COGs trivial.
* How will Debug experience work, can users BREAK and STEP in their source code ?
* Can users in-line P2 Assembler, in this flow, like they can on fastspin-C ?
* Can users manage multiple COGs and shared memory, in a clean manner ?
Very good questions.
* I haven't implemented debug yet, as I haven't read the RISC-V debug spec. In theory it should be possible to debug the RISC-V code, as RISC-V code (that is, run the RISC-V version of gdb on it) but that's not something I've tried or implemented yet.
* No, the compiler is a RISC-V compiler (GCC or LLVM) so the inline assembly is RISC-V assembly language and the syntax is the usual GCC or LLVM inline assembly syntax. I have added new RISC-V instructions for things like smartpins and cog management, but those are only in the emulator and not in the toolchain. Fortunately there is a standard assembler directive (.insn) that lets you create custom instructions, but it would be even nicer to be able to use clean mnemonics. For example, the RISC-V equivalent of:
drvl #56
test a, #1 wc
drvc pin
is
; eventually the assembler should let you write this as
; drv zero, 56(zero)
; drv a, 0(pin)
; but that isn't implemented yet
.insn sb CUSTOM_0, 2, zero, 56(zero) ; write 0 to pin 56 + 0
.insn sb CUSTOM_0, 2, a, 0(pin) ; write a to pin 0 + pin
* Multiple COGs should be no problem. There's a COGINIT instruction, which loads compiled P2 assembly code into a COG, and COGID and COGSTOP are also available. In the RISC-V emulator repository there's a demo using my VGA object, converted via spin2cpp.
Couple comments.
C++ is only really "bloated" if you use the C++ libraries (and STL). It's basically the same issue as C, just to a larger degree since the C++ libs are more extensive.
Yes, there is some extra size that can be attributed to RTTI or Exception handling, but those are small and can be easily disabled (and often are).
BlocklyProp & Simple Libraries:
BlocklyProp relies on PropGCC to actually compile the C output. All of the Propeller specific stuff is in the Simple Libraries (which use PropGCC intrinsic stuff). It also relies on some SimpleIDE-like features where it handles all the linking automatically based on #include's. It doesn't require any special syntax for that, it just automatically links libraries based on which #include's are in the source file.
I started trying to get some of the Simple Libraries compiling with fastspin, and ersmith fixed some things I ran into, but then it got to the point that I need to modify every header file with a special decoration indicating the location of the source for each function in order for fastspin to compile it (since fastspin does not have linking) and I stalled there. There was talk of ersmith maybe adding another mechanism for this that would involve a separate file to contain this special linking like info, which I would prefer. Also, it's not a simple case of having the same decoration on every function in a header, since most of the simple libraries implementation is split up into separate c files for each function (but sometimes not), and the name of the files isn't always the exact name of the function(s). Anyway, I'm at the point that I want to write a script of some kind to process all the simple library files to create all these special declarations, but I'd rather have it spit out a sidecar file, than modify every header.
There was talk of ersmith maybe adding another mechanism for this that would involve a separate file to contain this special linking like info, which I would prefer. Also, it's not a simple case of having the same decoration on every function in a header, since most of the simple libraries implementation is split up into separate c files for each function (but sometimes not), and the name of the files isn't always the exact name of the function(s). Anyway, I'm at the point that I want to write a script of some kind to process all the simple library files to create all these special declarations, but I'd rather have it spit out a sidecar file, than modify every header.
Actually I realized that we don't need a special kind of separate file, it can just be a regular C file with the decorations. That is, we could preprocess the library files to put all the C function definitions in one .c file:
// libsimple_defs.c: automatically produced by some tool
// functions defined in file1.c
int func1(int x, ...) __fromfile("path/to/file1.c");
int func2(int) __fromfile("path/to/file1.c");
// functions defined in file2.c
int baz(char *str) __fromfile("path/to/file2.c");
// and so on...
Then either put a #include of that generated file in all the headers, or arrange for the generated file to be included in the build.
I hate the SimpleIDE behind the scenes magic, it means that you can't build the projects with other tools (like make and so on).
Doesn't that solution mean that everything you compile will have everything linked? We don't want that. We only want to link in the libs that are referenced in the c file(s) (via include).
The Simple Libraries is a collection of ~50 libraries, each of which is made up of one to dozens of c files with one header file that matches the library name. Your program might only use 1 or just a few of those 50 libraries.
So wouldn't we need one of your "defs" files per library?
I hate the SimpleIDE behind the scenes magic, also.
Doesn't that solution mean that everything you compile will have everything linked? We don't want that. We only want to link in the libs that are referenced in the c file(s) (via include).
No, declarations like:
int foo(int x) __fromfile("path/to/file.c");
are just declarations, they don't automatically force "path/to/file.c" to be included. But if a reference to function "foo" is made that can't be resolved, then fastspin will look at the __fromfile and include that.
The Simple Libraries is a collection of ~50 libraries, each of which is made up of one to dozens of c files with one header file that matches the library name. Your program might only use 1 or just a few of those 50 libraries.
So wouldn't we need one of your "defs" files per library?
I think we could get away with one defs file. Although if it gets very large and unwieldy, or if it's easier to integrate with SimpleIDE, then we could break them up (e.g. it might make sense to have one defs file per library).
We could make each PropGCC .a file into one of these defs files. Indeed it might make sense to (a) have a tool that automatically generates these, and (b) make fastspin accept ".a" as an alternate suffix for ".c", so the defs files could be named as "something.a" but really be parsed as if they were .c files. That would be a step towards normalizing the fastspin build environment.
Indeed, I see no particular reason to expect that a "truly" native C++ compiler will ever become available. p2gcc is pretty close, but it still targets another architecture (P1). And unless PropGCC gets updated it will continue to fall further and further behind of current C++ standards, which are changing rapidly.
Eric, I find that comment a bit depressing, especially coming from you. It does surprise me a bit that Parallax hasn't even begun to even develop a plan to implement a C/C++ compiler for the P2. However, I still believe that any minute now Parallax with come to the realization that they'll need development tools for the P2, and it would be beneficial to have a C++ compiler for it.
Well, I certainly could be mistaken, but I haven't myself gotten the impression that Parallax has thought much at all about P2 tools, beyond whatever Chip is writing. I hope I'm wrong. But until we do get some definite direction from Parallax, I think we should proceed under the assumption that we (the community) are on our own, and do whatever makes us happy. And perhaps that will also prove useful to Parallax, if they eventually decide they want C/C++ support; or perhaps not. But if we wait for them we could be waiting a very long time...
(I would be very happy to be corrected by anyone from Parallax!)
I think we could get away with one defs file. Although if it gets very large and unwieldy, or if it's easier to integrate with SimpleIDE, then we could break them up (e.g. it might make sense to have one defs file per library).
either approach would work, and sounds like both could be supported ?
We could make each PropGCC .a file into one of these defs files. Indeed it might make sense to
(a) have a tool that automatically generates these, and
(b) make fastspin accept ".a" as an alternate suffix for ".c", so the defs files could be named as "something.a" but really be parsed as if they were .c files.
That would be a step towards normalizing the fastspin build environment.
(b) sounds easy to do, and (a) has appeal, and would tend to create one file per library ?
Other compiler tools allow a format like
Link.exe @LinkDo.L
where the LinkDo.L replaces a long unwieldly command line, with usually one line per file / one line per option
fastspin may already support that ?
ersmith,
Ok, so we could just have one defs file for all of it. I'll attempt to make a script (python probably) that will generate a defs file from the Simple Libraries sources.
If I include the defs file in the "main" c file compiled by fastspin, will it work in the current version as you described?
Also, sorry if this is a dumb question, but can fastspin be passed multiple c files to compile together? I assume not, since it doesn't do linking. So any code you make spanning multiple files will need this defs stuff as well? Feels really non-standard and painful.
ersmith,
Ok, so we could just have one defs file for all of it. I'll attempt to make a script (python probably) that will generate a defs file from the Simple Libraries sources.
Great, thanks! A script like that will come in handy for many projects.
If I include the defs file in the "main" c file compiled by fastspin, will it work in the current version as you described?
Yes. Or you could pass it on the command line as a separate file. In fact fastspin is OK with having more than one file on the command line, it just puts them all into the same top level object. So the "library_defs.c" file can just be given on the command line like any other C file, although all it has in it are definitions. (That's why I eventually would like to have fastspin accept "library_defs.a", so it'll act more like a regular library file even though it is a C file with definitions in it.)
Yea, it definitely is. One of my least favorite features of the IDE as well. I'm glad it works for Parallax's customers though...
I had to work around it in PropWare, too, and here's my current solution: https://github.com/parallaxinc/PropWare/blob/develop/external_libs/ParseSimpleIDEMetaData.cmake
I take advantage of the fact that CMake is its own (less than ideal) scripting language and do the necessary magic to parse all of the .side files to determine where the headers are and compute the full list of source files. I then compile put all of the source files into a single static library. This works fine so long as you use GCC's -fdata-sections, -ffunction-sections, and -Wl,--gc-sections.
FastSpin has the ability to prune unused code, right? Might this solution work for you, too?
#!/usr/bin/python3
import os
import re
import sys
from typing import List
def parse_simpleide_project_files(file_paths: List[str]) -> None:
library_file_pattern = re.compile('^.*>-create_library.*$', re.RegexFlag.MULTILINE)
for project_filepath in file_paths:
with open(project_filepath, 'r') as f:
file_contents = f.read()
if library_file_pattern.search(file_contents) is not None:
library_root = os.path.dirname(project_filepath)
add_simple_sources(library_root, file_contents)
def add_simple_sources(root_dir: str, file_contents: str) -> None:
lines = [line.strip() for line in file_contents.split('\n') if line.strip()]
# Remove the first line, because SimpleIDE project files always ignore the first line when creating libraries
lines = lines[1:]
new_sources = []
compiler_flags = []
for line in lines:
# If the line doesn't start with a '>', then it's source code
if line.startswith('>'):
# Various compiler flags are declared via the project files, so let's parse those now...
if line.startswith('>optimize='):
# Optimization...
compiler_flags.append(line.split('=')[1])
elif line.startswith('>defs::'):
# Preprocessor definitions
compiler_flags += line.split('::')[1].split()
elif line.startswith('>-l') or line.startswith('>-create_library'):
# Skip linker lines, and obvious '-create_library' is not a GCC argument
pass
elif line.startswith('>-'):
# Add other miscellaneous flags
compiler_flags.append(line[1:])
elif not line.endswith('.h'):
# Remove the link symbol if it exists
file_name = line.split(' -> ')[0]
new_sources.append(os.path.join(root_dir, file_name))
for source in new_sources:
# Do something with the source file and its known compiler flags
# In CMake, I would use set_source_files_properties() to set compiler flags on specific source files
print('{}: {}'.format(source, ' '.join(compiler_flags)))
# Add all of those sources to a library
if '__main__' == __name__:
if 1 == len(sys.argv):
raise Exception('Expected a single argument and that argument should be the root of the Simple libraries '
'(such as "foo/bar/Learn/Simple Libraries")')
simple_root = sys.argv[1]
if not os.path.exists(simple_root) or not os.path.isdir(simple_root):
raise FileNotFoundError(2, 'Argument should be the root of the Simple libraries (such as '
'"foo/bar/Learn/Simple Libraries")', simple_root)
all_project_files = []
header_search_paths = []
for root, dirs, filenames in os.walk(simple_root):
for filename in filenames:
if filename.endswith('.side'):
all_project_files.append(os.path.join(root, filename))
elif filename.endswith('.h'):
header_search_paths.append(root)
# Remove duplicate header search paths
header_search_paths = list(set(header_search_paths))
parse_simpleide_project_files(all_project_files)
While doing this I was reminded of one of the pain points: some of the code in Simple MUST be compiled with different flags. The only concrete example of this that I've noticed are dht22.c and wavplayer.c which must be compiled as -O2 instead of -Os.
Sorry to jump in in the middle of this Simple Libraries discussion but I wonder if it is even necessary to come up with a way of using SimpleIDE with the new tools. Didn't Ken Gracey say a while back that they wanted to move away from a proprietary IDE? Maybe it's good enough to figure out how to build the Simple Libraries outside of SimpleIDE and not worry about find a way to continue to use SimpleIDE itself.
David,
I just want the Simple Libraries ported to work with fastspin/P2. It will allow BlocklyProp generated code to be compiled for P2, and also allow all the parallax tutorial code for C (on the learn site) to be compiled for P2.
They contain a lot of useful code for talking to sensors, common protocols, servos, etc.
I personally really hate the SimpleIDE IDE part. It's got some really bad issues for anyone that does C coding all the time. Like just trying to type code in and it does stuff that messes up your code Stuff that will never get fixed, some intentionally so... What I'd like to see is an extension for Visual Studio or Visual Studio Code, both of those IDEs are pretty great and free (or essentially free). I use both of them daily for work. I even use Visual Studio to edit my code that I end up compiling with SimpleIDE, because that's less painful than trying to use SimpleIDE to type any code.
David,
I just want the Simple Libraries ported to work with fastspin/P2. It will allow BlocklyProp generated code to be compiled for P2, and also allow all the parallax tutorial code for C (on the learn site) to be compiled for P2.
They contain a lot of useful code for talking to sensors, common protocols, servos, etc.
Yup. That would be really useful.
I personally really hate the SimpleIDE IDE part. It's got some really bad issues for anyone that does C coding all the time. Like just trying to type code in and it does stuff that messes up your code Stuff that will never get fixed, some intentionally so... What I'd like to see is an extension for Visual Studio or Visual Studio Code, both of those IDEs are pretty great and free (or essentially free). I use both of them daily for work. I even use Visual Studio to edit my code that I end up compiling with SimpleIDE, because that's less painful than trying to use SimpleIDE to type any code.
David,
I just want the Simple Libraries ported to work with fastspin/P2. It will allow BlocklyProp generated code to be compiled for P2, and also allow all the parallax tutorial code for C (on the learn site) to be compiled for P2.
They contain a lot of useful code for talking to sensors, common protocols, servos, etc.
I personally really hate the SimpleIDE IDE part. It's got some really bad issues for anyone that does C coding all the time. Like just trying to type code in and it does stuff that messes up your code Stuff that will never get fixed, some intentionally so... What I'd like to see is an extension for Visual Studio or Visual Studio Code, both of those IDEs are pretty great and free (or essentially free). I use both of them daily for work. I even use Visual Studio to edit my code that I end up compiling with SimpleIDE, because that's less painful than trying to use SimpleIDE to type any code.
Roy,
I use PropTool to edit both my P2 and P2 source files. I still call my P2 programs xxx.spin to keep the color coding. I do like some of the editing features.
If i were to change editors i would like to use NotePad++ but its only windoze
Cluso99,
I never really liked the colors in PropTool. I prefer a more traditional color syntax highlighting. I do like Proptool for being simple and reliable for spin/pasm, but wish it had openspin under the covers to gain the added features.
I love notepad++ also (use it a lot also), but the syntax highlighting doesn't fit Spin/PASM very well. You really need custom specific stuff to make syntax highlighting of Spin and PASM work properly.
You should really give Visual Studio Code a shot, it allows you to "open a folder" as a kind of project. Which kind of feels similar to Proptool. It's packed with a ton of other really nice stuff too, and has lots of extensions. We just need a Spin/PASM extension for it.
Visual Studio and Visual Studio Code use something called Language Server and this thing is astonishingly used by other editors too.
I looked into it briefly because I do use VS since decades and really like it.
But all examples are written in C and -hmm- I do not speak C.
As far as I could follow the Language Server provides parsing, code completion and other stuff.
Building one for Spin/PASM would be great, C/C++ is already supported by VS (even COBOL).
Cluso99,
I never really liked the colors in PropTool. I prefer a more traditional color syntax highlighting. I do like Proptool for being simple and reliable for spin/pasm, but wish it had openspin under the covers to gain the added features.
I love notepad++ also (use it a lot also), but the syntax highlighting doesn't fit Spin/PASM very well. You really need custom specific stuff to make syntax highlighting of Spin and PASM work properly.
You should really give Visual Studio Code a shot, it allows you to "open a folder" as a kind of project. Which kind of feels similar to Proptool. It's packed with a ton of other really nice stuff too, and has lots of extensions. We just need a Spin/PASM extension for it.
I don’t mind PropTools colors. It’s nice to know you are in DAT vs Spin - the other spaces not too significant.
Of course you can edit with PropTool and compile with OpenSpin (or pnut etc on P2).
I like some of the editing features like copying/pasting a block of code/text - more like a window by choosing a start x,y and end x,y. Not sure what its called. I believe NotePad++ is capable of this but I’ve never investigated it.
Never really looked at VS. Maybe when i get some extra time.
I use NotePad++ quite a bit and have written some python scripts to process some web page html files each week for work.
I believe the colored block style of Prop Tool is even more useful for P2.
We now have cogexec ,lutexec and hubexec.
Being able to easily distinguish between the three would be useful.
Cluso99,
Yeah, notepad++ has block copy, so does VS and VS Code. Theirs are even better. In VS you can do things like copy a word, then select a block column and paste and it will fill the column with the word. You can block column insert too.
Coloring the BG is not needed to id areas.... I'd rather have minimap style vertical scroll bar. check it out in VS Code or VS.
Cluso99,
Yeah, notepad++ has block copy, so does VS and VS Code. Theirs are even better.
In VS you can do things like copy a word, then select a block column and paste and it will fill the column with the word.
You can block column insert too....
I believe the colored block style of Prop Tool is even more useful for P2.
We now have cogexec ,lutexec and hubexec.
Being able to easily distinguish between the three would be useful.
jmg,
No, notepad++ can't do everything I described about block select/copy/paste. It does a bunch of it.
Another thing you can do in VS, is block select a line (a column without actually selecting a character width), and then type and it will insert whatever you type on all the lines (inserting at the selection point).
VS has a lot of other very nice editing features geared around coding. VS Code has most of them, but not all.
They are all free, so you can download and try out each.
..
Another thing you can do in VS, is block select a line (a column without actually selecting a character width), and then type and it will insert whatever you type on all the lines (inserting at the selection point).
Ok, maybe notepad++ added some things that I wasn't aware of.
I do recall notepad++ not having everything the VS had related to column select/copy/paste/typing, but can't remember what and it may not be true anymore. I have been using all of them for many years now (VS Code a little less so).
Comments
Those P1 Simple Libraries could use the same porting path that P1-asm to p2-asm uses, in the short term ?
The reasons I asked about ' BlocklyProp C " are
a) Parallax already have educational customers using this, and they are a significant customer base.
As soon as P2 becomes widely public, those customers will be asking about P2 versions
b) The level of C support needed to compile this generated code, is likely simpler/smaller than a full-release C, and so could prove a useful development stepping stone.
Sorry, typo. Try https://github.com/totalspectrum/riscvemu.
Very good questions.
* I haven't implemented debug yet, as I haven't read the RISC-V debug spec. In theory it should be possible to debug the RISC-V code, as RISC-V code (that is, run the RISC-V version of gdb on it) but that's not something I've tried or implemented yet.
* No, the compiler is a RISC-V compiler (GCC or LLVM) so the inline assembly is RISC-V assembly language and the syntax is the usual GCC or LLVM inline assembly syntax. I have added new RISC-V instructions for things like smartpins and cog management, but those are only in the emulator and not in the toolchain. Fortunately there is a standard assembler directive (.insn) that lets you create custom instructions, but it would be even nicer to be able to use clean mnemonics. For example, the RISC-V equivalent of: is
* Multiple COGs should be no problem. There's a COGINIT instruction, which loads compiled P2 assembly code into a COG, and COGID and COGSTOP are also available. In the RISC-V emulator repository there's a demo using my VGA object, converted via spin2cpp.
C++ is only really "bloated" if you use the C++ libraries (and STL). It's basically the same issue as C, just to a larger degree since the C++ libs are more extensive.
Yes, there is some extra size that can be attributed to RTTI or Exception handling, but those are small and can be easily disabled (and often are).
BlocklyProp & Simple Libraries:
BlocklyProp relies on PropGCC to actually compile the C output. All of the Propeller specific stuff is in the Simple Libraries (which use PropGCC intrinsic stuff). It also relies on some SimpleIDE-like features where it handles all the linking automatically based on #include's. It doesn't require any special syntax for that, it just automatically links libraries based on which #include's are in the source file.
I started trying to get some of the Simple Libraries compiling with fastspin, and ersmith fixed some things I ran into, but then it got to the point that I need to modify every header file with a special decoration indicating the location of the source for each function in order for fastspin to compile it (since fastspin does not have linking) and I stalled there. There was talk of ersmith maybe adding another mechanism for this that would involve a separate file to contain this special linking like info, which I would prefer. Also, it's not a simple case of having the same decoration on every function in a header, since most of the simple libraries implementation is split up into separate c files for each function (but sometimes not), and the name of the files isn't always the exact name of the function(s). Anyway, I'm at the point that I want to write a script of some kind to process all the simple library files to create all these special declarations, but I'd rather have it spit out a sidecar file, than modify every header.
Actually I realized that we don't need a special kind of separate file, it can just be a regular C file with the decorations. That is, we could preprocess the library files to put all the C function definitions in one .c file:
// libsimple_defs.c: automatically produced by some tool // functions defined in file1.c int func1(int x, ...) __fromfile("path/to/file1.c"); int func2(int) __fromfile("path/to/file1.c"); // functions defined in file2.c int baz(char *str) __fromfile("path/to/file2.c"); // and so on...Then either put a #include of that generated file in all the headers, or arrange for the generated file to be included in the build.
I hate the SimpleIDE behind the scenes magic, it means that you can't build the projects with other tools (like make and so on).
The Simple Libraries is a collection of ~50 libraries, each of which is made up of one to dozens of c files with one header file that matches the library name. Your program might only use 1 or just a few of those 50 libraries.
So wouldn't we need one of your "defs" files per library?
I hate the SimpleIDE behind the scenes magic, also.
int foo(int x) __fromfile("path/to/file.c");are just declarations, they don't automatically force "path/to/file.c" to be included. But if a reference to function "foo" is made that can't be resolved, then fastspin will look at the __fromfile and include that.I think we could get away with one defs file. Although if it gets very large and unwieldy, or if it's easier to integrate with SimpleIDE, then we could break them up (e.g. it might make sense to have one defs file per library).
We could make each PropGCC .a file into one of these defs files. Indeed it might make sense to (a) have a tool that automatically generates these, and (b) make fastspin accept ".a" as an alternate suffix for ".c", so the defs files could be named as "something.a" but really be parsed as if they were .c files. That would be a step towards normalizing the fastspin build environment.
Well, I certainly could be mistaken, but I haven't myself gotten the impression that Parallax has thought much at all about P2 tools, beyond whatever Chip is writing. I hope I'm wrong. But until we do get some definite direction from Parallax, I think we should proceed under the assumption that we (the community) are on our own, and do whatever makes us happy. And perhaps that will also prove useful to Parallax, if they eventually decide they want C/C++ support; or perhaps not. But if we wait for them we could be waiting a very long time...
(I would be very happy to be corrected by anyone from Parallax!)
Eric
(b) sounds easy to do, and (a) has appeal, and would tend to create one file per library ?
Other compiler tools allow a format like
Link.exe @LinkDo.L
where the LinkDo.L replaces a long unwieldly command line, with usually one line per file / one line per option
fastspin may already support that ?
Ok, so we could just have one defs file for all of it. I'll attempt to make a script (python probably) that will generate a defs file from the Simple Libraries sources.
If I include the defs file in the "main" c file compiled by fastspin, will it work in the current version as you described?
Also, sorry if this is a dumb question, but can fastspin be passed multiple c files to compile together? I assume not, since it doesn't do linking. So any code you make spanning multiple files will need this defs stuff as well? Feels really non-standard and painful.
Great, thanks! A script like that will come in handy for many projects.
Yes. Or you could pass it on the command line as a separate file. In fact fastspin is OK with having more than one file on the command line, it just puts them all into the same top level object. So the "library_defs.c" file can just be given on the command line like any other C file, although all it has in it are definitions. (That's why I eventually would like to have fastspin accept "library_defs.a", so it'll act more like a regular library file even though it is a C file with definitions in it.)
Yea, it definitely is. One of my least favorite features of the IDE as well. I'm glad it works for Parallax's customers though...
I had to work around it in PropWare, too, and here's my current solution: https://github.com/parallaxinc/PropWare/blob/develop/external_libs/ParseSimpleIDEMetaData.cmake
I take advantage of the fact that CMake is its own (less than ideal) scripting language and do the necessary magic to parse all of the .side files to determine where the headers are and compute the full list of source files. I then compile put all of the source files into a single static library. This works fine so long as you use GCC's -fdata-sections, -ffunction-sections, and -Wl,--gc-sections.
FastSpin has the ability to prune unused code, right? Might this solution work for you, too?
#!/usr/bin/python3 import os import re import sys from typing import List def parse_simpleide_project_files(file_paths: List[str]) -> None: library_file_pattern = re.compile('^.*>-create_library.*$', re.RegexFlag.MULTILINE) for project_filepath in file_paths: with open(project_filepath, 'r') as f: file_contents = f.read() if library_file_pattern.search(file_contents) is not None: library_root = os.path.dirname(project_filepath) add_simple_sources(library_root, file_contents) def add_simple_sources(root_dir: str, file_contents: str) -> None: lines = [line.strip() for line in file_contents.split('\n') if line.strip()] # Remove the first line, because SimpleIDE project files always ignore the first line when creating libraries lines = lines[1:] new_sources = [] compiler_flags = [] for line in lines: # If the line doesn't start with a '>', then it's source code if line.startswith('>'): # Various compiler flags are declared via the project files, so let's parse those now... if line.startswith('>optimize='): # Optimization... compiler_flags.append(line.split('=')[1]) elif line.startswith('>defs::'): # Preprocessor definitions compiler_flags += line.split('::')[1].split() elif line.startswith('>-l') or line.startswith('>-create_library'): # Skip linker lines, and obvious '-create_library' is not a GCC argument pass elif line.startswith('>-'): # Add other miscellaneous flags compiler_flags.append(line[1:]) elif not line.endswith('.h'): # Remove the link symbol if it exists file_name = line.split(' -> ')[0] new_sources.append(os.path.join(root_dir, file_name)) for source in new_sources: # Do something with the source file and its known compiler flags # In CMake, I would use set_source_files_properties() to set compiler flags on specific source files print('{}: {}'.format(source, ' '.join(compiler_flags))) # Add all of those sources to a library if '__main__' == __name__: if 1 == len(sys.argv): raise Exception('Expected a single argument and that argument should be the root of the Simple libraries ' '(such as "foo/bar/Learn/Simple Libraries")') simple_root = sys.argv[1] if not os.path.exists(simple_root) or not os.path.isdir(simple_root): raise FileNotFoundError(2, 'Argument should be the root of the Simple libraries (such as ' '"foo/bar/Learn/Simple Libraries")', simple_root) all_project_files = [] header_search_paths = [] for root, dirs, filenames in os.walk(simple_root): for filename in filenames: if filename.endswith('.side'): all_project_files.append(os.path.join(root, filename)) elif filename.endswith('.h'): header_search_paths.append(root) # Remove duplicate header search paths header_search_paths = list(set(header_search_paths)) parse_simpleide_project_files(all_project_files)While doing this I was reminded of one of the pain points: some of the code in Simple MUST be compiled with different flags. The only concrete example of this that I've noticed are dht22.c and wavplayer.c which must be compiled as -O2 instead of -Os.
The script above produces the following output:
That whole -O2 vs -Os thing is because of the performance differences on P1 for those, most likely.
I just want the Simple Libraries ported to work with fastspin/P2. It will allow BlocklyProp generated code to be compiled for P2, and also allow all the parallax tutorial code for C (on the learn site) to be compiled for P2.
They contain a lot of useful code for talking to sensors, common protocols, servos, etc.
I personally really hate the SimpleIDE IDE part. It's got some really bad issues for anyone that does C coding all the time. Like just trying to type code in and it does stuff that messes up your code Stuff that will never get fixed, some intentionally so... What I'd like to see is an extension for Visual Studio or Visual Studio Code, both of those IDEs are pretty great and free (or essentially free). I use both of them daily for work. I even use Visual Studio to edit my code that I end up compiling with SimpleIDE, because that's less painful than trying to use SimpleIDE to type any code.
Roy,
I use PropTool to edit both my P2 and P2 source files. I still call my P2 programs xxx.spin to keep the color coding. I do like some of the editing features.
If i were to change editors i would like to use NotePad++ but its only windoze
I never really liked the colors in PropTool. I prefer a more traditional color syntax highlighting. I do like Proptool for being simple and reliable for spin/pasm, but wish it had openspin under the covers to gain the added features.
I love notepad++ also (use it a lot also), but the syntax highlighting doesn't fit Spin/PASM very well. You really need custom specific stuff to make syntax highlighting of Spin and PASM work properly.
You should really give Visual Studio Code a shot, it allows you to "open a folder" as a kind of project. Which kind of feels similar to Proptool. It's packed with a ton of other really nice stuff too, and has lots of extensions. We just need a Spin/PASM extension for it.
I looked into it briefly because I do use VS since decades and really like it.
But all examples are written in C and -hmm- I do not speak C.
As far as I could follow the Language Server provides parsing, code completion and other stuff.
Building one for Spin/PASM would be great, C/C++ is already supported by VS (even COBOL).
Enjoy!
Mike
I don’t mind PropTools colors. It’s nice to know you are in DAT vs Spin - the other spaces not too significant.
Of course you can edit with PropTool and compile with OpenSpin (or pnut etc on P2).
I like some of the editing features like copying/pasting a block of code/text - more like a window by choosing a start x,y and end x,y. Not sure what its called. I believe NotePad++ is capable of this but I’ve never investigated it.
Never really looked at VS. Maybe when i get some extra time.
I use NotePad++ quite a bit and have written some python scripts to process some web page html files each week for work.
We now have cogexec ,lutexec and hubexec.
Being able to easily distinguish between the three would be useful.
Yeah, notepad++ has block copy, so does VS and VS Code. Theirs are even better. In VS you can do things like copy a word, then select a block column and paste and it will fill the column with the word. You can block column insert too.
Coloring the BG is not needed to id areas.... I'd rather have minimap style vertical scroll bar. check it out in VS Code or VS.
Seconded
No, notepad++ can't do everything I described about block select/copy/paste. It does a bunch of it.
Another thing you can do in VS, is block select a line (a column without actually selecting a character width), and then type and it will insert whatever you type on all the lines (inserting at the selection point).
VS has a lot of other very nice editing features geared around coding. VS Code has most of them, but not all.
They are all free, so you can download and try out each.
You mean like this (typed once, in column mode) ?
NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattoo NotePadDoesthattooI do recall notepad++ not having everything the VS had related to column select/copy/paste/typing, but can't remember what and it may not be true anymore. I have been using all of them for many years now (VS Code a little less so).
Took a look at VSC keyboard commands. Looks good and cross platform, open and MIT.
Should make a good base for a P2 editor
So thanks for giving me the heads up.
Now I’ll have to search for a scripting plugin - do you know if one exists?