GrantRi's WebLog [MS] : Work

Remodel Marches On

grantri — Thu, 16 Jun 2005 06:59:01 GMT

Well, my house is half torn apart and the new parts are about half-built. There's not much to talk about here at work, as we're busy finishing off the last few bugs and getting everything up to snuff. The question in my mind is which will finish first, my house or Whidbey...

--Grant

I've run out of ideas again

grantri — Wed, 01 Dec 2004 20:48:00 GMT

In case you haven't noticed, I've run out of ideas to write about. I'm sure there's still a few things I know that I haven't explained, btu I can't remember them...

If you've been dying to know something about the C# compiler, ALink, CLR file formats, 64-bit JITs, please ask,a nd I'll see what I can do.

--Grant

Good post on running/writing/compiling managed binaries as 32-bit or 64-bit

grantri — Fri, 15 Oct 2004 20:49:00 GMT

How the OS Loader will force .Net v1.0/1.1 executables to run under WOW64 on a 64-Bit Machine (http://blogs.msdn.com/joshwil/archive/2004/10/15/243019.aspx)

In General I think all of Josh's recent posts are worth a read.

--Grant

Some Clarifications

grantri — Wed, 15 Sep 2004 20:32:00 GMT

In my previous post The problem with being second, it seems like there was a lot of confusion. I'm going to attempt to clarify some of that. The heart of that post was meant to point out that people/developers don't always how close or far they are from a spec, until somebody else tries to implement the spec and they compare the two implementations.

#1 Although I was referring to the ECMA and all that it allowed as far as runtime/JIT optimizations, that's not exactly the same as what Microsoft will ship. As many of you pointed out, it would break way to much of existing code. I would personally argue that it was already broken and you just didn't know it yet, but that's an argument not worth having. Microsoft really does value backwards compatibility and thus we won't ship until we've figured out a way to not break customers (think about how many windows APIs maintain backwards compatibility so that old programs that relied on bugs still work, this will be just another example).

#2 A few people my have interpreted my statements about testers as somehow negative. It was not meant that way. This is my public apology to all testers. I was using testers as an example because they're our 'first' customers. They see our code and its results before anybody else. In general I think testers on compilers, JITs, and runtimes are very smart and technically adept to be able to understand, test and break this stuff. I can't speak for all teams, but the ones I've had experience with, the testers are a vital part of the development cycle, and I enjoy a good 2 way relationship with them, where they are my peers.

--Grant

[corrected some mis-spellings]

64bit versus 32bit

grantri — Tue, 07 Sep 2004 17:56:00 GMT

Please don't start a flame war over this. It is meant as more of a Dilbert-style post with just the slightest bit of real technical content.

64-bit machines are twice as fast as 32-bit machines because they have more bits.

Believe it or not there are still some people inside and outside Microsoft that believe this. They're probably the same folks that believe a 4GHz P4 is twice as fast as a 2GHz P4. Wouldn't it be nice if all that was really true?

I really do love my 64-bit machines. One of them I run with a 32-bit OS, the other with a 64-bit OS. They're both really fast at real world developer tasks despite their seemingly slow clocks. They're not twice as fast, but they might be if you figure out a way to factor in their inherent disadvantage: all the pointers are twice as big. Depending on your data structures, that could be a pretty big disadvantage.

--Grant

The problem with being second

grantri — Tue, 07 Sep 2004 17:00:00 GMT

First, hats off to the Mono team. I think they've done a great job at writing some great software, but also at proving that evil MS really does know how to produce a truly common language runtime that can be properly standardized and ported to other platforms and languages.

Now for the meat of my blog. Working on the AMD64 JIT for the runtime is really fun, but it has a few downsides. You we are the 'second' JIT that MS has written. As such the knee-jerk reaction of testers is not to consult the spec and see if what we're doing is different, but acceptable. Instead they blindly compare it to the first JIT (the x86 JIT) and if it's different and it breaks their test, it must be wrong. As we all know, 2 different implementations of the same spec are going to behave differently.

The biggest difference I see is that the AMD64 JIT has borrowed a lot of code and optimizations from the native AMD64 compiler. Because of this, we perform some optimizations that are 100% legal according to the CLR spec, but that are certainly unexpected by those who have been using the x86 JIT for a while. Almost all of these examples stem from end users not writing proper thread safe code.

Here's a real example from System.Collections.Hashtable:

private bucket[] buckets;

public virtual bool ContainsKey(Object key) { if (key == null) { throw new ArgumentNullException("key", Environment.GetResourceString("ArgumentNull_Key")); }

uint seed; uint incr; // Take a snapshot of buckets, in case another thread resizes table bucket[] lbuckets = buckets; uint hashcode = InitHash(key, lbuckets.Length, out seed, out incr); int ntry = 0; bucket b; int bucketNumber = (int) (seed % (uint)lbuckets.Length); do { b = lbuckets[bucketNumber]; if (b.key == null) { return false; } if (((b.hash_coll & 0x7FFFFFFF) == hashcode) && KeyEquals (b.key, key)) return true; bucketNumber = (int) (((long)bucketNumber + incr)% (uint)lbuckets.Length); } while (b.hash_coll < 0 && ++ntry < lbuckets.Length); return false; }

I added the emphasis. Notice the comment that indicates the code is assuming that this.buckets will change on another thread. With the x86 JIT, simply copying the member into a local was enough. However, the AMD64 JIT applied some simple copy-propagation to this code and realized that since the this pointer was already enregistered, it was easy to access this.buckets as a simple indirection. So the AMD64 JIT completely ignores the local copy. At this point some of you might be thinking that was an illegal optimization. It's not. Go read the specs and study your compiler theory.

There is exactly one thing needed to correct this method. Its the volatile keyword. By simply marking the buckets member as being volatile, then the JIT cannot add or remove reads or writes to it, thus it cannot copy-prop.

As a side note, I believe this code really is fine even if the buckets array does get bigger on another thread. It would only have a problem it buckets got smaller after bucketNumber was calculated, but before it was used to index into the array. Don't quote me on this, but I vaguely remember that Hashtable never does resize smaller, so this really is a total non-issue, but still a good example.

--Grant

Shameless Plug

grantri — Thu, 12 Aug 2004 18:46:00 GMT

Personally I think the MS marketing team really did rop the ball. They we're so busy promoting .NET that when VC 7.0 (aka 2002) and VC 7.1 (2003) shipped they forgot to mention all the tons of cool purely-native improvements in the product. Well now in Whidbey (8.0 Beta 1 is availible for download), they've finally got the right idea. Yes, we're still doing a lot of cool .NET stuff for C++ (so you can play with the hardware and enjoy a garbage collector), but we're also taking some time to mention all the other stuff that's been done: better standards conformance, better native code-gen, support for the latest instruction sets and processors, more secure CRT APIs, jsut to name a few.

Anyway, some people in the VC org have put together an online chat where you ask real MS workers about the next version of VC!

Online Chat: Visual C++ 2005 Beta

Join the Visual C++ team to discuss your questions and comments on the Beta
release of Visual C++ 2005. Whether you are a first-time user of the Visual
C++ Express Edition Beta (http://lab.msdn.microsoft.com/express/visualc) or
an experienced developer exploring the full Visual Studio 2005 suite, we
want to answer your questions to provide you with a smooth development
experience. So please bring your questions and issues to our attention and
get the answers you need from the Visual C++ team.

August 19, 2004
12:00 - 1:00 P.M. Pacific time
3:00 - 4:00 P.M. Eastern time
19:00 - 20:00 GMT

Chat time for cities world-wide:
http://www.timeanddate.com/worldclock/fixedtime.html?day=19&month=8&year=2004&hour=12&min=0&sec=0&p1=234&sort=1

To add this chat to you calendar:
http://msdn.microsoft.com/chats/outlook_reminders/MSDN_VC2005B_Aug19_04.ics

For more info on MSDN chats, including other upcoming developer chats, chat
archives, and other info see http://www.msdn.microsoft.com/chats

--Grant

Trade-offs

grantri — Thu, 05 Aug 2004 17:16:00 GMT

It seems like a lot of the time we (as software developers) are forced to make trade-offs. Choosing between 2 algorithms that solve the same problem, but with different characteristics. Sometimes it's an easy choice: option #1 is O(1) and option #2 is O(n^3). Sometimes we're forced to compare apples and oranges: option #1 runs as O(1), but uses memory as O(n^2) and option #2 runs as O(n) and uses memory as O(n).

The thing I've been pondering lately is if we should be always striving to make the best trade-offs, or if we should we be redefining the problems so that it's always an easy choice?

The current problem I struggling with in the compiler space is accuracy versus effeciency. Specifically in the case of exceptional flow control. Everbody would love a compiler that modelled the control flow of exceptions smartly enough to be able to do really advanced optimizations (dead-store, common sub-expression elimination, constant propigation, SSA, etc.) across try/catch/finally blocks (and of course get it right). However properly modelling such flow often results in some very comples flow graphs that tend kill the throughput of most optimizers especially if the algorithms happens to be O(n) or greater where n is the number of edges.

So basically we're looking at several ideas that are 'accurate enough' to do al of the desired optimizations while still not bloating the flow graph with a large number of edges that would slow down those optimizations. Of course even in that statement, we need to clearly define what 'accurate enough' is and how fast is fast. Thos terms change greatly between different compilers (JIT, pre-JIT, stand-alone compiler, etc.)

--Grant

Why doesn't the C# compiler accept /resource:*.resources?

grantri — Mon, 19 Jul 2004 20:39:00 GMT

Well, here I am finally getting back to this.

In my previous post on resources, I glossed over one issue. Not all managed resources are exactly what they seem. Specifically at the metadata/compiler level, there is a table that simply points to the resource and gives it a name. This is very similar to how Win32 native resources work. A lot of managed code assumes that data stored there is a .resources file. There is actually a magic cookie value that is at the very beginning of the header for .resources files, but that's not exactly a guarantee that what follows really is a .resources file. That is why the compiler and ALink allow you to embed anything you want as a resource. Likewise Assembly.GetManifestResourceStream, returns just a stream. You have to know what data is in the stream.

As a side note, given this architecture, it seems like the metadata for 'managed' resources adds no value over the existing native Win32 resource format. So it seems like another case of NIH.

Way back before we actually had a good idea of what an assembly was (and before we had any tools that created them) the frameworks team just used raw .resources files sitting on the disk in the application directory. When they moved over to real assemblies, they decided to keep the same naming scheme. This led the compiler team (well basically just me) to come up with the novel idea of using the resource's filename as the default name for the resource. That way they didn't have to type the filename twice.

The problem here is that we weren't thinking about the big picture and how this would look to an end user who hadn't seen the intermediate steps. As a convention most people name their source files according to the class inside it. Thus it would make sense to name a .resource file after the resources inside it, but that doesn't mean we should default it. In fact if I were to do it all over again I would make 2 big changes:

Never default the name, always make it explicit. However, place the name of the resources somehow in the .resources and .resx file itself, rather than on the command-line. Then the designers could do proper code-spit without relying on things like the default namespace or the hidden correlation between the class name and the .resources name. Also we wouldn't have to have a long ugly command-line option to specify the name.
Get rid of the metadata for managed resources, and just use native Win32 resources. Yes the .resources file would still be embedded in the .rsrc section, but we wouldn't need all new tools and APIs to deal with managed resources versus native resources. You also wouldn't have ugly discrepancies like when you set the icon for your main form, but forget to set it as the application icon (which gets it into the Win32 resources, which is where the OS/shell looks).

I still think it would be possible to have managed resource embedded into the .rsrc section, but since they store things in different formats (like icons) it wouldn't help much.

Basically given the fact that I wanted resource names to be explicit, thats the main reason I pushed for not allowing wildcards. There was also the confusion about whether wildcards should be applied recursively. So I guess the end result was that nobody foresaw a huge customer demand, and the few people that cared (like me) seemed moderately opposed.

--Grant

Alignment

grantri — Wed, 14 Jul 2004 22:04:00 GMT

I've seen this come up in conversations a few times so I thought others might be interested in it too.

First off, I think since the large majority of us use x86-based processors we forget that one day in our CS or EE class where they talked about alignment. So technically this should just be a refresher course. The reason it needs refreshing is because x86 is letting it's market dominance slip and more and more of us are wanting our apps to run on other processors. Also remember that most of this doesn't apply to managed code, but some of it does, so don't just stop reading because you use C# and or VB and never use pointers.

From here on out I'm going to use ARM-based chips as my example just because I know the most about them.

What is Alignment?

The easiest way to think of it is that all of your computer's memory is just one big array of a given type (starting at address 0), and thus every time you read or write memory, you're just reading or writing from the array. In the case of 32-bit integers, this means that you'll never need the lower order 2 bits of any address because they'll always be zero. In the case of 64-bit integers, the low order 3 bits will always be zero. The reason for this lies all the way down at the CPU level.

Many (maybe even all) CPUs offer instructions to load difference sized values from a memory address into a register. For ARM-based chips this is ld (for load dword, 4 bytes), lh (load half-word, 2 bytes), lb (load byte). The ARM CPU further restricts that the address used for the loads must be properly aligned according to the data being loaded. For DWORDs, the address must be 4-byte aligned (the low-order 2 buts must be 0), for WORDs it must be 2-byte aligned (the low-order bit must be 0), etc. If the address is not properly aligned, the CPU will throw and exception (similar to how fp-exceptions occur or divide-by-zero, etc.). My best guess for why they do it is because they want to make sure that all 4 bytes of a DWORD are in the same page, or something to do with the memory bus, etc. Consider loading a DWORD from 0xFFFFFFFE: Byte 0 is at 0xFFFFFFFE, Byte 1 is at 0xFFFFFFFF, Byte 2 is at 0x00000000, and Byte 3 is at 0x00000001!

Why is Alignment Important?

The short answer is that if you violate alignment your application will get an exception if you run it on just about any other CPU besides x86. This includes PocketPCs, a ton of WindowsCE devices, IA64-based machines, etc. Now for the interesting part: even on x86 alignment matters. Several of the MMX, SSE, and SSE/2 instructions perform significantly better if the memory addresses involved are properly aligned, and some of them will even raise exceptions in certain modes!

So how to 'Align' everything?

The easiest way is to just not fool with the compiler/OS. The compiler will automatically layout locals and parameters on properly aligned addresses. The same goes for malloc, realloc, new, etc. The problem arises when you allocate one thing, but then treat it like something else. The simple case is that you allocate an array of 2 shorts (16-bit integers), and then cast it to a pointer to an int (32-bit integer). Here you are playing Russian Roulette and have a 50% chance of getting an alignment fault. The reason is that any even address is properly aligned for shorts, but only half of those addresses are properly aligned for ints. Some memory allocators try to help by always aligning everything to the maximum alignment, but that needlessly wastes memory.

If you do need to treat something as 2 different types, then create a union so the compiler knows about it. Then the compiler will always align it to the maximum alignment needed for any of the union members.

The other big way to unalign something is to override the compiler's default layout mechanism. In C# this is done using LayoutKind.Explicit, in C++ it's done by anything that messes with the default packing size (#pragma pack and related). When you do this the compiler/OS will properly align the start of the struct, but you are responsible for making sure that the interior members are properly aligned. Example:

struct MisAligned {
byte someValue;
int someOtherValue;
};

By default someValue will be at offset 0, and someOtherValue will be at offset 4. Yes, that 'wastes' 3 bytes for each MisAligned struct, but that often isn't a big deal. If you mess with the packing size, like set it down to 1, someOtherValue will be at offset 1. This means that someOtherValue will always be at an odd offset and thus always cause an alignment fault!

So the rule is don't mess with how the compiler lays out fields in a struct. If you need to pack more data into less space, re-arrange the data so the compiler doesn't have to waste space on padding. The easiest way to do this is to always organize your fields according to size: largest to smallest. For C++ this applies to classes and structs. For managed code (C# and VB) this really only applies to structs. The reason is that classes default to LayoutKind.Auto which means that the runtime is free to reorder the fields within the type. The runtime currently orders fields to get minimal padding.

What if I have to have unaligned data?

Well, needless to say there are situations where data is going to be unaligned. The most common case is reading stuff off of disk or networks where data has been tightly packed. For C++ you simply need to declare pointers using the UNALIGNED macro (like int UNALIGNED * pui). Then when the compiler generates code to dereference this pointer it will generate code to do the right thing and not cause an alignment fault even if the address is not properly aligned.

At this point one might ask why aren't all pointers marked as UNALIGNED? The short answer is that it's slower. Some CPUs help by having unaligned variants of all load and store instructions. These variants are generally slower than their aligned counter parts but not too bad (if you want to find out how bad find a PocketPC and run some tests, but remember this is entirely CPU dependent). Other CPUs force the compiler to just generate a byte-by-byte load or store and possibly waste several registers in the process (sort of like a memcpy from a register to memory). This I think is the slowest, but again it is entirely architecture dependent.

It is a macro so that your code is more portable. On alignment sensitive architectures, it is defined to be __unaligned, otherwise it is just ignored.

MSIL took a different approach. Instead of decorating a pointer, it modifies the actual load or store opcodes with an unaligned opcode prefix. This prefix instructs the JIT/runtime to generate the proper code just like the native compiler does for the UNALIGNED macro. Unfortunately the C# language designers chose not to complicate the C# language in any way to expose this. So if you want to load or store unaligned data in C# you'll have to use something else (there was talk about adding helper routines to mscorlib.dll to do the unaligned load or store), or manually do the byte-by-byte load or store.

Here's a good random link with more docs on the subject.

Hope you enjoyed the reading, and possibly learned a few things.

--Grant

Command-line Trivia

grantri — Thu, 08 Jul 2004 17:52:00 GMT

So many people have wondered why the C# compiler isn't smarter about some of it's command-line arguments. Here's a summary of the type of questions I hope to answer in this post:

Why doesn't the C# compiler accept /reference:*.dll?
Why doesn't the C# compiler accept /addmodule:*.*?
Why doesn't the C# compiler just automatically add all the dependencies? Or if I'm only using a.dll, why do I have to reference b.dll?
Why do I have to add /reference:MyAssembly.dll, but not /reference:System.dll
Why doesn't the C# compiler accept /resource:*.resources?

Basically it's because of our premise that our developers/users are smart and don't like too much black magic going on under the covers. We thought that developers would always want to know exactly what their dependencies are. By forcing you to put each dependency on the command-line you have to think up front what your dependencies are. Wild-cards do not help that.

The second issue arises from lookup rules. In the native world, C/C++ programmers use the LIB environment variable to tell the linker where to go looking for LIB files (The C# compiler also uses the environment variable to find references). Classic VB users would just open the add component dialog box, which basically walked HKEY_CLASSES_ROOT for all registered COM/ActiveX type libraries, objects and interfaces. The down-side to the VB model was that developers often had no way of knowing which components he or she had rights to redistribute. So that is one reason why the C# compiler never looks in the GAC for references. Our model is “GAC is for runtime, use someplace else for compile-time“. That's why the framework SDK installs assemblies like System.dll into 2 places: the GAC for runtime and the SDK directory for compile-time.

Does anybody really fully understand fusion's complicated lookup/binding rules? Especially when you throw in machine, user, application and publisher policy? I don't. Every time they're explained to me, they all seem to have good reasons and make sense for applications, but not for developers. Instead we went with a classical path-based lookup. MSDN clearly explains which directories the compiler will search and in what order in this article.

As far as assembly dependencies go the compiler possibly could do better, but it would end up having rules very similar to fusion. The simplest problem is that there is no guaranteed relationship between an assembly name and the actual file name for that assembly. I think that's one reason why fusion has such complex rules. Thus to look up second order dependencies the compiler would either need to rely on fusion (which we already decided was bad) or put in some black magic of our own. The decision was to put the developer in change and force them to declare exactly which files to use as dependencies.

For module dependencies it gets even harder. With module dependencies I suppose we could do slightly better. However multi-file assemblies are extremely rare and the metadata doesn't help us out as much as we'd like. Now unlike assembly references, module references actually contain the filename. The problem arises because the ModuleRef table also stores other stuff, like all the filenames from DllImportAttributes. Thus there's no easy way to determine the difference between a dependent managed module and a native dependency that's not part of the assembly (like kernel32.dll for instance). Also when building an assembly it is possible that not all the modules will be referenced. So again we decided to put the programmer in change and make you explicitly list all of them.

Many of you have noticed that you never need to explicitly reference Microsoft assemblies like mscorlib.dll or System.dll. The main reason I guess is because we're self-centered. Well I guess not completely because we do have some almost good reasons.

First I'll get to mscorlib.dll. In case you haven't noticed there a few types the compiler just needs regardless of what you're compiling. These include (this is by no means a complete list) System.Int32, System.Object, System.String, System.Delegate, System.Enum, etc. All of these are in mscorlib.dll. Because these always have to be there, everybody (except those actually building mscorlib.dll) need to reference mscorlib.dll, so the compiler tries to save you a little redundancy by always implicitly referencing mscorlib.dll. If you don't want it, you have to turn it off with /nostdlib.

Now for System.dll and it's friends. Here is where i think we might have gone a little overboard. Even though we wanted you the developer to have total control of your dependencies, it became a little unwieldy to compile simple winforms apps from the command-line. At one point we had up-wards of 40 different assemblies you needed to reference! Since we already had response files we thought we make a 'default' response file that just referenced all of those assemblies, since everybody wants them (sarcasm intended). So we created a default response file that always gets used in every command-line compilation unless turned off with /noconfig. Please go look in your runtime directory right now at csc.rsp (it's right next to csc.exe). Please take some time to edit it to suite your needs, it can save you a lot of typing! Go ahead and add you favorite references, and remove the ones you don't want. Also feel free to add flags to adjust the default command-line options. You can always override them by using the opposite flag on the actual command-line.

The resources question is just going to have to wait for another day. I think it really is worthy of it's own post.

--Grant

Multi-file Assemblies: What and How

grantri — Wed, 07 Jul 2004 21:30:00 GMT

I intentionally left out the 'why' because only you as developer on your own product can decide why a given programming feature should or shouldn't be used.

First the easy part: What

Multi-file assemblies are simply assemblies that consist of more than one file. That begs the question of what is an assembly. Although I've seen several very amorphous descriptions of what an assembly is logically or theoretically, from my pragmatic compiler background I prefer to describe it how I see it literally. An assembly is a grouping of 1 or more files, where exactly one of those files contains an assembly manifest.

Now I know that there exists such things a native manifests, but in this case, I'm referring to the AssemblyDef record in normal metadata. If you run ildasm, it will be the details of the tree node named “MANIFEST”. There is a section that begins with “.assembly 'SomeName' { ... } “. That same manifest will also contain a list of FileDef records that list what other files physically constitute the assembly. The interesting tidbit here is that the files within the assembly that do not contain the manifest also do not contain any back-pointers to the assembly that they 'belong' to. Thus a single file can be a part of several different assemblies, but don't do it because it will cause tons of other problems down the road.

How:

There are several ways to create a multi-file assembly. None of them can be done inside the IDE with C# or VB.NET without special build rules or custom actions. (Yes C++ can do it inside the IDE). So from here on out I will assume everybody knows how to use the command-line tools.

First you need to build a file without an assembly manifest for C# and VB.NET just use “/target:module”. The next step is to include that module into an assembly. This is where things get a little tricky, and due to my lack of complete knowledge, I'll limit myself to C#. First of all there is no tool that MS sells that will allow you to modify an assembly once it has been built. There are type identity issues, code-signing issues, etc. You always need to save building the manifest file (the file that contains the assembly manifest) until the very last step. You can include an existing module into an assembly as you build it by simply adding “/addmodule:<module name>” to your command line. However the compiler is just plain not as efficient as it could be if you did things slightly differently.

Did you know the C# compiler allows you to produce multiple output files in a single compilation? It does. The gotcha is that it will only produce one assembly, so if you have multiple “/out” or “/target” switches on the same command-line, you're building a multi-file assembly! This is logically the same as doing the 2 step “/target:module” and then “/addmodule:”, except the compiler is slightly more efficient in some of the metadata.

If you're really desperate to show off your geek-ness, you can build a multi-file assembly using al.exe, but it's not worth it. See my previous post on why you should use csc.exe instead.

Why:

OK so I changed my mind, I will give you a few possible reasons for why you might want to use multi-file assemblies. Just remember though that these are just possible reasons. You still must think and decide for yourself in your situation!

Multi-language assemblies: this I think is the biggest possible reason. Maybe some of your programmers only know VB, maybe you need to interop with some old C/C++ code. The list goes on forever because there are an infinite number of reasons why you might want to write part of your application in different languages. Now you could put each language in its own assembly, but then you get stuck with a poor organization model, and the choice of making certain things public when they really shouldn't be and trying to compensate by using fancy security or obfuscation. As I pointed out in another post, this reason is going away (now you can have multi-language single-file assemblies)!

Incremental Download: back when we were still trying to figure out what exactly an assembly was, this was the poster-child example for multi-file assemblies. Now I think it was really more of a straw-man. Either way I'm not even sure we actually support it, but the original idea was that in a Internet or web-based application you would put the 'common-use' code in one file and the less-used code in another file. That way user that only needed MyReallySmallReallyFast90PercentCase functionality got it, and weren't punished with long download times for MyReallyBigAndSlow10PercentCase that few people needed. The app would download the small part, start running, and only download the other files (that contained the potentially bigger, and less frequently needed code) as needed. It seems like a great idea on paper, but now that more and more people have broadband, I seriously question its value.

Linked Resources: the idea here was that you had some file that was logically part of your assembly, but needed to be it's own file for some reason, possibly because some native API needed to read it and only accepted a file name argument. Possibly because the file was itself a native DLL. Possibly because you want the user to be able to modify it (like a splash screen bitmap or something). At one point in the design we even had a flag on the FileDef record indicating that a given file was 'modifiable'. I don't think that flag survived, and I know there's know way to set it with C#, VB, C++, or ALink. This I think actually has some merit, but it is definitely not common.

If you've got another good reason for multi-file assemblies, speak up, I'd love to hear about it.

--Grant

Exception Handling (Part 2 of 2)

grantri — Mon, 28 Jun 2004 17:46:00 GMT

Sorry it took so long to get to part 2.

First up is the unwind info (I think it's the .XDATA, but don't quote me). Basically there is a set of opcode sequences that are allowed in the prologue and epilogue, and there is some info in the describes what is happening in the prologue. The OS can read that data (the unwind info) and figure out what registers were saved, the frame size, if there's a frame pointer register, and how big the prologue is, etc. Each processor defines different things to store in the unwind info.

Second is the exception info (I think it's the .PDATA). This describes a bunch or ranges: the range of protected code (usually called a try body in high-level languages like C# or C++), the protector (the catch or finally body), a filter (like in VB.NET or SEH where you can have actual code executed to determine is a catch body is appropriate). There is also usually a spot reserved int he PDATA for language specific stuff to be passed to the personality routine.

So what happens when an exception is thrown? Well on x86 the OS just walks the 'linked-list' of exception information stored at FS:[0], and calls the personality routine or filters (I'm a little fuzzy here) to see if they want to 'catch' the exception. On IA64 and AMD64 the OS has to walk the .PDATA. Once the a handler is found the first pass has ended and a second pass begins. All stack frames between where the exception occurred and the handler are unwound. This is a joint effort between the OS and the personality routine. The personality routine is responsible for running things like destructors and finally clauses at each stack level (like when you have nested try/finally blocks). The OS does the physical unwinding by changing the stack pointer, frame pointer, instruction pointer, and restoring saved registers, accordingly. I have no clue how this works on x86, but for AMD64 and IA64, the OS reads the XDATA and figures out what to do (generally this is just undoing the prologue).

So the real point of all this was to see the differences. In the code, for x86 the entry of a try body results in pushing a new exception record pointer into FS:[0]. This is generally just 2 opcodes: one to store the existing pointer into the new record, and one change FS:[0] to point to the new record. The end of the try body is indicated by restoring FS:[0] to it's original value (popping the head off of the linked list).

For AMD64 and IA64 there is nothing in the code that indicates the start or end of a try body. This seems like it would be better. For the general case I think it is. The ugly part comes into play when the try body doesn't exit normally (you have a goto or leave from inside the try body to someplace other than the end of the try/catch or try/finally block). For x86 this just means you pop the exception record in more than one place, but for AMD64 and IA64 this means extra PDATA (and possibly XDATA). Since everything is range based, and there's no way to encode something like “everything in this range except the 5 sub-ranges”, you end up breaking the range into a bunch of smaller ranges and duplicating all the handler info.

Exception Handling (Part 1 of 2)

grantri — Tue, 22 Jun 2004 00:10:00 GMT

Anybody that done any programming on .NET has probably used some EH at least once or twice. It all seems pretty natural and straight forward. Well, I'm glad we can fool so many of you into thinking it's easy.

What follows is a gross-over-simplification of EH, but still useful if you know nothing about EH.

The short explanation is that the OS takes care of actually unwinding the stack, but relies on something called a 'Personality Routine' to determine what stuff to do at each stack level (like execute a finally, call a C++ destructor, etc.). For x86 the OS and personality routines rely on an exception record stack that is pointed to by FS:[0]. Well on IA64 and AMD64 (and a few other architectures), it's a little different. They are table based.

With the stack based approach you actually have instructions in your code that push and pop the exception state (like which finallys or catches to execute). These correlate very nicely with some of the semantics .NET has. The down side is that the pushing and popping seems rather inefficient, when simple static analysis can dictate what the EH stack would look like at any given point.

So then we have PDATA and XDATA. I don't know much about the exact difference (one is used more for unwinding info, the other more for exception info). The general idea is to have a bunch of tables that state at a given instruction address, here are the EH clauses that are in effect.

I relate all this because I've recently been working on a bug where in certain cases the wrong EH clause was being called. This was a direct result of put opcodes in the wrong protected region (or to state it differently, having the protected regions protect too much). This gets particularly interesting when you consider asynchronous EH (like ThreadAbortException).

Hopefully tomorrow, I can finish this off. Either way I think the real geeks will find this interesting.

--Grant

Am I really this popular?

grantri — Thu, 03 Jun 2004 23:10:00 GMT

I've noticed a lot of my links come from searches (primarily google). Is that because I'm actually answering a lot of releavant information that people want to know? Is it possibly because I happen to use all the magic keywords so that google pushes me to the top of its list?

--Grant