Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #135560
| Path | csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail |
|---|---|
| From | peter <peter.noreply@tin.it> |
| Newsgroups | comp.lang.forth |
| Subject | Re: Forth on ARM64 |
| Date | Fri, 4 Sep 2026 23:51:29 +0200 |
| Organization | A noiseless patient Spider |
| Lines | 106 |
| Message-ID | <20260904235129.000057b0@tin.it> (permalink) |
| References | <117cmk0$1st8p$1@paganini.bofh.team> <20260904073311.00003526@tin.it> <nnd$3b980ba8$57c49a3b@950882b8bd21bd72> <117fcl7$26t23$1@paganini.bofh.team> |
| MIME-Version | 1.0 |
| Content-Type | text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding | quoted-printable |
| Injection-Date | Fri, 04 Sep 2026 21:51:31 +0000 (UTC) |
| Injection-Info | dont-email.me; logging-data="863177"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX190FG/rclbF1nUavWcWg7IFxzB+K2uuHKs="; posting-host="38b1f3ab950c9c31586e4c52c336de43" |
| Cancel-Lock | sha1:XrdOv01IRLRTudZpTAAwJbbAfxM= sha256:RkuB1/+49q5M0KWgHMlCF9VoFrhMCtlIO1DxR+3/TOk= sha1:u0CIZCx4btqATrio3g3ZmKn7f3Q= sha256:QUi61HnyLfh+SMnX4MvQTM/MJM2jeC+MGW/1fFGBn/k= |
| X-Newsreader | Claws Mail 4.4.0 (GTK 3.24.51; x86_64-w64-mingw32) |
| Xref | csiph.com comp.lang.forth:135560 |
Show key headers only | View raw
On Fri, 4 Sep 2026 21:19:37 -0000 (UTC) antispam@fricas.org (Waldek Hebisch) wrote: > albert@spenarnc.xs4all.nl wrote: > > In article <20260904073311.00003526@tin.it>, > > peter <peter.noreply@tin.it> wrote: > >>On Thu, 3 Sep 2026 20:51:14 -0000 (UTC) > >>antispam@fricas.org (Waldek Hebisch) wrote: > >> > >>> Under Linux on ARM64 trying to set machine stack pointer to > >>> value which is not divisible by 16 leads to error. AFAICS this > >>> means that in default setting machine stack pointer is not > >>> usable as as Forth user stack pointer or return stack pointer. > >>> I wonder what Forth implementation do? Do they use different > >>> registers as user and return stack pointer? Maybe they use > >>> machine stack pointer for control and locals? Or maybe some > >>> system magic removes the restriction? > >>> > >> > >>Here is the register assignments for the token VM I wrote for > >>ARM64 for lxf 64 > >> > >>/* > >>VM8 assembler based aarch64 vm for lxf64 Forth > >>Copyright 2020 Peter Fälth > >> > >>Register usage > >> X19 ip vm instruction pointer > >> x20 TOP top of stack cached in x20 > >> x21 sp vm stack pointer > >> x22 rp vm return stack pointer > >> x23 fp vm floating point stack pointer > >> x24 lp vm local stack pointer > >> x25 idx loop index of innermost loop > >> x26 limit loop limit of innermost loop > >> x27 address of jump table > >> d8 FTOP top of float stack cached in d8 > >> > >>sequence to nest to next opcode is RELOAD > >> > >> ldrb w0, [x19], 1 load opcode byte at ip, advance ip by 1 > >> ldr x2, [x27, x0, lsl 3] load address of machine code from jmptable+opcode*8 > >> br x2 jump to next machine code > >> > >>*/ > >> > >>There are just 2 calls in the hole VM, in these cases 2 registers are > >>pushed to maintain 16 byte alignment. > >> > >>You can avoid the 16 byte alignment by using a register other then sp > >>for the processor stack. My tests showed this code to be about 30% slower > >>in execution speed. > > > > The problem you have is unrelated to linux, but more a c-compatibility. > > > > With my assembler Forth I have no problem in linux. > > All system calls are done via SVC and filling registers X0, X1 X2 X3 X4 etc. > > The stack pointer SP plays no role in the whole Forth, it is arbitrarily > > mapped to R13. I could map SPO to x21 equally well. > > I wrote "machine stack pointer" (or if you prefer register number 31) > because it is special on ARM64. Of course, Forth can use a different > register, but not using machine stack pointer is a waste. C > compatibility makes this waste more painful, because there are > only 11 registers not touched by C. For traditional Forth > implementations this is enough, but I am looking at generating > machine code. > I will also in the future make a code generator for ARM64. I have one for X64 now! my idea is to use stp x29, x30, [sp, -16]! and ldp x29, x30, [sp], 16 at the start and end of words that has call in them >r r> r@ can be done with stp xzr, x20, [sp, -16]! and ldp xzr, x20, [sp], 16 This keeps everything aligned at 16 bytes I will use all registers for my code generator. To handle C library compatibility I will have a gate that all C calls pass that saves needed registers. This is how I handle it on X64 now. It works great. X64 also has a requirement of 16 byte alignment of the return stack. This is not enforced by the CPU, but it can bite you for specific opcodes that require 16 byte alignment. It is worse as Windows and Linux have different opinions on when the stack should be aligned, before or after the call? I handle that now by not aligning in code I generate and instead switch to a properly aligned stack at the call gate. BR Peter
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Forth on ARM64 antispam@fricas.org (Waldek Hebisch) - 2026-09-03 20:51 +0000
Re: Forth on ARM64 peter <peter.noreply@tin.it> - 2026-09-04 07:33 +0200
Re: Forth on ARM64 albert@spenarnc.xs4all.nl - 2026-09-04 10:21 +0200
Re: Forth on ARM64 antispam@fricas.org (Waldek Hebisch) - 2026-09-04 21:19 +0000
Re: Forth on ARM64 peter <peter.noreply@tin.it> - 2026-09-04 23:51 +0200
Re: Forth on ARM64 albert@spenarnc.xs4all.nl - 2026-09-05 13:11 +0200
Re: Forth on ARM64 Paul Rubin <no.email@nospam.invalid> - 2026-09-05 15:49 -0700
Re: Forth on ARM64 antispam@fricas.org (Waldek Hebisch) - 2026-09-05 23:39 +0000
Re: Forth on ARM64 antispam@fricas.org (Waldek Hebisch) - 2026-09-04 22:25 +0000
Re: Forth on ARM64 peter <peter.noreply@tin.it> - 2026-09-05 09:54 +0200
csiph-web