Decompiler ambiguity for SCI0 and SCI01

[Charles]

I was looking through the decompiled QFG1EGA, and noticed something I think might be decompiling wrong, and I wanted to get other opinions on.

I've tried this in fresh decompilations for LSL3, QFG1EGA and QFG2, all with the same results. In script 994 (GAME.SC) it decompiles to (trimmed unnecessary code):

Code: [Select]

(instance controls of Controls
(properties)
)
(class Rm of Rgn
(properties
controls 0
)

(method (init &tmp temp0)
(= controls controls)
)
)

So there's a script instance called controls, and there's a property in the Rm class called the same thing.  In the Rm class, it's assigning (= controls controls).  Looks like the IDE assumes they're referencing the same thing, the control property (and I assume the compiler does the same), but I believe the original code being decompiled is actually (= <property>controls <instance>controls).

Can anybody confirm what's going on, or am I way off base?

[lskovlun]

This can occur when the name property is set explicitly. In that case, the object would have been called one thing in the source code, different from what you see when viewing it in the debugger for example, or when decompiling. There is no way for the decompiler to know what the original name was, and even detecting that this has occurred is problematic. In this particular case, we might detect the clash - doing something about it is another thing entirely. Rename either or both the variable and the object? Introduce a scoping operator?

(for example: Is the room class actually called Room or Rm? different games do different things, the source code calls it Room though, see https://github.com/OmerMor/SCI16/blob/master/SYSTEM/GAME.SC)

[Charles]

I’m less concerned with fixing this in the general case for the decompile than I am in solving it manually in this specific case. This feels like an edge case, so my interest is more for accuracy’s sake (for both the template and the decompilation archives).

How would one go about figuring out what the original control variables reference in that line? And is there a way without laboriously examining the bytecode?

[Kawa]

In (= controls controls) above, it clearly sets the Rm::controls property to a reference to the controls instance. Renaming the property may cause selector-related issues down the road in other scripts (because property names are stored in the selector table) but if that controls instance is only used locally you should be good to rename that.

[Charles]

In (= controls controls) above, it clearly sets the Rm::controls property to a reference to the controls instance.

I don't think it clearly does that, but I do agree it's the most reasonable assumption.

I know how to rename things to avoid the conflict, but I was hoping to actually confirm the reasonable assumption.

[troflip]

You can confirm it by looking at the disassembly for Rm's init method.

Code: [Select]

    (method (init) // method_097e
  097e:3f 01             link 1 // (var $1)
  0980:81 0b              lag gGNorth
  0982:65 0a             aTop number
  0984:72 f7a3          lofsa $012a // controls
  0987:65 18             aTop controls

In particular these lines:

Code: [Select]

  0984:72 f7a3          lofsa $012a // controls
  0987:65 18             aTop controls

load offset of controls into the accumulator (therefore controls must be an instance somewhere in this script)
put accumulator in property controls (therefore controls much be a property on this object)

[Charles]

Thank you, that was exactly what I was looking for!

I don't know enough about assembly to really do anything yet, but I'd like to learn more. I know I came across some pages before on how to decompile SCI byte code, but I haven't been able to find them again for the longest time.

Aha, wait a sec, here we go! This was what I was looking for. An earlier blog post from you: https://mtnphil.wordpress.com/2016/04/09/decompiling-sci-byte-code-part-1/

And a wiki page to help decipher the assembly codes: https://wiki.scummvm.org/index.php/SCI/Specifications/SCI_virtual_machine/The_Sierra_PMachine

I think I'll give those a read when I find the time.  Thanks again for your help.