From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 61F1A7F8C9 for ; Tue, 19 Jan 2016 09:54:47 +0100 (CET) IronPort-PHdr: 9a23:RVPcHhE7rhY5UzpYFIh6aZ1GYnF86YWxBRYc798ds5kLTJ75o8uwAkXT6L1XgUPTWs2DsrQf27SQ4v+rADZZqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh770qsKYOl8RzBOGIppMbzyO5T3LsccXhYYwYo0Q8TDu5kVyRuJN2GlzLkiSlRuvru25/Zpk7jgC86l5r50IAu3GePEzRLlcSTAnKHwd5cvxtBCFQxHcyGEbVzAsgx1IDgmN0Bb5Q5v4+n/mselg1CCyJsOwQLs5WHK+6KdsSwKugSxBNSZvozKfsdB5kK8O+EHpnBd42YOBOIw= Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=tokuda@sf.ecei.tohoku.ac.jp; spf=None smtp.mailfrom=tokuda@sf.ecei.tohoku.ac.jp; spf=None smtp.helo=postmaster@mail1.is.tohoku.ac.jp Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of tokuda@sf.ecei.tohoku.ac.jp) identity=pra; client-ip=130.34.41.151; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="tokuda@sf.ecei.tohoku.ac.jp"; x-sender="tokuda@sf.ecei.tohoku.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of tokuda@sf.ecei.tohoku.ac.jp) identity=mailfrom; client-ip=130.34.41.151; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="tokuda@sf.ecei.tohoku.ac.jp"; x-sender="tokuda@sf.ecei.tohoku.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail1.is.tohoku.ac.jp) identity=helo; client-ip=130.34.41.151; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="tokuda@sf.ecei.tohoku.ac.jp"; x-sender="postmaster@mail1.is.tohoku.ac.jp"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMAgAG+Z1Wl5cpIoJehAxtBohQo2gBkVIahylDEAEBAQEBAQEBEAEBAQEBCBYHT4ItgiARfA8CJgIkEgEFAVeHeZ8MggeBMT4xi0CMe4MtgQCPd4JRgUkFjjiEW4QHgRKMTYFeh2+FNI0RESSBFzmBdQxPgXNjhm4BAQE X-IPAS-Result: A0AMAgAG+Z1Wl5cpIoJehAxtBohQo2gBkVIahylDEAEBAQEBAQEBEAEBAQEBCBYHT4ItgiARfA8CJgIkEgEFAVeHeZ8MggeBMT4xi0CMe4MtgQCPd4JRgUkFjjiEW4QHgRKMTYFeh2+FNI0RESSBFzmBdQxPgXNjhm4BAQE X-IronPort-AV: E=Sophos;i="5.22,316,1449529200"; d="scan'208";a="160847102" Received: from zhwhg041151.star.net.tohoku.ac.jp (HELO mail1.is.tohoku.ac.jp) ([130.34.41.151]) by mail3-smtp-sop.national.inria.fr with ESMTP; 19 Jan 2016 09:54:45 +0100 Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by mail1.is.tohoku.ac.jp (Postfix) with ESMTPSA id 99F3B857C1 for ; Tue, 19 Jan 2016 17:54:40 +0900 (JST) Received: by mail-lb0-f176.google.com with SMTP id oh2so360146647lbb.3 for ; Tue, 19 Jan 2016 00:54:40 -0800 (PST) X-Gm-Message-State: ALoCoQnUivslXqE7WYBmO3ta9tALdMbL/MMwW6X/zeOfR4karMFE0hvt2t/TYWMwZ+z/ysoDvsCMS10iHlJKiWz+EyM1I2J/qg== MIME-Version: 1.0 X-Received: by 10.112.168.194 with SMTP id zy2mr10545845lbb.120.1453193667911; Tue, 19 Jan 2016 00:54:27 -0800 (PST) Received: by 10.25.17.207 with HTTP; Tue, 19 Jan 2016 00:54:27 -0800 (PST) Date: Tue, 19 Jan 2016 17:54:27 +0900 X-Gmail-Original-Message-ID: Message-ID: From: Ryohei Tokuda To: caml-list@inria.fr Content-Type: text/plain; charset=UTF-8 X-Validation-by: tokuda@sf.ecei.tohoku.ac.jp Subject: [Caml-list] Data representation of records Dear the compiler developers, I am just curious about memory representation of records. When I read dump of `clambda`, I felt the representation of records a little bit strange. In the following program, functions just create the variants and records. a.ml type t = A of int | B of float type r1 = {x:int; y:float} let make_a x = A x let make_b x = B x let make_r1 x y = {x;y} type r2 = {a:int; b:int} let make_r2 a b = {a; b} The result of `ocamlopt -dclambda -c a.ml` show the following. (seq (let (make_a/1014 (closure (fun camlA__make_a_1014 1 x/1015 (makeblock 0 x/1015)) )) (setfield_imm 0 (global camlA!) make_a/1014)) (let (make_b/1016 (closure (fun camlA__make_b_1016 1 x/1017 (makeblock 1 x/1017)) )) (setfield_imm 1 (global camlA!) make_b/1016)) (let (make_r/1018 (closure (fun camlA__make_r_1018 2 x/1019 y/1020 (makeblock 0 x/1019 y/1020)) )) (setfield_imm 3 (global camlA!) make_r/1018)) (let (make_r/1024 (closure (fun camlA__make_r_1024 2 a/1025 b/1026 (makeblock 0 a/1025 b/1026)) )) (setfield_imm 2 (global camlA!) make_r/1024)) 0a) This dump of IL is likely to show: - `makeblock` seems like `alloc`, which first argument is the label. - `makeblock` creates variants, and labels are different in A and B (0 for A, and 1 for B). - `makeblock` also creates records, and the label seems always 0. I checked the above understanding by reading output assemblies, I believe it is right comprehension. My question is, why records need the labels. In my comprehension, there is no chance that we check the label of records. Thanks. -- Ryohei Tokuda