Re: scm_remember_upto_here_* obsolete?

2011-05-27 Thread Peter Brett
BT Templeton  writes:

> Are the scm_remember_upto_here_* functions useful now that Guile uses
> BDW-GC?

They're still useful if you want your code to work with both 1.8.x and
2.x.

   Peter ;-)

-- 
Peter Brett 
Remote Sensing Research Group
Surrey Space Centre




Re: Cross-compiling Guile 2.0

2011-05-27 Thread Andy Wingo
So!

On Mon 21 Mar 2011 21:42, Andy Wingo  writes:

> On Mon 21 Mar 2011 20:58, l...@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/



Re: Cross-compiling Guile 2.0

2011-05-27 Thread Ludovic Courtès
Hello!

Andy Wingo  skribas:

> 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.

Sounds good, but you’d need additional data that maps triplets (well,
$host_cpu) to low-level info such as endianness and word size, right?

Thanks,
Ludo’.