[Vm-dev] nuSqueak source

Yoshiki Ohshima Yoshiki.Ohshima at acm.org
Wed Oct 28 23:05:50 UTC 2020


I may be simply on a wrong OS. The main reason for me to dive in again was
to fix it for Raspberry Pi OS users:

https://www.raspberrypi.org/downloads/raspberry-pi-os/

but then it simply is not a 64bit OS I gather. It's just the compiler on
targets 32 bit. Sorry for a confusion.  The following is the results from

cc -dM -E - </dev/null | grep ARM
#define __ARM_SIZEOF_WCHAR_T 4
#define __ARM_FEATURE_SAT 1
#define __ARM_ARCH_ISA_ARM 1
#define __ARMEL__ 1
#define __ARM_FEATURE_UNALIGNED 1
#define __ARM_FP 12
#define __ARM_SIZEOF_MINIMAL_ENUM 4
#define __ARM_PCS_VFP 1
#define __ARM_FEATURE_LDREX 4
#define __ARM_FEATURE_QBIT 1
#define __ARM_ARCH_6__ 1
#define __ARM_32BIT_STATE 1
#define __ARM_FEATURE_CLZ 1
#define __ARM_ARCH_ISA_THUMB 1
#define __ARM_ARCH 6
#define __ARM_FEATURE_SIMD32 1
#define __ARM_FEATURE_COPROC 15
#define __ARM_EABI__ 1
#define __ARM_FEATURE_DSP 1



