[Openmcl-devel] CCL on Solaris sparc architecture
Semih.Cemiloglu at nec.com.au
Thu Jan 21 15:21:32 PST 2010
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
From: Gary Byers [mailto:gb at clozure.com]
Sent: Thursday, 21 January 2010 3:04 PM
To: Semih Cemiloglu
Cc: openmcl-devel at clozure.com; semih at cemiloglu.org
Subject: Re: [Openmcl-devel] CCL on Solaris sparc architecture
On Thu, 21 Jan 2010, Semih Cemiloglu wrote:
> Dear CCL Developers,
> I am in need of a CL implementation for our product/project which is
> aimed at Solaris sparc and x86 platforms.
> I see that CCL is available on OpenSolaris/x86 but not on sparc
> Is it possible to get an idea of work involved to port CCL to sparc
> architecture? Is it necessary to write assembly code to complete the
> port? Is internals of CCL and/or building from source documented? If
> yes, where can one access the documentation?
describes how to rebuild CCL from its source code; this is also
in the documentation, which is available online at:
<http://ccl.clozure.com/ccl-documentation.html> ; single HTML page
<http://ccl.clozure.com/manual/> ; one page per chapter
The single page version is distributed with CCL.
Much of CCL is written in itself, which means that "compiling it from
source" is only relevant if you have a compiler that targets the
platform that you're compiling on/for. Getting to that point
generally involves writing a compiler backend and machine-specific
runtime support for the target, using that compiler backend to
cross-compile the sources (into FASL files and a bootstrapping image)
for the new target and getting that cross-compiled code working
natively. Matt Emerson (rme at clozure.com) wrote a wiki page with his
notes on the cross-compilation/ bootstrapping process that he used
when working on the ia32 port; I don't know the URL for that page
offhand, but I'm sure that we can find it (somehow) if anyone's
About 10 years ago, I did a port of (a very early version of) what's
now CCL to 32-bit SPARC/Solaris; that took around 2 months to get to
the point where the system could compile itself natively. I remember
knowing of some things that didn't work at all and I'm sure that there
were some things that didn't work and that I didn't know about. That
was done as quickly as it was by ignoring the differences between the
PPC and the SPARC (e.g., register windows weren't used by Lisp code).
CCL/OpenMCL didn't use native threads in those days, and I'm sure that
some of the things that were done in that SPARC port weren't anywhere
close to being thread-safe.
I didn't keep the results of that work (and sometimes regret that),
and AFAIK no one else did, either. The last few ports that we've done
(ia32 and x86-64) have taken roughly 6 months each; a PPC64 port done
a few years earlier probably took around 3 months (with those months
staggered over a few years.) My best rough guess is that a SPARC port
would be easier than the x86 ports (because the architecture is saner)
and longer than the PPC64 port (because one would have to start from
scratch), so a rough estimate would be that a SPARC port would take
> Thanks in advance,
> Kind regards,
> Semih Cemiloglu
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel