[VM-team] SoundPlugin updates for 64-bit (Mantis 7103)

> Updates to the platforms code and VMMaker are needed to make SoundPlugin
> work on 64-bit platforms. This is a coordinated change affecting all platforms.
>
> I'm not sure of folks' schedules right now, so Ian, John, Andreas - are you
> available to do the updates over say the next two weeks or so?
>
> The following steps are required:
>
> Dave:
> - Update SoundPlugin in VMMaker with patches from Mantis 7103.
>
> Ian:
> - Update platforms/Cross and platforms/unix. The diffs on Mantis 7103
>   are slightly out of date, so I am attaching a fresh copy of the affected
>   files (M7103-platforms.tgz).
>   These are:
>       platforms/Cross/plugins/SoundPlugin/SoundPlugin.h
>       platforms/unix/plugins/SoundPlugin/sqUnixSound.c
>       platforms/unix/vm/SqSound.h
>       platforms/unix/vm-sound-ALSA/sqUnixSoundALSA.c
>       platforms/unix/vm-sound-NAS/sqUnixSoundNAS.c
>       platforms/unix/vm-sound-Sun/sqUnixSoundSun.c
>       platforms/unix/vm-sound-MacOSX/sqUnixSoundMacOSX.c
>       platforms/unix/vm-sound-null/sqUnixSoundNull.c
>       platforms/unix/vm-sound-OSS/sqUnixSoundOSS.c
>
> Andreas:
> - Update platforms/win32/plugins/SoundPlugin/sqWin32Sound.c to match
>   the new declarations in SoundPlugin.h. I believe this will involve only
>   changing various int declarations to the appropriate sqInt or (void *)
>   declarations, then testing to make sure sound still works. However, I
>   have not tried a windows build to verify this.
>
> John:
> - Update the files in platforms/Mac OS/plugins/SoundPlugin/ with declarations
>   to match SoundPlugin.h in Cross. I'm not sure what needs to be done here,
>   although I think that current OS X support is based on the unix SoundPlugin,
>   so you may be able to use the update in platforms/unix.
> - I'm not sure of the implications (if any) for your new VM work or for iPhone.
>

>  
> Updates to the platforms code and VMMaker are needed to make SoundPlugin
> work on 64-bit platforms. This is a coordinated change affecting all platforms.
>
> I'm not sure of folks' schedules right now, so Ian, John, Andreas - are you
> available to do the updates over say the next two weeks or so?
>
> The following steps are required:
>
> Dave:
>  - Update SoundPlugin in VMMaker with patches from Mantis 7103.
>
> Ian:
>  - Update platforms/Cross and platforms/unix. The diffs on Mantis 7103
>    are slightly out of date, so I am attaching a fresh copy of the affected
>    files (M7103-platforms.tgz).
>    These are:
>        platforms/Cross/plugins/SoundPlugin/SoundPlugin.h
>        platforms/unix/plugins/SoundPlugin/sqUnixSound.c
>        platforms/unix/vm/SqSound.h
>        platforms/unix/vm-sound-ALSA/sqUnixSoundALSA.c
>        platforms/unix/vm-sound-NAS/sqUnixSoundNAS.c
>        platforms/unix/vm-sound-Sun/sqUnixSoundSun.c
>        platforms/unix/vm-sound-MacOSX/sqUnixSoundMacOSX.c
>        platforms/unix/vm-sound-null/sqUnixSoundNull.c
>        platforms/unix/vm-sound-OSS/sqUnixSoundOSS.c
>
> Andreas:
>  - Update platforms/win32/plugins/SoundPlugin/sqWin32Sound.c to match
>    the new declarations in SoundPlugin.h. I believe this will involve only
>    changing various int declarations to the appropriate sqInt or (void *)
>    declarations, then testing to make sure sound still works. However, I
>    have not tried a windows build to verify this.
>  
> John:
>  - Update the files in platforms/Mac OS/plugins/SoundPlugin/ with declarations
>    to match SoundPlugin.h in Cross. I'm not sure what needs to be done here,
>    although I think that current OS X support is based on the unix SoundPlugin,
>    so you may be able to use the update in platforms/unix.
>  - I'm not sure of the implications (if any) for your new VM work or for iPhone.
>
>
> Dave
>
> --- background ---
>
> For reference this was the suggested "to-do" list that I posted a while back.
> These updates will complete step #2 on the list. Note, with John's recent
> 64-bit work and new VM development, we will no doubt have a few new
> items to add to the list :)
>
> 1) Closure support (COMPLETE)
>  - Priority: High, should be done as soon as possible
>  - All major VM distributions should support images with closure bytecodes.
>  
> 2) Changes to support Etoys and teaching for kids.
>  - Priority: High, supports large educational programs.
>  - Mantis 7266: SerialPlugin doesn't handle arbitrary nodes names (COMPLETE)
>  - Mantis 7103: Playing sounds in linux 64 bits causes a vm segmentation fault
>    (subject of this note - NEXT UP on the list)
>  
> 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".
>

