Thanks for the debugging suggestions. I'll certainly keep those in mind going forward. My initial focus is on getting the language compilers for Spin, BASIC, and C done, and then adding more features after that.
Speaking of which, it feels like the BASIC language is pretty much "done", except for adding libraries. Have I missed any features in BASIC that anyone would use?
It looks like all the required source files have to be in the same folder.
Look for FastSpin's "-I" or "-L" option.
$ fastspin -O2 -L /opt/parallax.spin.src/spin mandelbrot-fixed16-vga-512x384x1.bas
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2018 Total Spectrum Software Inc.
Version 3.9.10-beta-6f57b5b Compiled on: Nov 10 2018
mandelbrot-fixed16-vga-512x384x1.bas
|-VGA_512x384_Bitmap.spin
mandelbrot-fixed16-vga-512x384x1.pasm
Done.
Program size is 26640 bytes
I think I just noticed fastspin just exit when code has a problem...
I was comparing output from bad code between different compilers...
Anyway, I put a "t" at the end of this code and fastspin just exits without any error messages:
it does work from command line...
Not sure what's going on... When I pipe the output to a file, I don't get the error in the output file...
But, I do get error message on command line...
C:\Users\Ray>cmd.exe /C ""D:\Propeller\Code\SpinEdit\Debug\fastspin.exe" -L "C:\Program Files (x86)\Parallax Inc\Propeller Tool v1.3.2\Library" "D:\Propeller\Code\SpinEdit\temp\Test1.spin" > "D:\Propeller\Code\SpinEdit\Debug\FastSpin.out""
D:\Propeller\Code\SpinEdit\temp\Test1.spin(18) error: Unknown symbol T
I think I just noticed fastspin just exit when code has a problem...
Well no, not in general. Normally it prints an error message. As you noticed later it does print an error message, but it's to the standard error output rather than the regular output.
Not sure what's going on... When I pipe the output to a file, I don't get the error in the output file...
But, I do get error message on command line...
C:\Users\Ray>cmd.exe /C ""D:\Propeller\Code\SpinEdit\Debug\fastspin.exe" -L "C:\Program Files (x86)\Parallax Inc\Propeller Tool v1.3.2\Library" "D:\Propeller\Code\SpinEdit\temp\Test1.spin" > "D:\Propeller\Code\SpinEdit\Debug\FastSpin.out""
D:\Propeller\Code\SpinEdit\temp\Test1.spin(18) error: Unknown symbol T
There are two different output streams in Windows: stdout (standard output) and stderr (standard error messages). The > redirection symbol only redirects stdout. To redirect stderr as well you have to use something like:
The "2>&1" says to redirect stderr (handle 2) the same was as stdout (handle 1). The same syntax is used in Linux and the Mac too.
I see that openspin outputs everything to stdout. I guess I understand why, but having error messages go to stderr is more usual, and many other compilers (like gcc) do it that way.
I think I just noticed that a quote character, when not the first character on a line, also indicates a comment. Is this right?
It doesn't give an error, but not sure if it is just being ignored or not...
A single quote character (') starts a comment, just like in Spin. It can be anywhere on the line, and goes to the end of the line.
There is a way to do multi-line comments (they start with /' and ends with '/, kind of like C comments but with quote instead of *. I think this is kind of ugly, so I don't use them myself, but FreeBasic has them and I did want some way to do multi-line comments in BASIC.
Yeah, I haven't come up with a good name for the whole suite of programs. "fastspin" is obviously outdated now that it can handle BASIC and (part of) C. I guess "fastspin/fastbasic/fastc" are reasonable names, unless somebody can think of something better .
Yeah, I haven't come up with a good name for the whole suite of programs. "fastspin" is obviously outdated now that it can handle BASIC and (part of) C. I guess "fastspin/fastbasic/fastc" are reasonable names, unless somebody can think of something better .
Well, "fastc" might actually be an inaccurate name if we end up getting GCC or LLVM for P2 as they will likely be faster.
Yeah, I haven't come up with a good name for the whole suite of programs. "fastspin" is obviously outdated now that it can handle BASIC and (part of) C. I guess "fastspin/fastbasic/fastc" are reasonable names, unless somebody can think of something better .
Prop Fast Suite?
Propfast Suite?
Propeller Fast Suite? (need to get permission from Parallax on the trademark).
Yeah, I haven't come up with a good name for the whole suite of programs. "fastspin" is obviously outdated now that it can handle BASIC and (part of) C. I guess "fastspin/fastbasic/fastc" are reasonable names, unless somebody can think of something better .
Well, "fastc" might actually be an inaccurate name if we end up getting GCC or LLVM for P2 as they will likely be faster.
That will depend on the benchmark, I think . For some things fastspin will produce better code than PropGCC. For other things PropGCC will be better.
Yeah, I haven't come up with a good name for the whole suite of programs. "fastspin" is obviously outdated now that it can handle BASIC and (part of) C. I guess "fastspin/fastbasic/fastc" are reasonable names, unless somebody can think of something better .
Well, "fastc" might actually be an inaccurate name if we end up getting GCC or LLVM for P2 as they will likely be faster.
That will depend on the benchmark, I think . For some things fastspin will produce better code than PropGCC. For other things PropGCC will be better.
In that case, why not just forget GCC or LLVM and just go with fastspin/c? I suppose someone will want C++ though.
How about "flexspin", "flexbasic", and "flexc"? The idea is that the compiler is pretty flexible, accepting PASM, Spin, BASIC, and C as input and producing P1 asm, P2 asm, or C/C++ as output. I'd call the overall collection "flex", but that's a widely used tool in Unix. Maybe "flexprop"?
I've created a new release of spin2gui (1.2.3) and fastspin (3.9.10). I had expected big change by now, but those are still pending, so this is another bugfix/maintainance release from the Spin and BASIC sides (the C support does have a lot of new features, including typedef and a __builtin_printf function, but it's still very much a work in progress).
I'll probably hold off on the name change until after the new C preprocessor and case-insensitive symbol support is in, and we can run some significant Propeller C programs.
Speaking of C support, any suggestions on how C code should import objects from other languages?
In Spin we do:
OBJ
ser: "SimpleSerial.spin" ' a Spin object
math: "math.bas" ' a BASIC object
foo: "foo.c" ' a C object
and in BASIC we do:
dim ser as class using "SimpleSerial.spin" ' a Spin object
dim math as class using "math.bas" ' a BASIC object
dim foo as class using "foo.c" ' a C object
C doesn't have an object mechanism, so this will (obviously) be an extension. Some options:
- use a #pragma. This is compatible with the C standard, but possibly awkward
- use a string after extern. I think this would be a compatible extension to C++
- come up with a new keyword
What you are suggesting sounds reasonable, but I can't help wondering if there is a reason for not using "obj" or "object" as the key word for all three cases. It would at least be more consistent to do so.
I didn't use "obj" or "object" in all cases because that's not a reserved word in all the languages. We could define a new keyword like "_Obj" for C (it would have to start with an underscore to avoid conflicts with variables in existing programs), so that is an option. But overall I was trying to do this extension while keeping the "feel" of each language. Unfortunately they all have very different ways of declaring variables. If anything Spin is the odd man out, since it has a completely different way of declaring objects from other variables.
@Rayman:
Using "#include" is an interesting idea. At first glance it's intuitively obvious. Unfortunately it also has some problems -- normally "#include" means to literally insert the text of the file being included into this point in the file. We could change that for files whose name ends in .spin or .bas, but for .c files there would be a conflict -- are you including the .c as an object, or just putting the text in-line? There's existing code that does the latter already.
I also worry that it could lead beginners into a common trap where they think of #include as doing more than it does. I've already seen that in questions about PropGCC, where they seem to think of #include as arranging for everything needed for linking, where in fact (in standard C at least) it's just a plain text substitution.
C doesn't have an object mechanism, so this will (obviously) be an extension. Some options:
- use a #pragma. This is compatible with the C standard, but possibly awkward
- use a string after extern. I think this would be a compatible extension to C++
- come up with a new keyword
I kind of like the extern idea, like:
extern "SimpleSerial.spin" ser;
or even:
struct extern "SimpleSerial.spin" ser;
What do you think?
Will this ultimately have a linker ? If so, any plan should be linker compatible ?
With a linker, a header file can declare names, and then the linked .OBJ file can come from any language source at all.
Comments
Speaking of which, it feels like the BASIC language is pretty much "done", except for adding libraries. Have I missed any features in BASIC that anyone would use?
The Prop tool has a library folder that it also searches for source.
Maybe this is fine as is. I guess in C++, I keep everything in one folder (except the build output goes into a different folder).
I was comparing output from bad code between different compilers...
Anyway, I put a "t" at the end of this code and fastspin just exits without any error messages:
it does work from command line...
Not sure what's going on... When I pipe the output to a file, I don't get the error in the output file...
But, I do get error message on command line...
There are two different output streams in Windows: stdout (standard output) and stderr (standard error messages). The > redirection symbol only redirects stdout. To redirect stderr as well you have to use something like:
The "2>&1" says to redirect stderr (handle 2) the same was as stdout (handle 1). The same syntax is used in Linux and the Mac too.
I see that openspin outputs everything to stdout. I guess I understand why, but having error messages go to stderr is more usual, and many other compilers (like gcc) do it that way.
OpenSpin and bstc and propellent don't act this way, but I'm glad it's an easy fix.
2>&1 this one is cool. I always redirected 2> into a second file. Never heard about &1.
Thanks,
Mike
It doesn't give an error, but not sure if it is just being ignored or not...
A single quote character (') starts a comment, just like in Spin. It can be anywhere on the line, and goes to the end of the line.
There is a way to do multi-line comments (they start with /' and ends with '/, kind of like C comments but with quote instead of *. I think this is kind of ugly, so I don't use them myself, but FreeBasic has them and I did want some way to do multi-line comments in BASIC.
Also, I think I am seeing that leading whitespace is always ignored.
FastC?
We're calling the Basic FastBasic, right?
Prop Fast Suite?
Propfast Suite?
Propeller Fast Suite? (need to get permission from Parallax on the trademark).
That will depend on the benchmark, I think
On the Atari I used a language called ACTION. a mix between BASIC and 6502 Assembler. That would keep the speed meme.
One could use the same trick as in @ersmith username, but erbasic, erc and erspin seems not so smart.
But currently fastspin is the most complete compiler collection so ECC comes to my mind...
Mike
Btw... an other very flexible compiler is (T)ACK ((The) Amsterdam Compiler Kit) and it is showing a not so common naming idea.
Hmm... so why not...
HCC - Halifax Compiler Collection.
Ok... GCC now is surrounded... \o/
I'll probably hold off on the name change until after the new C preprocessor and case-insensitive symbol support is in, and we can run some significant Propeller C programs.
In Spin we do: and in BASIC we do:
C doesn't have an object mechanism, so this will (obviously) be an extension. Some options:
- use a #pragma. This is compatible with the C standard, but possibly awkward
- use a string after extern. I think this would be a compatible extension to C++
- come up with a new keyword
I kind of like the extern idea, like: or even:
What do you think?
Maybe another way is do:
I didn't use "obj" or "object" in all cases because that's not a reserved word in all the languages. We could define a new keyword like "_Obj" for C (it would have to start with an underscore to avoid conflicts with variables in existing programs), so that is an option. But overall I was trying to do this extension while keeping the "feel" of each language. Unfortunately they all have very different ways of declaring variables. If anything Spin is the odd man out, since it has a completely different way of declaring objects from other variables.
@Rayman:
Using "#include" is an interesting idea. At first glance it's intuitively obvious. Unfortunately it also has some problems -- normally "#include" means to literally insert the text of the file being included into this point in the file. We could change that for files whose name ends in .spin or .bas, but for .c files there would be a conflict -- are you including the .c as an object, or just putting the text in-line? There's existing code that does the latter already.
I also worry that it could lead beginners into a common trap where they think of #include as doing more than it does. I've already seen that in questions about PropGCC, where they seem to think of #include as arranging for everything needed for linking, where in fact (in standard C at least) it's just a plain text substitution.
The #include is obviously not compliant with anything, but have you ever seen a #include with a .spin extension?
Actually, I think I changed my mind...
I like your: better...
Will this ultimately have a linker ? If so, any plan should be linker compatible ?
With a linker, a header file can declare names, and then the linked .OBJ file can come from any language source at all.