Unix VM closure enabled?

 
Bert Freudenberg wrote: Hmm, the unix VM still fails to build properly on NetBSD 3.0 due to not
including rpath info (and thus crashing due to missing libraries at
runtime) and also it doesn't detect OSS sound properly.
Bugs I believe I reported back around VM version 1.3 or so...

 
On Fri, Jul 17, 2009 at 9:55 PM, Andreas Wacknitz<[hidden email]> wrote:
> I intend to create Solaris SPARC packages. Alas I have some problems with
> prerequisites at the moment. Libffi-3.0.8 has

Hi Andreas,

I have been building squeak on Solaris / SPARC for about 4 years now
for my own use.  I have a list of 8 patches that I've put together, as well
as a small script to apply them and run configure 'correctly'.

I agree with you about /opt; I use /opt/squeak as --prefix.

The main issue that I'm facing at the moment is that gcc-4.4.0 generates
code that causes unaligned accesses in fetchFloatAtinto; the same code
works in gcc-4.2.4 on SPARC.  Until I or someone else (hint!) fixes this,
I'm continuing to build with gcc-4.2.4.  But it does concern me that the VM
code shows bugs like this from time to time.  I suspect that some problems
remain hidden due to the fact that most users are using x86 (on whatever OS),
so alignment, long pointers, and endianness bugs are never encountered.

So building and testing the VM on a platform like SPARC  which enforces
alignment strictly, where pointers are/can be 64-bits, and which is big-endian,
will benefit the VM code.

Thanks for helping with this.
Andrew

 
On Sat, Jul 18, 2009 at 08:45:13AM +0200, Andreas Wacknitz wrote:
If you are trying to build a VM for any unix species other than what
you find on Ian's distribution page, then you should consider it an
absolute requirement to use VMMaker to generate the sources. The
files in platforms/unix/src will pretty much always be out of date,
as they are a snapshot of generated sources as of whenever Ian may
have last built a distribution.

It will take you a few hours of messing around with the VMMaker tool
to get used to it, but the investment will save you a lot of confusion
and wasted time.

Yes it is confusing to have a copy of the generated sources in the
platforms tree, but it seems to be important for Linux distribution
builders to have access to the C code, so I think it still needs to
be there despite the confusion.

Dave

 

Am 19.07.2009 um 16:40 schrieb David T. Lewis:
I have created a Solaris-10 SPARC package from Squeak-3.10-5 sources  
with minor patches
in the SocketPlugin for UNIX. This has no closure support yet and I  
expect FFI will not work because
of the actual state of the libffi that I used. It depends on the  
runtime libraries for gcc-4.3.2 from
Sun (SUNWgccfss432_runtime.tar.bz2 file downloadable from Sun).

The next step is to get some experiences with VMMaker and to create  
closure sources with it.
Some simple speed test results for my momentary SPARC machines (taken  
with Cuis):

" Blade 2500 (2*1,6GHz UltraSPARC-IIIi): "
0 tinyBenchmarks '97190584 bytecodes/sec; 4133412 sends/sec'

" Blade 2500 (2*1,28GHz UltraSPARC-IIIi): "
0 tinyBenchmarks '77015643 bytecodes/sec; 3275651 sends/sec'

" Blade 2000 (2*1,2GHz UltraSPARC-III)"
0 tinyBenchmarks '73101085 bytecodes/sec; 2990128 sends/sec'

" E250 (2*300MHz UltraSPARC-II):"
0 tinyBenchmarks '19643953 bytecodes/sec; 761256 sends/sec'


Regards
Andreas

 
On Saturday 18 Jul 2009 2:06:15 am Andreas Wacknitz wrote:
> /usr/local violates SysV specs. User compiled software should be  
> installed to /opt for SysV. /usr/local is only valid for BSD and Linux  
> systems.
This is true only if you are installing Squeak as a traditional Unix program.
/usr was reserved for network wide shared files and sys admins did not want
users modifying it. /opt was pretty much available to local host admins.

