Talk:SCM Instruction

Article name

The name "opcode" does not seem fitting for a page that describes the actual SCM instruction format. While the introduction suggests that the page is about the opcode alone ("Each script instruction is represented by a number called opcode"), the rest simply describes the format of instructions along with their arguments. As such, I propose that either the page's title is changed to something like "Instruction" or "Script Instruction", or that another page be created for the non-opcode information (which seems silly, given how little there is to say about the opcode itself).

– Squ1dd13 (talk) 15:38, 17 August 2020 (UTC)

Agreed that this article covers more than opcodes. Not sure what name would fit there. It should be a clear distiction between instructions in 3D and HD eras. Maybe SCM Instruction. Seemann (talk) 05:35, 19 August 2020 (UTC)

SCM Instruction sounds like a good name. Should we rename the page then? I don't actually know how to do that. – Squ1dd13 (talk) 11:05, 19 August 2020 (UTC)

Cheers. I've changed the introduction so that it fits with the new title, so you might just wanna check if it's ok. – Squ1dd13 (talk) 17:10, 19 August 2020 (UTC)

We should somehow connect this page with SCM language (which is one of the languages that compile into SCM). Seemann (talk) 17:22, 19 August 2020 (UTC)

I think that if SCM language doesn't already link to this page somewhere, it should, but otherwise I think we should make sure it's obvious that there is a difference between the compiled SCM files and the languages that compile into them. My issue with SCM language is that it covers both the R* syntax and some details about compiled files, which I think ought to be kept separate. Whatever happens, I think this page should be independent (i.e. not part of a larger page). – Squ1dd13 (talk) 17:56, 19 August 2020 (UTC)

Format of value reading code

I notice that my edit was reverted with the following reason:

Reminder: this is not a personal wiki and be careful to not get rid of valid information (original terminology does matter too).

I'm willing to accept that I may have done something wrong, but I'm unsure as to what that was. My aim was to convert the code for reading argument values from almost plain C/C++ to something more abstract. It seems to me that code such as

value = SignExtend32(ReadInt16(Bytecode, PC))
PC += 2

is rather too implementation-specific and is also unnecessarily terse:

1. Does SignExtend32 help demonstrate the structure?

It appears to be an implementation detail that doesn't really help illustrate how someone might read the value from code. In many programming languages, this function call could be replaced with a cast or even nothing at all.

2. Does PC need to be PC rather than something equivalent but more accessible, such as programCounter?

