[Openmcl-devel] CCL on Solaris sparc architecture

[Semih Cemiloglu]

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.

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


Regards
Semih Cemiloglu


-----Original Message-----
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
ANSI
> 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
yet
> 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
lexicals.

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 Mastenbrook
brian at mastenbrook.net
http://brian.mastenbrook.net/