Live data from Hacker News

MIT Scheme on Apple Silicon

kennethfriedman.org

51–60 of 87 posts

Re: MIT Scheme on Apple Silicon

#51
post #14
post #8

What's stopping people from just compiling Scheme for ARM? The website has a separate aarch64 download it seems, so why not patch that instead of relying on Rosetta2? The vfork/fork issue and the compiler upgrade issue don't seem to be too problematic to work around, so there must be some kind of ARM limitation that's preventing Scheme from working, but what?

MacOS on the M1 processor is the first to use, and require, the W^X bit in memory, meaning that pages of memory are either writable, or can be executed from, but not both. MIT Scheme's front page says this is fundamentally incompatible with their design, and therefore it won't build. When running in the emulator, this requirement would be relaxed for compatibility reasons. There is an escape hatch for writing JIT com…

From perusing the source of the MIT/GNU Scheme compiler, I suspect that “only” two changes are needed to support W^X:

- Compiled code needs to be allocated separately from Scheme objects. It can still be garbage collected and such - they will probably need to make a separate set of allocation functions for code vs. data. The closure/function objects can be made to point to the code, or, if they don’t need to be written often, simply allocated wholly from the “code” pages. - Before modifying any of the code (e.g. to patch addresses after GC relocation), a system-specific hook function will need to be called to set the permissions to RW. They already call an I-cache flush function after each modification, so this shouldn’t be too bad.

Some of the necessary changes are already sketched out in cmpint.txt. And, sooner or later, they’re going to have to make these changes: OpenBSD already enforces W^X (but provides a workaround), and MIT/GNU Scheme already applies a paxctl workaround to gain W|X on NetBSD.

Re: MIT Scheme on Apple Silicon

#52

Earlier quoted context omitted.

I can't say what Apple will do, but I'm really hoping they'll keep Rosetta 2 around for longer than Rosetta 1. For starters, the Mac became a lot more popular in the Intel era than it ever was while on PPC, so there's a much larger quantity of legacy software that Apple would be cutting off. Secondly, the overall user experience of running apps via Rosetta 2 seems to be a lot better than Rosetta 1. And for Apple, Ros…

And for Apple, Rosetta 2 was developed in-house and doesn't require continuous licensing fees to keep around (not that I'm particularly sympathetic to Apple's pocketbook.) I don't think any of those things matter; Apple will stop supporting Rosetta 2 as quickly as they can. They announced the transition to Apple Silicon will be two years and unless something unforeseen happens, that's what it's going to be. I suspect…

> A great example is 32-bit apps, where Apple gave something like an 8-year heads-up that 32-bit apps were going away, which happened a few years ago but it's not hard to find threads on HN where people are still complaining about it.

But actually, I personally believe that the actual reason Apple killed 32bit support was because they didn't want to build it into Rosetta. (And they didn't want Intel computers to be able to run anything their new Apple Silicon computers could not.)

Before Apple Silicon was on the horizon, it was no problem for Apple to keep 32 bit and carbon libraries around for eight years because they might as well, it's not doing any harm.

