FreiK's WebLog

Quick note about x64 Tail call

2009-02-09T22:28:43Z

A coworker on the CLR dropped by recently, having hit a brick wall about some problem he was having with some ASM code for x64 that was trying to tail call. He has already grep’ed through the ABI docs, and had actually hit this blog prior to knocking on my door. The problem? How to emit a tail call through a register such that the OS unwinder doesn’t puke. The quick answer is to use a REX prefix extension on the JMP instruction. For those of you that know what you’re doing,...(read more)

What's in a title?

2008-06-03T23:50:00Z

My wife just asked "What's an 'after-sales engineer'?" I parsed the terms, and came up with "Tech Support Dude". As a teenager, I was a Foliage Architect (I mowed lawns), System Builder (computer assembly slave), Network Administrator (very poorly paid, local 'after sales engineer') and an Information Delivery Engineer (paper boy)....(read more)

The customer is wrong

2008-04-03T07:45:45Z

I just watched the highly lame “You wouldn’t steal a car…Downloading pirated movies is stealing ” ‘trailer’. How’s this for irony: I watched this trailer because it was the SECOND thing to play on the DVD of Die Hard 4 that I just purchased. The FIRST thing to play on this DVD was a menu that asked me what language I would like: English, Mandarin, Russian, and about 8 other languages that I had never heard of, or couldn’t read. The DVD cost me 7RMB...(read more)

Turning off comments for a while...

2008-02-18T22:31:00Z

The spam bots have been causing me all sorts of trouble - I had over 1000 messages informing me that some spam has been deleted over the weekend. I'm going to kill comments, and hope that in a few months, (after I get a chance to write up something of value), the spam bots will have stopped attempting to comment on my blog. In the mean time, if you want to ask me a question, my email address is the title of my blog [freik] except my first initial comes _before_ my last name] at m1cr0s0ft.c0m, except...(read more)

Vista x64 Media Center 'fix'

2007-09-07T19:52:00Z

<RETRACTION> Crap. After getting a couple of comments saying they tried the same thing, and it didn't work for them, I went back and tried it myself. And it turns out it doesn't work. I think I had tried it with some media that I had already transcoded to WMV without realizing it. The reason it doesn't work is actually quite simple: The managed assemblies aren't pure IL - they're IJW images (lame-speak for "they contain some native code") so they're hard-tied to the platform they're shipped...(read more)

How not to benchmark different languages

2007-06-11T22:41:00Z

I've recently been trolling the web for any sort of language-comparision benchmarks, to see how the CLR's JIT stacks up to the competition. Dr. Dobbs has what seemed to be a pretty reasonable micro-benchmark article. It's not particularly insightful, but hey, it is hard to come up with stuff that makes sense to compare across multiple disparate languages. I started looking for specific C# to Java comparisons and came upon this little gem. I'll give you a few minutes to read it.

Now that you've read it, I would like to challenge you to understand how anyone would ever believe the question of "How long does it take to do nothing 1 billion times" in any language is worth comparing. Seriously, ignore the thoughts regarding whether the comparison itself was fair or not. The best part of that article is that the Java JIT they seem to be pushing doesn't get rid of the empty loops in a newer version. Then look at their 'testing methodology' (or the lack thereof). Not only are they not actually benchmarking anything that anyone with a brain in their head would care about, but they didn't even bother to figure out how use the tools that they claim to be comparing against. Does anyone that actually uses C++* think that if they care about performance they're not going to enable the optimizer? Every reasonable C++ compiler on the planet will completely eliminate the loops if only told to optimize. And then the comparison against Assembly stuck in my craw. Assembly is there because you KNOW WHAT YOU'RE DOING!!!! If an assembly programmer writes a loop that iterates for a billion times, it's probably because they're trying to measure some particular pattern of code on the CPU they're running.

