Re: redoing SCM representation in 2.2

[Ken Raeburn]

On May 15, 2011, at 11:47, Andy Wingo wrote:
> 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 :)

I knew a bunch of ancient OSes for Vax were made obsolete in gcc, but last I 
looked, the source files were still in the tree.

The latest NetBSD release, NetBSD 5.1, included updates to the vax port.  They 
just introduced a 3-tier system for the ports; Vax is in the second tier -- not 
the main project focus, but still alive and community-supported.

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

What are they teaching you kids today? :)

Seriously, at some point it probably is reasonable to ditch the really old 
platforms no one cares about any more (e.g., try to find free or open-source 
software for a machine without 8-bit bytes), but at the same time, there is a 
part of the community that wants to use some of the old hardware out there with 
modern software.  For some it may just be nostalgia, or the challenge of it, or 
maybe some have real needs for old hardware (supporting old but still-important 
devices via old bus architectures?).  For me, it's partly nostalgia (4.2/4.3BSD 
was how I learned UNIX in school), and partly trying to keep awareness of 
general porting issues.

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

Well, I think it's also a subset of "long double", but if you define the 
operations as overflowing rather than giving results in the long double range, 
then you've defined it as a closed set, sure.

But the question I was after was, even if we want to use the full range of the 
values, do we need the entire set to be representable *in immediate form*?  I 
doubt the very largest and smallest values are used often, so making just those 
values use heap storage probably wouldn't be too costly in space.  (The code 
might be a bit annoying, but like I said, it gets us lots of bits back for 
pointer/integer values.)  And if those largest and smallest values are used 
more than I suspect, that brings up the question of whether we might want the 
"long double" range available instead.

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

Ooh, also very interesting.  Though, I would think the win of using ELF would 
be the ability to treat it as a native object file and use native support, 
which only works on ELF systems.  Not Windows, not Mac OS X, probably not on 
some UNIX system still being sold, almost certainly not on some UNIX system 
still being used.  Why "ELF everywhere" rather than "native object file 
formats"?  Scheme is wonderful and all, but I think calling "dlopen" is 
probably much nicer than writing it from scratch in any language. :-)

If you have to write your own loader anyways, we could pick up some lessons 
from ELF, and maybe use something modeled on it, but I'm not sure ELF itself is 
best; it's probably got a lot of stuff we don't need.

Ken