It looks like this code has been taken from a larger codebase (although that's just a guess), so I can see why PC would be favoured there over something longer, since the variable would be used so much. However these are two or three line snippets, so I don't think there's a need to keep things short, especially when a longer name would be clearer. Sure, most readers are likely to know that PC would stand for "program counter", but why make things harder for the odd person who doesn't know that?

3. Is value the right name for variable offsets?

I get that the offsets are technically values, but when the description given is Global integer/floating-point variable, I think it would be possible for someone to interpret the variable name value as meaning "the value of the global integer/floating-point variable" rather than "the offset at which the value of the global integer/floating-point variable can be found". It is for this reason that I changed the name for the variable offsets.

I don't actually know what it was that caused my edit to be reverted, but I've written out these three points in case it was any of those.

I object to the suggestion that I'm treating this website as "a personal wiki": I'm just trying to help improve the article. I don't see how making edits amounts to treating this as my personal site.

As for "be careful to not get rid of valid information" and the suggestion that I changed terminology: I'm not sure what these comments are about. I was under the impression that I had simply changed the format of the information and only removed things that were not about the instruction format, such as SignExtend32. There may have been something I missed though, so I apologise if I removed something useful.

I'm only spending time writing this so I can better understand what I'm doing wrong here. Don't worry; I won't do this every time an edit gets reverted – only when I'm confused about the reasoning. I'm still quite new here, but I hope to keep contributing, so I want to learn how to go about that in the most constructive way possible.

– Squ1dd13 (talk) 19:34, 19 March 2021 (UTC)

First of all, you are disseminating the whole wiki with Go codes also as a replacement of the ones written in C/C++ and whatnot, hence the belief you are treating this as something personal. Secondly, although I can barely agree that only the backronym form of PC may reveal the real meaning to ill-informed programmers (reading N bytes and increasing the PC by N says it all, however), we can in no way omit what an implicit cast would do under the hood because pseudocodes are merely demos and are not typified in this particular instance. Thirdly and less importantly, value hasn't ever been used in place of a variable offset or index (check it out again and be aware locals are always pointed to by index unlike globals). – Wesser (talk) 03:07, 20 March 2021 (UTC)

Apologies for the value mistake; that was just me being stupid and misremembering what I had changed without looking at the diff. I'll leave things as they are now. However, I do have a few issues with your argument. I do not consider my code here as Go. I think what you must be picking up on as Go is just the := syntax which, as I'm sure you are aware, has been used in pseudocode since long before Go was around to mean declaration (rather than assignment). Besides, "disseminating the whole wiki with Go" seems like somewhat of an overstatement given that the only place where I've used Go (to my knowledge) is on SFX (SA), where there was no code before – only some brief structure descriptions which I translated to Go (for consistency) expanded on with more structures, before adding more code. I see no reason to dismiss that contribution as bad simply because of the choice of programming language. Even including my edit here as using Go would make only two total uses of Go – hardly "the whole wiki". I've seen no rule anywhere which mandates that code be in C or C++ (although there could be one somewhere that I have missed). I disagree about the point on casting, but there's not much point arguing about that further. Although I do disagree I can also understand what you're saying, so I will think a bit more about the value of my changes before making them in the future, because I'd rather not get into situations like this. – Squ1dd13 (talk) 14:21, 20 March 2021 (UTC)

You do know := serves as a facility to discriminate an assignment from an equality comparison and you do understand it has no utility whatsoever in our use-case, so I do not believe there is room for any kind of ambiguity. Indeed, Go is gaining popularity yearly but still that does not mean it is very well-known to the mass at present and thinking that its syntax would help more than the one of a pseudocode/structure (which is generic and can be translated to your likings) is just the result of your own preference. – Wesser (talk) 19:09, 20 March 2021 (UTC)

I actually did not know that about :=, but either way it's irrelevant. What you saw as Go was simply pseudocode which used the := syntax. Even if I had written it as Go, that is no reason to decide that the contribution is invalid. If there are no rules about what languages can be used, I should not have to use C/C++. Similarly, others should not have to follow my language choices, and I won't attempt to force them to (by means such as reverting their edits). I also notice that you are focusing solely on Go rather than on the content of my edit. My aim was to make the code more useful as a quick reference with a few small changes, so I think a more sensible discussion would revolve around why I did not (in your opinion) achieve that aim, rather than on my choice of language syntax. However, we're evidently going to get nowhere with this, so I am happy to finish this exchange here if you are. – Squ1dd13 (talk) 20:37, 20 March 2021 (UTC)

Let's put it like that: if you are willing to contribute by making things more descriptive and such you cannot take the advantage of an unusual syntax to show them off, that's incongruous. Nonetheless, you too have your reasons and I do apologise. In the effort to answer your replies I somehow forgot to enumerate the grounds for the decision I took to revert your changes (many of which I have already pointed out though):

• The need for a colon prior the equal sign was utterly unnecessary (resembling a Go-like assignment);
• The variable name bytes is far more vague than Bytecode;
• No need to expand the PC acronym as per R* naming (if one knows what an instruction pointer is, linking it with "Program Counter" comes naturally);
• The sign-extension assumes a cast and removing it was harmful (one may read a byte/word instead of a double-word in contrast with the runtime);
• Local variables are always accessed by index and not by offset like the global counterpart, so localVariableOffset is a wrong name as well as indexVariableOffset (global offset or local index);
• String literals are called text lables as being technically identifiers except for double-quoted strings (128 bytes long).

– Wesser (talk) 02:28, 21 March 2021 (UTC)

Ok, I can accept that these particular points are far more valid (and numerous) than mine, so it is fair that my edit was rolled back. I appreciate you taking the time to explain this in more depth. I'll make sure to do more research prior to committing changes next time. – Squ1dd13 (talk) 13:34, 21 March 2021 (UTC)