Smalltalk › Squeak › Squeak - Dev

Apple starting to alert users that it will end 32-bit app support on the Mac

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

fniephaus

Apple starting to alert users that it will end 32-bit app support on the Mac

Hi all,

According to [1], Apple has started to alert users when they open a 32-bit app on the Mac and I've seen such a dialog today myself when opening a 32-bit Squeak image.

It looks like it is time to make 64-bit the default, maybe with the next release? The Pharo community is already doing that for quite some time, so I'm wondering if there is any reason not to do the same?

Best,

Fabio

[1] https://techcrunch.com/2018/04/11/apple-starting-to-alert-users-that-it-will-end-32-bit-app-support/

Bert Freudenberg

Re: Apple starting to alert users that it will end 32-bit app support on the Mac

If that's indeed the case we need to make a 64 bit VM for 32 bit images. I think this should be just a matter of picking the right compiler options.

Otherwise we won't have any way of opening regular 32 bit images on Macs.

- Bert -

On 12 April 2018 at 14:47, Fabio Niephaus <[hidden email]> wrote:

Hi all,

According to [1], Apple has started to alert users when they open a 32-bit app on the Mac and I've seen such a dialog today myself when opening a 32-bit Squeak image.

It looks like it is time to make 64-bit the default, maybe with the next release? The Pharo community is already doing that for quite some time, so I'm wondering if there is any reason not to do the same?

Best,
Fabio

[1] https://techcrunch.com/2018/04/11/apple-starting-to-alert-users-that-it-will-end-32-bit-app-support/

Squeak - Dev mailing list

Re: Apple starting to alert users that it will end 32-bit app support on the Mac

In reply to this post by fniephaus

Switching to 64 bit is the simple solution but it would also prevent us from using 32 bit Raspberry Pi and other similar devices that are on 32 bit processors...

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

On Thursday, April 12, 2018, 8:47:41 a.m. EDT, Fabio Niephaus <[hidden email]> wrote:

Hi all,

According to [1], Apple has started to alert users when they open a 32-bit app on the Mac and I've seen such a dialog today myself when opening a 32-bit Squeak image.

Best,

Fabio

[1] https://techcrunch.com/2018/04/11/apple-starting-to-alert-users-that-it-will-end-32-bit-app-support/

marcel.taeumel

Re: Apple starting to alert users that it will end 32-bit app support on the Mac

It could just be the default for the macOS release.

Best,

Marcel

Am 12.04.2018 15:34:09 schrieb Benoit St-Jean via Squeak-dev <[hidden email]>:
Switching to 64 bit is the simple solution but it would also prevent us from using 32 bit Raspberry Pi and other similar devices that are on 32 bit processors...

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

On Thursday, April 12, 2018, 8:47:41 a.m. EDT, Fabio Niephaus <[hidden email]> wrote:

Hi all,

According to [1], Apple has started to alert users when they open a 32-bit app on the Mac and I've seen such a dialog today myself when opening a 32-bit Squeak image.

It looks like it is time to make 64-bit the default, maybe with the next release? The Pharo community is already doing that for quite some time, so I'm wondering if there is any reason not to do the same?

Best,
Fabio

[1] https://techcrunch.com/2018/04/11/apple-starting-to-alert-users-that-it-will-end-32-bit-app-support/

Tobias Pape

Re: Apple starting to alert users that it will end 32-bit app support on the Mac

In reply to this post by Bert Freudenberg

On 12.04.2018, at 16:05, Eliot Miranda <[hidden email]> wrote:

Hi Bert,

On Apr 12, 2018, at 6:03 AM, Bert Freudenberg <[hidden email]> wrote:

If that's indeed the case we need to make a 64 bit VM for 32 bit images. I think this should be just a matter of picking the right compiler options.

How so? AFAIA it is not. It means, for example, changing every memory access for an instance variable from 64 to 32 bits. It is non-trivial.

But wasn't that done once already?

