unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: ludo@gnu.org (Ludovic Courtès)
Cc: guile-devel@gnu.org
Subject: Re: Cross-compiling Guile 2.0
Date: Fri, 27 May 2011 16:32:47 +0200	[thread overview]
Message-ID: <m3ei3kp628.fsf@unquote.localdomain> (raw)
In-Reply-To: <m3aagotdc8.fsf@unquote.localdomain> (Andy Wingo's message of "Mon, 21 Mar 2011 21:42:31 +0100")

So!

On Mon 21 Mar 2011 21:42, Andy Wingo <wingo@pobox.com> writes:

> On Mon 21 Mar 2011 20:58, ludo@gnu.org (Ludovic Courtès) writes:
>
>> At some point there will have to be a triplet → arch → endianness
>> conversion.
>
> Indeed.
>
>>  I’d rather have that conversion occur as close to the UI as
>> possible—i.e., close to ‘scripts/compile.scm’—rather than deep down in
>> (system base compile) because the triplet string is really a UI notion IMO.
>
> Actually I think it's more fundamental than that.  The compilation
> process tries, generically, to find a path through the language tower
> path from the source language to the target language.  There is nothing
> bytecode-specific in (scripts compile), except for a couple default
> target languages.
>
> It seems to me that the value of the target-type fluid at the time that
> `compile-passes' is called should be what determines the compilation
> path and target-specific settings.  For example, to continue the ARM
> compilation example, perhaps it would cause a different target language
> to be selected.
>
> Dunno.  All of that could just be too complicated, and maybe you are
> right.

To re-take this topic...  I looked at this, and had a patch that looked
for a #:target-endianness option in the compile options.  I'm fairly
sure that it does the bytecode compilation OK, but then to write the
objcode out to disk we need to attach the right cookie on the beginning
(word size and endianness), and we don't have the #:target-endianness at
that point.

After having read "Using System Type" again in the autoconf manual, I am
convinced again that the right thing to do is to add a %target-type
fluid or mutable parameter, defaulting to the %host-type.  We select how
to compile for the target by making decisions based on %target-type.
Since in Guile those decisions don't currently need to be made anywhere
except in compile-bytecode.scm and in bytecode->objcode in objcodes.c,
this is easy.  In the future when the %target-type could select an
entirely different assembler et al, the "where" of the decisions could
be moved somewhat; but I think that the mechanism sounds right to me.

Let me know if you have objections.  Thanks!

Andy
-- 
http://wingolog.org/



  reply	other threads:[~2011-05-27 14:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-05 19:47 Cross-compiling Guile 2.0 Neil Jerram
2011-03-05 21:41 ` Andy Wingo
2011-03-06 11:03   ` Neil Jerram
2011-03-06 20:43     ` Andy Wingo
2011-03-06 22:12 ` Ludovic Courtès
2011-03-18  0:04   ` Andy Wingo
2011-03-18 10:17     ` Ludovic Courtès
2011-03-19 11:04       ` Andy Wingo
2011-03-20 13:50         ` Ludovic Courtès
2011-03-20 15:25           ` Andy Wingo
2011-03-20 21:31             ` Ludovic Courtès
2011-03-20 21:53               ` Andy Wingo
2011-03-21 19:58                 ` Ludovic Courtès
2011-03-21 20:42                   ` Andy Wingo
2011-05-27 14:32                     ` Andy Wingo [this message]
2011-05-27 14:51                       ` Ludovic Courtès
2011-05-29 18:10                         ` Andy Wingo
2011-05-30 20:22                           ` Andy Wingo
2011-05-31 15:24                             ` Ludovic Courtès
2011-03-16 13:02 ` Jan Nieuwenhuizen

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

  List information: https://www.gnu.org/software/guile/

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

  git send-email \
    --in-reply-to=m3ei3kp628.fsf@unquote.localdomain \
    --to=wingo@pobox.com \
    --cc=guile-devel@gnu.org \
    --cc=ludo@gnu.org \
    /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).