[OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

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

[OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

Eliot Miranda-3
 
  Branch: refs/heads/Cog
  Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
  Commit: 08822ce610c20b61e1faec0ce72e635c8ad10e7c
      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/08822ce610c20b61e1faec0ce72e635c8ad10e7c
  Author: Nicolas Cellier <[hidden email]>
  Date:   2016-07-07 (Thu, 07 Jul 2016)

  Changed paths:
    M platforms/win32/vm/sqWin32Backtrace.c

  Log Message:
  -----------
  Revise valid macro for LLP64 case in sqWin32Backtrace.c

The code would have truncated fp bits because sizeof(long) > sizeof(fp) in LLP64
It would have worked because we only inspect least significant bits for alignment
But it's better to suppress suspicious compiler warning.
Thus use sqInt which is allways large enough to hold a pointer.


Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

David T. Lewis
 
sqInt is not always large enough to hold a pointer, in particular for the
common case of a 64-bit VM running a 32-bit object memory (yes I know
there is not currently such a configuration for Cog/Spur). It would be
good to avoid that assumption if possible.

Dave

>    Branch: refs/heads/Cog
>   Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
>   Commit: 08822ce610c20b61e1faec0ce72e635c8ad10e7c
>       https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/08822ce610c20b61e1faec0ce72e635c8ad10e7c
>   Author: Nicolas Cellier <[hidden email]>
>   Date:   2016-07-07 (Thu, 07 Jul 2016)
>
>   Changed paths:
>     M platforms/win32/vm/sqWin32Backtrace.c
>
>   Log Message:
>   -----------
>   Revise valid macro for LLP64 case in sqWin32Backtrace.c
>
> The code would have truncated fp bits because sizeof(long) > sizeof(fp) in
> LLP64
> It would have worked because we only inspect least significant bits for
> alignment
> But it's better to suppress suspicious compiler warning.
> Thus use sqInt which is allways large enough to hold a pointer.
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

Nicolas Cellier
 
OK, I did think of it, but effectively considered it was not maintained in COG.
If we really want to re-integrate this, what would be the right type to use?
We can't use long (might be too short), nor sqLong (might be too long).
Should we create a new type just for this case?

2016-07-07 18:03 GMT+02:00 David T. Lewis <[hidden email]>:

sqInt is not always large enough to hold a pointer, in particular for the
common case of a 64-bit VM running a 32-bit object memory (yes I know
there is not currently such a configuration for Cog/Spur). It would be
good to avoid that assumption if possible.

Dave

>    Branch: refs/heads/Cog
>   Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
>   Commit: 08822ce610c20b61e1faec0ce72e635c8ad10e7c
>       https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/08822ce610c20b61e1faec0ce72e635c8ad10e7c
>   Author: Nicolas Cellier <[hidden email]>
>   Date:   2016-07-07 (Thu, 07 Jul 2016)
>
>   Changed paths:
>     M platforms/win32/vm/sqWin32Backtrace.c
>
>   Log Message:
>   -----------
>   Revise valid macro for LLP64 case in sqWin32Backtrace.c
>
> The code would have truncated fp bits because sizeof(long) > sizeof(fp) in
> LLP64
> It would have worked because we only inspect least significant bits for
> alignment
> But it's better to suppress suspicious compiler warning.
> Thus use sqInt which is allways large enough to hold a pointer.
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

David T. Lewis
 
What type to declare? That's a very good question and I am not sure the
best answer. I do think it might make sense to come up with a type
declaration for a thing that may store either a sqInt value or a C pointer
value. There are quite a few cases where we need to deal with that problem
throughout the VM and plugins.

Dave


>  OK, I did think of it, but effectively considered it was not maintained
> in
> COG.
> If we really want to re-integrate this, what would be the right type to
> use?
> We can't use long (might be too short), nor sqLong (might be too long).
> Should we create a new type just for this case?
>
> 2016-07-07 18:03 GMT+02:00 David T. Lewis <[hidden email]>:
>
>>
>> sqInt is not always large enough to hold a pointer, in particular for
>> the
>> common case of a 64-bit VM running a 32-bit object memory (yes I know
>> there is not currently such a configuration for Cog/Spur). It would be
>> good to avoid that assumption if possible.
>>
>> Dave
>>
>> >    Branch: refs/heads/Cog
>> >   Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
>> >   Commit: 08822ce610c20b61e1faec0ce72e635c8ad10e7c
>> >
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/08822ce610c20b61e1faec0ce72e635c8ad10e7c
>> >   Author: Nicolas Cellier <[hidden email]>
>> >   Date:   2016-07-07 (Thu, 07 Jul 2016)
>> >
>> >   Changed paths:
>> >     M platforms/win32/vm/sqWin32Backtrace.c
>> >
>> >   Log Message:
>> >   -----------
>> >   Revise valid macro for LLP64 case in sqWin32Backtrace.c
>> >
>> > The code would have truncated fp bits because sizeof(long) >
>> sizeof(fp)
>> in
>> > LLP64
>> > It would have worked because we only inspect least significant bits
>> for
>> > alignment
>> > But it's better to suppress suspicious compiler warning.
>> > Thus use sqInt which is allways large enough to hold a pointer.
>> >
>> >
>> >
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

Henrik Sperre Johansen
...uintptr_t?

*ducks and covers*
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

Eliot Miranda-2
In reply to this post by David T. Lewis
 
Hi David,

On Thu, Jul 7, 2016 at 9:03 AM, David T. Lewis <[hidden email]> wrote:

sqInt is not always large enough to hold a pointer, in particular for the
common case of a 64-bit VM running a 32-bit object memory (yes I know
there is not currently such a configuration for Cog/Spur). It would be
good to avoid that assumption if possible.

I wonder what the benefit of trying to maintain the   64-bit VM running a 32-bit object memory configuration is, now that we have an efficient 64-bit on 64-bit configuration.  This is costly to maintain, and unless people really want to use it for me it feels like wasted effort.  I realise it's your baby, and that it may have meaning.  But it's also a hungry mouth to feed...


Dave

>    Branch: refs/heads/Cog
>   Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
>   Commit: 08822ce610c20b61e1faec0ce72e635c8ad10e7c
>       https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/08822ce610c20b61e1faec0ce72e635c8ad10e7c
>   Author: Nicolas Cellier <[hidden email]>
>   Date:   2016-07-07 (Thu, 07 Jul 2016)
>
>   Changed paths:
>     M platforms/win32/vm/sqWin32Backtrace.c
>
>   Log Message:
>   -----------
>   Revise valid macro for LLP64 case in sqWin32Backtrace.c
>
> The code would have truncated fp bits because sizeof(long) > sizeof(fp) in
> LLP64
> It would have worked because we only inspect least significant bits for
> alignment
> But it's better to suppress suspicious compiler warning.
> Thus use sqInt which is allways large enough to hold a pointer.
>
>
>





--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

Tobias Pape
In reply to this post by Henrik Sperre Johansen


On 07.07.2016, at 18:51, Henrik Sperre Johansen <[hidden email]> wrote:

> ...uintptr_t?
>
> *ducks and covers*


what he says

Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

Eliot Miranda-2
In reply to this post by Henrik Sperre Johansen
 
Hi Henrik,

On Thu, Jul 7, 2016 at 9:51 AM, Henrik Sperre Johansen <[hidden email]> wrote:

...uintptr_t?

*ducks and covers*

 uintptr_t implies four tasks:
- verifying uintptr_t is supported in the C compilation environments on (at least) the 5 standard platforms we have (and the FreeBSD folks would like to know too, and RiscOS).
- adding uintptr_t support in Slang's type inferrencer
- going through all the VMMaker methods that declare C types, identifying which type declarations should use uintptr_t and modifying them to do so
- going through all the platforms source for all functions that take pointer arguments (hundreds) and modifying them to use uintptr_t instead of long (the last default)

That's at least half a week's work.  Do you volunteer?

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

Nicolas Cellier
 


2016-07-07 20:20 GMT+02:00 Eliot Miranda <[hidden email]>:
 
Hi Henrik,

On Thu, Jul 7, 2016 at 9:51 AM, Henrik Sperre Johansen <[hidden email]> wrote:

...uintptr_t?

*ducks and covers*

 uintptr_t implies four tasks:
- verifying uintptr_t is supported in the C compilation environments on (at least) the 5 standard platforms we have (and the FreeBSD folks would like to know too, and RiscOS).
- adding uintptr_t support in Slang's type inferrencer
- going through all the VMMaker methods that declare C types, identifying which type declarations should use uintptr_t and modifying them to do so
- going through all the platforms source for all functions that take pointer arguments (hundreds) and modifying them to use uintptr_t instead of long (the last default)

That's at least half a week's work.  Do you volunteer?

_,,,^..^,,,_
best, Eliot


Hi Eliot,
what about using a squeak specific type, something like

#if SIZEOF_LONG == SIZEOF_VOID_P
typedef long sqInt_ptr;
typedef unsigned long usqInt_ptr;
#else
typedef long long sqInt_ptr;
typedef unsigned long long usqInt_ptr;
#endif

sounds simple enough
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

David T. Lewis
 

>  2016-07-07 20:20 GMT+02:00 Eliot Miranda <[hidden email]>:
>
>>
>> Hi Henrik,
>>
>> On Thu, Jul 7, 2016 at 9:51 AM, Henrik Sperre Johansen <
>> [hidden email]> wrote:
>>
>>>
>>> ...uintptr_t?
>>>
>>> *ducks and covers*
>>>
>>
>>  uintptr_t implies four tasks:
>> - verifying uintptr_t is supported in the C compilation environments on
>> (at least) the 5 standard platforms we have (and the FreeBSD folks would
>> like to know too, and RiscOS).
>> - adding uintptr_t support in Slang's type inferrencer
>> - going through all the VMMaker methods that declare C types,
>> identifying
>> which type declarations should use uintptr_t and modifying them to do so
>> - going through all the platforms source for all functions that take
>> pointer arguments (hundreds) and modifying them to use uintptr_t instead
>> of
>> long (the last default)
>>
>> That's at least half a week's work.  Do you volunteer?
>>
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
> Hi Eliot,
> what about using a squeak specific type, something like
>
> #if SIZEOF_LONG == SIZEOF_VOID_P
> typedef long sqInt_ptr;
> typedef unsigned long usqInt_ptr;
> #else
> typedef long long sqInt_ptr;
> typedef unsigned long long usqInt_ptr;
> #endif
>
> sounds simple enough
>

+1

That sounds like a good idea to me.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

Eliot Miranda-2
In reply to this post by Nicolas Cellier
 
Hi Henrik^H^H^H^H^H^H^HNicolas,

On Thu, Jul 7, 2016 at 12:16 PM, Nicolas Cellier <[hidden email]> wrote:
 


2016-07-07 20:20 GMT+02:00 Eliot Miranda <[hidden email]>:
 
Hi Henrik,

On Thu, Jul 7, 2016 at 9:51 AM, Henrik Sperre Johansen <[hidden email]> wrote:

...uintptr_t?

*ducks and covers*

 uintptr_t implies four tasks:
- verifying uintptr_t is supported in the C compilation environments on (at least) the 5 standard platforms we have (and the FreeBSD folks would like to know too, and RiscOS).
- adding uintptr_t support in Slang's type inferrencer
- going through all the VMMaker methods that declare C types, identifying which type declarations should use uintptr_t and modifying them to do so
- going through all the platforms source for all functions that take pointer arguments (hundreds) and modifying them to use uintptr_t instead of long (the last default)

That's at least half a week's work.  Do you volunteer?

_,,,^..^,,,_
best, Eliot


Hi Eliot,
what about using a squeak specific type, something like

#if SIZEOF_LONG == SIZEOF_VOID_P
typedef long sqInt_ptr;
typedef unsigned long usqInt_ptr;
#else
typedef long long sqInt_ptr;
typedef unsigned long long usqInt_ptr;
#endif

sounds simple enough

 sqInt_ptr implies three tasks:
- adding sqInt_ptr support in Slang's type inferrencer
- going through all the VMMaker methods that declare C types, identifying which type declarations should use sqInt_ptr and modifying them to do so
- going through all the platforms source for all functions that take pointer arguments (hundreds) and modifying them to use sqInt_ptr instead of long (the last default)

That's at least half a week's work.  Do you volunteer?

[In this case I have no objection.  I just don't want to do the work].

BTW, we don't need sqInt_ptr and usqInt_ptr.  One or other.  Sq sqptr_t or sqIntptr_t would be better choices.

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

Nicolas Cellier
 


2016-07-07 21:33 GMT+02:00 Eliot Miranda <[hidden email]>:
 
Hi Henrik^H^H^H^H^H^H^HNicolas,

On Thu, Jul 7, 2016 at 12:16 PM, Nicolas Cellier <[hidden email]> wrote:
 


2016-07-07 20:20 GMT+02:00 Eliot Miranda <[hidden email]>:
 
Hi Henrik,

On Thu, Jul 7, 2016 at 9:51 AM, Henrik Sperre Johansen <[hidden email]> wrote:

...uintptr_t?

*ducks and covers*

 uintptr_t implies four tasks:
- verifying uintptr_t is supported in the C compilation environments on (at least) the 5 standard platforms we have (and the FreeBSD folks would like to know too, and RiscOS).
- adding uintptr_t support in Slang's type inferrencer
- going through all the VMMaker methods that declare C types, identifying which type declarations should use uintptr_t and modifying them to do so
- going through all the platforms source for all functions that take pointer arguments (hundreds) and modifying them to use uintptr_t instead of long (the last default)

That's at least half a week's work.  Do you volunteer?

_,,,^..^,,,_
best, Eliot


Hi Eliot,
what about using a squeak specific type, something like

#if SIZEOF_LONG == SIZEOF_VOID_P
typedef long sqInt_ptr;
typedef unsigned long usqInt_ptr;
#else
typedef long long sqInt_ptr;
typedef unsigned long long usqInt_ptr;
#endif

sounds simple enough

 sqInt_ptr implies three tasks:
- adding sqInt_ptr support in Slang's type inferrencer
- going through all the VMMaker methods that declare C types, identifying which type declarations should use sqInt_ptr and modifying them to do so
- going through all the platforms source for all functions that take pointer arguments (hundreds) and modifying them to use sqInt_ptr instead of long (the last default)

That's at least half a week's work.  Do you volunteer?

[In this case I have no objection.  I just don't want to do the work].

BTW, we don't need sqInt_ptr and usqInt_ptr.  One or other.  Sq sqptr_t or sqIntptr_t would be better choices.

_,,,^..^,,,_
best, Eliot


Hi Eliot
agree on sqIntptr_t, the closest we are from the standard the better.
As I see it, this type will be primarily used in platforms/win32 to replace thing like (int)hInstance.
At this stage no need to make any change in VMMaker, so it's completely transparent.
Later we'll need to review usage of long in VMMaker in order to support LLP64.
But it will not necessarily be replaced with sqIntptr_t.
Either sqInt or sqLong in the oscog branch would do in most cases.

I let 32bits image on 64bits VM apart, currently the VMMaker branches are not compatible.
That's mostly this special case that requires introduction of sqIntptr_t in VMMaker.
I don't plan to invest time into it.
However if we can preserve some degree of compatibility in platforms source for a moderate cost, let's not spoil this possibility.

Nicolas
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

David T. Lewis
In reply to this post by Eliot Miranda-2
 
On Thu, Jul 07, 2016 at 11:14:20AM -0700, Eliot Miranda wrote:

>  
> Hi David,
>
> On Thu, Jul 7, 2016 at 9:03 AM, David T. Lewis <[hidden email]> wrote:
>
> >
> > sqInt is not always large enough to hold a pointer, in particular for the
> > common case of a 64-bit VM running a 32-bit object memory (yes I know
> > there is not currently such a configuration for Cog/Spur). It would be
> > good to avoid that assumption if possible.
> >
>
> I wonder what the benefit of trying to maintain the   64-bit VM running a
> 32-bit object memory configuration is, now that we have an efficient 64-bit
> on 64-bit configuration.  This is costly to maintain, and unless people
> really want to use it for me it feels like wasted effort.  I realise it's
> your baby, and that it may have meaning.  But it's also a hungry mouth to
> feed...
>

Hi Eliot,

Regarding the type declarations, it is a lot easier to put effort into
doing it right the first time, rather than trying to fix it later. It is
also easier to find and fix problems in that area if you are working in
a mixed environment with 64-bit pointers and 32-bit sqInt. So yes there
is value in maintaining that configuration.

Kudos to Nicolas for taking the time to think the issue through and get
the declarations right. It is the right thing to do, and it will save a
good deal of pain for other people in the years to come :-)

Dave

Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

Eliot Miranda-2
 
Hi David,

On Thu, Jul 7, 2016 at 4:43 PM, David T. Lewis <[hidden email]> wrote:

On Thu, Jul 07, 2016 at 11:14:20AM -0700, Eliot Miranda wrote:
>
> Hi David,
>
> On Thu, Jul 7, 2016 at 9:03 AM, David T. Lewis <[hidden email]> wrote:
>
> >
> > sqInt is not always large enough to hold a pointer, in particular for the
> > common case of a 64-bit VM running a 32-bit object memory (yes I know
> > there is not currently such a configuration for Cog/Spur). It would be
> > good to avoid that assumption if possible.
> >
>
> I wonder what the benefit of trying to maintain the   64-bit VM running a
> 32-bit object memory configuration is, now that we have an efficient 64-bit
> on 64-bit configuration.  This is costly to maintain, and unless people
> really want to use it for me it feels like wasted effort.  I realise it's
> your baby, and that it may have meaning.  But it's also a hungry mouth to
> feed...
>

Hi Eliot,

forgive me.  I don't want a knock down fight, but I really do disagree.  I'm sure you won't take this personally.
 

Regarding the type declarations, it is a lot easier to put effort into
doing it right the first time, rather than trying to fix it later. It is
also easier to find and fix problems in that area if you are working in
a mixed environment with 64-bit pointers and 32-bit sqInt. So yes there
is value in maintaining that configuration.

There is no practical benefit to a 64-bit pop upon 32-bit address space configuration.  Because...
- 64 bits are used in every oop yet only a 32-bit address space can be accessed, so the excess bits don't increase address space, but actually reduce it since pure pointer objects are twice as large
- every access must fetch two words, use two registers, etc, etc
So this configuration only provides overhead.  It does not provide additional functionality; and given 64-bit machines are common these days, it does not provide any useful testing.

So I reiterate, IMO this is pure overhead.

In contrast, a 32-bit oop over 64-bit address space configuration can provide considerable benefits:
- access to 64-bit instructions and 64-bit registers for efficient streaming computation
- more compact images/footprint for small machines (Pi)

So please, can we knock the 64-bit pop in 32-bit address space configuration on the head and bury it quietly?  Who's going to miss it?  Seriously.


Kudos to Nicolas for taking the time to think the issue through and get
the declarations right. It is the right thing to do, and it will save a
good deal of pain for other people in the years to come :-)

Dave




--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

David T. Lewis
 
On Fri, Jul 08, 2016 at 03:53:38PM -0700, Eliot Miranda wrote:

>  
> Hi David,
>
> On Thu, Jul 7, 2016 at 4:43 PM, David T. Lewis <[hidden email]> wrote:
>
> >
> > On Thu, Jul 07, 2016 at 11:14:20AM -0700, Eliot Miranda wrote:
> > >
> > > Hi David,
> > >
> > > On Thu, Jul 7, 2016 at 9:03 AM, David T. Lewis <[hidden email]>
> > wrote:
> > >
> > > >
> > > > sqInt is not always large enough to hold a pointer, in particular for
> > the
> > > > common case of a 64-bit VM running a 32-bit object memory (yes I know
> > > > there is not currently such a configuration for Cog/Spur). It would be
> > > > good to avoid that assumption if possible.
> > > >
> > >
> > > I wonder what the benefit of trying to maintain the   64-bit VM running a
> > > 32-bit object memory configuration is, now that we have an efficient
> > 64-bit
> > > on 64-bit configuration.  This is costly to maintain, and unless people
> > > really want to use it for me it feels like wasted effort.  I realise it's
> > > your baby, and that it may have meaning.  But it's also a hungry mouth to
> > > feed...
> > >
> >
> > Hi Eliot,
> >
>
> forgive me.  I don't want a knock down fight, but I really do disagree.
> I'm sure you won't take this personally.
>

Hi Eliot,

I don't agree, aside from your point about not wanting to argue about it.

Dave


>
> >
> > Regarding the type declarations, it is a lot easier to put effort into
> > doing it right the first time, rather than trying to fix it later. It is
> > also easier to find and fix problems in that area if you are working in
> > a mixed environment with 64-bit pointers and 32-bit sqInt. So yes there
> > is value in maintaining that configuration.
> >
>
> There is no practical benefit to a 64-bit pop upon 32-bit address space
> configuration.  Because...
> - 64 bits are used in every oop yet only a 32-bit address space can be
> accessed, so the excess bits don't increase address space, but actually
> reduce it since pure pointer objects are twice as large
> - every access must fetch two words, use two registers, etc, etc
> So this configuration only provides overhead.  It does not provide
> additional functionality; and given 64-bit machines are common these days,
> it does not provide any useful testing.
>
> So I reiterate, IMO this is pure overhead.
>
> In contrast, a 32-bit oop over 64-bit address space configuration can
> provide considerable benefits:
> - access to 64-bit instructions and 64-bit registers for efficient
> streaming computation
> - more compact images/footprint for small machines (Pi)
>
> So please, can we knock the 64-bit pop in 32-bit address space
> configuration on the head and bury it quietly?  Who's going to miss it?
> Seriously.
>
>
> Kudos to Nicolas for taking the time to think the issue through and get
> > the declarations right. It is the right thing to do, and it will save a
> > good deal of pain for other people in the years to come :-)
> >
> > Dave
> >
> >
>
>
> --
> _,,,^..^,,,_
> best, Eliot

Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 08822c: Revise valid macro for LLP64 case in sqWin32Backtr...

Nicolas Cellier
In reply to this post by Eliot Miranda-2
 


2016-07-09 0:53 GMT+02:00 Eliot Miranda <[hidden email]>:
 
Hi David,

On Thu, Jul 7, 2016 at 4:43 PM, David T. Lewis <[hidden email]> wrote:

On Thu, Jul 07, 2016 at 11:14:20AM -0700, Eliot Miranda wrote:
>
> Hi David,
>
> On Thu, Jul 7, 2016 at 9:03 AM, David T. Lewis <[hidden email]> wrote:
>
> >
> > sqInt is not always large enough to hold a pointer, in particular for the
> > common case of a 64-bit VM running a 32-bit object memory (yes I know
> > there is not currently such a configuration for Cog/Spur). It would be
> > good to avoid that assumption if possible.
> >
>
> I wonder what the benefit of trying to maintain the   64-bit VM running a
> 32-bit object memory configuration is, now that we have an efficient 64-bit
> on 64-bit configuration.  This is costly to maintain, and unless people
> really want to use it for me it feels like wasted effort.  I realise it's
> your baby, and that it may have meaning.  But it's also a hungry mouth to
> feed...
>

Hi Eliot,

forgive me.  I don't want a knock down fight, but I really do disagree.  I'm sure you won't take this personally.
 

Regarding the type declarations, it is a lot easier to put effort into
doing it right the first time, rather than trying to fix it later. It is
also easier to find and fix problems in that area if you are working in
a mixed environment with 64-bit pointers and 32-bit sqInt. So yes there
is value in maintaining that configuration.

There is no practical benefit to a 64-bit pop upon 32-bit address space configuration.  Because...
- 64 bits are used in every oop yet only a 32-bit address space can be accessed, so the excess bits don't increase address space, but actually reduce it since pure pointer objects are twice as large
- every access must fetch two words, use two registers, etc, etc
So this configuration only provides overhead.  It does not provide additional functionality; and given 64-bit machines are common these days, it does not provide any useful testing.

So I reiterate, IMO this is pure overhead.

In contrast, a 32-bit oop over 64-bit address space configuration can provide considerable benefits:
- access to 64-bit instructions and 64-bit registers for efficient streaming computation
- more compact images/footprint for small machines (Pi)

So please, can we knock the 64-bit pop in 32-bit address space configuration on the head and bury it quietly?  Who's going to miss it?  Seriously.


Hi Eliot,
I think we're focusing on most interesting case:

32bit-oop (sizeof(sqInt)==BytesPerOop that is ==4) on 64bits address space (sizeof(void *)=BytesPerWord that is ==8).
Because of LLP64 and windows x64 support, we cannot rely on long as a universal uintptr_t, nor on sqInt that is too short in this case.
Note that 'm mixing the two features (LLP64 & 32bits image on 64bits VM) voluntarily otherwise we would do the job twice.

For windows, we are forced to introduce the sqIntptr_t anyway and use it in the plugins that exchange pointer with image, and a few places in the VM. That means that we must use (u)sqIntptr_t in positiveMachineInteger and signedMachineInteger.
For 32 bits image on 64bits VM, we must distinguish again BytesPerOop for sqInt from BytesPerWord for sqIntptr_t in CCodeGenerator (for infering int type length, int type harmonization, etc...)

I've started the job in a VMMaker branch VMMaker.oscogintptr-nice.1900 at http://smalltalkhub.com/mc/nice/NiceVMExperiments/main and I'm testing if no regression on mac 32/64.

I don't think we have to care too much of 64bits image on 32bits pointer indeed, but I don't think that we are putting much effort in it, do we?

 
Kudos to Nicolas for taking the time to think the issue through and get
the declarations right. It is the right thing to do, and it will save a
good deal of pain for other people in the years to come :-)

Dave




--
_,,,^..^,,,_
best, Eliot