I see Squeak 5.7.4.1 (John Macintosh did it I think).

Wich advertises itself as

and worked very well. Not saying every bits are there for the present (spur etc)

but at least, we have been there already at least once…

What /is/ trivial is detecting that an image's word size is unsupported on a platform and offering to convert it, a process that takes less than a minute for typical images.

If we go this route we would include a headless 64-bit image that converts 32-bit images to 64-bits on 64-bit only systems, and a headless 32-bit image that converts 64-bit images to 32-bits on 32-bit only systems.

IIRC 64 to 32 bit conversion needs to be written, but I think it is trivial compared to building a 64-bit vm for 32-bit images.

Of course this applies only to Spur images. We don't have a way of automatically converting V3 images to Spur. Yo do that going forward we may have to depend on OS virtual machines, but somehow I can't see an ARMv8 Mac supporting x86 VMs like Parallels. This could be the end of an interoperability era.

Otherwise we won't have any way of opening regular 32 bit images on Macs.

- Bert -

On 12 April 2018 at 14:47, Fabio Niephaus <[hidden email]> wrote:
Hi all,

According to [1], Apple has started to alert users when they open a 32-bit app on the Mac and I've seen such a dialog today myself when opening a 32-bit Squeak image.

It looks like it is time to make 64-bit the default, maybe with the next release? The Pharo community is already doing that for quite some time, so I'm wondering if there is any reason not to do the same?

Best,
Fabio

[1] https://techcrunch.com/2018/04/11/apple-starting-to-alert-users-that-it-will-end-32-bit-app-support/

Bert Freudenberg

Re: Apple starting to alert users that it will end 32-bit app support on the Mac

On 12 April 2018 at 16:31, Tobias Pape <[hidden email]> wrote:

Hi
On 12.04.2018, at 16:05, Eliot Miranda <[hidden email]> wrote:

Hi Bert,

On Apr 12, 2018, at 6:03 AM, Bert Freudenberg <[hidden email]> wrote:

If that's indeed the case we need to make a 64 bit VM for 32 bit images. I think this should be just a matter of picking the right compiler options.

How so? AFAIA it is not. It means, for example, changing every memory access for an instance variable from 64 to 32 bits. It is non-trivial.

But wasn't that done once already?

I see Squeak 5.7.4.1 (John Macintosh did it I think).
Wich advertises itself as

and worked very well. Not saying every bits are there for the present (spur etc)
but at least, we have been there already at least once…

Yep. Its just the 32 bit VM compiled on a 64 bit host. This worked without big problems on the interpreter. I don't know what additional constraints are imposed by Cog / Spur, but I thought at least for intel, the 32 bit instruction set was a strict subset of x64, so there should be no big problems.

- Bert -

johnmci

Re: Apple starting to alert users that it will end 32-bit app support on the Mac

Actually it is a 64bit compiled application that works with 32bit images, there was also a 64bit application that works with 64bit images. However was Eliot points out the format of a 64bit image is different because it has other immediate types, and different context structures. The original 64bit image type didn't have any of those changes.

On Thu, Apr 12, 2018 at 1:34 PM, Bert Freudenberg <[hidden email]> wrote:

On 12 April 2018 at 16:31, Tobias Pape <[hidden email]> wrote:
Hi
On 12.04.2018, at 16:05, Eliot Miranda <[hidden email]> wrote:

Hi Bert,

On Apr 12, 2018, at 6:03 AM, Bert Freudenberg <[hidden email]> wrote:

If that's indeed the case we need to make a 64 bit VM for 32 bit images. I think this should be just a matter of picking the right compiler options.

How so? AFAIA it is not. It means, for example, changing every memory access for an instance variable from 64 to 32 bits. It is non-trivial.

But wasn't that done once already?

I see Squeak 5.7.4.1 (John Macintosh did it I think).
Wich advertises itself as

and worked very well. Not saying every bits are there for the present (spur etc)
but at least, we have been there already at least once…

