Re: M1 port

Tim McNerney <[email protected]> Sat, 6 Jan 2024 02:37:38 -0500
Newsgroups gmane.lisp.openmcl.devel
Message-ID <[email protected]>
We hear you Bharat,

One of our priorities is to write more internals documentation while we work on the M1 port.
Part of the discipline will include everyone keeping (and checking in) their contemporary notes/journals, which we will distill into a document “how to port CCL to (yet) another processor” on an ongoing basis.

Another thing that is in the immediate plan is to write “slow but correct” versions of all the subprims (e.g. bignum arithmetic) in Lisp, which are all currently written in assembly language for every CCL target architecture.

--Tim

On Jan 6, 2024, at 01:28, Bharat Shetty <[email protected]> wrote:


Agree people should contribute. However some good introduction to internals and updating documentation would be very helpful. More important than M1 port is we set this right. We might get M1 running after some effort but in a couple of years we will end up in a similar situation and talk about funding someone again.

Most of us also have day jobs.

Regards,

Bharat

On Sat, 6 Jan 2024, 03:57 Andrew Shalit, <[email protected] > wrote:

Hi Nicolas -

Just to be 100% clear about this: Clozure as an entity does not exist anymore, nor does it exist as a loosely organized cabal. At this point Matthew Emerson manages the web domains and owns Github account where CCL is hosted, but that’s it. I’m sure he would welcome as much help as anyone wants to provide and would happily give commit privileges to anyone who shows they can work on the code. If someone would rather fork and go wild, that’d be fine too. But really, no one should let themselves be slowed down by thinking they need Clozure’s permission to do something.

> On Jan 5, 2024, at 3:42 PM, Nicolas Martyanoff <[email protected] > wrote:

>>

> I'm not disagreeing, but none of this is happening unless either Clozure

> gives project admin right to someone really invested, or this someone

> does the job of forking the project.