From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: Re: redoing SCM representation in 2.2 Date: Sun, 15 May 2011 16:43:26 -0400 Message-ID: <72BFF702-0847-45A6-A433-4BAC00F5950B@raeburn.org> References: <2932B3D9-7CE6-46B9-8A1E-51702E417D53@raeburn.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1305492222 13724 80.91.229.12 (15 May 2011 20:43:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 15 May 2011 20:43:42 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun May 15 22:43:38 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QLiA3-0005df-1Z for guile-devel@m.gmane.org; Sun, 15 May 2011 22:43:35 +0200 Original-Received: from localhost ([::1]:49225 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QLiA2-0000Tq-KD for guile-devel@m.gmane.org; Sun, 15 May 2011 16:43:34 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:51407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QLi9z-0000TZ-TX for guile-devel@gnu.org; Sun, 15 May 2011 16:43:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QLi9y-0005S4-Qe for guile-devel@gnu.org; Sun, 15 May 2011 16:43:31 -0400 Original-Received: from mail-vx0-f169.google.com ([209.85.220.169]:62153) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QLi9y-0005Rw-N3 for guile-devel@gnu.org; Sun, 15 May 2011 16:43:30 -0400 Original-Received: by vxk20 with SMTP id 20so3655725vxk.0 for ; Sun, 15 May 2011 13:43:29 -0700 (PDT) Original-Received: by 10.52.115.230 with SMTP id jr6mr5103881vdb.25.1305492209022; Sun, 15 May 2011 13:43:29 -0700 (PDT) Original-Received: from squish.raeburn.org (c-24-128-48-142.hsd1.ma.comcast.net [24.128.48.142]) by mx.google.com with ESMTPS id u11sm473207vdt.25.2011.05.15.13.43.27 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 May 2011 13:43:28 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.1084) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.220.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12497 Archived-At: 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? >=20 > 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=