Yep. Its just the 32 bit VM compiled on a 64 bit host. This worked without big problems on the interpreter. I don't know what additional constraints are imposed by Cog / Spur, but I thought at least for intel, the 32 bit instruction set was a strict subset of x64, so there should be no big problems.

- Bert -

===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================

Bert Freudenberg

Re: Apple starting to alert users that it will end 32-bit app support on the Mac

On 12 April 2018 at 22:45, John McIntosh <[hidden email]> wrote:

Actually it is a 64bit compiled application that works with 32bit images, there was also a 64bit application that works with 64bit images. However was Eliot points out the format of a 64bit image is different because it has other immediate types, and different context structures. The original 64bit image type didn't have any of those changes.

The Spur image, yes.

But we're only talking about running a 32 bit image on a 64 bit VM. Here's a refresher on the terminology:

http://squeakvm.org/squeak64/faq.html

- Bert -

On Thu, Apr 12, 2018 at 1:34 PM, Bert Freudenberg <[hidden email]> wrote:

On 12 April 2018 at 16:31, Tobias Pape <[hidden email]> wrote:
Hi
On 12.04.2018, at 16:05, Eliot Miranda <[hidden email]> wrote:

Hi Bert,

On Apr 12, 2018, at 6:03 AM, Bert Freudenberg <[hidden email]> wrote:

If that's indeed the case we need to make a 64 bit VM for 32 bit images. I think this should be just a matter of picking the right compiler options.

How so? AFAIA it is not. It means, for example, changing every memory access for an instance variable from 64 to 32 bits. It is non-trivial.

But wasn't that done once already?

I see Squeak 5.7.4.1 (John Macintosh did it I think).
Wich advertises itself as

and worked very well. Not saying every bits are there for the present (spur etc)
but at least, we have been there already at least once…

Yep. Its just the 32 bit VM compiled on a 64 bit host. This worked without big problems on the interpreter. I don't know what additional constraints are imposed by Cog / Spur, but I thought at least for intel, the 32 bit instruction set was a strict subset of x64, so there should be no big problems.

- Bert -

--
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================

Eliot Miranda-2

Re: Apple starting to alert users that it will end 32-bit app support on the Mac

In reply to this post by Bert Freudenberg

Hi Bert,

On Thu, Apr 12, 2018 at 1:34 PM, Bert Freudenberg <[hidden email]> wrote:

On 12 April 2018 at 16:31, Tobias Pape <[hidden email]> wrote:
Hi
On 12.04.2018, at 16:05, Eliot Miranda <[hidden email]> wrote:

Hi Bert,

On Apr 12, 2018, at 6:03 AM, Bert Freudenberg <[hidden email]> wrote:

If that's indeed the case we need to make a 64 bit VM for 32 bit images. I think this should be just a matter of picking the right compiler options.

How so? AFAIA it is not. It means, for example, changing every memory access for an instance variable from 64 to 32 bits. It is non-trivial.

But wasn't that done once already?

I see Squeak 5.7.4.1 (John Macintosh did it I think).
Wich advertises itself as

and worked very well. Not saying every bits are there for the present (spur etc)
but at least, we have been there already at least once…

Yep. Its just the 32 bit VM compiled on a 64 bit host. This worked without big problems on the interpreter. I don't know what additional constraints are imposed by Cog / Spur, but I thought at least for intel, the 32 bit instruction set was a strict subset of x64, so there should be no big problems.

The main problem is in arranging that the heap is allocated in the 32-bit addressable part of the address space. It's also effectively another VM to support, with its won bizarre configuration of FFI (64-bit) for a 32-bit client. That could be expensive.

The thing that the above 64-bit system did that made it quick to port but under-performant was to keep oops exactly the same as in 32-bits, but simply make them occupy 64-bits. SmallIntegers had the same range as in 32-bits. And I'm guessing that this predated Andreas' FFI, so it could avoid addressing the FFI issue. We can't. If we wanted full support we would have to provide a way of loading 32-bit dlls and calling them via the FFI through the 32-bit calling convention. That's not trivial.

