Smalltalk › Squeak › Squeak - Dev

managing the transition to 64-bit

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Chris Muller-4

managing the transition to 64-bit

I'm ready to make a push to migrate all my stuff to 64-bit, so this
means I need the ability to run either a 32-bit VM or a 64-bit VM, at
least for now. Unfortunately, it appears each uses the same the VM
file directory structure, and so whichever one is installed last
stomps out the other.

Eliot, you have unique names for VM versions, have you considered
inserting something to uniquefy the names to support co-existence of
32 and 64-bit of the same VM version? Or, does anyone have any best
practices to allow the co-existence of 32-bit with 64-bit VM?

I'm not talking about the problem with the names of the executables
(scripts) all being "squeak". I've already been renaming the shell
scripts from "squeak" to "cog" or "spur". Now the problem between 32
and 64-bit is the "lib" directory they refer to -- they share the
exact same name.

I still have a lot of 32-bit images around. Does anyone have any
pointers on how best to manage both a 32-bit and 64-bit?

Levente Uzonyi

Re: managing the transition to 64-bit

Do you mean that you want to make a single executable to run both 32-bit
and 64-bit images?
If so, you can make a script which reads the image version from the header
and runs it with the corresponding VM.
But I don't see why you would want to do that. :)

Levente

On Mon, 12 Dec 2016, Chris Muller wrote:

> I'm ready to make a push to migrate all my stuff to 64-bit, so this
> means I need the ability to run either a 32-bit VM or a 64-bit VM, at
> least for now. Unfortunately, it appears each uses the same the VM
> file directory structure, and so whichever one is installed last
> stomps out the other.
>
> Eliot, you have unique names for VM versions, have you considered
> inserting something to uniquefy the names to support co-existence of
> 32 and 64-bit of the same VM version? Or, does anyone have any best
> practices to allow the co-existence of 32-bit with 64-bit VM?
>
> I'm not talking about the problem with the names of the executables
> (scripts) all being "squeak". I've already been renaming the shell
> scripts from "squeak" to "cog" or "spur". Now the problem between 32
> and 64-bit is the "lib" directory they refer to -- they share the
> exact same name.
>
> I still have a lot of 32-bit images around. Does anyone have any
> pointers on how best to manage both a 32-bit and 64-bit?

timrowledge

Re: managing the transition to 64-bit

> On 12-12-2016, at 10:55 AM, Levente Uzonyi <[hidden email]> wrote:
>
> Do you mean that you want to make a single executable to run both 32-bit and 64-bit images?
> If so, you can make a script which reads the image version from the header and runs it with the corresponding VM.

