Funny compiler bug

[Wuerfel21]

ExampleVGMPlay - Archive [Date 2023.01.30 Time 00.48].zip

Apparently setting _CLKFREQ from a subobject constant is busted in 2.9.2. The changelog alleges that such an issue has been fixed, but I guess this is an edge case?

[PropGit]

Are you getting a compiler error, or a runtime error of some sort? I compiled your example starting from "ExampltVGMPlay.spin2" and it compiled successfully.

[Wuerfel21]

Oh yes, it's a run-time problem. Connect audio to appropriate pins and marvel at the difference between the given _clkfreq expression and setting it to 320_000_000 (or anything else, really)

[PropGit]

Maybe I'm missing something somewhere, but what I see is exactly what it should be:
The subobject's OPN_SAMPLE_RATE value is 55555 (which is 8,000,000 / (6 * 4 * 6))
and 55555 * 256 * 23 is 327,107,840 which is exactly what Propeller Tool shows the _CLKFREQ constant was set to:

So setting the _CLKFREQ = 320_000_000 will of course result in a different frequency (and different behavior) that the calculated value.

I went back and tested this also on Propeller Tool v2.8 and v2.7; both of which compile it the same as 2.9.2.

[Wuerfel21]

Yep, it shows the correct value, but is broken at runtime

[ChipGracey]

Clock settings are going to be computed for each object, according to any clock-setting symbols present. Only the top file's setting will be used, in the end. Child objects should be checking the runtime variable "clkfreq" to get the actual clock frequency. Any child object that relies on its own compile-time clock settings can wind up out of tune with the top file's setting which was used on application start-up. Am I not understanding something, though, Wuerfel21?

[Wuerfel21]

No, the problem is setting the top-level clkfreq to an expression involving a constant from a sub-object. Just download the the archive in OP and see it for yourself. Surely you got one of those DAC boards around.

[ChipGracey]

I think this should be fixed in v38 of PNut.

…

On Fri, Feb 3, 2023 at 12:34 PM Wuerfel21 ***@***.***> wrote: No, the problem is setting the top-level clkfreq to an expression involving a constant from a sub-object. Just download the the archive in OP and see it for yourself. Surely you got one of those DAC boards around. — Reply to this email directly, view it on GitHub <#176 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZ7M2NGJH35DBDC5LDVZHDWVVTWBANCNFSM6AAAAAAUKQZ7VI> . You are receiving this because you commented.Message ID: ***@***.***>