On Wed, Oct 28, 2020 at 3:58 PM Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Yoshiki,
>
> On Wed, Oct 28, 2020 at 12:59 PM Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>
> wrote:
>
>>
>> As for linux64ARMv8, I had to hack like this (The below is somewhat
>> inconsistent but you'll get an idea) to get it produce a VM:
>>
>> It looks like an issue of  missing compiler macros for the architecture.
>> The hack to sqUnixHeartbeat.c  is likely to be wrong... the asm code
>> specified for __ARM_ARCHI_ISA_A64 does not  compile.
>>
>> -----------------------------------------------
>> diff --git a/platforms/Cross/vm/sqAtomicOps.h
>> b/platforms/Cross/vm/sqAtomicOps.h
>> index ff5d3fdd7..96abe3a22 100644
>> --- a/platforms/Cross/vm/sqAtomicOps.h
>> +++ b/platforms/Cross/vm/sqAtomicOps.h
>> @@ -203,7 +203,7 @@ AtomicGet(__int64 *target)
>>
>>  # else /* TARGET_OS_IS_IPHONE elif x86 variants etc */
>>
>> -#if defined(__arm__) && (defined(__ARM_ARCH_6__) ||
>> defined(__ARM_ARCH_7A__))
>> +#if defined(__arm__) && (defined(__ARM_ARCH_6__) ||
>> defined(__ARM_ARCH_7A__)) || 1
>>  /* tpr - this is code intended for the Raspberry Pi Raspbian OS
>>   * We'll experimentally trust in our MMU to keep 64bit accesses atomic */
>>  # define get64(variable) variable
>> diff --git a/platforms/unix/vm/sqUnixHeartbeat.c
>> b/platforms/unix/vm/sqUnixHeartbeat.c
>> index e9e3545fa..a526b4515 100644
>> --- a/platforms/unix/vm/sqUnixHeartbeat.c
>> +++ b/platforms/unix/vm/sqUnixHeartbeat.c
>> @@ -183,7 +183,7 @@ ioHighResClock(void)
>>   : "rdx");
>>  #elif defined(__ARM_ARCH_ISA_A64) || defined(__arm64__) ||
>> defined(__aarch64__) || defined(ARM64)
>>      __asm__ __volatile__ ("MRS  X0, CNTVCT_EL0");
>> -#elif defined(__arm__) && (defined(__ARM_ARCH_6__) ||
>> defined(__ARM_ARCH_7A__))
>> +#elif defined(__arm__) && (defined(__ARM_ARCH_6__) ||
>> defined(__ARM_ARCH_7A__)) || 1
>>   /* tpr - do nothing for now; needs input from eliot to decide further */
>>   /* Tim, not sure I have input beyond:
>>   Is there a 64-bit clock on ARM?  If so, access it here :-)
>> diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c
>> index d62b05f40..110685ac4 100644
>> --- a/spur64src/vm/cogit.c
>> +++ b/spur64src/vm/cogit.c
>> @@ -6,6 +6,8 @@
>>  # define SysV 1
>>  #endif
>>
>> +#define __arm64__ 1
>> +
>>  #if defined(__arm64__) || defined(__aarch64__) ||
>> defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
>>
>>  # include "cogitARMv8.c"
>> diff --git a/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c
>> b/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c
>> index 2878f9529..a0e5e0596 100644
>> --- a/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c
>> +++ b/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c
>> @@ -7,7 +7,7 @@
>>  # define ARM32FFIPlugin_exports SqueakFFIPrims_exports
>>  # include "ARM32FFIPlugin.c"
>>
>> -#elif defined(__ARM_ARCH_ISA_A64) || defined(__aarch64__) ||
>> defined(__arm64__) || defined(ARM64) || defined(_M_ARM64)
>> +#elif defined(__ARM_ARCH_ISA_A64) || defined(__aarch64__) ||
>> defined(__arm64__) || defined(ARM64) || defined(_M_ARM64) || 1
>>
>>  # define ARM64FFIPlugin_exports SqueakFFIPrims_exports
>>  # include "ARM64FFIPlugin.c"
>>
>
> If you do
>     $ cc -dM -E - </dev/null
> what predefined identifying macros do you get for aarch64/armv8?  Then I
> can add them to the set tested in cogit.c
>
>
>>
>> On Wed, Oct 28, 2020 at 9:24 AM Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>
>> wrote:
>>
>>> Ok!
>>>
>>> I did make a pull request but then merged it by myself.  Next thing for
>>> me to try is to build linux64ARMv8.
>>>
>>> On Wed, Oct 28, 2020 at 8:47 AM Eliot Miranda <eliot.miranda at gmail.com>
>>> wrote:
>>>
>>>>
>>>> Hi Yoshiki,
>>>>
>>>> On Oct 28, 2020, at 8:34 AM, Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>
>>>> wrote:
>>>>
>>>> 
>>>> Come to think of it, a better fix for a problem like this one:
>>>>
>>>>  KeySym symbolic;
>>>>  int keyCode= x2sqKey(&evt->xkey, &symbolic);
>>>>  int ucs4= xkeysym2ucs4(symbolic);
>>>>
>>>> was (obviously) to change the first line to:
>>>>
>>>>  KeySym symbolic= 0;
>>>>
>>>> rather than to try to store 0 into *symbolic on the callee side. (A
>>>> professor of my college days once told us that "most bugs are related to
>>>> uninitialized variables."  I should've known better.)
>>>>
>>>>
>>>> I had exactly this bug in the win32 CameraPlugin the other day.  And it
>>>> didn’t surface until shutting down the plugin on exiting the system.  C,
>>>> what a love/hate relationship it engenders :-)
>>>>
>>>> When I get  around to it, I'll make another change and this time make a
>>>> pull request.
>>>>
>>>>
>>>> Or if you’d like I could invite you to become a committer and then you
>>>> could avoid the pull request.
>>>>
>>>>
>>>>
>>>> On Tue, Oct 27, 2020 at 11:43 AM Eliot Miranda <eliot.miranda at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima <
>>>>> Yoshiki.Ohshima at acm.org> wrote:
>>>>>
>>>>>>
>>>>>> Thanks!  Maybe I should not have sent a separate email to Eliot ^^;
>>>>>>
>>>>>
>>>>> Don't sweat it :-)  Fixes gratefully received :-)  Thanks *very* much
>>>>> for attending to the input issue. Much appreciated.
>>>>>
>>>>>>
>>>>>> On Tue, Oct 27, 2020 at 10:46 AM Nicolas Cellier <
>>>>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> Ah too late, Eliot was faster, hit the pull request next time :)
>>>>>>>
>>>>>>> Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier <
>>>>>>> nicolas.cellier.aka.nice at gmail.com> a écrit :
>>>>>>>
>>>>>>>> Hi Yoshiki,
>>>>>>>> what you could do is
>>>>>>>> 1) revert the changes to sqPlatformSpecific.h (fseek, ftell) since
>>>>>>>> we have a working workaround now
>>>>>>>> 2) just create a pull request from the github web interface (that's
>>>>>>>> rather easy)
>>>>>>>> It will be very easy for us to integrate (one click), and we'll
>>>>>>>> keep your authorship.
>>>>>>>>
>>>>>>>> Le mar. 27 oct. 2020 à 18:02, Yoshiki Ohshima <
>>>>>>>> Yoshiki.Ohshima at acm.org> a écrit :
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have a branch on a clone on github:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fix-2020-Oct
>>>>>>>>>
>>>>>>>>> It might be easier to pull from this?  Separately, I'll mail you
>>>>>>>>> sqUnixX11.c.
>>>>>>>>>
>>>>>>>>> On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda <
>>>>>>>>> eliot.miranda at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Yoshiki,
>>>>>>>>>>
>>>>>>>>>>     on my Mac patch isn't smart enough to decode a git diff.  Can
>>>>>>>>>> you just email me your platforms/unix/vm-display-X11/sqUnixX11.c and I'll
>>>>>>>>>> integrate?  Thanks!
>>>>>>>>>>
>>>>>>>>>> On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima <
>>>>>>>>>> Yoshiki.Ohshima at acm.org> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The previous one was just a hack but I think I found the real
>>>>>>>>>>> problem. It was about the variable symbolic, that gets symbolic key code
>>>>>>>>>>> *when* it is needed has to be zero'ed  out when it is not needed.
>>>>>>>>>>>
>>>>>>>>>>> The diff is attached... I'll a make pull request if that helps.
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima <
>>>>>>>>>>> Yoshiki.Ohshima at acm.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> For the /build.linuxARMv6/squeak.cog.spur/build.debug  case, a
>>>>>>>>>>>> hack I did was like this:
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/platforms/unix/vm/sqPlatformSpecific.h
>>>>>>>>>>>> b/platforms/unix/vm/sqPlatformSpecific.h
>>>>>>>>>>>>
>>>>>>>>>>>> index 268593673..bfb57257b 100644
>>>>>>>>>>>>
>>>>>>>>>>>> --- a/platforms/unix/vm/sqPlatformSpecific.h
>>>>>>>>>>>>
>>>>>>>>>>>> +++ b/platforms/unix/vm/sqPlatformSpecific.h
>>>>>>>>>>>>
>>>>>>>>>>>> @@ -105,8 +105,8 @@ extern void sqFilenameFromString(char
>>>>>>>>>>>> *uxName, sqInt stNameIndex, int sqNameLeng
>>>>>>>>>>>>
>>>>>>>>>>>>  #undef sqFTruncate
>>>>>>>>>>>>
>>>>>>>>>>>>  /* sqFTruncate should return 0 on success, ftruncate does
>>>>>>>>>>>> also */
>>>>>>>>>>>>
>>>>>>>>>>>>  #define        sqFTruncate(f,o) ftruncate(fileno(f), o)
>>>>>>>>>>>>
>>>>>>>>>>>> -#define ftell(s) ftello(s)
>>>>>>>>>>>>
>>>>>>>>>>>> -#define fseek(s,o,w) fseeko(s,o,w)
>>>>>>>>>>>>
>>>>>>>>>>>> +// #define ftell(s) ftello(s)
>>>>>>>>>>>>
>>>>>>>>>>>> +// #define fseek(s,o,w) fseeko(s,o,w)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  #if defined(__GNUC__)
>>>>>>>>>>>>
>>>>>>>>>>>>  # if !defined(VM_LABEL)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c
>>>>>>>>>>>>
>>>>>>>>>>>> index d62b05f40..e1c14a021 100644
>>>>>>>>>>>>
>>>>>>>>>>>> --- a/spur64src/vm/cogit.c
>>>>>>>>>>>>
>>>>>>>>>>>> +++ b/spur64src/vm/cogit.c
>>>>>>>>>>>>
>>>>>>>>>>>> @@ -6,6 +6,8 @@
>>>>>>>>>>>>
>>>>>>>>>>>>  # define SysV 1
>>>>>>>>>>>>
>>>>>>>>>>>>  #endif
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> +#define __arm64__
>>>>>>>>>>>>
>>>>>>>>>>>> +
>>>>>>>>>>>>
>>>>>>>>>>>>  #if defined(__arm64__) || defined(__aarch64__) ||
>>>>>>>>>>>> defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> and this produced a runnable VM on Raspberry Pi4
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima <
>>>>>>>>>>>> Yoshiki.Ohshima at acm.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> And I tried a few more things by checking out the last release
>>>>>>>>>>>>> tag 202003021730 or try opensmalltalk-vm/build.
>>>>>>>>>>>>> linuxARMv6/squeak.cog.spur/build.debug but those attempts did
>>>>>>>>>>>>> not work. For the latter got this error:
>>>>>>>>>>>>>
>>>>>>>>>>>>> In file included from /usr/include/features.h:424,
>>>>>>>>>>>>>
>>>>>>>>>>>>>                  from /usr/include/pthread.h:21,
>>>>>>>>>>>>>
>>>>>>>>>>>>>                  from
>>>>>>>>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62,
>>>>>>>>>>>>>
>>>>>>>>>>>>>                  from
>>>>>>>>>>>>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
>>>>>>>>>>>>>
>>>>>>>>>>>>>                  from
>>>>>>>>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
>>>>>>>>>>>>>
>>>>>>>>>>>>> /usr/include/stdio.h:721:12: error: conflicting types for
>>>>>>>>>>>>> ‘fseeko’
>>>>>>>>>>>>>
>>>>>>>>>>>>>  extern int __REDIRECT (fseeko,
>>>>>>>>>>>>>
>>>>>>>>>>>>>             ^~~~~~~~~~
>>>>>>>>>>>>>
>>>>>>>>>>>>> In file included from
>>>>>>>>>>>>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
>>>>>>>>>>>>>
>>>>>>>>>>>>>                  from
>>>>>>>>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
>>>>>>>>>>>>>
>>>>>>>>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22:
>>>>>>>>>>>>> note: previous declaration \
>>>>>>>>>>>>>
>>>>>>>>>>>>> of ‘fseeko’ was here
>>>>>>>>>>>>>
>>>>>>>>>>>>>  #define fseek(s,o,w) fseeko(s,o,w)
>>>>>>>>>>>>>
>>>>>>>>>>>>>                       ^~~~~~
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima <
>>>>>>>>>>>>> Yoshiki.Ohshima at acm.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Eliot,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For build.linux64ARMv8/squeak.cog.spur/build.debug, i get
>>>>>>>>>>>>>> the following error. I think I followed the steps in the instructions,
>>>>>>>>>>>>>> including running updateSCCSVersion and mvm. How can I fix it?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error:
>>>>>>>>>>>>>> #error As yet no Cogit implementation appears to exist for your platform.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  # error As yet no Cogit implementation appears to exist for
>>>>>>>>>>>>>> your platform.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    ^~~~~
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error:
>>>>>>>>>>>>>> #error Consider implementing it, starting by adding a subclass of
>>>>>>>>>>>>>> CogAbstractInstruction.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  # error Consider implementing it, starting by adding a
>>>>>>>>>>>>>> subclass of CogAbstractInstruction.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    ^~~~~
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> make[1]: *** [Makefile:207: cogit.o]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda <
>>>>>>>>>>>>>> eliot.miranda at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Yoshiki,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima <
>>>>>>>>>>>>>>> Yoshiki.Ohshima at acm.org> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I heard that people got a new problem in inputting Japanese
>>>>>>>>>>>>>>>> text into Scratch 1.4 running on Raspberry Pi OS after, or around the
>>>>>>>>>>>>>>>> version 2020-08-20. I would like to take a look at it but it might involve
>>>>>>>>>>>>>>>> recompiling and generating  the VM with debugging info.  Last time I looked
>>>>>>>>>>>>>>>> into it was years and years ago and I need to basically make a fresh start.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is the process of making NuSqeauk VM For Raspberry Pi up to
>>>>>>>>>>>>>>>> date and straightforward? Can people point me to the right point to start?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Making a Cog VM for Raspberry pi is straight-forward.  Clone
>>>>>>>>>>>>>>> opensmalltalk-vm.  cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug,
>>>>>>>>>>>>>>> or build.linux64ARMv8/squeak.stack.spur/build.debug, then
>>>>>>>>>>>>>>> run ./mvm
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _,,,^..^,,,_
>>>>>>>>>>>>>>> best, Eliot
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> -- Yoshiki
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> -- Yoshiki
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> -- Yoshiki
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> -- Yoshiki
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> _,,,^..^,,,_
>>>>>>>>>> best, Eliot
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> -- Yoshiki
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> -- Yoshiki
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> _,,,^..^,,,_
>>>>> best, Eliot
>>>>>
>>>>
>>>>
>>>> --
>>>> -- Yoshiki
>>>>
>>>>
>>>
>>> --
>>> -- Yoshiki
>>>
>>>
>>
>> --
>> -- Yoshiki
>>
>>
>
> --
> _,,,^..^,,,_
> best, Eliot
>


-- 
-- Yoshiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20201028/a846aa4a/attachment-0001.html>


More information about the Vm-dev mailing list