Phil,
Here is fine, or a new thread is too. I'll start with a list here of a few things I was hoping to do...
1. Full preprocessor pass
2. Make OBJ references work like #include, allowing full/partial paths.
3. Dead code elemination (for spin, not pasm).
4. Case sensitivity
5. Add the '<exp> ? <true> : <false>" (ternary operation). This is a Chip request, that I really wan too.
6. Allow () for parameter-less functions.
This looks great. I'm Visual Studio user too...
Only thing I don't like is that you still need external tools to get the compiled program onto the Propeller.
To me, that kinda defeats the whole purpose...
Anyway, how hard would it be to write a MIT licenced loader?
Rayman, surely a compiler should compile and a loader should load?
It's the UNIX philosophy.
If you want a combined tool that can be done with a script, make file or a graphical IDE to drive them.
propgcc already has a loader and there are others around.
Rayman, surely a compiler should compile and a loader should load?
It's the UNIX philosophy.
If you want a combined tool that can be done with a script, make file or a graphical IDE to drive them.
propgcc already has a loader and there are others around.
It would be fairly trivial to include core elements of the propgcc loader in the compiler.
I'm thinking of programs such as my VisualSpin, that try to do everything...
I can do it now, without dependencies, by embedding propellent in my executable and then extracting it when needed.
But, it'd be much cleaner to do it all in C++.
One thing I don't want to do is include any GPL licensed code...
One thing I don't want to do is include any GPL licensed code...
We're all with you in avoiding the strict original GPL license sense.
GCC is no longer bound by such GPL problems because of the GPL3 exception clause.
The propgcc loader is MIT licensed.
Parallax would also like to avoid things that they consider unsustainable.
Ah but, let's assume we have a GPL Spin compiler and a GPL Propeller loader. Now you have no licence problems in running those from your IDE whatever licence terms you may want to put on it. Everyone is happy:)
Here is fine, or a new thread is too. I'll start with a list here of a few things I was hoping to do...
1. Full preprocessor pass
2. Make OBJ references work like #include, allowing full/partial paths.
3. Dead code elemination (for spin, not pasm).
4. Case sensitivity
5. Add the '<exp> ? <true> : <false>" (ternary operation). This is a Chip request, that I really wan too.
6. Allow () for parameter-less functions.
Okay, thanks. Here goes:
1. I would like to see a new, optional PRE section in Spin that can be used to specify an executable which is fed source via STDIN and outputs processed source via STDOUT.
2. Not so enthusiastic about the #INCLUDE pragma. I would rather see sublibraries specified on a line-by-line basis, like this:
The double-colon notation is OS-agnostic (i.e. no "/" or "\") and refers to subdirectories relative to a PATH hierarchy that's specified elsewhere. Allowing full paths in the source code makes the code less portable, IMO. However, a local PATH section may be acceptable for specific installations. (It could be called DIR in keeping with the three-letter section-header scheme.) It should not be used in library objects, however. It would be nice if the OBEX were further divided into sublibraries which matched the user's local library directory structure. This is the way Perl modules are organized, and it works quite well, with CPAN being the equivalent of the OBEX.
3. Dead code elimination: yes!
4. Case sensitivity. Enforced case coherence, maybe, but case sensitivity will be a minefield for new users. I'm not swayed by this one.
5. Ternary conditional operator: yes, absolutely!
6. Allow, but not require, () for parameterless methods: yes!
Some additions to your list:
7. with blocks that specify a default object reference so that things like sio#CR and sio.tx(byt) can just be written CR and tx(byt). In case of duplicate symbols, the symbols accessed would be those defined in the innermost block, working outwards.
8. Constant folding: eliminate the const pseudo-function entirely.
9. "Multicharacter strings with embedded escapes\n" that don't require that annoying string pseudo-function. Any constant string in Spin with more than one character should be zero-terminated and return its address, the way string works now. Single-character "strings" can still use the string function to distinguish them from simple byte values.
10. Local symbol tables for PASM code blocks. In cases where multiple assembly programs reside in one object, it's annoying having to come up with label names that aren't shared amongst them, and it makes it hard to incorporate previously-written code from other objects. seg and endseg pseudo-ops could be used to encapsulate the labels they delineate, and those labels would be unknown outside of the defined segment. In case of conflicts with global labels, the local ones would take precedence.
11. In PASM, the ability to address a :local_label from outside its range by prepending its controlling global label: global:local_label. This is the way it was done in SX assembly, and I'm surprised Chip didn't include it in PASM.
12. In PASM, a with pseudo-op that works the same way for external constants as the one in Spin. It would terminate with an endwith pseudo-op.
13. In PASM, MACROS!
14. In Spin, predefined constant functions:
CON
CR = $0d
FORMANT(x) = x * 100 / 1930
PUB start | f
f := FORMANT(1000) 'Compiled as f := 51
Anyway, that's a start. I've also got some ideas for a compact dereferencing syntax that makes heterogeneous structures and linked lists easier to access, but I've got to find my notes first.
Thanks for your consideration and indulgence!
-Phil
Addendum: I realize that some of my suggestions entail the use of a dictionary stack by the compiler. I hope it won't be too hard to add if it's not there already.
Actually what is the licence on the new open source Spin compiler? I'm not near my PC to check now.
It does not make any sence for Parallax to invest in creating open source dev tools under the MIT license. Some competitor could, theoreticaly, create their own new improved Prop I/II and adopt the Parallax tools add private improvements and be in business.
Ray,
Just curious but why do we want to see Chip's original x86 compiler code when we have Roy's C translation that does the same.
Might be intereting to see how Chip's brain works but it's not generally useful.
Roy, I guess this means you have the Assembly source code from Chip. Any more news on when or if that will be publically released?
My understanding was that they didn't want to release the x86 assembly source, and that was one of the main reasons I did the port to C/C++. Ken/Chip can correct me if I'm wrong.
Well, Roy qualified his program as "alpha" and "may have bugs".
If I had the x86 assembly code, I think I could just include it as inline assembly...
I'd now call it beta. Still has bugs, but the x86 code is completely translated. I have fixed a ton of bugs already, and will be doing bug fixes as highest priority in order to get this solid asap.
The double-colon notation is OS-agnostic (i.e. no "/" or "\") and refers to subdirectories relative to a PATH hierarchy that's specified elsewhere.
Why can't the tool just translate "\" to "/" ? Multiplatform Qt handles this internally, mostly without headaches to the user.
The :: is a C++ thingy - are you a convert already?
7. with blocks that specify a default object reference so that things like sio#CR and sio.tx(byt) can just be written CR and tx(byt). In case of duplicate symbols, the symbols accessed would be those defined in the innermost block, working outwards.
I disagree. This obfuscates code. If an object member is used, it should be prefixed by the object name. I.E terminal.str(...)
9. "Multicharacter strings with embedded escapes\n" that don't require that annoying string pseudo-function. Any constant string in Spin with more than one character should be zero-terminated and return its address, the way string works now. Single-character "strings" can still use the string function to distinguish them from simple byte values.
Enthusiastically Absolutely ! Please don't make me go another day having to use that horrible string syntax.
Problem is "the defacto standard" Propeller Tool will not like any extensions. This was solved by a tag in PBASIC.
a BIG on/off switch for the new features that defaults to OFF.
As ported, the compiler supports SPIN2011 (latest Spin standard based on 1.3 Propeller Tool). Anything added from now on either needs to pass a full regression test or be turned off by default so the default option compiler will ALWAYS compile the way the Propeller Tool does (at least until the standards committee meets and votes on the SPIN2014 standards and deprecates anything currently supported).
Why can't the tool just translate "\" to "/" ? Multiplatform Qt handles this internally, mostly without headaches to the user. The :: is a C++ thingy - are you a convert already?
It's better for the notation to be OS-neutral from the get-go, without explicit reference to a particular directory syntax. Being able to abstract in this way from a specific directory structure is probably the reason C++ and Perl both use the "::" notation. I'm a firm believer that implementation details like OS-specific syntax should not be part of the language itself.
I disagree. This obfuscates code. If an object member is used, it should be prefixed by the object name. I.E terminal.str(...)
It works in other languages and can make code more readable by eliminating unnecessary syntactic clutter, especially in the case of external constants.
'Didn't say that. What I meant was that I'm not enthused about it as a mechanism for specifying object directories.
Sorry I misunderstood. However, #include is typically used to bring in any code and definitely should not have the single use of specifying spin objects.
I do agree with everything else in your initial post where I did not reply.
To me :: does not say directory as good as "\" or the alternative. Maybe that's not the point though? Perhaps it has a better meaning?
I'm not influenced by your other counter points though. Even the dustbin thingy doesn't work though because there will still be "old propeller tool" users. To me the extended compiler really is just an option in addition to the current definition. I will definitely embrace it over the dusty one though
Did it look to anyone else like the title of this thread is an open source SPASM compiler?
I agree that pre-compiler directives would be welcomed, such as ifdef and such. You can make them backwards compatible by including them in comment blocks:
I also think the :: delimiter is a good idea, quite frankly, Windows and DOS before it, doesn't follow the convention set out decades before. A backslash for for escapes, has been and always will be. When writing a compiler you have a parser and tokenizer, the backslash character gets overloaded to mean a directory and escape, that is bad. The compiler shouldn't have to say "this is a special case because it's a file name", it should treat all literal strings the same internally.
The only way to make the old SPIN compiler grok the new format is using 2 methods:
new SPIN adds a directive such as REQUIRE 1.4 which means it requires a spin compiler with SPIN rev 1.4 or above. This will cause the old SPIN compiler to choke, aborting compilation. This will cause the new SPIN compiler to properly do a revision test and suggest you upgrade your compiler. This could avoid any non-compatible new keywords or formats.
Pre-compiler directives could be included in comments to make it backwards compatible, but if the code depends on those, then it should break compilation anyway.
I look at it like this, if Parallax is going to support a compiler, and they will bless changes, it isn't a problem because that compiler is always available for people to download. If some 3rd person makes incompatible changes to the compiler, then the REQUIRE directive would solve those incompatibilities. Distributing of objects that use non-standard extensions is always a problem. The only way this would be a real issue is if Parallax declines to include some community supported changes either through intent or lack of action. If this were to occur, it is most likely that the community at large would take over the stewardship of the compiler and Parallax would no longer be the upstream provider, they would be a consumer of the community developed compiler. This is not a bad thing per-se, but it would be in Parallax's best interests to remain the corporate steward of the compiler and language and to be responsive to best-practiced changes.
To me :: does not say directory as good as "\" or the alternative. Maybe that's not the point though?
Precisely. "Subdirectory" is an OS concept, not a computer language concept. A distinction without a difference? Perhaps, as long as the hierarchy of objects stands in one-to-one correspondence with the OS's directory structure. But who's to say that will always be the case? One other thing to consider: the object names are enclosed in double quotes. There may be times when it's desirable to embed escape sequences in those names, say, for users who want to save their objects with Russian names. That would preclude using "\" for sub-class notation.
As long as the extensions do not break backwards compatibility, a compile switch is probably unnecessary. However, the addition of any new keywords does break compatibility, since someone is bound to have used the new keyword as a variable name. So I'll concede the point.
My understanding was that they didn't want to release the x86 assembly source, and that was one of the main reasons I did the port to C/C++. Ken/Chip can correct me if I'm wrong.
What Roy said.
The objective was to produce the C/C++ compiler, to validate it as bug-free, and to have it be the tool from which we make the various extensions and modifications identified above. The x86 assembly source requires some support and explanation from Chip, which Roy was able to obtain after several visits and discussions (and a year of work). We don't have a formal testing process in place for Roy's translation yet, but Jeff will start testing after we get the Eclipse GUI closer to release for the PropGCC beta.
I'm not about to burden Chip with the request, let alone expose him to the follow-up questions (even though Rayman wouldn't bother him, others will). Right now Chip's on a productive path with Propeller 2 and one of my jobs is give him the environment to finish the project.
Ken Gracey
P.S. to Roy: welcome to the Star Contributors section of our web site!
A few quick things (I'll reply in more detail when I am not at work):
1. I am inclined to use '/' ONLY as a directory delimiter for OBJ references. I do not like the idea of using :: for it at all, sorry. I also did not intend to allow for other OS specific elements in there either (so no "C:"). I did plan to support using '.' and '..' to mean current directory and parent directory and '/' to mean the root. As far as I know those all work the same across linux, mac, and windows.
2. My feeling is that #includes can go anywhere in the code and include any kind of file containing any kind of data, it's just part of the preprocessor.
3. It's my hope that I once this is solid, I'll work with Jeff Martin at parallax to make it so that the Propeller Tool uses this instead of the x86 code it uses now. This would be an interim step to bring up the existing tool to the current Spin compiler while a new cross platform tool is worked on. It should be pretty easy and quick for us to do it, once we are ready.
4. I'm really not a fan of the "with" stuff at all. I feel that the minor amount of typing it saves comes with a strong downside of code obfuscation. (e.g. when I see #CR I expect to find CR defined in the current file, I think it's horrible to have to find and navigate indirections that could be significantly distant from the instance I am looking at).
I'm working on some testing stuff, also, using propellent and my code to process the same spin file and produce binary output and then compare the results. This should help me find and fix a lot of bugs in the interim while Jeff works on his other tasks.
This should help me find and fix a lot of bugs in the interim while Jeff works on his other tasks.
Roy
That's what I figure. We'll bring Jeff in after some of the more obvious fixes are made. I'll wait to get the word from you when you think we're at that point. I saw an Eclipse demo with PropGCC from him yesterday and it's working quite nicely. Next up is GDB integration.
Comments
Here is fine, or a new thread is too. I'll start with a list here of a few things I was hoping to do...
1. Full preprocessor pass
2. Make OBJ references work like #include, allowing full/partial paths.
3. Dead code elemination (for spin, not pasm).
4. Case sensitivity
5. Add the '<exp> ? <true> : <false>" (ternary operation). This is a Chip request, that I really wan too.
6. Allow () for parameter-less functions.
Roy
Only thing I don't like is that you still need external tools to get the compiled program onto the Propeller.
To me, that kinda defeats the whole purpose...
Anyway, how hard would it be to write a MIT licenced loader?
It's the UNIX philosophy.
If you want a combined tool that can be done with a script, make file or a graphical IDE to drive them.
propgcc already has a loader and there are others around.
It would be fairly trivial to include core elements of the propgcc loader in the compiler.
I can do it now, without dependencies, by embedding propellent in my executable and then extracting it when needed.
But, it'd be much cleaner to do it all in C++.
One thing I don't want to do is include any GPL licensed code...
GCC is no longer bound by such GPL problems because of the GPL3 exception clause.
The propgcc loader is MIT licensed.
Parallax would also like to avoid things that they consider unsustainable.
One Ring to bring them all and in the darkness bind them
Keep the tools separate, let the GUI or Makefiles do their magic.
Okay, thanks. Here goes:
2. Not so enthusiastic about the #INCLUDE pragma. I would rather see sublibraries specified on a line-by-line basis, like this:
The double-colon notation is OS-agnostic (i.e. no "/" or "\") and refers to subdirectories relative to a PATH hierarchy that's specified elsewhere. Allowing full paths in the source code makes the code less portable, IMO. However, a local PATH section may be acceptable for specific installations. (It could be called DIR in keeping with the three-letter section-header scheme.) It should not be used in library objects, however. It would be nice if the OBEX were further divided into sublibraries which matched the user's local library directory structure. This is the way Perl modules are organized, and it works quite well, with CPAN being the equivalent of the OBEX.
3. Dead code elimination: yes!
4. Case sensitivity. Enforced case coherence, maybe, but case sensitivity will be a minefield for new users. I'm not swayed by this one.
5. Ternary conditional operator: yes, absolutely!
6. Allow, but not require, () for parameterless methods: yes!
Some additions to your list:
8. Constant folding: eliminate the const pseudo-function entirely.
9. "Multicharacter strings with embedded escapes\n" that don't require that annoying string pseudo-function. Any constant string in Spin with more than one character should be zero-terminated and return its address, the way string works now. Single-character "strings" can still use the string function to distinguish them from simple byte values.
10. Local symbol tables for PASM code blocks. In cases where multiple assembly programs reside in one object, it's annoying having to come up with label names that aren't shared amongst them, and it makes it hard to incorporate previously-written code from other objects. seg and endseg pseudo-ops could be used to encapsulate the labels they delineate, and those labels would be unknown outside of the defined segment. In case of conflicts with global labels, the local ones would take precedence.
11. In PASM, the ability to address a :local_label from outside its range by prepending its controlling global label: global:local_label. This is the way it was done in SX assembly, and I'm surprised Chip didn't include it in PASM.
12. In PASM, a with pseudo-op that works the same way for external constants as the one in Spin. It would terminate with an endwith pseudo-op.
13. In PASM, MACROS!
14. In Spin, predefined constant functions:
Thanks for your consideration and indulgence!
-Phil
Addendum: I realize that some of my suggestions entail the use of a dictionary stack by the compiler. I hope it won't be too hard to add if it's not there already.
It does not make any sence for Parallax to invest in creating open source dev tools under the MIT license. Some competitor could, theoreticaly, create their own new improved Prop I/II and adopt the Parallax tools add private improvements and be in business.
Roy, I guess this means you have the Assembly source code from Chip. Any more news on when or if that will be publically released?
Tried running spin.exe on one of my spin files and got an error. It compiles fine with the prop tool
It did not like wr,nr on a PASM line as shown
Tom
Just curious but why do we want to see Chip's original x86 compiler code when we have Roy's C translation that does the same.
Might be intereting to see how Chip's brain works but it's not generally useful.
If I had the x86 assembly code, I think I could just include it as inline assembly...
My understanding was that they didn't want to release the x86 assembly source, and that was one of the main reasons I did the port to C/C++. Ken/Chip can correct me if I'm wrong.
Only thing missing now is a good editor in C++ with MIT license...
Thanks for the report, I've added it to the issue tracker at google code, and will fix it tonight after work.
I'd now call it beta. Still has bugs, but the x86 code is completely translated. I have fixed a ton of bugs already, and will be doing bug fixes as highest priority in order to get this solid asap.
Why can't the tool just translate "\" to "/" ? Multiplatform Qt handles this internally, mostly without headaches to the user.
The :: is a C++ thingy - are you a convert already?
Except for the initial 3 hour installation for the development environment
I disagree. This obfuscates code. If an object member is used, it should be prefixed by the object name. I.E terminal.str(...)
Enthusiastically Absolutely ! Please don't make me go another day having to use that horrible string syntax.
Problem is "the defacto standard" Propeller Tool will not like any extensions. This was solved by a tag in PBASIC.
I'm even less enthusiastic about this. Why do we need to introduce such blocks in PASM?
As ported, the compiler supports SPIN2011 (latest Spin standard based on 1.3 Propeller Tool). Anything added from now on either needs to pass a full regression test or be turned off by default so the default option compiler will ALWAYS compile the way the Propeller Tool does (at least until the standards committee meets and votes on the SPIN2014 standards and deprecates anything currently supported).
It's better for the notation to be OS-neutral from the get-go, without explicit reference to a particular directory syntax. Being able to abstract in this way from a specific directory structure is probably the reason C++ and Perl both use the "::" notation. I'm a firm believer that implementation details like OS-specific syntax should not be part of the language itself.
It works in other languages and can make code more readable by eliminating unnecessary syntactic clutter, especially in the case of external constants.
The defacto standard Propeller Tool will be banished to the dustbin of history -- I can only hope.
So we can say mov acc,#CR instead of mov acc,#sio#CR. It's just cleaner and less cumbersome to type.
-Phil
-Phil
I do agree with everything else in your initial post where I did not reply.
To me :: does not say directory as good as "\" or the alternative. Maybe that's not the point though? Perhaps it has a better meaning?
I'm not influenced by your other counter points though. Even the dustbin thingy doesn't work though because there will still be "old propeller tool" users. To me the extended compiler really is just an option in addition to the current definition. I will definitely embrace it over the dusty one though
I agree that pre-compiler directives would be welcomed, such as ifdef and such. You can make them backwards compatible by including them in comment blocks:
{
#ifdef foobar
#define baz round(a)
#else
#define baz floor(a)
#endif
}
I also think the :: delimiter is a good idea, quite frankly, Windows and DOS before it, doesn't follow the convention set out decades before. A backslash for for escapes, has been and always will be. When writing a compiler you have a parser and tokenizer, the backslash character gets overloaded to mean a directory and escape, that is bad. The compiler shouldn't have to say "this is a special case because it's a file name", it should treat all literal strings the same internally.
The only way to make the old SPIN compiler grok the new format is using 2 methods:
new SPIN adds a directive such as REQUIRE 1.4 which means it requires a spin compiler with SPIN rev 1.4 or above. This will cause the old SPIN compiler to choke, aborting compilation. This will cause the new SPIN compiler to properly do a revision test and suggest you upgrade your compiler. This could avoid any non-compatible new keywords or formats.
Pre-compiler directives could be included in comments to make it backwards compatible, but if the code depends on those, then it should break compilation anyway.
I look at it like this, if Parallax is going to support a compiler, and they will bless changes, it isn't a problem because that compiler is always available for people to download. If some 3rd person makes incompatible changes to the compiler, then the REQUIRE directive would solve those incompatibilities. Distributing of objects that use non-standard extensions is always a problem. The only way this would be a real issue is if Parallax declines to include some community supported changes either through intent or lack of action. If this were to occur, it is most likely that the community at large would take over the stewardship of the compiler and Parallax would no longer be the upstream provider, they would be a consumer of the community developed compiler. This is not a bad thing per-se, but it would be in Parallax's best interests to remain the corporate steward of the compiler and language and to be responsive to best-practiced changes.
--Perry
As long as the extensions do not break backwards compatibility, a compile switch is probably unnecessary. However, the addition of any new keywords does break compatibility, since someone is bound to have used the new keyword as a variable name. So I'll concede the point.
-Phil
What Roy said.
The objective was to produce the C/C++ compiler, to validate it as bug-free, and to have it be the tool from which we make the various extensions and modifications identified above. The x86 assembly source requires some support and explanation from Chip, which Roy was able to obtain after several visits and discussions (and a year of work). We don't have a formal testing process in place for Roy's translation yet, but Jeff will start testing after we get the Eclipse GUI closer to release for the PropGCC beta.
I'm not about to burden Chip with the request, let alone expose him to the follow-up questions (even though Rayman wouldn't bother him, others will). Right now Chip's on a productive path with Propeller 2 and one of my jobs is give him the environment to finish the project.
Ken Gracey
P.S. to Roy: welcome to the Star Contributors section of our web site!
1. I am inclined to use '/' ONLY as a directory delimiter for OBJ references. I do not like the idea of using :: for it at all, sorry. I also did not intend to allow for other OS specific elements in there either (so no "C:"). I did plan to support using '.' and '..' to mean current directory and parent directory and '/' to mean the root. As far as I know those all work the same across linux, mac, and windows.
2. My feeling is that #includes can go anywhere in the code and include any kind of file containing any kind of data, it's just part of the preprocessor.
3. It's my hope that I once this is solid, I'll work with Jeff Martin at parallax to make it so that the Propeller Tool uses this instead of the x86 code it uses now. This would be an interim step to bring up the existing tool to the current Spin compiler while a new cross platform tool is worked on. It should be pretty easy and quick for us to do it, once we are ready.
4. I'm really not a fan of the "with" stuff at all. I feel that the minor amount of typing it saves comes with a strong downside of code obfuscation. (e.g. when I see #CR I expect to find CR defined in the current file, I think it's horrible to have to find and navigate indirections that could be significantly distant from the instance I am looking at).
Thanks!
I'm working on some testing stuff, also, using propellent and my code to process the same spin file and produce binary output and then compare the results. This should help me find and fix a lot of bugs in the interim while Jeff works on his other tasks.
Roy
That's what I figure. We'll bring Jeff in after some of the more obvious fixes are made. I'll wait to get the word from you when you think we're at that point. I saw an Eclipse demo with PropGCC from him yesterday and it's working quite nicely. Next up is GDB integration.
Ken