Spin compiler oddity/bug/optimization?

mpark

I've encountered something I don't understand in the prop tool (and propellent too).
I have three files, odd0.spin, odd1.spin, and odd2.spin:

' odd0
OBJ
o1 : "odd1"
o2 : "odd2"
PUB Start0
return 0

' odd1
PUB Start1
return 1

' odd2
PUB Start2
return 2

When I compile odd0.spin and save the binary, odd0.binary is 60 bytes long. So far, so good.
If I change odd2's Start2 to return 1 instead of 2 and recompile, odd0.binary is 48 bytes long. Odd!

Comparing the bytes generated in the two cases, it appears to me that in the second case, the compiler has omitted odd2 entirely. OBJ variables o1 and o2 both point to the same object, odd1 (or maybe it's odd2, and odd1 has been omitted; there's no way to tell because they're identical). It's as if the compiler detected that odd1 and odd2 are identical and optimized one of them away. But this is totally unexpected, given the complete lack of optimization everywhere else in the compiler. I'm rather inclined to consider this a bug, but maybe there's another explanation. What do you folks·think?







▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Michael Park

PS, BTW, and FYI:
To search the forum, use search.parallax.com (do not use the Search button).
Check out the Propeller Wiki: propeller.wikispaces.com/

Mike Green

It may be odd, but it's expected. There is one optimization done by the compiler. If the binary code produced by the compiler for two objects (like odd1 and odd2) is identical, one of them is discarded and the one copy is used for both references. This is intended to handle the case where you have the same code (like FullDuplexSerial) used for several instances (with unique variable areas created). You just happened to stumble across that mechanism in a slightly different scenario. For this to work, the binary code produced by compiling the two objects must be identical. Any VAR areas are not included since they're not allocated until later in the compilation process.

mpark

Learn something every day. Thanks Mike!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Michael Park

PS, BTW, and FYI:
To search the forum, use search.parallax.com (do not use the Search button).
Check out the Propeller Wiki: propeller.wikispaces.com/

Timmoore

Mike, That could cause an interesting problem. If you have 2 copies of an object that uses DAT rather than VAR. You call routines in each to set their DAT variables and then after you have set both objects DAT variables you start a ASM cog in each that uses the DAT variables to do something different. If they both use the same binary then they will overwrite each others DAT areas. Is this what you expect?

Mike Green

The DAT sections are not supposed to be unique. They are normally treated as constants. If you have two cogs where the same DAT section is to be loaded, your code has to make sure they're not both modified in hub memory at the same time. The only time this could cause a problem is if you have two objects that are compiled from different source code that, by chance or by deliberate effort, consist of the same compiled interpretive code and DAT information. Except for some very trivial cases, there is vanishingly small likelihood of this happening by chance. I think this should be well documented in Propeller Tricks and Traps and, eventually, some revision of the manual. I can't see that it needs to be fixed otherwise. A simple fix for those that care would be to include the name of the source program as a two long DAT constant somewhere in the program.

Timmoore

I can't find it in the traps doc. The case I have seen is with my 4 serial port driver. I use DAT so you can use it in multiple objects each using 1 or more of the ports. Someone wanted more than 4 ports. The way I have seen it suggested in other drivers e.g. serialmirror is to copy and rename the file. What you are saying is this is not enough, you must copy the file and change something. Your suggestion of a dat variable that is effectivity a file version is a good way to do this.

Phil Pilgrim (PhiPi)

This issue came up with my callback object, which uses Spin-level self-modifying code. You can read about it, including Chip's reply, here.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

Timmoore

Thanks Phil, that explains the problem folks were seeing with pcFullDuplexSerial4FC.spin. I added a long in the DAT section and added some comments to make it clearer.