From: Edi Weitz
Subject: Apple's new 64-bit processor - and Lisp?
Date: 
Message-ID: <87y8zszjce.fsf@bird.agharta.de>
OK, the cat is out of the bag - Apple has announced desktop systems
for August which'll feature 64-bit PowerPC processors by IBM. (They
have some other rather impressive specs, too). It also looks like
Apple has re-written their own gcc-based compiler such that
"optimizing" C/C++/Objective-C apps for the new architecture will
"just" involve recompiling. I guess they'll also take care of Java.

But what about Lisp? There's obviously more work than just recompiling
to make a real 64-bit Lisp out of existing CL implementations. I'm
curious about what to expect from the new Macs with respect to Lisp
and when.

What about the C-based Lisps like CLISP, ECL, GCL? Will it be easy for
them to "upgrade"? MCL and LispWorks? They've recently released or
announced new OS X versions. I wonder if they knew about the new
processors. Franz? They have a 64-bit version for AIX, don't they?
Does that help? CMUCL/SBCL? Some people seem to work on OS X versions
but they haven't surfaced yet AFAIK. I currently don't know why I
should donate money for the SBCL-AMD64 project but I'd definitely
shell out some bucks for a 64-bit OS X version of SBCL or CMUCl with
native threads. OpenMCL?

Any vendors/implementors willing to comment?

Thanks,
Edi.

From: Espen Vestre
Subject: Re: Apple's new 64-bit processor - and Lisp?
Date: 
Message-ID: <kwhe6fexa2.fsf@merced.netfonds.no>
Edi Weitz <···@agharta.de> writes:

> I'm curious about what to expect from the new Macs with respect to Lisp
> and when.

AOL.

But there's no need for immediate worry, is there? I've used 32-bit
lisps on 64-bit Solaris with no problems. If your memory requirements
are modest, what would you gain from a 64 bit version of lisp?
-- 
  (espen)
From: Duane Rettig
Subject: Re: Apple's new 64-bit processor - and Lisp?
Date: 
Message-ID: <4y8zrcxod.fsf@beta.franz.com>
Alain Picard <·······················@optushome.com.au> writes:

> Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> 
> > But there's no need for immediate worry, is there? I've used 32-bit
> > lisps on 64-bit Solaris with no problems. If your memory requirements
> > are modest, what would you gain from a 64 bit version of lisp?
> 
> Well, lispworks vectors, for example, are limited to
> 2^21 in length (and 2^23 for simple strings).  This has
> annoyed me greatly on many occasions.
> 
> One imagines that on a native 64 bit platform, that number might be
> more in the range 2^53.  That might be nice.

2^56.  Perhaps on some Lisps, it would be 2^55.  The number is derived
assuming the same type set, which requires an octet, so it is
really just the word with in bits minus 8.

> When do we get a native 64 bit, os-multi-cpu-multithreaded SBCL 
> on OS X though?  Now that would be COOOOOL....  :-)

Can't help you there :-)

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Daniel Barlow
Subject: Re: Apple's new 64-bit processor - and Lisp?
Date: 
Message-ID: <87r85js0y1.fsf@noetbook.telent.net>
I haven't see the original article, but a followup from Duane Rettig
indicates that Alain Picard <·······················@optushome.com.au> 
probably wrote:
> When do we get a native 64 bit, os-multi-cpu-multithreaded SBCL 
> on OS X though?  Now that would be COOOOOL....  :-)

Christophe Rhodes and I have experimented with 64 bit SBCL, targetted
initially at Digital^WCompaq^WHP Alpha because (a) the port already
exists (albeit restricted to 32 bit lispobjs) and (b) the hardware is
easy to get hold of.

