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 6 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-08-30 06:43 -0700 |
| Message-ID | <3a7e0bef-d091-4a04-b129-f9443876ce11@googlegroups.com> |
| In reply to | #68685 |
On Sunday, August 30, 2015 at 9:35:34 AM UTC-4, Rick C. Hodgin wrote:
> -----[ Begin x64 Debug Assembly ]-----
> // printf("%f %f %f %f %f %f %f\n", f1, f2, f3, f4, f5, f6, f7);
>
> 0x13F701052 movd xmm0,dword ptr [f7]
> 0x13F70105B cvtps2pd xmm0,xmm0
>
> 0x13F70105E movd xmm1,dword ptr [f6]
> 0x13F701067 cvtps2pd xmm1,xmm1
>
> 0x13F70106A movd xmm2,dword ptr [f5]
> 0x13F701073 cvtps2pd xmm2,xmm2
>
> 0x13F701076 movd xmm3,dword ptr [f4]
> 0x13F70107F cvtps2pd xmm3,xmm3
>
> 0x13F701082 movd xmm4,dword ptr [f3]
> 0x13F70108B cvtps2pd xmm4,xmm4
>
> 0x13F70108E movd xmm5,dword ptr [f2]
> 0x13F701094 cvtps2pd xmm5,xmm5
>
> 0x13F701097 movd xmm6,dword ptr [f1]
> 0x13F70109D cvtps2pd xmm6,xmm6
>
> 0x13F7010A0 movsd mmword ptr [rsp+38h],xmm0
> 0x13F7010A6 movsd mmword ptr [rsp+30h],xmm1
> 0x13F7010AC movsd mmword ptr [rsp+28h],xmm2
> 0x13F7010B2 movsd mmword ptr [rsp+20h],xmm3
>
> 0x13F7010B8 movapd xmm3,xmm4
> (1) 0x13F7010BC movd r9, xmm3
> 0x13F7010C1 movapd xmm2,xmm5
> (2) 0x13F7010C5 movd r8, xmm2
> 0x13F7010CA movapd xmm1,xmm6
> (3) 0x13F7010CE movd rdx, xmm1
>
> // This is "%f %f %f %f %f %f %f\n"
> 0x13F7010D3 lea rcx,[__xi_z+130h (13F706790h)]
>
> 0x13F7010DA call qword ptr [__imp_printf (13F70B548h)]
> -----[ End x64 Debug Assembly ]-----
>
> (Regarding (1), (2) and (3) in the x64 Debug assembly generation)
>
> Why are these floating point values being moved into rdx, r8, r9?
> According to what I've read, all floating point values should be
> in xmmN regs, and not in the integer regs.
Referring to:
https://msdn.microsoft.com/en-us/library/zthk2dkh%28v=vs.80%29.aspx
"Floating-point and double-precision arguments are passed in
XMM0 - XMM3 (up to 4) with the integer slot (RCX, RDX, R8,
and R9) that would normally be used for that cardinal slot
being ignored (see example) and vice versa."
"Example of argument passing 3 -- mixed ints and floats:"
func3(int a, double b, int c, float d);
// a in RCX, b in XMM1, c in R8, d in XMM3
Is the compiler just doing extra unnecessary work here since the
values are still in xmm1, xmm2, xmm3? If so, I find that a very
odd bug in Visual Studio's compiler.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-30 15:10 +0100 |
| Message-ID | <mrv2ol$6g9$1@dont-email.me> |
| In reply to | #68685 |
On 30/08/2015 14:35, Rick C. Hodgin wrote:
> On Sunday, August 30, 2015 at 8:36:34 AM UTC-4, Rick C. Hodgin wrote:
>> ...Some commit after this
>> should have the 64-bit dispatch working properly (Lord willing):
>
> Bart, I've run into something I don't understand. I created a
> simple test program:
> printf("%f %f %f %f %f %f %f\n", f1, f2, f3, f4, f5, f6, f7);
> Why are these floating point values being moved into rdx, r8, r9?
> According to what I've read, all floating point values should be
> in xmmN regs, and not in the integer regs.
Normally, yes. Except for variadic functions such as printf. Then any
floating point arguments have to be loaded to both XMM and the
corresponding GPR.
(I asked a similar question in comp.lang.misc. James Harris posted this
link:
http://msdn.microsoft.com/en-us/library/ms235286.aspx
If you read down far enough (which I didn't at first) then it will say
the same thing.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-30 08:59 -0700 |
| Message-ID | <7e0dc1ab-89ec-4ce3-9827-9888f3cc10dc@googlegroups.com> |
| In reply to | #68687 |
On Sunday, August 30, 2015 at 10:10:19 AM UTC-4, Bart wrote:
> On 30/08/2015 14:35, Rick C. Hodgin wrote:
> > On Sunday, August 30, 2015 at 8:36:34 AM UTC-4, Rick C. Hodgin wrote:
> >> ...Some commit after this
> >> should have the 64-bit dispatch working properly (Lord willing):
> >
> > Bart, I've run into something I don't understand. I created a
> > simple test program:
>
> > printf("%f %f %f %f %f %f %f\n", f1, f2, f3, f4, f5, f6, f7);
>
> > Why are these floating point values being moved into rdx, r8, r9?
> > According to what I've read, all floating point values should be
> > in xmmN regs, and not in the integer regs.
>
> Normally, yes. Except for variadic functions such as printf. Then any
> floating point arguments have to be loaded to both XMM and the
> corresponding GPR.
>
> (I asked a similar question in comp.lang.misc. James Harris posted this
> link:
>
> http://msdn.microsoft.com/en-us/library/ms235286.aspx
>
> If you read down far enough (which I didn't at first) then it will say
> the same thing.)
Thank you, Bart. I found this quote:
"For vararg or unprototyped functions, any float values must be
duplicated in the corresponding general-purpose register."
I would think that should be prominent reading on the other page as well,
included in an additional example, for example. :-)
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-08-30 10:54 -0700 |
| Message-ID | <ppg6uap3115epsf4pis8r5v10v5s3am8v8@4ax.com> |
| In reply to | #68691 |
On Sun, 30 Aug 2015 08:59:31 -0700 (PDT), "Rick C. Hodgin"
<rick.c.hodgin@gmail.com> wrote:
>On Sunday, August 30, 2015 at 10:10:19 AM UTC-4, Bart wrote:
>> On 30/08/2015 14:35, Rick C. Hodgin wrote:
>> > On Sunday, August 30, 2015 at 8:36:34 AM UTC-4, Rick C. Hodgin wrote:
>> >> ...Some commit after this
>> >> should have the 64-bit dispatch working properly (Lord willing):
>> >
>> > Bart, I've run into something I don't understand. I created a
>> > simple test program:
>>
>> > printf("%f %f %f %f %f %f %f\n", f1, f2, f3, f4, f5, f6, f7);
>>
>> > Why are these floating point values being moved into rdx, r8, r9?
>> > According to what I've read, all floating point values should be
>> > in xmmN regs, and not in the integer regs.
>>
>> Normally, yes. Except for variadic functions such as printf. Then any
>> floating point arguments have to be loaded to both XMM and the
>> corresponding GPR.
>>
>> (I asked a similar question in comp.lang.misc. James Harris posted this
>> link:
>>
>> http://msdn.microsoft.com/en-us/library/ms235286.aspx
>>
>> If you read down far enough (which I didn't at first) then it will say
>> the same thing.)
>
>Thank you, Bart. I found this quote:
>
> "For vararg or unprototyped functions, any float values must be
> duplicated in the corresponding general-purpose register."
>
>I would think that should be prominent reading on the other page as well,
>included in an additional example, for example. :-)
>
https://msdn.microsoft.com/en-us/library/6yy8aw4d.aspx
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-30 10:57 -0700 |
| Message-ID | <56c65207-f517-433b-a42a-d8fd3ea1dbfc@googlegroups.com> |
| In reply to | #68704 |
On Sunday, August 30, 2015 at 1:54:21 PM UTC-4, Geoff wrote:
> On Sun, 30 Aug 2015 08:59:31 -0700 (PDT), "Rick C. Hodgin"
> <rick.c.hodgin@gmail.com> wrote:
>
> >On Sunday, August 30, 2015 at 10:10:19 AM UTC-4, Bart wrote:
> >> On 30/08/2015 14:35, Rick C. Hodgin wrote:
> >> > On Sunday, August 30, 2015 at 8:36:34 AM UTC-4, Rick C. Hodgin wrote:
> >> >> ...Some commit after this
> >> >> should have the 64-bit dispatch working properly (Lord willing):
> >> >
> >> > Bart, I've run into something I don't understand. I created a
> >> > simple test program:
> >>
> >> > printf("%f %f %f %f %f %f %f\n", f1, f2, f3, f4, f5, f6, f7);
> >>
> >> > Why are these floating point values being moved into rdx, r8, r9?
> >> > According to what I've read, all floating point values should be
> >> > in xmmN regs, and not in the integer regs.
> >>
> >> Normally, yes. Except for variadic functions such as printf. Then any
> >> floating point arguments have to be loaded to both XMM and the
> >> corresponding GPR.
> >>
> >> (I asked a similar question in comp.lang.misc. James Harris posted this
> >> link:
> >>
> >> http://msdn.microsoft.com/en-us/library/ms235286.aspx
> >>
> >> If you read down far enough (which I didn't at first) then it will say
> >> the same thing.)
> >
> >Thank you, Bart. I found this quote:
> >
> > "For vararg or unprototyped functions, any float values must be
> > duplicated in the corresponding general-purpose register."
> >
> >I would think that should be prominent reading on the other page as well,
> >included in an additional example, for example. :-)
> >
>
> https://msdn.microsoft.com/en-us/library/6yy8aw4d.aspx
It's the only other calling type. It should be in the examples listed
here and not buried down in some other section. It's one more example
and shouldn't be too hard to squeeze in there:
https://msdn.microsoft.com/en-us/library/zthk2dkh.aspx
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-08-30 11:13 -0700 |
| Message-ID | <3sh6uats42ct5862si3025177vvu6vht05@4ax.com> |
| In reply to | #68705 |
On Sun, 30 Aug 2015 10:57:32 -0700 (PDT), "Rick C. Hodgin"
<rick.c.hodgin@gmail.com> wrote:
>On Sunday, August 30, 2015 at 1:54:21 PM UTC-4, Geoff wrote:
>> On Sun, 30 Aug 2015 08:59:31 -0700 (PDT), "Rick C. Hodgin"
>> <rick.c.hodgin@gmail.com> wrote:
>>
>> >On Sunday, August 30, 2015 at 10:10:19 AM UTC-4, Bart wrote:
>> >> On 30/08/2015 14:35, Rick C. Hodgin wrote:
>> >> > On Sunday, August 30, 2015 at 8:36:34 AM UTC-4, Rick C. Hodgin wrote:
>> >> >> ...Some commit after this
>> >> >> should have the 64-bit dispatch working properly (Lord willing):
>> >> >
>> >> > Bart, I've run into something I don't understand. I created a
>> >> > simple test program:
>> >>
>> >> > printf("%f %f %f %f %f %f %f\n", f1, f2, f3, f4, f5, f6, f7);
>> >>
>> >> > Why are these floating point values being moved into rdx, r8, r9?
>> >> > According to what I've read, all floating point values should be
>> >> > in xmmN regs, and not in the integer regs.
>> >>
>> >> Normally, yes. Except for variadic functions such as printf. Then any
>> >> floating point arguments have to be loaded to both XMM and the
>> >> corresponding GPR.
>> >>
>> >> (I asked a similar question in comp.lang.misc. James Harris posted this
>> >> link:
>> >>
>> >> http://msdn.microsoft.com/en-us/library/ms235286.aspx
>> >>
>> >> If you read down far enough (which I didn't at first) then it will say
>> >> the same thing.)
>> >
>> >Thank you, Bart. I found this quote:
>> >
>> > "For vararg or unprototyped functions, any float values must be
>> > duplicated in the corresponding general-purpose register."
>> >
>> >I would think that should be prominent reading on the other page as well,
>> >included in an additional example, for example. :-)
>> >
>>
>> https://msdn.microsoft.com/en-us/library/6yy8aw4d.aspx
>
>It's the only other calling type. It should be in the examples listed
>here and not buried down in some other section. It's one more example
>and shouldn't be too hard to squeeze in there:
>
> https://msdn.microsoft.com/en-us/library/zthk2dkh.aspx
>
I agree. Perhaps you can follow the link labeled, "Any Suggestions?"
and post a suggestion to that effect.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-30 11:16 -0700 |
| Message-ID | <dad95507-1df9-4e04-bce4-346185d5648c@googlegroups.com> |
| In reply to | #68706 |
On Sunday, August 30, 2015 at 2:13:25 PM UTC-4, Geoff wrote:
> On Sun, 30 Aug 2015 10:57:32 -0700 (PDT), "Rick C. Hodgin"
> <rick.c.hodgin@gmail.com> wrote:
>
> >On Sunday, August 30, 2015 at 1:54:21 PM UTC-4, Geoff wrote:
> >> On Sun, 30 Aug 2015 08:59:31 -0700 (PDT), "Rick C. Hodgin"
> >> <rick.c.hodgin@gmail.com> wrote:
> >>
> >> >On Sunday, August 30, 2015 at 10:10:19 AM UTC-4, Bart wrote:
> >> >> On 30/08/2015 14:35, Rick C. Hodgin wrote:
> >> >> > On Sunday, August 30, 2015 at 8:36:34 AM UTC-4, Rick C. Hodgin wrote:
> >> >> >> ...Some commit after this
> >> >> >> should have the 64-bit dispatch working properly (Lord willing):
> >> >> >
> >> >> > Bart, I've run into something I don't understand. I created a
> >> >> > simple test program:
> >> >>
> >> >> > printf("%f %f %f %f %f %f %f\n", f1, f2, f3, f4, f5, f6, f7);
> >> >>
> >> >> > Why are these floating point values being moved into rdx, r8, r9?
> >> >> > According to what I've read, all floating point values should be
> >> >> > in xmmN regs, and not in the integer regs.
> >> >>
> >> >> Normally, yes. Except for variadic functions such as printf. Then any
> >> >> floating point arguments have to be loaded to both XMM and the
> >> >> corresponding GPR.
> >> >>
> >> >> (I asked a similar question in comp.lang.misc. James Harris posted this
> >> >> link:
> >> >>
> >> >> http://msdn.microsoft.com/en-us/library/ms235286.aspx
> >> >>
> >> >> If you read down far enough (which I didn't at first) then it will say
> >> >> the same thing.)
> >> >
> >> >Thank you, Bart. I found this quote:
> >> >
> >> > "For vararg or unprototyped functions, any float values must be
> >> > duplicated in the corresponding general-purpose register."
> >> >
> >> >I would think that should be prominent reading on the other page as well,
> >> >included in an additional example, for example. :-)
> >> >
> >>
> >> https://msdn.microsoft.com/en-us/library/6yy8aw4d.aspx
> >
> >It's the only other calling type. It should be in the examples listed
> >here and not buried down in some other section. It's one more example
> >and shouldn't be too hard to squeeze in there:
> >
> > https://msdn.microsoft.com/en-us/library/zthk2dkh.aspx
> >
>
> I agree. Perhaps you can follow the link labeled, "Any Suggestions?"
> and post a suggestion to that effect.
I had that thought. I'm very anti-Microsoft so I'm a little
reticent to help them out. :-)
A few years ago I had an idea for a web browser extension called
Markup, which allows add-ons to be made to any web page which are
only visible through the Markup extension. It would be nice to
be able to have that ability to correct or expand upon things seen
on the Internet that could do with some flushing out.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-08-30 11:59 -0700 |
| Message-ID | <d4k6uap71egpfvmjkeqlv7ehb9bonj8gj9@4ax.com> |
| In reply to | #68708 |
On Sun, 30 Aug 2015 11:16:41 -0700 (PDT), "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: >I had that thought. I'm very anti-Microsoft so I'm a little >reticent to help them out. :-) > Microsoft coders and their bugs have made me a lot of money over the years so I can't be very anti-Microsoft. :-) I'll sometimes put in a suggestion on their MSDN simply to make it a better tool since I am often a user of that tool. Your position is hypocritical since you use their tools, their platform and their API in your work and your projects are derivative of their works. >A few years ago I had an idea for a web browser extension called >Markup, which allows add-ons to be made to any web page which are >only visible through the Markup extension. It would be nice to >be able to have that ability to correct or expand upon things seen >on the Internet that could do with some flushing out. For which browser? I can remember when web pages were mostly pure text with diagrams and images secondary, these days I'm bombarded by scripts, Flash and unwanted advertising instead of the content I am seeking.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-30 12:15 -0700 |
| Message-ID | <3d41e250-c308-49e4-8f3f-1db124215f0e@googlegroups.com> |
| In reply to | #68712 |
On Sunday, August 30, 2015 at 2:59:12 PM UTC-4, Geoff wrote:
> On Sun, 30 Aug 2015 11:16:41 -0700 (PDT), "Rick C. Hodgin"
> <rick.c.hodgin@gmail.com> wrote:
>
> >I had that thought. I'm very anti-Microsoft so I'm a little
> >reticent to help them out. :-)
> >
>
> Microsoft coders and their bugs have made me a lot of money over the
> years so I can't be very anti-Microsoft. :-) I'll sometimes put in a
> suggestion on their MSDN simply to make it a better tool since I am
> often a user of that tool.
>
> Your position is hypocritical since you use their tools, their
> platform and their API in your work and your projects are derivative
> of their works.
My position is not hypocritical. I worked exceedingly hard to
create my own operating system, called "Exodus" (6 years before
I was a believer in Jesus Christ), because I wanted it to be a
"mass departure from evil," which was Microsoft:
https://github.com/RickCHodgin/libsf-full/tree/master/_exodus
I began working with FoxBASE+ back in the late 80s when it was
owned by Fox Software. Microsoft bought Fox Software in the early
1990s. I had the inertia of my former Fox Software code base in
moving forward, and I resigned myself to complete Exodus and then
create my own version of a compiler, which at that time I called
q/Compiler (which was more or less what RDC intends to be).
And when Microsoft cancelled their Visual FoxPro version in 2010,
I resolved to write a free replacement. I have written the code
base solely since July 12, 2012, and have released the full fruits
of my work originally into a GPL-like license, which ensured it
would remain open, but then later as a Christian I realized what
God had given us in this world (He provided everything, and then
gave us a choice to use it as He indicated, or not), so I changed
my license to now release it into the Public Domain with a caveat:
self-accountability to God to keep the software open at our request
(the authors who work on these projects).
I have also had interests for years (with my first design being
completed in 1993) to create my own CPU design to replace Intel and
AMD with a custom offering. And my first attempt as a Christian
is called the LibSF 386-x40, a 40-bit extension of the original
i386 core, with some more modern ISA features thrown in:
https://github.com/RickCHodgin/libsf/tree/master/li386
I am moving forward in my life in all ways to which I have skills.
In the meantime, I am using what is available for a job, all the
while "evangelizing" that other people help me write my products.
To date, I've found two people who have actually contributed code
to help. Most people have no interest because there's a cross on
the front door, and our purpose in making these offerings is not
to do them for money, but as an offering unto the Lord of the skills
He first gave us.
> >A few years ago I had an idea for a web browser extension called
> >Markup, which allows add-ons to be made to any web page which are
> >only visible through the Markup extension. It would be nice to
> >be able to have that ability to correct or expand upon things seen
> >on the Internet that could do with some flushing out.
>
> For which browser?
Firefox.
> I can remember when web pages were mostly pure text with diagrams and
> images secondary, these days I'm bombarded by scripts, Flash and
> unwanted advertising instead of the content I am seeking.
I have also proposed a new web browser for the Liberty Software Foundation,
called Interface. It is built around Visual FreePro, and it uses custom
programming to create web content rather than complex HTML, CSS, and other
languages. In this way, you can run the web service locally, remotely,
and download entire code bases to replicate functionality of the remote
web server on your machine locally, etc.
I have ideas across the board on shared collaboration using the skills
each of us possess to augment the skills of other people who came before
us, but because I put a cross on the door, and in my heart, I do not
have people interested in helping. As such, I continue as best I'm able,
advocating at all points that people avoid everything Microsoft after
about 2010, and for those software programs they must use because that's
the way the world operates, use them minimally, and write your own
replacements as you're able.
I would like to have resources to complete all of my ideas. I have had
a plan since 2010 I've been working toward:
(1) Visual FreePro
(2) My RDC Compiler, a requirement of Visual FreePro
(3) Exodus-32
(4) Armodus-32
(5) Exodus-64
(6) Armodus-64
And since November of 2014, that has changed slightly because I learned
Verilog and began working on my own CPU designs for the LibSF 386-x40:
(1) Visual FreePro
(2) RDC compiler
(3) Exodus-32
(4) Armodus-32
(5) Logician software
(6) LibSF 386-x40 CPU
(7) Exodus-386-x40
All of those products will be completely open, and released under a
commensurate public domain license with the same caveat of self-
accountability to God to keep the technology open.
It is my best offering unto the Lord in this world. I don't know how
to do it better or I would. If anyone has any suggestions, please let
me know and I'll consider them.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-08-30 12:57 -0700 |
| Message-ID | <f7n6uapoorjhgrv0kuqmi82m8leqi23ur6@4ax.com> |
| In reply to | #68714 |
On Sun, 30 Aug 2015 12:15:27 -0700 (PDT), "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: >My position is not hypocritical. I worked exceedingly hard to >create my own operating system, called "Exodus" So which operating system are you using at this moment to post in this group? Which browser are you using to access the evil Google groups? Firefox? Is it ported to Exodus? You're certainly not using the godless Linux or GNU are you? Which operating system are you using to run your Visual Studio and the vaunted Edit and Continue you love so much? Certainly not your own RDC since it's not finished. Neither would you be surprised by the ABI behavior in this thread if you were the author of it. The hypocrite never knows himself, neither did the Pharisees.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-30 13:40 -0700 |
| Message-ID | <35de2fdc-c5c5-4641-908b-3fc844ab57b7@googlegroups.com> |
| In reply to | #68717 |
On Sunday, August 30, 2015 at 3:57:33 PM UTC-4, Geoff wrote: > On Sun, 30 Aug 2015 12:15:27 -0700 (PDT), "Rick C. Hodgin" > <rick.c.hodgin@gmail.com> wrote: > > >My position is not hypocritical. I worked exceedingly hard to > >create my own operating system, called "Exodus" > > So which operating system are you using at this moment to post in this > group? Which browser are you using to access the evil Google groups? > Firefox? Is it ported to Exodus? You're certainly not using the > godless Linux or GNU are you? > > Which operating system are you using to run your Visual Studio and the > vaunted Edit and Continue you love so much? Certainly not your own RDC > since it's not finished. Neither would you be surprised by the ABI > behavior in this thread if you were the author of it. > > The hypocrite never knows himself, neither did the Pharisees. I look forward to the day when the evil ways of Satan are put down, for they mislead men to such an extent, and there is so much harm being done. I long for the days of healing, love, peace, and joy. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-08-30 11:15 -0700 |
| Message-ID | <huh6uah5bu3gia51fh9qh9jjop78tgj6vc@4ax.com> |
| In reply to | #68705 |
FWIW, here's the preamble to printf on my system when I stepped into the function: printf: 000000006001ECB0 mov qword ptr [rsp+8],rcx 000000006001ECB5 mov qword ptr [rsp+10h],rdx 000000006001ECBA mov qword ptr [rsp+18h],r8 000000006001ECBF mov qword ptr [rsp+20h],r9 000000006001ECC4 sub rsp,58h ...
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-30 11:28 -0700 |
| Message-ID | <16afe51f-3a51-4056-aa8f-b95c531345a7@googlegroups.com> |
| In reply to | #68707 |
On Sunday, August 30, 2015 at 2:15:41 PM UTC-4, Geoff wrote: > FWIW, here's the preamble to printf on my system when I stepped into > the function: > > printf: > 000000006001ECB0 mov qword ptr [rsp+8],rcx > 000000006001ECB5 mov qword ptr [rsp+10h],rdx > 000000006001ECBA mov qword ptr [rsp+18h],r8 > 000000006001ECBF mov qword ptr [rsp+20h],r9 > 000000006001ECC4 sub rsp,58h > ... Thank you, Geoff. I am working on this support right now. Maybe somebody can explain to me how the Win64 method of passing parameters is a better way of doing so than the Win32 way, if, for no other reason, it requires that every function called by 16-byte aligned and include a 4x8 = 32 byte extra buffer the caller(!!) is responsible for setting up, even if the called function has no parameters. What a way to consume stack memory unnecessary and pollute the cache with useless, often unused, data. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-30 20:11 +0100 |
| Message-ID | <mrvkdr$gju$1@dont-email.me> |
| In reply to | #68709 |
On 30/08/2015 19:28, Rick C. Hodgin wrote: > On Sunday, August 30, 2015 at 2:15:41 PM UTC-4, Geoff wrote: >> FWIW, here's the preamble to printf on my system when I stepped into >> the function: >> >> printf: >> 000000006001ECB0 mov qword ptr [rsp+8],rcx >> 000000006001ECB5 mov qword ptr [rsp+10h],rdx >> 000000006001ECBA mov qword ptr [rsp+18h],r8 >> 000000006001ECBF mov qword ptr [rsp+20h],r9 >> 000000006001ECC4 sub rsp,58h >> ... > > Thank you, Geoff. I am working on this support right now. > > Maybe somebody can explain to me how the Win64 method of passing > parameters is a better way of doing so than the Win32 way, if, for > no other reason, it requires that every function called by 16-byte > aligned and include a 4x8 = 32 byte extra buffer the caller(!!) is > responsible for setting up, even if the called function has no > parameters. It's worse in Linux because the first six arguments are passed in registers! Although I don't know if it requires the caller to commit 64 bytes on the stack. I think the idea is that both caller and callee can just keep values in registers, while pushing an empty 32-bytes is a single, fast instruction (sub rsp,32). In practice, unless the function being called calls no other functions, any further calls requires that those register variables being written to the stack anyway (into that pre-allocated 32-byte area). It also makes it harder to generate code for simple compilers that don't have sophisticated register allocators, such as mine. For that reason I don't bother with any of this, and just push all arguments onto the stack; very simple. I found keeping the stack 16-byte aligned, even inside expressions, to be a nightmare anyway. (Of course I have to do things properly when calling foreign functions. Such as DLL functions. Doing aligned pushes of XMM registers might be another issue, but I haven't needed to so far.) > What a way to consume stack memory unnecessary and pollute the > cache with useless, often unused, data. It shouldn't affect the cache at all. But pushing arguments that are never used by the caller, would. And it doesn't use any more stack than the old method, other than because of extra alignment (and everything being 8-bytes wide). The idea is good, just very fiddly to work with. But I don't know how much difference it makes in practice. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-30 22:28 +0200 |
| Message-ID | <mrvouh$3ra$1@dont-email.me> |
| In reply to | #68713 |
On 30/08/15 21:11, Bartc wrote: > On 30/08/2015 19:28, Rick C. Hodgin wrote: >> On Sunday, August 30, 2015 at 2:15:41 PM UTC-4, Geoff wrote: >>> FWIW, here's the preamble to printf on my system when I stepped into >>> the function: >>> >>> printf: >>> 000000006001ECB0 mov qword ptr [rsp+8],rcx >>> 000000006001ECB5 mov qword ptr [rsp+10h],rdx >>> 000000006001ECBA mov qword ptr [rsp+18h],r8 >>> 000000006001ECBF mov qword ptr [rsp+20h],r9 >>> 000000006001ECC4 sub rsp,58h >>> ... >> >> Thank you, Geoff. I am working on this support right now. >> >> Maybe somebody can explain to me how the Win64 method of passing >> parameters is a better way of doing so than the Win32 way, if, for >> no other reason, it requires that every function called by 16-byte >> aligned and include a 4x8 = 32 byte extra buffer the caller(!!) is >> responsible for setting up, even if the called function has no >> parameters. > > It's worse in Linux because the first six arguments are passed in > registers! Although I don't know if it requires the caller to commit 64 > bytes on the stack. > For x86-64, Linux uses the standard ABI calling convention that AMD (along with OS and compiler developers) picked and everybody follows, except MS on Windows. It is a more efficient calling convention, because it makes better use of registers in parameter passing, and it doesn't have this silly 32-byte extra block that increases the function call overhead in 64-bit Windows. The "advantages" of the Windows system is that it can help poor-quality debuggers and compilers that can't track variables in registers properly, and it can significantly speed up variable argument functions. However, since far and away the biggest use of variable argument functions is for printf and friends, and these are already relatively slow, it is a poor idea to make them marginally less slow at the expense of every overhead in other function call. > I think the idea is that both caller and callee can just keep values in > registers, while pushing an empty 32-bytes is a single, fast instruction > (sub rsp,32). In practice, unless the function being called calls no > other functions, any further calls requires that those register > variables being written to the stack anyway (into that pre-allocated > 32-byte area). > > It also makes it harder to generate code for simple compilers that don't > have sophisticated register allocators, such as mine. For that reason I > don't bother with any of this, and just push all arguments onto the > stack; very simple. > > I found keeping the stack 16-byte aligned, even inside expressions, to > be a nightmare anyway. (Of course I have to do things properly when > calling foreign functions. Such as DLL functions. Doing aligned pushes > of XMM registers might be another issue, but I haven't needed to so far.) > >> What a way to consume stack memory unnecessary and pollute the >> cache with useless, often unused, data. > > It shouldn't affect the cache at all. But pushing arguments that are > never used by the caller, would. And it doesn't use any more stack than > the old method, other than because of extra alignment (and everything > being 8-bytes wide). > > The idea is good, just very fiddly to work with. But I don't know how > much difference it makes in practice. >
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-01 01:13 -0700 |
| Message-ID | <6ed52afe-bef5-4b12-88e0-352c7137df7c@googlegroups.com> |
| In reply to | #68713 |
On Sunday, August 30, 2015 at 3:11:43 PM UTC-4, Bart wrote: > On 30/08/2015 19:28, Rick C. Hodgin wrote: > > On Sunday, August 30, 2015 at 2:15:41 PM UTC-4, Geoff wrote: > >> FWIW, here's the preamble to printf on my system when I stepped into > >> the function: > >> > >> printf: > >> 000000006001ECB0 mov qword ptr [rsp+8],rcx > >> 000000006001ECB5 mov qword ptr [rsp+10h],rdx > >> 000000006001ECBA mov qword ptr [rsp+18h],r8 > >> 000000006001ECBF mov qword ptr [rsp+20h],r9 > >> 000000006001ECC4 sub rsp,58h > >> ... > > > > Thank you, Geoff. I am working on this support right now. > > > > Maybe somebody can explain to me how the Win64 method of passing > > parameters is a better way of doing so than the Win32 way, if, for > > no other reason, it requires that every function called by 16-byte > > aligned and include a 4x8 = 32 byte extra buffer the caller(!!) is > > responsible for setting up, even if the called function has no > > parameters. > > It's worse in Linux because the first six arguments are passed in > registers! Although I don't know if it requires the caller to commit 64 > bytes on the stack. > > I think the idea is that both caller and callee can just keep values in > registers, while pushing an empty 32-bytes is a single, fast instruction > (sub rsp,32). In practice, unless the function being called calls no > other functions, any further calls requires that those register > variables being written to the stack anyway (into that pre-allocated > 32-byte area). > > It also makes it harder to generate code for simple compilers that don't > have sophisticated register allocators, such as mine. For that reason I > don't bother with any of this, and just push all arguments onto the > stack; very simple. > > I found keeping the stack 16-byte aligned, even inside expressions, to > be a nightmare anyway. (Of course I have to do things properly when > calling foreign functions. Such as DLL functions. Doing aligned pushes > of XMM registers might be another issue, but I haven't needed to so far.) > > > What a way to consume stack memory unnecessary and pollute the > > cache with useless, often unused, data. > > It shouldn't affect the cache at all. But pushing arguments that are > never used by the caller, would. And it doesn't use any more stack than > the old method, other than because of extra alignment (and everything > being 8-bytes wide). > > The idea is good, just very fiddly to work with. But I don't know how > much difference it makes in practice. What I don't understand is they already allocate, or potentially allocate, four integer regs, and four floating point xmm regs, so why maintain them in cardinal positions? Why not allow up to eight parameters being passed this way, rather than only four? Why not put the first four integers in the regs, and the first four floats, doubles, or small structs, in xmm regs? I could see doing this in all cases except variadic, where they should not even consider using regs (integer or xmm), but only use the stack. I just don't see why they did it the way they did. It seems so wasteful of machine resources, including the cache (due to the wasted, often unused, data being also in the cache, interspersed alongside real data in use). I mean how hard would it be for any functions which need to save registers to allocate its own stack space if needed? Trivial. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-09-03 00:40 -0700 |
| Message-ID | <MPG.3051994fc6a3969d55@news.eternal-september.org> |
| In reply to | #68798 |
Rick C. Hodgin wrote: [regarding the Win64 requirement of allocating an extra 32 bytes of stack space for every function call] > I just don't see why they did it the way they did. It seems so > wasteful of machine resources, including the cache (due to the > wasted, often unused, data being also in the cache, interspersed > alongside real data in use). I mean how hard would it be for > any functions which need to save registers to allocate its own > stack space if needed? Trivial. I agree, it seems very wasteful of cache. As far as I can tell, it is only to simplify the implementation of varargs functions, but I don't see why they didn't make the requirement apply to varargs functions only, since they are a tiny minority of functions.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 01:26 -0700 |
| Message-ID | <7cf0420f-e751-47ee-9463-945c32bc31d9@googlegroups.com> |
| In reply to | #69061 |
Philip Lantz wrote: > I agree, it seems very wasteful of cache. As far > as I can tell, it is only to simplify the > implementation of varargs functions, but I > don't see why they didn't make the > requirement apply to varargs functions only, > since they are a tiny minority of functions. Something occurred to me. AMD released specs publicly for x86-64 on August 10, 1999 IIRC. At that time, Intel was working on their own proprietary 64-bit solution, called Itanium, with Merced being first released in May, 2001 IIRC. Merced CPUs would've been in silicon and being tested and developed for by the late 90s. So I'm wondering if this wasn't a purposeful decision by Microsoft to harm AMD's offering in favor of their "Wintel" partnership? Supporting their partner by hobbling x86-64 in this way. Wouldn't surprise me at all. Both Microsoft and Intel have been found guilty in various international courts of monopoly practices, fined billions. 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. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-03 11:34 +0200 |
| Message-ID | <ms9441$m61$1@dont-email.me> |
| In reply to | #69067 |
On 03/09/15 10:26, Rick C. Hodgin wrote: > Philip Lantz wrote: >> I agree, it seems very wasteful of cache. As far >> as I can tell, it is only to simplify the >> implementation of varargs functions, but I >> don't see why they didn't make the >> requirement apply to varargs functions only, >> since they are a tiny minority of functions. > > Something occurred to me. AMD released specs > publicly for x86-64 on August 10, 1999 IIRC. At > that time, Intel was working on their own proprietary > 64-bit solution, called Itanium, with Merced being > first released in May, 2001 IIRC. > > Merced CPUs would've been in silicon and being > tested and developed for by the late 90s. So I'm > wondering if this wasn't a purposeful decision by > Microsoft to harm AMD's offering in favor of their > "Wintel" partnership? Supporting their partner by > hobbling x86-64 in this way. > > Wouldn't surprise me at all. Both Microsoft and > Intel have been found guilty in various international > courts of monopoly practices, fined billions. > > 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. > That seems unlikely. Microsoft has always been quite happy to work with other x86 manufacturers - it's only with non-x86 architectures that they are reluctant (they did make Windows NT for the PPC, MIPS and Alpha - but they expected the cpu manufacturers to pay for the development!). At that time, MS's compiler was not particularly highly optimising, AFAIUI. It was okay, but not great. And their debugger was poor, especially for optimised code. This was all for C only, not C++. Thus their emphasis was on making a calling convention that was relatively easy to integrate with their C compiler, would work reasonably well with C code (including varargs functions), and would work well with their debugger. 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. I don't think MS actually saw much of a market for x86-64 at the time - certainly not in the immediate future. It was worth paying attention, but not investing much money in ABI's, API's, tools, etc. Remember, at that time most desktops were running a 16-bit/32-bit hybrid (Win98, then WinME - both running on top of 16-bit DOS). Professional use had mostly switched to the full 32-bit NT4 and then W2K, but no one expected mass-market Windows systems to be 64-bit any time soon. The exception would be in server systems, and it made more sense to bet on Intel's IA64 for that. 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-03 03:15 -0700 |
| Message-ID | <a0fbdcf4-b3eb-4308-869f-e2eb8d80f769@googlegroups.com> |
| In reply to | #69080 |
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.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web