ccl

ccl copied to clipboard

There's errors with regards to C compiler. No one has maintained the App from the App Store in over 2 years. I just deleted it. It's a waste of time.

The command line tool works though. If you are working with Emacs it's good enough. Hoping for a ARM (Mx) port of CCL.

Yep. Switched to SBCL after using CCL for a long time. Can't get it to work on my m1 Air. And there's a related issue asking for m1 support which also has no responses. Surely it can't be that difficult to support M processors. I couldn't make sense of the errors that show up. I suspect it's some other underlying cause. If anyone has any ideas about what the issue really is, I am happy to contribute along with others to bring CCL to M1/ M2.

HI,

There was an email posted a few months ago from Andew Shalit in January that I am borrowing from but the problem comes down to:

• ccl deeply integrates with the OS.  This is what gave you the nice environment.  But it means that changes in the OS break things where other programs will not break.

• ccl does not work on ARM64.  It works on ARM32 and x86-64 but apparently Rosetta2 is not able to exactly work in a way that ccl x86-64 needs it to work for success.

Before this would have all been done by Gary Byers, but, alas, he had to stop working on this.

My "plan" such as it is, is to first develop an ARMv8 simulator in ccl, followed by changing the compiler so that it can compile to ARMv8 all while running in ccl on x86-64.  Then once ccl can partially cross compile itself and write la64fsl files from x86-64 linux ccl then hand write enough of the kernel to slowly bootstrap up an ARMv8 linux version.

That could then be a basis for a M1/M2 mac version.

Don't hold you breath though but the ARMv8 simulator is in process.  That is the easiest step.

cheers

bruce

Andrew's email is

"CCL runs much closer to the metal than most other Lisp implementations. For example, it uses native threads. It uses things like segfaults and interrupts to support the object model, eg knowing when it has to allocate more stack space or trigger a GC. It has a relocating garbage collector. So whoever does the work needs to be comfortable navigating the operating system and CCLs internal data structures and runtime in GDB. And they need to do all that in the context of 30+ years of code that was mostly written by one very smart person. So, yes, it requires someone with a very specific skill set, and there aren’t many such people around."

On 2022-07-18T08:58:10.000+02:00, vrunhofen @.***> wrote:

 Yep. Switched to SBCL after using CCL for a long time. Can't get it  to work on my m1 Air.  And there's a related issue asking for m1 support which also has no  responses.  Surely it can't be that difficult to support M processors. I  couldn't make sense of the errors that show up. I suspect it's some  other underlying cause. If anyone has any ideas about what the issue  really is, I am happy to contribute along with others to bring CCL  to M1/ M2.    —  Reply to this email directly, view it on GitHub  [https://github.com/Clozure/ccl/issues/413#issuecomment-1186833862],  or unsubscribe  [https://github.com/notifications/unsubscribe-auth/ACEXJISRZ4CM4BVVJS74YALVUT6AFANCNFSM5VH5YDOQ].  You are receiving this because you are subscribed to this @.***>

(Sorry if you get two copies.  I just noticed that most of the email addresses were "noreply")

HI,

There was an email posted a few months ago from Andew Shalit in January that I am borrowing from but the problem comes down to:

• ccl deeply integrates with the OS.  This is what gave you the nice environment.  But it means that changes in the OS break things where other programs will not break.

• ccl does not work on ARM64.  It works on ARM32 and x86-64 but apparently Rosetta2 is not able to exactly work in a way that ccl x86-64 needs it to work for success.

Before this would have all been done by Gary Byers, but, alas, he had to stop working on this.

My "plan" such as it is, is to first develop an ARMv8 simulator in ccl, followed by changing the compiler so that it can compile to ARMv8 all while running in ccl on x86-64.  Then once ccl can partially cross compile itself and write la64fsl files from x86-64 linux ccl then hand write enough of the kernel to slowly bootstrap up an ARMv8 linux version.

That could then be a basis for a M1/M2 mac version.

Don't hold you breath though but the ARMv8 simulator is in process.  That is the easiest step.

cheers

bruce

Andrew's email is

"CCL runs much closer to the metal than most other Lisp implementations. For example, it uses native threads. It uses things like segfaults and interrupts to support the object model, eg knowing when it has to allocate more stack space or trigger a GC. It has a relocating garbage collector. So whoever does the work needs to be comfortable navigating the operating system and CCLs internal data structures and runtime in GDB. And they need to do all that in the context of 30+ years of code that was mostly written by one very smart person. So, yes, it requires someone with a very specific skill set, and there aren’t many such people around."

On 2022-07-18T08:58:10.000+02:00, vrunhofen @.***> wrote:

 Yep. Switched to SBCL after using CCL for a long time. Can't get it  to work on my m1 Air.  And there's a related issue asking for m1 support which also has no  responses.  Surely it can't be that difficult to support M processors. I  couldn't make sense of the errors that show up. I suspect it's some  other underlying cause. If anyone has any ideas about what the issue  really is, I am happy to contribute along with others to bring CCL  to M1/ M2.    —  Reply to this email directly, view it on GitHub  [https://github.com/Clozure/ccl/issues/413#issuecomment-1186833862],  or unsubscribe  [https://github.com/notifications/unsubscribe-auth/ACEXJISRZ4CM4BVVJS74YALVUT6AFANCNFSM5VH5YDOQ].  You are receiving this because you are subscribed to this @.***>

I have a way to run CCL on M1. It requires the other X86 mac. Brew install clozure-cl on x86 mac. run ccl, and type "(require "cocoa-application")" copy all the directory of CCL from X86 mac to M1 mac in the same path. Now CCL(command-line) and IDE CCL both work on M1 mac for me (through rosseta2).