That's why for me by far the simplest thing is to convert.

_,,,^..^,,,_

best, Eliot

Eliot Miranda-2

Re: Apple starting to alert users that it will end 32-bit app support on the Mac

In reply to this post by Bert Freudenberg

Hi Bert, Hi David,

On Thu, Apr 12, 2018 at 1:57 PM, Bert Freudenberg <[hidden email]> wrote:

On 12 April 2018 at 22:45, John McIntosh <[hidden email]> wrote:
Actually it is a 64bit compiled application that works with 32bit images, there was also a 64bit application that works with 64bit images. However was Eliot points out the format of a 64bit image is different because it has other immediate types, and different context structures. The original 64bit image type didn't have any of those changes.

The Spur image, yes.

But we're only talking about running a 32 bit image on a 64 bit VM. Here's a refresher on the terminology:

http://squeakvm.org/squeak64/faq.html

So am I being a prima donna by finding this page misleading? It's referring to a system that few if any people use. It doesn't mention that we have a 64-bit system that is much faster, has a full FFI, etc. Shouldn't this page at least say that there is a more modern 64-bit system along with a URL, and state that this VM is effectively obsolete? Does this come over like me trying to kill the old VM? I wish people would be frank about their feelings (if any) here rather than keeping silent. I don't want to offend, but I do want to provide high-performance functional systems with the person power we have available, and provide good information to the new user. I do feel frustrated when I see the old 64-bit system still described as if it's current. I wonder if people feel as strongly for the old 64-bit system.

- Bert -

On Thu, Apr 12, 2018 at 1:34 PM, Bert Freudenberg <[hidden email]> wrote:

On 12 April 2018 at 16:31, Tobias Pape <[hidden email]> wrote:
Hi
On 12.04.2018, at 16:05, Eliot Miranda <[hidden email]> wrote:

Hi Bert,

On Apr 12, 2018, at 6:03 AM, Bert Freudenberg <[hidden email]> wrote:

If that's indeed the case we need to make a 64 bit VM for 32 bit images. I think this should be just a matter of picking the right compiler options.

How so? AFAIA it is not. It means, for example, changing every memory access for an instance variable from 64 to 32 bits. It is non-trivial.

But wasn't that done once already?

I see Squeak 5.7.4.1 (John Macintosh did it I think).
Wich advertises itself as

and worked very well. Not saying every bits are there for the present (spur etc)
but at least, we have been there already at least once…

Yep. Its just the 32 bit VM compiled on a 64 bit host. This worked without big problems on the interpreter. I don't know what additional constraints are imposed by Cog / Spur, but I thought at least for intel, the 32 bit instruction set was a strict subset of x64, so there should be no big problems.

- Bert -

--
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk
===========================================================================

_,,,^..^,,,_

best, Eliot

Jecel Assumpcao Jr

Re: [Vm-dev] Apple starting to alert users that it will end 32-bit app support on the Mac

In reply to this post by Eliot Miranda-2

Eliot Miranda wrote on Thu, 12 Apr 2018 14:10:38 -0700
> That's why for me by far the simplest thing is to convert.

Computers have become a hundred times faster since Squeak first came out
and while disks are also faster the difference is a lot less dramatic.
So though having image files be nearly exact memory dumps might not be
as important today.

Couldn't we have a (possibly optional) plugin capable of loading
different image file formats and then depositing the objects into the
VMs memory? I am supposing that computing and disk i/o happen in
parallel. In that case even non trivial transformations would be
essentially free.

If the performance is good enough we could convert on every single load
if needed. Currently we convert endiness on load, but always save in the
native order. This policy would work well here as well, except that a
lack of "save as 32 Bit V3" and such would make sharing with old VMs
harder. I don't see as a problem since the format wouldn't be the only
thing that would trip up an older VM and you could always use something
like SystemTracer if you really need this.

