[Openmcl-devel] CCL on Solaris sparc architecture

[Brian Mastenbrook]

On 1/21/2010 6:48 PM, Semih Cemiloglu wrote:
> Hi Brian,
>
> I did and am still evaluating various open source CL implementations.
> What strike me most about CCL is elaborate documentation and responsive
> user community. I came here off from ECL, slightly frustrated with
> inadequate documentation about its internals and cross-language
> interfacing.

(Apologies in advance to the Clozure folks; this email is my take on 
what makes sense if you have a need for a CL on SPARC, which doesn't end 
up selling CCL.)

The CCL user community is usually quite responsive and friendly, but I 
wouldn't necessarily describe the documentation as "elaborate" when 
compared to (say) Allegro Common Lisp. This isn't meant as a slight 
against CCL.

Just for reference, here is a list of the Common Lisp implementations I 
know of that include native SPARC backends (not including portable 
implementations like ECL, CLISP, etc):

* SBCL (32-bit only, free, lousy semispace garbage collector, no threads)
* CMUCL (32-bit only, free, generational garbage collector, no threads)
* Scieneer (32- and 64-bit, not free, generational garbage collector, 
native threads)
* Allegro (32- and 64-bit, not free, generational garbage collector, 
green threads only until version 9)
* LispWorks (might actually be Liquid Common Lisp, in which case it's 
quite likely to be stale)

I would hazard a guess that licensing one of the commercial versions 
would be cost-competitive with paying Clozure to port CCL. If you have a 
business need (backed up by dollars) for a Common Lisp implementation on 
SPARC, then you probably have such a need now, not four to five months 
from now plus whatever amount of time is necessary to shake all the bugs 
out of the new backend. All of these options are available today. One of 
them probably meets your needs and budget.

If, on the other hand, you don't have any money to spend, then you'll 
probably need to do the port yourself. I'll warn you that this kind of 
work has a steep learning curve. If it would take Gary four to five 
months to port to SPARC, you can count on at least doubling that time 
estimate unless you are are very quick study who is already extremely 
familiar with SPARC or PowerPC and at least one compiler of similar 
scope and complexity as CCL. (That you'd propose a C backend for CCL 
leads me to believe otherwise.)

If neither of the above is true, then this discussion is entirely 
academic. If that's the case, I'll try to steer it towards an ARM port, 
which would be eminently more useful to me. (Academic discussions are 
usually self-serving like this.)

> I doubt sparc architecture is on the brink of oblivion. Instead, as a
> software developer I see interesting possibilities:
> http://www.opensparc.net/
> http://cooltools.sunsource.net/
> http://www.sun.com/solutions/cloudcomputing/index.jsp

I'd say that SPARC is less healthy now than Alpha was ten years before 
its demise. Sun has just been acquired by a historically 
software-oriented company whose commitment to maintaining a unique 
architecture is unproven to say the least. One major processor (Rock) 
has been canceled within the past year and all of their recent processor 
projects have been plagued by delays. While the processors are very 
interesting technically, it takes quite a lot of work to keep up in this 
segment. They've retreated from the low end of the market and have 
filled in with x86 servers. It will be interesting to see if Sun can 
pull it off, but the unfortunate reality is that interesting developer 
possibilities don't equal market success in a business environment where 
every dollar is counted.
-- 
Brian Mastenbrook
brian at mastenbrook.net
http://brian.mastenbrook.net/