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. |
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. > > > |
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]>:
|
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. >> > >> > >> > >> >> >> > |
...uintptr_t?
*ducks and covers* |
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:
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...
_,,,^..^,,,_ best, Eliot |
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 |
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 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) _,,,^..^,,,_ best, Eliot |
2016-07-07 20:20 GMT+02:00 Eliot Miranda <[hidden email]>:
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 |
> 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 |
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:
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) [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 |
2016-07-07 21:33 GMT+02:00 Eliot Miranda <[hidden email]>:
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 |
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 |
Hi David,
On Thu, Jul 7, 2016 at 4:43 PM, David T. Lewis <[hidden email]> wrote:
forgive me. I don't want a knock down fight, but I really do disagree. I'm sure you won't take this personally.
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 _,,,^..^,,,_ best, Eliot |
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 |
In reply to this post by Eliot Miranda-2
2016-07-09 0:53 GMT+02:00 Eliot Miranda <[hidden email]>:
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?
|
Free forum by Nabble | Edit this page |