|Hi everyone, I'm Rich Skorski||Rich Skorski||4/18/12 8:28 PM|
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
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!
|Re: Hi everyone, I'm Rich Skorski||Mike Acton||4/19/12 12:17 AM|
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.
|Re: Hi everyone, I'm Rich Skorski||Alex 'darbotron' Darby||4/19/12 3:08 PM|
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.
|Re: Hi everyone, I'm Rich Skorski||Alex 'darbotron' Darby||4/19/12 3:12 PM|
bollocks! accidentally pressed something that caused that to post half-
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.
circumvent the issue, though I'm sure there's some very clever but
unnecessary uses of templates that won't work that way ;)
|RE: Hi everyone, I'm Rich Skorski||Bruce||4/19/12 10:22 PM|
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
For the 64-bit ABI some things you could look at are:
There are numerous advantages to this, although it can make stack walking
That's all that comes to mind. It's probably way more than you are planning
|Re: Hi everyone, I'm Rich Skorski||Rich Skorski||4/20/12 11:41 AM|
@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
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
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>
> Alex- Hide quoted text -
> - Show quoted text -
|Re: Hi everyone, I'm Rich Skorski||Alex 'darbotron' Darby||4/20/12 1:00 PM|
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
which is the documentation for a delegate library hosted at
codeproject that I know has been used in anger in in multi platform
Look forwards to the article Rich ;)
|Re: Hi everyone, I'm Rich Skorski||Stefan Reinalter||4/20/12 2:26 PM|
For a different view on the topic, this is how I implemented delegates
The post also contains links to other posts/MSDN, which explain why
member function pointers can have different sizes, etc.
On Apr 20, 10:00 pm, Alex darbotron Darby <darbot...@darbotron.com>
> Hey Bruce, I knew you'd comment on my comment ;)> http://www.codeproject.com/Articles/7150/Member-Function-Pointers-and...
|Re: Hi everyone, I'm Rich Skorski||Alex 'darbotron' Darby||4/21/12 1:47 AM|
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.
|Re: Hi everyone, I'm Rich Skorski||Stefan Reinalter||4/21/12 1:55 AM|
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
On Apr 21, 10:47 am, Alex darbotron Darby <darbot...@darbotron.com>
|Re: Hi everyone, I'm Rich Skorski||Rich Skorski||4/21/12 12:10 PM|
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
|Re: Hi everyone, I'm Rich Skorski||Alex 'darbotron' Darby||4/23/12 11:09 AM|
Ace! cheers dude :)
|Re: Hi everyone, I'm Rich Skorski||Alex 'darbotron' Darby||4/23/12 12:44 PM|
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! ;)
|Re: Hi everyone, I'm Rich Skorski||Alex 'darbotron' Darby||4/23/12 12:45 PM|
oops! that was supposed to be an email just to Stefan. My bad.