Building and running gforth-0.2.1 on Debian 11 AMD64

[Anton Ertl]

For some reason I wanted to run gforth-0.2.1 (from 1996). My old
binary no longer works (it's an a.out binary), so I had a go at
rebuilding it. And I got it to work, and in 64-bit mode, too (AMD64
only appeared in 2003, but we had already ported Gforth to the Alpha
when we released 0.2.1).

Here's how I built it:

./configure
make

That's just what the documentation says. Running it is a little more
involved, though. From the build directory:

setarch `uname -m` -R ./gforth -p.

The "setarch -R" is there to disable ASLR (gforth-0.2.1 was released
shortly before that became fashionable), the "-p." is there so it
takes the gforth.fi image from the build directory rather than the
32-bit image that I have installed elsewhere.

That was surprisingly painless.

- 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

[Brian Fox]

On Monday, May 2, 2022 at 1:53:38 PM UTC-4, Anton Ertl wrote:
> For some reason I wanted to run gforth-0.2.1 (from 1996). My old
> binary no longer works (it's an a.out binary), so I had a go at
> rebuilding it. And I got it to work, and in 64-bit mode, too (AMD64
> only appeared in 2003, but we had already ported Gforth to the Alpha
> when we released 0.2.1).
>
> Here's how I built it:
>
> ./configure
> make
>
> That's just what the documentation says. Running it is a little more
> involved, though. From the build directory:
>
> setarch `uname -m` -R ./gforth -p.
>
> The "setarch -R" is there to disable ASLR (gforth-0.2.1 was released
> shortly before that became fashionable), the "-p." is there so it
> takes the gforth.fi image from the build directory rather than the
> 32-bit image that I have installed elsewhere.
>
> That was surprisingly painless.
>
> - anton
> --

This makes me want to ask the group a question.
If you have a program that you build with a Forth cross-compiler, how
do you provide the user with the type of compiler switches that Anton
is demonstrating?

I have typically just written a Forth "script" to control everything but
command line switches are pretty convenient . I am curious how
others people handle this in a Forth cross-compiler environment.

[Hans Bezemer]

On Tuesday, May 3, 2022 at 9:21:02 PM UTC+2, Brian Fox wrote:
> This makes me want to ask the group a question.
> If you have a program that you build with a Forth cross-compiler, how
> do you provide the user with the type of compiler switches that Anton
> is demonstrating?
>
> I have typically just written a Forth "script" to control everything but
> command line switches are pretty convenient . I am curious how
> others people handle this in a Forth cross-compiler environment.

I've cross-compiled 4tH on more platforms than I care to count. In general,
it's not difficult. It merely depends on the platform. I have "about" two platforms,
Microschoft based and *Nix based.

It merely concentrates on things like directory separators and the odd popen() call.
Predefined #macros figure most of that stuff out, like __GNU__, __TURBO_C__,
__WIN32__, etc.

Then there is embedded bytecode, which comes in two versions, 32bit and 64bit.
When *not* cross compiling, the Makefile can figure out how to build these. It requires
a "dummy", intermediate compiler (which "make" creates as well) which is discarded
later.

Since the generated files are ordinary, valid C files, cross compilation just requires
inclusion of these files - and all will be fine. No "dummy" compiler needed.

Hans Bezemer

[Brian Fox]

On Tuesday, May 3, 2022 at 5:29:38 PM UTC-4, the.bee...@gmail.com wrote:

> It merely concentrates on things like directory separators and the odd popen() call.
> Predefined #macros figure most of that stuff out, like __GNU__, __TURBO_C__,
> __WIN32__, etc.
>
> Then there is embedded bytecode, which comes in two versions, 32bit and 64bit.
> When *not* cross compiling, the Makefile can figure out how to build these. It requires
> a "dummy", intermediate compiler (which "make" creates as well) which is discarded
> later.
>
> Since the generated files are ordinary, valid C files, cross compilation just requires
> inclusion of these files - and all will be fine. No "dummy" compiler needed.
>
> Hans Bezemer

That part I am clear on. (at least until I find my next bug) :-)
But do you use the O/S command line typically ?
Do you use "compiler switches" on the command line? ( Like -R -o2 and the rest)

For example my hobby cross-compiler is used like this:

c:> XFC99 FLOAD CC9900\SRC.ITC\FORTHITC.MAK

But I don't provide the user with any way to switch what will happen on the
command line. Once the compiler begins reading the file it just runs.

Just wondering if that is ever done with Forth.

[dxforth]

On 4/05/2022 08:46, Brian Fox wrote:
>
> That part I am clear on. (at least until I find my next bug) :-)
> But do you use the O/S command line typically ?
> Do you use "compiler switches" on the command line? ( Like -R -o2 and the rest)
>
> For example my hobby cross-compiler is used like this:
>
> c:> XFC99 FLOAD CC9900\SRC.ITC\FORTHITC.MAK
>
> But I don't provide the user with any way to switch what will happen on the
> command line. Once the compiler begins reading the file it just runs.
>
> Just wondering if that is ever done with Forth.