(I'm also one of the people who was/is mad about 32 bit support, but I acknowledge that my opinion on the matter has no bearing on what Apple will decide to do.)

Re: MIT Scheme on Apple Silicon

#53
post #10

Earlier quoted context omitted.

So Java, Groovy, Scala, Kotlin and Clojure aren't running on x86, nor ARM, nor Apple Silicon?

In a lot of ways, yes. Their runtimes are so massive that saying they "run" on any of those architectures is a stretch of what is actually happening at a lower level.

Depending on code, a quite large fraction of your java code is run as x86 machine code at any times. It hardly gets more native than that.

Re: MIT Scheme on Apple Silicon

#55
post #20

Earlier quoted context omitted.

I'm comfortable making that distinction. JavaScript isn't executed like normal, native code, so... I still agree.

When the majority of programs in the world can't be "run" according to your definition, you might want to reconsider your definition.

Since we're enjoying a nitpick picnic you can compile JS AOT to Java with rhino and then to native code with GCJ

Re: MIT Scheme on Apple Silicon

#57

Earlier quoted context omitted.

I have to ask, how far along is this project? Is it good enough to run all of the examples in the books? I have run into the issue where the provided compiled version of scmutils from GJS' website doesn't run on recent versions of MIT Scheme (version 11 and up) and there's not much info on compiling it yourself.

It is good enough! Almost all code forms from the book live in the tests (see the FDG directory[0], for example), and there are a few nice environments like Nextjournal[1] where everything from the books works in the browser. The Clojure port is quite fast, faster than the original for all benchmarks GJS has sent me, and more fleshed out. (That will change, as I've been pushing bugfixes and performance improvements b…

Awesome resources, thank you!

Re: MIT Scheme on Apple Silicon

#58

Earlier quoted context omitted.

And for Apple, Rosetta 2 was developed in-house and doesn't require continuous licensing fees to keep around (not that I'm particularly sympathetic to Apple's pocketbook.) I don't think any of those things matter; Apple will stop supporting Rosetta 2 as quickly as they can. They announced the transition to Apple Silicon will be two years and unless something unforeseen happens, that's what it's going to be. I suspect…

> A great example is 32-bit apps, where Apple gave something like an 8-year heads-up that 32-bit apps were going away, which happened a few years ago but it's not hard to find threads on HN where people are still complaining about it. But actually, I personally believe that the actual reason Apple killed 32bit support was because they didn't want to build it into Rosetta. (And they didn't want Intel computers to be a…

But actually, I personally believe that the actual reason Apple killed 32bit support was because they didn't want to build it into Rosetta. (And they didn't want Intel computers to be able to run anything their new Apple Silicon computers could not.)

I doubt it; that’s not how Apple rolls. They’re not like Microsoft which keeps legacy technologies around for backwards compatibility for several years after a technology is no longer mainstream.

Reasonable people can disagree but Apple is about the present and the future, not the past. Sure, they could have kept Carbon around or pick your favorite framework from the past but that’s generally not their thing.

Occasionally something from their past reappears, like the QuickDraw GX font format from the 90s that became the basis for today’s variable fonts on the web.

Apple has always been fine with some software not making the leap to the next operating system or processor architecture.

We’ve seen this going back to 68K to PowerPC then to Intel and now ARM.

Being able to run x86 operating systems (Windows) natively on Intel Macs was a huge selling point not that long ago and now it’s an afterthought that current buyers (mostly) don’t care about. Microsoft would bring Windows for ARM to Apple Silicon and so far, they haven’t.

And while this is all going on, Macs have never been more popular.

Re: MIT Scheme on Apple Silicon

#59

Earlier quoted context omitted.

And for Apple, Rosetta 2 was developed in-house and doesn't require continuous licensing fees to keep around (not that I'm particularly sympathetic to Apple's pocketbook.) I don't think any of those things matter; Apple will stop supporting Rosetta 2 as quickly as they can. They announced the transition to Apple Silicon will be two years and unless something unforeseen happens, that's what it's going to be. I suspect…

> A great example is 32-bit apps, where Apple gave something like an 8-year heads-up that 32-bit apps were going away, which happened a few years ago but it's not hard to find threads on HN where people are still complaining about it. But actually, I personally believe that the actual reason Apple killed 32bit support was because they didn't want to build it into Rosetta. (And they didn't want Intel computers to be a…

I would say it is more of the legacy codes that Apple don't want to keep providing support for backward compatibility. And it uses up spaces in your drive if they need to keep 32-bit library in case for those app that are running in that level.

Microsoft want to do that but it will be a huge risk since it will alienate their enterprise consumers.

Re: MIT Scheme on Apple Silicon

#60
post #43

Earlier quoted context omitted.

Pointer authentication isn’t in 3rd party processes though, only system ones. (or maybe it’s available but optional, I forget)

> Pointer authentication isn’t in 3rd party processes though Still isn’t, because the arm64e ABI isn’t stable. As such, any binaries not bundled with the OS, including Apple applications, use the arm64 ABI without pointer authentication. You can use -arm64e_preview_abi as a boot argument to enable arm64e support for non-OS bundled processes. Note that however the arm64e binaries that you compile might not work on fut…

System libraries are more than happy to use some parts of pointer authentication, such as return address signing.
Post reply on HN