Hi everyone, I'm Rich Skorski

36 views
Skip to first unread message

Rich Skorski

unread,
Apr 18, 2012, 11:28:37 PM4/18/12
to AltDevAuthors
I've been a software engineer at Turbine for 6 years, and worked in QA
for 6 months before that. That's been my only professional gig since
graduating from Full Sail. I'm really excited to be a part of what
you guys have created here.

I have a handful of topics for post ideas, but there are two in
particular I want to do before the rest. They were both directly
influenced by posts on AltDev. I'd love to hear which the rest of the
authors here would like to hear about first.


--------------------------
Performance considerations with fastcall and the x64 ABI

Bruce Dawson's series on floating point numbers has been awesome, and
he mentions that the x64 ABI has one calling convention that's similar
to x86's fastcall. That fascinated me, and I was eager to know how
much parameter order can affect performance. I'll have the breakdown
of the assembly output of an example function after changing the
parameter order. I also have VTune numbers showing the difference in
speed.

--------------------------
Anatomy of function pointers

Alex Darby's Low Level Curriculum series mentioned that function
pointers can vary in size. I did not know that. I needed to
understand why that is, and did a bunch of experiments with virtual
functions and virtual class hierarchies. I only focused on the MSVC
implementation (vc7.1, but I figure it would be appropriate to do the
same experiments in vc10 for a post) to disect what data the compiler
keeps with the function pointer. I don't think this will be super
practical information, but more of a fun exercise to highlight some of
the problems compiler writers have to deal with.

--------------------------

Let me know what you guys think!

Mike Acton

unread,
Apr 19, 2012, 3:17:39 AM4/19/12
to altdev...@googlegroups.com
I think both would be great and I don't have a particular preference for one or the other. I think it's great when one post inspires another. :)

I definitely think a deeper understanding of x64 ABI differences is an interesting topic though and there's quite a lot of ground there that hasn't been covered well that I'm sure folks would be interested in.

Mike.

Alex darbotron Darby

unread,
Apr 19, 2012, 6:08:14 PM4/19/12
to AltDevAuthors
I'd be interested in both of those! :)

One of the major motivating factors in my quest to understand what the
compiler has to do for any given bit of C++ (as well as wanting to
write better code) has always been to find out what features of the
language make it do stuff that is "undesirable" (quotes because this
gets pretty subjective with me....)

My "literally 30 minutes of dicking about with MSVC and googling" take
on the function pointer thing was basically: I've never _needed_ to
use the the C++ code idioms that require these weird "not just a
memory address" function pointers, and the cases where they are
generated are (probably) avoidable.

My (irrational?) problem with this stems from 3 things:
ember function pointers have horrific syntax, If you ask me, any
language feature that causes a "function pointer" to be more than a
memory address of some code to execute has got to be bad juju. I
prefer to use static functions with explicit this pointers to get
around the issue.

Alex

Alex darbotron Darby

unread,
Apr 19, 2012, 6:12:45 PM4/19/12
to AltDevAuthors
bollocks! accidentally pressed something that caused that to post half-
written!!

Here's what that last paragraph SHOULD have said:

My (irrational?) problem with this stems from 3 things:
1) Member function pointers have horrific syntax, especially in
actually usuing them
2) The dereferencing of a member function pointer is some weird edge
case in C++ that (I think I'm correct in saying this) is the only
pointer type whose dereferenced value cannot be stored
3) If you ask me, any language feature that causes a "pointer" to be
more than a memory address has got to be bad juju.

I prefer to use static functions with explicit this pointers to
circumvent the issue, though I'm sure there's some very clever but
unnecessary uses of templates that won't work that way ;)

Alex

Bruce Dawson

unread,
Apr 20, 2012, 1:22:12 AM4/20/12
to altdev...@googlegroups.com
I'll dodge the issue of whether complex function pointers are good or evil
(functors that contain both a code address and a this pointer are certainly
invaluable) but some knowledge of them can be helpful. And, if you restrict
yourself to simple void* compatible pointers how can you say "I want a
pointer to a virtual member function such that when I call it with any
derived type -- even using multiple inheritance -- it will navigate the
hierarchy and call the correct function". Pointers to member functions can
be useful and I think it is the extending to that logical conclusion that
can make them large.

Twice this year I've been asked to help people figure out why the size of a
structure seemed to vary. The reason was that it contained a function
pointer, and that function pointers size varied due to changes in how the
code was compiled. Pure evil. The techniques for investigating such problems
are not at all obvious. Ping me and I can send along my notes, which might
be helpful.

For the 64-bit ABI some things you could look at are:
- How parameters are passed (first registers, then memory), mixed parameters
(float and int), and how well it handles m128 parameters
- Perhaps discuss the home space (memory on the stack left for registers
that are passed even if they never go there)
- Different exception handling support (metadata instead of linked-list of
handlers)
- Different stack walking model (metadata instead of linked-list of stack
frames)
- Different standard for where float results are returned
- Stack pointer that never changes throughout a function (parameters to
called functions are placed not pushed)

There are numerous advantages to this, although it can make stack walking
slightly more expensive and arguably less obvious.

That's all that comes to mind. It's probably way more than you are planning
to cover, but I figured it's always helpful to know where some of the
interesting/sharp areas are when you start investigating.

Rich Skorski

