§ ¶Eight general purpose registers on x86

An x86 CPU has eight main registers in its scalar register file in 32-bit mode: EAX, EBX, ECX, EDX, ESI, EDI, EBP, and ESP. All of these have various special uses, but of them, the eighth, ESP, has the most special status as the stack pointer.

I did say [i]eight[/i] general purpose registers.

It is possible, in some cases, to temporarily reuse ESP as a general purpose register. Since the x86 architecture is so register-starved, adding an eighth register can eliminate the need to spill variables to memory and boost the speed of a critical inner loop. I've used this in a couple of places in VirtualDub when I really needed it, and some have asked if it is actually safe to do this. The answer is yes.

§ ¶68000 assembly language

Nostalgia alert.

I've been writing 80386 assembly language for about ten years now, and I've gotten rather used to it -- enough, at least, to write some fairly long assembly language fragments for some obscure video program. 80386 assembly has a lot of goofy syntax and instruction set idiosyncracies, and it's almost the ugliest and nastiest assembly language I know, second only to 8086 real mode. It probably didn't help that I had the joy of learning the latter with the original IBM Macro Assembler 1.00.

I know a couple of other assembly languages, too, such as 6502 -- of which my main abuses can be summed up with BIT $C030 -- and enough MIPS that I can squeak by when reading a PowerPC listing. My favorite assembly language of all time, however, is that of the MC68000. Not only was that the CPU on which I did most of my early major assembly language coding, but the assembly code is very readable, and the instruction set rather flexible.

§ ¶VirtualDub 1.6.12 released

VirtualDub 1.6.12 has been posted to SourceForge. It took a long time primarily because I spent a lot of time reworking the timing logic in the capture module and going back and forth with some users who were willing to test internal builds with varying balances of breakage and functionality. Special props go to the users with handles Moitah and i4004 on the forums, who graciously spent a lot of time telling me that my resynchronizer sucked and that giving me hard data as to what was going on. Because the resynchronizer was quite heavily reworked, and because I sneaked in several features, both capture and non-capture, this build is marked as experimental.

One notable feature that I snuck into this build is that you can now capture from a DV capture device that uses the MSDV driver through DirectShow. Previously this didn't work because DV data comes in as type MEDIATYPE_Interleaved rather than separate MEDIATYPE_Video and MEDIATYPE_Audio streams; I don't own a DV camcorder, and the scenery around me is far too boring to warrant me getting one, so I didn't have a way to look at the filter graph and fix this. Well, as luck would have it, when I visited my older brother John over the holidays I was able to scam^H^H^Hborrow some time with his DV camcorder to develop against and add the code to insert the DV splitter into the graph. It isn't terribly tested (implementation and testing time approx. one hour), you can't shuttle the tape or control via timecode, and it only records type-2 DVs, but it's a little better than before, at least.

§ ¶Data Execution Prevention (DEP) related crashes

A few users have reported to me that they're getting crashes in VirtualDub when opening the video compression dialog or when opening an AVI file, the crash diagnosis is Access Violation, and the highlighted line in the advanced crash view looks like this:

01671710: 8b442408        mov    eax, [esp+08]      <-- FAULT

At first I thought this was an overclocking related crash, because it's a virtual impossibility for ESP to be invalid and for exception handlers to still fire. It wasn't until I saw this line that I realized what was going on:

Windows 5.1 (Windows XP build 2600) [Service Pack 2]

The crash was occurring because the video codec was attempting to execute dynamically generated code in a memory block that wasn't marked as executable, and crashed due to Data Execution Prevention (DEP) in XPSP2. Both dumps I received implicated PICVideo MJPEG 2.1 (pvmjpg21.dll), but there may be other codecs that have this problem (probably due to "protection" or compression wrappers). Turning DEP off will temporarily work around the problem, but if this is happening to you I highly recommend checking with the vendor for an update. I was not able to reproduce this problem with the latest version of PICVideo MJPEG v3.

§ ¶Wikipedia and AVI fractions

There seems to have been a number of attacks on Wikipedia lately with regard to the credibility of its articles. Personally, I think Wikipedia deserves a lot of credit for the quality of its articles despite the problems inherent in allowing public posting and editing. Some classes of articles I would definitely not trust without double-checking sources; I'm betting that the article on George W. Bush will be either still protected or in an edit war when I die. With regard to science and math articles, however, Wikipedia tends to be a very excellent starting source. Sometimes when I get bored, I start digging around the Internet for information on the most random of topics, and frankly, Wikipedia can give me the most convenient and densest amount of reasonably correct information on polystyrene in short notice.

My main problem with Wikipedia now is that it doesn't have a convenient offline form; it was really annoying when I was without Internet for a couple of days and couldn't get to the continued fractions page that I had forgotten to locally save. It's possible to download the database dumps and import them into a local Mediawiki, but that seems like a lot of work. Personally, I'd love to pay the Wikimedia Foundation for a personal dump of the pages on a DVD, but I know that some contributors are upset with some potential plans for doing so.

Another good example of Wikipedia's helpfulness would be how to handle fractions.

The AVI format stores the sample rate for all streams in rational form — that is, as the ratio of two 32-bit unsigned integers. This means that a number of frame rates that would otherwise be inaccurately stored as a single integer can be stored exactly, most notably the annoying 30000/1001 frame rate of NTSC video. The need to manipulate fractions, however, necessitates arithmetic routines that are a bit more complicated than the standard scalar routines. Everyone knows the rules for handling basic fraction multiplication and division, but there are some corner cases that require much nastier algorithms to solve. I noted this in passing on one of my earlier blog entries, and a reader helpfully pointed me to the Wikipedia article for continued fractions, of which I had never heard before but offered a direct solution to the problem.