The original thread question was about Spin vs. C speed. We've seen that C++ and Tachyon can both use special libraries to implement SPI at 3.3 Mbps, but this doesn't necessarily tell us much about the language speeds. What happens if you have to implement a custom bit-banging protocol to control a board? Which language should you choose then?
I submit that the answer is Spin, compiled with fastspin. Here's a Spin version (pure Spin, no PASM!) of the SPI protocol:
CON
_clkmode = xtal1 + pll16x
_clkfreq = 80_000_000
DO = 0 'pins
CLK = 1
CS = 2
OBJ
fds : "FullDuplexSerial.spin"
VAR
byte array[512]
pub Main | i, time, ptr
'' start up the serial port
fds.start(31, 30, 0, 115200)
outa[CS] := 1
dira[CS] := 1
dira[DO] := 1
dira[CLK] := 1
repeat i from 0 to 511
array[i] := i & 255
time := cnt
ptr := @array[0]
outa[CS] := 0
repeat 512
spiout(byte[ptr])
ptr++
outa[CS] := 1
time := cnt-time
' print time
fds.str(string("elapsed time: "))
fds.dec(time)
fds.str(string(" cycles", 13, 10))
repeat
pub spiout(value)
value ><= 8 'MSB first
repeat 8 '8 bits
outa[DO] := value
outa[CLK] := 1
value >>= 1
outa[CLK] := 0
and load the resulting spitest.binary using the tool of your choice, to get:
elapsed time: 98848 cycles
That's for 512 bytes, so the speed is 3314988 Mbps -- slightly slower than the Propware and Tachyon versions, but note that there is absolutely no PASM, inline or otherwise, needed and no custom libraries -- we're just directly bit-banging.
That's very impressive. Is that compiled in COG mode or LMM?
The original thread question was about Spin vs. C speed. We've seen that C++ and Tachyon can both use special libraries to implement SPI at 3.3 Mbps, but this doesn't necessarily tell us much about the language speeds. What happens if you have to implement a custom bit-banging protocol to control a board? Which language should you choose then?
I submit that the answer is Spin, compiled with fastspin. Here's a Spin version (pure Spin, no PASM!) of the SPI protocol:
CON
_clkmode = xtal1 + pll16x
_clkfreq = 80_000_000
DO = 0 'pins
CLK = 1
CS = 2
OBJ
fds : "FullDuplexSerial.spin"
VAR
byte array[512]
pub Main | i, time, ptr
'' start up the serial port
fds.start(31, 30, 0, 115200)
outa[CS] := 1
dira[CS] := 1
dira[DO] := 1
dira[CLK] := 1
repeat i from 0 to 511
array[i] := i & 255
time := cnt
ptr := @array[0]
outa[CS] := 0
repeat 512
spiout(byte[ptr])
ptr++
outa[CS] := 1
time := cnt-time
' print time
fds.str(string("elapsed time: "))
fds.dec(time)
fds.str(string(" cycles", 13, 10))
repeat
pub spiout(value)
value ><= 8 'MSB first
repeat 8 '8 bits
outa[DO] := value
outa[CLK] := 1
value >>= 1
outa[CLK] := 0
and load the resulting spitest.binary using the tool of your choice, to get:
elapsed time: 98848 cycles
That's for 512 bytes, so the speed is 3314988 Mbps -- slightly slower than the Propware and Tachyon versions, but note that there is absolutely no PASM, inline or otherwise, needed and no custom libraries -- we're just directly bit-banging.
That's very impressive. Is that compiled in COG mode or LMM?
Unless fastspin also implements a caching mechanism like fcache, that would have to be COG mode wouldn't it? In which case... hmm... why doesn't COG mode with PropGCC compile to something similar, instead of the above reported 1.43 Mbps? Perhaps further testing is needed.
That's very impressive. Is that compiled in COG mode or LMM?
Unless fastspin also implements a caching mechanism like fcache, that would have to be COG mode wouldn't it? In which case... hmm... why doesn't COG mode with PropGCC compile to something similar, instead of the above reported 1.43 Mbps? Perhaps further testing is needed.
That's for LMM mode. fastspin does implement fcache now, which is how it was able to get to that number. Its optimizer is also better than GCC's on small, specialized code (like bit-banging) -- it's not nearly as good yet on loops or math, but this program has pretty simple loops and not much math.
That's very impressive. Is that compiled in COG mode or LMM?
Unless fastspin also implements a caching mechanism like fcache, that would have to be COG mode wouldn't it? In which case... hmm... why doesn't COG mode with PropGCC compile to something similar, instead of the above reported 1.43 Mbps? Perhaps further testing is needed.
That's for LMM mode. fastspin does implement fcache now, which is how it was able to get to that number. Its optimizer is also better than GCC's on small, specialized code (like bit-banging) -- it's not nearly as good yet on loops or math, but this program has pretty simple loops and not much math.
Wow! You've done some great work on FastSpin! Thanks for your efforts.
That's very impressive. Is that compiled in COG mode or LMM?
Unless fastspin also implements a caching mechanism like fcache, that would have to be COG mode wouldn't it? In which case... hmm... why doesn't COG mode with PropGCC compile to something similar, instead of the above reported 1.43 Mbps? Perhaps further testing is needed.
That's for LMM mode. fastspin does implement fcache now, which is how it was able to get to that number. Its optimizer is also better than GCC's on small, specialized code (like bit-banging) -- it's not nearly as good yet on loops or math, but this program has pretty simple loops and not much math.
Wow! You've done some great work on FastSpin! Thanks for your efforts.
Indeed! That really brings Spin into a new light.
Oh, and @ersmith, what's the code size for your SPI benchmark?
Oh, and @ersmith, what's the code size for your SPI benchmark?
3112 bytes (vs. 936 bytes for openspin; so 4x larger and > 100x faster for this particular benchmark)
Good numbers, what does it come down to, if you move the print to another COG
-ie generate just code for SPI Send ?
Or is there a MAP file that shows that ?
Oh, and @ersmith, what's the code size for your SPI benchmark?
3112 bytes (vs. 936 bytes for openspin; so 4x larger and > 100x faster for this particular benchmark)
Good numbers, what does it come down to, if you move the print to another COG
-ie generate just code for SPI Send ?
Or is there a MAP file that shows that ?
Without the FullDuplexSerial (and with the prints commented out) the size is 1392 bytes. That still includes the LMM kernel and some utility functions like multiply. Compiling it for COG puts the size down to 848 bytes.
It's working well for me. I really wasn't aware of PropBASIC before this. Now, I'm running PropBASIC programs and wow they are fast. PropBAISC was just what I was looking for.
I'm working on code to provide I/O support to a 6502, and Spin was working but slow. I doubt I have the dedication to learn PASM just yet. PropBASIC fills the gap nicely and this IDE makes it easy. Thanks Brett, Bean, JohnnyMac and all the contributors. Amazing stuff.
Ran some comparison numbers this afternoon. Max SPI rate on an LPC4357 is 102 Mbps.
Dedicated hardware peripherals are sure great. What makes you bring up the lpc4357?
The LPC4357 is my ultimate target. It will use SPI to talk to an FPGA on the same board, but I didn't have the driver ready to test when I needed to test the FPGA design, so I did a quick SPI driver on the Propeller. The Propeller makes it easy to do quick prototypes like this, even if it doesn't have the ultimate performance I need.
Your question was if SPI coded in C is faster than in Spin and not what's the fastest SPI rate you can reach with the Prop.
With the use of the Counters you get 20 MBit/s with the Videoshifter you can maybe reach higher rates than your LPC. Both needs PASM and a good understanding of the Hardware. And it depends also on the data you want to send: Is it a single constant that you send multiple times, ist it an array of data in memory, is it runtime calculated data ?
The issues listed at the GitHub site are as follows:
- Please add to ColorPal library
- Renaming this GitHub to something more appropriate
- TOGGLE command bug in SimpleTools.h
- wavplayer.c needs optimization check
- sscani documented but missing
- Simple Libraries appear to need lib*.a rebuilds for propeller-gcc default branch.
- Doc SimpleText readStr() needs CR to complete entry.
- Library Header simpletext.h Needs Print Format Specifier Descriptions
- ee_put_float appears to only work when executed before other put actions
- Other-Cog resources only support LMM/CMM
I don't think any of these issues are related to using the latest PropGCC code.
I don't think it's any of these issues. I think Parallax considers the problem to be with the new GCC and not with the Simple Libraries so there wouldn't be an issue posted here. On the other hand, the issue could be posted to the propeller-gcc project. I'll see if I can track down the issues and get them posted there.
I'm just pinging this to see if it gets any action. PARALLAX, ARE YOU READING THIS. Yes, I was yelling. Maybe they'll hear it this time.
The issues listed at the GitHub site are as follows:
- Please add to ColorPal library
- Renaming this GitHub to something more appropriate
- TOGGLE command bug in SimpleTools.h
- wavplayer.c needs optimization check
- sscani documented but missing
- Simple Libraries appear to need lib*.a rebuilds for propeller-gcc default branch.
- Doc SimpleText readStr() needs CR to complete entry.
- Library Header simpletext.h Needs Print Format Specifier Descriptions
- ee_put_float appears to only work when executed before other put actions
- Other-Cog resources only support LMM/CMM
I don't think any of these issues are related to using the latest PropGCC code.
I don't think it's any of these issues. I think Parallax considers the problem to be with the new GCC and not with the Simple Libraries so there wouldn't be an issue posted here. On the other hand, the issue could be posted to the propeller-gcc project. I'll see if I can track down the issues and get them posted there.
I'm just pinging this to see if it gets any action. PARALLAX, ARE YOU READING THIS. Yes, I was yelling. Maybe they'll hear it this time.
I think the problem has boiled down to a problem when code compiled with the new version of PropGCC gets linked with binary libraries build with an older version. That sometimes results in programs that don't work correctly even though they do link correctly. The new version works fine as long as you compile everything from source and don't use old binary object files or libraries. I'm not sure how to address that other than maybe change the ELF file header information so the linker refuses to link old and new binaries.
The issues listed at the GitHub site are as follows:
- Please add to ColorPal library
- Renaming this GitHub to something more appropriate
- TOGGLE command bug in SimpleTools.h
- wavplayer.c needs optimization check
- sscani documented but missing
- Simple Libraries appear to need lib*.a rebuilds for propeller-gcc default branch.
- Doc SimpleText readStr() needs CR to complete entry.
- Library Header simpletext.h Needs Print Format Specifier Descriptions
- ee_put_float appears to only work when executed before other put actions
- Other-Cog resources only support LMM/CMM
I don't think any of these issues are related to using the latest PropGCC code.
I don't think it's any of these issues. I think Parallax considers the problem to be with the new GCC and not with the Simple Libraries so there wouldn't be an issue posted here. On the other hand, the issue could be posted to the propeller-gcc project. I'll see if I can track down the issues and get them posted there.
I'm just pinging this to see if it gets any action. PARALLAX, ARE YOU READING THIS. Yes, I was yelling. Maybe they'll hear it this time.
I think the problem has boiled down to a problem when code compiled with the new version of PropGCC gets linked with binary libraries build with an older version. That sometimes results in programs that don't work correctly even though they do link correctly. The new version works fine as long as you compile everything from source and don't use old binary object files or libraries. I'm not sure how to address that other than maybe change the ELF file header information so the linker refuses to link old and new binaries.
That seems like a reasonable solution. Any reason not to implement it?
The issues listed at the GitHub site are as follows:
- Please add to ColorPal library
- Renaming this GitHub to something more appropriate
- TOGGLE command bug in SimpleTools.h
- wavplayer.c needs optimization check
- sscani documented but missing
- Simple Libraries appear to need lib*.a rebuilds for propeller-gcc default branch.
- Doc SimpleText readStr() needs CR to complete entry.
- Library Header simpletext.h Needs Print Format Specifier Descriptions
- ee_put_float appears to only work when executed before other put actions
- Other-Cog resources only support LMM/CMM
I don't think any of these issues are related to using the latest PropGCC code.
I don't think it's any of these issues. I think Parallax considers the problem to be with the new GCC and not with the Simple Libraries so there wouldn't be an issue posted here. On the other hand, the issue could be posted to the propeller-gcc project. I'll see if I can track down the issues and get them posted there.
I'm just pinging this to see if it gets any action. PARALLAX, ARE YOU READING THIS. Yes, I was yelling. Maybe they'll hear it this time.
I think the problem has boiled down to a problem when code compiled with the new version of PropGCC gets linked with binary libraries build with an older version. That sometimes results in programs that don't work correctly even though they do link correctly. The new version works fine as long as you compile everything from source and don't use old binary object files or libraries. I'm not sure how to address that other than maybe change the ELF file header information so the linker refuses to link old and new binaries.
So it sounds like there really is nothing preventing Parallax from putting out an update of SimpleIDE with the latest PropGCC. They just need to rebuild everything.
The issues listed at the GitHub site are as follows:
- Please add to ColorPal library
- Renaming this GitHub to something more appropriate
- TOGGLE command bug in SimpleTools.h
- wavplayer.c needs optimization check
- sscani documented but missing
- Simple Libraries appear to need lib*.a rebuilds for propeller-gcc default branch.
- Doc SimpleText readStr() needs CR to complete entry.
- Library Header simpletext.h Needs Print Format Specifier Descriptions
- ee_put_float appears to only work when executed before other put actions
- Other-Cog resources only support LMM/CMM
I don't think any of these issues are related to using the latest PropGCC code.
I don't think it's any of these issues. I think Parallax considers the problem to be with the new GCC and not with the Simple Libraries so there wouldn't be an issue posted here. On the other hand, the issue could be posted to the propeller-gcc project. I'll see if I can track down the issues and get them posted there.
I'm just pinging this to see if it gets any action. PARALLAX, ARE YOU READING THIS. Yes, I was yelling. Maybe they'll hear it this time.
I think the problem has boiled down to a problem when code compiled with the new version of PropGCC gets linked with binary libraries build with an older version. That sometimes results in programs that don't work correctly even though they do link correctly. The new version works fine as long as you compile everything from source and don't use old binary object files or libraries. I'm not sure how to address that other than maybe change the ELF file header information so the linker refuses to link old and new binaries.
So it sounds like there really is nothing preventing Parallax from putting out an update of SimpleIDE with the latest PropGCC. They just need to rebuild everything.
It's not quite that easy. Users may have old libraries laying around that will result in zillions of support calls when they suddenly fail to work with the new version of SimpleIDE.
The issues listed at the GitHub site are as follows:
- Please add to ColorPal library
- Renaming this GitHub to something more appropriate
- TOGGLE command bug in SimpleTools.h
- wavplayer.c needs optimization check
- sscani documented but missing
- Simple Libraries appear to need lib*.a rebuilds for propeller-gcc default branch.
- Doc SimpleText readStr() needs CR to complete entry.
- Library Header simpletext.h Needs Print Format Specifier Descriptions
- ee_put_float appears to only work when executed before other put actions
- Other-Cog resources only support LMM/CMM
I don't think any of these issues are related to using the latest PropGCC code.
I don't think it's any of these issues. I think Parallax considers the problem to be with the new GCC and not with the Simple Libraries so there wouldn't be an issue posted here. On the other hand, the issue could be posted to the propeller-gcc project. I'll see if I can track down the issues and get them posted there.
I'm just pinging this to see if it gets any action. PARALLAX, ARE YOU READING THIS. Yes, I was yelling. Maybe they'll hear it this time.
I think the problem has boiled down to a problem when code compiled with the new version of PropGCC gets linked with binary libraries build with an older version. That sometimes results in programs that don't work correctly even though they do link correctly. The new version works fine as long as you compile everything from source and don't use old binary object files or libraries. I'm not sure how to address that other than maybe change the ELF file header information so the linker refuses to link old and new binaries.
So it sounds like there really is nothing preventing Parallax from putting out an update of SimpleIDE with the latest PropGCC. They just need to rebuild everything.
It's not quite that easy. Users may have old libraries laying around that will result in zillions of support calls when they suddenly fail to work with the new version of SimpleIDE.
This indeed does suck. Support calls suck. "Broken" linkers suck. Many unhappy people. So your options are:
1) Never update PropGCC in SimpleIDE
2) Update PropGCC in SimpleIDE and deal with the support calls/unhappy customers (this can be mitigated to some extent, large or small, with warning labels, SimpleIDE major version number bump, and who knows what else)
3) Revert the changes that were applied to PropGCC that caused incompatible binaries.
Maybe you know of others? Of these three options, none are good. However, they're the only three that I can think of, and I bet #2 is the best. #3 sounds fine and dandy, but I'll bet it's very difficult and potentially removes and/or reduces the featureset (only the PropGCC devs could answer that though). Hopefully we all - even Parallax - agree that #1 is a terrible idea.
The issues listed at the GitHub site are as follows:
- Please add to ColorPal library
- Renaming this GitHub to something more appropriate
- TOGGLE command bug in SimpleTools.h
- wavplayer.c needs optimization check
- sscani documented but missing
- Simple Libraries appear to need lib*.a rebuilds for propeller-gcc default branch.
- Doc SimpleText readStr() needs CR to complete entry.
- Library Header simpletext.h Needs Print Format Specifier Descriptions
- ee_put_float appears to only work when executed before other put actions
- Other-Cog resources only support LMM/CMM
I don't think any of these issues are related to using the latest PropGCC code.
I don't think it's any of these issues. I think Parallax considers the problem to be with the new GCC and not with the Simple Libraries so there wouldn't be an issue posted here. On the other hand, the issue could be posted to the propeller-gcc project. I'll see if I can track down the issues and get them posted there.
I'm just pinging this to see if it gets any action. PARALLAX, ARE YOU READING THIS. Yes, I was yelling. Maybe they'll hear it this time.
I think the problem has boiled down to a problem when code compiled with the new version of PropGCC gets linked with binary libraries build with an older version. That sometimes results in programs that don't work correctly even though they do link correctly. The new version works fine as long as you compile everything from source and don't use old binary object files or libraries. I'm not sure how to address that other than maybe change the ELF file header information so the linker refuses to link old and new binaries.
So it sounds like there really is nothing preventing Parallax from putting out an update of SimpleIDE with the latest PropGCC. They just need to rebuild everything.
It's not quite that easy. Users may have old libraries laying around that will result in zillions of support calls when they suddenly fail to work with the new version of SimpleIDE.
This indeed does suck. Support calls suck. "Broken" linkers suck. Many unhappy people. So your options are:
1) Never update PropGCC in SimpleIDE
2) Update PropGCC in SimpleIDE and deal with the support calls/unhappy customers (this can be mitigated to some extent, large or small, with warning labels, SimpleIDE major version number bump, and who knows what else)
3) Revert the changes that were applied to PropGCC that caused incompatible binaries.
Maybe you know of others? Of these three options, none are good. However, they're the only three that I can think of, and I bet #2 is the best. #3 sounds fine and dandy, but I'll bet it's very difficult and potentially removes and/or reduces the featureset (only the PropGCC devs could answer that though). Hopefully we all - even Parallax - agree that #1 is a terrible idea.
Option 4 is to change the object file header so the linker will generate an error if old and new objects are linked together.
I don't quite understand why a user would use an old library if they were told not to, but it seems like option 4 is the solution. So how do we get this to happen?
The issues listed at the GitHub site are as follows:
- Please add to ColorPal library
- Renaming this GitHub to something more appropriate
- TOGGLE command bug in SimpleTools.h
- wavplayer.c needs optimization check
- sscani documented but missing
- Simple Libraries appear to need lib*.a rebuilds for propeller-gcc default branch.
- Doc SimpleText readStr() needs CR to complete entry.
- Library Header simpletext.h Needs Print Format Specifier Descriptions
- ee_put_float appears to only work when executed before other put actions
- Other-Cog resources only support LMM/CMM
I don't think any of these issues are related to using the latest PropGCC code.
I don't think it's any of these issues. I think Parallax considers the problem to be with the new GCC and not with the Simple Libraries so there wouldn't be an issue posted here. On the other hand, the issue could be posted to the propeller-gcc project. I'll see if I can track down the issues and get them posted there.
I'm just pinging this to see if it gets any action. PARALLAX, ARE YOU READING THIS. Yes, I was yelling. Maybe they'll hear it this time.
I think the problem has boiled down to a problem when code compiled with the new version of PropGCC gets linked with binary libraries build with an older version. That sometimes results in programs that don't work correctly even though they do link correctly. The new version works fine as long as you compile everything from source and don't use old binary object files or libraries. I'm not sure how to address that other than maybe change the ELF file header information so the linker refuses to link old and new binaries.
So it sounds like there really is nothing preventing Parallax from putting out an update of SimpleIDE with the latest PropGCC. They just need to rebuild everything.
It's not quite that easy. Users may have old libraries laying around that will result in zillions of support calls when they suddenly fail to work with the new version of SimpleIDE.
This indeed does suck. Support calls suck. "Broken" linkers suck. Many unhappy people. So your options are:
1) Never update PropGCC in SimpleIDE
2) Update PropGCC in SimpleIDE and deal with the support calls/unhappy customers (this can be mitigated to some extent, large or small, with warning labels, SimpleIDE major version number bump, and who knows what else)
3) Revert the changes that were applied to PropGCC that caused incompatible binaries.
Maybe you know of others? Of these three options, none are good. However, they're the only three that I can think of, and I bet #2 is the best. #3 sounds fine and dandy, but I'll bet it's very difficult and potentially removes and/or reduces the featureset (only the PropGCC devs could answer that though). Hopefully we all - even Parallax - agree that #1 is a terrible idea.
Option 4 is to change the object file header so the linker will generate an error if old and new objects are linked together.
Option 4 wouldn't require doing any of option 3 since the incompatibilities could be resolved by rebuilding the libraries. The simple libraries and the GCC libraries would all be packaged together so there wouldn't be any incompatibles as long as they are used together. The only problem would be if someone tried to link with objects/libraries built from an earlier version of PropGCC. With Option 4 the user would be told to rebuild his old objects/libraries.
Option 4 wouldn't require doing any of option 3 since the incompatibilities could be resolved by rebuilding the libraries. The simple libraries and the GCC libraries would all be packaged together so there wouldn't be any incompatibles as long as they are used together. The only problem would be if someone tried to link with objects/libraries built from an earlier version of PropGCC. With Option 4 the user would be told to rebuild his old objects/libraries.
That was dumb of me I meant to say option 2. I meant that it should be implied that if PropGCC is updated within SimpleIDE, the new linker will throw an error when attempting to link with old libraries.
We're certainly not going to revert any changes. If we did that we might as well just stick with the version of PropGCC that is already part of SimpleIDE.
Comments
Unless fastspin also implements a caching mechanism like fcache, that would have to be COG mode wouldn't it? In which case... hmm... why doesn't COG mode with PropGCC compile to something similar, instead of the above reported 1.43 Mbps? Perhaps further testing is needed.
That's for LMM mode. fastspin does implement fcache now, which is how it was able to get to that number. Its optimizer is also better than GCC's on small, specialized code (like bit-banging) -- it's not nearly as good yet on loops or math, but this program has pretty simple loops and not much math.
Indeed! That really brings Spin into a new light.
Oh, and @ersmith, what's the code size for your SPI benchmark?
3112 bytes (vs. 936 bytes for openspin; so 4x larger and > 100x faster for this particular benchmark)
Good numbers, what does it come down to, if you move the print to another COG
-ie generate just code for SPI Send ?
Or is there a MAP file that shows that ?
Without the FullDuplexSerial (and with the prints commented out) the size is 1392 bytes. That still includes the LMM kernel and some utility functions like multiply. Compiling it for COG puts the size down to 848 bytes.
GHarris made the following comment:
Dedicated hardware peripherals are sure great. What makes you bring up the lpc4357?
The LPC4357 is my ultimate target. It will use SPI to talk to an FPGA on the same board, but I didn't have the driver ready to test when I needed to test the FPGA design, so I did a quick SPI driver on the Propeller. The Propeller makes it easy to do quick prototypes like this, even if it doesn't have the ultimate performance I need.
With the use of the Counters you get 20 MBit/s with the Videoshifter you can maybe reach higher rates than your LPC. Both needs PASM and a good understanding of the Hardware. And it depends also on the data you want to send: Is it a single constant that you send multiple times, ist it an array of data in memory, is it runtime calculated data ?
Andy
Many of the MCUs have some port-pin limits, that are sadly lower than the formula or core ....
Verified on an oscilloscope.
That seems like a reasonable solution. Any reason not to implement it?
This indeed does suck. Support calls suck. "Broken" linkers suck. Many unhappy people. So your options are:
1) Never update PropGCC in SimpleIDE
2) Update PropGCC in SimpleIDE and deal with the support calls/unhappy customers (this can be mitigated to some extent, large or small, with warning labels, SimpleIDE major version number bump, and who knows what else)
3) Revert the changes that were applied to PropGCC that caused incompatible binaries.
Maybe you know of others? Of these three options, none are good. However, they're the only three that I can think of, and I bet #2 is the best. #3 sounds fine and dandy, but I'll bet it's very difficult and potentially removes and/or reduces the featureset (only the PropGCC devs could answer that though). Hopefully we all - even Parallax - agree that #1 is a terrible idea.
Sorry, I meant for #4 to be an implied part of #2
That was dumb of me