ANN: iForth 32-bit final release
Marcel Hendrix
on, all further development will be for the 64-bit version.
Users that acquired iForth not earlier than 2006 will receive a
free update automatically.
Thanks to an awesome patch by a very talented iForth user a
processor register was freed up. As a consequence, per-task
user areas are back again, without any negative repercussions on
the runtime performance. The result is that the transputer-derived
parallel programming language extensions (threads) now work
perfectly on Linux. Also, debugging of CALLBACKs has become easier.
The FP performance on an AMD 3 GHz processor under SuSE Linux 10.3
is still over 12 GFlop/s (matrix multiplication benchmark).
Other changes were made to rationalize the color naming scheme and
the terminal's attribute settings.
A large number of (minor) source/example file cleanups were done.
The installation procedure for Linux has been vastly improved (but
there is still a long way to go).
Because of the ridiculously low dollar exchange rates, next year the
price of iForth shall be 100 Euros instead of 100 $US. Profit
from this 30 dollar bargain while it lasts :-)
-marcel
hel...@gmail.com
??!!! Are you sure? Nothing against EUR/$, but 64bit is that big
player in market?
Bis dann,
Helmar
Slava Pestov
> The final 32-bit release of iForth is in testing phase. From now
> on, all further development will be for the 64-bit version.
Why? I don't know how iForth is designed, but with Factor we haven't
had any trouble supporting multiple CPU architectures. Our x86 backend
is a total of 2164 lines of code; of this, 305 is specific to 32-bit
x86 and 221 is specific to 64-bit x86. So if we were to drop 32-bit
x86 support, it would mean 305 less lines of code to maintain;
negligible.
Slava
Marcel Hendrix
I have the distinct feeling that for you phrasing this question is far more
important than getting the answer :-)
Anyway, iForth is in three parts. First there is a runtime loader and server
written in C. As this was designed more than 12 years ago now, it doesn't
work quite the same way on Windows and Linux (there was/is Delories 32bit
DOS-extender for a while, and even a MMURTL port). Although I probably could
redesign it to be platform independent with a rewrite, for 64-bit the cygwin
support is not there yet. As iForth has native graphics, sound, pipes, threads,
and library support (e.g. BLAS, CLapack, Gint, FFTW, GotoBLAS, unrar, Matlab
and Excel shells), this runtime is not entirely trivial. Although I regard
it as pretty elementary and non-essential code, it is some 108 MBytes on disk
(Linux). I have the uneasy feeling that making it 64-bit compatible will
not be as easy as removing -m32 from the makefiles (let alone mixing 32 and
64bit code).
Second, there is a level 1 kernel of Forth code words that are only intended
to be interpreted (some 644 Kbytes on disk).
The third level is a second layer of optimizers written in highlevel Forth.
Each ANS Forth word has an optimizing mirror that tracks the stack arguments
as long as possible and generates machine code when the (5) stack queues need
to be flushed. This code is some 608 Kbytes on disk.
The second and third levels are independent of the OS (apparently they almost
work on Darwin too :-) Unfortunately, the code generation is all over the place
and uses a build-in mini Forth assembler. There is some peep-hole optimizing
going on in places that is also x86 dependent.
The fact that you have only about 305 x86 dependent lines in Factor will
probably be visible in a slight speed disadvantage with respect to iForth.
Small example:
[1] iForth server 1.01 (console), Nov 20 2007, 22:12:02.
[2] Stuffed iForth at 00437F00 [entry: 0x440000]
[3] Current process priority is 32.
[4] Executing /dfwforth/include/iforth.prf
Creating --- Several utilities Version 3.07 ---
Creating --- Extended OS words Version 3.16 ---
Creating --- Terminal Driver Version 3.13 ---
Creating --- Command line Editor Version 1.30 ---
Creating --- Online help Version 1.34 ---
Creating --- Glossary Generator Version 1.05 ---
Creating --- Disassembler Version 2.21 ---
iForth version 2.1.2692, generated 21:49:33, December 2, 2007.
x86 binary, native floating-point, double precision.
Copyright 1996 - 2008 Marcel Hendrix.
FORTH> create ape 3 C, 6 C, ok
FORTH> 2variable foo 22. foo 2! ok
FORTH> 121 value a ok
FORTH> 3.1459e FVALUE fpi ok
FORTH> : test fpi f2* f>d a + 3 xor foo 2! ; ok
FORTH> : mytest test foo 2@ d. ; ok
FORTH> see test
Flags: TOKENIZE, ANSI
: test fpi F2* F>D a + 3 XOR foo 2! ; ok
FORTH> see mytest
Flags: ANSI
$00545140 : mytest
$00545148 fld $00544C70 qword-ptr
$0054514E fmul $0046CB34 float-ptr
$00545154 fldcw $0046AC84 word-ptr
$0054515A sub esi, 8 b#
$0054515D fistp [esi 0 +] qword
$0054515F mov ecx, [esi 0 +] dword
$00545161 mov ebx, [esi 4 +] dword
$00545164 add esi, 8 b#
$00545167 fldcw $0046AC80 word-ptr
$0054516D add ebx, $00544C50 dword-ptr
$00545173 xor ebx, 3 b#
$00545176 mov $00544C30 dword-ptr, ebx
$0054517C mov $00544C34 dword-ptr, ecx
$00545182 push $00544C34 dword-ptr
$00545188 push $00544C30 dword-ptr
$0054518E jmp D.+8 ( $00481E68 ) offset NEAR
-marcel
Slava Pestov
> Slava Pestov <sl...@jedit.org> writes Re: ANN: iForth 32-bit final release
>
> > On Dec 5, 8:55 am, m...@iae.nl (Marcel Hendrix) wrote:
> >> The final 32-bit release of iForth is in testing phase. From now
> >> on, all further development will be for the 64-bit version.
> > Why? I don't know how iForth is designed, but with Factor we haven't
> > had any trouble supporting multiple CPU architectures. Our x86 backend
> > is a total of 2164 lines of code; of this, 305 is specific to 32-bit
> > x86 and 221 is specific to 64-bit x86. So if we were to drop 32-bit
> > x86 support, it would mean 305 less lines of code to maintain;
> > negligible.
>
> I have the distinct feeling that for you phrasing this question is far more
> important than getting the answer :-)
Actually, my point was that it is very easy to support both 32-bit and
64-bit x86 with the same code generator. Very little code actually
differs between the two, mostly just C library calling convention
support.
Most compilers being built these days have clean front end/back end
separation. gcc, LLVM, SBCL, and so on. I don't think its wise to
arbitrarily mix assembler in with the compiler front end.
> As iForth has native graphics, sound, pipes, threads,
> and library support (e.g. BLAS, CLapack, Gint, FFTW, GotoBLAS, unrar, Matlab
> and Excel shells), this runtime is not entirely trivial.
Why is support for these things built directly into the runtime? Can't
you just implement a generic C library interface and then load Forth
code on demand to interface with these libraries?
Slava
Marcel Hendrix
> Actually, my point was that it is very easy to support both 32-bit and
> 64-bit x86 with the same code generator. Very little code actually
> differs between the two, mostly just C library calling convention
> support.
There must be a fundamental difference between what you and I call "code",
then. The x86_64 has many more registers than the x86_32, can use just
any register for 8-16-32-64 bit parameters, and is free to use SSE2 and
better.
> Most compilers being built these days have clean front end/back end
> separation. gcc, LLVM, SBCL, and so on. I don't think its wise to
> arbitrarily mix assembler in with the compiler front end.
Are you suggesting to use gcc at runtime? No thanks.
Or are you suggesting that I implement iForth like gcc, SBCL etc.? That is
clearly not within my reach, and I don't think iForth users would be happy
with the general performance and responsiveness.
>> As iForth has native graphics, sound, pipes, threads,
>> and library support (e.g. BLAS, CLapack, Gint, FFTW, GotoBLAS, unrar, Matlab
>> and Excel shells), this runtime is not entirely trivial.
> Why is support for these things built directly into the runtime? Can't
> you just implement a generic C library interface and then load Forth
> code on demand to interface with these libraries?
1. That would bleed the C parameter conventions (like zero-terminated strings
and worse) into Forth. I assume iForth users are interested in writing Forth,
not in struggling with yet another language.
2. Convenience. There is a pretty wide gap between a C socket lib call and
something that does something useful. I don't want weird structures,
macros and magic constants cluttering up what should be a simple call.
Check the iTools (internet tools) preludes for non-iForths to see what I mean.
3. Building (some of) them in provides a uniform interface to like functionality
on each supported platform.
Well, these 3 could've done in the way you suggest, but for the iForth user
it makes no difference. And each re-implementation seems to make it better, so
I don't really mind the extra work. It's not that I expect having to support
many more CPU's and OS's in the coming years -- it all seems to converge nicely.
Multiple-cores fall within the existing framework.
-marcel