Gforth 0.7.0 available
Anton Ertl
available from <http://www.complang.tuwien.ac.at/forth/gforth/>. A
binary distribution for Windows should be available from there soon.
The source package should also be available soon on a GNU mirror near
you <http://www.gnu.org/prep/ftp.html>.
Gforth is a fast and portable implementation of the ANS Forth
language. It works nicely with the Emacs editor, offers some nice
features such as input completion and history, backtraces, a
decompiler and a powerful locals facility, and it even has a
manual. Gforth combines traditional implementation techniques with
newer techniques for portability and performance: its inner
interpreter is direct threaded with several optimizations, but you can
also use a traditional-style indirect threaded interpreter. Gforth is
distributed under the GNU General Public license (see COPYING).
Gforth runs under GNU, BSD, and similar systems, MS Windows, MacOS X,
OS/2, and DOS and should not be hard to port to other systems
supported by GCC. This version has been tested successfully on the
following platforms:
alpha-unknown-linux-gnu
armv5l-unknown-linux-gnu
i686-pc-linux-gnu
ia64-hp-hpux11.23
powerpc-unknown-linux-gnu
powerpc64-unknown-linux-gnu
sparc-sun-solaris2.10
x86_64-unknown-linux-gnu
i386-apple-darwin9.4.0
x86_64-apple-darwin9.4.0
ppc-apple-darwin9.4.0
i686-pc-cygwin
gforth-ec: r8c, 4stack, misc, 8086
User-visible changes between 0.6.2 and 0.7.0:
Requirements:
At run-time requires libtool and gcc (for the libcc C interface) and
gdb (for the disassembler (SEE)) on some platforms.
Installation:
support for DESTDIR, POST_INSTALL, INSTALL_SCRIPT
automatic performance tuning on building (--enable-force-reg unnecessary)
report performance and functionality problems at end of "make"
autogen.sh now exists
License:
Changed to GPLv3
Bug fixes
Now works with address-space randomization.
The single-step debugger works again in some engines.
Many others.
Ports:
AMD64, ARM, IA-64 (Itanium): better performance
PPC, PPC64: disassembler and assembler
Gforth EC: R8C, 4stack, misc, 8086 work
MacOS X: better support
Invocation:
New flags --ignore-async-signals, --vm-commit (default overcommit)
--print-sequences
Forth 200x:
X:extension-query: produce true for all implemented extensions
X:required REQUIRED etc. (not new)
X:defined: [DEFINED] and [UNDEFINED]
X:parse-name: PARSE-NAME (new name)
X:deferred: deferred words (new: DEFER@ DEFER! ACTION-OF)
X:structures: +FIELD FIELD: FFIELD: CFIELD: etc.
X:ekeys: new: EKEY>FKEY K-SHIFT-MASK K-CTRL-MASK K-ALT-MASK K-F1...K-F12
X:fp-stack (not new)
X:number-prefixes (partially new, see below)
Number prefixes:
0x is a hex prefix: 0xff and 0XfF now produces (decimal) 255
# is a decimal prefix: #10 now produces (decimal) 10
Signs after the number prefix are now accepted, e.g, #-50.
' now only handles a single (x)char: 'ab is no longer accepted,
'a' now produces (decimal) 97
Unicode support (currently supports only uniform encoding):
added xchars words for dealing with variable-width multi-byte characters
provide 8bit (ISO Latin 1) and UTF-8 support for xchars
New words:
\C C-FUNCTION C-LIBRARY END-C-LIBRARY C-LIBRARY-NAME (libcc C interface)
LIB-ERROR (complements OPEN-LIB)
OUTFILE-EXECUTE INFILE-EXECUTE BASE-EXECUTE (limited change of global state)
16-bit and 32-bit memory acces: UW@ UL@ SW@ SL@ W! L! W@ L@ /W /L
NEXT-ARG SHIFT-ARGS (OS command-line argument processing)
NOTHROW (for backtrace control)
FTRUNC FMOD (undocumented)
SEE-CODE SEE-CODE-RANGE (show generated dynamic native code)
Improvements/changes of existing words:
S\", .\" now support \l, \m, \z, and limits hex and octal character specs.
OPEN-FILE with W/O no longer creates or truncates files (no compat. file)
OPEN-LIB now understands ~ at the start, like OPEN-FILE.
TRY...ENDTRY changed significantly, compatibility files available (see docs).
The disassembler (DISCODE) can now use gdb to disassemble code
Uninitialized defered words now give a warning when executed
Division is floored (disable with "configure --enable-force-cdiv")
Gforth (not gforth-fast) reports division by zero and overflow on division
on all platforms.
Newly documented words:
S>NUMBER? S>UNUMBER?
EKEY keypress names: K-LEFT K-RIGHT K-UP K-DOWN K-HOME K-END K-PRIOR
K-NEXT K-INSERT K-DELETE
CLEARSTACKS
FORM
Environment variable GFORTHSYSTEMPREFIX (used by word SYSTEM and friends)
C interface:
exported symbols now start with "gforth_" (for referencing them from C code)
libcc C function call interface (requires libtool and gcc at run-time)
alternative: undocumented libffi-based interface
Libraries:
depth-changes.fs: report stack depth changes during interpretation
ans-report.fs now reports CfV extensions
fsl-util.4th: FSL support files (undocumented)
regexp.fs for regular expressions (undocumented)
complex.fs for complex numbers (undocumented)
fft.fs for Fast Fourier Transform (undocumented)
wf.fs, a Wiki implementation (undocumented)
httpd.fs, a web server (undocumented)
status.fs, show interpreter status in separate xterm (undocumented)
profile.fs for profiling (undocumented, incomplete)
endtry-iferror.fs, recover-endtry.fs to ease the TRY change transition
test/tester.fs: Now works with FP numbers (undocumented)
test/ttester.fs: Version of tester.fs with improved interface (T{...}T).
compat library:
compat/execute-parsing.fs
Speed improvements:
automatic performance tuning on building
static stack caching (good speedup on PPC)
mixed-precision division is now faster
support for int128 types on AMD64
workarounds for gcc performance bugs (in particular, PR 15242)
branch target alignment (good speedup on Alpha).
- 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
Bernd Paysan
> A
> binary distribution for Windows should be available from there soon.
It's available now from
http://www.complang.tuwien.ac.at/forth/gforth/gforth-0.7.0.exe
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
jacko
just wodered how easy it would be to move it to pocket pc? have an
amiga anywhere devkit, with gcc i think. how modular is the source?
because if I was going to get 0.7.0 up and running, i'd be a bit
miffed if i had to modify lots to get 0.8.0 up and running again.
I assume major system dependant is user i/o
1) is files via <stdio>
2) is cosole via <stdio>
3) is floats via <stdnum>
etc.
maybe I should read the source.
cheers
jacko
Albert van der Horst
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Gforth 0.7.0 (source distribution, and various doc formats) is now
<Impressive list deleteted>
Isn't it time for version 1.0.0 ?
>
>- 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
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Anton Ertl
>Isn't it time for version 1.0.0 ?
When the C interface is complete.
jacko
doc is not fully complete.
Looks like I'll have to prune it down to the main files, and the .fs
file set to get it to work on the pocket pc. It seems that a method of
trying forth or defs for some words is present, I would have prefered
all .fs defs and a few c basis defs. Not as kitchen sink, but much
simpler to bootstrap.
If I can make a .fs file of all the forth defined words, as a seperate
loadable, then I can make a c program to load and run it. Just need
the c primitive set (virtual machine spec).
What is the Gforth VM spec?
cheers
jacko
Anton Ertl
You mean to an ARM-based computer with Windows CE? ARM is no problem
(we have ARM ports already) but Windows CE is probably hard.
> have an
>amiga anywhere devkit, with gcc i think. how modular is the source?
>because if I was going to get 0.7.0 up and running, i'd be a bit
>miffed if i had to modify lots to get 0.8.0 up and running again.
One of our major goals is portability, so if you produce something
that can be integrated without too much pain in the Gforth
distribution, we would like to do so. In that case, if we had remote
access to a testing environment, the next release should work without
you having to do anything more.
>I assume major system dependant is user i/o
>1) is files via <stdio>
>2) is cosole via <stdio>
>3) is floats via <stdnum>
>etc.
What is <stdnum>?
We are using mainly ANSI C and POSIX functions in the C part. We are
also depending on a Posix/Unix-like build environment and gcc, and
currently we cannot cross-build. Looking around, I see that there are
things like CeGCC <http://cegcc.sourceforge.net/docs/using.html>,
CELIB <http://celib.sourceforge.net/>, and GNUWINCE
<http://win-ce.voxware.com:28575/Development%20Tools/gnuwince.html>,
which might be helpful.
An alternative to building full Gforth would be to make a Gforth EC
port for that platform; however, since the platform looks powerful
enough to support full Gforth, that would be a pity.
Anton Ertl
>I've read some of the source, and some ans words are missing and the
>doc is not fully complete.
What are you missing?
>Looks like I'll have to prune it down to the main files, and the .fs
>file set to get it to work on the pocket pc. It seems that a method of
>trying forth or defs for some words is present, I would have prefered
>all .fs defs and a few c basis defs. Not as kitchen sink, but much
>simpler to bootstrap.
>
>If I can make a .fs file of all the forth defined words, as a seperate
>loadable, then I can make a c program to load and run it. Just need
>the c primitive set (virtual machine spec).
You lost me along the way, but it seems that you want to do your own
build process based on the Forth source files and your own engine.
That's somewhat similar to Gforth EC, but it's probably not a good
idea if you want a full Gforth.
>What is the Gforth VM spec?
Look at the file "prim" or "prim.b".
jacko
The GCC environment that I have is Amiga Anywhere Devkit 2, It is not
disclosable what the very flashy graphics libraries etc supplied have
as functions, but the full CE library set is included (loads of .h
files). It is gcc based. It does not use Makefiles. .c and .h are
supported. Any binary release I make would have to be distributed by
Amiga Inc under licence conditions for use of the devkit. This may not
be possible under GPL, but is under LGPL.
What I really need for easy porting is a .fs file of all words defined
in forth (asy to parse and can build a dictionary), and a description
of the primitive base (the words which need to be in C, or Java2ME
etc.)
The current distribution is complex, and it is difficult to sort out
the exact complete set of primitives needed. The .fs files are easy to
sort through and cat together, but dependancies are not apparent so
the order would have to be experimental.
The idea was to make a compatabile VM andthe use the GPLed compiled
forth dictionary which sits upon the VM base. This would allow me to
release the compatable VM through Amiga and allow a GPL dictionary to
be downloaded.
The options of using other gcc systems still exsst, but the makefile
system is definatly not going to happen soon. I suggest a .fs
organization system based on levels:
.fs0 = primitive and entry point definition file
.fs = fully forth words
This makes most of the forth system reuseable by building a VM in any
language that can code the .fs0 wordset. It provides other system
implementation options, and ensures the Gforth common dictionary set.
A simple utility could then compile a .bin of the .fs files to load or
mmap into place. It could also work out any dependance order too.
If the prmitives maintain a standard numerical order, then a relative
addressed .bin would be part of the distribution (DTC and ITC
versions). I would download the windows binary if it makes such a .bin
dicionary, and the primitie numbering and function were available,
along with the .bin entry point address.
I am also looking to use a small forth (16 bit, 64Kcells) with the
nibz chip. http://nibz.googlecode.com as I have just released a design
file for a $12.00 CPLD chip cntaining a 16 bit processor, 40 general
IO pins, a full 16 bit static RAM memory bus, and 512 cells of boot
flash. It is a tight fit at 94% of an Altera MAX IIZ EPM570ZM100C6. It
programs to become an ultra low power 16 bit micro controller at 1.5
to 2 MIPS using the internal oscillator (CLK_O -> CLK_I).
I wonder if any Gforth options will produce such a small .bin
dictionary. Considering the cost of a 6502 this is competative.
cheers
jacko
Bernd Paysan
> The options of using other gcc systems still exsst, but the makefile
> system is definatly not going to happen soon. I suggest a .fs
> organization system based on levels:
>
> .fs0 = primitive and entry point definition file
> .fs = fully forth words
Only the file kernel/aliases.fs contains the primitive entry point
definitions. The .fi files the cross compiler creates are loaded by the
engine. The internals are undocumented, but it's not that far away from
what you think it should be.
> I am also looking to use a small forth (16 bit, 64Kcells) with the
> nibz chip. http://nibz.googlecode.com as I have just released a design
> file for a $12.00 CPLD chip cntaining a 16 bit processor, 40 general
> IO pins, a full 16 bit static RAM memory bus, and 512 cells of boot
> flash. It is a tight fit at 94% of an Altera MAX IIZ EPM570ZM100C6. It
> programs to become an ultra low power 16 bit micro controller at 1.5
> to 2 MIPS using the internal oscillator (CLK_O -> CLK_I).
>
> I wonder if any Gforth options will produce such a small .bin
> dictionary. Considering the cost of a 6502 this is competative.
That would be a Gforth EC port - look e.g. at the r8c port in arch/r8c as a
starting point. I do not consider $12 for a 2 MIPS 16 bit controller
as "competitive". Maybe I'm just too deep into making things like that ;-).
Anton Ertl
>The GCC environment that I have is Amiga Anywhere Devkit 2, It is not
>disclosable what the very flashy graphics libraries etc supplied have
>as functions, but the full CE library set is included (loads of .h
>files). It is gcc based. It does not use Makefiles. .c and .h are
>supported. Any binary release I make would have to be distributed by
>Amiga Inc under licence conditions for use of the devkit. This may not
>be possible under GPL, but is under LGPL.
If it is distributable under LGPL, it is also distributable under GPL,
because the LGPL allows switching to GPL.
>The idea was to make a compatabile VM andthe use the GPLed compiled
>forth dictionary which sits upon the VM base.
That's the way that Gforth is organized. What you call the VM is
called the engine, and what you call the dictionary is called the
image.
>I would download the windows binary if it makes such a .bin
>dicionary,
Yes, the Gforth image for Windows should work on the PocketPC: Cell
size and byte order are the same, and the little OS-dependent stuff
there is in an image is already set up for Windows there. The one
thing that would not work would be the disassembler and assembler (the
ones in the Windows image are for the 386 architecture, not ARM).
jacko
The r8c arch explained a lot. 3 .fs files to define the primitives,
assembler and machine layout. This should not be too complex to do for
some processor. No arm assembler in arch/arm so this would require an
arm assembler source.
Looks like any .fs could be included in the compile of the dictionary.
Will get round to doing nibz40 EC port, with a nibz40+ emulator for
pocket PC. ('cos that's what I need).
A more compact solution would be to write a CIL .netCF2 assembler and
do pocket pc that way, with testing working on desktop pc .net.
majic...
cheers
jacko
m_l_g3
gcc -I./../arch/386 -I. -Wall -O2 -fomit-frame-pointer -fforce-addr -
march=pentium -DHAVE_CONFIG_H -DFORCE_LL -DDEFAULTPATH='".:/usr/local/
lib/gforth/site-forth:/usr/local/share/gforth/site-forth:/usr/local/
lib/gforth/0.7.0:/usr/local/share/gforth/0.7.0"' -o main-fast-ll.o -
c ./main.c
./main.c: In function ‘dict_alloc_read’:
./main.c:616: warning: ignoring return value of ‘fread’, declared with
attribute warn_unused_result
./main.c:696:2: warning: #warning You can ignore the warnings about
clobbered variables in gforth_go
./main.c: In function ‘prepare_super_table’:
./main.c:846: error: ‘N_noop’ undeclared (first use in this function)
./main.c:846: error: (Each undeclared identifier is reported only once
./main.c:846: error: for each function it appears in.)
./main.c: In function ‘gforth_loader’:
./main.c:1898: warning: ignoring return value of ‘fread’, declared
with attribute warn_unused_result
./main.c:1922: warning: ignoring return value of ‘fread’, declared
with attribute warn_unused_result
make[3]: *** [main-fast-ll.o] Error 1
m_l_g3
: x.name ['] .name catch if ." (invalid)" drop then ;
2. In the previous version,
ekey body> >name .name
worked just fine. What is the suggested way now?
Bernd Paysan
> 1. can you please make .name print something sensible on invalid data?
Should be quite easy. >name returns 0 for invalid data.
> : x.name ['] .name catch if ." (invalid)" drop then ;
>
> 2. In the previous version,
>
> ekey body> >name .name
>
> worked just fine. What is the suggested way now?
The previous version used CREATE to define these constants, but that doesn't work when you have bits for shift, ctrl, and alt. ATM, there's no such easy way to convert an ekey to a description string.
Anton Ertl
>m_l_g3 wrote:
>
>> 1. can you please make .name print something sensible on invalid data?
>
>Should be quite easy. >name returns 0 for invalid data.
So what should >name print? Or is throwing an error the right thing
to do after all?
>> : x.name ['] .name catch if ." (invalid)" drop then ;
>>
>> 2. In the previous version,
>>
>> ekey body> >name .name
>>
>> worked just fine. What is the suggested way now?
>
>The previous version used CREATE to define these constants, but that doesn't work when you have bits for shift, ctrl, and alt. ATM, there's no such easy way to convert an ekey to a description string.
Since the EKEY/EKEY>FKEY values are generated in a systematic way, it
would not be hard to have a word FKEY. that prints such a description
string (generating a complete string would be a little more involved).
But is there enough demand for this functionality to justify the cost?
Anton Ertl
>I'm getting an error trying to compile it under bububu 8.10, gcc 4.3:
>
>gcc -I./../arch/386 -I. -Wall -O2 -fomit-frame-pointer -fforce-addr -
>lib/gforth/site-forth:/usr/local/share/gforth/site-forth:/usr/local/
>lib/gforth/0.7.0:/usr/local/share/gforth/0.7.0"' -o main-fast-ll.o -
>c ./main.c
>./main.c:616: warning: ignoring return value of =91fread=92, declared with
>attribute warn_unused_result
>./main.c:696:2: warning: #warning You can ignore the warnings about
>clobbered variables in gforth_go
>./main.c:846: error: =91N_noop=92 undeclared (first use in this function)
>./main.c:846: error: (Each undeclared identifier is reported only once
>./main.c:846: error: for each function it appears in.)
>./main.c:1898: warning: ignoring return value of =91fread=92, declared
>with attribute warn_unused_result
>./main.c:1922: warning: ignoring return value of =91fread=92, declared
>with attribute warn_unused_result
>make[3]: *** [main-fast-ll.o] Error 1
That's strange, whatever OS bububu might be. Maybe you have a preset
include path (using the CPATH or C_INCLUDE_PATH environment
variables), that lets you include the wrong file or something.
Alternatively, the file engine/prim_num-fast.i could have been
generated wrong (or its generation failed or was terminated, but it
was not deleted afterwards; in that case trying to build from scratch
could help).
What you could do to help us diagnose this problem is to generate a
file after the C preprocessing step, i.e., go into the directory
engine and do:
gcc -I./../arch/386 -I. -Wall -O2 -fomit-frame-pointer -fforce-addr -march=3Dpentium -DHAVE_CONFIG_H -DFORCE_LL -DDEFAULTPATH=3D'".:/usr/local/lib/gforth/site-forth:/usr/local/share/gforth/site-forth:/usr/local/lib/gforth/0.7.0:/usr/local/share/gforth/0.7.0"' -E ./main.c >main-fast-ll.i
and make the resultin main-fast-ll.i available to us.
Ian Osgood
wrote:
> Gforth 0.7.0 (source distribution, and various doc formats) is now
> available from <http://www.complang.tuwien.ac.at/forth/gforth/>. A
> binary distribution for Windows should be available from there soon.
> The source package should also be available soon on a GNU mirror near
> you <http://www.gnu.org/prep/ftp.html>.
...
> Speed improvements:
> automatic performance tuning on building
> static stack caching (good speedup on PPC)
> mixed-precision division is now faster
> support for int128 types on AMD64
> workarounds for gcc performance bugs (in particular, PR 15242)
> branch target alignment (good speedup on Alpha).
>
> - 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
This autotooled version is the first since 0.6.2 that built
successfully from scratch on my Mac OS X Core2Duo laptop. (maybe not
from scratch; it finds an existing 0.6.2 install) (no libffi detected.
Do any of the shipped libraries depend on libffi-style interfaces?)
Performance is much improved. FCP bench results:
MacPorts gforth-fast 0.6.2
Results: 66900 nps
Custom built gforth-fast 0.7.0 (default options)
Results: 104779 nps
Someone who knows the BSD/MacPorts/Debian/Red Hat systems should push
this upstream. Five years without a release is far too long.
Any tutorials on using the new FFI system?
Ian
Anton Ertl
>This autotooled version is the first since 0.6.2 that built
>successfully from scratch on my Mac OS X Core2Duo laptop. (maybe not
>from scratch; it finds an existing 0.6.2 install)
I tested it on systems that have no Gforth installed (and on some
where I renamed the existing Gforth, so it would not be found).
> (no libffi detected.
>Do any of the shipped libraries depend on libffi-style interfaces?)
No. But libffi.fs, which provides the libffi-style interface, needs
libffi.
>Someone who knows the BSD/MacPorts/Debian/Red Hat systems should push
>this upstream.
I guess those distributions that have had Gforth packages before will
create 0.7.0 packages, too. However, since we are the source (i.e.,
as upstream as possible), the correct term would be "downstream".
Hmm, googling a bit it seems that some are faster than others:
<http://rpmfind.net/linux/RPM/fedora/updates/9/i386/gforth-0.7.0-1.fc9.i386.html>
>Any tutorials on using the new FFI system?
For now there's the documentation:
<http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/C-Interface.html>
Anton Ertl
>Bernd Paysan <bernd....@gmx.de> writes:
>>m_l_g3 wrote:
>>> 2. In the previous version,
>>>
>>> ekey body> >name .name
>>>
>>> worked just fine. What is the suggested way now?
>Since the EKEY/EKEY>FKEY values are generated in a systematic way, it
>would not be hard to have a word FKEY. that prints such a description
>string (generating a complete string would be a little more involved).
>But is there enough demand for this functionality to justify the cost?
In the spirit of supporting introspection, I have implemented it for
now (it's in the CVS), so you can do, e.g.:
ekey ekey>fkey . fkey.
and if you press Shift-F7 on an xterm, you get the following output:
-1 k-f7 k-shift-mask or
Bernd Paysan
> I guess those distributions that have had Gforth packages before will
> create 0.7.0 packages, too. However, since we are the source (i.e.,
> as upstream as possible), the correct term would be "downstream".
>
> Hmm, googling a bit it seems that some are faster than others:
>
<http://rpmfind.net/linux/RPM/fedora/updates/9/i386/gforth-0.7.0-1.fc9.i386.html>
OpenSUSE's factory repository also contains Gforth 0.7.0, so it will be part
of OpenSUSE 11.1.
Aleksej Saushev
> Ian Osgood <ia...@quirkster.com> writes:
>>Someone who knows the BSD/MacPorts/Debian/Red Hat systems should push
>>this upstream.
>
> I guess those distributions that have had Gforth packages before will
> create 0.7.0 packages, too. However, since we are the source (i.e.,
> as upstream as possible), the correct term would be "downstream".
I happened to be overloaded these days, pkgsrc package will appear in a week or so.
--
HE CE3OH...
jacko
\ FORTH Assembler for nibz40
\
\ Copyright (C) 2006,2007 Free Software Foundation, Inc.
\ This file is part of Gforth.
\ Gforth is free software; you can redistribute it and/or
\ modify it under the terms of the GNU General Public License
\ as published by the Free Software Foundation, either version 3
\ of the License, or (at your option) any later version.
\ This program is distributed in the hope that it will be useful,
\ but WITHOUT ANY WARRANTY; without even the implied warranty of
\ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
\ GNU General Public License for more details.
\ You should have received a copy of the GNU General Public License
\ along with this program. If not, see http://www.gnu.org/licenses/.
\
\ Autor: Simon Jackson, BEng.
\
\ Information:
\
\ - Simple Assembler
\ only forth definitions
require asm/basic.fs
also ASSEMBLER definitions
require asm/target.fs
HERE ( Begin )
\ primary opcode constant writers
: BA 0 , ;
: FI 1 , ;
: RI 2 , ;
: SI 3 , ;
: GO 4 , ;
: DI 5 , ;
: BO 6 , ;
: SU 7 , ;
: RO 8 , ;
: FA 9 , ;
: RA 10 , ;
: SA 11 , ;
: SO 12 , ;
: FE 13 , ;
: RE 14 , ;
: SE 15 , ;
HERE SWAP -
CR .( Length of Assembler: ) . .( Bytes ) CR
jacko
Just a few things while looking at various files
1) in kernal/prims.fs the following functions are defined in the wrong
order (I think, giving a bad
colondef entry for d+ in the first function)
: m+ ( d1 n -- d2 )
s>d d+ ;
: d+ ( d1 d2 -- d )
rot + >r tuck + swap over u> r> swap - ;
2) in the r8c assembler why are the branch control words defined, and
not using (?branch) ?
3) for floats what is the minimum primitive set to define, and which
extra files have to be included?
4) It is not completly clear what setvalue options to use, and what
extra words would be required,
some are obvious, but some are more involved, e.g. if I wanted a
compiler included, what setvalue
would I use? and is there any extra words required?
cheers for now
jacko
Bernd Paysan
> Hi
>
> Just a few things while looking at various files
>
> 1) in kernal/prims.fs the following functions are defined in the wrong
> order (I think, giving a bad
>
> colondef entry for d+ in the first function)
>
> : m+ ( d1 n -- d2 )
> s>d d+ ;
>
> : d+ ( d1 d2 -- d )
> rot + >r tuck + swap over u> r> swap - ;
That's intentional, because the cross compiler is in a special mode, where
it skips already defined words up to the next empty line. Since the cross
compiler can do forward resolving, it will work all right.
> 2) in the r8c assembler why are the branch control words defined, and
> not using (?branch) ?
Those are branch control words for the assembler sources, not for the high
level Forth words. Example in prim.fs, the word ?branch:
tos , tos tst.w 0= IF -2 [ip] , ip mov.w:g THEN
This is the assembler's IF and THEN.
> 3) for floats what is the minimum primitive set to define, and which
> extra files have to be included?
Floats aren't supported in Gforth EC. It's usually pointless to do floats in
a 16 bit CPU.
> 4) It is not completly clear what setvalue options to use, and what
> extra words would be required,
>
> some are obvious, but some are more involved, e.g. if I wanted a
> compiler included, what setvalue
>
> would I use? and is there any extra words required?
Look at the sources in the kernel/ subdirectory. The values are queried with
has? <value>, so you can see which value has what kind of effect on the
sources. The compiler value certainly is called "compiler" ;-).
m_l_g3
wrote:
user@ubuntu:~/gforth-0.7.0/engine$ echo $CPATH -- $C_INCLUDE_PATH
--
user@ubuntu:~/gforth-0.7.0/engine$
> Alternatively, the file engine/prim_num-fast.i could have been
> generated wrong (or its generation failed or was terminated, but it
> was not deleted afterwards; in that case trying to build from scratch
> could help).
>
> What you could do to help us diagnose this problem is to generate a
> file after the C preprocessing step, i.e., go into the directory
> engine and do:
>
> gcc -I./../arch/386 -I. -Wall -O2 -fomit-frame-pointer -fforce-addr -march=3Dpentium -DHAVE_CONFIG_H -DFORCE_LL -DDEFAULTPATH=3D'".:/usr/local/lib/gforth/site-forth:/usr/local/share/gforth/site-forth:/usr/local/lib/gforth/0.7.0:/usr/local/share/gforth/0.7.0"' -E ./main.c >main-fast-ll.i
>
> and make the resultin main-fast-ll.i available to us.
>
> - 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
user@ubuntu: ~/gforth-0.7.0/engineuser@ubuntu:~/gforth-0.7.0/engine$
gcc -I./../arch/386 -I. -Wall -O2 -fomit-frame-pointer -fforce-addr -
march=3Dpentium -DHAVE_CONFIG_H -DFOl/lib/gforth/site-forth:/usr/local/
share/gforth/site-forth:/usr/local/lib/gforth/0.7.0:/usr/local/share/
gforth/0.7.0"' -E ./main.c >main-fast-ll.i
cc1: error: bad value (3Dpentium) for -march= switch
cc1: error: bad value (3Dpentium) for -mtune= switch
user@ubuntu:~/gforth-0.7.0/engine$ uname -a
Linux ubuntu 2.6.27-7-generic #1 SMP Fri Oct 24 06:42:44 UTC 2008 i686
GNU/Linux
#Hmmm, why they call it 8.10 then?
user@ubuntu:~/gforth-0.7.0/engine$ gcc --version
gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
<...>
user@ubuntu:~/gforth-0.7.0/engine$ g++ --version
g++ (Ubuntu 4.3.2-1ubuntu11) 4.3.2
<...>
user@ubuntu:~/gforth-0.7.0/engine$ cat main-fast-ll.i
# 1 "./main.c"
user@ubuntu:~/gforth-0.7.0/engine$
---
-- I've been installing Ubuntu.
-- you mumble
-- I've been installing Ubuntu!
-- You don't pronounce the last word!
-- I'VE BEEN INSTALLING UBUNTU
-- You shout, but swallow the same last word! I hear only boo-boo-boo.
-- U-B-U-N-T-U, a Linux name.
-- Who on Earth called it so?
Anton Ertl
>On Nov 7, 9:27=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> What you could do to help us diagnose this problem is to generate a
>> file after the C preprocessing step, i.e., go into the directory
>> engine and do:
>>
>arch=3D3Dpentium -DHAVE_CONFIG_H -DFORCE_LL -DDEFAULTPATH=3D3D'".:/usr/loca=
>l/lib/gforth/site-forth:/usr/local/share/gforth/site-forth:/usr/local/lib/g=
>forth/0.7.0:/usr/local/share/gforth/0.7.0"' =A0-E ./main.c >main-fast-ll.i
>>
>> and make the resultin main-fast-ll.i available to us.
>>
>> - anton
>> --
>> comp.lang.forth FAQs:http://www.complang.tuwien.ac.at/forth/faq/toc.html
>> =A0 =A0 =A0New standard:http://www.forth200x.org/forth200x.html
>
>user@ubuntu: ~/gforth-0.7.0/engineuser@ubuntu:~/gforth-0.7.0/engine$
>gcc -I./../arch/386 -I. -Wall -O2 -fomit-frame-pointer -fforce-addr -
>share/gforth/site-forth:/usr/local/lib/gforth/0.7.0:/usr/local/share/
>gforth/0.7.0"' -E ./main.c >main-fast-ll.i
>cc1: error: bad value (3Dpentium) for -mtune=3D switch
I won't clean up the quoted-printable mess (e.g., turning "=" into
"=3D") that your news posting software produces.
>user@ubuntu:~/gforth-0.7.0/engine$ uname -a
>Linux ubuntu 2.6.27-7-generic #1 SMP Fri Oct 24 06:42:44 UTC 2008 i686
>GNU/Linux
Ah, Ubuntu. I just inserted the Ubuntu 8.10 Live CD for the AMD64
architecture (sorry, I had no i686 CD handy), and built gforth-0.7.0.
I had to install m4 to build it, and emacs was missing, too (so I got
no gforth.elc), but apart from that the build succeeded; a Live CD is
cool with enough RAM.
I did start again from scratch after installing m4, because just
continuing the build failed. Hmm, make does not delete the target of
the failed command; looking in the documentation, this is due to
backwards compatibility. I have now fixed this in the CVS (by adding
".DELETE_ON_ERROR").
>user@ubuntu:~/gforth-0.7.0/engine$ cat main-fast-ll.i
># 1 "./main.c"
Since the compiler driver produced an error, the result is incomplete
and does not tell us anything.
m_l_g3
wrote:<...>
> >cc1: error: bad value (3Dpentium) for -mtune=3D switch
>
> I won't clean up the quoted-printable mess (e.g., turning "=" into
> "=3D") that your news posting software produces.
The news posting software is google groups.
I do not know if the proverb "[Please/you may] complain to Google" is
international... Well, you see.
gavino
wrote:
> Gforth 0.7.0 (source distribution, and various doc formats) is now
> available from <http://www.complang.tuwien.ac.at/forth/gforth/>. A
> binary distribution for Windows should be available from there soon.
> The source package should also be available soon on a GNU mirror near
> you <http://www.gnu.org/prep/ftp.html>.
>
> language. It works nicely with the Emacs editor, offers some nice
> features such as input completion and history, backtraces, a
> decompiler and a powerful locals facility, and it even has a
> manual. Gforth combines traditional implementation techniques with
> newer techniques for portability and performance: its inner
> interpreter is direct threaded with several optimizations, but you can
> also use a traditional-style indirect threaded interpreter. Gforth is
> distributed under the GNU General Public license (see COPYING).
>
> Gforth runs under GNU, BSD, and similar systems, MS Windows, MacOS X,
> OS/2, and DOS and should not be hard to port to other systems
> supported by GCC. This version has been tested successfully on the
> following platforms:
>
> alpha-unknown-linux-gnu
> armv5l-unknown-linux-gnu
> i686-pc-linux-gnu
> ia64-hp-hpux11.23
> powerpc-unknown-linux-gnu
> powerpc64-unknown-linux-gnu
> sparc-sun-solaris2.10
> x86_64-unknown-linux-gnu
> i386-apple-darwin9.4.0
> x86_64-apple-darwin9.4.0
> ppc-apple-darwin9.4.0
> i686-pc-cygwin
> gforth-ec: r8c, 4stack, misc, 8086
>
> User-visible changes between 0.6.2 and 0.7.0:
>
> Requirements:
> At run-time requires libtool and gcc (for the libcc C interface) and
> gdb (for the disassembler (SEE)) on some platforms.
> Installation:
> support for DESTDIR, POST_INSTALL, INSTALL_SCRIPT
> automatic performance tuning on building (--enable-force-reg unnecessary)
> report performance and functionality problems at end of "make"
> autogen.sh now exists
> License:
> Changed to GPLv3
> Bug fixes
> Now works with address-space randomization.
> The single-step debugger works again in some engines.
> Many others.
> Ports:
> AMD64, ARM, IA-64 (Itanium): better performance
> PPC, PPC64: disassembler and assembler
> Gforth EC: R8C, 4stack, misc, 8086 work
> MacOS X: better support
> Invocation:
> New flags --ignore-async-signals, --vm-commit (default overcommit)
> --print-sequences
> Forth 200x:
> X:extension-query: produce true for all implemented extensions
> X:required REQUIRED etc. (not new)
> X:defined: [DEFINED] and [UNDEFINED]
> X:parse-name: PARSE-NAME (new name)
> X:deferred: deferred words (new: DEFER@ DEFER! ACTION-OF)
> X:structures: +FIELD FIELD: FFIELD: CFIELD: etc.
> X:ekeys: new: EKEY>FKEY K-SHIFT-MASK K-CTRL-MASK K-ALT-MASK K-F1...K-F12
> X:fp-stack (not new)
> X:number-prefixes (partially new, see below)
> Number prefixes:
> 0x is a hex prefix: 0xff and 0XfF now produces (decimal) 255
> # is a decimal prefix: #10 now produces (decimal) 10
> Signs after the number prefix are now accepted, e.g, #-50.
> ' now only handles a single (x)char: 'ab is no longer accepted,
> 'a' now produces (decimal) 97
> Unicode support (currently supports only uniform encoding):
> added xchars words for dealing with variable-width multi-byte characters
> provide 8bit (ISO Latin 1) and UTF-8 support for xchars
> New words:
> \C C-FUNCTION C-LIBRARY END-C-LIBRARY C-LIBRARY-NAME (libcc C interface)
> LIB-ERROR (complements OPEN-LIB)
> OUTFILE-EXECUTE INFILE-EXECUTE BASE-EXECUTE (limited change of global state)
> 16-bit and 32-bit memory acces: UW@ UL@ SW@ SL@ W! L! W@ L@ /W /L
> NEXT-ARG SHIFT-ARGS (OS command-line argument processing)
> NOTHROW (for backtrace control)
> FTRUNC FMOD (undocumented)
> SEE-CODE SEE-CODE-RANGE (show generated dynamic native code)
> Improvements/changes of existing words:
> S\", .\" now support \l, \m, \z, and limits hex and octal character specs.
> OPEN-FILE with W/O no longer creates or truncates files (no compat. file)
> OPEN-LIB now understands ~ at the start, like OPEN-FILE.
> TRY...ENDTRY changed significantly, compatibility files available (see docs).
> The disassembler (DISCODE) can now use gdb to disassemble code
> Uninitialized defered words now give a warning when executed
> Division is floored (disable with "configure --enable-force-cdiv")
> Gforth (not gforth-fast) reports division by zero and overflow on division
> on all platforms.
> Newly documented words:
> S>NUMBER? S>UNUMBER?
> EKEY keypress names: K-LEFT K-RIGHT K-UP K-DOWN K-HOME K-END K-PRIOR
> K-NEXT K-INSERT K-DELETE
> CLEARSTACKS
> FORM
> Environment variable GFORTHSYSTEMPREFIX (used by word SYSTEM and friends)
> C interface:
> exported symbols now start with "gforth_" (for referencing them from C code)
> libcc C function call interface (requires libtool and gcc at run-time)
> alternative: undocumented libffi-based interface
> Libraries:
> depth-changes.fs: report stack depth changes during interpretation
> ans-report.fs now reports CfV extensions
> fsl-util.4th: FSL support files (undocumented)
> regexp.fs for regular expressions (undocumented)
> complex.fs for complex numbers (undocumented)
> fft.fs for Fast Fourier Transform (undocumented)
> wf.fs, a Wiki implementation (undocumented)
> httpd.fs, a web server (undocumented)
> status.fs, show interpreter status in separate xterm (undocumented)
> profile.fs for profiling (undocumented, incomplete)
> endtry-iferror.fs, recover-endtry.fs to ease the TRY change transition
> test/tester.fs: Now works with FP numbers (undocumented)
> test/ttester.fs: Version of tester.fs with improved interface (T{...}T).
> compat library:
> compat/execute-parsing.fs
> Speed improvements:
> automatic performance tuning on building
> static stack caching (good speedup on PPC)
> mixed-precision division is now faster
> support for int128 types on AMD64
> workarounds for gcc performance bugs (in particular, PR 15242)
> branch target alignment (good speedup on Alpha).
>
> --
> 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
how is it cmoparing to helforth now?
helforth had some stat about being faster...
http://maschenwerk.de/HelFORTH/benchmarks.html
gavino
does the manual have tutorial? ah here
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/index.html#Top
why does this page have no link to the manual?
http://www.gnu.org/software/gforth/#TOCintroduction
I just compile 7.0 on archlinux after realizing I needed to add m4.
congradulations! excellent work!! you rock!!
any cpan for forth? cFan? comperehensive forth app archive?
gavino
have the m4?
gavino
still using your forth web server?