Open dbetz opened 8 years ago
As discussed in the forum posting, this is not a bug in OpenSpin. It's a limitation of the original compiler, but BSTC is allowing the code to work.
Any chance it could be fixed in both? I guess you said it was a lot of work though. Anyway, it seems like a major flaw since it prevents symbols from an object to be used in a general way in an enclosing object.
On Oct 3, 2016, at 3:50 PM, Roy Eltham notifications@github.com wrote:
As discussed in the forum posting, this is not a bug in OpenSpin. It's a limitation of the original compiler, but BSTC is allowing the code to work.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/parallaxinc/OpenSpin/issues/30#issuecomment-251207495, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq-1gXVNpnACg-sb2vgjuC6q7V7SmGAks5qwVyMgaJpZM4KKF2o.
Doubtful the original x86 compiler will be changed to allow this case. It's possible a future version of OpenSpin might be able to make this case work.
The total size of the local variables needs to be known during the first pass compile step, and during that step the symbols for any child objects are not known (the child objects haven't been compiled yet).
I would like to try some experiments reorganizing how the compiling is done. One possible solution is to add another pass up front that finds the entire object tree structure. Then compile everything starting with all the leaves first and then working back towards the root/top object. This could not only solve this issue, but would make the unused method removal simpler and less fragile. However, the end result compiled objects would likely not be 100% binary matches with the original compiler's output, since the order of compiling impacts some tables, offsets, etc. that are in the binary output. I'll have to try it and see.
Hi Roy,
There is no rush to fix this design issue since I only found it trying to compile my old xbasic VM that no one is currently using. Your approach sounds like it would probably work though. in fact, xbasic has some similar problems and I think I handled it there by making an extra pass over the source where I only parse constants and function prototypes. That would fix this problem without a huge restructuring of the compiler. You only really need to capture the “interface” on this first pass. Anyway, thanks for considering my suggestion. You’ve done great work with OpenSpin!
David
On Oct 3, 2016, at 4:08 PM, Roy Eltham notifications@github.com wrote:
Doubtful the original x86 compiler will be changed to allow this case. It's possible a future version of OpenSpin might be able to make this case work.
The total size of the local variables needs to be known during the first pass compile step, and during that step the symbols for any child objects are not known (the child objects haven't been compiled yet).
I would like to try some experiments reorganizing how the compiling is done. One possible solution is to add another pass up front that finds the entire object tree structure. Then compile everything starting with all the leaves first and then working back towards the root/top object. This could not only solve this issue, but would make the unused method removal simpler and less fragile. However, the end result compiled objects would likely not be 100% binary matches with the original compiler's output, since the order of compiling impacts some tables, offsets, etc. that are in the binary output. I'll have to try it and see.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/parallaxinc/OpenSpin/issues/30#issuecomment-251212053, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq-1oJ34H0fDxZyqDqJ2cCq5JcLlbubks5qwWDQgaJpZM4KKF2o.
I just tried switching from BSTC to OpenSpin for compiling the Spin portions of xbasic and am running into a problem. I get an "undefined symbol 'vm'" error when compiling this code:
Here is the error message:
I built OpenSpin from sources cloned today from github so it should be the latest version.