[Vm-dev] Re: [Poll] Who is interested in, thinking about, or already contributing to a 64-bit OpenSmalltalk VM for Windows?

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Jul 13 14:43:34 UTC 2016


2016-07-13 14:32 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:

>
> Hi Nicolas,
>
>
> On Jul 12, 2016, at 11:33 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>
>
> 2016-07-12 23:23 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>
>>
>> Hi Marcel,
>>
>>
>> > On Jul 12, 2016, at 12:24 PM, marcel.taeumel <Marcel.Taeumel at hpi.de>
>> wrote:
>> >
>> >
>> > Hi Nicolas,
>> >
>> > I suppose there are several places in some low-level parts of Cog/Jit
>> where
>> > Long and Pointer-Type are used interchangeably. One would have to fix
>> that
>> > first. Only then, we can start caring for interfacing the win-api
>> correctly.
>>
>> That's right.  Throughout the Cogit is the assumption that sizeof(long)
>> == sizeof(sqInt) == sizeof(void *).  That's why I'm hoping we can use a C
>> compiler which obeys this for win64.  It is nontrivial to fix, as I've
>> already discussed.  Did my words fall on deaf ears and you're proposing to
>> go ahead?
>>
>>
> Hi Eliot,
>
> for sizeof(long) != sizeof(void *) that's not a big problem from what i
> see in VMMaker (unless I'm also blind)
> there are not so many usage of long/unsigned long
>
>
> It means that sizeof(long) is undefined in Spur 64-bit, as it may be
> either 4 or 8 bytes in size.  So we have to either eliminate it or
> post-process it to emit it as eg long64 and have #defines to map it to
> int64 on win64 and long everywhere else.
>
> Right. Solution is to replace with usqIntptr_t

The most annoying case is printf... See
http://stackoverflow.com/questions/1255099/whats-the-proper-use-of-printf-to-display-pointers-padded-with-0s
Complete madness. If we support pre C99, that means going through our own
macros...


> If we keep it, it is a source of confusion that must be documented and
> learned.  If we eliminate it, its absence is a source of confusion that
> must be documented and learned.
>
> We must keep it only for case when an external function uses an (unsigned)
long prototype.
Otherwise, we could raise a Warning/Error in type inferencer, harmonizer,
etc...
That would document it properly.


> I had hoped we could avoid outright butchery :-(
>
> Let's call it surgery :)


> longAt() answers a sqInt so it's OK.
> I've published VMMaker.oscogLLP64-nice.1901 on
> http://smalltalkhub.com/mc/nice/NiceVMExperiments/main and the list of
> changes is rather short.
> Maybe I forgot some places though, it needs consolidation.
>
> for sizeof(sqInt) != sizeof(void *) that's really more difficult.
> There are assumptions that objectMemory == machineMemory and avoidance of
> oopForPointer() pointerForOop() macros spreaded across Cog/Spur as I
> understand it.
> But we ain't gonna need it until we try to run 32bits image on 64bits VM.
>
>
> >
>> > Best,
>> > Marcel
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://forum.world.st/Poll-Who-is-interested-in-thinking-about-or-already-contributing-to-a-64-bit-OpenSmalltalk-VM-for-Wi-tp4904953p4906337.html
>> > Sent from the Squeak VM mailing list archive at Nabble.com
>> <http://nabble.com>.
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160713/1fccb7d6/attachment.htm


More information about the Vm-dev mailing list