Not that I've seen. 'command line and switch' being an OS-related feature
may exist or not. Typically what one finds in forth is a 'load block'
(however that is implemented) and 'electives' i.e. blocks of code it loads
or not. One might call it a 'make' file. Whether it's worth adding command-
line control depends on number of variables/targets etc. IIRC Moore said
didn't care for 'conditional compilation' as being an unnecessary complication.
YMMV

[Stephen Pelc]

On 3 May 2022 at 21:21:01 CEST, "Brian Fox" <bria...@brianfox.ca> wrote:

> If you have a program that you build with a Forth cross-compiler, how
> do you provide the user with the type of compiler switches that Anton
> is demonstrating?
>
> I have typically just written a Forth "script" to control everything but
> command line switches are pretty convenient . I am curious how
> others people handle this in a Forth cross-compiler environment.

Firstly, a cross compiler is a Forth app and its tools are only buried by
vocabulary/wordlist selection.

Secondly.most cross compilers support EQU, e.g
5 EQU MACHINE-TYPE
An equ is a constant that uses no target space and is ideal for
defining target switches. The MPE compiler has switches such
as
TASKING? \ true for multitasking
FAST-CMOVE? \ true for huge but fast CMOVE
as well as configuration values such as
SP-SIZE \ data stack size

The words available during interpretation include directives that
can change configuration.

Fine names/paths can also be used with macros, e.g.
ms" myproj/%arch%/floats.fth"
where %arch% may give x86 or x64 or ARM32 or ARM64.
Text Macros are also available in hosted systems.

The tools are designed with the knowledge that they will be
used in a cross-compiler. The techniques can be mixed as required.
The following programs the target Flash after compilation.

\ Define device, speed (0=auto) and project file
\ Download the target image when compilation finishes
jlink LPC4078 0 Project.jlink \ JLINK and device setup
useSWD \ use SWD rather than the
default JTAG
-download-prompts \ no prompting for download
afterwards download-sections \ download image after completion.


--
Stephen Pelc, ste...@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

[Hans Bezemer]

On Wednesday, May 4, 2022 at 12:46:15 AM UTC+2, Brian Fox wrote:
> Do you use "compiler switches" on the command line? ( Like -R -o2 and the rest)

> Just wondering if that is ever done with Forth.

Just the usual suspects, like -O3, -fsigned-char (yeah, I know - ported TC2 code),
-s, -L., -I., -o, -l4th, -Wall, the occasional -D to force specific behavior.

Nothing special or fancy. And no - the user gets to choose his Makefile. Unless
he goes editing that one himself, he's got not much of a choice.

Hans Bezemer

[Anton Ertl]

