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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | owen.jacobson@grimoire.ca |
|---|---|
| Date | 2015-07-24 08:32 -0700 |
| Message-ID | <423e68dd-b265-4402-9a5b-087d89b54e4b@googlegroups.com> |
| In reply to | #66125 |
On Tuesday, July 21, 2015 at 4:21:49 PM UTC-4, Bart wrote: > One problem I posted about a couple of years ago was along these lines: > > * You have a pointer to a function (which happens to be to an external, > runtime-loaded dynamic library function, but I'm not sure it matters) > > * You know, at runtime, the number of parameters N, and the types of > each parameter, and the return type (encoded as integers according to > some scheme). > > * There is an array of arguments to be passed (consider each element to > be a union of possible integer, float and pointer types). > > The problem I had then was you couldn't write, in C, a function call > with a variable number of arguments (to a function taking a fixed > number). It is only possible to do this: > > retval = ((<cast>)fnptr) (params[0], params[1], params[2]); > > but that covers the N==3 case only. If NMAX is 15, say, then there are > 16 lines like the above to write, when the return type is int. Plus > another 16 for float (because usually the value is in a different kind > of register), so 32 in total. > > Then there might be C and Windows call conventions, so we're looking at > 64 combinations (with 64 kinds of cast to apply to fnptr). > > Apparently there is is no other solution in C, so I went along with that > (not all combinations are populated; they are only added as needed). > > ------------------------------------------------------------------ > > But now there is another twist, which is due to the calling conventions > used with x64: the first 4 to 6 parameters are passed in general purpose > registers for integers, and XMM registers for floats/doubles. > > That means I can't use my generic params[] list as above; I have to > specify whether each argument is a integer or float. That means that for > N parameters, there could be 2**N different combinations of integer or > float arguments. > > Obviously writing tens of thousands of lines is no longer viable (it > won't be that many as functions that take floats don't usually have lots > of parameters, but it will be enough.) > > I just wondered if anyone had any ideas .... I'd start by looking at how other languages implement foreign function binding, since it's the same shape of problem. It turns out a lot of languages now use libffi[0] for this very thing, and it appears to build on Windows. -o [0] https://sourceware.org/libffi/
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-07-24 18:48 +0000 |
| Message-ID | <mou1a8$cje$1@news.xmission.com> |
| In reply to | #66283 |
In article <423e68dd-b265-4402-9a5b-087d89b54e4b@googlegroups.com>, <owen.jacobson@grimoire.ca> wrote: ... >I'd start by looking at how other languages implement foreign function binding, >since it's the same shape of problem. It turns out a lot of languages now use >libffi[0] for this very thing, and it appears to build on Windows. I looked at libffi briefly. Haven't gotten around to downloading/compiling it yet. Thanks for the pointer. It looks like a somewhat more polished version of ffcall (avcall). It looks like OSX-64 is still not supported, though. -- "The God of the Old Testament is arguably the most unpleasant character in all fiction: jealous and proud of it; a petty, unjust, unforgiving control-freak; a vindictive, bloodthirsty ethnic cleanser; a misogynistic, homophobic, racist, infanticidal, genocidal, filicidal, pestilential, megalomaniacal, sadomasochistic, capriciously malevolent bully." - Richard Dawkins, The God Delusion -
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-24 20:22 +0100 |
| Message-ID | <mou36s$p8g$1@dont-email.me> |
| In reply to | #66283 |
On 24/07/2015 16:32, owen.jacobson@grimoire.ca wrote: > I'd start by looking at how other languages implement foreign function binding, since it's the same shape of problem. It turns out a lot of languages now use libffi[0] for this very thing, and it appears to build on Windows. > [0] https://sourceware.org/libffi/ How much would it dwarf my application though? (It comprises some 300 files (pre-config and pre-make), requires a 22000-line configuration script that doesn't run on Windows, and a 'make' script. How many files would need to be added to my project? Would my users need to bother their heads about any special requirements or configuration that would be dragged in by this library?) I specialise in small, tidy, self-contained applications, and third party libraries such as this, just to solve one small problem in one feature out of hundreds, would not be appropriate. If I did it for every feature, it would hardly get out the door! And be as much of a nightmare to build as all those other interpreters. Mine has to be a bit different otherwise there's no point. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-25 03:03 -0700 |
| Message-ID | <8ee5bff2-b54c-4d82-bb49-687ed84708fe@googlegroups.com> |
| In reply to | #66305 |
On Friday, July 24, 2015 at 8:22:39 PM UTC+1, Bart wrote: > > How much would it dwarf my application though? (It comprises some 300 > files (pre-config and pre-make), requires a 22000-line configuration > script that doesn't run on Windows, and a 'make' script. How many files > would need to be added to my project? Would my users need to bother > their heads about any special requirements or configuration that would > be dragged in by this library?) > > I specialise in small, tidy, self-contained applications, and third > party libraries such as this, just to solve one small problem in one > feature out of hundreds, would not be appropriate. > > If I did it for every feature, it would hardly get out the door! And be > as much of a nightmare to build as all those other interpreters. Mine > has to be a bit different otherwise there's no point. > Exactly. That's the whole premise behind the tiff loader. You can get lib tiff lib Sam Leffler, and it's good piece of work. But it's not as useful for portable utilities.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-07-25 13:32 -0700 |
| Message-ID | <1d297043-5cf2-46a5-9c9f-73fb62218d01@googlegroups.com> |
| In reply to | #66125 |
Bart,
I haven't had time to test the actual functionality of this code, or to
run through permutations relating to the parameters. It seems to generate
code which compiles correctly using my hard-coded 4 and 16 values, 4 for
the number of variable parameters, and 16 for the maximum number of params
that are defined, for the hard-coded filenames:
dllfuncs.c
dllfuncs_1.h
dllfuncs_2.h
dllfuncs_3.h
Generate the dllfuncs*.* files from the command prompt, and then include
the dllfuncs.c program in your compilation list. It should be self-
contained, and compile correctly for linking.
Source code:
https://github.com/RickCHodgin/libsf/tree/master/source/unsorted/gencode
Please report any errors. Thank you.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-25 23:28 +0100 |
| Message-ID | <mp12ga$8ku$1@dont-email.me> |
| In reply to | #66354 |
On 25/07/2015 21:32, Rick C. Hodgin wrote: > dllfuncs.c > dllfuncs_1.h > dllfuncs_2.h > dllfuncs_3.h > > Generate the dllfuncs*.* files from the command prompt, and then include > the dllfuncs.c program in your compilation list. It should be self- > contained, and compile correctly for linking. > > Source code: > > https://github.com/RickCHodgin/libsf/tree/master/source/unsorted/gencode OK, I've had a quick look at the files generated, and the two big files come to some 18000 lines. Even allowing for not all lines being a call, that's a lot more combinations than I anticipated. I was starting to think today about what exactly to do about this. But if the best solution is to generate large numbers of different calls, then my figures are different. In the tables below, it assumed there are 0 to 15 arguments (although each additional argument has a small extra cost of 1, 2, 32 or 128 lines for each group). Arguments are numbered 1 to 15, with argument '0' informally used to refer to the return type (which must figure in the permutations). Here, I'm only interested in floating point or not floating point (ie. int, char or pointer, not struct nor complex or anything like that). The first two tables are when there is at least one floating point argument in the first 4 or 6, and/or the return type is floating point. This is the complicated case that the thread is about: Win64 (first 4 arguments in GP/XMM registers): Nargs: Call combinations for each Nargs: 0 to 0 2 0 to 1 4 0 to 2 8 0 to 3 16 0 to 4 32 0 to 5 32 Arguments 5+ pushed as 64-bit int patterns 0 to 6 32 0 to 7 32 0 to 8 32 0 to 9 32 0 to 10 32 0 to 11 32 0 to 12 32 0 to 13 32 0 to 14 32 0 to 15 32 Total: 414 Linux64 (first 6 arguments in GP/XMM registers): NArgs: Call combinations for each Nargs: 0 to 0 2 0 to 1 4 0 to 2 8 0 to 3 16 0 to 4 32 0 to 5 64 0 to 6 128 0 to 7 128 Arguments 7+ as 64-bit int patterns 0 to 8 128 0 to 9 128 0 to 10 128 0 to 11 128 0 to 12 128 0 to 13 128 0 to 14 128 0 to 15 128 Total: 1406 Win64/Linux64 where no argument or return value is floating point: NArgs: Call combinations for each Nargs: 0 to 0 1 0 to 1 1 All arguments pushed as int patterns 0 to 2 1 0 to 3 1 0 to 4 1 0 to 5 1 0 to 6 1 0 to 7 1 0 to 8 1 0 to 9 1 0 to 10 1 0 to 11 1 0 to 12 1 0 to 13 1 0 to 14 1 0 to 15 1 Total: 16 For 32-bit targets, then after 64-bit ints/floats are been expanded to two 32-bit arguments each, then it looks like the following. There will be two for each Nargs: floating point return type/non-floating point return type: NArgs: Call combinations for each Nargs: 0 to 0 2 0 to 1 2 All arguments pushed as int patterns 0 to 2 2 0 to 3 2 0 to 4 2 0 to 5 2 0 to 6 2 0 to 7 2 0 to 8 2 0 to 9 2 0 to 10 2 0 to 11 2 0 to 12 2 0 to 13 2 0 to 14 2 0 to 15 2 Total: 32 Except (1) Maximum number of arguments might be as little as 7 or 8 if all are 64 bits, so might need to go a bit further. (2) With 32 bits, there might be several different call coventions, so the above might need to be duplicated further, so perhaps 4 or 6 combinations per Nargs. But it will still be simpler overall than the floating point calls in 64-bit. (Intended targets are x86, x64, and 32-bit ARM; Windows and Linux. I'm not looking at any completely general solution. Basically, I want to be able to run libraries such as OpenGL directly from interpreted code.) Anyway, even if all permutations are present, it's under 2000 call combinations (although some of the lines will be quite long; there might need to be casts, but that can be applied per-call I think). I suspect though that the vast majority will never be used. However ... after all that, I think I will start off by trying the 'dummy call' method and seeing how well that works. With the above method of dispatching to large numbers of call-patterns kept in reserve or used when I need to generate a distribution. (BTW you should really try using a scripting language when generating one-off stuff like this. Your C code looks gorgeous, but it's an unnecessary extra effort for something that will be run once, for a fraction of a second!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-07-26 06:18 -0700 |
| Message-ID | <a2728038-dfad-41e9-b385-a6a69a7c80c8@googlegroups.com> |
| In reply to | #66365 |
Bart wrote: > (BTW you should really try using a scripting > language when generating one-off stuff like > this. Your C [is] an unnecessary extra effort > for something that will be run once, for a > fraction of a second!) Ready for something mind blowing? I had the idea while writing this to extend its abilities to write out source code which is created, compiled, and dynamically loaded at runtime, employing only those functions that have been dynamically requested by the user in the runtime environment. In that way, a "cache" can be built up which does something simple like SHA-1 hashing to determine if the definition they have is old or new, and if old reuse the cache, and if new reparse, regenerate, and reload like normal. Would be interesting. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-07-26 13:39 +0000 |
| Message-ID | <mp2nu8$c09$1@news.xmission.com> |
| In reply to | #66404 |
In article <a2728038-dfad-41e9-b385-a6a69a7c80c8@googlegroups.com>, Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: >Bart wrote: >> (BTW you should really try using a scripting >> language when generating one-off stuff like >> this. Your C [is] an unnecessary extra effort >> for something that will be run once, for a >> fraction of a second!) > >Ready for something mind blowing? I had the >idea while writing this to extend its abilities to >write out source code which is created, compiled, >and dynamically loaded at runtime, employing >only those functions that have been dynamically >requested by the user in the runtime environment. Those who do not get "avcall" are bound to re-invent it. Over and over and over again. Badly. P.S. Actually, I've been working with libffi lately (which I found out about because of a pointer posted somewhere in this thread). It is a lot more complex and a lot harder to use than avcall, but it has the one sole redeeming value that it *does* work on OSX-64. Note that I had reported earlier that it didn't look like it (libffi) did support OSX-64, but that turned out to be an error, because they refer to OSX as "Darwin". So you have to search the features list for Darwin rather than for OSX. -- Faith doesn't give you the answers; it just stops you from asking the questions.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-07-26 07:33 -0700 |
| Message-ID | <181a91cd-a0cf-48a5-8fab-617326870e9f@googlegroups.com> |
| In reply to | #66406 |
This little project here has really gotten me thinking about runtime-created, compiled, and dynamically linked code. An examination of the runtime environment could yield advantages a static pre-launch expectation could not. And as Bart says, it takes so little time to generate, and, for small bits of code, compile. Might be worth investigating a completely dynamic application which self-assembles itself as required, as per runtime needs. Instant startup, brief pauses when entering something the first time, oft-used components are cached making their re-use almost instantaneous. I will consider this. Best regards, Rick C. Hodgin PS - I wonder if this would work for dynamically reconfiguring hardware at runtime? I have proposed an idea for an ISA that allows runtime compilation to leverage machine resources at the hardware opcode level in dynamic ways. I see a patteen emerging.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-26 16:21 +0100 |
| Message-ID | <mp2tq4$av4$1@dont-email.me> |
| In reply to | #66407 |
On 26/07/2015 15:33, Rick C. Hodgin wrote: > This little project here has really gotten me > thinking about runtime-created, compiled, and > dynamically linked code. An examination of the > runtime environment could yield advantages a > static pre-launch expectation could not. And as > Bart says, it takes so little time to generate, and, for small bits of code, compile. > > Might be worth investigating a completely > dynamic application which self-assembles itself > as required, as per runtime needs. Instant > startup, brief pauses when entering something > the first time, oft-used components are cached > making their re-use almost instantaneous. This is one of the off-the-wall possibilities that I hinted at early in the thread (or the AVCALL one); trapping each new dynamic call combination, and compiling dedicated native code for each. (The difficulty is where that code is going to go, and how it will be accessed, a more challening problem than the original.) It can be practical in some cases, but this imposes a requirement to have C compiler system lying around. Although I will have it at my machine (1), and if I distribute my program as C source, the user building it will have at theirs (2), the resultant application might be running at a third site (3), where they are not going to have a compiler available. (Or the more likely scenerio is I distribute a packaged interepreter + bytecode application which should just work. It would be unreasonable for the user to have a large sprawling C compiler too! And he would anywway install it in the wrong place. I sent a simple application to someone which should have been installed in C:\appldir. When I looked at his machine it was somehow installed instead in: C:\Users\computername\Desktop\DATA\Desktop\APPLDIR\appldir (Yes, with two Desktops and two appldirs!) You can make things as simple as possible, and people will still get it wrong.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-07-26 08:39 -0700 |
| Message-ID | <ee9e31d5-3dd9-489e-8bcf-61df510110c0@googlegroups.com> |
| In reply to | #66409 |
You're very clever, Bart -- out of the box thinking. Reminds me of the Bochs emulator slogan: "Think inside the Bochs," which is different in this case, of course. LOL! :-) Still similar though. I've been thinking about this in the context of my RDC (C-like) compiler which supports edit- and-continue (which I call LiveCode). Such an infrastructure would make the system easy to implement, and it could be done almost completely transparently with existing resources on that ABI. I think it's an exciting possibility. It's like having some replicators lying around ready to fabricate whatever's needed, rather than bulk storehouses with a wide, yet fixed, range of inventory parts. Replicators have all inventory parts within, and are therefore much more flexible, and configurable, addressing all needs as they're needed. They do require more immediate power than storehouses, but so long as things are equal that wouldn't be an issue. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-26 05:37 -0700 |
| Message-ID | <176eef6c-2106-4439-8ed9-2d190c0614b0@googlegroups.com> |
| In reply to | #66125 |
On Tuesday, July 21, 2015 at 4:21:49 PM UTC-4, Bart wrote:
> One problem I posted about a couple of years ago was along these lines:
>
> * You have a pointer to a function (which happens to be to an external,
> runtime-loaded dynamic library function, but I'm not sure it matters)
>
> * You know, at runtime, the number of parameters N, and the types of
> each parameter, and the return type (encoded as integers according to
> some scheme).
>
> * There is an array of arguments to be passed (consider each element to
> be a union of possible integer, float and pointer types).
>
> The problem I had then was you couldn't write, in C, a function call
> with a variable number of arguments (to a function taking a fixed
> number). It is only possible to do this:
>
> retval = ((<cast>)fnptr) (params[0], params[1], params[2]);
>
> but that covers the N==3 case only. If NMAX is 15, say, then there are
> 16 lines like the above to write, when the return type is int. Plus
> another 16 for float (because usually the value is in a different kind
> of register), so 32 in total.
>
> Then there might be C and Windows call conventions, so we're looking at
> 64 combinations (with 64 kinds of cast to apply to fnptr).
>
> Apparently there is is no other solution in C, so I went along with that
> (not all combinations are populated; they are only added as needed).
>
> ------------------------------------------------------------------
>
> But now there is another twist, which is due to the calling conventions
> used with x64: the first 4 to 6 parameters are passed in general purpose
> registers for integers, and XMM registers for floats/doubles.
>
> That means I can't use my generic params[] list as above; I have to
> specify whether each argument is a integer or float. That means that for
> N parameters, there could be 2**N different combinations of integer or
> float arguments.
>
> Obviously writing tens of thousands of lines is no longer viable (it
> won't be that many as functions that take floats don't usually have lots
> of parameters, but it will be enough.)
>
> I just wondered if anyone had any ideas ....
>
> --
> Bartc
I have implemented this in 32-bit form in Visual FreePro, Jr. I am
getting ready to debug and test the 32-bit version today, and, Lord
willing, to code the 64-bit version later today. After that, I will
turn my full attention to the compiler.
-----
The 32-bit code begins around line 118, with the assembly code block
beginning around 416 thru 569. It supports input parameters of varying
types, and is able to retrieve return parameters:
https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/dllfuncs/dllfuncs.cpp
Variable types supported:
void // Used only for the return type (when there is no return type)
s8, u8 (int8_t, pushed as 32-bit)
s16, u16 (int16_t, pushed as 32-bit)
s32, u32 (int32_t)
s64, u64 (int64_t)
f32, f64 (float, double)
void* // Handles generic access to indirect things
Windows IDispatch* object // Handles access to Windows objects
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-26 14:36 +0100 |
| Message-ID | <mrkf90$ucj$1@dont-email.me> |
| In reply to | #68399 |
On 26/08/2015 13:37, Rick C. Hodgin wrote:
> On Tuesday, July 21, 2015 at 4:21:49 PM UTC-4, Bart wrote:
>> But now there is another twist, which is due to the calling conventions
>> used with x64: the first 4 to 6 parameters are passed in general purpose
>> registers for integers, and XMM registers for floats/doubles.
>> Obviously writing tens of thousands of lines is no longer viable
> I have implemented this in 32-bit form in Visual FreePro, Jr. I am
> getting ready to debug and test the 32-bit version today, and, Lord
> willing, to code the 64-bit version later today. After that, I will
> turn my full attention to the compiler.
>
> -----
> The 32-bit code begins around line 118, with the assembly code block
> beginning around 416 thru 569. It supports input parameters of varying
> types, and is able to retrieve return parameters:
>
> https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/dllfuncs/dllfuncs.cpp
I hope you haven't done this just for me. Because your solution is very
comprehensive (I'm mainly dealing with lumps of data that happen to be
32 bits or 64 bits wide; the complication was that some 64-bit lumps
might need passing in special registers.)
But also it seems to use ASM so it's no good. I can code my own ASM
solution; I wanted one in C! (I prefer to use ASM only as an optional
add-on used to provide a faster solution, but it should work without too.)
I've had to put aside this rather untidy problem, which seems to be one
of organisation. I'm coding in a non-C language and the various
combinations of target and OS don't help:
OS:
Windows32 Windows64 Linux32 Linux64
Target:
X64 -- A -- B (x64 only)
C32 C (C) D (D)
C64 -- E -- F
The 'target' is the output of my compiler. I've just finished upgrading
it to use proper 64-bit pointers (and enable C64) to make life simpler.
That still leaves scenarios A thru F to deal with! But looking only at
the A,C,E versions for Windows:
C32/C has distinct C and Windows call conventions. But floating point
arguments are passed like integer/pointer ones. ((C) just runs
under Windows64 in 32-bit mode.)
C64/E uses Fastcall so only one call convention. But floating point
arguments have to be passed in XMM registers. This was the
problem. I was going to use my idea to do dummy pushes of floating
point arguments to get things in the right place.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-26 06:46 -0700 |
| Message-ID | <90bdf741-7fc2-425c-a515-059d38d678d3@googlegroups.com> |
| In reply to | #68412 |
On Wednesday, August 26, 2015 at 9:36:21 AM UTC-4, Bart wrote:
> On 26/08/2015 13:37, Rick C. Hodgin wrote:
> > On Tuesday, July 21, 2015 at 4:21:49 PM UTC-4, Bart wrote:
>
> >> But now there is another twist, which is due to the calling conventions
> >> used with x64: the first 4 to 6 parameters are passed in general purpose
> >> registers for integers, and XMM registers for floats/doubles.
>
> >> Obviously writing tens of thousands of lines is no longer viable
>
> > I have implemented this in 32-bit form in Visual FreePro, Jr. I am
> > getting ready to debug and test the 32-bit version today, and, Lord
> > willing, to code the 64-bit version later today. After that, I will
> > turn my full attention to the compiler.
> >
> > -----
> > The 32-bit code begins around line 118, with the assembly code block
> > beginning around 416 thru 569. It supports input parameters of varying
> > types, and is able to retrieve return parameters:
> >
> > https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/dllfuncs/dllfuncs.cpp
>
> I hope you haven't done this just for me. Because your solution is very
> comprehensive (I'm mainly dealing with lumps of data that happen to be
> 32 bits or 64 bits wide; the complication was that some 64-bit lumps
> might need passing in special registers.)
No. This is the actual DLL code that will run in Visual FreePro, Jr.
However, I was inspired by you to do it now rather than later. :-)
But it still needed to be done at some point.
> But also it seems to use ASM so it's no good. I can code my own ASM
> solution; I wanted one in C! (I prefer to use ASM only as an optional
> add-on used to provide a faster solution, but it should work without too.)
I don't think I'll ever write a C-only version. I wouldn't know how
to start in C-only code (apart from using the methods indicated
previously in this thread, but I have no experience in those ways of
processing parameters, so it would all be trial-and-error).
> I've had to put aside this rather untidy problem, which seems to be one
> of organisation. I'm coding in a non-C language and the various
> combinations of target and OS don't help:
>
> OS:
> Windows32 Windows64 Linux32 Linux64
> Target:
> X64 -- A -- B (x64 only)
> C32 C (C) D (D)
> C64 -- E -- F
>
> The 'target' is the output of my compiler. I've just finished upgrading
> it to use proper 64-bit pointers (and enable C64) to make life simpler.
>
> That still leaves scenarios A thru F to deal with! But looking only at
> the A,C,E versions for Windows:
>
> C32/C has distinct C and Windows call conventions. But floating point
> arguments are passed like integer/pointer ones. ((C) just runs
> under Windows64 in 32-bit mode.)
>
> C64/E uses Fastcall so only one call convention. But floating point
> arguments have to be passed in XMM registers. This was the
> problem. I was going to use my idea to do dummy pushes of floating
> point arguments to get things in the right place.
I almost have this DLL code debugged. I've had to add some support
for calling it in the two forms observed in source code:
(1) A standalone, like "Sleep(5000)": dllFunc(...)
(2) Assignment, like "f = CreateFont(...)": x = dllFunc(...)
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-26 16:11 +0100 |
| Message-ID | <mrkkrs$lh1$1@dont-email.me> |
| In reply to | #68414 |
On 26/08/2015 14:46, Rick C. Hodgin wrote: Bartc: >> I've had to put aside this rather untidy problem, which seems to be one of organisation > I almost have this DLL code debugged. I've had to add some support > for calling it in the two forms observed in source code: > > (1) A standalone, like "Sleep(5000)": dllFunc(...) > (2) Assignment, like "f = CreateFont(...)": x = dllFunc(...) Don't forget the case of x = dllFunct(...,dllFunct(...(dllFunct...))). Plus the case where, once it's in the DLL function, it triggers a callback to your code which leads to another x=dllFunct(...) before it's returned from the first. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-26 08:20 -0700 |
| Message-ID | <9fe77988-b90c-4093-a536-e6fa6dbe9b14@googlegroups.com> |
| In reply to | #68425 |
On Wednesday, August 26, 2015 at 11:11:44 AM UTC-4, Bart wrote: > On 26/08/2015 14:46, Rick C. Hodgin wrote: > > Bartc: > >> I've had to put aside this rather untidy problem, which seems to be > one of organisation > > > I almost have this DLL code debugged. I've had to add some support > > for calling it in the two forms observed in source code: > > > > (1) A standalone, like "Sleep(5000)": dllFunc(...) > > (2) Assignment, like "f = CreateFont(...)": x = dllFunc(...) > > Don't forget the case of x = dllFunct(...,dllFunct(...(dllFunct...))). Each of those inner functions is still of the (2) assignment case. It's just that the "x" in "x = dllFunc(...)" is a temporary variable, that's then used as input to the follow-on. > Plus the case where, once it's in the DLL function, it triggers a > callback to your code which leads to another x=dllFunct(...) before it's > returned from the first. I do not support any callback abilities in my dispatch of DLL functions in Visual FreePro, Jr. because they are not supported in any XBASE language I'm aware of. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-27 16:53 -0700 |
| Message-ID | <083f838c-d986-4512-9cc6-ae743e3b436d@googlegroups.com> |
| In reply to | #66125 |
On Tuesday, July 21, 2015 at 4:21:49 PM UTC-4, Bart wrote: > One problem I posted about a couple of years ago was along these lines: > > * You have a pointer to a function (which happens to be to an external, > runtime-loaded dynamic library function, but I'm not sure it matters) > > * You know, at runtime, the number of parameters N, and the types of > each parameter, and the return type (encoded as integers according to > some scheme). > > * There is an array of arguments to be passed (consider each element to > be a union of possible integer, float and pointer types). > > The problem I had then was you couldn't write, in C, a function call > with a variable number of arguments (to a function taking a fixed > number). It is only possible to do this: > > retval = ((<cast>)fnptr) (params[0], params[1], params[2]); > > but that covers the N==3 case only. If NMAX is 15, say, then there are > 16 lines like the above to write, when the return type is int. Plus > another 16 for float (because usually the value is in a different kind > of register), so 32 in total. > > Then there might be C and Windows call conventions, so we're looking at > 64 combinations (with 64 kinds of cast to apply to fnptr). > > Apparently there is is no other solution in C, so I went along with that > (not all combinations are populated; they are only added as needed). > > ------------------------------------------------------------------ > > But now there is another twist, which is due to the calling conventions > used with x64: the first 4 to 6 parameters are passed in general purpose > registers for integers, and XMM registers for floats/doubles. > > That means I can't use my generic params[] list as above; I have to > specify whether each argument is a integer or float. That means that for > N parameters, there could be 2**N different combinations of integer or > float arguments. > > Obviously writing tens of thousands of lines is no longer viable (it > won't be that many as functions that take floats don't usually have lots > of parameters, but it will be enough.) > > I just wondered if anyone had any ideas .... Bart, what assembler are you using for Windows x64? Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-28 01:03 +0100 |
| Message-ID | <mro8e7$cee$1@dont-email.me> |
| In reply to | #68540 |
On 28/08/2015 00:53, Rick C. Hodgin wrote: > Bart, what assembler are you using for Windows x64? Nasm 2.x. Not the fastest, but to switch to something like the faster GoAsm is too much effort. As is bypassing an external assembler and generating object code directly. (Usually the Nasm code is generated by my compiler when I'm not targeting C. I don't write Nasm directly unless it's inline assembly.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-30 05:36 -0700 |
| Message-ID | <4e92d3ea-d33a-497f-9744-e4b696c6f9e3@googlegroups.com> |
| In reply to | #68542 |
On Thursday, August 27, 2015 at 8:04:10 PM UTC-4, Bart wrote:
> On 28/08/2015 00:53, Rick C. Hodgin wrote:
>
> > Bart, what assembler are you using for Windows x64?
>
> Nasm 2.x. Not the fastest, but to switch to something like the faster
> GoAsm is too much effort. As is bypassing an external assembler and
> generating object code directly.
>
> (Usually the Nasm code is generated by my compiler when I'm not
> targeting C. I don't write Nasm directly unless it's inline assembly.)
I have had experience with MASM 1.0 through 6.11d back in the day with
the work on my operating system, nearly all of which the kernel code
was written in assembly:
https://github.com/RickCHodgin/libsf-full/tree/master/_exodus/source
http://www.visual-freepro.org/videos/2014_02_13__exodus_debi_debugger.ogv
I searched for a version of MASM which came with Visual Studio and I
found that it exists. It's "ml64.exe". I also found when I broke out
my asm code into separate asm files (one for 32-bit, and one for 64-bit)
and added them back into the project, it automatically added a build
script for it, roughly equivalent of:
ml64 /c /Zi dll_dispatch_64.asm
-----
Anyway, I was pleased that this worked. I've gone ahead and posted
here my 32-bit and 64-bit DLL solution. As of the time of this
writing the 32-bit is working correctly (to my testing so far), and
the 64-bit is dispatching, but it is presently (as of GitHub push
below) pushing parameters in the reverse order. I'll be rewriting
that algorithm today (Lord willing), so it should be working
correctly soon:
Source code for generic DLL call support. Note, the 32-bit DLL is
a direct #include file with the _asm { } block. But, since VS2010
doesn't support inline AMD64 assembly, I had to create it as an
actual stand-alone assembly source file assembled with ml64.exe:
https://github.com/RickCHodgin/libsf/tree/master/source/vjr/source/dllfuncs
https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/dllfuncs/dllfuncs.cpp
https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/dllfuncs/dll_dispatch_32.asm
https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/dllfuncs/dll_dispatch_64.asm
Here's the commit which is referenced above. Some commit after this
should have the 64-bit dispatch working properly (Lord willing):
https://github.com/RickCHodgin/libsf/commit/1e2672c2f0d3f2fb4e8a1392d211b7ad779da371
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-30 06:35 -0700 |
| Message-ID | <c449cf18-11d3-4cf1-8008-c3ea51d68701@googlegroups.com> |
| In reply to | #68683 |
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:
-----[ Start C Program ]-----
#include <stdio.h>
#include <tchar.h>
void test(int i1, float f1,
int i2, float f2,
int i3, float f3,
int i4, float f4,
int i5, float f5,
int i6, float f6,
int i7, float f7)
{
printf("%f %f %f %f %f %f %f\n", f1, f2, f3, f4, f5, f6, f7);
printf("%d %d %d %d %d %d %d\n", i1, i2, i3, i4, i5, i6, i7);
}
int _tmain(int argc, _TCHAR* argv[])
{
int i1, i2, i3, i4, i5, i6, i7;
float f1, f2, f3, f4, f5, f6, f7;
i1 = 1; i2 = 2; i3 =3; i4 = 4; i5 = 5; i6 = 6; i7 = 7;
f1 = 1.0f; f2 = 2.0f; f3 = 3.0f; f4 = 4.0f; f5 = 5.0f; f6 = 6.0f; f7 = 7.0f;
test(i1, f1,
i2, f2,
i3, f3,
i4, f4,
i5, f5,
i6, f6,
i7, f7);
return 0;
}
-----[ End C Program ]-----
-----[ 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.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web