Squeak is quite well-behaved in that respect and can run pretty much from a
subtree located anywhere (e.g. $HOME), even on volumes mounted with noexec.
See Etoys-to-go for launcher scripts that override compiled paths. If you are
experimenting with different vms, this is a good option.

FYI .. Subbu

 
On Sat, Jul 18, 2009 at 05:25:48PM +0200, Andrew Gaylard wrote:
>  
> The main issue that I'm facing at the moment is that gcc-4.4.0 generates
> code that causes unaligned accesses in fetchFloatAtinto; the same code
> works in gcc-4.2.4 on SPARC.  Until I or someone else (hint!) fixes this,
> I'm continuing to build with gcc-4.2.4.

fetchFloatAtInto() is implemented in platforms/Cross/vm/sqMemoryAccess.h
in the form of cpp macros. It might be tricky to debug this, but I note
that the implementation depends on DOUBLE_WORD_ALIGNMENT, which is a macro
that would have been set when you run configure. You might playing with
this setting to see if it gives you the results you want. For example, as
a complete SWAG, it might be the case that SPARC plus gcc-4.2.4 needs this
macro defined but for some reason configure is not setting it for you.

In any case, it would be good if you could open a Mantis issue on this
so we don't forget about the issue.

> But it does concern me that the VM
> code shows bugs like this from time to time.  I suspect that some problems
> remain hidden due to the fact that most users are using x86 (on whatever OS),
> so alignment, long pointers, and endianness bugs are never encountered.

There are lots of bugs like this, and many of them are being flushed out
simply because x86_64 is becoming a very common platform these days. The
good news is that most bugs of this nature are quite obvious (usually a
vm crash), so we typically don't get intermittent symptoms.

> So building and testing the VM on a platform like SPARC  which enforces
> alignment strictly, where pointers are/can be 64-bits, and which is big-endian,
> will benefit the VM code.

Absolutely yes!

Dave

 
Here is a list of VM updates that I think would be reasonable to accomplish
over the next couple of months. This is based on known issues (Mantis) with
solutions that are either available now, or that can be completed without
significant additional work. Comments? Additions or changes?

Dave

1) Closure support.
 - Priority: High, should be done as soon as possible
 - All major VM distributions should support images with closure bytecodes.
 - Current status: All necessary support incorporated in VMMaker, no platforms
   changes needed.
 - Need Ian to do a build/release to cover Unix/Linux.

2) Changes to support Etoys and teaching for kids.
 - Priority: High, supports large educational programs.
 - Mantis 7266: SerialPlugin doesn't handle arbitrary nodes names
 - Mantis 7103: Playing sounds in linux 64 bits causes a vm segmentation fault
 - Current status: These require changes to VMMaker and platforms sources,
   all platforms effected. Changes are straightforward but must be done in a
   coordinated manner for all platforms.

3) Some simple updates for 23/64 bit platforms.
 - Priority: Low
 - Mantis 7236: Make AsynchFilePlugin work on 32/64 bit images and 32/64 bit unix VMs
 - Mantis 6828: make FileCopyPlugin work on 32/64 bit images and 32/64 bit unix VMs
 - Current status: These are minor updates, low priority but easy to do. Patches
   are available but must be coordinated for all platforms.

4) 64-bit FFI (Interpreter updates as well as FFI)
 - Priority: Medium
 - Mantis 7237: Make FFI work on 64 bit platforms
 - Current status: Patches are available, but additional work and testing may
   be required on some platforms. I consider this update important because it
   effects the interpreter as well as FFI itself, e.g. these changes are
   a prerequisite to closing out the issues in Mantis 6987: "signed32BitValueOf:,
   signed64BitValueOf: etc. broken".

 
Hi David,

 
On Mon, Jul 20, 2009 at 11:25:15AM -0700, Eliot Miranda wrote:
That's actually good timing with respect to some of the other things on
the list. End of summer corresponds to start of the school year in the
northern hemisphere, so we can target having all major VMs supporting the
closure bytecodes now, followed by an end-of-summer release that covers at
least item #2 two below. That would be the right time to also include whatever
things you may have ready to go in the August time frame.