* information sur camlidl (passage des tableaux)
@ 1999-08-03 9:41 Patrick Goldbronn - SYSCO
1999-08-15 13:25 ` Xavier Leroy
0 siblings, 1 reply; 2+ messages in thread
From: Patrick Goldbronn - SYSCO @ 1999-08-03 9:41 UTC (permalink / raw)
To: caml Inria
Bonjour,
J'essaie d'utiliser camlidl pour intégrer une librairie C permettant
d'accéder à des fichiers sous le format HDF.
La particularité de cette librairie est qu'elle ne fait pas d'allocation
mémoire. Lorsqu'on lit un tableau, il faut l'avoir alloué avant et le
passer en argument pour le remplir !
Le problème avec camlidl, c'est qu'il transforme le tableau caml en
tableau C et qu'il alloue un nouveau tableau caml qu'il remplit avec le
tableau C retourné.
Peut-on spécifier à camlidl qu'il s'agit en fait du meme tableau et
qu'il n'a pas besoin d'en creer un nouveau.
Autres remarques :
Pourquoi ne pas se servir du fait que les tableaux de double caml sont
les "memes" que les tableaux C et ne passer que le pointeur au lieu de
dupliquer (comme cela est fait pour les strings !).
Peut-on paramétrer camlidl pour qu'il fasse des actions spécifiques
selon le type de l'argument ?
Par exemple, j'utilise un type caml représentant un tableau de
dimensions quelconques contenant un tableau d'entier (les dimensions du
tableau) et un bloc avec le tag alloc_final contenant un pointeur vers
un tableau C.
type float_array = {
fvect : float_array_adr ;
fdims : int array ;
} ;;
Je définis une struct C le représentant.
struct float_array {
double *fvect ;
int *fdims ;
}
Comment dire à camlidl que "int* fdims" et "fdims : int array" doivent
etre recopié lorsqu'on passe de caml au C et réciproquement
(fonctionnement normal) et que "double *fvect" et "fvect :
float_array_adr" ne doivent pas être recopié mais simplement extraire
les pointeurs (en tenant compte de l'alloc_final) ?
( si j'ai bien compris la doc et le source générer, cela à voir avec les
fonctions ...c2ml... et ...ml2c...)
Merci d'avance.
PS : Peut-on trouver quelque part des exemples ou des informations
supplémentaires sur l'utilisation de camlidl ?
--
#####################################
# Patrick GOLDBRONN #
# CEA - DRN/DMT/SYSCO #
# CE-Saclay, Bâtiment 460 #
# 91191 GIF/YVETTE CEDEX (FRANCE) #
# #
# Tél : 01 69 08 40 66 #
# Fax : 01 69 08 96 96 #
#####################################
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: information sur camlidl (passage des tableaux)
1999-08-03 9:41 information sur camlidl (passage des tableaux) Patrick Goldbronn - SYSCO
@ 1999-08-15 13:25 ` Xavier Leroy
0 siblings, 0 replies; 2+ messages in thread
From: Xavier Leroy @ 1999-08-15 13:25 UTC (permalink / raw)
To: Patrick Goldbronn - SYSCO, caml Inria
> Le problème avec camlidl, c'est qu'il transforme le tableau caml en
> tableau C et qu'il alloue un nouveau tableau caml qu'il remplit avec le
> tableau C retourné.
> Peut-on spécifier à camlidl qu'il s'agit en fait du meme tableau et
> qu'il n'a pas besoin d'en creer un nouveau.
Actuellement, non. Cela pourrait en effet être intéressant pour un
tableau de "double" (voir ci-dessous). Pour les autres types de
tableau, une conversion de représentation Caml<->C des éléments du
tableau est nécessaire de toute façon, et les possibilités de partage
sont très réduites.
> Pourquoi ne pas se servir du fait que les tableaux de double caml sont
> les "memes" que les tableaux C et ne passer que le pointeur au lieu de
> dupliquer (comme cela est fait pour les strings !).
La principale raison est un problème d'alignement. Les tableaux Caml
de type "float array" sont (comme tous les blocs du tas Caml) alignés
en mémoire sur des frontières de mots Caml (4 octets sur les machines
32 bits, 8 octets sur les 64). Le code machine produit par les
compilateurs C et Fortran fait généralement l'hypothèse qu'un tableau
de "double" est aligné à 8 octets. Sur certains processeurs (Intel
x86, PowerPC), les accès à un "double" aligné à 4 ne posent pas de
problèmes (sauf une légère perte de vitesse); mais d'autres
processeurs (Sparc, MIPS en mode "R4000") plantent sur tout accès non
aligné à un "double". Enfin, sur les machines 64 bits, le problème ne
se pose pas car tout est aligné à 8 dans le tas Caml.
J'envisage de produire des "#ifdef" dans le code généré par CamlIDL
pour éviter la copie lorsque le processeur le permet.
Aussi, nous sommes en train de travailler sur une bibliothèque qui
fournira de "grands" tableaux numériques alloués hors du tas (afin de
contourner les limitations de tailles des tableaux Caml). Ces
tableaux seront bien sûr alignés à 8 et pourront être passés entre
Caml, C et Fortran sans aucune recopie.
> Peut-on paramétrer camlidl pour qu'il fasse des actions spécifiques
> selon le type de l'argument ?
Oui. Il faut jouer finement sur "typedef" et ses options dans le
source IDL. Par exemple, voici comment passer des "float array" de
Caml vers C sans les copier, en spécifiant sa propre fonction de
conversion Caml->C:
typedef [ml2c(float_array_ml2c)]
struct { int len; [size_is(len)] double data[]; }
float_array;
quote(C, "
void float_array_c2ml(value input, float_array * output)
{
output->len = Wosize_val(input) / Double_wosize;
output->data = &(Double_field(input, 0));
}
")
> PS : Peut-on trouver quelque part des exemples ou des informations
> supplémentaires sur l'utilisation de camlidl ?
Je n'ai pour le moment à vous offrir que la doc et les exemples qui se
trouvent dans la distribution (répertoire "tests").
- Xavier Leroy
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1999-08-22 18:17 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-08-03 9:41 information sur camlidl (passage des tableaux) Patrick Goldbronn - SYSCO
1999-08-15 13:25 ` Xavier Leroy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox