From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id A4375BBCA for ; Mon, 5 May 2008 17:01:02 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQEAIO+HkjRVcivc2dsb2JhbACDHY5cAQwDBAQJDwWUTINw X-IronPort-AV: E=Sophos;i="4.27,437,1204498800"; d="scan'208";a="25848019" Received: from wf-out-1314.google.com ([209.85.200.175]) by mail4-smtp-sop.national.inria.fr with ESMTP; 05 May 2008 17:01:01 +0200 Received: by wf-out-1314.google.com with SMTP id 28so812737wfa.15 for ; Mon, 05 May 2008 08:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=oiwoINsVvaQvVGIOzjuG/u3pVYULlXWnzXmEQkwpj5E=; b=HZyijY+SEABfuEQ4swvUdohD2gUqAzFHyQgqzH3iyMIfmnFUUzIaxf+QqXvlP667G/nFg351Tw4IV1JjWiNXW9RQ7ktQ2O7GqLVskDIcTPVPJQBqaFTpP0WfQO6WUolGKWQzlzmUt4jXd77NLZA7Jr0dW47tZza8ut18WIe0ArE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BAEpc0L3y540zcf4l6J2yrlgkf/VQv+4Q16cF89Tlh3+rpLpNP3dZRtTrkb0oCUeYPXJ+MRhUgBJn6WyZjcc++MqI1Pgi5Vl71JLrtskBMtDCO4lUUUadIn4I00ha/UzdibESNMuwpadCOVY2PyAy3E95D22mfqSS4NbvEquDmM= Received: by 10.142.50.15 with SMTP id x15mr2552436wfx.169.1209999660454; Mon, 05 May 2008 08:01:00 -0700 (PDT) Received: by 10.143.19.2 with HTTP; Mon, 5 May 2008 08:01:00 -0700 (PDT) Message-ID: Date: Mon, 5 May 2008 11:01:00 -0400 From: "Markus Mottl" To: "Stefano Zacchiroli" Subject: Re: [Caml-list] Core has landed Cc: caml-list@yquem.inria.fr In-Reply-To: <20080505064238.GC29236@aquarium.takhisis.invalid> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1209764381.8680.38.camel@nyc-qws-018.delacy.com> <20080503081946.GA30935@annexia.org> <20080505064238.GC29236@aquarium.takhisis.invalid> X-Spam: no; 0.00; markus:01 mottl:01 markus:01 mottl:01 zacchiroli:01 zack:01 endian:01 patched:01 big-endian:01 big-endian:01 integers:01 runtime:01 hand-written:01 ocaml:01 wrote:01 On Mon, May 5, 2008 at 2:42 AM, Stefano Zacchiroli wrote: > Sounds like a reasonable solution indeed. Way better than not having > bin-prot on some archs (this is particularly annoying in Debian, where > we support several big endian machines; the status quo would mean no > Core on them and in turn no application using Core on them. Currently we > patched Core on that architecture to remove the bin-prot dependency, but > is a rather hackish solution I would like to get rid off). > > Do you plan to implement such a solution in forthcoming releases? We currently do not have any immediate need and man power to fully support big-endian machines (we also don't have access to any), but we'll gladly accept patches. This could be implemented using platform-specific macros as is the case with 32/64bit. This is what works / doesn't work as of now: *) Big-endian and little-endian machines cannot communicate with each other for anything but very specific cases. Don't use the binary protocol in such heterogeneous environments. *) 32 and 64 bit, little-endian architectures can communicate freely, assuming, of course, that integers do not overflow on 32bit. This is tested at runtime to prevent hard to debug errors. *) 32bit big-endian machines can communicate with each other freely. 64 bit big-endians can communicate with each other freely, too, but not necessarily with 32bit big-endians: values of type int64, etc., may not necessarily be communicated correctly. Note, too, that you should exclusively use the automatically generated converters on big-endian machines. The hand-written (slower) ones for the basic types are intended mostly for testing purposes only, and will not work when mixed with a different endianness (they assume little-endians). Thus, it certainly makes sense to package the binary protocol for big-endians, too, as long as people are informed of what works. Since almost nobody uses big-endian machines, most users won't care. But I'd surely be happy to see a patch to fully support all architectures... Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com