Re: redoing SCM representation in 2.2

[Andy Wingo <wingo@pobox.com>]

On Sun 15 May 2011 11:00, Ken Raeburn <raeburn@raeburn.org> writes:

> So... Guile 2.2 won't work on the VAXstation in my basement, which
> doesn't do IEEE math? :-(
> (Not that I've powered it up in some time...)

I have no idea.

However... note that GCC obsoleted all vax ports but openbsd and netbsd
in 4.3, removed them in 4.4, and just obsoleted it on netbsd recently I
think.  Just saying :)

> Guess I hadn't thought about that before; we've got code that refers to
> IEEE floating point already, so does that mean we require IEEE floating
> point already?

Probably?  I hope so? :)  I think I'm too young to know about pre-ieee
FP :)

> On 64-bit SPARC and perhaps some other architectures, we'd be dependent
> on the OS only effectively using 48 bits worth of address space even if
> the hardware supports more.  I'd be surprised if we encounter a program
> that needs more storage than that, and I expect most current OSes will
> tend to have a couple of regions growing toward each other rather than
> scatter stuff all over the address space, but I could imagine a
> particularly naïve or aggressive form of address space layout
> randomization trying to take advantage of all 64 bits by scattering
> mapped memory throughout all 2**64 addresses (minus whatever the kernel
> uses), for libraries or heap allocation or both.

Yes, indeed.

> If the 64-bit SCM type isn't required to represent the full range of
> integer values the machine can support as immediate values, does it
> really have to encompass the full range of "double" values?

No, but the nice thing about doubles is that it's a closed set.  Any
operation on a double produces a double.  Subsets do not have that
property.

>> I think we need to do the JSC way, as it appears to be the only way to
>> work with the BDW GC, currently anyway.  We will need some integration
>> with the GC to ensure the 48-bit space, but that should be doable.
>
> Don't we have some objects now which can be initialized statically by
> the compiler, and for which the addresses get encoded directly into the
> resulting SCM objects?

Yes, though this is optional.  We could whitelist some set of platforms
for which this can work.

FWIW I plan on moving objcode to be ELF in 2.2, which will mean we write
our own loader for ELF, so we would have similar concerns about mapping
the file in the right address range.

Regards,

Andy
-- 
http://wingolog.org/