On 4 May 2012 16:48, Casimiro de Almeida Barreto
<casimiro.barreto at gmail.com> wrote:
> 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).
>
yeah.. but note that larger memory size(s) means more work for GC.
we definitely should use different GC strategies for huge object memories.
If you look at original design of Squeak VM and object formats it was
primarily focused on conserving space
which is not an issue today even on portable devices.

working with huge object memories requires different approaches.

> 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 :) ).
>
i think multithreading is orthogonal to platform bit-ness. :)


> 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
>
>
>
>



-- 
Best regards,
Igor Stasenko.