Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MIT Scheme on Apple Silicon

kennethfriedman.org

Post reply on HN
Print view View original

71–80 of 87 posts

Re: MIT Scheme on Apple Silicon

#71

Post by olliej »

spijdar wrote: post #14
jeroenhd wrote: 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…

I mean if they pass the correct flags they get memory that can be toggled rapidly between X and W mode - or is MIT Scheme mixing data and code in the heap and so actually requiring RWX?

Re: MIT Scheme on Apple Silicon

#72

Post by olliej »

esprehn wrote: post #35
spijdar wrote: post #32

Earlier quoted context omitted.

Basically, yeah. In addition, the usual way to bypass W^X memory, using ROP chains, is also mitigated by the pointer authentication the M1 implements. It's not bullet proof, but it prevents most of the old exploit methods from working at all. You'd need to throw up a VM on an M1 Mac to learn much this way (although that'd be ideal anyway, to get an environment without other protections like ASLR) I know at least Open…

Windows has had this enabled by default for a long time: https://docs.microsoft.com/en-us/windows/win32/memory/data-e... There's a per program exception list to handle legacy programs though.

On M1 CPUs you cannot ever have simultaneously writable and executable memory. Windows just makes default allocations write only, you have to explicitly request RWX, which is what every other OS has been doing basically since x86 actually added support for non executable memory :)

Re: MIT Scheme on Apple Silicon

#73

Post by olliej »

simonh wrote: post #17
jeroenhd wrote: post #13

Earlier quoted context omitted.

Apple Silicon has a (mostly) hardware translation layer, which this software is running on. There's a special aarch64 build of the software available, so it clearly runs on ARM. Perhaps there's some kind of issue specifically on macOS that makes the existing ARM port incompatible with Apple's ARM implementation?

> Apple Silicon has a (mostly) hardware translation layer… I can’t imagine what you mean by this, Rosetta 2 is a binary translation system implemented in software, based on QuickTransit. There are a few features implemented in Apple Silicon to make translation easier and more efficient, such as supporting Intel memory ordering, but thats about it. I think it’s reasonable to worry about how long rosetta2 will be avail…

Rosetta 2 has nothing to do with Rosetta 1 (other than the name), nor any other company’s software.

Re: MIT Scheme on Apple Silicon

#74

Post by astrange »

Wowfunhappy wrote: post #52
alwillis wrote: post #50

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…

x86-32 was removed because it’s significantly less secure and performant than x86-64 and there were unfixable issues with the ABI like fragile ObjC superclasses. Don’t need any secret projects to explain that. The only people who seem to still have a problem are video game developers, who should maybe try writing clean code.

32-bit isn’t completely gone, it’s still on watchOS.

Re: MIT Scheme on Apple Silicon

#75

Post by School-Cotton »

Koshkin wrote: post #64

That MIT Scheme includes an emacs clone that uses Scheme instead of elisp is a nice touch.

There’s a fork of Emacs itself that can run scheme, by replacing the internal lisp engine with Guile (which can run both scheme and elisp). It doesn’t seem to have gotten a lot of love in the last few years, but did mostly work at one point.

Re: MIT Scheme on Apple Silicon

#77

Post by kkylin »

bigdict wrote: post #67
mark_l_watson wrote: post #66

Earlier quoted context omitted.

I like it, but I have only worked about 1/3 of the way through it.

What would someone who has worked through SICP learn from it (based on the first third that you've read)?

I've also gotten through about the first 1/3. Based on this, and the table of contents, it goes into much more depth (both in terms of implementation and non-trivial illustrative examples) into a number of topics that are either only touched upon in SICP, or not discussed at all. These include combinators, generic functions, pattern matching, etc. There's a chapter on propagators, which didn't even exist when the last edition of SICP was written, though I think SICP does discuss related (but simpler) ideas on constraint propagation.

Re: MIT Scheme on Apple Silicon

#78

Post by saagarjha »

Wowfunhappy wrote: post #68
saagarjha wrote: post #62

Earlier quoted context omitted.

> But actually, I personally believe that the actual reason Apple killed 32bit support was because they didn't want to build it into Rosetta. Rosetta 2 contains functionality to correctly emulate 32-bit Intel code.

It's not the 32 bit code though, it's all the old libraries (carbon) which happen to also be 32 bit.

Right. The 32 bit emulation is only really useful to CrossOver.

Re: MIT Scheme on Apple Silicon

#79

Post by bigdict »

kkylin wrote: post #77
bigdict wrote: post #67

Earlier quoted context omitted.

What would someone who has worked through SICP learn from it (based on the first third that you've read)?

I've also gotten through about the first 1/3. Based on this, and the table of contents, it goes into much more depth (both in terms of implementation and non-trivial illustrative examples) into a number of topics that are either only touched upon in SICP, or not discussed at all. These include combinators, generic functions, pattern matching, etc. There's a chapter on propagators, which didn't even exist when the las…

Thank you.
Post reply on HN