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.
2016-01-31 - C
The C programming language is really enjoyable to work with. It’s a nice simple language that does very little to get in your way but that also makes it a very error-prone language.
In C there’s a limited number of types and ways of interacting with those types. It is possible to define structs which wrap multiple bits of information and functions which wrap a series of operations but this is very limited compared to the object-oriented aspects of other languages. That being said it is possible to build these more complex systems out of what is provided. This is one of C greatest strengths. It provides a small easy to learn base that is powerful enough to support large complex systems being built on top of it.
This does have some potential for issues though. Because the complex systems have to be built from scratch there’s a large chance that mistakes can be made if the people building the complex system are not very careful. C is also not the kind of language that will catch these mistakes for you. Thus as you build the complex systems you also need to design things to catch and prevent mistakes.
This simplicity and lack of validation comes from C’s heritage as a language for making operating systems. If you are building the base system for controlling the computer it’s hard to rely on the things that those systems usually provide. C is basically just an abstraction of assembly and as suck It provides the same freedom to have the computer do whatever you want it to do. It was meant to make writing these low-level systems easier without limiting the programmers options.
I would describe C as a good experimental language. It’s very easy to quickly make a program that does something and in doing so gain a better understanding of how the computer works. It’s not something you really want to be building really complicated programs out of unless you really know what you are doing and need the freedom it provides.
2016-01-16 - In IL: Variables and Types
Variables are important to any program as they determine where information gets stored. Types are equally important as they determine the format of that information. So to start this investigation off we are going to look at how and where information is stored in an IL program. The following C# program declares a bunch of variables and then writes the string representation of those variables to the screen.
If you compile this program and then look at the generated IL code using ildasm or ilspy you will see something like the following (Note that you may need to compile it in debug mode to stop the compiler from optimizing out some variables).
Now there is a lot there but we are just interested in is how variables are declared so we are going to ignore most of it for now. Line 63 to 79 contains what we are interested in.
.locals is an IL directive that is used to declare the variables of a method. The init keyword indicates that these variables should be initialized to their default values. The declaration of local variables is very similar to how arrays are declared in many languages. It starts with a number in square brackets that denotes the variable’s index. Next there’s a type identifier which denotes the type of the variable. Finally there is the optional name of the variable. IL instructions reference variables either by their index or their name which gets translated to the index when the program is assembled.
If you look at the rest of the method you can see these indexes being used. For example on line 122 we see “ldloc.0” followed by “call void [mscorlib]System.Console::WriteLine(bool)”. In the C# code we call Console.WriteLine on line 27 and pass it a bool argument when we go to print the b variable. Looking in the locals array we see “[0] bool b” on line 63 which we know is the declaration of the b variable with index 0 and type bool. So “ldloc.0” is likely doing something with the b variable so that it can be printed by a call to Console.WriteLine.
Since the .locals directive contains the name of the variable it is fairly easy to map C# types to IL types. bool is bool, char is char, float32 is float, int64 is long etc. These types are built-in types that are inherently understood by the virtual machine. Some are more complicated though like the C# decimal type declared as “valuetype [mscorlib]System.Decimal” and ArrayList declared as “class [mscorlib]System.Collections.ArrayList”. These are user defined types described in assemblies that can be accessed by the virtual machine to look up their definition. Square brackets surround the name of the assembly in which the type is defined. Following the square brackets is the fully-qualified name (Includes but the name of the type and the namespace in which it is defined) of the type.
The types that start with “valuetype” are user defined value types. A value type variable directly contains the data of that variable. The types that start with “class” are user defined reference types. Reference types contain references to a location where the data of that variable is stored. A value type variable can be converted to a reference type variable through a process known as boxing. This involves copying the variable’s data to another location and then creating a reference type variable that references that location. Every value type has a corresponding reference type. The reverse is not generally the case.
The built-in types can also be classified as either value or reference types. The following table describes some of the built in types and specifies what kind of type they are.
| Built-in Type | Description | Kind |
|---|---|---|
| bool | True/false value | Value type |
| char | Unicode 16-bit char. | Value type |
| float32 | IEC 60559:1989 32-bit float | Value type |
| float64 | IEC 60559:1989 64-bit float | Value type |
| int8 | Signed 8-bit integer | Value type |
| int16 | Signed 16-bit integer | Value type |
| int32 | Signed 32-bit integer | Value type |
| int64 | Signed 64-bit integer | Value type |
| uint8 | Unsigned 8-bit integer | Value type |
| uint16 | Unsigned 16-bit integer | Value type |
| uint32 | Unsigned 32-bit integer | Value type |
| uint64 | Unsigned 64-bit integer | Value type |
| object | Base of all types | Reference Type |
| string | Unicode string | Reference Type |
Next time we will see how IL variables work with a Visual Basic .NET program.



![[Valid RSS]](/images/valid-rss-rogers.png)
