A really small and understandable Forth
123forth
weforth2.exe is nearly 190KB and F# (version 2.40) is only 34KB.
Is the big size of weforth2.exe caused by :
db 20000H dup(0)
DICTEND:
Question #1:
Can weforth2.exe be put on a diet to get sliimer (as F#) ? How can it
be done?
How minimal is F# compared to mini4th by Edward B.Beach version 4.15
(1989 ) and modified by Barry Marks?
Core1.com is only 6KB and can load core1.4 (11KB) to give a nice forth
system with "SEE":
ok
SEE SEE
: SEE ' DUP C@ 233 =
IF DOWORD
ELSE IS" ." CODE word at $" .H
THEN ;
ok
is it much better than F# "SEE":
$ > SEE SEE
' CR doLIT 28 0 0 0 >R COUNT DUP doLIT 0 0 0 = B DB 8B 5D 0 8D 6D 4
74 48 DROP DUP @ OVER CELL+ + >NAME ?DUP B DB 8B 5D 0 8D 6D 4
Question #2
Forthly, how do you rate F# (version 2.40) vs Mini4th (version 4.15)
disregard the fact that F# is 32bit and has a GUI console and Mini4th
is 16 bit and does not.
Question #3
Is there a 32bit version of Mini4th ?
Your help is much appreciated.
Regards,
123forth
ron
> Greetings,
>
> weforth2.exe is nearly 190KB and F# (version 2.40) is only 34KB.
>
> Is the big size of weforth2.exe caused by :
>
> db 20000H dup(0)
> DICTEND:
Yes, partly. Without having access to the weforth source code, I can
tell you this line makes the exe 20,000 bytes bigger. Assuming that
it does not have to be initialized (after all, I have no idea what
this buffer is for), making sure it's at the end of the source, and
changing (0) to (?) should slim things down.
crc
Shouldn't that be 128k since 20000H is a hex value?
-- crc
123forth
> > > db 20000H dup(0)
> > > DICTEND:
>
> > Yes, partly. Without having access to the weforth source code, I can
> > tell you this line makes the exe 20,000 bytes bigger. Assuming that
> > it does not have to be initialized (after all, I have no idea what
> > this buffer is for), making sure it's at the end of the source, and
Yes, it is at the end of the source (MASM32):
db 20000H dup(0)
DICTEND:
;COLD0:
;again0:
; call KEY
; cmp ebx,27
; je Exit
; call DUPP
; call EMIT
; call EMIT
; jmp again0
;Exit:
; ret
;====================================================================
end start
> > changing (0) to (?) should slim things down.
That doesn't seem to work as yet.
The size is still around 189 KB.
>
> Shouldn't that be 128k since 20000H is a hex value?
Yes, I think the directive:
db 20000H dup(0)
statically allocated extra 128 KB for the dictionary space.
Thanks for your help.
123forth
> -- crc- Hide quoted text -
>
> - Show quoted text -
ron
> Shouldn't that be 128k since 20000H is a hex value?
Oops. Yes :)
jacko
using Pro-Dos CP/M. It is quite small considering the features. It is
still larger than Jupiter ACE forth though, which I think is 8K,
although has a non standard DEFINER DOES> and COMPILER RUNS>. I thinks
its to do with SEE (implicit word not defined) being an exact recall
for edit. Full Z80 source for Jupiter ACE is available.
Cheers Jacko
123forth
Thanks for the tips, but isn't it about time we stop going back to the
future to look for really small and understandable Forth. Even with
time sharing, rental time on time machine is pretty expensive ;-)
Isn't 'Jonesforth' the latest Public Domain Forth on the block? The
implementation documents (embedded in the assembly source code) is
very understandable and the words are SEEable.
But it looks like 'Mini4th' is still winning by a wide margin in the
size and understandability(?) when it comes to SEE SEE:
[root@hphRHx86 jones]# ls -l
total 184
-rwxr-xr-x 1 root root 177 Mar 15 10:52 build
-rwxr-xr-x 1 root root 16992 Mar 15 10:52 jonesforth
-rw-r--r-- 1 root root 59363 Mar 5 16:10 jonesforth.f
-rw-r--r-- 1 root root 93661 Mar 5 16:11 jonesforth.S
[root@hphRHx86 jones]# cat build
# gcc -m32 -nostdlib -static -Wl,-Ttext,0 -Wl,--build-id=none -o
jonesforth jonesforth.S
options="-m32 -nostdlib -static -Wl,-Ttext,0"
gcc ${options} -o jonesforth jonesforth.S
[root@hphRHx86 jones]# cat jonesforth.f - | ./jonesforth
SEE SEE
: SEE WORD FIND HERE @ LATEST @ 2 PICK OVER <> 0BRANCH ( 24 ) NIP DUP
@ BRANCH ( -44 ) DROP SWAP ':' EMIT SPACE DUP ID. SPACE DUP ?IMMEDIATE
0BRANCH ( 28 ) S" IMMEDIATE " TELL >DFA 2DUP > 0BRANCH ( 620 ) DUP @ '
LIT OVER = 0BRANCH ( 40 ) DROP 4 + DUP @ . BRANCH ( 532 ) ' LITSTRING
OVER = 0BRANCH ( 120 ) DROP 83 EMIT '"' EMIT SPACE 4 + DUP @ SWAP 4 +
SWAP 2DUP TELL '"' EMIT SPACE + ALIGNED 4 - BRANCH ( 392 ) ' 0BRANCH
OVER = 0BRANCH ( 80 ) DROP S" 0BRANCH ( " TELL 4 + DUP @ . S" ) " TELL
BRANCH ( 292 ) ' BRANCH OVER = 0BRANCH ( 80 ) DROP S" BRANCH ( " TELL
4 + DUP @ . S" ) " TELL BRANCH ( 192 ) ' ' OVER = 0BRANCH ( 64 ) DROP
39 EMIT SPACE 4 + DUP @ CFA> ID. SPACE BRANCH ( 108 ) ' EXIT OVER =
0BRANCH ( 64 ) DROP 2DUP 4 + <> 0BRANCH ( 24 ) S" EXIT " TELL BRANCH
( 24 ) DUP CFA> ID. SPACE DROP 4 + BRANCH ( -628 ) ';' EMIT CR 2DROP ;
BYE
BYE
[root@hphRHx86 jones]#
Cheers,
123forth
Bruce McFarling
> Isn't 'Jonesforth' the latest Public Domain Forth on the block? The
> implementation documents (embedded in the assembly source code) is
> very understandable and the words are SEEable.
Of course, its neither Forth-79, Forth-83 nor Forth-94, and a number
of the design choices are quite idiosyncratic ... more designing the
forth for the benefit of the implementer than for the benefit of using
it to do something.
It seems that the online documentation that tries to explain how it
all goes together as clearly as possible is a factor in getting
attention for an implementation over and above the characteristics of
the implementation.
rickman
>
> On Mar 14, 4:48 pm, jacko <jackokr...@gmail.com> wrote:
>
> > I am playing with f83 for CP/M at the moment on a SIMcoupe emulator,
> > using Pro-Dos CP/M. It is quite small considering the features. It is
> > still larger than Jupiter ACE forth though, which I think is 8K,
> > although has a non standard DEFINER DOES> and COMPILER RUNS>. I thinks
> > its to do with SEE (implicit word not defined) being an exact recall
> > for edit. Full Z80 source for Jupiter ACE is available.
>
> > Cheers Jacko
>
> >http://forum.nibzx.co.uk
>
> Thanks for the tips, but isn't it about time we stop going back to the
> future to look for really small and understandable Forth. Even with
> time sharing, rental time on time machine is pretty expensive ;-)
Aren't time machines infinitely inexpensive? When you have completed
your use of the machine, can't you send it back in time to whatever
time it is needed next? I guess there is still wear and tear... or
does a time machine ever wear out? Somehow it seems like it should be
impervious to time passing.
Rick
Josh Grams
<ed4705d8-5b6f-4030...@g4g2000yqa.googlegroups.com>
My observation has been that a substantial fraction of the hobbyists who
discover Forth aren't particularly interested in learning to use the
language, but are merely attracted by the property that a Forth system
can be small enough that one person can easily understand the whole
thing.
I keep thinking it would be a nice community service to sit down for a
day or two and run up a simple generic system emphasizing the basic
model behind Forth-94: a stack-based virtual machine, an interpreter
which parses line-by-line and word-by-word, and an associative array
mapping names to behaviors (two behviors per name). Factor out the
back-end so you can build with STC/DTC/ITC VMs, various dictionary
models, and so on. It could let those folks see how a system can fit
together, but with more emphasis on the "fitting together" and less on
the quirks of particular implementation methods.
I even wrote an outline for it once. But so far I always seem to have
more interesting things to do with my time than writing yet another toy
Forth system...
--Josh
Bruce McFarling
> I keep thinking it would be a nice community service to sit down for a
> day or two and run up a simple generic system emphasizing the basic
> model behind Forth-94: a stack-based virtual machine, an interpreter
> which parses line-by-line and word-by-word, and an associative array
> mapping names to behaviors (two behviors per name). Factor out the
> back-end so you can build with STC/DTC/ITC VMs, various dictionary
> models, and so on. It could let those folks see how a system can fit
> together, but with more emphasis on the "fitting together" and less on
> the quirks of particular implementation methods.
It would even be of general use in bringing up a Forth-94 system
quickly if it was divided into a minimal Forth that only enough to get
to loading the file that had the rest of the system in Forth.
That is, rather than the fig-Forth / eForth model of having the
complete starting system defined in assembler, define a sub-Forth-94
system that builds the rest of its system by extension based on a
script handed to it on the system command line when it is launched. If
there is a second filename there, it then loads that filename, if not
it starts up at the keyboard.
Based on working with modifying the MAF model to a different threading
model, it needs:
* ALLOT HERE EXIT ' , COMPILE,
* a word to create a colon definition header
* a word to create the header for words that will have <Variable>
<Constant> <Create>
* a word to "Reveal" the definition in the current dictionary or
defined "Head"/"Latest" variables used by the interpreter and header
definers
* <Branch> and <0Branch>
* <do> <?do> <loop> etc.
* a starter interpreter that has \ and decimal numbers at least, where
the Forth-94 interpreter/compiler can be defined in the load
script ... so that at some point in the script the Forth-94
interpreter/compiler is called and from that point on the script looks
like normal Forth.
* and a starting set of arithmatic and logic words.
The system could be called SeedForth, with the initial load defined in
assembler or C or whatever as the Kernel and the script that is run
with the Kernel as the Hull.
jacko
primitive. So I am starting a new MIDP 2.0 implementation (Maybe MIDP
1). Called ACE B FORTH. New Java SDK downloaded, mostly Ace forth,
without some specific words and a few more added. General way of entry
kept. All non CALL using programs will be compatible with minor
modifications.
Try this on a new forth you find. OPEN-ME-SOME-BLOCKS-OR-FILES-YOU-
UNDOCUMENTED-THING and then see if it would be suitable for mobile
systems with limited file access. MID4th was such a botch of ANS that
I would rather go a bit retrograde for now.
Cheers Jacko
jacko
No C, C@ or C! as fully cell aligned
No BLOAD BSAVE BVERIFY VERIFY IN OUT
The PLOT y range will be extended
No SLOW FAST CALL
Will add MIDI URL MEDIA
And internet server SLOAD SSAVE
Will add HIDE to hide some words of implementation and prevent editing
by word not found
I may even add full bitmap graphics later. Have I missed any feature?
I don't mind the input, I don't mind it being a toy forth, I don't see
how a beginner would get passed knowing about many things outside
forth before reaching forth without keeping it simple stupid. But
great inclusions are worth having.
This is woth doing. Creation of a simple forth for mobile devices
would be good for learning, especially when many free books on jupiter
forth are available.
Cheers Jacko
123forth
>
> My observation has been that a substantial fraction of the hobbyists who
> discover Forth aren't particularly interested in learning to use the
> language, but are merely attracted by the property that a Forth system
> can be small enough that one person can easily understand the whole
> thing.
>
As a matter of fact, Forth does not directly put the bread and butter
on the table but it's been very helpful in taking me to the
supermarket.
> I keep thinking it would be a nice community service to sit down for a
> day or two and run up a simple generic system emphasizing the basic
> model behind Forth-94: a stack-based virtual machine, an interpreter
> which parses line-by-line and word-by-word, and an associative array
> mapping names to behaviors (two behviors per name). Factor out the
I really hope your thought will somehow materialize.
> back-end so you can build with STC/DTC/ITC VMs, various dictionary
> models, and so on. It could let those folks see how a system can fit
> together, but with more emphasis on the "fitting together" and less on
> the quirks of particular implementation methods.
>
and the high level colon words should behave the same way?
I tried 'see see' on a Forth system with 4 diffrent models: itc, idtc,
fast and stc (?)
(Gforth-itc + Gforth-fast + Gforth-stc?)
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
see see
: see
parse-name find-name dup 0=
IF drop -13 throw
THEN
name-see ; ok
(Gforth-ditc)
bash-3.2$ ./gforth-ditc
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
see see
: see
:1: Invalid memory address
see >>>see<<<
Backtrace:
There must be something wrong on my machine.
I tried to drill down from "see see" and gave up when I reached "see
xt-see":
see xt-see
: xt-see
cr c-init dup >does-code
IF seedoes EXIT
THEN
dup xtprim?
IF seecode EXIT
THEN
dup @ docon: over =
IF drop seecon
ELSE dovalue: over =
IF drop seevalue
ELSE docol: over =
IF drop seecol
ELSE dovar: over =
IF drop seevar
ELSE douser: over =
IF drop seeuser
ELSE dodefer: over =
IF drop seedefer
ELSE dofield: over =
IF drop seefield
ELSE over over =
IF drop seecode
ELSE over 8 +
over =
IF drop
seecode
ELSE 2drop
IF c"
unknown
word type
"
c(abort"
)
THEN
drop
THEN
THEN
THEN
THEN
THEN
THEN
THEN
THEN
THEN ; ok
> I even wrote an outline for it once. But so far I always seem to have
> more interesting things to do with my time than writing yet another toy
> Forth system...
>
> --Josh
To me, designing a good educational toy for the toddlers is much
harder than putting together a curriculum for a University student.
Cheers,
123forth
Andrew Haley
>
> My observation has been that a substantial fraction of the hobbyists who
> discover Forth aren't particularly interested in learning to use the
> language, but are merely attracted by the property that a Forth system
> can be small enough that one person can easily understand the whole
> thing.
I think that's true. It's a fantastically useful property.
> I keep thinking it would be a nice community service to sit down for a
> day or two and run up a simple generic system emphasizing the basic
> model behind Forth-94: a stack-based virtual machine, an interpreter
> which parses line-by-line and word-by-word, and an associative array
> mapping names to behaviors (two behviors per name).
It really helps to get the names of things right: it's a dictionary
that maps words onto definitions.
Andrew.
jacko
A see-cfa variety case-of?? There isn't anyway arround this. Reducing
the cfa types just makes the case smaller. Even having everthing like
(:) there is still an initial compiled word in a definition e.g. LIT-
EXIT for constants, which needs to be checked to produce the, as
entered, SEE listing. For IF THEN etcetra, the compiled 0BRANCH or
(IF) needs to be decoded differently. This is why COMPILER RUNS> is a
good idea. Knowing that the word being 'seen' is a compiler definition
allows simple display of the word. e.g. 2 ( OR 1 CELL ) COMPILER IF
HERE 0 , ( MARKER ) RUNS> @ >IP ; can display IF and skip the branch
address. The -1 COMPILER ." .... ; would be most common so defaulting
to string with " termination display is best. Otherwise a COMPILER ...
RUNS> ... DISPLAYS> ... ; would be needed, for such infrequent usage.
This case decision is done in most languages but is implicit and
hidden, with the listing mainly done via a plain text file, so the
case is for run time type usage. e.g. BASIC and $ ! % variable types.
SEE could be extended to machine code dissembly, with auto labels, but
such a thing is not compact, and would not be good in general for
education. An extended version of SEE say called EXPLAIN where words
are expanded down to primitives in terms of an execution chain might
be what your after.
Cheers Jacko
MarkWills
> discover Forth aren't particularly interested in learning to use the
> language, but are merely attracted by the property that a Forth system
> can be small enough that one person can easily understand the whole
> thing.
It's true. But I would not waste energy on writing articles/tutorials/
software for that segment of the Forth 'market' because their interest
will be fleeting, and once they have written their Forth (or, in
truth, once they have written all the easy bits and not bothered doing
the hard bits) they will move on.
Of course, some, (perhaps like me?) will turn out to be a bit more
hard-core. I became interested in Forth when I wanted a language to
bootstrap a homebrew hardware project I was building. My goal was
simply to understand Forth enough to write one to boot my vero-board
project.
Of course, I found myself "drawn in" to Forth, and the more I read
about it's philosophy, the more I agreed with it. It was kind of akin
to suddenly discovering a political party, who's every view and policy
was in complete agreement with your own. Philosophical values such as
advocating simplicty instead of the 'catch all' bullshit that you
often see built into 'production' code was common sense to me, but
like a breath of fresh air to see someone else advocating it.
Then I began to understand how Forth actually *works* and it was a
real *wow* moment. The beauty of it. Perhaps Elizabeth Rather and
others over the years had a similar feeling when the penny dropped and
they 'got it'. I've never had so much fun programming than I have with
Forth. I don't know how many there are like me, but I, and people such
as myself would probably be your ideal 'market'!
However, advice given on this group previously is very good advice
indeed: It's easy to understand how Forth works, but it doesn't mean
you can program Forth ;-) Probably better to study it and use a
production Forth system first. Don't jump in feet first, like I did!
Regards
Mark
Andrew Haley
> Then I began to understand how Forth actually *works* and it was a
> real *wow* moment. The beauty of it. Perhaps Elizabeth Rather and
> others over the years had a similar feeling when the penny dropped and
> they 'got it'.
I'm sure that's true. I suspect, however, that some never 'get it'!
> I've never had so much fun programming than I have with Forth. I
> don't know how many there are like me, but I, and people such as
> myself would probably be your ideal 'market'!
>
> However, advice given on this group previously is very good advice
> indeed: It's easy to understand how Forth works, but it doesn't mean
> you can program Forth ;-)
It takes a little time. I don't think Forth is unusual in this
respect.
Andrew.
Josh Grams
> Josh Grams <jo...@qualdan.com> wrote:
>>
>> the property that a Forth system can be small enough that one person
>> can easily understand the whole thing.
>
Why? I can understand that it's an interesting property, and it's fun.
But I haven't read or experienced anything that suggests that it is a
property that has much practical value, unless you're trying to
bootstrap development for a new system. And most beginners aren't in
that situation at all.
>> an associative array mapping names to behaviors (two behaviors per
>> name).
>
> It really helps to get the names of things right: it's a dictionary
> that maps words onto definitions.
Well, sure. But those are Forth terms, mostly. I thought it would be
better to introduce the concept in words that people might already know,
and *then* define the Forth terms and use them consistently in the rest
of the document.
--Josh
Anton Ertl
>I tried 'see see' on a Forth system with 4 diffrent models: itc, idtc,
>fast and stc (?)
The executable "gforth" uses the same execution model as gforth-fast:
primitive-centric hybrid direct/indirect threaded code with dynamic
superinstructions (plus static superinstructions and multi-state stack
caching for gforth-fast); it's just intended to give better error
messages for debugging, so it disables some optimizations, and also
does more bookkeeping elsewhere, resulting in slower speed.
>(Gforth-ditc)
Gforth-ditc is only intended to be used for creating images like gforth.fi
>bash-3.2$ ./gforth-ditc
>Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
>Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>Type `bye' to exit
>see see
>: see
>:1: Invalid memory address
>see >>>see<<<
>Backtrace:
>
>There must be something wrong on my machine.
No, the decompiler apparently has not been prepared to work on
gforth-ditc; the same happens on my machine. Since decompiling is not
something one usually does when creating an image, we will probably
not fix this problem.
>I tried to drill down from "see see" and gave up when I reached "see
>xt-see":
>
>see xt-see
>: xt-see
> cr c-init dup >does-code
> IF seedoes EXIT
> THEN
> dup xtprim?
> IF seecode EXIT
> THEN
> dup @ docon: over =3D
> IF drop seecon
> ELSE dovalue: over =3D
> IF drop seevalue
> ELSE docol: over =3D
> IF drop seecol
> ELSE dovar: over =3D
...
That's what a CASE construct decompiles to.
- 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 2009: http://www.euroforth.org/ef09/
Andrew Haley
> Andrew Haley wrote:
>> Josh Grams <jo...@qualdan.com> wrote:
>>>
>>> the property that a Forth system can be small enough that one person
>>> can easily understand the whole thing.
>>
>> It's a fantastically useful property.
>
> Why? I can understand that it's an interesting property, and it's fun.
It's a bit like anything else in life: if you have an accurate mental
model of what's going on you make better decisions. Consider driving
a car, for example.
The human mind likes to make up "just so" stories about things: I've
seen some interesting but gloriously inaccurate theories about how C
and Java implementations work, for example. Untrue beliefs hurt
because they cause people to make bad decisions.
Also, knowledge of the system you're using is tremendously empowering
because you can change it. For example, I've seen plenty of cases
where tweaks were made in a Forth system to do things like tracing,
profiling. I've converted the threading model to make code more
compact when a program wouldn't fit into ROM. I'm sure we could
collect quite a list! This sort of thing can make the difference
between success and disaster in a project.
>>> an associative array mapping names to behaviors (two behaviors per
>>> name).
>>
>> It really helps to get the names of things right: it's a dictionary
>> that maps words onto definitions.
>
> Well, sure. But those are Forth terms, mostly.
That's fair enough. I have seen the term "dictionary" used with this
meaning outside Forth, but I suppose "associative array" is more
common ATM. I always preferred the simple "map" or "mapping".
Andrew.
123forth
On Mar 18, 9:26 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
>
> The executable "gforth" uses the same execution model as gforth-fast:
> primitive-centric hybrid direct/indirect threaded code with dynamic
> superinstructions (plus static superinstructions and multi-state stack
> caching for gforth-fast); it's just intended to give better error
> messages for debugging, so it disables some optimizations, and also
> does more bookkeeping elsewhere, resulting in slower speed.
>
Thanks for the explanation.
> >(Gforth-ditc)
>
> Gforth-ditc is only intended to be used for creating images like gforth.fi
>
I've been trying to find out if other gforth's (besides ditc) can
create these images as well, if not, what makes ditc so special,
without success.
Has anyone tried it.
Cheers,
123forth
Anton Ertl
>Hi,
>
>
>On Mar 18, 9:26=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> Gforth-ditc is only intended to be used for creating images like gforth.f=
>i
>>
>
>I've been trying to find out if other gforth's (besides ditc) can
>create these images as well, if not, what makes ditc so special,
>without success.
You can create an image with SAVESYSTEM, but at best this will only
work with the engine (gforth, gforth-fast, etc.) that you used for
creating the image. And even that won't work if dynamic
superinstructions are used (which is usually the default) or if the OS
uses address space randomization (which many Linux distributions do by
default these days).
In order to get a relocatable image, Gforth (in particular the
gforthmi script) creates two such non-relocatable images where the
data lies at different places and where the "code addresses" point to
different places. Then we compare these two images and create
relocation information for a relocatable image.
In order to guarantee that the "code addresses" point to different
places, and in a way that lets us know where they are intended to
point to, we don't let them point into code at all, but to an array of
real code addresses. I.e., we use doubly-indirect threaded code.
123forth
wrote:
> >> Gforth-ditc is only intended to be used for creating images like gforth.f=
> >i
>
>
> You can create an image with SAVESYSTEM, but at best this will only
> work with the engine (gforth, gforth-fast, etc.) that you used for
[SNIP]
>
> In order to guarantee that the "code addresses" point to different
> places, and in a way that lets us know where they are intended to
> point to, we don't let them point into code at all, but to an array of
> real code addresses. I.e., we use doubly-indirect threaded code.
>
> - anton
That's very enlightening, many thanks.
123forth.
Albert van der Horst
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>123forth <hohoa...@gmail.com> writes:
>>Hi,
>>
>>
>>On Mar 18, 9:26=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>>wrote:
>>> Gforth-ditc is only intended to be used for creating images like gforth.f=
>>i
>>>
>>
>>I've been trying to find out if other gforth's (besides ditc) can
>>create these images as well, if not, what makes ditc so special,
>>without success.
>
>You can create an image with SAVESYSTEM, but at best this will only
>work with the engine (gforth, gforth-fast, etc.) that you used for
>creating the image. And even that won't work if dynamic
>superinstructions are used (which is usually the default) or if the OS
>uses address space randomization (which many Linux distributions do by
>default these days).
Does that mean that in practice you can't use gforth to
make a debian package with a useful program (say OCR)
that will run on all systems where gforth is installed?
That is in the documentation is about OCR.
<SNIP>
>- anton
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Anton Ertl
[SAVESYSTEM limitations]
>Does that mean that in practice you can't use gforth to
>make a debian package with a useful program (say OCR)
>that will run on all systems where gforth is installed?
My recommendation for packaging such a program would be to package the
Forth source file. Gforth compiles fast enough, no need to bother
with images.
However, if you want to distribute an image, you can do that, too.
Just create the image with gforthmi, and it won't have any of the
limitations of a SAVESYSTEM-generated image.
Gforthmi-generated images still are for a particular cell size and
byte order, and (less critical) they may contain a disassembler and
assembler for a particular architecture, so they won't run on all
systems where Gforth is installed; instead, you will create a
different package for each architecture, as is customary for binary
packages.
The package (whether it contains source code or an image) would also
declare a dependency on the gforth package, so installing the package
will install Gforth automatically.
>That is in the documentation is about OCR.
?