An alternative that I worked on in the 1990s was a size independent
image format. It used trivial compression to encode integers that could
be arbitrarily long. Object references were compressed by being relative
to each object being encoded: so 3 means the object a little after this
one in the file while -1 is the previous object. As the file was read in
the integers would become either SmallIntegers or LargeIntegers
depending on the processor's bit width.

I would not recommend something like this for Open Smalltalk, but was
just showing that there are multiple solutions.
-- Jecel

David T. Lewis

Re: Apple starting to alert users that it will end 32-bit app support on the Mac

In reply to this post by Eliot Miranda-2

On Thu, Apr 12, 2018 at 02:15:00PM -0700, Eliot Miranda wrote:
> Hi Bert, Hi David,

Hi,

I am hopelessly behind on emails and I probably missed a lot of the
discussion, but I'll try to catch up a bit.

Bert is right that saying that a 64 bit host VM should work with a 32 bit
image, and that this is the right thing to do. In theory it should also
be the easiest thing to do, but in practice it probably is not.

Eliot is right is saying that making a 64 bit host/32 bit image VM is
non-trivial. There probably are no big issues, but I would expect a lot
of small issues and a lot of effort required to make it happen. The general
approach of generating a single ./src base for the 32/64 bit images would
probably still work for the oscog code base, but actually doing all of
those changes, while also adding the cog code generator differences
(which I actually know very little about) does not sound like a small
project to me, and even with the best of intentions it would not get
done any time soon.

John summarized nicely below, I would add only that for the base interpreter
VM, all four combinations of 32 and 64 bit host and image worked properly
at one point, and I say "at one point" only because I have not recently
tried the 64 bit image on 32 bit host combination, and the last time I
tried it there was a bit rot regression. We also had 32/64 bit FFI working,
but that was in Mantis and never made its way into the VM.

Tim has a really good suggestion about handling image conversion at image
load time. This might work and we should give it some thought. A trivially
simple example is the interpreter VM loading Cog 6505 images, and running
and saving in its native 6504 format. I don't know how extensible this
approach is, but the general idea of a VM that can load and run a wide
variety of input formats, while saving them in its own preferred native
format, makes a lot of sense to me.

Eliot suggests using worker images to do image conversions. That will be
messy from a support and distribution point of view, but it is probably
our best and only near term solution.

One more note in line below.

>
> On Thu, Apr 12, 2018 at 1:57 PM, Bert Freudenberg <[hidden email]>
> wrote:
>
> > On 12 April 2018 at 22:45, John McIntosh <[hidden email]>
> > wrote:
> >
> >> Actually it is a 64bit compiled application that works with 32bit images,
> >> there was also a 64bit application that works with 64bit images. However
> >> was Eliot points out the format of a 64bit image is different because it
> >> has other immediate types, and different context structures. The original
> >> 64bit image type didn't have any of those changes.
> >>
> >
> +1
>
> ???The Spur image, yes.
> >
> > But we're only talking about running a 32 bit image on a 64 bit VM. Here's
> > a refresher on the terminology:
> >
> > http://squeakvm.org/squeak64/faq.html???
> >
>
> So am I being a prima donna by finding this page misleading?

Prima donna? no. Defensive? perhaps.

Bert was referring to that page because it clarifies the terminology. That
is a helpful thing in the context of a discussion like this.

Dave

