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.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE autolearn=disabled version=3.1.3 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 4407BBC69 for ; Mon, 14 Jan 2008 13:16:46 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAALiikdDWxLC/2dsb2JhbACBVqYi X-IronPort-AV: E=Sophos;i="4.24,281,1196636400"; d="scan'208";a="6014352" Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194]) by mail2-smtp-roc.national.inria.fr with ESMTP; 14 Jan 2008 13:16:39 +0100 Received: from kuba.bertec.net (kuba.bertec.net [192.168.2.16]) by server1.bertec.net (Postfix) with ESMTP id EB1F6105830; Mon, 14 Jan 2008 07:16:37 -0500 (EST) From: Kuba Ober To: Will Farr Subject: Re: [Caml-list] ocaml doesn't need to optimize on amd64?? Date: Mon, 14 Jan 2008 07:16:36 -0500 User-Agent: KMail/1.9.6 (enterprise 0.20071123.740460) References: <200801090922.00231.ober.14@osu.edu> <200801110814.35168.ober.14@osu.edu> In-Reply-To: Cc: caml-list@yquem.inria.fr MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801140716.36916.ober.14@osu.edu> X-Spam: no; 0.00; ocaml:01 allocations:01 run-time:01 variants:01 c-like:01 compiler:01 ocaml:01 compiler:01 higher-order:01 c--:01 afaik:01 c--:01 cheers:01 48,:98 abstract:01 > > Yeah, but my area of interest is really embedded realtime stuff, running > > typically on architectures which are quite resource constrained. On some > > of those your typical GC wouldn't even fit in the code memory. And I'm > > not even (most of the time) using dynamic memory allocations. None of my > > code really calls for any sort of boxing -- there's no need for it. All I > > need is C that is more expressive and easier to optimize. No run-time > > variants, really, all types are known and fixed, and data is at fixed > > locations in memory, or on the stack, or occasionally on the heap which > > is manually managed (C-like). > > > > Of course that pertains to the code that gets generated, because I should > > be able to use abstract concepts while writing the code. If I pass a > > function to a function, it doesn't necessarily mean that the compiler > > must emit the code for the former, and that the latter should actually > > call (as call machine instruction) the former. > > This may be something you have seen before and dismissed, and it's not > really OCaml at all, but have you looked at PreScheme? It's a scheme > dialect (and, in fact, runs *un-modified* in a scheme interpreter), > plus a compiler that turns it into optimized C of the type you're > talking about. (For example, one optimization is that all > higher-order procedures are beta-substituted away at compile time.) > It might not really fit your needs, but perhaps there's some ideas you > could steal there, in any case. (The scheme48 guys used it to write > the VM for scheme48, which sounds to my un-expert ears like it would > have a lot in common with the tasks you're looking at doing.) If it turned it into C-- it'd be even better, because I can't count much on C compilers for my platforms either: Zilog Z8 compiler and assembler/linker has bugs which produce wrong code, and for SX28 there's, afaik, only one C compiler that isn't quite there yet anyway. C-- would be easier to generate code from. Right now my hackish platform runs in LISP, so Scheme wouldn't be so much different, but I don't really know how macros are done in Scheme, and I kind of depend on them. Cheers, Kuba