ccl icon indicating copy to clipboard operation
ccl copied to clipboard

Port to 64-bit ARM

Open xrme opened this issue 8 years ago • 8 comments

Port CCL to the 64-bit ARM.

Historically, a port to a new architecture has taken about 3 or 4 wizard-months.

The 64-bit ARM can be configured in such a way that the high 8 bits of address will be ignored by the address-translation hardware. This requires OS support, but the last time we looked, Linux kernel version 3.12.0 seemed to have adequate support (i.e., the tags were preserved in signal context, in addition to setting the MMU bit to enable ignoring the high 8 bits of addresses).

This makes it worthwhile to consider using high tags. I have collected some notes about this and other issues that I could probably transcribe somewhere when/if we ever get the resources to do this port.

xrme avatar Feb 18 '17 18:02 xrme

I fried my Odroid C2 (the only 64-bit ARM I have) by using a 12v power adapter rather than a 5v power adapter. I ordered a replacement, but it won't ship until January.

xrme avatar Dec 19 '17 22:12 xrme

What would one need to do to get this ball rolling? I have a Raspberry Pi 4 computer (64-bit Manjaro Linux), some knowledge in C, more knowledge in Lisp, and a desire to contribute to a thing!

I don't know if I could complete it in 3-4 Wizard Months, but it doesn't look like this has been touched in 3-4 Wizard Years! 😜 I would like to at least push this forward a bit, and see what I would need to get started.

serialhex avatar Oct 06 '21 17:10 serialhex

What I have tried to do with very little success is to convert the arm32 kernel to an arm64 one.

I figured once I had a working arm64 kernel I could modify the compiler to produce arm64 output rather than arm32 output and slowly iterate do where I would have a full arm64 version.

I have not been successful.  It is made worse because I don't know either arm32 nor arm64 assembly so the changes to make the lisp kernel assemble has been very slow.

I've also been hindered because the source files are processed by m4 so it is slow for me to trace the error message back to where in the source file it is wrong.

I've considered just writing the lisp kernel from scratch.  It is possible that would be slower to start but would teach me enough that in the end it would be faster.

It seems what is needed here is someone who deeply understands how CCL is put together combined with a good arm64 understanding.

cheers

bruce

On 2021-10-06T19:33:21.000+02:00, serialhex @.***> wrote:

 What would one need to do to get this ball rolling? I have a  Raspberry Pi 4 computer (64-bit Manjaro Linux), some knowledge in C,  more knowledge in Lisp, and a desire to contribute to a thing!    I don't know if I could complete it in 3-4 Wizard Months, but it  doesn't look like this has been touched in 3-4 Wizard Years! 😜 I  would like to at least push this forward a bit, and see what I would  need to get started.    —  You are receiving this because you are subscribed to this thread.  Reply to this email directly, view it on GitHub  [https://github.com/Clozure/ccl/issues/11#issuecomment-936753995],  or unsubscribe  [https://github.com/notifications/unsubscribe-auth/ACEXJIRL44CK3QI23SSGN6TUFSB6DANCNFSM4DAUZILA].  Triage notifications on the go with GitHub Mobile for iOS  [https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675]  or Android  [https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub].

edoneel avatar Oct 06 '21 18:10 edoneel

Any progress on this? Other issues are closed referencing this one, so was wondering and the last update is a while back..

vrunhofen avatar Aug 11 '23 09:08 vrunhofen

Now, the problem will recur with the next processor, and the next, etc. Perhaps we should defer to a team with bigger budget, I mean LLVM. A port to LLVM would allow us to benefit from all the LLVM backends at once, and to get updates with minimal work. We may just have to adjust to the VM layout for the various word sizes. https://llvm.org/docs/CodeGenerator.html. Of course if somebody wanted to work on the LLVM backend, then that would be a different issue: Port to LLVM.

informatimago avatar Aug 11 '23 10:08 informatimago

Any progress on this? Other issues are closed referencing this one, so was wondering and the last update is a while back..

Little to no progress.

There is developer interest (as least I'm interested) in working on it, but it's the old, sad, story of not enough money and therefore not enough time.

xrme avatar Aug 11 '23 17:08 xrme

Now, the problem will recur with the next processor, and the next, etc.

Excellent point. However, if you pick your battles, sometimes you can win the endgame--which to me is the CCL IDE on macOS. I wonder what other people think about CCL's continuing "raison d'être".

ghost avatar Sep 23 '23 15:09 ghost