[Openmcl-devel] CCL on Solaris sparc architecture
Semih.Cemiloglu at nec.com.au
Fri Jan 22 00:48:57 UTC 2010
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
I doubt sparc architecture is on the brink of oblivion. Instead, as a
software developer I see interesting possibilities:
From: Brian Mastenbrook [mailto:brian at mastenbrook.net]
Sent: Friday, 22 January 2010 11:15 AM
To: Semih Cemiloglu
Cc: semih at cemiloglu.org; openmcl-devel at clozure.com
Subject: Re: [Openmcl-devel] CCL on Solaris sparc architecture
On 1/21/2010 5:21 PM, Semih Cemiloglu wrote:
> Hi Gary,
> Thank you for the detailed response.
> Ron Garret has promised to chase the abandoned sparc compiler backend.
> If he finds it, I will see what I can do with it.
> At this juncture, I really wished that CCL had a generic (=portable
> C) compiler backend and runtime support *in addition to* manually
> optimized assembly backends. That would make porting task very easy.
> Maybe next compiler backend development should aim that, instead of
> another architecture port.
> Some of the compilers I work with (Sun Studio CC and Intel C++ in
> particular) generates very efficient and optimized code. Trying to
> better their efficiency manually feels like crossing over to level of
> diminishing returns.
Optimizing C and optimizing Common Lisp are two very different things.
Generating C is an approach used by other implementations (notably ECL
and GCL), but their performance does not equal that of the best CL
implementations because the hard parts of optimizing Common Lisp aren't
taken care of by the C compiler. Specifically, the C compiler can't do
anything to optimize out type checks or perform type inference on
As much as I think a SPARC port of CCL would be technically interesting
in an abstract sense, I have to wonder why you're not using an
implementation that already supports the SPARC (of which there are
several, both free and commercial). It's a waning niche architecture
that may or may not be around ten years hence; it seems to me that any
effort spent porting a new implementation should be well justified as I
doubt it will really attract a whole lot of users.
brian at mastenbrook.net
More information about the Openmcl-devel