Talk:SCO

Maybe it is a silly question, but if there is a push onto the stack, how the numbers are pop'ed back? Since SCO seems to be similar to ASM (I have not yet took a look to scripts, only to this article) I think it is worth to mention this in the article (if there is an awnser, what I hope ^^). --Aschratt 20:17, 5 February 2009 (UTC)

The list of opcodes is incomplete, there are ones that pop numbers back.Seemann 00:05, 6 February 2009 (UTC)

Well, since they only seem to be used as function parameters, there is no real point in popping them from the stack (since called functions do that internally), is there? Although, how are return values handled? Can there be multiple return values? --Steve-m 00:48, 6 February 2009 (UTC)

Steve I don't think there are multiple return values. CallNative opcode has a parameter that specifies the outputs generated by the native, but that seems to be only 0 and 1. Of course you can always create a structure then output a pointer like in C++. --Sacky

Difference Between 'Local' variables and 'Global' variables

Does anyone know it? The only difference I could possibly see between them is a public declaration in the script so other scripts could access it... I don't see how local variables are even used when function locals are supported.

Hmm, Sacky, what you mean by difference? The locals are usable only within one script (from any of its internal functions), whereas the globals are usable from any script. Seemann 10:13, 14 February 2009 (UTC)

So Local Variables can only be accessed by the host script (but are still global from a 1 script only perspective) and Global Variables can be accessed by other scripts? If so how does 1 script access anothers globals? I suppose this would also indicate an access right change so a 'public' declaration should be the proper way to distinguish a global variable from a local variable? Sacky

There is the global variables buffer (only one) where all global variables store their values. Local variables have a number of buffers (a seperate one for each script). So, the globals could be accessed by any script (using specific globals-only opcodes), and the locals could be accessed only by host script containing that buffer using specific locals-only opcodes. That's what I know, but I dunno the real purpose of the global variables container. Seemann 15:10, 14 February 2009 (UTC)

I think we should also clarify the names of opcodes 54 -> 61 and opcode 62. They don't really deal with local variables, but rather with stack variables!. This distinction is quite important as they are really accessing different things. The names LocalVarPtr/LocalVarPtrEx is confusing and should be avoided. Having -Ptr added to the opcode name further adds to the confusion as opcodes 63/64 also push a ptr onto the stack. Since the rest of the opcodes seem to come from the Scruff/SparkIV list, I'm curious to why you renamed these two? Aru 17:02, 24 February 2009 (UTC)

Here's the list of opcodes listener made for his unreleased tool:

0 = nop
1 = iadd
2 = isub
3 = imul
4 = idiv
5 = imod
6 = iszero
7 = ineg
8 = icmpeq
9 = icmpne
10 = icmpgt
11 = icmpge
12 = icmplt
13 = icmple
14 = fadd
15 = fsub
16 = fmul
17 = fdiv
18 = fmod
19 = fneg
20 = fcmpeq
21 = fcmpne
22 = fcmpgt
23 = fcmpge
24 = fcmplt
25 = fcmple
26 = vadd
27 = vsub
28 = vmul
29 = vdiv
30 = vneg
31 = iand
32 = ior
33 = ixor
34 = j
35 = jf
36 = jt
37 = itof
38 = ftoi
39 = ftov
40 = ipush2
41 = ipush
42 = fpush
43 = dup
44 = drop
45 = native
46 = call
47 = enter
48 = ret
49 = pget
50 = pset
51 = ppeekset
52 = fromstack
53 = tostack
54 = pframe0  
55 = pframe1  
56 = pframe2  
57 = pframe3  
58 = pframe4  
59 = pframe5  
60 = pframe6  
61 = pframe7  
62 = pframe
63 = pstatic
64 = pglobal
65 = parray
66 = switch
67 = spush
68 = op68
69 = scpy
70 = itos    
71 = sadd    
72 = saddi    
73 = catch    
74 = throw
75 = sncpy

Not that I like all of these, but he used a completely different way of naming, so probably some names could be accepted as a standard (at least in this article). Seemann 03:53, 25 February 2009 (UTC)

Your right those opcodes did need renaming, in fact I've renamed them along the lines of the list that Seemann provided because I think that conforms closer to assemblies produce by the likes of IDA etc. Also I've changed the naming of local variables and global variables to global variables and public variables (as that initially caused me some confusion). High Level Representation will need to be rewritten a bit to accommodate these changes. Also I think that Opcode 79 should be treated as a specific opcode, even though it's not listed in the jumptable, it has a special function which is apparent by the checking if(opcode == 79) in the default segment of that jumptable. --Sacky

You have to note that in the 360 disassembly, the XLive protect opcodes (76, 77, 78) also result in the same action as of opcode 79. You'll also never see this opcode in any of the compiled scripts. Aru 14:54, 17 March 2009 (UTC)