[Vm-dev] 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 <eliot.miranda at gmail.com>:

>
> Hi Henrik^H^H^H^H^H^H^HNicolas,
>
> On Thu, Jul 7, 2016 at 12:16 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>>
>>
>>
>> 2016-07-07 20:20 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>>
>>>
>>> Hi Henrik,
>>>
>>> On Thu, Jul 7, 2016 at 9:51 AM, Henrik Sperre Johansen <
>>> henrik.s.johansen at veloxit.no> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160707/eee69278/attachment.htm