> It's
> referring to a system that few if any people use. It doesn't mention that
> we have a 64-bit system that is much faster, has a full FFI, etc.
> Shouldn't this page at least say that there is a more modern 64-bit system
> along with a URL, and state that this VM is effectively obsolete? Does
> this come over like me trying to kill the old VM? I wish people would be
> frank about their feelings (if any) here rather than keeping silent. I
> don't want to offend, but I do want to provide high-performance functional
> systems with the person power we have available, and provide good
> information to the new user. I do feel frustrated when I see the old
> 64-bit system still described as if it's current. I wonder if people feel
> as strongly for the old 64-bit system.
>
>
>
> > - Bert -
> >
> >
> >
> >>
> >>
> >> On Thu, Apr 12, 2018 at 1:34 PM, Bert Freudenberg <[hidden email]>
> >> wrote:
> >>
> >>>
> >>>
> >>> On 12 April 2018 at 16:31, Tobias Pape <[hidden email]> wrote:
> >>>
> >>>> Hi
> >>>>
> >>>> On 12.04.2018, at 16:05, Eliot Miranda <[hidden email]> wrote:
> >>>>
> >>>> Hi Bert,
> >>>>
> >>>>
> >>>> On Apr 12, 2018, at 6:03 AM, Bert Freudenberg <[hidden email]>
> >>>> wrote:
> >>>>
> >>>> If that's indeed the case we need to make a 64 bit VM for 32 bit
> >>>> images. I think this should be just a matter of picking the right compiler
> >>>> options.
> >>>>
> >>>>
> >>>> How so? AFAIA it is not. It means, for example, changing every memory
> >>>> access for an instance variable from 64 to 32 bits. It is non-trivial.
> >>>>
> >>>>
> >>>> But wasn't that done once already?
> >>>>
> >>>> I see Squeak 5.7.4.1 (John Macintosh did it I think).
> >>>> Wich advertises itself as
> >>>>
> >>>> and worked very well. Not saying every bits are there for the present
> >>>> (spur etc)
> >>>> but at least, we have been there already at least once???
> >>>>
> >>>
> >>> ???Yep. Its just the 32 bit VM compiled on a 64 bit host. This worked
> >>> without big problems on the interpreter. I don't know what additional
> >>> constraints are imposed by Cog / Spur, but I thought at least for intel,
> >>> the 32 bit instruction set was a strict subset of x64, so there should be
> >>> no big problems.
> >>>
> >>> - Bert -???
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> ============================================================
> >> ===============
> >> John M. McIntosh. Corporate Smalltalk Consulting Ltd
> >> https://www.linkedin.com/in/smalltalk
> >> ============================================================
> >> ===============
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
> --
> _,,,^..^,,,_
> best, Eliot

Phil B

Re: Apple starting to alert users that it will end 32-bit app support on the Mac

In reply to this post by Eliot Miranda-2

Eliot,

On Thu, Apr 12, 2018, 5:15 PM Eliot Miranda <[hidden email]> wrote:

Hi Bert, Hi David,

On Thu, Apr 12, 2018 at 1:57 PM, Bert Freudenberg <[hidden email]> wrote:
On 12 April 2018 at 22:45, John McIntosh <[hidden email]> wrote:
Actually it is a 64bit compiled application that works with 32bit images, there was also a 64bit application that works with 64bit images. However was Eliot points out the format of a 64bit image is different because it has other immediate types, and different context structures. The original 64bit image type didn't have any of those changes.

+1

The Spur image, yes.

But we're only talking about running a 32 bit image on a 64 bit VM. Here's a refresher on the terminology:

http://squeakvm.org/squeak64/faq.html

This page doesn't appear to have been touched since 2007. Though it would be nice if someone could do something similar to this page as was done to wiki.squeak.org/squeak/560

(For the record, I do still occasionally fire up the legacy VMs including the 64-bit version. But don't worry, I'm not pining for the good old days when VMs ran at a more leisurely pace... It's a compatibility thing :-)

So am I being a prima donna by finding this page misleading? It's referring to a system that few if any people use. It doesn't mention that we have a 64-bit system that is much faster, has a full FFI, etc. Shouldn't this page at least say that there is a more modern 64-bit system along with a URL, and state that this VM is effectively obsolete? Does this come over like me trying to kill the old VM? I wish people would be frank about their feelings (if any) here rather than keeping silent. I don't want to offend, but I do want to provide high-performance functional systems with the person power we have available, and provide good information to the new user. I do feel frustrated when I see the old 64-bit system still described as if it's current. I wonder if people feel as strongly for the old 64-bit system.

-