public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
From: Basile Starynkevitch <basile@starynkevitch.net>
To: "Marc Nieper-Wißkirchen" <marc@nieper-wisskirchen.de>
Cc: jit@gcc.gnu.org
Subject: Re: Incremental compilation
Date: Mon, 01 Jan 2018 00:00:00 -0000	[thread overview]
Message-ID: <2294a937-0220-d2cb-e16c-bc10ae70ffae@starynkevitch.net> (raw)
In-Reply-To: <CAEYrNrSjRwss7gXx_X2OqRwKWaFtmXQQD3ca2db_mSCAtT-p1g@mail.gmail.com>


On 12/30/18 12:54 PM, Marc Nieper-Wißkirchen wrote:
> Am So., 30. Dez. 2018 um 09:46 Uhr schrieb Basile Starynkevitch
> <basile@starynkevitch.net>:
> My use case is compiling a Scheme library. It contains macro
> definitions whose transformation procedures have to be compiled at
> first to expand subsequent parts of the library body. Furthermore, the
> compiled transformation procedures of global macro defintions have to
> appear in the final dynamic library as well.
>
>> The common wisdom would be to compile each function separately (perhaps
>> into its own shared object on Linux).
>>
>> Be aware that it is perfectly acceptable to have a big lot (e.g. many
>> hundred thousands) of shared objects on Linux.
> That's good to know!
>
> So what I probably need is a kind of linker for libgccjit that
> combines many of the compiled shared objects into one final module
>
No you don't need that. You can keep the many compiled shared objects, 
and it would be actually simpler. You should not need to combine all 
these in a single module (except for optimization purposes, and for that 
special case, which in my view is not useful, you would recompile all 
your functions again).

In practice, since you are implementing a Scheme, you are dealing with 
closures, not plain C or GCCJIT functions. A closure contain a pointer 
to a function (and closed values).

Queinnec's book Lisp In Small Pieces should be highly relevant to you.

-- 
Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France

      parent reply	other threads:[~2018-12-30 12:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-01  0:00 Marc Nieper-Wißkirchen
2018-01-01  0:00 ` Basile Starynkevitch
2018-01-01  0:00   ` Marc Nieper-Wißkirchen
2018-01-01  0:00     ` Basile Starynkevitch
2018-01-01  0:00       ` Marc Nieper-Wißkirchen
2018-01-01  0:00         ` Basile Starynkevitch
2019-01-01  0:00           ` Marc Nieper-Wißkirchen
2018-01-01  0:00     ` Basile Starynkevitch [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2294a937-0220-d2cb-e16c-bc10ae70ffae@starynkevitch.net \
    --to=basile@starynkevitch.net \
    --cc=jit@gcc.gnu.org \
    --cc=marc@nieper-wisskirchen.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).