By , March 30, 2012 3:20 pm

Are you any good at communication? Thats a good question. If you’re like me, you probably think you are not good at communication.

You may think that good communicators are slick, polished, don’t make mistakes, can sum things up nicely and exude a certain level of confidence. Well yes, the public speakers that have been around for a while do tend to be that way. But that is more the result of speaking in public many times than natural ability. Eric Ries wasn’t as polished when he started speaking in public. He is the first to admit that. Practice makes perfect.

That isn’t want I’m talking about. I’m asking you if you communicate your ideas to others and if at the end of the conversation do they understand you?

Why am I mentioning this? Years ago I had a performance review by my line manager. The review was done in 3 parts. My manager would fill in his scores for various tasks and abilities, rating me. I would do the same. Then we’d compare the scores we had for each task and discuss the differences/similarities and how to improve any areas that needed improvement and how to make the most of areas I excelled at.

There were lots of categories, none of which I can remember except for “communication”. I don’t tend to award myself a 10 or 1 in anything when I self score, so the sheet had various high scores and a few low scores. I was hitting it out of the park in software development terms (which would come back to bite me a few years later in the form of RSI – my work was 3 months ahead of schedule) but for communication I gave myself a really low mark.

The really low mark for communication confused my line manager and we spent a good chunk of the review just talking about communication. I had interpreted “communication” on the form as “Can I present, Do I speak in public, do I do this, that the other…” all these imagined things that I thought a good speaker should do. I didn’t think I could do them.

My line manager wasn’t interested in that. He was interested in did my team mates, colleagues, people in teams interfacing with our team (in person or via our documented API), senior managers etc, did these people understand the technical work I was doing? Did they understand how to use it, why certain things were the way they were and most importantly if someone came and asked me a question could I answer it with confusing the living daylights out of them?

Turns out I could. I scored quite well on all that. No idea what he wrote down. Not really relevant these days.

All I’m trying to say is communication is making sure the other person understands. Far better to be slightly slower, or more verbose, or elaborate (or whatever) and succeed in communicating than be super concise, uber terse, abrupt and leave the other person feeling bewildered or intimidated by what you’ve just said.

How do you feel about communication now? Think you’re better at it than before reading this?

64 bit porting gotcha #2! x64 Register preservation

By , March 9, 2012 8:01 pm

In a previous article on x64 development I mentioned the problem of aligning the callstack on 16 byte boundaries and what happens if you do not do this.

Why 16 bytes?

At the time it seemed odd to me that the stack had to be 16 byte aligned. Why? All the parameters are 8 bytes (64 bits) wide and the first four are passed in registers. Everything else spills onto the stack and anything larger is passed as a reference. Floating point values are passed in dedicated floating point registers.

And there lies the key. That last sentence. The floating point registers.

Floating point on x64 is not done using the floating point coprocessor instructions. Instead the SSE instruction sets (and its extensions) are used.

If everything floats, whats the point?

If you are just hooking x64 functions and possibly collecting callstack you may never know need to know about floating point register preservation. We managed to get all four of our C++ tools (coverage, memory, profiler and deadlock detector) functional without knowing. Why would we need to know? Floating point preservation was never important for x86 because we could never damage the floating point without trying to do so.

But when we got into the details of the last bugs that were killing us we noticed seemingly random crashes. Closer investigation showed that calls to Win32 API functions had a tendency to wipe out the floating point registers. And that is when we got interested in what happens if we preserved the x64 floating point registers.

How to view the registers?

At first glance this wasn’t obvious to me. The Registers window in Visual Studio just shows the registers from RAX through R15 etc. However if you right click this window there is a helpful context menu that allows you to choose just how much information you display in this window.

Once you have the registers in view things get a lot easier inside the debugger. You can step through your code ensuring that nothing is getting trampled on until Viola! the floating point registers get totally hosed. A bit more investigation and you realise that seemingly innocent call you had in your code contains a call to a Win32 function (for example VirtualProtect) and that that function is responsible for the register death.

OK, so how do we preserve registers on x64? Its nothing like on x86.

x64 floating point preservation

The x64 designers in their infinite wisdom took away two very useful instructions (pushad and popad). As a result x64 hook writers now have to push lots of registers and pop lots of registers at the start and end of each hook. You can even see this in parts of the Windows operating system DLLs. So much simpler just to push everything and pop everything.

However what the Lord taketh away he can give back. And the x64 designers did that by providing two dedicated instructions for saving and restoring floating point. fxsave and fxrstor. These instructions take one operand each. The operand must point to a 512 byte chunk of memory which is 16 byte aligned.

A common usage would be as shown below although you can use any register as the destination location. It just so happens that the stack pointer (rsp) is the most common usage.

	sub	rsp, 200h;
	fxsave	[rsp];

	.. do your task that damages the floating point registers

	fxrstor	[rsp;]
	add	rsp, 200h;

When you see the above usage you can see why there is the requirement for the stack to be 16 byte aligned. Why 16 bytes? I suspect it is because it is the start of a cache line and that makes executing the instruction *SO* much quicker.


So now you know why the x64 callstack is 16 byte aligned. Its all to do with ensuring your code executes as fast as possible, especially when executing a memory intensive register copy when saving and restoring the x64 floating point registers. I’ve also shown you how to preserve and restore the floating point registers.

Panorama Theme by Themocracy