Difference between revisions of "Talk:SCO"
Jump to navigation
Jump to search
(→Difference Between 'Local' variables and 'Global' variables) |
|||
| (7 intermediate revisions by 3 users not shown) | |||
| Line 10: | Line 10: | ||
::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? [[User:Sacky|Sacky]] | ::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? [[User:Sacky|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 [[SCO#Global_Variables|global variables container]]. [[User:Seemann|Seemann]] 15:10, 14 February 2009 (UTC) | :::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 [[SCO#Global_Variables|global variables container]]. [[User:Seemann|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? [[User:Aru|Aru]] 17:02, 24 February 2009 (UTC) | ||
| + | :Here's the list of opcodes {{U|listener}} made for his unreleased tool: | ||
| + | <div class="NavFrame collapsed"><div class="NavHead"></div><div class="NavContent"> | ||
| + | <pre> | ||
| + | 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</pre></div> | ||
| + | :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). [[User:Seemann|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. --[[User:Sacky|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. [[User:Aru|Aru]] 14:54, 17 March 2009 (UTC) | ||
Latest revision as of 02:37, 11 April 2009
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
- 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)
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)
- 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
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)