Brian Fox <bria...@brianfox.ca> writes:
>On Monday, May 2, 2022 at 1:53:38 PM UTC-4, Anton Ertl wrote:
>> For some reason I wanted to run gforth-0.2.1 (from 1996). My old
>> binary no longer works (it's an a.out binary), so I had a go at
>> rebuilding it. And I got it to work, and in 64-bit mode, too (AMD64
>> only appeared in 2003, but we had already ported Gforth to the Alpha
>> when we released 0.2.1).
>>
>> Here's how I built it:
>>
>> ./configure
>> make
>>
>> That's just what the documentation says. Running it is a little more
>> involved, though. From the build directory:
>>
>> setarch `uname -m` -R ./gforth -p.
>>
>> The "setarch -R" is there to disable ASLR (gforth-0.2.1 was released
>> shortly before that became fashionable), the "-p." is there so it
>> takes the gforth.fi image from the build directory rather than the
>> 32-bit image that I have installed elsewhere.

And the `unane -m` is unnecessary.

>This makes me want to ask the group a question.
>If you have a program that you build with a Forth cross-compiler, how
>do you provide the user with the type of compiler switches that Anton
>is demonstrating?
>
>I have typically just written a Forth "script" to control everything but
>command line switches are pretty convenient . I am curious how
>others people handle this in a Forth cross-compiler environment.

Most Forth systems allow putting Forth code on the OS command line, so
you can mix between having some parameters in a configuration file,
and some on the OS command line.

That being said, gforth usually passes a configuration file name on
the command line, but not individual parameters, e.g.:

./preforth -p ".:~+:." -e 's" arch/8086/mach.fs" include ./kernel-ec/main.fs' -e "save-cross kernl-8086.fi- /usr/local/bin/gforth-0.7.9_20220428 bye"

The configuration file is arch/8086/mach.fs.

[Brian Fox]

OK. So that's is what I have done as well.
I used VALUE definitions in the COMPILER vocabulary rather than EQU.
I can do that because VALUE is not in the final target Camel Forth at this time.
I may re-think that when the time comes.

[Brian Fox]

On Wednesday, May 4, 2022 at 11:01:52 AM UTC-4, Anton Ertl wrote:

> Most Forth systems allow putting Forth code on the OS command line, so
> you can mix between having some parameters in a configuration file,
> and some on the OS command line.
>
> That being said, gforth usually passes a configuration file name on
> the command line, but not individual parameters, e.g.:
>
> ./preforth -p ".:~+:." -e 's" arch/8086/mach.fs" include ./kernel-ec/main.fs' -e "save-cross kernl-8086.fi- /usr/local/bin/gforth-0.7.9_20220428 bye"
>
> The configuration file is arch/8086/mach.fs.

Ok, so you have both. That's what I was wondering about.
You demonstrate more command line control than I would ever need for the single target I play with. :-)
I will take a look at that configuration file.

[Brian Fox]

On Tuesday, May 3, 2022 at 9:13:55 PM UTC-4, dxforth wrote:
> Not that I've seen. 'command line and switch' being an OS-related feature
> may exist or not. Typically what one finds in forth is a 'load block'
> (however that is implemented) and 'electives' i.e. blocks of code it loads
> or not. One might call it a 'make' file. Whether it's worth adding command-
> line control depends on number of variables/targets etc. IIRC Moore said
> didn't care for 'conditional compilation' as being an unnecessary complication.
> YMMV

No question, in a traditional block based Forth I would do the same.

I am in my cross-compiler environment build on a Forth system that uses
text files.
LOL. So HsForth (1994) heavily modified, makes another Retro Forth.

I opted to make the cross-compiler into a saved system program
and kick it off from the command line with a file path.

Thus the question on industry practice.

[none albert]

I have turnkey manx. You run it with (bitbanging the parallel port)

tmanx song.sco

If you are on linux machine with no parallel port, I purchased a
ser/par board on pci, now that parallel port is on C030.

In linux I do now

tmanx -p C030 song.sco

-p is a regular Forth word, say

\ Execute the only option in existance -p : set the port
: -p SHIFT-ARGS 1 ARG[] HEX EVALUATE ATTACH-PARALLEL-PORT DECIMAL
SHIFT-ARGS ;

\ Handle all options
: MANX-OPTIONS ARGC 1 > IF 1 ARG[] DROP C@ &- = IF -p THEN THEN ;

Prerequisites are ARG[] ARGC and SHIFT-ARGS. These are left as an
exercise for the reader. (Hint:it fits in one screen, with space
to spare for environment stuff)

Groetjes Albert

In MS-Windows I could define /p instead of -p.
--
"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

[Brian Fox]

That's exactly the kind of thing I was thinking about.
Adding compiling control words that are sent to the job via the command line.
So I am not totally crazy. OK, maybe a little.
I will move along these lines. If I ever give this cross-compiler to the wider
hobbyist world it's probably easier to adopt if I provide some familiar
concepts.