Gforth on M1 macOS

[Branimir Maksimovic]

Works.

I'll write some in it :P
let's make Forth propaganda :p
5 dup swap over rot . . . 5 5 5 ok
Perfect!
thanks, Anton.
--
7-77-777
\|/
---
/|\
--
Evil Sinner!

[Anton Ertl]

Branimir Maksimovic <branimir....@gmail.com> writes:
>
>Works.

Good. Which version? I recommend a recent snapshot on Aarch64 for
performance.

Could you run

gforth-fast onebench.fs

and post (or send me) the output?

>thanks, Anton.

My pleasure, but I am not the only one working on Gforth.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

[Branimir Maksimovic]

On 2021-09-23, Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> Branimir Maksimovic <branimir....@gmail.com> writes:
>>
>>Works.
>
> Good. Which version? I recommend a recent snapshot on Aarch64 for
> performance.
>

bmaxa@Branimirs-Air ~ % gforth -v
gforth 0.7.3

I'll try, but I don't need perf, just good program.
I'll plan to port some of my code to show how good
Forth is :P

tried to compile:
gcc -pthread engine-noll.o engine2-noll.o main-noll.o io.o signals.o support-noll.o arm-cacheflush0.o exp10.o sincos.o dblsub.o -ldl -lm libmain.o -o gforth-noll
true gforth-noll
cd engine && /Library/Developer/CommandLineTools/usr/bin/make DOSTRIP=true gforth-ditc-noll OPT=-noll OPTDEFINES= OPTOBJECTS=dblsub.o
make[4]: `gforth-ditc-noll' is up to date.
cp -p engine/gforth-ditc-noll gforth-ditc
true gforth-ditc
true
HOSTPREFIX="" GFORTHD="./gforth-ditc -p .:~+:." GFORTH="./gforth-ditc --die-on-signal --debug-mcheck -p .:~+:. -i kernl64l.fi exboot.fs startup.fs arch/arm/asm.fs arch/arm/disasm.fs" includedir=`pwd`/include extrastuff=' -I'`pwd`/include/gforth/0.7.9_20210916/arm bindir=`pwd` libccdir=`pwd`/lib/gforth/0.7.9_20210916/arm/libcc-named ./gforthmi gforth.fi --die-on-signal -p ".:~+:." -i kernl64l.fi exboot.fs startup.fs arch/arm/asm.fs arch/arm/disasm.fs


Segmentation fault: 11.


Segmentation fault: 11.


Segmentation fault: 11.
make[3]: *** [gforth.fi] Error 1
make[2]: *** [gforth-noll] Error 2
make[2]: *** Deleting file `gforth-noll'
make[1]: *** [optgforth] Error 2
make: *** [gforth] Error 2

> Could you run
>
> gforth-fast onebench.fs
>
> and post (or send me) the output?

bmaxa@Branimirs-Air projects % gforth-fast ./onebench.fs
sieve bubble matrix fib fft
0.244 0.244 0.176 0.276
in file included from *OS command line*:-1
onebench.fs:40: No such file or directory
>>>run-bench<<<
Backtrace:
$124813E98 throw
$124842378 included
$0
$E9DBE
$124842710 include-main-time

>
>>thanks, Anton.
>
> My pleasure, but I am not the only one working on Gforth.
>

kudos to all!
> - anton

Branimir.

[Branimir Maksimovic]

This is what I get by running 7.3 in gforth dir:
bmaxa@Branimirs-Air gforth % gforth-fast onebench.fs

sieve bubble matrix fib fft

0.357 0.399 0.290 0.452

in file included from *OS command line*:-1

in file included from onebench.fs:40
in file included from fft-bench.fs:3
in file included from fft.fs:23
complex.fs:43: Undefined word
: z+! ( z zaddr -- ) dup >r float+ >>>f+!<<< r> f+! ;
Backtrace:
$14F808A20 throw
$14F81EC40 no.extensions
$14F80C358 compiler-notfound1

so, I should try my best git version works.
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://git.savannah.gnu.org/gforth.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master

--
7-77-777
\|/
---
/|\

[Anton Ertl]

Branimir Maksimovic <branimir....@gmail.com> writes:
>On 2021-09-23, Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>HOSTPREFIX="" GFORTHD="./gforth-ditc -p .:~+:." GFORTH="./gforth-ditc --die-on-signal --debug-mcheck -p .:~+:. -i kernl64l.fi exboot.fs startup.fs arch/arm/asm.fs arch/arm/disasm.fs" includedir=`pwd`/include extrastuff=' -I'`pwd`/include/gforth/0.7.9_20210916/arm bindir=`pwd` libccdir=`pwd`/lib/gforth/0.7.9_20210916/arm/libcc-named ./gforthmi gforth.fi --die-on-signal -p ".:~+:." -i kernl64l.fi exboot.fs startup.fs arch/arm/asm.fs arch/arm/disasm.fs
>
>
>Segmentation fault: 11.
>
>
>Segmentation fault: 11.
>
>
>Segmentation fault: 11.

So the built gforth-ditc does not work. We will have to investigate
this.

>bmaxa@Branimirs-Air projects % gforth-fast ./onebench.fs
> sieve bubble matrix fib fft
> 0.244 0.244 0.176 0.276

Thanks.

[Klapaucius Klapaucius]

How does gforth assemble new machine code at runtime ?

I'm not a FORTH expert, barely a neophyte. However, while trying to port a jonesforth variant for the heck of it, I did notice that Apple seems to disallow having pages with rwx permissions. You either can write to a page, or you can execute it, but not both.

Executing machine code created at runtime raises segfaults/gives bus errors.