So (still snickering at the previous stuff), I guess I'm asking for input: Does anyone have any non-micro-benchmark relatively objective managed code comparison links they'd recommend? I'd really like to see how the CLR's JIT stacks up against some of the JVM's out there, for more than just little tiny toy code samples.

I'm also interested in 'end-to-end' timing, which includes JIT time. Microbenchmarks with internal clocks don't tell you how long something actually ran for. If a JIT takes 5 minutes to figure out it can remove 2 dead loops, your runtime isn't less than 1 second - it's less than 5 minutes and 1 second.

-Kev

* I found 4 different syntax errors in the C++ source code they provided...

Boost 1.34.0 and how to get it to build for AMD64...

2007-06-08T06:37:00Z

I've recently been deluged by a pile of new electronic gadgets* so that I haven't had time to do much coding. So I was looking around yesterday and found that there's (finally) a new version of Boost available. I was actually underwhelmed by the lack of interesting new libraries that have been added (there have been a number of interesting libraries approved, but the only one of the group that have been approved that I was anxious to use trivially was Xpressive - I might rip out "for each" from my source code to try BOOST_FOREACH instead, too). That aside, I immediately discovered that they removed support for BJam V1, and require BJam V2. It took me another 2 hours of digging to figure out how to build the 64 bit libraries with the new build system. Here's how you do it:

bjam toolset=msvc address-model=64 stage

