Odd BST behavior

Mike Green

I have BST 0.19.4-pre12 for the MacOS. I took the F32 demo and modified FloatString and the demo program to use just F32. When I compile it using the "Compile information" menu item, I get a dependency chart that's missing the F32 entry under FloatString. This is regardless of whether the optimization to eliminate unused methods is on or off. The Propeller Tool properly shows F32 under FloatString as well as under the main program.

Attached is the archive that demonstrates this. The problem originally showed up in a much larger and more complex program that I was modifying to use F32.

davidsaunders

This is definitely odd behaviour. It works correctly with bst.linux v0.19.3 and bstc.linux 0.15.4pre5 on XUbuntu 10.10.

SSteve

I think it's just a display error. Propeller Tool under Windows, bst, and pzst (which uses bstc for its compiler) with all optimizations off all show code size being 1126 longs. PZST doesn't show a dependency chart, though.

Your modified FloatString uses F32, but never calls F32.start. Will that be a problem since F32 uses a cog?

Mike Green

@SSteve
That's a good catch, but it solves a different problem. The few variables in F32 should have been moved to a DAT section rather than a VAR section so there's only one copy no matter how many times F32 is included in the object tree. That way, only the main program needs to start up the cog. All other uses of F32 refer to the same (already running) cog. Unfortunately, fixing that doesn't seem to change the way BST displays the object tree. F32 is still missing under FloatString.

Here's the version with F32 using a DAT section.

lonesock

Just as a reference, I left F32 as a non-singleton so I could use multiple instances to speed up calculations by using multiple cogs. This may be too niche for most users...if we can get a consensus on the default mode, I'd be happy to change it for the next revision. I *really* wish the main propeller tool supported conditional compilation. I use BST for all my dev work, but can't expect that to be the case for all users of F32.

Jonathan

SSteve

Mike, bst and the prop tool create identical binaries and eeprom files, so it looks like the program is correct. Is your concern just that the dependency tree is incorrect?

Also (and I hope this isn't hijacking the thread. I'll start a new thread if you prefer) if you use your modified F32 as a singleton does that not create a potential race condition if F32 is being accessed from processes in multiple cogs?

Mike Green

For the applications I have in mind, F32 would only be used by one cog, so locking it or having multiple instances is not an issue. My concern is that the Propeller Tool and BST are behaving differently in terms of displaying the object tree. I'm also concerned that the code produced may be different in this case. I haven't checked yet, so it's only conjecture.

This is one of those "natural situations" (running two copies of F32) where an object (F32) needs to be referenced from more than one object (Main and FloatString) and there are legitimate reasons why some of these references should be to one instance and other references should be to another instance and there's no way to specify that or make it happen. The code involved (F32) is identical in all instances and ought to be shared. It can be done by duplicating source code with different file names, but that's a cludge.

Phil Pilgrim (PhiPi)

Mike,

It takes more than different files names to force inclusion of separate load modules -- at least for the Prop Tool. Chip's compiler actually compares the object code generated by different objects and, when there's an exact match, includes only one in the build. You'd have to change the source code slightly to force two copies.

-Phil