On 03-05-2012 23:50, Casey Ransberger wrote:
> (snip)
>> It would be interesting to have a x86_64 version of Cog running in all
>> supported platforms (windowze, OS X, Linux, iOS, etc). i686 architecture
>> is not well supported in newer versions of many OSes, particularly
>> mixing i686 and x86_64 in Linux is kind of hell. Besides, it makes no
>> sense to have only the old 32bit image and it would be good to have a
>> 64bit one (addressing, etc) though it would demand changes in VMs. The
>> last 64bit image I was able to mine dates from 2010.
> It would; I think it's worth noting, though, that there's probably a pile of work underneath making it happen. There are also other considerations, like what you want out of a 64-bit Cog. Do you want a huge image or to add 64 bit integers as efficiently as possible? What's the goal?
>
> The goal will tell us things. Should we go back to a vtable or keep on keeping on with direct pointers?
>
> Etc...
For me, and I know it is really a particular plead:

a) Seamless integration with 64bit OS, particularly Linux, meaning among
other things seamless use of foreign libraries. Particularly in linux it
is a hell having to work simultaneously with 32bit and 64bit libraries.
And currently FFI does not makes any easier to transit between 32 and
64bit libraries.

b) Address space. Current images are limited to 4GBytes. For most
applications this is more than satisfactory but, again, in certain areas
it would be nice to be able to have a larger memory address space. Like:
image analysis with backbone written in smalltalk and specific vector
processing routines written in C/C++ CUDA (NVIDIA).

c) Current version of Cog allows limited threading. It is not a problem
inherent to x86_64 platform, but advancing in
multithreading/multiprocessing would be interesting (I'm extremely
curious about Jecel's work :) ).

d) Virtualization. Again, not something specific to x86_64
architectures. But using (somehow) OSProcess/CommandShell in order to
start foreign processes that start processes that manage execute
multiple versions of systems in virtual environments is quite limiting
(thinking about Seaside here...). Preparing squeak and its forks
(particularly pharo that is targeted to internet services) to cloud
processing is quite important.

(snip)

Best regards,

Casimiro Barreto

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120504/e1b22f8c/signature.pgp