And, voila - amd64 builds. For the discerning multi-proc engineer (most of us are now, right?) try adding a -j%NUMBER_OF_PROCESSORS% to that command line to use every CPU core your machine has [it builds quite quickly on my Core 2 Quad, and my 2x2 Opteron [faster on my Opteron, actually - the C++ compiler eats data cache for breakfast - I think the extra pipe to memory really helps].

And now, to explain the * above:

Over the past two or three months, I've splurged a lot on myself and/or my wife:

Sony HD-SR1 camcorder - Good video quality - shockingly better than my old JVC GZ-27, and significantly better than any of the MiniDV camcorders I've owned. AVCHD is less than a great post-processing experience, right now, though
Apple iPod Shuffle - Fabulous form factor, super-crappy software - one of the devs on my team said that I must be using it in a way that Steve Jobs doesn't, because that's the only way Apple tests their products. I would have waited to get a Creative Labs Stone for half the price, but it was a gift for my wife for her birthday, and the Stone wasn't yet available. Seriously, why do I need a $#@@ driver to use a %#@# flash device? To be fair with my complaints, the Zune does the same thing. Lame lame lame lame. Everyone else on the planet calls 'em USB storage devices, what is wrong with Apple and Microsoft?
Roku SoundBridge M500 - Great size, great audio quality, but it took forever for me to figure out that Windows Media Connect doesn't like to share audio files that are already on a network share. Once I migrated my music onto my media center, it actually navigated my 150+ Gigs of audio remarkably well, and handles lossless WMA like a champ!
Bose Companion 2 speakers - Fabulous audio quality, nice looking desing - attached to the SoundBridge in our master bathroom - All my wife needs now is a hot plate and she could live in the master bathroom
Final not-so-electronic not-so-gadget: Ellsworth Epiphany mountain bike, built up with most SRAM X.9 components. This thing climbs better than my 1997 GT aluminum hard tail. It's much bigger than my GT, but weighs about the same, and I have no idea what I'll do with those 27 gears. I think I only ever used 19 of the 21 available on my GT. I picked it up on Monday night at REI [wouldn't have bought it except for their nice little test track demonstrated that it really does have no weaknesses], I've ridden it to work 2 days [in the rain, but I really didn't care], and I'll be riding it this weekend (probably in the mud) Saturday and Sunday morning. St. Edwards park, and perhaps I'll go visit the Tape Worm in Renton.

How to use RtlUnwindEx

2007-03-15T18:24:00Z

Disclaimer: I've never actually written an unwind personality routine, so take what's here with a grain of salt.

A few days back, I spent 30 minutes defending the C++ runtime's exception handling personality routine to the guy that has the less than enviable job of supporting the .Net Framework's exception handling personality routine. The eventual point to be learned is that the documentation for RtlUnwindEx is abysmal, and can cause the VC 8.0 C++ runtime to leak objects left and right.

The problem revolves around the C++ team's decision (which I fully support) to cause code compiled with /EHs or /EHsc flags to only invoke destructors when a C++ exception occurs. This means that if you take a hardware exception, call RaiseException yourself, or call longjmp none of your C++ destructors between the point of exception and the handler will be invoked. I've talked about why this is a good idea, but I'll sum it up with this: If that scenario seems bad to you, then you should be compiling your code with /EHa.

Anyway, back to the issue: Say I'm writing a 'personality routine' which will be inovked by the OS when an exception occurs. If you're writing the kind that requires that your handler initiates the second phase of unwind, you need to call RtlUnwindEx. The documentation, which is arguably bad (it's little more that a function declaration), indicates that the EXCEPTION_RECORD structure to pass in is optional. And that's true: the functions on the stack will still be unwound. But the personality routines for those functions might want to actually know that they're being invoked due to an exception, and not for something like a longjmp. So, if you have an exception record that could be passed to the RtlUnwindEx function, you should. If you don't, another personality routine might assume that there's not an exception to examine, and might decide to do something like NOT invoke the destructors for the object on the stack.

BTW - this bug exists only on x86, and only when you're crossing a managed code -> native code boundary, in particularly weird scenarios. And I hope it's getting fixed :-)

-Kev

AMD64 unwind info gotchas

2007-03-12T20:34:00Z

I had a brief e-mail exchange with one of the devs on the optimizer team about a checkin he put up for review. He modified the compiler so that it only aligns the stack for functions that call other functions - that's the typical definition in compiler lingo of a 'leaf function'. My first response was "don't do that - you may still have to align for reasons A, B, & C". To which he responded with a quote from the ABI doc that explicitly says you only have to align the stack if you're calling a function. So I started reading. Turns out, he's right (and so is the doc), but there are some really nasty gotchas involved. When we initially did this stuff, we just lived with the scenario where you might be wasting a bit more stack space...

The theme of the problems revolve around restrictions on encoding information in the unwind data. If you are saving XMM registers and have an unaligned stack pointer, you must use the SAVE_XMM128_FAR opcode because the SAVE_XMM128 opcode will only accept offsets in multiples of 16 bytes. Or I guess you could use MOVUPS instead of MOVAPS to save & restore your XMM register, but I wouldn't recommend that on current hardware. Similarly, you have to use the ALLOC_LARGE descriptor for stack allocation of sizes that aren’t [n * 8 + 8]. ALLOC_LARGE actually has 2 variants - one that multiples by 8, and the other than doesn't. You can use the latter to allocate random amounts of data from the stack. But then if you want to use a frame pointer, you're going to be in a pretty weird spot, because it will have to be unaligned, as well. Unwind data dictates that you can only have a frame pointer that = RSP + 16 * [1-15].

I'll probably come back to this article & add some nice hyperlinks to ABI details in the doc itself, but it's been a while since I blogged anything useful, so I figured I'd just get this out there quickly.

New Job, SP1

2006-12-19T20:42:00Z

I recently switched from the lead of the Code Gen & Tools team for Visual C++ to the lead for the Code Gen team for the .Net Framework. I've not used managed code much, but for some classes of code, it sure does look easier to use [I'm working on a goofy GUI app for my personal use in C# that took me forever to do in C++]. There are lots of interesting problems to solve in this space, and a dramatically different set of customer constraints & potential customer scenarios. I have to admit the security concerns for a JIT in the ASP.NET world are a little bit unnerving...

In far more interesting news, VS 2005 SP1 just released. OK, it actually released a few days ago, but my power didn't come back on from our nasty storm Thursday night until Monday, so I was a bit preoccupied. I highly recommend picking this up if you're using the AMD64 compiler. We shipped an awful lot of compiler fixes, along with a few code quality improvements, in this release. You'll notice that prologues and epilogues of complex functions look much different, and that the compiler throughput (the amount of time it takes to compile a function) is a bit better. There are some severe bugs in the PGO scenario {Profile Guided Optimization} that anyone using this feature really needs. Aside from that, I hear that the VS experience is just much more pleasant than VS 2005 RTM. Go forth and Download!

Anyway, I'll try to get some more interesting blogs posts going in the future - work seems to have calmed down quite a bit, since Vista finally shipped.

Speaking in 'public'...

2006-10-18T06:35:00Z

I'll be hanging out with the cool kids at the Northwest C++ Users Group tomorrow night. If you're in the area, and want to heckle me, swing by. We'll be in building 40 at 6:30 PM. My talk starts at 7:00 PM. I'm talking about the actual runtime cost of exception handling for x64 and x86 on Windows.

Update:

Check out http://www.nwcpp.org/Meetings/2006/10.html for the slides, and a video of the talk, if you're interested. You can see my thinning hair in back, my marvelous posture, and my always entertaining speaking style.

Bug in x86 inline assembly to watch out for

2006-10-17T23:53:00Z

Imagine this very lame code:

int main() {}

void BugAsm() 
{
   __asm {
        MOV     [ESP+12],OFFSET main
   }
}

void(*BugAsmPt)()=&BugAsm; // this is just to make sure the function is not removed by /OPT:REF

Now imagine your significantly less lame code doing something similar.
Now imagine that the compiler crashes with a bizzare message about "x86\code.c" something or other.

Well, you can fix this problem by changing the assembly code to this:

mov DWORD PTR[esp+12], OFFSET main

Another unfixed bug, worked around :-|

-Kev

A more flexible array template [and the evolution of the idea]

2006-09-19T00:17:00Z

{Disclaimer - I started with a bunch of code from boost::array - it's a great implementation of the functionality it provides}

While my day job doesn't generally allow me to goof around with advanced C++ features, I still managed to find time to do so after the kids are in bed. Mark & I were talking about a new feature in C99: variable length arrays. They're incredibly useful for certain scenarios, and will, by most compilers I imagine, just get turned into an _alloca call. This led to a discussion of the value of variable sized arrays, and to categorize them. Here's the final result:

Type 1: Fixed size arrays: Easy to do in C, boost::array<T, N> does it for C++ with all the bells & whistles of an STL container [tr1 has something awfully similar]
Type 2: Variable length arrays: Hard to do in C, std::vector<T> does it for C++
Type 3: Variable sized arrays at construction time: Easy to do in C (malloc or _alloca always produce these), doesn't exist currently in either boost or STL

When we started comparing these things, we came to the conclusion that C99 style variable length arrays would be very useful. Using __forceinline and _alloca, you can produce an implementation that works for any scenario that stays in a single function scope. As soon as you start working across scopes, or try to implement something as a global, it falls to pieces. It also fails miserably if the compiler doesn't actually inline forceinline functions [which is the case for -Od, and anything with -Ob0]. And I don't have a very reliable way of detecting this scenario :-(

Ignoring the weaknesses, let's assume that the programmer is very intelligent and all-knowing, and will never accidentally abuse these routines. Here's an initial implementation (just the part that matters) that supports stack-based allocation of both Type 1 and Type 3 arrays:

public:
    array(std::size_t n = N) { BOOST_ASSERT(n == N); }
};

template<typename T>
class array<T, 0> : public impl::_common_array<T, array<T,0> > {
protected:
    friend impl::_common_array<T, array<T,0> >;
    T *elems;
public:
    __forceinline array(std::size_t s) : sz(s), elems((T*)_alloca(sizeof(T)*s)
    {
        for (size_t i = 0; i < s; i++)
            T *temp = new(&elems[i]) T;
    }
    ~array()
    {
        for (size_t i = 0; i < sz; i++)
            elems[i].~T();
    }
};

But I don't like allowing a programmer to shoot themselves in the foot accidentally (on purpose is fine :-)). First, I added some code so that we don't try stack-allocation for DEBUG code, since the inliner is rarely enabled for that scenario. Next I promoted a warning to an error so that if the routine ever doesn't get inlined, you'll fail. Finally, I declared a private operator new, so that you can't construct one of these things on the heap and really screw up the world:

template<class T>
class array<T, 0> : public impl::_common_array<T, array<T,0> > {
private:
    void *operator new(std::size_t sz);
protected:
    friend impl::_common_array<T, array<T,0> >;
    T *elems;
public:
#if defined(_DEBUG) || defined(DEBUG)

#pragma message("Using lame implementation")

    array(std::size_t sz) : sz(sz), elems(new T[sz])
    {}
    ~array() {delete[] elems;}

#elif !defined(NODEBUG) && !defined(NDEBUG) && !defined(_NODEBUG)

#pragma message("Be sure that your optimized build is NOT using -Ob0 - this completely disables inlining")
#pragma error("Please define DEBUG or _DEBUG for your debug build, and NODEBUG, NDEBUG or _NODEBUG for your optimizing build, otherwise, this code won't work!")

#else

#pragma message("Using good implementation")
#pragma warning(error:4714)
#pragma optimize("b1", on)
#pragma auto_inline(on)

    // If this thing doesn't get inlined, the code won't work - you'll need to use the previous blob of code instead
    __forceinline array(std::size_t sz) : sz(sz), elems((T*)_alloca(sizeof(T)*sz))
    {
        for (size_t i = 0; i < sz; i++)
        {
            T* temp = new(&elems[i]) T;
        }
    }
    ~array()
    {
        for (size_t i = 0; i < sz; i++)
            elems[i].~T();
    }
};

But I'd really like to allow these things to be a bit more general purpose! Fact is, a tricky optimizer could turn a malloc/free into an alloca, and a fixed-size alloca into a zero-cost part of the stack frame adjustment. But getting the compiler to decide that a variable sized malloc should be turned into an alloca seems error-prone. What if I want an array of 4Mb?
There goes my stack - poof - in one fell swoop.

So, now, I'm headed to some sort of policy based memory allocation where the programmer could indicate that stack allocation should be used.

It's still unsafe, but not automatically so. The programmer is the one who should understand the implications of the malloc/free -> alloca conversion. If there is no allocated memory, we'll just new & delete the memory manually. So, instead of auto-allocating memory on the stack, we'll allow the programmer to allocate memory that they wish to keep track of manually, or, if no memory is provided, we'll allocate it from the heap, and free it when the object is destroyed.

namespace kbf
{
    namespace impl
    {
        template <typename T, class CHILD>
        class _common_array
        {
        protected:
            __forceinline CHILD *downcast() { return (CHILD *)this; }
            __forceinline const CHILD *downcast() const { return (const CHILD *)this; }
        public:
            // type definitions
            typedef T              value_type;
            typedef T*             iterator;
            typedef const T*       const_iterator;
            typedef T&             reference;
            typedef const T&       const_reference;
            typedef std::size_t    size_type;
            typedef std::ptrdiff_t difference_type;
            typedef std::reverse_iterator<iterator> reverse_iterator;
            typedef std::reverse_iterator<const_iterator> const_reverse_iterator;

            // iterator support
            iterator                begin()        { return downcast()->elems; }
            const_iterator          begin() const { return downcast()->elems; }
            iterator                end()          { return downcast()->elems+downcast()->size(); }
            const_iterator          end()    const { return downcast()->elems+downcast()->size(); }
            reverse_iterator        rbegin()       { return reverse_iterator(downcast()->end()); }
            const_reverse_iterator rbegin() const { return const_reverse_iterator(downcast()->end()); }
            reverse_iterator        rend()         { return reverse_iterator(begin()); }
            const_reverse_iterator rend()   const { return const_reverse_iterator(begin()); }

            // at() with range check
            reference       at(size_type i)       { rangecheck(i); return downcast()->elems[i]; }
            const_reference at(size_type i) const { rangecheck(i); return downcast()->elems[i]; }

            // front() and back()
            reference       front()       { return c_array()[0]; }
            const_reference front() const { return data()[0]; }
            reference       back()        { return c_array()[downcast()->size()-1]; }
            const_reference back() const { return data()[downcast()->size()-1]; }

// direct access to data (read-only)
const T* data() const { return downcast()->elems; }

// use array as C array (direct read/write access to data)
T* c_array() { return downcast()->elems; }

// assign one value to all elements
void assign (const T& value) { std::fill_n(begin(),downcast()->size(),value); }

            // check range (may be private because it is static)
            void rangecheck (size_type i) const {
                if (i >= downcast()->size()) {
                    throw std::range_error("array<>: index out of range");
                }
            }

            // operator[]
            reference operator[](size_type i)
            {
                BOOST_ASSERT( i < downcast()->size() && "out of range" );
                return c_array()[i];
            }

            const_reference operator[](size_type i) const
            {
                BOOST_ASSERT( i < downcast()->size() && "out of range" );
                return data()[i];
            }
        };
    }

    template<typename T, std::size_t N = 0>
    class array : public impl::_common_array<T, array<T,N> > {
    protected:
        friend impl::_common_array<T, array<T,N> >;
        T elems[N];    // fixed-size array of elements of type T
    public:
        array(std::size_t n = N) { BOOST_ASSERT(n == N); }
        // size is constant
        static size_type size() { return N; }
        static bool empty() { return false; }
        static size_type max_size() { return N; }

        // swap (note: linear complexity)
        void swap (array<T,N>& y)
        {
            std::swap_ranges(begin(),end(),y.begin());
        }

        // assignment with type conversion
        template <typename T2>
        array<T,N>& operator= (const array<T2,N>& rhs)
        {
            std::copy(rhs.begin(),rhs.end(), begin());
            return *this;
        }

};

    template<typename T>
    class array<T, 0> : public impl::_common_array<T, array<T,0> > {
        // TODO: This needs to be noncopyable, probably, or deep-copyable...
    private:
        void *operator new(size_t);
    protected:
        friend impl::_common_array<T, array<T,0> >;

        std::size_t sz:sizeof(std::size_t) * 8 - 1;
        unsigned int releaseMem : 1;
        T *elems;

    public:
        array(std::size_t s, void *memory = NULL) : sz(s), releaseMem(!memory), elems((T*)memory)
        {
            if (releaseMem)
            {
                memory = malloc(s * sizeof(T));
                elems = (T*)memory;
            }
            for (size_t i = 0; i < s; i++)
                T *temp = new(&elems[i]) T;
        }
        array(std::size_t s, const T &copyVal, void *memory = NULL) : sz(s), releaseMem(!memory), elems((T*)memory)
        {
            if (releaseMem)
            {
                memory = malloc(s * sizeof(T));
                elems = (T*)memory;
            }
            for (size_t i = 0; i < s; i++)
                T *temp = new(&elems[i]) T(copyVal);
        }
        ~array()
        {
            for (size_t i = 0; i < sz; i++)
                elems[i].~T();
            if (releaseMem)
                free(elems);
        }

        // size is constant
        size_type size() const { return sz; }
        bool empty() const { return sz != 0; }
        size_type max_size() const { return sz; }

        // swap (note: linear complexity)
        void swap (array<T,0>& y)
        {
            // error check
            std::swap_ranges(begin(),end(),y.begin());
        }

        // assignment with type conversion
        template <typename T2>
        array<T,0>& operator= (const array<T2,0>& rhs)
        {
            BOOST_ASSERT(rhs.size() == this->size());
            std::copy(rhs.begin(),rhs.end(), begin());
            return *this;
        }

};

    // comparisons
    template<typename T, std::size_t N>
    bool operator== (const array<T,N>& x, const array<T,N>& y) {
        return std::equal(x.begin(), x.end(), y.begin());
    }
    template<typename T, std::size_t N>
    bool operator< (const array<T,N>& x, const array<T,N>& y) {
        return std::lexicographical_compare(x.begin(),x.end(),y.begin(),y.end());
    }
    template<typename T, std::size_t N>
    bool operator!= (const array<T,N>& x, const array<T,N>& y) {
        return !(x==y);
    }
    template<typename T, std::size_t N>
    bool operator> (const array<T,N>& x, const array<T,N>& y) {
        return y<x;
    }
    template<typename T, std::size_t N>
    bool operator<= (const array<T,N>& x, const array<T,N>& y) {
        return !(y<x);
    }
    template<typename T, std::size_t N>
    bool operator>= (const array<T,N>& x, const array<T,N>& y) {
        return !(x<y);
    }

    // global swap()
    template<typename T, std::size_t N>
    inline void swap (array<T,N>& x, array<T,N>& y) {
        x.swap(y);
    }

} /* namespace kbf */

This is where I am currently.
This seems incredibly useful, and still very performant.
What I'd really like is to be able to eliminate vectors from most of my code, and use these things unless I really do need growable vectors...

I'm working on writing something up about how to use chained unwind info next, hopefully that won't be quite so long in coming as this post...

-Kev

ML64 bug to watch out for

2006-07-20T23:45:00Z

If you're porting your application to x64, and you use much in the way of __asm in your x86 code, you're likely to start looking at ml64 - the 64 bit version of Masm. The reason you're likely to do this is that the x64 compiler doesn't support __asm blocks in C code. So you can either use the compiler intrinsic functions [and there are a lot of 'em, and they're all documented relatively well], or you have to use ml64. For folks that aren't new to Masm, you're also likely to try to use some of the nifty little time-saver features of Masm to automatically generate prologue's and epilogues for your functions. For ML64, DO NOT DO THIS!
Here's an example:
.DATA
.CODE
testfunc PROC uses rbx
xor rbx, rbx
ret
testfunc ENDP
END
There are 2 problems with the code that ML64 generates. #1: There is no .xdata of any sort. No unwind directives are emitted, despite the fact that you're allocating stack, and saving a nonvolatile register. #2: The epilogue is invalid - it uses the 'leave' instruction, which is ineffecient, but also just plain illegal in an x64 function epilogue. The stack unwind routines will not properly recognize the instruction sequence as an epilogue, so the debugger and the EH routines will all fail [the EH routines will just terminate your process if an exception occurs while testfunc is on the stack].

BTW - Here's the link to the customer bug. It came in about 3 months too soon for serious consideration for VC8, so we punted it to the next version, but now it's pushed out until we get some more resources for investment in MASM.

Visual C++ Code Gen & Tools bugs

2006-07-20T23:22:00Z

My role for the past 6 months (and the next several) I'm charged with effectively "going down with the ship" WRT the current generation of code gen & tools for Visual C++. This includes the linker, Masm, ml64, DIA, c2, pdb, and a few other miscellaneous components. The entire ball of wax is to be replaced with components from a product with the much overused codename of Phoenix over the next few product cycles. I have a skeleton crew [trust me on this one] to do the work, and I get to manage them. As the lead of the bunch, I wind up making many less than pleasant calls of 'won't fix'ing a bugs that, in a previous product cycle, would have been fixed in a heart-beat. I'm going to start blogging about each & every customer bug that I mark as "Won't Fix" simply to keep a public list of what not to do until the toolset is replaced.
I'm not sure how acceptable this is, but unless my management smacks me, I'm going to keep doing this for the next many months. The next entry is the first of many...