Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #135560

Re: Forth on ARM64

Show all headers | 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

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