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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
 
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".


M7103-platforms.tgz (39K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

johnmci

Ok, next week I'm somewhat on vacation but was planning to review the 64bit changes I have.  
Some of which are sound related.

I would also like to push the iphone/64 bit work into the squeakvm svn. I'll need to restructure the
isqueak svn a bit first to take it back to the original vmmaker tree structure and to "obsolete" the
older macintosh VM files into a subdirectory.


On 2009-12-29, at 11:09 AM, David T. Lewis wrote:

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

--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================




Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
In reply to this post by David T. Lewis
 
I have committed the 64-bit SoundPlugin updates to SqS/VMMaker.

Ian, John, Andreas: please proceed with platforms updates at your convenience
(see below for details).

As a point of reference:

- Platforms sources in Subversion are currently at revision 2147.

- VMMaker version 3.11.11 (VMMaker-dtl.155) works with SVN 2147.

- The updated VMMaker is 3.11.12 (VMMaker-dtl.156). This will be out
of sync with the SVN sources until the sound plugin platforms patches
are applied.

Note to other VM builders: If you have compile errors building SoundPlugin,
use VMMaker-dtl.155 or earlier until the necessary patches have been
applied. See Mantis 7103 for background.

Thanks,
Dave

On Tue, Dec 29, 2009 at 02:09:11PM -0500, David T. Lewis wrote:

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


Reply | Threaded
Open this post in threaded view
|

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

Bert Freudenberg
 
On 12.01.2010, at 00:20, David T. Lewis wrote:
>
>
> I have committed the 64-bit SoundPlugin updates to SqS/VMMaker.

Awesome!

- Bert -


Reply | Threaded
Open this post in threaded view
|

other 64bit changes, header files, and smalltalk

johnmci
In reply to this post by David T. Lewis
 
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
===========================================================================




changesToVMDEVFOLKS.zip (255K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: other 64bit changes, header files, and smalltalk

Igor Stasenko

2010/1/12 John M McIntosh <[hidden email]>:

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

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.
While platform specific code could always coerce this type to own

squeakFileOffsetType offset = (squeakFileOffsetType) vmOffset;


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


--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: other 64bit changes, header files, and smalltalk

Andreas.Raab
 
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.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: other 64bit changes, header files, and smalltalk

Igor Stasenko

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.
Afaik __int64 is platform/compiler specific.

> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: other 64bit changes, header files, and smalltalk

Andreas.Raab
 
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

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: other 64bit changes, header files, and smalltalk

Igor Stasenko

2010/1/12 Andreas Raab <[hidden email]>:

>
> 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
>
Oh, well, then how about

typedef struct {
   long hi;
   long lo;
} squeakFileOffsetType;

let me restate what i intend to achieve:
  i just want to make interp.c to be independent from
compiler-specific idiosyncrasies , and from platform-specific types.



> Cheers,
>  - Andreas
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: other 64bit changes, header files, and smalltalk

Andreas.Raab
 
Igor Stasenko wrote:

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

Could do, but that's not the same as a native 64 bit int on little
endian machines so all code using squeakFileOffsetType needs to be
rewritten to use struct accessors. Not sure if that's worth it.

> let me restate what i intend to achieve:
>   i just want to make interp.c to be independent from
> compiler-specific idiosyncrasies , and from platform-specific types.

I'm not sure what purpose this serves. The compiler will fail instantly
for an absent definition of squeakFileOffsetType so it's not that
there's any doubt about what you need to do if you port to a new
platform. Let's be pragmatic here - as much as I agree that having
compiler specific stuff in there isn't the best choice, there are some
situations where the alternative is needlessly complex. This seems to be
one of those.

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: other 64bit changes, header files, and smalltalk

Eliot Miranda-2
In reply to this post by Andreas.Raab
 


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


Reply | Threaded
Open this post in threaded view
|

Re: other 64bit changes, header files, and smalltalk

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


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




Reply | Threaded
Open this post in threaded view
|

Re: other 64bit changes, header files, and smalltalk

Eliot Miranda-2
 


On Tue, Jan 12, 2010 at 11:52 AM, John M McIntosh <[hidden email]> 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.

OK, but in any case IMO the usqLong/sqLong defines belong alongside the sqInt/usqInt ones.
 


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






Reply | Threaded
Open this post in threaded view
|

Re: other 64bit changes, header files, and smalltalk

Igor Stasenko
In reply to this post by johnmci

2010/1/12 John M McIntosh <[hidden email]>:
>
> 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.
>

Right , and that's why i feel this type usage in
readImageFromFileHeapSizeStartingAt()
awfully wrong.

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



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: other 64bit changes, header files, and smalltalk

Andreas.Raab
In reply to this post by johnmci
 
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
> ===========================================================================
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: other 64bit changes, header files, and smalltalk

Igor Stasenko

2010/1/12 Andreas Raab <[hidden email]>:

>
> 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).
>
Exactly what i want :)

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



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: other 64bit changes, header files, and smalltalk

David T. Lewis
 
On Tue, Jan 12, 2010 at 10:41:30PM +0200, Igor Stasenko wrote:

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

Sounds right to me as well.