The result from:
cc -dM -E - </dev/null | grep -i arm
is shown below. There is only one non uppercase value:
#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__ 1
#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 4:17 PM Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Oct 28, 2020 at 4:06 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
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
Forgive me pushing, but can you also send the result of cc -dM -E - </dev/null | grep -i arm ? And the 64-bit ones are *way* faster and cheap...
Tim, what do you get for the same on raspbian?
#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@gmail.com wrote:
Hi Yoshiki,
On Wed, Oct 28, 2020 at 12:59 PM Yoshiki Ohshima < Yoshiki.Ohshima@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@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@gmail.com wrote:
Hi Yoshiki,
On Oct 28, 2020, at 8:34 AM, Yoshiki Ohshima Yoshiki.Ohshima@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@gmail.com> wrote:
> > > > On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima < > Yoshiki.Ohshima@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@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@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@acm.org> a écrit : >>>> >>>>> >>>>> I have a branch on a clone on github: >>>>> >>>>> >>>>> https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi... >>>>> >>>>> 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@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@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@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@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@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@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Yoshiki, >>>>>>>>>>> >>>>>>>>>>> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < >>>>>>>>>>> Yoshiki.Ohshima@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
-- _,,,^..^,,,_ best, Eliot