For a FORTH that assembles code into a common segment, that poses a real quandary. I don't know how to separate the 'already written and immutable' and 'modifiable'/'new' parts of the code in FORTH - it's seems antithetical to FORTH's philosophy, if there is such a thing.

See:
[1] https://stackoverflow.com/questions/74132150/forth-implementation-with-jit-write-protection
[2] https://stackoverflow.com/questions/74124485/mmap-rwx-page-on-macos-arm64-architecture

Maybe you are seeing the same thing. If gforth has figured this out, I'd be super happy to learn how.

[Anton Ertl]

Klapaucius Klapaucius <klapa...@gmail.com> writes:
>How does gforth assemble new machine code at runtime ?
>

>I'm not a FORTH expert, barely a neophyte. However, while trying to port a =
>jonesforth variant for the heck of it, I did notice that Apple seems to dis=

>allow having pages with rwx permissions.

Yes, my (unfinished) attempts at porting Gforth to MacOS on ARM64
revealed that to me.

>Maybe you are seeing the same thing. If gforth has figured this out, I'd be=

> super happy to learn how.

For now Gforth does not work on MacOS on ARM64. My plan is to disable
native code generation and fall back to threaded code (so Gforth on
MacOS will be slower than Gforth on Linux on the same hardware). If I
was much more motivated, I would try to map the same memory twice,
once RW and once RX, and use one mapping for writing and one for
executing. I don't know if that works on MacOS on ARM64, though.
Another alternative is to change the page(s) you want to write to RW
before writing and back to RX afterwards, using mprotect(); note that
the code that is executed between these two mprotect()s has to be
executable all the time.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html

New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

[Ron AARON]

On 20/10/2022 10:08, Anton Ertl wrote:
> Klapaucius Klapaucius <klapa...@gmail.com> writes:
>> How does gforth assemble new machine code at runtime ?
>>
>> I'm not a FORTH expert, barely a neophyte. However, while trying to port a =
>> jonesforth variant for the heck of it, I did notice that Apple seems to dis=
>> allow having pages with rwx permissions.
>
> Yes, my (unfinished) attempts at porting Gforth to MacOS on ARM64
> revealed that to me.
>
>> Maybe you are seeing the same thing. If gforth has figured this out, I'd be=
>> super happy to learn how.
>
> For now Gforth does not work on MacOS on ARM64. My plan is to disable
> native code generation and fall back to threaded code (so Gforth on
> MacOS will be slower than Gforth on Linux on the same hardware). If I
> was much more motivated, I would try to map the same memory twice,
> once RW and once RX, and use one mapping for writing and one for
> executing. I don't know if that works on MacOS on ARM64, though.
> Another alternative is to change the page(s) you want to write to RW
> before writing and back to RX afterwards, using mprotect(); note that
> the code that is executed between these two mprotect()s has to be
> executable all the time.
>
> - anton

8th's M1 port uses "pthread_jit_write_protect_np()" as appropriate
before and after writing native code.

[Ron AARON]

And, I almost forgot:

void __clear_cache(void *start, void *end)
{
sys_icache_invalidate(start, (char *)end-(char *)start);
}

[minf...@arcor.de]

Yep. See for instance:
https://developer.apple.com/documentation/apple-silicon/porting-just-in-time-compilers-to-apple-silicon

[none albert]

In article <48865615-4d33-400a...@googlegroups.com>,

jonesforth is loosely based on ciforth.
https://github.com/albertvanderhorst/ciforth
A guy name Spykerman has figured this out a long time ago for me
long ago for the Apple.

ciforth comes in a number of thoroughly tested versions under which
xina for the apple.
See ciforth.html on my site below.
The exercise to convert a ciforth to a jonesforth is trivial.
I don't like this much.
- ciforth is as simple as jonesforth
- ciforth is solid ISO94
- ciforth is carefully designed to allow extensions that
you can, but need not, use.
(fp, multitasking,decorators, scripting, native executables,
32/64 bit assembler, you name it.)

I have made a competing pedagogical effort to jonesforth:
https://github.com/albertvanderhorst/yourforth
that has at least no gratitious deviations from ISO94.
Throwing out doubles, the <# # #S #> has to be redefined as
<% % %S %> .

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Klapaucius Klapaucius]

I don't think that's enough. For a traditional java JIT etc, the code that generates the new code lives in a separate space, presumably. This is possible because the jit compiler itself is immutable.

In FORTH, the compiler itself can be and often is (re)written at runtime, in the same segments non-compiler stuff is.

I believe one would have to somehow separate out the 'compiler' code from 'non-compiler' code - then you could at least create native non-compiler code your way.

It seems like a lot of work for not that much benefit, at the cost of significantly complicating the FORTH language model.

It's annoying that Apple seems to have made a policy choice to intentionally cripple their machines without an out (e.g. remove sip protection). Sigh.

[Klapaucius Klapaucius]

Very cool, ciforth!

I chose jonesforth mostly because I already had ported it to macOS Catalina on x64, and because I found a linux implemenation for ARM64 that I hoped would be trivial to port:

https://github.com/narenratan/jonesforth_arm64_apl/blob/master/jonesforth.S

It's pretty fun with all the APL syntax ;) I don't mind that it's not standards compatible, I'd care more if I were to write larger systems with it. It's more like a toy for me right now, and to learn a bit of ARM assembly code - porting a forth is a fun way of doing that ;)

If I had more time, I'd create a usable system for ARM/RISC SOC boards, like micropython. But my RTOS-fu is not up to the task and I don't have the time to level up ...
When I do, I keep ciforth in mind!

Have a great day!
K