>
> Attached is a zip file of the header changes to common I've made in the last three months,
> plus some fixes for VMMaker.
>
> If people could poke at them and discuss, that would be helpful.
>
> My other notes say:
> REPlugin is broken
> Squeak3D is broken
> RePlugin is broken
>
> sqInt readImageFromFileHeapSizeStartingAt(sqImageFile  f, sqInt desiredHeapSize, squeakFileOffsetType  imageOffset);
> should be
> sqInt readImageFromFileHeapSizeStartingAt(sqImageFile  f, usqInt desiredHeapSize, squeakFileOffsetType  imageOffset);
>

> EXPORT(sqInt) dumpImage(sqInt fileName);
> should be
> EXPORT(sqInt) dumpImage(char * fileName);
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>

>
> Igor Stasenko wrote:
>>
>> Btw,  about that function. Its using a squeakFileOffsetType, which is
>> platform specific, and i had hard times
>> trying to deal with right header inclusion order imposing dependency
>> of interpreter from platform code, which, IMO should be avoided.
>> I propose to change it to
>> typedef  unsigned long long vmFileOffsetType;
>> and use this type instead.
>
> I'm not sure if MSVC supports long long nowadays. It didn't used to - it
> used to require __int64 which is why the definition of squeakFileOffsetType
> is external.
>

>  
> 2010/1/12 Andreas Raab <[hidden email]>:
>> Igor Stasenko wrote:
>>> Btw,  about that function. Its using a squeakFileOffsetType, which is
>>> platform specific, and i had hard times
>>> trying to deal with right header inclusion order imposing dependency
>>> of interpreter from platform code, which, IMO should be avoided.
>>> I propose to change it to
>>> typedef  unsigned long long vmFileOffsetType;
>>> and use this type instead.
>> I'm not sure if MSVC supports long long nowadays. It didn't used to - it
>> used to require __int64 which is why the definition of squeakFileOffsetType
>> is external.
>>
>
> There should be an ANSI long long integer type.

>
> Igor Stasenko wrote:
>>
>>  2010/1/12 Andreas Raab <[hidden email]>:
>>>
>>> Igor Stasenko wrote:
>>>>
>>>> Btw,  about that function. Its using a squeakFileOffsetType, which is
>>>> platform specific, and i had hard times
>>>> trying to deal with right header inclusion order imposing dependency
>>>> of interpreter from platform code, which, IMO should be avoided.
>>>> I propose to change it to
>>>> typedef  unsigned long long vmFileOffsetType;
>>>> and use this type instead.
>>>
>>> I'm not sure if MSVC supports long long nowadays. It didn't used to - it
>>> used to require __int64 which is why the definition of
>>> squeakFileOffsetType
>>> is external.
>>>
>>
>> There should be an ANSI long long integer type.
>
> There's a C99 long long type (does MSVC implement C99?) but for example no
> C++ long long type. See also:
>
> http://bytes.com/topic/c/answers/63790-__int64-vs-long-long
>
> I'd strongly suggest leaving this in a way that allows for external
> redefinition. You could have something that says:
>
> #ifndef LONGLONG_NOT_SUPPORTED
> typedef long long squeakFileOffsetType
> #endif
>

>> I'd strongly suggest leaving this in a way that allows for external
>> redefinition. You could have something that says:
>>
>> #ifndef LONGLONG_NOT_SUPPORTED
>> typedef long long squeakFileOffsetType
>> #endif
>>
> Oh, well, then how about
>
> typedef struct {
>    long hi;
>    long lo;
> } squeakFileOffsetType;