unread,
Apr 20, 2012, 2:41:09 PM4/20/12
to AltDevAuthors
@Bruce: You bring a good point about structure size, I didn't think
about that. I would love to see your notes to cross reference, and
perhaps fill in some holes of my understanding. I found a site
written by a Microsoft gentleman (link escapes me right now) that also
tries to explain it, but his results were different than mine.
Perhaps with 3 sets of notes, we can normalize all the information :)

It sounds like a more detailed post or perhaps a series on the x64 ABI
would be appropriate. It would probably be better to explain some of
that first just to ensure readers know about the ABI before I go and
show them how performance can change when you change parameter order.
I would prefer a series since would be a good amount to cover and it
could be very heavy stuff to take in one big spoonful for many
readers.

some other points to add to that list:
- data on the stack is 16 byte aligned
- Difference between Microsoft's and AMD's calling convention (could
probably be a subnote in a "how parameters are passed" section/post)

If you guys are cool with it, I'll start writing up a rough draft on
an Intro to the x64 ABI over the weekend and have something for your
reviewing eyes hopefully by Monday. If one of you gentlemen would
rather take the reigns, I understand. This would be my first post,
and I haven't actually dug into x64 compilation outside of
experimentation and research. I've yet to have any experience with it
at work.

Also, I will agree that member function pointers are crazy-bananas. I
spent multiple days trying to figure out what the different data
members of the ethereal function-pointer-to-virtual-base-class-member
are for. The intent of the post would be to encourage more
appreciation for compiler writers. I don't expect many folks (myself
included) will exercise the knowledge often.


On Apr 20, 1:22 am, "Bruce Dawson" <brucedaw...@cygnus-software.com>
wrote:
> Alex- Hide quoted text -
>
> - Show quoted text -

Alex darbotron Darby

unread,
Apr 20, 2012, 4:00:28 PM4/20/12
to AltDevAuthors
Hey Bruce, I knew you'd comment on my comment ;)

I agree that delegates are awesome :)

Incidentally, Rich this is where I got my information, and I think it
might answer many ofthe questions you'd need to look into

http://www.codeproject.com/Articles/7150/Member-Function-Pointers-and-the-Fastest-Possible

which is the documentation for a delegate library hosted at
codeproject that I know has been used in anger in in multi platform
shipped games.

Look forwards to the article Rich ;)

Alex

Stefan Reinalter

unread,
Apr 20, 2012, 5:26:50 PM4/20/12
to AltDevAuthors
For a different view on the topic, this is how I implemented delegates
and events:
http://molecularmusings.wordpress.com/2011/09/19/generic-type-safe-delegates-and-events-in-c/

The post also contains links to other posts/MSDN, which explain why
member function pointers can have different sizes, etc.

Stefan


On Apr 20, 10:00 pm, Alex darbotron Darby <darbot...@darbotron.com>
wrote:
> Hey Bruce, I knew you'd comment on my comment ;)
>
> I agree that delegates are awesome :)
>
> Incidentally, Rich this is where I got my information, and I think it
> might answer many ofthe questions you'd need to look into
>
> http://www.codeproject.com/Articles/7150/Member-Function-Pointers-and...

Alex darbotron Darby

unread,
Apr 21, 2012, 4:47:25 AM4/21/12
to AltDevAuthors
Stefan.

That is awesome. Love it.

Do you know how well it works cross platform? (e.g. will it compile
under the PS3 GCC compiler?)

I can totally check that myself, but thought I'd ask.

Alex

Stefan Reinalter

unread,
Apr 21, 2012, 4:55:45 AM4/21/12
to AltDevAuthors
Yes, it should work on every platform (PC, Wii, 360, PS3, 3DS). Might
have been the SN compiler on the PS3, but GCC should also be able to
handle it.
Stefan


On Apr 21, 10:47 am, Alex darbotron Darby <darbot...@darbotron.com>
wrote:

Rich Skorski

unread,
Apr 21, 2012, 3:10:28 PM4/21/12
to AltDevAuthors
Thanks guys, this is great stuff. Alex, that's the site I had
mentioned earlier, though I thought I was viewing it on an MSDN blog.
I incorrectly assumed he was a Microsoft guy. Regardless, thanks for
the links.

Alex darbotron Darby

unread,
Apr 23, 2012, 2:09:07 PM4/23/12
to AltDevAuthors
Ace! cheers dude :)


Alex darbotron Darby

unread,
Apr 23, 2012, 3:44:04 PM4/23/12
to AltDevAuthors
So one question about that blog post...

At the point where you introduce the 2 template functions that return
the different types of function pointers (free and member), the class
they're in (in the sample code) isn't templated, and the return type
of the two static functions is "R" which isn't mentioned in the
parameter list of either templated function.

This is in the source box immediately after "That means we can turn
our delegates into the following:"

Is this a typo from when you were diting the code for the blog? I
assume so, since "R" is used as the template parameter in the
templated delegate class in the next source code window, and that
would make sense, but I'm always discovering new and weird aspects of
template syntax so I thought I'd ask! ;)

Cheers,

Alex

Alex darbotron Darby

unread,
Apr 23, 2012, 3:45:36 PM4/23/12
to AltDevAuthors
oops! that was supposed to be an email just to Stefan. My bad.
Reply all
Reply to author
Forward
0 new messages