nuSqueak source
Locked
 
|
Thanks! Maybe I should not have sent a separate email to Eliot ^^; On Tue, Oct 27, 2020 at 10:46 AM Nicolas Cellier <[hidden email]> wrote:
-- Yoshiki
|
|
|
On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima <[hidden email]> wrote:
Don't sweat it :-) Fixes gratefully received :-) Thanks *very* much for attending to the input issue. Much appreciated.
_,,,^..^,,,_ best, Eliot |
|
|
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.) When I get around to it, I'll make another change and this time make a pull request. On Tue, Oct 27, 2020 at 11:43 AM Eliot Miranda <[hidden email]> wrote:
-- Yoshiki
|
|
|
Hi Yoshiki, On Oct 28, 2020, at 8:34 AM, Yoshiki Ohshima <[hidden email]> 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 <[hidden email]> wrote:
-- Yoshiki
|
|
|
In reply to this post by Yoshiki Ohshima-3
> On 2020-10-28, at 8:34 AM, Yoshiki Ohshima <[hidden email]> wrote: > > (A professor of my college days once told us that "most bugs are related to uninitialized variables." I should've known better.) AKA - Constants aren't. Variables won't. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Oxymorons: Religious tolerance |
|
|
In reply to this post by Yoshiki Ohshima-3
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" On Wed, Oct 28, 2020 at 9:24 AM Yoshiki Ohshima <[hidden email]> wrote:
-- Yoshiki
|
|
|
Weird - I didn't have to change anything to get it to compile, but it won't run on Raspberry Pi OS 64 yet because of the write/execute address flimflammery that Eliot has had to mess with. > On 2020-10-28, at 12:59 PM, Yoshiki Ohshima <[hidden email]> 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" > > > On Wed, Oct 28, 2020 at 9:24 AM Yoshiki Ohshima <[hidden email]> 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 <[hidden email]> wrote: > > Hi Yoshiki, > >> On Oct 28, 2020, at 8:34 AM, Yoshiki Ohshima <[hidden email]> 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 <[hidden email]> wrote: >> >> >> >> On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima <[hidden email]> 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 <[hidden email]> wrote: >> >> Ah too late, Eliot was faster, hit the pull request next time :) >> >> Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >> >> Hi Yoshiki, >> >> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima <[hidden email]> 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 > tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful Latin Phrases:- Cave ne ante ullas catapultas ambules = If I were you, I wouldn't walk in front of any catapults. |
|
|
In reply to this post by Yoshiki Ohshima-3
> On 2020-10-28, at 9:24 AM, Yoshiki Ohshima <[hidden email]> wrote: > > Ok! > > I did make a pull request but then merged it by myself. Next thing for me to try is to build linux64ARMv8. Assuming you do get a working ARMv8 VM, you *should* find that loading NuScratch from SqueakMap works. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Cashtration (n.): The act of buying a house, which renders the subject financially impotent for an indefinite period. |
|
|
In reply to this post by Yoshiki Ohshima-3
Hi Yoshiki, On Wed, Oct 28, 2020 at 12:59 PM Yoshiki Ohshima <[hidden email]> wrote:
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
_,,,^..^,,,_ best, Eliot |
|
|
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: 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 <[hidden email]> wrote:
-- Yoshiki
|
|
|
On Wed, Oct 28, 2020 at 4:06 PM Yoshiki Ohshima <[hidden email]> wrote:
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?
_,,,^..^,,,_ best, Eliot |
|
|
In reply to this post by Yoshiki Ohshima-3
> On 2020-10-28, at 4:05 PM, Yoshiki Ohshima <[hidden email]> 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. Ah, you're making a mistake made by many. The Pi 4 (and indeed 3+, 3 and even the 2) have ARMv8 cpus. *BUT* Raspbian is a 32bit OS using the v7 support in the ARM A53 & A72 cores. A lot of people have posted questions asking if they have been sold a 'fake' Pi after seeing that the API for querying the processor type tells them they have a 32 bit v7. That is actually an upstream Debian issue not under the control of RPF at all. So the squeak vm supplied for the current default Raspbian (or rather, recently renamed, Raspberry Pi OS) is a 32 bit version as built in the opensmalltalk-vm ▸ build.linux32ARMv6 ▸ squeak.stack.spur tree. There *is* a 64 bit version of Raspberry PI OS that is currently in late-beta. That would need a VM from the opensmalltalk-vm ▸ build.linux32ARMv6 ▸ squeak.stack.spur tree and of course a 64 bit image. That VMworks on *some* OS but not others due to some issue with the permission bits for memory being messed around in the name of some sort of security waffle. Eliot has made it work for at least some cases - Manjaro, for example. It still needs sorting out for the Pi 64bit OS. As soon as you have a 32bit vm that handled the Japanese input stuff ok, let me know and I'll do a build and ask RPF to upload it. I don't know how many people still use it on any sort of regular basis but it certainly isn't 0, which is gratifying. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim On a clear disk you can seek forever... |
|
|
In reply to this post by Eliot Miranda-2
The result from: 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 <[hidden email]> wrote:
-- Yoshiki
|
|
|
In reply to this post by Eliot Miranda-2
> On 2020-10-28, at 4:17 PM, Eliot Miranda <[hidden email]> wrote: > > cc -dM -E - </dev/null | grep -i arm On a Pi 4 running the *32 bit default Raspbian* I get - #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 a Pi 4 running *64 bit Gentoo* I get - #define __ARM_SIZEOF_WCHAR_T 4 #define __ARM_FEATURE_IDIV 1 #define __ARM_FP 14 #define __ARM_SIZEOF_MINIMAL_ENUM 4 #define __ARM_FEATURE_FMA 1 #define __ARM_ALIGN_MAX_PWR 28 #define __ARM_FP16_FORMAT_IEEE 1 #define __ARM_FP16_ARGS 1 #define __ARM_FEATURE_CLZ 1 #define __ARM_64BIT_STATE 1 #define __ARM_ARCH_PROFILE 65 #define __ARM_PCS_AAPCS64 1 #define __ARM_ARCH 8 #define __ARM_FEATURE_UNALIGNED 1 #define __ARM_ARCH_8A 1 #define __ARM_NEON 1 #define __ARM_ALIGN_MAX_STACK_PWR 16 #define __ARM_FEATURE_NUMERIC_MAXMIN 1 #define __ARM_ARCH_ISA_A64 1 This same Gentoo reports mprotect(x,y,PROT_READ | PROT_EXEC): Permission denied when I try to run the 64 bit ARM VM. I could have sworn I had a uSD with Raspbian64 on it but it seems not. I'll make one and test on that again. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Has a one-way ticket on the Disoriented Express. |
|
|
> On 2020-10-28, at 4:34 PM, tim Rowledge <[hidden email]> wrote: > > I could have sworn I had a uSD with Raspbian64 on it but it seems not. I'll make one and test on that again. Loaded and updated at last - Pi 4 with 64 bit Raspberry Pi OS: #define __ARM_SIZEOF_WCHAR_T 4 #define __ARM_FEATURE_UNALIGNED 1 #define __ARM_FEATURE_IDIV 1 #define __ARM_FP 14 #define __ARM_ALIGN_MAX_STACK_PWR 16 #define __ARM_SIZEOF_MINIMAL_ENUM 4 #define __ARM_ALIGN_MAX_PWR 28 #define __ARM_FP16_FORMAT_IEEE 1 #define __ARM_FP16_ARGS 1 #define __ARM_FEATURE_FMA 1 #define __ARM_64BIT_STATE 1 #define __ARM_ARCH_PROFILE 65 #define __ARM_PCS_AAPCS64 1 #define __ARM_FEATURE_CLZ 1 #define __ARM_ARCH 8 #define __ARM_ARCH_8A 1 #define __ARM_NEON 1 #define __ARM_FEATURE_NUMERIC_MAXMIN 1 #define __ARM_ARCH_ISA_A64 1 tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Oxymorons: Religious tolerance |
|
|
In reply to this post by timrowledge
On 29/10/20 4:52 am, tim Rowledge wrote: > There*is* a 64 bit version of Raspberry PI OS that is currently in > late-beta. That would need a VM from the opensmalltalk-vm ▸ > build.linux32ARMv6 ▸ squeak.stack.spur tree and of course a 64 > bit image. Ubuntu released their 64-bit desktop versions for Raspberry Pi 4 just last week: https://ubuntu.com/raspberry-pi introduction and installation https://youtu.be/0pT4-RcTERU direct link http://cdimage.ubuntu.com/ubuntu/releases/20.10/release/ HTH .. Subbu |
|
|
Hi Yoshiki, Tim, Subbu, ARMv8 is cool; but Linux is a hydra. In getting the JIT to work with ARMv8 I went with the first full 64-bit ARMv8 platform I could access, Manjaro on Raspberry Pi 4. I now also have an Apple Silicon Mac Mini. The OS can impose radically different constraints on the JIT. In Mankato it is impossible to derive an executable region from mmap that is at the same time writable. On MacOS it is possible, but the VM needs a capability conveyed through its Info.plist and baked in when the app bundle is signed. Other linuxes for Pi4 May impose different constraints. As I only have these two variants I need your help in dealing with differing constraints on these other platforms. So what of these constraints? Manjaro’s prevents one from simply allocating the code zone as read+write+execute. So I have to allocate it read+execute and map it elsewhere in the address space as read+write and do all code zone modification (code generation, send-site editing/dynamic-linking/garbage-collection updating, compaction) through this second mapping. To enable that scheme the VM must be compiled with -DDUAL_MAPPED_CODE_ZONE=1. This is enabled in the mvm scripts in build.linux64ARMv8/squeak.cog.spur. I need to know if the dual mapping scheme is needed on other 64-bit distros. So can you take a look, try both variants and report back? The allocation of the code zone and it’s remapping is done via mmap calls in platforms/unix/vm/sqUnixSpurMemory.c. I have a small C test file that I used to experiment with copying a function into mmapped executable memory that I can post if you need to investigate why mmap might refuse to map write+execute and try and evade the restrictions it imposes. _,,,^..^,,,_ (phone) On Oct 29, 2020, at 3:29 AM, K K Subbu <[hidden email]> wrote:
|
|
|
In reply to this post by K K Subbu
> On 2020-10-29, at 3:29 AM, K K Subbu <[hidden email]> wrote: > > On 29/10/20 4:52 am, tim Rowledge wrote: >> There*is* a 64 bit version of Raspberry PI OS that is currently in >> late-beta. That would need a VM from the opensmalltalk-vm ▸ >> build.linux32ARMv6 ▸ squeak.stack.spur tree and of course a 64 >> bit image. > > Ubuntu released their 64-bit desktop versions for Raspberry Pi 4 just last week: Yeah, I saw that on the Pi forum. The bad news is that it includes that *appalling* UI, one that should never, ever, have seen the light of pixels. And unless there is some core OS difference it will presumably cause the same rtprio problem that the i7 version is causing... tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim A)bort, R)etry, I)nfluence with large hammer. |
|
|
In reply to this post by Eliot Miranda-2
On 29/10/20 9:01 pm, Eliot Miranda wrote: > The OS can impose radically different constraints on the JIT. In > Mankato it is impossible to derive an executable region from mmap that > is at the same time writable. On MacOS it is possible, but the VM needs > a capability conveyed through its Info.plist and baked in when the app > bundle is signed. doesn't PROT_EXEC imply PROT_READ? a region with write|exec would essentially be equivalent to an unprotected one. > Other linuxes for Pi4 May impose different constraints. As I only have > these two variants I need your help in dealing with differing > constraints on these other platforms. I don't have a RP 4 board to test the Ubuntu aarch64 (COVID-19 lockdown constraints). Sorry :-(. Regards .. Subbu |
| Free forum by Nabble | Edit this page |