> On 2010-01-12, at 11:42 AM, Eliot Miranda wrote:
>
>
> On Tue, Jan 12, 2010 at 7:54 AM, Andreas Raab <[hidden email]> wrote:
>>
>> Igor Stasenko wrote:
>>>
>>> Btw,  about that function. Its using a squeakFileOffsetType, which is
>>> platform specific, and i had hard times
>>> trying to deal with right header inclusion order imposing dependency
>>> of interpreter from platform code, which, IMO should be avoided.
>>> I propose to change it to
>>> typedef  unsigned long long vmFileOffsetType;
>>> and use this type instead.
>>
>> I'm not sure if MSVC supports long long nowadays. It didn't used to - it used to require __int64 which is why the definition of squeakFileOffsetType is external.
>
> We should just use usqLong.  The platform-specific definition in platforms/Cross/vm/sqVirtualMachine.h can be moved to sqMemoryAccess.h so that usqLong & sqLong are also available once sqInt & usqInt are.
>
>>
>> Cheers,
>>  - Andreas
>>
>
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>

>
>
> On 2010-01-12, at 11:42 AM, Eliot Miranda wrote:
>
>>
>>
>> On Tue, Jan 12, 2010 at 7:54 AM, Andreas Raab <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>
>>     Igor Stasenko wrote:
>>
>>         Btw,  about that function. Its using a squeakFileOffsetType,
>>         which is
>>         platform specific, and i had hard times
>>         trying to deal with right header inclusion order imposing
>>         dependency
>>         of interpreter from platform code, which, IMO should be avoided.
>>         I propose to change it to
>>         typedef  unsigned long long vmFileOffsetType;
>>         and use this type instead.
>>
>>
>>     I'm not sure if MSVC supports long long nowadays. It didn't used
>>     to - it used to require __int64 which is why the definition of
>>     squeakFileOffsetType is external.
>>
>>
>> We should just use usqLong.  The platform-specific definition in
>> platforms/Cross/vm/sqVirtualMachine.h can be moved to sqMemoryAccess.h
>> so that usqLong & sqLong are also available once sqInt & usqInt are.
>>
>>  
>>
>>
>>     Cheers,
>>      - Andreas
>>
>>
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]
> <mailto:[hidden email]>>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>

>
> John M McIntosh wrote:
>>
>> Mmm no, the history of the squeakFileOffsetType was originally for the use
>> of file system 64bit points back when 64bit support Windows was a footnote
>> in some Microsoft engineers diary.  It was first introduced on the mac
>> version of the VM with other variations following years? later.
>> Technically it is a platform specific entity since not all file systems
>> support 64bit values, so it's improper to consider for other usages outside
>> the file system support plugins.
>
> That may be true but these platforms can still return 64 bit values (and
> fail if the request is larger than 32 bit). I think Eliot's suggestion is a
> good one: Make all file operations take 64 bit, leave it to the vm
> implementors to deal with the consequences, and alias squeakFileOffsetType
> to usqLong (or get rid of it).
>

> Cheers,
>  - Andreas
>
>>
>>
>> On 2010-01-12, at 11:42 AM, Eliot Miranda wrote:
>>
>>>
>>>
>>> On Tue, Jan 12, 2010 at 7:54 AM, Andreas Raab <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>
>>>    Igor Stasenko wrote:
>>>
>>>        Btw,  about that function. Its using a squeakFileOffsetType,
>>>        which is
>>>        platform specific, and i had hard times
>>>        trying to deal with right header inclusion order imposing
>>>        dependency
>>>        of interpreter from platform code, which, IMO should be avoided.
>>>        I propose to change it to
>>>        typedef  unsigned long long vmFileOffsetType;
>>>        and use this type instead.
>>>
>>>
>>>    I'm not sure if MSVC supports long long nowadays. It didn't used
>>>    to - it used to require __int64 which is why the definition of
>>>    squeakFileOffsetType is external.
>>>
>>>
>>> We should just use usqLong.  The platform-specific definition in
>>> platforms/Cross/vm/sqVirtualMachine.h can be moved to sqMemoryAccess.h so
>>> that usqLong & sqLong are also available once sqInt & usqInt are.
>>>
>>>
>>>
>>>    Cheers,
>>>     - Andreas
>>>
>>>
>>
>> --
>>
>> ===========================================================================
>> John M. McIntosh <[hidden email]
>> <mailto:[hidden email]>>   Twitter:  squeaker68882
>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>
>> ===========================================================================
>>
>>
>>
>>
>

>
> 2010/1/12 Andreas Raab <[hidden email]>:
> >
> > That may be true but these platforms can still return 64 bit values (and
> > fail if the request is larger than 32 bit). I think Eliot's suggestion is a
> > good one: Make all file operations take 64 bit, leave it to the vm
> > implementors to deal with the consequences, and alias squeakFileOffsetType
> > to usqLong (or get rid of it).
> >
> Exactly what i want :)