Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #66125 > unrolled thread
| Started by | Bartc <bc@freeuk.com> |
|---|---|
| First post | 2015-07-21 21:21 +0100 |
| Last post | 2015-09-03 22:33 +0200 |
| Articles | 20 on this page of 153 — 26 participants |
Back to article view | Back to comp.lang.c
Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-21 21:21 +0100
Re: Generic function-calling code jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-21 23:04 +0200
Re: Generic function-calling code luser droog <luser.droog@gmail.com> - 2015-07-21 14:45 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 00:56 +0100
Re: Generic function-calling code BGB <cr88192@hotmail.com> - 2015-07-22 00:25 -0500
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 02:37 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 11:50 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 04:29 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 13:04 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 05:44 -0700
AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-22 12:50 +0000
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 06:07 -0700
Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-22 13:30 +0000
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 07:42 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) David Brown <david.brown@hesbynett.no> - 2015-07-22 17:07 +0200
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 08:16 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Keith Thompson <kst-u@mib.org> - 2015-07-22 08:41 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Keith Thompson <kst-u@mib.org> - 2015-07-22 08:47 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 08:53 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) David Brown <david.brown@hesbynett.no> - 2015-07-22 18:09 +0200
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) David Kleinecke <dkleinecke@gmail.com> - 2015-07-22 16:38 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 18:28 +0100
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) James Kuyper <jameskuyper@verizon.net> - 2015-07-22 13:37 -0400
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) BGB <cr88192@hotmail.com> - 2015-07-22 15:04 -0500
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 10:39 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 19:10 +0100
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 11:39 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 20:01 +0100
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 12:06 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 20:51 +0100
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) guinness.tony@gmail.com - 2015-07-22 17:48 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) raltbos@xs4all.nl (Richard Bos) - 2015-07-22 19:50 +0000
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 13:15 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 21:28 +0100
Re: Let's see who can be the most off-topic Gareth Owen <gwowen@gmail.com> - 2015-07-22 21:44 +0100
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Morris Dovey <mrdovey@iedu.com> - 2015-07-22 16:35 -0500
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 15:17 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Morris Dovey <mrdovey@iedu.com> - 2015-09-05 15:20 -0500
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 23:01 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) wssimms@gmail.com - 2015-09-06 01:58 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 02:28 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Keith Thompson <kst-u@mib.org> - 2015-09-06 12:48 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 07:08 -0700
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Keith Thompson <kst-u@mib.org> - 2015-07-22 13:50 -0700
Re: Let's see who can be the most off-topic Gareth Owen <gwowen@gmail.com> - 2015-07-22 21:43 +0100
Re: Let's see who can be the most off-topic guinness.tony@gmail.com - 2015-07-22 17:43 -0700
Re: Let's see who can be the most off-topic James Kuyper <jameskuyper@verizon.net> - 2015-07-24 10:41 -0400
Re: Let's see who can be the most off-topic Richard Heathfield <rjh@cpax.org.uk> - 2015-07-24 16:01 +0100
Re: Let's see who can be the most off-topic raltbos@xs4all.nl (Richard Bos) - 2015-07-25 19:20 +0000
Re: Let's see who can be the most off-topic Gareth Owen <gwowen@gmail.com> - 2015-07-24 20:25 +0100
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) Rosario19 <Ros@invalid.invalid> - 2015-07-23 20:41 +0200
Re: Let's see who can be the most off-topic (Was: AVCALL ...) Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 12:00 -0700
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-22 17:43 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-22 19:36 +0000
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-22 23:19 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 15:43 -0700
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-22 23:47 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 04:44 -0700
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 13:14 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 06:26 -0700
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 15:00 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 07:13 -0700
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 18:02 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 10:05 -0700
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 18:19 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 10:37 -0700
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) Bartc <bc@freeuk.com> - 2015-07-23 23:29 +0100
Re: AVCALL (from the 'ffcall' package) really is the answer! (Was: Generic function-calling code) gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-23 16:18 +0000
Re: Generic function-calling code Richard Damon <Richard@Damon-Family.org> - 2015-07-24 01:21 -0400
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 13:23 +0100
Re: Generic function-calling code Ian Collins <ian-news@hotmail.com> - 2015-07-23 07:44 +1200
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-22 22:24 +0100
Re: Generic function-calling code luser droog <luser.droog@gmail.com> - 2015-07-22 10:29 -0700
Re: Generic function-calling code luser droog <luser.droog@gmail.com> - 2015-07-22 10:32 -0700
Re: Generic function-calling code Keith Thompson <kst-u@mib.org> - 2015-07-21 15:38 -0700
Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-21 17:26 -0700
Re: Generic function-calling code Ian Collins <ian-news@hotmail.com> - 2015-07-22 14:27 +1200
Re: Generic function-calling code gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-22 02:39 +0000
Re: Generic function-calling code Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-07-23 09:28 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-23 19:04 -0700
Re: Generic function-calling code owen.jacobson@grimoire.ca - 2015-07-24 08:32 -0700
Re: Generic function-calling code gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-24 18:48 +0000
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-24 20:22 +0100
Re: Generic function-calling code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 03:03 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-25 13:32 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-25 23:28 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-26 06:18 -0700
Re: Generic function-calling code gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-26 13:39 +0000
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-26 07:33 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-07-26 16:21 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-26 08:39 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 05:37 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-26 14:36 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 06:46 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-26 16:11 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 08:20 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-27 16:53 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-28 01:03 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 05:36 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 06:35 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 06:43 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-30 15:10 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 08:59 -0700
Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 10:54 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 10:57 -0700
Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 11:13 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 11:16 -0700
Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 11:59 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 12:15 -0700
Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 12:57 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 13:40 -0700
Re: Generic function-calling code Geoff <geoff@invalid.invalid> - 2015-08-30 11:15 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-30 11:28 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-08-30 20:11 +0100
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-08-30 22:28 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 01:13 -0700
Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 00:40 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 01:26 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 11:34 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 03:15 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 03:21 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 13:07 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 04:30 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 13:39 +0200
Re: Generic function-calling code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-03 07:20 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 20:25 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 11:30 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 11:44 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-09-03 11:21 +0100
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 13:19 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 04:51 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 14:31 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 05:57 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 04:56 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 14:53 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 06:08 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 15:18 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 06:30 -0700
Re: Generic function-calling code Martin Shobe <martin.shobe@yahoo.com> - 2015-09-03 10:09 -0500
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 08:59 -0700
Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 08:37 -0700
Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 08:31 -0700
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 09:07 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 20:42 +0200
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 11:49 -0700
Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 08:25 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-09-03 16:46 +0100
Re: Generic function-calling code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-03 09:02 -0700
Re: Generic function-calling code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-04 04:04 +0000
Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 00:36 -0700
Re: Generic function-calling code Bartc <bc@freeuk.com> - 2015-09-03 16:29 +0100
Re: Generic function-calling code Philip Lantz <prl@canterey.us> - 2015-09-03 08:45 -0700
Re: Generic function-calling code David Brown <david.brown@hesbynett.no> - 2015-09-03 22:33 +0200
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 03:21 -0700 |
| Message-ID | <51f2150a-0da9-49a5-93b3-7437ccda0594@googlegroups.com> |
| In reply to | #69087 |
On Thursday, September 3, 2015 at 6:15:47 AM UTC-4, Rick C. Hodgin wrote:
> ...I wrote a
> cartoon about it in the fictional place of Clara County:
>
> http://www.libsf.org/software/misc/clara_county__2009_03_19.zip
The images are no longer on the TG Daily website:
http://www.tgdaily.com/games-and-entertainment-features/41778-clara-county-x86-cross-license-dispute
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-03 13:07 +0200 |
| Message-ID | <ms99hs$9nr$1@dont-email.me> |
| In reply to | #69087 |
On 03/09/15 12:15, Rick C. Hodgin wrote: > On Thursday, September 3, 2015 at 5:34:45 AM UTC-4, David Brown wrote: >> So I don't think the Windows x86-64 ABI mistakes are the result of >> conspiracies - merely a failure on MS' part to predict the future >> accurately. At worst, you could call it laziness on behalf of the MSVC >> compiler and debugger developers - at best, a result of an appropriate >> level of investment based on the market predictions. > > I find it difficult to believe that a company like Microsoft would make > such a horrible design decision for their flagship server OSes based on > the laziness of MSVC and related tools. I would think AMD would be all > too happy to send a few hardware and software liaisons to Microsoft, > giving them all the assistance they need to make their x64 related > implementations sing, for just the phone call. > > And Microsoft was aware of AMD's success during this time, as was Intel. > In fact it's during this time that Intel was later found in courts of > law to be guilty of several anti-competitive practices wielded against > AMD directly. As the lawsuit was approaching completion, I wrote a > cartoon about it in the fictional place of Clara County: > > http://www.libsf.org/software/misc/clara_county__2009_03_19.zip > > This timeframe was one of AMD's greatest in their history. W. Jerry > Sanders, III was still at the helm, making wild and boastful claims > that it seemed AMD could back up. K8 and Opteron were beginning to > flex their muscles, providing a straight-forward path for migration > to the 64-bit world. AMD would soon publicly announce their intention > to partner with UMC and create their own state-of-the-art fabrication > facility in Dresden, Germany (to be completed in 2005). > > Microsoft would've been foolish to not pay AMD some proper attention. > > And based on how wildly harmful this ABI decision is to x86-64's cache, > and machine resources in general, it seems to be of such a poor decision > that it almost has to be deliberate. And if not directly purposeful > toward harming AMD solely, then at least that factor had to be a tide > tipping component in the equation to make such a decision. > > I don't buy it. It's such a nasty implementation that it has to have > been purposefully implemented. Such a software architectural design > decision would not pass scrutiny and review otherwise. A few short > meetings and that one would've been sorted out... after all, they > were already re-writing what they had used previously with Win32. It's > not like this was a mild tweak. This was a new adoption. > > Not buying it, David. And now I'm becoming curious as to where your > funding is coming from, rising to such quick defense of Microsoft with > what is, in my opinion, a reaching argument. > > But, I'm just an outsider looking at what I see, using my own reasoning > mind and thought processes, applying objective thinking, coupled to the > knowledge that Intel and Microsoft have both been fined billions each > for their anti-competitive practices during this time frame. Still, I > could be wrong in my conclusions. > I haven't done any measurements or comparisons to see the real-world effects of the different calling conventions, but I believe you are over-estimating the problem. It's not /that/ bad - and most of the extra effort will be hidden by the super-scaler execution of the instructions. And while MS might have colluded with Intel (or been persuaded by Intel) to delay work on amd64 support, it would not have been in their interests to sabotage it. Remember the old adage - never assign to malice that which can equally well be explained by incompetence!
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 04:30 -0700 |
| Message-ID | <c20ba464-790a-4809-9df9-6df8af73fc47@googlegroups.com> |
| In reply to | #69091 |
On Thursday, September 3, 2015 at 7:07:33 AM UTC-4, David Brown wrote: > Remember the old adage - never assign to malice that which can equally > well be explained by incompetence! A trait people who pursue malice often rely upon... Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-03 13:39 +0200 |
| Message-ID | <ms9bed$g4r$1@dont-email.me> |
| In reply to | #69093 |
On 03/09/15 13:30, Rick C. Hodgin wrote: > On Thursday, September 3, 2015 at 7:07:33 AM UTC-4, David Brown wrote: >> Remember the old adage - never assign to malice that which can equally >> well be explained by incompetence! > > A trait people who pursue malice often rely upon... > Perhaps. (Note that I know both Intel and Microsoft have been in court many times for unethical business practices, and I believe both - especially Microsoft - are capable of a total disregard for morality in the pursuit of profit and control of their markets. But they are also capable of making mistakes or poor decisions, and I believe that is the case here.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-09-03 07:20 -0700 |
| Message-ID | <59a5b676-d68f-48ae-bafe-36c202f7cded@googlegroups.com> |
| In reply to | #69094 |
On Thursday, September 3, 2015 at 12:39:47 PM UTC+1, David Brown wrote: > > (Note that I know both Intel and Microsoft have been in court many times > for unethical business practices, and I believe both - especially > Microsoft - are capable of a total disregard for morality in the pursuit > of profit and control of their markets. But they are also capable of > making mistakes or poor decisions, and I believe that is the case here.) > I think they often use sharp business practices. But I'd distinguish that from a total disregard for morality. It's not as through they're involved in gun- running, narcotics, pornography, adultery-dating websites, or even low wage sweated labour. They do break standards and release clones of competitors' products for free. However GNU also do the latter.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-03 20:25 +0200 |
| Message-ID | <msa374$lth$1@dont-email.me> |
| In reply to | #69126 |
On 03/09/15 16:20, Malcolm McLean wrote: > On Thursday, September 3, 2015 at 12:39:47 PM UTC+1, David Brown wrote: >> >> (Note that I know both Intel and Microsoft have been in court many times >> for unethical business practices, and I believe both - especially >> Microsoft - are capable of a total disregard for morality in the pursuit >> of profit and control of their markets. But they are also capable of >> making mistakes or poor decisions, and I believe that is the case here.) >> > I think they often use sharp business practices. But I'd distinguish that from > a total disregard for morality. It's not as through they're involved in gun- > running, narcotics, pornography, adultery-dating websites, or even low > wage sweated labour. OK, they could be worse! However, they have both shown that they are quite happy to deliberately and knowingly break laws, with the plan that they will damage their competitors irreparably then pay the fines years down the line when the court cases are finished - they view such actions as long-term investments in market capital. > They do break standards and release clones of competitors' > products for free. However GNU also do the latter. > They (especially MS) have done much worse than that. There are endless lists and sources available online if you are interested - there's no point in giving them here. Note that I make no claims that GNU are especially righteous, or that any competitors of Intel or Microsoft are perfect corporate citizens. I am just making the point that I know both Intel and MS are capable of illegal and unfair dealings, though I don't think it was the case in the context of the Windows x86-64 ABI.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 11:30 -0700 |
| Message-ID | <34109d93-03e5-4a05-8bf8-d661ee15a56c@googlegroups.com> |
| In reply to | #69180 |
On Thursday, September 3, 2015 at 2:25:36 PM UTC-4, David Brown wrote: > [snip] > I am just making the point that I know both Intel and MS are capable of > illegal and unfair dealings, though I don't think it was the case in the > context of the Windows x86-64 ABI. What did Microsoft do with IA-64's ABI? Itanium has far more explicit integer registers, but is the protocol similar in fashion (passing some parameters in integer registers, some in floating point, and using the cardinal position for both, thereby effectively interweaving data here and there (apart from optimization))? It would be telling (I think) to note the devotion they gave to IA-64's ABI versus the haphazard devotion they gave AMD64's ABI. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 11:44 -0700 |
| Message-ID | <2c8852cd-8333-442b-8d4e-c844176d4f6b@googlegroups.com> |
| In reply to | #69181 |
On Thursday, September 3, 2015 at 2:30:53 PM UTC-4, Rick C. Hodgin wrote:
> On Thursday, September 3, 2015 at 2:25:36 PM UTC-4, David Brown wrote:
> > [snip]
> > I am just making the point that I know both Intel and MS are capable of
> > illegal and unfair dealings, though I don't think it was the case in the
> > context of the Windows x86-64 ABI.
>
> What did Microsoft do with IA-64's ABI? Itanium has far more explicit
> integer registers, but is the protocol similar in fashion (passing some
> parameters in integer registers, some in floating point, and using
> the cardinal position for both, thereby effectively interweaving
> data here and there (apart from optimization))?
>
> It would be telling (I think) to note the devotion they gave to IA-64's
> ABI versus the haphazard devotion they gave AMD64's ABI.
>
> Best regards,
> Rick C. Hodgin
In researching this, I find from an Intel's manual on Itanium Register
Convention, it reads in part:
"The software conventions specify that up to eight registers are
used for parameter passing. Any registers in the inputand local
region beyond those eight may be allocated for use as preserved
locals. Floating-point parameters may produce 'holes' in the
parameter list that is passed in the general registers; those
unused input registers may also be used for preserved locals."
So, apparently it's something Microsoft had been working on with Itanium
during the Merced years (1990s) and carried it forward.
I stand corrected.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-03 11:21 +0100 |
| Message-ID | <ms96sr$d9$1@dont-email.me> |
| In reply to | #69080 |
On 03/09/2015 10:34, David Brown wrote: > On 03/09/15 10:26, Rick C. Hodgin wrote: >> Based on the horrible design Microsoft chose, it >> seems like a valid reason for why they chose it. >> Remember it was a long time before Intel would >> capitulate to create their own x86-64 version. > By putting the first four parameters into registers, they > could make small functions quite fast. But by leaving space for those > registers on the stack, it would be easy to change code to put those > parameters onto the stack without disturbing anything else, and then you > could debug the code. (It would be interesting to see figures as to how much difference in performance it actually makes to pass arguments in registers. I've done some crude tests, such as using 'gcc -m64 -O0'. Although unoptimised, I assume it still uses the same Fastcall convention (even for non-global calls). Yet the results compared badly with a certain other compiler that I know doesn't use Fastcall and just pushes everything to the stack.) > AMD, on the other hand, wanted into the workstation market. Their main > effort in developing x86-64 was in cooperation with *nix developers and > compiler developers for that market. Thus they worked with folks like > IBM, the Linux kernel developers, SUSE, Red Hat, CodeSourcery, etc. > Their ABI - as used by everyone except Windows - is the System V ABI for > x86-64, targeted at *nix systems and made in cooperation with gcc and a > few other compiler developers for *nix. > > > So I don't think the Windows x86-64 ABI mistakes are the result of > conspiracies - merely a failure on MS' part to predict the future > accurately. What's so terrible about the Windows ABI compared with System V? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-03 13:19 +0200 |
| Message-ID | <ms9a80$cgi$1@dont-email.me> |
| In reply to | #69089 |
On 03/09/15 12:21, Bartc wrote: > On 03/09/2015 10:34, David Brown wrote: >> On 03/09/15 10:26, Rick C. Hodgin wrote: > >>> Based on the horrible design Microsoft chose, it >>> seems like a valid reason for why they chose it. >>> Remember it was a long time before Intel would >>> capitulate to create their own x86-64 version. > >> By putting the first four parameters into registers, they >> could make small functions quite fast. But by leaving space for those >> registers on the stack, it would be easy to change code to put those >> parameters onto the stack without disturbing anything else, and then you >> could debug the code. > > (It would be interesting to see figures as to how much difference in > performance it actually makes to pass arguments in registers. > > I've done some crude tests, such as using 'gcc -m64 -O0'. Although > unoptimised, I assume it still uses the same Fastcall convention (even > for non-global calls). Yet the results compared badly with a certain > other compiler that I know doesn't use Fastcall and just pushes > everything to the stack.) I agree that a direct comparison would be needed to give a fair judgement - as I noted in my reply to Rick, I don't think it makes a particularly big difference. You can't do sensible timed comparisons with -O0 on gcc, as it typically gives very simplistic direct translation of the source code. It is often bigger and slower than code produced by other compilers even if they too have optimisations disabled. There is no independent or absolute scale to optimisations - the flags are just a hint to the compiler as to how hard it should work, and different compilers treat them very differently. In any speed comparisons, you either have to use otherwise identical compilers or you have to ask the compilers for the fastest code they can produce. In this case, you would use a 64-bit Windows build of gcc compared to the same version for 64-bit Linux, running on the same hardware (dual boot, or both within the same sort of virtual machines). It is certainly possible to do, but I for one can't be bothered! > >> AMD, on the other hand, wanted into the workstation market. Their main >> effort in developing x86-64 was in cooperation with *nix developers and >> compiler developers for that market. Thus they worked with folks like >> IBM, the Linux kernel developers, SUSE, Red Hat, CodeSourcery, etc. >> Their ABI - as used by everyone except Windows - is the System V ABI for >> x86-64, targeted at *nix systems and made in cooperation with gcc and a >> few other compiler developers for *nix. >> >> >> So I don't think the Windows x86-64 ABI mistakes are the result of >> conspiracies - merely a failure on MS' part to predict the future >> accurately. > > What's so terrible about the Windows ABI compared with System V? > <https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions> The two key differences are that that with System V ABI, more registers are used for passing parameters than in Windows ABI (this only affects functions with more than 4 integer parameters or 4 floating point parameters), and that the Windows ABI insists that the caller sets up a 32-byte "shadow space" on the stack that is reserved for copies of the register parameters. It is this shadow space that makes the real difference. It means that a function that calls other functions must always make a stack frame, even if it doesn't need one otherwise. It takes a couple of instructions to reserve the space, and it means that you are wasting 32-bytes (plus possibly another 8 bytes for storing the old stack pointer) for every function call - with deep nesting, that's L1 cache pointlessly wasted. But as I said, I don't know if it is a noticeable effect in real code.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 04:51 -0700 |
| Message-ID | <9298a940-a432-4111-ba96-a2370511fef4@googlegroups.com> |
| In reply to | #69092 |
On Thursday, September 3, 2015 at 7:19:17 AM UTC-4, David Brown wrote: > <https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions> > > The two key differences are that that with System V ABI, more registers > are used for passing parameters than in Windows ABI (this only affects > functions with more than 4 integer parameters or 4 floating point > parameters), and that the Windows ABI insists that the caller sets up a > 32-byte "shadow space" on the stack that is reserved for copies of the > register parameters. > > It is this shadow space that makes the real difference. It means that a > function that calls other functions must always make a stack frame, even > if it doesn't need one otherwise. It takes a couple of instructions to > reserve the space, and it means that you are wasting 32-bytes (plus > possibly another 8 bytes for storing the old stack pointer) for every > function call - with deep nesting, that's L1 cache pointlessly wasted. You are also wasting half of the reserved register space set aside explicitly for passed parameters in rcx,rdx,r8,r9 and xmm0,xmm1,xmm2,xmm3, because you can't pass up to eight parameters in registers, but only four, using this protocol. Why? It's a wholly wasteful use of stack space that will likely often go unused, one that's coupled to the reality that you can add it back in whenever you need with the same overhead required to set it aside in the first place, but without the cache pollution from wasted space, not to mention the registers which will always go unused a minimum of half the time. I honestly can't imagine why someone made this decision unless it was to be deliberately hurtful to the architecture. > But as I said, I don't know if it is a noticeable effect in real code. I think notable. It would be quite a hit given that the average x86 program branches every 6 instructions (IIRC), and issues a call to a function every 6 to 18 instructions (12 typical, not counting prologue and epilogue). It's much faster to move values to registers than memory, and this is true for use in subsequent calculations. I would've reserved the same input rcx,rdx,r8,r9 and xmm0,xmm1,xmm2,xmm3 to be used to hold multiple return values as well since they have to be re-written each time anyway. Register to register shuffling is pretty fast, and can be done in parallel with other non-interfering instructions. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-03 14:31 +0200 |
| Message-ID | <ms9eff$sb1$1@dont-email.me> |
| In reply to | #69095 |
On 03/09/15 13:51, Rick C. Hodgin wrote: > On Thursday, September 3, 2015 at 7:19:17 AM UTC-4, David Brown wrote: >> <https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions> >> >> The two key differences are that that with System V ABI, more registers >> are used for passing parameters than in Windows ABI (this only affects >> functions with more than 4 integer parameters or 4 floating point >> parameters), and that the Windows ABI insists that the caller sets up a >> 32-byte "shadow space" on the stack that is reserved for copies of the >> register parameters. >> >> It is this shadow space that makes the real difference. It means that a >> function that calls other functions must always make a stack frame, even >> if it doesn't need one otherwise. It takes a couple of instructions to >> reserve the space, and it means that you are wasting 32-bytes (plus >> possibly another 8 bytes for storing the old stack pointer) for every >> function call - with deep nesting, that's L1 cache pointlessly wasted. > > You are also wasting half of the reserved register space set aside > explicitly for passed parameters in rcx,rdx,r8,r9 and xmm0,xmm1,xmm2,xmm3, > because you can't pass up to eight parameters in registers, but only four, > using this protocol. Why? > You are not using them for parameter passing, but the compiler can still use them for local data. And most functions don't have more than four parameters (plus four floating point parameters), so it is a minor issue. Also, x86 cpus have hardware specially aimed at making reads and writes to stack data as fast as possible - there are special buffers for this, because in 32-bit mode the x86 is so register-poor that the stack is heavily used. All in all, it is not going to make much of a difference - though I fully agree that it makes sense to allow more parameters to be passed in registers (because it costs nothing, and occasionally helps). > It's a wholly wasteful use of stack space that will likely often go > unused, one that's coupled to the reality that you can add it back in > whenever you need with the same overhead required to set it aside in > the first place, but without the cache pollution from wasted space, > not to mention the registers which will always go unused a minimum of > half the time. > > I honestly can't imagine why someone made this decision unless it was > to be deliberately hurtful to the architecture. > >> But as I said, I don't know if it is a noticeable effect in real code. > > I think notable. It would be quite a hit given that the average x86 > program branches every 6 instructions (IIRC), and issues a call to a > function every 6 to 18 instructions (12 typical, not counting prologue > and epilogue). > > It's much faster to move values to registers than memory, and this is > true for use in subsequent calculations. That's all true - but how many of these function calls need more than four parameters? > > I would've reserved the same input rcx,rdx,r8,r9 and xmm0,xmm1,xmm2,xmm3 > to be used to hold multiple return values as well since they have to be > re-written each time anyway. Register to register shuffling is pretty > fast, and can be done in parallel with other non-interfering instructions. > > Best regards, > Rick C. Hodgin >
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 05:57 -0700 |
| Message-ID | <7bb4d973-7f17-4ab0-9ef3-a902372bec21@googlegroups.com> |
| In reply to | #69099 |
On Thursday, September 3, 2015 at 8:31:39 AM UTC-4, David Brown wrote:
> On 03/09/15 13:51, Rick C. Hodgin wrote:
> > On Thursday, September 3, 2015 at 7:19:17 AM UTC-4, David Brown wrote:
> >> <https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions>
> >>
> >> The two key differences are that that with System V ABI, more registers
> >> are used for passing parameters than in Windows ABI (this only affects
> >> functions with more than 4 integer parameters or 4 floating point
> >> parameters), and that the Windows ABI insists that the caller sets up a
> >> 32-byte "shadow space" on the stack that is reserved for copies of the
> >> register parameters.
> >>
> >> It is this shadow space that makes the real difference. It means that a
> >> function that calls other functions must always make a stack frame, even
> >> if it doesn't need one otherwise. It takes a couple of instructions to
> >> reserve the space, and it means that you are wasting 32-bytes (plus
> >> possibly another 8 bytes for storing the old stack pointer) for every
> >> function call - with deep nesting, that's L1 cache pointlessly wasted.
> >
> > You are also wasting half of the reserved register space set aside
> > explicitly for passed parameters in rcx,rdx,r8,r9 and xmm0,xmm1,xmm2,xmm3,
> > because you can't pass up to eight parameters in registers, but only four,
> > using this protocol. Why?
> >
>
> You are not using them for parameter passing, but the compiler can still
> use them for local data. And most functions don't have more than four
> parameters (plus four floating point parameters), so it is a minor
> issue. Also, x86 cpus have hardware specially aimed at making reads and
> writes to stack data as fast as possible - there are special buffers for
> this, because in 32-bit mode the x86 is so register-poor that the stack
> is heavily used.
>
> All in all, it is not going to make much of a difference - though I
> fully agree that it makes sense to allow more parameters to be passed in
> registers (because it costs nothing, and occasionally helps).
>
> > It's a wholly wasteful use of stack space that will likely often go
> > unused, one that's coupled to the reality that you can add it back in
> > whenever you need with the same overhead required to set it aside in
> > the first place, but without the cache pollution from wasted space,
> > not to mention the registers which will always go unused a minimum of
> > half the time.
> >
> > I honestly can't imagine why someone made this decision unless it was
> > to be deliberately hurtful to the architecture.
> >
> >> But as I said, I don't know if it is a noticeable effect in real code.
> >
> > I think notable. It would be quite a hit given that the average x86
> > program branches every 6 instructions (IIRC), and issues a call to a
> > function every 6 to 18 instructions (12 typical, not counting prologue
> > and epilogue).
> >
> > It's much faster to move values to registers than memory, and this is
> > true for use in subsequent calculations.
>
> That's all true - but how many of these function calls need more than
> four parameters?
Six. Perhaps seven. :-)
> > I would've reserved the same input rcx,rdx,r8,r9 and xmm0,xmm1,xmm2,xmm3
> > to be used to hold multiple return values as well since they have to be
> > re-written each time anyway. Register to register shuffling is pretty
> > fast, and can be done in parallel with other non-interfering instructions.
I think it's worth finding out. I propose a three-part test:
(1) GCC on Windows running testparams.c.
(2) GCC on Linux running the same testparams.c.
(3) GCC on Windows (or Linux) running a custom testparams.c
generated to assembly with manual modification allowing
for all 8 parameters to be passed in registers, and no
shadow stack space.
I'm willing to conduct this test. It will take a while for me to
find the time.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 04:56 -0700 |
| Message-ID | <756eb52a-bceb-4d63-aea2-7891bb452b70@googlegroups.com> |
| In reply to | #69092 |
On Thursday, September 3, 2015 at 7:19:17 AM UTC-4, David Brown wrote: > But as I said, I don't know if it is a noticeable effect in real code. Wouldn't it be easy enough to test? Use the same version of GCC, one instance on Windows with MinGW, and one instance on Linux with MinGW. They use slightly different calling conventions. Setup a little test which passes each combination of values through to other functions which do some trivial thing on the inputs (add one to each), and then returns the sum of the results. Compile both with -O0 and compare the execution times over a million iterations. Something like that should work. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-03 14:53 +0200 |
| Message-ID | <ms9fpk$1lu$1@dont-email.me> |
| In reply to | #69096 |
On 03/09/15 13:56, Rick C. Hodgin wrote: > On Thursday, September 3, 2015 at 7:19:17 AM UTC-4, David Brown wrote: >> But as I said, I don't know if it is a noticeable effect in real code. > > Wouldn't it be easy enough to test? Use the same version of GCC, one > instance on Windows with MinGW, and one instance on Linux with MinGW. > They use slightly different calling conventions. Setup a little test > which passes each combination of values through to other functions > which do some trivial thing on the inputs (add one to each), and then > returns the sum of the results. Compile both with -O0 and compare > the execution times over a million iterations. > > Something like that should work. > Yes, I said as much in a reply to Bart. However, compiling with -O0 is seldom good for comparison - you would lose any timing difference in the mass of stack manipulation that is done with -O0 in gcc. Comparing with -O2 would give realistic results. You would need code that makes a lot of function calls across modules to see the difference - with static functions in the same module, the compiler can use whatever calling convention it likes. Even if the function is not static, the compiler can make a local static copy of it with a different calling convention if it wants to (recent gcc's can do quite a bit of function cloning for speed). If you want to do such a test, it would be interesting to see the results. If you are interested, here are some links: <http://people.freebsd.org/~obrien/amd64-elf-abi.pdf> <https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_Calling_Conventions> <http://stackoverflow.com/questions/4429398/why-does-windows64-use-a-different-calling-convention-from-all-other-oses-on-x86>
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 06:08 -0700 |
| Message-ID | <0a91bc26-5094-4de8-94c4-e44f93243958@googlegroups.com> |
| In reply to | #69107 |
On Thursday, September 3, 2015 at 8:54:01 AM UTC-4, David Brown wrote: > On 03/09/15 13:56, Rick C. Hodgin wrote: > > On Thursday, September 3, 2015 at 7:19:17 AM UTC-4, David Brown wrote: > >> But as I said, I don't know if it is a noticeable effect in real code. > > > > Wouldn't it be easy enough to test? Use the same version of GCC, one > > instance on Windows with MinGW, and one instance on Linux with MinGW. > > They use slightly different calling conventions. Setup a little test > > which passes each combination of values through to other functions > > which do some trivial thing on the inputs (add one to each), and then > > returns the sum of the results. Compile both with -O0 and compare > > the execution times over a million iterations. > > > > Something like that should work. > > > > Yes, I said as much in a reply to Bart. However, compiling with -O0 is > seldom good for comparison - you would lose any timing difference in the > mass of stack manipulation that is done with -O0 in gcc. Comparing with > -O2 would give realistic results. The stack manipulation should be the same on both platforms, and therefore a constant, which is why I proposed it. Since we're comparing the Windows Win64 protocol to that seen in Linux, we'll just make sure we specify commensurate forms in the function definitions. > You would need code that makes a lot of function calls across modules to > see the difference - with static functions in the same module, the > compiler can use whatever calling convention it likes. We wouldn't leave that decision up to the compiler, as we're explicitly trying to test the relative speed of these particular calling conventions. > Even if the > function is not static, the compiler can make a local static copy of it > with a different calling convention if it wants to (recent gcc's can do > quite a bit of function cloning for speed). Hence -O0. > If you want to do such a test, it would be interesting to see the results. > > If you are interested, here are some links: > > <http://people.freebsd.org/~obrien/amd64-elf-abi.pdf> > <https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_Calling_Conventions> > > <http://stackoverflow.com/questions/4429398/why-does-windows64-use-a-different-calling-convention-from-all-other-oses-on-x86> I will at some point when I have some free time. I believe we'll find the difference is negligible on functions with 0 to 4 parameters, and a few percentage points on others (approaching 7% or 8% on heavy recursion (polluted stack) or heavy mixed parameter passing (misuse of half of the passed parameters)). In real-world code bases, probably an average of a 2% or 3% hit max in performance. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-03 15:18 +0200 |
| Message-ID | <ms9h86$7j2$1@dont-email.me> |
| In reply to | #69115 |
On 03/09/15 15:08, Rick C. Hodgin wrote: > On Thursday, September 3, 2015 at 8:54:01 AM UTC-4, David Brown > wrote: >> On 03/09/15 13:56, Rick C. Hodgin wrote: >>> On Thursday, September 3, 2015 at 7:19:17 AM UTC-4, David Brown >>> wrote: >>>> But as I said, I don't know if it is a noticeable effect in >>>> real code. >>> >>> Wouldn't it be easy enough to test? Use the same version of GCC, >>> one instance on Windows with MinGW, and one instance on Linux >>> with MinGW. They use slightly different calling conventions. >>> Setup a little test which passes each combination of values >>> through to other functions which do some trivial thing on the >>> inputs (add one to each), and then returns the sum of the >>> results. Compile both with -O0 and compare the execution times >>> over a million iterations. >>> >>> Something like that should work. >>> >> >> Yes, I said as much in a reply to Bart. However, compiling with >> -O0 is seldom good for comparison - you would lose any timing >> difference in the mass of stack manipulation that is done with -O0 >> in gcc. Comparing with -O2 would give realistic results. > > The stack manipulation should be the same on both platforms, and > therefore a constant, which is why I proposed it. > It is likely to be roughly the same, but not exactly. And the inefficiencies of -O0 compilation will totally dominate your timings - the differences in calling convention overhead will probably be a fraction of a percent. If you have more compact and efficient code with -O2, the differences in the calling conventions will stand out much clearer. > Since we're comparing the Windows Win64 protocol to that seen in > Linux, we'll just make sure we specify commensurate forms in the > function definitions. > >> You would need code that makes a lot of function calls across >> modules to see the difference - with static functions in the same >> module, the compiler can use whatever calling convention it likes. > > We wouldn't leave that decision up to the compiler, as we're > explicitly trying to test the relative speed of these particular > calling conventions. Thus you make sure the functions you are calling are in separately compiled modules. > >> Even if the function is not static, the compiler can make a local >> static copy of it with a different calling convention if it wants >> to (recent gcc's can do quite a bit of function cloning for >> speed). > > Hence -O0. No, that's not the way to do it (as explained above). I agree with you on your aims here, just not on the best method to achieve those aims. > >> If you want to do such a test, it would be interesting to see the >> results. >> >> If you are interested, here are some links: >> >> <http://people.freebsd.org/~obrien/amd64-elf-abi.pdf> >> <https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_Calling_Conventions> >> >> >> <http://stackoverflow.com/questions/4429398/why-does-windows64-use-a-different-calling-convention-from-all-other-oses-on-x86> > > I will at some point when I have some free time. I believe we'll > find the difference is negligible on functions with 0 to 4 > parameters, and a few percentage points on others (approaching 7% or > 8% on heavy recursion (polluted stack) or heavy mixed parameter > passing (misuse of half of the passed parameters)). > > In real-world code bases, probably an average of a 2% or 3% hit max > in performance. That's possible, but of course it will depend highly on the type of code involved. > > Best regards, Rick C. Hodgin >
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 06:30 -0700 |
| Message-ID | <77cd64ad-32ae-4766-a0fe-26dd51391b16@googlegroups.com> |
| In reply to | #69118 |
On Thursday, September 3, 2015 at 9:18:51 AM UTC-4, David Brown wrote: > On 03/09/15 15:08, Rick C. Hodgin wrote: > > On Thursday, September 3, 2015 at 8:54:01 AM UTC-4, David Brown > > wrote: > >> On 03/09/15 13:56, Rick C. Hodgin wrote: > >>> On Thursday, September 3, 2015 at 7:19:17 AM UTC-4, David Brown > >>> wrote: > >>>> But as I said, I don't know if it is a noticeable effect in > >>>> real code. > >>> > >>> Wouldn't it be easy enough to test? Use the same version of GCC, > >>> one instance on Windows with MinGW, and one instance on Linux > >>> with MinGW. They use slightly different calling conventions. > >>> Setup a little test which passes each combination of values > >>> through to other functions which do some trivial thing on the > >>> inputs (add one to each), and then returns the sum of the > >>> results. Compile both with -O0 and compare the execution times > >>> over a million iterations. > >>> > >>> Something like that should work. > >>> > >> > >> Yes, I said as much in a reply to Bart. However, compiling with > >> -O0 is seldom good for comparison - you would lose any timing > >> difference in the mass of stack manipulation that is done with -O0 > >> in gcc. Comparing with -O2 would give realistic results. > > > > The stack manipulation should be the same on both platforms, and > > therefore a constant, which is why I proposed it. > > > > It is likely to be roughly the same, but not exactly. And the > inefficiencies of -O0 compilation will totally dominate your timings - > the differences in calling convention overhead will probably be a > fraction of a percent. If you have more compact and efficient code with > -O2, the differences in the calling conventions will stand out much clearer. It's easy enough to examine in assembly, fixup whatever's whacky, and then proceed on equal footing. The inefficiencies will dominate the timing, but they will dominate it equally on both platforms, and therefore reveal only the differences I'm interested in. > > Since we're comparing the Windows Win64 protocol to that seen in > > Linux, we'll just make sure we specify commensurate forms in the > > function definitions. > > > >> You would need code that makes a lot of function calls across > >> modules to see the difference - with static functions in the same > >> module, the compiler can use whatever calling convention it likes. > > > > We wouldn't leave that decision up to the compiler, as we're > > explicitly trying to test the relative speed of these particular > > calling conventions. > > Thus you make sure the functions you are calling are in separately > compiled modules. Nope. I should be able to make them how I like, and with -O0 and an explicit call type, it will generate what I want from a single source file. > >> Even if the function is not static, the compiler can make a local > >> static copy of it with a different calling convention if it wants > >> to (recent gcc's can do quite a bit of function cloning for > >> speed). > > > > Hence -O0. > > No, that's not the way to do it (as explained above). I disagree. But, we'll see. I could be wrong. I would welcome your contribution as a comparison. I might learn something from someone with your background. > I agree with you on your aims here, just not on the best method to > achieve those aims. I could be wrong. It will be easy enough to sort out when the time comes. > >> If you want to do such a test, it would be interesting to see the > >> results. > >> > >> If you are interested, here are some links: > >> > >> <http://people.freebsd.org/~obrien/amd64-elf-abi.pdf> > >> <https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_Calling_Conventions> > >> > >> > >> > <http://stackoverflow.com/questions/4429398/why-does-windows64-use-a-different-calling-convention-from-all-other-oses-on-x86> > > > > I will at some point when I have some free time. I believe we'll > > find the difference is negligible on functions with 0 to 4 > > parameters, and a few percentage points on others (approaching 7% or > > 8% on heavy recursion (polluted stack) or heavy mixed parameter > > passing (misuse of half of the passed parameters)). > > > > In real-world code bases, probably an average of a 2% or 3% hit max > > in performance. > > That's possible, but of course it will depend highly on the type of code > involved. They will be contrived tests, obviously, designed to test across the range of input parameter forms. If you know of any good real-world apps I could test for mixed integer and floating point computation based on these same compiler setting changes... Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-09-03 10:09 -0500 |
| Message-ID | <ms9no0$2cr$1@dont-email.me> |
| In reply to | #69123 |
On 9/3/2015 8:30 AM, Rick C. Hodgin wrote: > On Thursday, September 3, 2015 at 9:18:51 AM UTC-4, David Brown wrote: >> On 03/09/15 15:08, Rick C. Hodgin wrote: >>> On Thursday, September 3, 2015 at 8:54:01 AM UTC-4, David Brown >>> wrote: >>>> On 03/09/15 13:56, Rick C. Hodgin wrote: >>>>> On Thursday, September 3, 2015 at 7:19:17 AM UTC-4, David Brown >>>>> wrote: >>>>>> But as I said, I don't know if it is a noticeable effect in >>>>>> real code. >>>>> >>>>> Wouldn't it be easy enough to test? Use the same version of GCC, >>>>> one instance on Windows with MinGW, and one instance on Linux >>>>> with MinGW. They use slightly different calling conventions. >>>>> Setup a little test which passes each combination of values >>>>> through to other functions which do some trivial thing on the >>>>> inputs (add one to each), and then returns the sum of the >>>>> results. Compile both with -O0 and compare the execution times >>>>> over a million iterations. >>>>> >>>>> Something like that should work. >>>>> >>>> >>>> Yes, I said as much in a reply to Bart. However, compiling with >>>> -O0 is seldom good for comparison - you would lose any timing >>>> difference in the mass of stack manipulation that is done with -O0 >>>> in gcc. Comparing with -O2 would give realistic results. >>> >>> The stack manipulation should be the same on both platforms, and >>> therefore a constant, which is why I proposed it. >>> >> >> It is likely to be roughly the same, but not exactly. And the >> inefficiencies of -O0 compilation will totally dominate your timings - >> the differences in calling convention overhead will probably be a >> fraction of a percent. If you have more compact and efficient code with >> -O2, the differences in the calling conventions will stand out much clearer. > > It's easy enough to examine in assembly, fixup whatever's whacky, and > then proceed on equal footing. Since you two want the generate exact machine code sequences, why aren't you using assembly in the first place? Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 08:59 -0700 |
| Message-ID | <291ab4ab-3b0c-4e7e-a9ce-ad32e170edc8@googlegroups.com> |
| In reply to | #69135 |
On Thursday, September 3, 2015 at 11:09:46 AM UTC-4, Martin Shobe wrote: > Since you two want the generate exact machine code sequences, why aren't > you using assembly in the first place? I don't want to generate the exact sequences. I want to generate sequences which are using the same source code, conducting the same workload, but are doing so within the 64-bit confines of the calling convention. On Linux it will pass six parameters in regs, and not use shadow stack space. On Windows it will pass four parameters in regs, and will use shadow stack space. These parameters being in varying places will determine how some operations are conducted by the compiler, as it may be more efficient to leave it in memory and add to it there, rather than load from memory to a register, do the add, and then write back, etc. I'll post all of my results here. And if there are any things that aren't right, I'll re-run them. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web