I’m pretty sure there is already a program (‘ckformat' I think?) that reads the header and reports the type. It’s even used in the shell script for launching squeak, at least in the interpreterVM world.

Take a look at http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/unix/cmake/squeak.in?view=markup
and
http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/unix/cmake/ckformat.c?view=markup

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Why use one word when two polysyllabic agglomerates will do?

Chris Muller-3

Re: managing the transition to 64-bit

In reply to this post by Levente Uzonyi

I'm saying that the traditional way of installing a global VM, by installing under /usr/local, cannot support dual 32 and 64-bit installation because the directory name under "lib" is exactly the same for both platforms.

Installing from cog_linux32x86_squeak.cog.spur_201608171728.tar.gz:

/./products/cogspurlinuxht/lib/squeak/5.0-201608171728/squeak "32-bit"

and from cog_linux64x64_squeak.cog.spur_201608171728.tar.gz:

/./products/cogspur64linuxht/lib/squeak/5.0-201608171728/squeak "64-bit!"

copying from the highlighted, down, to the traditional /usr/local location makes that conflict.

I want to run the same version of each VM, so there will be no question if disparity's arise during testing. I'd like to have access to a global "spur" (32-bit) and "spur64" commands. Any advice for this Linux user is appreciated, thx..

On Mon, Dec 12, 2016 at 12:55 PM, Levente Uzonyi <[hidden email]> wrote:

Do you mean that you want to make a single executable to run both 32-bit and 64-bit images?
If so, you can make a script which reads the image version from the header and runs it with the corresponding VM.
But I don't see why you would want to do that. :)

Levente

On Mon, 12 Dec 2016, Chris Muller wrote:

I'm ready to make a push to migrate all my stuff to 64-bit, so this
means I need the ability to run either a 32-bit VM or a 64-bit VM, at
least for now. Unfortunately, it appears each uses the same the VM
file directory structure, and so whichever one is installed last
stomps out the other.

Eliot, you have unique names for VM versions, have you considered
inserting something to uniquefy the names to support co-existence of
32 and 64-bit of the same VM version? Or, does anyone have any best
practices to allow the co-existence of 32-bit with 64-bit VM?

I'm not talking about the problem with the names of the executables
(scripts) all being "squeak". I've already been renaming the shell
scripts from "squeak" to "cog" or "spur". Now the problem between 32
and 64-bit is the "lib" directory they refer to -- they share the
exact same name.

I still have a lot of 32-bit images around. Does anyone have any
pointers on how best to manage both a 32-bit and 64-bit?

Ben Coman

Re: managing the transition to 64-bit

On Tue, Dec 13, 2016 at 3:34 AM, Chris Muller <[hidden email]> wrote:

I'm saying that the traditional way of installing a global VM, by installing under /usr/local, cannot support dual 32 and 64-bit installation because the directory name under "lib" is exactly the same for both platforms.

Installing from cog_linux32x86_squeak.cog.spur_201608171728.tar.gz:

/./products/cogspurlinuxht/lib/squeak/5.0-201608171728/squeak "32-bit"

and from cog_linux64x64_squeak.cog.spur_201608171728.tar.gz:

/./products/cogspur64linuxht/lib/squeak/5.0-201608171728/squeak "64-bit!"

copying from the highlighted, down, to the traditional /usr/local location makes that conflict.

I want to run the same version of each VM, so there will be no question if disparity's arise during testing. I'd like to have access to a global "spur" (32-bit) and "spur64" commands. Any advice for this Linux user is appreciated, thx..

But since gong forward there is likely more 64-bit installs than 32 bit, perhaps that should be spur32 & spur (64-bit)?

cheers -ben

On Mon, Dec 12, 2016 at 12:55 PM, Levente Uzonyi <[hidden email]> wrote:
Do you mean that you want to make a single executable to run both 32-bit and 64-bit images?
If so, you can make a script which reads the image version from the header and runs it with the corresponding VM.
But I don't see why you would want to do that. :)

Levente

On Mon, 12 Dec 2016, Chris Muller wrote:

I'm ready to make a push to migrate all my stuff to 64-bit, so this
means I need the ability to run either a 32-bit VM or a 64-bit VM, at
least for now. Unfortunately, it appears each uses the same the VM
file directory structure, and so whichever one is installed last
stomps out the other.

Eliot, you have unique names for VM versions, have you considered
inserting something to uniquefy the names to support co-existence of
32 and 64-bit of the same VM version? Or, does anyone have any best
practices to allow the co-existence of 32-bit with 64-bit VM?

I'm not talking about the problem with the names of the executables
(scripts) all being "squeak". I've already been renaming the shell
scripts from "squeak" to "cog" or "spur". Now the problem between 32
and 64-bit is the "lib" directory they refer to -- they share the
exact same name.

I still have a lot of 32-bit images around. Does anyone have any
pointers on how best to manage both a 32-bit and 64-bit?

Eliot Miranda-2

Re: managing the transition to 64-bit

Hi Chris,

On Dec 12, 2016, at 3:43 PM, Ben Coman <[hidden email]> wrote:

On Tue, Dec 13, 2016 at 3:34 AM, Chris Muller <[hidden email]> wrote:
I'm saying that the traditional way of installing a global VM, by installing under /usr/local, cannot support dual 32 and 64-bit installation because the directory name under "lib" is exactly the same for both platforms.

Installing from cog_linux32x86_squeak.cog.spur_201608171728.tar.gz:

/./products/cogspurlinuxht/lib/squeak/5.0-201608171728/squeak "32-bit"

and from cog_linux64x64_squeak.cog.spur_201608171728.tar.gz:

/./products/cogspur64linuxht/lib/squeak/5.0-201608171728/squeak "64-bit!"

copying from the highlighted, down, to the traditional /usr/local location makes that conflict.

I like any of the following:

/usr/local/squeak/{lib,lib64}/squeak/5.x-20yymmddhhmm/

/usr/local/squeak/{lib32,lib}/squeak/5.x-20yymmddhhmm/

/usr/local/squeak/{lib32,lib64}/squeak/5.x-20yymmddhhmm/

and then have /usr/local/squeak/squeak & /usr/local/squeak/bin/squeak determine which lib dir to use based on e.g. the od program, or possibly hexdump.

Does this make sense?

I want to run the same version of each VM, so there will be no question if disparity's arise during testing. I'd like to have access to a global "spur" (32-bit) and "spur64" commands. Any advice for this Linux user is appreciated, thx..

But since gong forward there is likely more 64-bit installs than 32 bit, perhaps that should be spur32 & spur (64-bit)?
cheers -ben

On Mon, Dec 12, 2016 at 12:55 PM, Levente Uzonyi <[hidden email]> wrote:
Do you mean that you want to make a single executable to run both 32-bit and 64-bit images?
If so, you can make a script which reads the image version from the header and runs it with the corresponding VM.
But I don't see why you would want to do that. :)

Levente

On Mon, 12 Dec 2016, Chris Muller wrote:

I'm ready to make a push to migrate all my stuff to 64-bit, so this
means I need the ability to run either a 32-bit VM or a 64-bit VM, at
least for now. Unfortunately, it appears each uses the same the VM
file directory structure, and so whichever one is installed last
stomps out the other.

Eliot, you have unique names for VM versions, have you considered
inserting something to uniquefy the names to support co-existence of
32 and 64-bit of the same VM version? Or, does anyone have any best
practices to allow the co-existence of 32-bit with 64-bit VM?

I'm not talking about the problem with the names of the executables
(scripts) all being "squeak". I've already been renaming the shell
scripts from "squeak" to "cog" or "spur". Now the problem between 32
and 64-bit is the "lib" directory they refer to -- they share the
exact same name.

I still have a lot of 32-bit images around. Does anyone have any
pointers on how best to manage both a 32-bit and 64-bit?

David T. Lewis

Re: managing the transition to 64-bit

In reply to this post by timrowledge

On Mon, Dec 12, 2016 at 11:07:13AM -0800, tim Rowledge wrote:
>
> > On 12-12-2016, at 10:55 AM, Levente Uzonyi <[hidden email]> wrote:
> >
> > Do you mean that you want to make a single executable to run both 32-bit and 64-bit images?
> > If so, you can make a script which reads the image version from the header and runs it with the corresponding VM.
>
> I???m pretty sure there is already a program (???ckformat' I think?) that reads the header and reports the type. It???s even used in the shell script for launching squeak, at least in the interpreterVM world.
>

An important point is that ckformat.c is intermediate source generated from
Smalltalk (ImageFormat class>> createCkFormatProgram in package ImageFormat
from the VMMaker repository).

The ckformat.c source code should be generated along with the VM sources, such
that the compiled ckformat program is always in sync with the latest version of
ImageFormat.

The compiled ckformat is then used to select an appropriate VM for the given image.

The latest version of ckformat knows about Spur 64 bit and Spur 32 bit, as well
as previous 32 and 64 bit V3 image formats. As new image formats are invented,
the ckformat program should be kept up to date through updates to ImageFormat
in the VMMaker repository.

The ImageFormat-Tests unit tests serve as additional documentation.

Dave