Some degree of initial success was observed (summary: it builds, but
doesn't run for very long) but in the absence of any real reason for
needing such a port - my Alpha is the slowest and noisiest machine I
own, and doesn't have >2Gb of RAM anyway - the project is pretty much
on the back burner.  Re-evaluation of priorities could be forced by
application of sufficient funding, I imagine.

Alternatively, OpenMCL might get there first ...


-dan

-- 

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources 
From: Edi Weitz
Subject: Re: Apple's new 64-bit processor - and Lisp?
Date: 
Message-ID: <87smpz984o.fsf@bird.agharta.de>
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:

> Edi Weitz <···@agharta.de> writes:
> 
> > I'm curious about what to expect from the new Macs with respect to
> > Lisp and when.
> 
> AOL.
> 
> But there's no need for immediate worry, is there? I've used 32-bit
> lisps on 64-bit Solaris with no problems. If your memory
> requirements are modest, what would you gain from a 64 bit version
> of lisp?

Hmm, my first thought was "larger fixnums". That'd make it easier to
implement algorithms efficiently which are specifically tailored for
32-bit integers, for example. I seem to remember that Pierre Mai's
cool MD5 implementation had to jump through some hoops and use
CMUCL-specific stuff to be almost on par with its C counterpart.

Edi.
From: Raymond Toy
Subject: Re: Apple's new 64-bit processor - and Lisp?
Date: 
Message-ID: <4nsmpz7dtn.fsf@edgedsp4.rtp.ericsson.se>
>>>>> "Edi" == Edi Weitz <···@agharta.de> writes:

    Edi> Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
    >> Edi Weitz <···@agharta.de> writes:
    >> 
    >> > I'm curious about what to expect from the new Macs with respect to
    >> > Lisp and when.
    >> 
    >> AOL.
    >> 
    >> But there's no need for immediate worry, is there? I've used 32-bit
    >> lisps on 64-bit Solaris with no problems. If your memory
    >> requirements are modest, what would you gain from a 64 bit version
    >> of lisp?

    Edi> Hmm, my first thought was "larger fixnums". That'd make it easier to
    Edi> implement algorithms efficiently which are specifically tailored for
    Edi> 32-bit integers, for example. I seem to remember that Pierre Mai's
    Edi> cool MD5 implementation had to jump through some hoops and use
    Edi> CMUCL-specific stuff to be almost on par with its C counterpart.

An experimental version of CMUCL on Solaris had support for unboxed
64-bit integers on Ultrasparcs.  It worked pretty well.
Unfortunately, there is a bug somewhere that I haven't been able to
track down wherein the compiler generates incorrect code.  Bummer.

Ray
From: Espen Vestre
Subject: Re: Apple's new 64-bit processor - and Lisp?
Date: 
Message-ID: <kw65mvetl5.fsf@merced.netfonds.no>
Edi Weitz <···@agharta.de> writes:

> Hmm, my first thought was "larger fixnums". 

That's a very good point! Could any users of actual 64 bit lisps
comment on that - do they have bigger fixnums at their disposal?
-- 
  (espen)
From: Duane Rettig
Subject: Re: Apple's new 64-bit processor - and Lisp?
Date: 
Message-ID: <43chzecf3.fsf@beta.franz.com>
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:

> Edi Weitz <···@agharta.de> writes:
> 
> > Hmm, my first thought was "larger fixnums". 
> 
> That's a very good point! Could any users of actual 64 bit lisps
> comment on that - do they have bigger fixnums at their disposal?

How about an implementor? :-)

Yes, our 64-bit lisps have fixnums that are 60 bits plus sign, so
they do 32-bit algorithms efficiently.  They also can do unboxed
(signed-byte 64) manipulation, in the same way the 32-bit lisps
can do (signed-byte 32) manipluation unboxed.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Joerg-Cyril Hoehle
Subject: Re: Apple's new 64-bit processor - and Lisp?
Date: 
Message-ID: <usmpqh8cu.fsf@T-Systems.com>
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:

> Edi Weitz <···@agharta.de> writes:
> > Hmm, my first thought was "larger fixnums". 

> That's a very good point! Could any users of actual 64 bit lisps
> comment on that - do they have bigger fixnums at their disposal?

I used the so-called "wide" version of CLISP on my stock 32bit Amiga
years ago. It features 32-bit fixnums and indeed, in a 32bit intensive
application, it ran faster than the normal CLISP version. However, on
other applications, it run ~40% slower (all objects in the wide
version were 8 bytes instead of 4).

I did not repeat these measurements using a CLISP version with
generational GC. Back then, I explained the higher speed of the wide
version on arthmetic by time spent on GC'ing the unused bignums in the
normal version of CLISP.

Summary: you can do 32bit arithmetic with some CL without having to
buy a 64bit machine.

	Joerg Hoehle
TSI ITC-Security Technologiezentrum