Re: [perl #53430] [PATCH] Concat call_list.txt from fragments in config step
On Mon, 2008-04-28 at 08:44 -0700, Geoffrey Broadwell wrote: I'm not wedded to splitting them up as much as I did. In fact, I'd be fine with core.in, opengl.in, and misc.in. Better for you? chromatic confirmed on IRC that this was his preference, saying also that this arrangement solves another problem we'll run into eventually [...] Knowing which thunks we need for a core even if we disable NCI in general. It's possible that a couple of the sigs in misc.in should be in core.in or vice-versa, but I tried my best to get them straightened out using the limited comments. (Any remaining missorted sigs can be straightened out in a separate RT ticket when we actually create an NCI disabled build; I gather that will be some time down the line.) After this patch is applied 53406 will have to be regenerated, but that was planned anyway because chromatic asked for 53406 to be rewritten using BigInt functionality. In any case, this version of the patch should be acceptable to chromatic and do no harm to the build; please apply. -'f === MANIFEST == --- MANIFEST (revision 5076) +++ MANIFEST (local) @@ -292,6 +292,10 @@ config/auto/va_ptr/test_c.in[] config/auto/warnings.pm [] config/auto/warnings/test_c.in [] +config/gen/call_list.pm [] +config/gen/call_list/core.in[] +config/gen/call_list/misc.in[] +config/gen/call_list/opengl.in [] config/gen/config_h.pm [] config/gen/config_h/config_h.in [] config/gen/config_h/feature_h.in[] @@ -2701,7 +2705,6 @@ src/bignum.h[] src/builtin.c [] src/byteorder.c [] -src/call_list.txt [devel]doc src/charset.c [] src/charset/ascii.c [] src/charset/ascii.h [] @@ -3536,6 +3539,7 @@ t/steps/auto_warnings-06.t [] t/steps/auto_warnings-07.t [] t/steps/auto_warnings-08.t [] +t/steps/gen_call_list-01.t [] t/steps/gen_config_h-01.t [] t/steps/gen_config_pm-01.t [] t/steps/gen_core_pmcs-01.t [] === MANIFEST.generated == --- MANIFEST.generated (revision 5076) +++ MANIFEST.generated (local) @@ -285,6 +285,7 @@ languages/squaak/squaak.pbc [main] languages/tcl/tcl.pbc [main] languages/tcl/runtime/tcllib.pbc [main] +src/call_list.txt [devel]doc src/glut_callbacks.c [main] src/jit_emit.h[main]include src/nci.c [main] === config/gen/call_list (new directory) == === config/gen/call_list/core.in == --- config/gen/call_list/core.in (revision 5076) +++ config/gen/call_list/core.in (local) @@ -0,0 +1,115 @@ +# Copyright (C) 2002-2008, The Perl Foundation. + +# DO NOT EDIT THIS FILE. +# +# Any changes made here will be lost. +# +# This file is generated automatically by config/gen/call_list.pm +# using config/gen/call_list/*.in . + + +# Function signature declarations for Parrot Native Call Interface. +# The first alphanumeric is the type of the return value, +# the other alphanumerics denote the input parameter types. + +# Types + +# INT register stuff +# I - INTVAL +# c - char +# s - short +# i - int +# l - long + +# NUM register stuff +# N - FLOATVAL +# f - float +# d - double + +# STR register stuff +# S - pointer to a STRING-register +# t - character string (0-terminated) +# Buffers are not valid return parameters, +# use 'p' when the native function returns a pointer value +# b - void * +# B - void ** + +# PMC register stuff +# P - pointer to a PMC-register +# O - pointer to PMC-register (object) +# p - data pointer from PMC (on store into a new UnManagedStruct PMC) +# 2 - pointer to short +# 3 - pointer to int +# 4 - pointer to long + +# void stuff +# v - void + +# special stuff +# 0 - insert a NULL (pointer) - doesn't consume a register +# J - Parrot_Interp param +# @ - slurpy array + +# callback stuff +# U - Single PMC parameter to pass into callback - user data + +#
Re: [perl #53430] [PATCH] Concat call_list.txt from fragments in config step
On Tuesday 06 May 2008 19:26:46 Geoffrey Broadwell wrote: On Mon, 2008-04-28 at 08:44 -0700, Geoffrey Broadwell wrote: I'm not wedded to splitting them up as much as I did. In fact, I'd be fine with core.in, opengl.in, and misc.in. Better for you? chromatic confirmed on IRC that this was his preference, saying also that this arrangement solves another problem we'll run into eventually [...] Knowing which thunks we need for a core even if we disable NCI in general. Thanks, applied as r27371. -- c
Re: [perl #53430] [PATCH] Concat call_list.txt from fragments in config step
On Sunday 27 April 2008 17:04:10 Geoffrey Broadwell wrote: Currently, src/call_list.txt is a static file; any time new NCI signatures are needed, it is edited manually. For very large APIs with many unique signatures that may vary from platform to platform (OpenGL), this is suboptimal. There are (at least) two problems with this: 1. Even if a large API is disabled (because it wasn't detected, or because Configure.pl was called with a --without-foo option), the unused NCI signatures are still compiled and included in the parrot library -- potentially several hundred K completely wasted. 2. When generating signatures from system headers, call_list.txt will need to be modified at Configure time anyway, so pretending it is static makes no sense. For this reason, I believe we should add a config step that concatenates src/call_list.txt from a directory of fragments. The attached patch makes just that change, splitting the existing call_list.txt into several smaller pieces in the process. I have checked that running Configure with the patch will produce a call_list.txt that contains the same signatures, though in a different order. Once this basic concept is accepted, then OpenGL (and potentially other libraries) can start generating the call_list fragment from system headers, and in particular not generating a fragment at all if OpenGL is disabled. This will come in a separate patch. (Currently the OpenGL fragment contains only a handful of signatures, just enough to get the triangle to spin. The generated version of opengl.in will contain 200-250 signatures.) I'm somewhat unconvinced, in general. For the OpenGL bindings, where the build process has to build specific C code which links against specific libraries, I can mostly see the point. For other bindings where it's possible to build Parrot without even having the libraries installed, install them later, and still use them (everything but the test libraries and OpenGL), there's little benefit. This just multiplies files based on which library needed a specific signature first. I'm not sure that will help us maintain them. As you say, the real problem is that we have a static list of NCI thunks known only at compile time. If it's easier to work on the OpenGL bindings in tree with a change like this, I can live with having a separate library of signatures merged in somehow, but I'm not sure that benefit outweighs the pain of splitting up everything else, especially given all of the hope that Kevin succeeds in his GSoC project. -- c
Re: [perl #53430] [PATCH] Concat call_list.txt from fragments in config step
On Mon, 2008-04-28 at 00:30 -0700, chromatic wrote: I'm somewhat unconvinced, in general. For the OpenGL bindings, where the build process has to build specific C code which links against specific libraries, I can mostly see the point. For other bindings where it's possible to build Parrot without even having the libraries installed, install them later, and still use them (everything but the test libraries and OpenGL), there's little benefit. Here you seem to be assuming that we will already have all of the NCI signatures we will need for any new library we come across. My experience (and my reading of comments in call_list.txt) is that that is very rarely true. At any given time, NCI seems be missing a handful of odd signatures needed by any new library we come across, which means that call_list.txt has to be updated and Parrot rebuilt anyway. nci.o is already needlessly large for users that don't need to load a pile of libraries; trying to include all common signatures will just make that worse. This just multiplies files based on which library needed a specific signature first. I'm not sure that will help us maintain them. I'm not wedded to splitting them up as much as I did. In fact, I'd be fine with core.in, opengl.in, and misc.in. Better for you? As you say, the real problem is that we have a static list of NCI thunks known only at compile time. If it's easier to work on the OpenGL bindings in tree with a change like this, It is. I can live with having a separate library of signatures merged in somehow, but I'm not sure that benefit outweighs the pain of splitting up everything else, especially given all of the hope that Kevin succeeds in his GSoC project. I'm trying to take advantage of the time I have now to get this OpenGL binding working well. As many of you can attest, my personal project time is very bursty -- I can't wait until the end of the summer, especially since there's no guarantee of success (though definitely my best wishes for success). I'm not trying to make the best choice for Parrot 1.0. I'm trying to make the best choice for Parrot 0.6.x. -'f
