2016-04-09 - Why Comment

Commenting code is one of those things that seems simple at first but turns out to be rather complicated. Write too few comments and it's hard for people to understand the code. Write too many comments and it's equally hard because it's difficult to see the code through the comments.

I think the answer is in determining what information isn't already being provided by the code. Variable names tell you what information is being worked with. Operations and function names tell you how those variables are going to change. Because the code is meant to tell the computer what to do it's also good at telling the reader what it's doing. The only thing missing is why. Why are you calling this function with these arguments? Why did you implement that algorithm a certain way? Why aren't you using this feature of the language? As much as possible you want your code to tell the reader everything they need to know but comments can be added to fill in gaps. They help to explain to future people reading the code why you did certain things a certain way if it's not obvious.

The same goes for documenting your own classes and functions. The class name, methods, and fields should tell you a lot about what the class if for. Similarly a function name, parameters, and return type can tell you what it will do. Again the only thing missing is why. Why would I want to use this class instead of another? Why would I want to call this function? That information can be put in comments on the class or function. Then people thinking about using that class or function can understand the scenario it's meant for and decide if it meets their needs or not.

2016-03-29 - In IL: Instructions and the Stack

So now that we’ve learned where local variables are stored it’s time to learn what we can do with them. In most high level languages you write a series of symbols which indicate what you want to happen with each symbol implying the action they represent. In IL you have a series of instruction and their arguments with the name of each instruction implying the action it will perform. Before we get to instructions though we need to understand stacks.

A Stack is a data structure that can be imagined as a pile of things. You can “push” things onto the top of the pile or “pop” things off of the top of the pile. Depending on the implementation you may also be able to look at things on the top of the pile without removing them. In IL every method has an Evaluation Stack. Most instructions pop things from this stack, push things onto this stack, or both. The stack is used to store temporary values similar to how registers work in some computer processors.

There are a bunch of instructions in IL so I will start by summarizing some of the common ones.

nop (No OPeration)

Used to fill up space for various uses. Such as allowing instructions to be patched in later.

ldc (LoaD Constant)

Pushes a value, determined by the instruction or its argument, onto the stack.

ldstr (LoaD STRing)

Pushes a reference to a string onto the stack

<T> represents a metadata token. These are 4-byte values that indicate a location where the actual data is stored in the file containing the code.

ldloc (LoaD LOCal variable)

Push the value of a local variable onto the stack.

conv (CONVersion)

Pops a value off of the stack, converts it to the type based on the specific instruction used and pushes the result onto the stack.

box

Pops a value-type value off of the stack, boxes it as the specified reference type and pushes the result onto the stack.

stloc (SeT LOCal variable)

Pops a value off of the stack and sets it as the value of a local variable.

add (ADDition), sub (SUBtraction), mul (MULtiplication), div (DIVision)

Pops two values off of the stack and pushes the result of the specified action onto the stack. How the action is performed and the type returned depends on the types of the values.

call

Used to call a method based on the argument to the instruction. The method pops its parameters off of the stack, if any, and pushes its return value onto the stack, if it has one.

ret (RETurn)

Returns from a method. Uses the value on the stack as the return value. The stack should be empty except for this value. If the method doesn't return a value then the stack should be completely empty.

Next time we will see some of these instructions in action.

2016-03-05 - Wire Entropy

One of the most annoying things about dealing with computers is all the wires. They seem to just wrap themselves around each other until you end up with a tangled mess. Well that phenomenon can be explained by entropy. Entropy is a complicated thermodynamic quantity but it can be generalized as a measure of how chaotic a system is.

When you first arrange wires they are very neat and tidy. This is a low entropy or ordered arrangement because the specific arrangement of the parts is very important to the overall state. There are a limited number of arrangements that can be considered “neat” and “tidy”. Wires being tangled up is a high entropy or chaotic arrangement because the arrangement of the parts isn’t very important to the overall state. There are a large number of arrangements that can be considered “tangled”.

The Second Law of Thermodynamics states that the entropy of a system can never decrease without work being done to it. This means that wires won’t straighten themselves out unless someone or something forces them to. The problem is there’s no law saying entropy can’t increase. As you bump your desk, as you pull on the wires, as the world turns they are being jostled about. These small forces tend to be rather random so they can’t really be thought of as directed work. So according to the laws of physics these small forces can’t straighten out the wires and can only tangle them.

And that’s the universe for you.

2016-02-13 - In IL: Variables in Visual Basic .NET

Last time we looked at how variables were defined in the IL generated by compiling a C# program. Now we will do the same with a Visual Basic .NET (VB) program and see what changes. Let’s start with a VB program that does the same thing as the C# program.

This program is functionally the same as the C# version. It declares a bunch of variables and then prints their string representation to the screen. There's a few syntax differences though such as how variables are declared, the lack less semicolons and curly braces, having to cast the string to a character using c. So let’s see what the compiled IL looks like.

That looks almost identical to the compiled C# program from last except for the added STAThreadAttribute line. But how can that be? These are two completely different programs in two completely different languages? Well it’s because they aren’t completely different programs. The actual operations being performed are identical so it makes sense that the IL generated would be the same.

IL captures the semantics of the code used to generate it not the syntax. The code to perform a specific operation could be completely different in two different languages but if those operations are meant to do the same thing then the IL generated will be similar. In the same way different languages could have features that look the same but work very differently which would generate different IL. The set of IL features is typically larger than the requirements of any single language to allow for a wide variety of language targeting the CLI.

Next time we will learn about stacks and operations.

15 16 17 18 19