[Openmcl-devel] CCL on Solaris sparc architecture

[Gary Byers]

If you think that compiling lisp to C is a good idea, there are
open-source implementations that do that. Of "precise, relocating GC"
and "support for native threads", which feature have you decided isn't
necessary for your application(s) (since you can't compile to C and
have both) ?

If CCL compiled to C, it wouldn't be CCL: it'd be a different CL
implementation with a different set of strengths, weaknesses, and features.
Since I generally like the things that CCL offers and generally don't
like the thought of giving up the things that compiling to C would force
me to give up, I find the whole idea of this approach unattractive.

As Brian pointed out, leveraging (generally very good) C compiler
technology to compile CL code can have mixed results, but I find the
strongest arguments in favor of compiling to C to be those based on
time-to-market concerns.  Unless you're convinced that a C-based
implementation will be adequate for all time, it's not clear that this
offers as much as it might seem to at first glance: if you're planning
on doing a native implementation eventually, then the C-based
implementation is likely to be either irrelevant or in the way.

If I haven't been negative enough about this whole issue: a lot of the
code in CCL is in some way sensitive to (or aware of ...) the fact
that it's running in a native implementation (and a particular native
implementation), and in some cases this code would have to be replaced
or significantly changed in order to work/work well with a C based
implementation.  (It's not just a case of writing a compiler backend
and recompiling everything; it also likely involves re-writing a lot
of stuff in the middle layers of the implementation.)  That generally
only needs to be done once, but when this work is factored in it's not
clear that the time to market on the first C-targeted port is a whole
lot less than it would be in the case of a native implementation.

On Fri, 22 Jan 2010, 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.
>
>
> Regards,
> Semih Cemiloglu
>
>
>
> -----Original Message-----
> 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
>> platforms.
>>
>> 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?
>
> <http://trac.clozure.com/ccl/wiki/UpdatingFromSource>
>
> describes how to rebuild CCL from its source code; this is also
> discussed
> in the documentation, which is available online at:
>
> <http://ccl.clozure.com/ccl-documentation.html> ; single HTML page
>
> and at
>
> <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
> interested.
>
> 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
> ~4-5 months.
>
>
>>
>> Thanks in advance,
>> Kind regards,
>>
>> Semih Cemiloglu
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>
>
>