CCL is my favorite Lisp implementation. Lots of the Lisp implementations faded away in the history. I sometimes play Gold Hill Common Lisp and Star Sapphire Common LISP under DOS, and feel interesting.

Yeah, CCL does work under rosetta2, for example when installed through the old brew install, after you have migrated from X86_64 to M1 macOS. But CCL under rosetta2 is quite slow.

Yes, it is quite slow. I have a hypothesis(maybe wrong): Program(code) run slow for the first time; Program(code) run fast for the second time; Maybe it experiences an rosetta2 translation at its first running.

My "plan" such as it is, is to first develop an ARMv8 simulator in ccl, followed by changing the compiler so that it can compile to ARMv8 all while running in ccl on x86-64.

I don’t see why “write an ARMv8 emulator in Lisp” should be a blocking task here. It might be a fun thing to do and a useful tool, but if the goal is to get a working CCL on macOS running on arm64 hardware, it will probably be a lot easier to:

1. Acquire a Raspberry Pi or similar cheap arm64 Linux box that supports armv7 cross-architecture execution. (This requires the arm64 machine actually support armv7 instructions too, which Apple’s CPUs do not. A Raspberry Pi 3 or 4 should work just fine.)
2. Get CCL fully operational for arm64 Linux, cross-building from CCL for armv7 Linux running under cross-arch on the same system. This will be extremely useful in itself, as there are many more people running arm64 Linux now than there used to be, including in datacenters.
3. Bootstrap CCL for arm64 Darwin/macOS, cross-building from CCL running on arm64 Linux on a VM.
4. Get CCL for arm64 Darwin/macOS self-hosting.

Does ccl run on ARM64 Linux ? The lisp-kernel directory has only a Makefile that was last touched 5 years back. Also linuxarm64 does not appear on the releases list.

Even assuming ccl runs on linuxarm64 I think there are major issues. And that is not with cross compiling but getting in code for supporting m1. Ccl uses optimised assembly extensively. M1 has some minor differences wrt std arm v8/v7 instruction set this is mentioned in the apple dev site, and some registers are reserved. MacOS/Linux use different instruction in some cases (one example adr vs ldr abd there might be more). And ccls choice of using these is not easily portable. If you look at lisp kernel sources the implementation for each architecture is unique. I have also noted assemble code in level-0 and level-1 use assembly for a lot of lisp features like clos, bignum and many more...

If clozure provides more information the wider community may help out. I am personally ok with buying a raspberrypi to get this running on linuxarm64. Buying a m1 system is quite expensive for me. Maybe going for m1 bmaas subscription is an option. But here again it makes sense to know what we are to do and then subscribe. We cant subscribe and then try to figure what needs to be done.

There's only a 32-bit ARM port.

There's only a 32-bit ARM port.

And that would be for armel platforms ? Or includes armhf(Arm7) arch as well ?

It runs just fine on Raspberry PI OS, 32 bit, and lscpu says this looks like a armv7l system.

Hardware wise it is a PI 400, so it could run the 64 bit OS version.  Though in my experience the 32 bit ARM CCL does not run on the 64 bit versions of the OS.

Though if you can get it to work please post instructions.  That would be a big help!

On 2022-12-17T22:57:57.000+01:00, Bharath Kumar Bhaskar Kizhur @.***> wrote:

  There's only a 32-bit ARM port.    And that would be for armel platforms ? Or includes armhf(Arm7) arch  as well ?    —  Reply to this email directly, view it on GitHub  [https://github.com/Clozure/ccl/issues/413#issuecomment-1356479803],  or unsubscribe  [https://github.com/notifications/unsubscribe-auth/ACEXJIS6VFT7KPPOPMKTUBTWNYZOLANCNFSM5VH5YDOQ].  You are receiving this because you commented.Message ID: @.***>

It runs just fine on Raspberry PI OS, 32 bit, and lscpu says this looks like a armv7l system. Hardware wise it is a PI 400, so it could run the 64 bit OS version.  Though in my experience the 32 bit ARM CCL does not run on the 64 bit versions of the OS. Though if you can get it to work please post instructions.  That would be a big help! … On 2022-12-17T22:57:57.000+01:00, Bharath Kumar Bhaskar Kizhur @.> wrote: >  There's only a 32-bit ARM port.    And that would be for armel platforms ? Or includes armhf(Arm7) arch  as well ?    —  Reply to this email directly, view it on GitHub  [#413 (comment)],  or unsubscribe  [https://github.com/notifications/unsubscribe-auth/ACEXJIS6VFT7KPPOPMKTUBTWNYZOLANCNFSM5VH5YDOQ].  You are receiving this because you commented.Message ID: @.>

Just got aarch64 image of ubuntu running on qemu-system-aarch64. M4 crashes due to stack over flow while processing arm64-spentry.s(second file to be processed). Looks like this will take a while. Will post when i get the lisp-kernel built.

M4 goes into an infinite misc_set_u32 while preprocessing arm64-spentry.s and crashing eventually. This happens when processing misc_set_common. This is on both linuxarm64 as well as cygwin. Does anyone know what the issue is ?

There is no 64-bit Arm version of CCL. Whatever files you've found were just some placeholders but no actual work was ever done to get it running.

There is no 64-bit Arm version of CCL. Whatever files you've found were just some placeholders but no actual work was ever done to get it running.

Yes thank you for letting me know. There are so many more issues with just that file. This particular issue was because extract_unsigned_byte was defined as (ubfx $2,$1,$0#$3) in arm64-macros.s. The $0 evaluates to the macro name. Replacing it with #0 fixed the issue.

Why did the development stop?

The Mac App Store version of CCL is broken, and it has been removed from the store.

Issue #11 is about a port to 64-bit ARM.

It's the old, sad story, but development has been slow to non-existent due to lack of sufficient funding.