JonesForth queries
Richard Russell
Windows' rather than run directly from the OS (it's not as crazy as it
first sounds; the BBC BASIC wrapper gives Forth the ability to output
graphics simply by EMITting 'VDU sequences').
I'm aware that there are mixed feelings about JonesForth, but I
selected it because I wanted a 'free' 32-bit assembler implementation.
My first query concerns this comment that I found on the web: "there’s
an error in Jones Forth. The implementation of ROT and -ROT are
reversed". Can anybody confirm whether that's still the case in the
latest version (45)?
The second query concerns the JonesForth syntax for CREATE which seems
to be different from examples I've seen elsewhere. Is this something
I need to worry about (excuse what is no doubt a naive question from a
non-Forth user)?
Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
Coos Haak
<snip>
> My first query concerns this comment that I found on the web: "thereοΏ½s
> an error in Jones Forth. The implementation of ROT and -ROT are
> reversed". Can anybody confirm whether that's still the case in the
> latest version (45)?
>
That's simple:
11 22 33 ROT . . . 11 33 22 ok
11 22 33 -ROT . . . 22 11 33 ok
> The second query concerns the JonesForth syntax for CREATE which seems
> to be different from examples I've seen elsewhere. Is this something
> I need to worry about (excuse what is no doubt a naive question from a
> non-Forth user)?
>
Can't answer that. Maybe Jones Forth is based on Figforth. CREATE was
quite different from the current implementations.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Josh Grams
> The second query concerns the JonesForth syntax for CREATE which seems
> to be different from examples I've seen elsewhere. Is this something
> I need to worry about (excuse what is no doubt a naive question from a
> non-Forth user)?
I would. :) It's not what Forth users are going to expect it to be...
At least name it something different. Maybe "NAME," or "HEADER" or
"DEFINE" or something?
IIRC there was a fairly recent discussion here with code for a standard
CREATE/DOES> for Jonesforth.
--Josh
MarkWills
> That's simple:
> 11 22 33 ROT . . . 11 33 22 ok
> 11 22 33 -ROT . . . 22 11 33 ok
>
You sure Coos?
I think it should be:
11 22 33 rot .s <3> 22 33 11 ok
11 22 33 -rot .s <3> 33 11 22 ok
Richard Russell
Either way JonesForth is wrong:
11 22 33 ROT . . .
22 11 33
11 22 33 -ROT . . .
11 33 22
I'm puzzled that it got as far as version 45 without this being fixed!
Richard Russell
> IIRC there was a fairly recent discussion here with code for a standard
> CREATE/DOES> for Jonesforth.
I found a JonesForth implementation for <BUILDS ... DOES> but CREATE
wasn't altered.
Paul E Bennett
> Either way JonesForth is wrong:
>
> 11 22 33 ROT . . .
> 22 11 33
> 11 22 33 -ROT . . .
> 11 33 22
From that they are reversed.
Correctly they should be:-
11 22 33 ROT . . .
11 33 22
11 22 33 -ROT . . .
22 11 33
A simple re-definition should correct each of these.
--
********************************************************************
Paul E. Bennett...............<email://Paul_E....@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Doug Hoffman
Coos had it right, and so do you. You simply displayed the results
"backwards" from the way Coos displayed them.
-Doug
Andrew Haley
> Richard Russell wrote:
> > The second query concerns the JonesForth syntax for CREATE which seems
> > to be different from examples I've seen elsewhere. Is this something
> > I need to worry about (excuse what is no doubt a naive question from a
> > non-Forth user)?
> I would. :) It's not what Forth users are going to expect it to be...
Yes. JonesForth is different from standard Forth in many ways, and
IMO many of these differences are pointless.
> At least name it something different. Maybe "NAME," or "HEADER" or
> "DEFINE" or something?
> IIRC there was a fairly recent discussion here with code for a standard
> CREATE/DOES> for Jonesforth.
Indeed. Be aware that there were two implementations of DOES>, and
only one of them worked. That was mine. :-)
Andrew.
Coos Haak
No, I used three dots.
.S might be not available everywhere ;-)
Richard Russell
wrote:
> JonesForth is different from standard Forth in many ways, and
> IMO many of these differences are pointless.
Do you consider it a lost cause, or could most of the shortcomings be
fixed without too much effort (given that it is so well documented)?
> Indeed. Be aware that there were two implementations of DOES>, and
> only one of them worked. That was mine. :-)
Any chance of a link? I'm not certain I've used the right one!
Do you believe the version listed here works (it's not the one I used,
but it's a little simpler):
http://www.lisphacker.com/temp/fixes.f
Elizabeth D Rather
> Op Sun, 6 Sep 2009 01:09:04 -0700 (PDT) schreef MarkWills:
>
>>> That's simple:
>>> 11 22 33 ROT . . . 11 33 22 ok
>>> 11 22 33 -ROT . . . 22 11 33 ok
>>>
>> You sure Coos?
>>
>> I think it should be:
>>
>> 11 22 33 rot .s <3> 22 33 11 ok
>> 11 22 33 -rot .s <3> 33 11 22 ok
>
> No, I used three dots.
> .S might be not available everywhere ;-)
It's in the TOOLS wordset, not CORE, but don't most systems have it?
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Andrew Haley
> On 6 Sep, 12:23, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
> > JonesForth is different from standard Forth in many ways, and
> > IMO many of these differences are pointless.
> Do you consider it a lost cause, or could most of the shortcomings
> be fixed without too much effort (given that it is so well
> documented)?
It's pretty hopeless IMO.
> > Indeed. ?Be aware that there were two implementations of DOES>, and
> > only one of them worked. ?That was mine. ?:-)
> Any chance of a link? I'm not certain I've used the right one!
Like this:
Assembly code file:
_does:
PUSHRSP %esi // push %esi on to the return stack
pop %esi // point %esi at the does> part
add $4, %eax // push the CFA of the defined word
push %eax
NEXT
defconst "(DOES)", 6,,dodoes,_does
Forth file:
HEX
: DODOES R> LATEST @ >CFA ! ;
: <BUILDS WORD CREATE 0 , ;
: DOES> ( - a) ' DODOES , E8 C, (DOES) HERE @ 4+ - , ;
IMMEDIATE
DECIMAL
Test it:
: CST <BUILDS , DOES> @ ;
9 CST FOO
FOO .
9
> Do you believe the version listed here works (it's not the one I used,
> but it's a little simpler):
> http://www.lisphacker.com/temp/fixes.f
That looks similar, but it's a bit more complicated and wastes a cell
in every child of DOES> . It looks to me like it's based on the old
fig-FORTH way of doing things. Either would probably work, but I know
that I tested mine!
Andrew.
[1] http://groups.google.co.uk/group/comp.lang.forth/msg/eef64bc7e57e52b4?hl=en
and
http://groups.google.co.uk/group/comp.lang.forth/msg/af27dd568fd60752?hl=en
Albert van der Horst
Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>Richard Russell <ne...@rtrussell.co.uk> wrote:
>> On 6 Sep, 12:23, Andrew Haley <andre...@littlepinkcloud.invalid>
>> wrote:
>> > JonesForth is different from standard Forth in many ways, and
>> > IMO many of these differences are pointless.
>
>> Do you consider it a lost cause, or could most of the shortcomings
>> be fixed without too much effort (given that it is so well
>> documented)?
>
>It's pretty hopeless IMO.
You mean in view of the assembler code under?
Don't despair. It is not half as difficult as it looks.
>
>> > Indeed. ?Be aware that there were two implementations of DOES>, and
>> > only one of them worked. ?That was mine. ?:-)
>
>> Any chance of a link? I'm not certain I've used the right one!
>
>Like this:
>
>Assembly code file:
>
>_does:
> PUSHRSP %esi // push %esi on to the return stack
> pop %esi // point %esi at the does> part
> add $4, %eax // push the CFA of the defined word
> push %eax
> NEXT
ciforth went through a transition to ISO (2001 jan)
This is documented (took more than 100 steps) in the RCS
file that is available as the generic ciforth system.
(I kept the regression test succeeding throughout the changes.)
The transition in ciforth from figforth BUILDS> to iso DOES>
is between version 3.63 and 3.64. As far as assembly code is
concerned 6 lines are changed.
Both versions can be checked out, build and experimented with.
With this example in hand an assembler programmer should not be
deterred. (Those interested can have the < 4 Mbyte zipped archive.
Mail me.)
The important issue is that DOES> wants to change a field,
that cannot be identified with one of the familiar fields
in the header. If this design issue is not solved, all
progress is impeded.
Groetjes Albert
P.S. I have no opinion whether it is a good idea to ISO-fy
Jonesforth. Just trying to help.
--
--
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
Andrew Haley
> In article <SvedndYpX7tiUjnX...@supernews.com>,
> Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
> >Richard Russell <ne...@rtrussell.co.uk> wrote:
> >> On 6 Sep, 12:23, Andrew Haley <andre...@littlepinkcloud.invalid>
> >> wrote:
> >> > JonesForth is different from standard Forth in many ways, and
> >> > IMO many of these differences are pointless.
> >
> >> Do you consider it a lost cause, or could most of the shortcomings
> >> be fixed without too much effort (given that it is so well
> >> documented)?
> >
> >It's pretty hopeless IMO.
> You mean in view of the assembler code under?
> Don't despair. It is not half as difficult as it looks.
I think we must agree to differ.
> >Assembly code file:
> >
> >_does:
> > PUSHRSP %esi // push %esi on to the return stack
> > pop %esi // point %esi at the does> part
> > add $4, %eax // push the CFA of the defined word
> > push %eax
> > NEXT
> ciforth went through a transition to ISO (2001 jan)
> This is documented (took more than 100 steps) in the RCS
> file that is available as the generic ciforth system.
> (I kept the regression test succeeding throughout the changes.)
> The transition in ciforth from figforth BUILDS> to iso DOES>
> is between version 3.63 and 3.64. As far as assembly code is
> concerned 6 lines are changed.
Sure, but JonesForth is a very, very long way from fig-FORTH.
> The important issue is that DOES> wants to change a field,
> that cannot be identified with one of the familiar fields
> in the header. If this design issue is not solved, all
> progress is impeded.
I'm sorry, I have no idea what you're talking about. DOES> works, so
what more is there to do?
Andrew.
Richard Russell
wrote:
> I'm sorry, I have no idea what you're talking about. DOES> works, so
> what more is there to do?
Your code for <BUILDS DOES> does seem to work, but it's messy
(especially the embedded E8 opcode, which requires switching to HEX).
I can't help feeling there must be an easier way to do it, maybe
something more like the code at 'lisphacker' which, contrary to your
comment, is actually considerably simpler than yours.
Unfortunately, I can't make it work (there's something fundamentally
different between his Jonesforth and mine, because neither of his
Forth implementations of VARIABLE work here).
Andrew Haley
> On 7 Sep, 22:01, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
> > I'm sorry, I have no idea what you're talking about. DOES> works,
> > so what more is there to do?
> Your code for <BUILDS DOES> does seem to work, but it's messy
> (especially the embedded E8 opcode, which requires switching to
> HEX).
Messy? Messy! I think it's beautiful. What on Earth is wrong with
HEX? This is Forth. :-)
> I can't help feeling there must be an easier way to do it, maybe
> something more like the code at 'lisphacker' which, contrary to your
> comment, is actually considerably simpler than yours.
Oh, come on now. It uses an extra cell and an extra level of
indirection, so I don't see how it can possibly be considered simpler.
A pointer from the code field directly to a jsr instruction in the
defining word has been standard in ITC Forths since about 1980, when
it was invented to replace the double indirection that was used in
fig-FORTH.
> Unfortunately, I can't make it work (there's something fundamentally
> different between his Jonesforth and mine, because neither of his
> Forth implementations of VARIABLE work here).
Heh. Well, mine works. So there...
Andrew.
Richard Russell
wrote:
> What on Earth is wrong with HEX? This is Forth. :-)
There's nothing wrong with HEX, as such, but I'd argue you really
ought to save and restore the current BASE rather than to set it
unconditionally to DECIMAL on exit from your code. Since the only
numeric constant in the 'lisphacker' version is zero, it's independent
of BASE.
> Oh, come on now. It uses an extra cell and an extra level of
> indirection, so I don't see how it can possibly be considered simpler.
It's simpler in terms of code size. The amount of assembler code in
each is virtually the same, but when it comes to the Forth part yours
defines three new words (DODOES, <BUILDS, DOES>) whereas his defines
only two (<BUILDS and DOES>). It's an admittedly crude basis for
comparison, but the lengths of the .f files are 146 bytes for yours
and 70 bytes for his (comments deleted):
HEX
: DODOES R> LATEST @ >CFA ! ;
: <BUILDS WORD CREATE 0 , ;
: DOES> ' DODOES , E8 C, (DOES) HERE @ 4+ - , ;
IMMEDIATE
DECIMAL
versus:
: <BUILDS WORD CREATE dodoes , 0 , ;
: DOES> R> LATEST @ >DFA ! ;
(in his original, 'dodoes' is a variable and there's an additional @
in the Forth code; in mine I've made 'dodoes' a constant - like your
(DOES) - so the @ isn't required).
But unless I can make his work this is so much hot air. Using yours
is definitely my fallback position.
Albert van der Horst
Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
<SNIP>
>
>A pointer from the code field directly to a jsr instruction in the
>defining word has been standard in ITC Forths since about 1980, when
>it was invented to replace the double indirection that was used in
>fig-FORTH.
You mean the code field of an ITC word contains a jsr to a
defining word. The return address is left on the stack,
and this is interpreted as a data pointer.
This has the advantage that it is ITC, which is sometimes
slightly faster, and more compact, a great advantage in 16 bit
systems.
IMO it is an ugly hack, and considerably less clean, less simple
and harder to understand then DTC. It mixes data and code in
a messy way. It greatly restricts how headers can be laid out.
Its compactness is beaten by umbilical systems, and its speed
by native compilation.
>
>Andrew.
Groetjes Albert
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
> <SNIP>
> >
> >A pointer from the code field directly to a jsr instruction in the
> >defining word has been standard in ITC Forths since about 1980, when
> >it was invented to replace the double indirection that was used in
> >fig-FORTH.
> You mean the code field of an ITC word contains a jsr to a
> defining word.
No, I meant what I said. The code field contains a pointer, not an
instruction.
> The return address is left on the stack, and this is interpreted as
> a data pointer.
No, the return address points to threaded code, not to data.
> This has the advantage that it is ITC, which is sometimes slightly
> faster, and more compact, a great advantage in 16 bit systems.
> IMO it is an ugly hack, and considerably less clean, less simple and
> harder to understand then DTC. It mixes data and code in a messy
> way. It greatly restricts how headers can be laid out.
Sorry, what is "it" in this context?
Andrew.
Albert van der Horst
Richard Russell <ne...@rtrussell.co.uk> wrote:
<SNIP>
>
>HEX
>: DODOES R> LATEST @ >CFA ! ;
>: <BUILDS WORD CREATE 0 , ;
>: DOES> ' DODOES , E8 C, (DOES) HERE @ 4+ - , ;
A DOES> that allocates spaces is incompatible with ISO.
The standard allows DOES> to fill in a pointer, not more.
>IMMEDIATE
>DECIMAL
>
>versus:
>
>: <BUILDS WORD CREATE dodoes , 0 , ;
>: DOES> R> LATEST @ >DFA ! ;
>
>(in his original, 'dodoes' is a variable and there's an additional @
>in the Forth code; in mine I've made 'dodoes' a constant - like your
>(DOES) - so the @ isn't required).
>
>But unless I can make his work this is so much hot air. Using yours
>is definitely my fallback position.
You have now used up your data field to specify the dodoes action.
There is no way left to specify where the real data hangs out.
That is were the extra indirection was for.
As in
: >BODY >DFA @ \ Pointer to data of a created word.
CELL+ \ Skip over DOES> pointer
;
You could eliminate the @ action if you filled in a code field.
But then you would have DOES> working with assembler code, not
with high level code as is a consequence of the standard for
indirect threading.
>
>Richard.
Andrew Haley
> Richard Russell <ne...@rtrussell.co.uk> wrote:
> <SNIP>
> >
> >HEX
> >: DODOES R> LATEST @ >CFA ! ;
> >: <BUILDS WORD CREATE 0 , ;
> >: DOES> ' DODOES , E8 C, (DOES) HERE @ 4+ - , ;
> A DOES> that allocates spaces is incompatible with ISO.
> The standard allows DOES> to fill in a pointer, not more.
I think we must agree that, in the case of JonesForth, ISO is the
pinnacle of irrelevance! But yes, having the data somewhere other
than at the PFA is certainly an inconvenience.
Andrew.
Richard Russell
wrote:
> You have now used up your data field to specify the dodoes action.
> There is no way left to specify where the real data hangs out.
> That is were the extra indirection was for.
All I changed was:
[original]
VARIABLE dodoes
Value dodoes !
....
dodoes @
[modified]
Value CONSTANT dodoes
....
dodoes
So long as Value is 'read only' (it's a pointer to some assembler
code, so never changes) surely these are equivalent?
Richard.
http://www.rtrussell.co.uk/
Richard Russell
wrote:
> I think we must agree that, in the case of JonesForth, ISO is the
> pinnacle of irrelevance!
I still don't understand what makes Jonesforth so fundamentally
incompatible with ISO compliance. Can you explain in some more
detail?
Andrew Haley
> On 9 Sep, 10:56, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
> > I think we must agree that, in the case of JonesForth, ISO is the
> > pinnacle of irrelevance!
> I still don't understand what makes Jonesforth so fundamentally
> incompatible with ISO compliance. Can you explain in some more
> detail?
To do that I'd have to go through every word, one at a time. I
haven't checked it all, but wherever I looked I found non-standard
definitions. There's nothing wrong with that: it wasn't supposed to
be standard. So, it's not one specific thing, it's just that the
words are different.
Andrew.
Richard Russell
wrote:
> To do that I'd have to go through every word, one at a time. I
> haven't checked it all, but wherever I looked I found non-standard
> definitions. There's nothing wrong with that: it wasn't supposed to
> be standard. So, it's not one specific thing, it's just that the
> words are different.
Hmm. Changing a few word definitions to be compliant ought to be
pretty easy. I assumed you were referring to some deeper problem, for
example associated with the way the threaded code was structured, that
made ISO-compliance impossible without a complete re-write.
The only Jonesforth definitions I *know* to be non-standard are ALLOT,
CREATE, HERE and (of course) the reversed ROT and -ROT. I also know
that ROLL and DO...LOOP are missing (I've already added ROLL, and am
working on DO...LOOP at the moment). If there are any others you know
to be wrong please let me know.
Richard.
http://www.rtrussell.co.uk/
Andrew Haley
We've already talked about DOES>. Then there's WORD, NUMBER, FIND,
and ' : that's most of the text interpeter. And that's without even
looking at the part of the system written in Forth.
As I said, there's nothing wrong with being nonstandard, but if you
wanted a standard Forth, you wouldn't start from here.
Andrew.
Richard Russell
wrote:
> We've already talked about DOES>.
I thought that was resolved by your code!
> Then there's WORD, NUMBER, FIND, and '
It would be so much more helpful if you could tell me *what* is wrong
with them! :-)
> And that's without even looking at the part of the system
> written in Forth.
But that bit is probably easier to fix, if only by substituting
somebody else's Forth implementation of the word(s).
> As I said, there's nothing wrong with being nonstandard, but if you
> wanted a standard Forth, you wouldn't start from here.
I don't know of an alternative I could use. I need a hybrid 32-bit
assembler/Forth implementation (hopefully with most of it in Forth for
ease of porting) with licensing conditions that allow me to use it in
the way I want to.
Richard.
http://www.rtrussell.co.uk/
Andrew Haley
> On 9 Sep, 15:35, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
> > We've already talked about DOES>.
> I thought that was resolved by your code!
OK.
> >Then there's WORD, NUMBER, FIND, and '
> It would be so much more helpful if you could tell me *what* is wrong
> with them! :-)
It's all in the standard. WORD takes a delimiter, NUMBER handles
doubles as well as singles, FIND has a different arg list, and ' does
something totally different.
> > And that's without even looking at the part of the system
> > written in Forth.
> But that bit is probably easier to fix, if only by substituting
> somebody else's Forth implementation of the word(s).
> > As I said, there's nothing wrong with being nonstandard, but if you
> > wanted a standard Forth, you wouldn't start from here.
> I don't know of an alternative I could use. I need a hybrid 32-bit
> assembler/Forth implementation (hopefully with most of it in Forth
> for ease of porting) with licensing conditions that allow me to use
> it in the way I want to.
I think Jones started with LINA Forth
(http://home.hccnet.nl/a.w.m.van.der.horst/lina.html) by Albert van
der Horst. I reckon it may actually be easier to port, since stuff
like this, although it's in an assembler source file, is very
portable:
N_WITHIN:
.long 6
.ASCII "WITHIN"
.balign 4,0x90
WITHIN:
.long DOCOL
.long WITHIN+HEADSIZE
.long 0x0
.long TSTOR
.long N_WITHIN
.long 0
.long 0
.long OVER, LSUB, TOR
.long LSUB, FROMR
.long ULESS
.long SEMIS
I have no experience of LINA Forth, so I can't recommend it. I
believe Albert when he says it's standard, though.
Andrew.
Elizabeth D Rather
The problem is that the host of niggling differences between Jonesforth
and Standard Forth are going to be a continuing hassle whatever you do.
The published books on Forth, other tutorials such as the one with
gForth, code that's published here and elsewhere, all are likely to be
somewhat incompatible in ways that you'll keep discovering. And
attempting to fix it will be fraught with problems since (if there's any
internal consistency, which I assume there is) every change to be more
standard will cause a host of new bugs to appear in code that depends on
the non-standard behavior.
You do not specify what licensing conditions you require, but it seems
to me there are a lot of fairly standard implementations out there that
should be more useful to you.
Richard Russell
> You do not specify what licensing conditions you require, but it seems
> to me there are a lot of fairly standard implementations out there that
> should be more useful to you.
I've looked at ciForth, which is ISO-compliant and for which IA-32
assembler source code is available, but the licensing conditions
explicitly rule out its use as a "general purpose Forth system", which
is precisely what I want to create (not in competition with all the
others, but hosted in 'BBC BASIC for Windows' for use - principally -
by the BBC BASIC community).
In any case I don't require full ISO compliance (for example I'm
expecting it to be an integer-only Forth), just that it should be
reasonably standard, so that anybody experimenting with Forth for the
first time on that platform won't have to 'unlearn' anything if they
migrate.
This started off as a very interesting (and initially rewarding)
investigation into the possibility of using BBC BASIC and its
integrated IA-32 assembler as a way of implementing a simple Forth
system with graphical output capability (by means of BBC BASIC's
graphics drivers). It could have provided an incentive for BBC BASIC
programmers (of which there are many) to dabble with Forth in a
familiar environment and - who knows - become hooked.
Regrettably the comments made here (no doubt with the best of
intentions) have had a seriously demotivating effect.
Elizabeth D Rather
> On 9 Sep, 20:05, Elizabeth D Rather <erat...@forth.com> wrote:
>> You do not specify what licensing conditions you require, but it seems
>> to me there are a lot of fairly standard implementations out there that
>> should be more useful to you.
>
> I've looked at ciForth, which is ISO-compliant and for which IA-32
> assembler source code is available, but the licensing conditions
> explicitly rule out its use as a "general purpose Forth system", which
> is precisely what I want to create (not in competition with all the
> others, but hosted in 'BBC BASIC for Windows' for use - principally -
> by the BBC BASIC community).
You might explore privately with Albert van der Horst, the author of
ciforth, whether you can get permission to do this, providing that it's
restricted specifically to BBC BASIC for Windows (which I doubt
conflicts with his goals).
> In any case I don't require full ISO compliance (for example I'm
> expecting it to be an integer-only Forth), just that it should be
> reasonably standard, so that anybody experimenting with Forth for the
> first time on that platform won't have to 'unlearn' anything if they
> migrate.
Your system can certainly be "integer-only" and fully ISO compliant,
since the floating point wordset is entirely optional (as are many other
wordsets). But as far as the central CORE words are concerned, if they
don't comply with the standard this will certainly create for your users
the same difficulties I highlighted: incompatibility with published
books and tutorials, inability to use posted code, etc., not to mention
their ability to move easily to another version of Forth should they
wish to do so.
> This started off as a very interesting (and initially rewarding)
> investigation into the possibility of using BBC BASIC and its
> integrated IA-32 assembler as a way of implementing a simple Forth
> system with graphical output capability (by means of BBC BASIC's
> graphics drivers). It could have provided an incentive for BBC BASIC
> programmers (of which there are many) to dabble with Forth in a
> familiar environment and - who knows - become hooked.
That's a worthwhile goal, but in order to work it will really help to
adhere to the existing standards.
Ian Osgood
wrote:
> andhttp://groups.google.co.uk/group/comp.lang.forth/msg/af27dd568fd60752...
Just curious, I've heard a lot of people complain here about Jones/ANS
incompatibilities, with solutions. Has anyone sent patches to the
JonesForth maintainer? That seems to be the mantra of open source
projects like this: "patches gratefully accepted".
Ian
Richard Russell
> Just curious, I've heard a lot of people complain here about Jones/ANS
> incompatibilities, with solutions. Has anyone sent patches to the
> JonesForth maintainer? That seems to be the mantra of open source
> projects like this: "patches gratefully accepted".
I'm not sure that Richard Jones is receptive to such ideas. I have
emailed him about my recent work, and whilst he has expressed interest
in linking to it from his site, questions I've asked about the
compatibility issue have been completely ignored!
I'm not personally convinced that it would be as difficult to 'fix'
Jonesforth as has been suggested here. I accept that a change in one
place can have knock-on effects elsewhere, but I can go some way to
avoiding that by making the 'fixes' a post-processing exercise. For
example, ROT and -ROT are known to be reversed in Jonesforth;
correcting them 'at source' would require changing every subsequent
definition that uses them. But I don't need to do that; I can leave
them reversed, and then at the very end when all the derivative words
have been defined I can swap them (I think I can even do it in such a
way that SEE will actually show the 'corrected' definitions of words
using them!).
Similarly with the other non-standard words; I can leave them alone
whilst they are used in subsequent definitions and re-define them at
the very end. Slightly wasteful of dictionary space, but it would
work. Unfortunately in that case SEE wouldn't show a 'correct'
definition, which could be misleading, but I'd live with that.
However to attempt such a fix I would want to feel that I had the
support of the Forth community here. Unfortunately those in the best
position to provide help seem to have convinced themselves it's not
going to be successful.
Josh Grams
> On 9 Sep, 15:35, Andrew Haley wrote:
>
>> Then there's WORD, NUMBER, FIND, and '
>
> It would be so much more helpful if you could tell me *what* is wrong
> with them! :-)
If you're not interested in learning standard Forth, why should anyone
take you seriously when you say you want to implement a standard Forth
system? :-)
>> As I said, there's nothing wrong with being nonstandard, but if you
>> wanted a standard Forth, you wouldn't start from here.
>
> I don't know of an alternative I could use. I need a hybrid 32-bit
> assembler/Forth implementation (hopefully with most of it in Forth for
> ease of porting) with licensing conditions that allow me to use it in
> the way I want to.
What's wrong with eForth?
--Josh
Richard Russell
> If you're not interested in learning standard Forth, why should anyone
> take you seriously when you say you want to implement a standard Forth
> system? :-)
I don't understand the basis for that comment. I do have references
which tell me what those words do in 'standard' Forth, but I don't
know exactly what they do in Jonesforth (particularly the ones
implemented in assembler code). Although in principle I could rewrite
the faulty Jonesforth words from scratch, knowing the correct
definitions, it's much easier if I can make modifications to the
existing code based on *how* they differ. Since Andrew has evidently
already made the comparison, I don't think it's unreasonable to ask
for details.
> What's wrong with eForth?
I did look at that, but (as far as I can tell) it's 16-bit only (for
MS-DOS). I need a 32-bit version for Windows. If there is a 32-bit
version of eForth I'd certainly be interested to know.
Andrew Haley
> On 9 Sep, 20:05, Elizabeth D Rather <erat...@forth.com> wrote:
> > You do not specify what licensing conditions you require, but it
> > seems to me there are a lot of fairly standard implementations out
> > there that should be more useful to you.
> I've looked at ciForth, which is ISO-compliant and for which IA-32
> assembler source code is available, but the licensing conditions
> explicitly rule out its use as a "general purpose Forth system",
I don't understand this. I'm looking at lina now, and it seems to be
free software, as does ciforth. The licence seems to be GPL.
> which is precisely what I want to create (not in competition with
> all the others, but hosted in 'BBC BASIC for Windows' for use -
> principally - by the BBC BASIC community).
> In any case I don't require full ISO compliance (for example I'm
> expecting it to be an integer-only Forth), just that it should be
> reasonably standard, so that anybody experimenting with Forth for
> the first time on that platform won't have to 'unlearn' anything if
> they migrate.
> This started off as a very interesting (and initially rewarding)
> investigation into the possibility of using BBC BASIC and its
> integrated IA-32 assembler as a way of implementing a simple Forth
> system with graphical output capability (by means of BBC BASIC's
> graphics drivers). It could have provided an incentive for BBC
> BASIC programmers (of which there are many) to dabble with Forth in
> a familiar environment and - who knows - become hooked.
> Regrettably the comments made here (no doubt with the best of
> intentions) have had a seriously demotivating effect.
While I was figuring out how to write DOES> I found that JonesForth is
a tricky program to modify, so much so that I needed several tries to
get DOES> to work correctly, even though I'm an expert.
I think it would take me a couple of weeks full-time trawling through
JonesForth to fix the basics, with no guarantee that it would work
properly in the end. I may well be wrong about that, but I really
don't want to send you into a black hole.
Given that there is a standard Forth you can use, I simply can't
understand your motives for wanting to fix JonesForth.
Andrew.
P.M.Lawrence
.
.
> > What's wrong with eForth?
>
> I did look at that, but (as far as I can tell) it's 16-bit only (for
> MS-DOS). I need a 32-bit version for Windows. If there is a 32-bit
> version of eForth I'd certainly be interested to know.
A quick google gave me http://www.offete.com/eforth1.html (and
http://www.eforth.com.tw/academy-n/basic.htm which appears to be an
older, less complete version of it). It contains:-
68000 eForth, Richard H. Haskell [http://www.offete.com/files/
68eforth.zip]
A 32-bit 68000 implementation of eForth for the Motorola ECB Board.
Dr. Ting also contributed a file in that MASM is forced to produce
code
in the Motorola byte order.
32-Bit 8086 eForth, Rick VanNorman [http://www.offete.com/files/
eforth32.zip]
This is a 32 bit implementation of eForth for 80x8x family of
processors.
Much of the high level code are rewritten in assembly to improve the
performance. The object code is generated by a Forth metacompiler
(included), not from MASM source. Many other utilities are provided
and are good eForth coding examples.
.
.
.
32-Bit 386 eForth V.4.02, C. H. Ting [http://www.offete.com/files/
386EF402.ZIP]
This is a 32 bit implementation of eForth for 80386 in the protected
mode. It enters into protected mode directly under DOS through an
OK loader. Only COM1 is active at 9600 baud. Keyboard, screen and
disks are all silenced. You need another PC to serve as a host through
the serial port.
All those appear to be in the area you need, if you don't want to
adapt the 16 bit versions yourself. P.M.Lawrence.
Richard Russell
wrote:
> I don't understand this. I'm looking at lina now, and it seems to be
> free software, as does ciforth. The licence seems to be GPL.
This is what the ciforth documentation states (wina.pdf: Section 3.1
'Legalese'): 'The GPL is interpreted in the sense that a system based
on ciforth and intended to serve a particular purpose, that purpose
not being a "general purpose Forth system", is fair use of the system,
even if it could accomplish everything ciforth could, under the
condition that the ciforth it is based on is available in accordance
to the GPL rules, and this is made known to the user of the derived
system'.
I read that as meaning that a derived "general purpose Forth system",
such as I wish to produce, is not "fair use of" ciforth.
Another difficulty with the GPL is that it requires any derivative
work also to be made available *in its entirety* under the GPL (with
certain exceptions that I don't think apply here). If I create a
system by combining BBC BASIC (a commercial product) with ciforth
(GPL) then I can't do that, because the BBC BASIC part isn't 'free'
software.
> While I was figuring out how to write DOES> I found that JonesForth is
> a tricky program to modify, so much so that I needed several tries to
> get DOES> to work correctly, even though I'm an expert.
I really feel DOES> is a special case. Yesterday I implemented DO ...
LOOP (including +LOOP and the I and J words) in assembler and it
*worked first time*.
> Given that there is a standard Forth you can use, I simply can't
> understand your motives for wanting to fix JonesForth.
We haven't established that there is a "standard Forth" I can use.
Richard Russell
> A 32-bit 68000 implementation of eForth for the Motorola ECB Board.
68000, so of no relevance to Windows!
> 32-Bit 8086 eForth, Rick VanNorman [http://www.offete.com/files/
> eforth32.zip]
Although described as '32-bit' it isn't really (the clue is '8086').
All the code is actually 16-bits; I think it's just the data that's 32-
bits.
> 32-Bit 386 eForth V.4.02, C. H. Ting [http://www.offete.com/files/
> 386EF402.ZIP]
That seems to be real IA-32 code, so may be of interest.
Unfortunately I can't find any licensing conditions, without which I
wouldn't dare use it.
> All those appear to be in the area you need, if you don't want to
> adapt the 16 bit versions yourself.
Adapting 16-bit code would be an awkward and time-consuming task
(having already done it for BBC BASIC it's not something I want to
repeat!).
Richard.
http://www.rtrussell.co.uk/
P.M.Lawrence
> On 10 Sep, 12:45, "P.M.Lawrence" <pml540...@gmail.com> wrote:
> > A 32-bit 68000 implementation of eForth for the Motorola ECB Board.
>
> 68000, so of no relevance to Windows!
But, it offers a comparative guide to the adaptation needed.
>
> > 32-Bit 8086 eForth, Rick VanNorman [http://www.offete.com/files/
> > eforth32.zip]
>
> Although described as '32-bit' it isn't really (the clue is '8086').
> All the code is actually 16-bits; I think it's just the data that's 32-
> bits.
So? The code is only a little over 30 primitives. To the processor,
the secondaries ARE data. You can optimise some of those into
primitives at leisure later, as convenient.
>
> > 32-Bit 386 eForth V.4.02, C. H. Ting [http://www.offete.com/files/
> > 386EF402.ZIP]
>
> That seems to be real IA-32 code, so may be of interest.
> Unfortunately I can't find any licensing conditions, without which I
> wouldn't dare use it.
Try googling eforth license - among other things it leads to
http://www.forthos.org/license.html which states inter alia: "Parts of
ForthOS started from a software distribution known as eForth. The
distribution of eForth explicitly places it in the public domain, so
I'm assuming that ForthOS's use of parts of eForth do not encumber
ForthOS. I will update this license as needed if I receive feedback to
the contrary."
>
> > All those appear to be in the area you need, if you don't want to
> > adapt the 16 bit versions yourself.
>
> Adapting 16-bit code would be an awkward and time-consuming task
> (having already done it for BBC BASIC it's not something I want to
> repeat!).
Not with that few primitives - which is why Ting built it that way in
the first place, to ease implementation. P.M.Lawrence.
Andrew Haley
> On 10 Sep, 11:22, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
> > I don't understand this. I'm looking at lina now, and it seems to be
> > free software, as does ciforth. The licence seems to be GPL.
> This is what the ciforth documentation states (wina.pdf: Section 3.1
> 'Legalese'): 'The GPL is interpreted in the sense that a system
> based on ciforth and intended to serve a particular purpose, that
> purpose not being a "general purpose Forth system", is fair use of
> the system, even if it could accomplish everything ciforth could,
> under the condition that the ciforth it is based on is available in
> accordance to the GPL rules, and this is made known to the user of
> the derived system'.
Firstly, GPL is GPL. It's not possible to limit a user's rights under
the GPL. Secondly, this wordage seems to extend the user's rights,
not restrict them.
> I read that as meaning that a derived "general purpose Forth
> system", such as I wish to produce, is not "fair use of" ciforth.
I don't think it means that, but it'd be good to ask the author.
> Another difficulty with the GPL is that it requires any derivative
> work also to be made available *in its entirety* under the GPL (with
> certain exceptions that I don't think apply here).
That's right.
> If I create a system by combining BBC BASIC (a commercial product)
> with ciforth (GPL) then I can't do that, because the BBC BASIC part
> isn't 'free' software.
Sure. I have no idea why you'd want to combine BBC BASIC and Forth,
but I agree that could be a real problem.
> > While I was figuring out how to write DOES> I found that
> > JonesForth is a tricky program to modify, so much so that I needed
> > several tries to get DOES> to work correctly, even though I'm an
> > expert.
> I really feel DOES> is a special case. Yesterday I implemented DO ...
> LOOP (including +LOOP and the I and J words) in assembler and it
> *worked first time*.
> > Given that there is a standard Forth you can use, I simply can't
> > understand your motives for wanting to fix JonesForth.
> We haven't established that there is a "standard Forth" I can use.
Indeed, but we're now in the domain of the legal rather than the
technical, so I'll bow out.
Andrew.
Richard Russell
wrote:
> I have no idea why you'd want to combine BBC BASIC and Forth,
No idea? You could try reading the very first post of this thread:
"I've recently ported JonesForth to be hosted by 'BBC BASIC for
Windows' rather than run directly from the OS (it's not as crazy as it
first sounds; the BBC BASIC wrapper gives Forth the ability to output
graphics simply by EMITting 'VDU sequences')".
I would add that it also gives Forth access to a number of other BBC
BASIC features, such as being able to change the text font, load and
save BMPs, select the printer, play a MIDI file, program the function
keys etc. (for those who know BBC BASIC, Forth has access to 'VDU' and
'OSCLI').
> but I agree that could be a real problem.
We seem to have come full circle. It's *not* a problem if I use
Jonesforth, which is simply 'public domain' and not encumbered by the
GPL: "I grant any entity the right to use this work for any purpose,
without any conditions, unless such conditions are required by law".
Admittedly Richard Jones acknowledges that it "draws on the design of
LINA Forth", i.e. ciforth, so I'm assuming there's not enough
similarity to complicate the licensing issue (he obviously believes
that).
I'll continue my attempts to fix some of the non-standard features of
Jonesforth, and add some missing ones. I hope I may be allowed to
seek advice here from time to time, without getting mired in another
'you really ought not to be doing that' debate.
Andrew Haley
> On 10 Sep, 16:01, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
> > I have no idea why you'd want to combine BBC BASIC and Forth,
> No idea? You could try reading the very first post of this thread:
> "I've recently ported JonesForth to be hosted by 'BBC BASIC for
> Windows' rather than run directly from the OS
Sure, I have hosted a Forth on BASIC too. It's not a crazy idea at
all: the Forth could make of the I/O routines and the floating-point
library, for example. Very neat.
> (it's not as crazy as it first sounds; the BBC BASIC wrapper gives
> Forth the ability to output graphics simply by EMITting 'VDU
> sequences')".
Sure, but how does hosting Forth on BBC BASIC make it a combined work?
> I would add that it also gives Forth access to a number of other BBC
> BASIC features, such as being able to change the text font, load and
> save BMPs, select the printer, play a MIDI file, program the
> function keys etc. (for those who know BBC BASIC, Forth has access
> to 'VDU' and 'OSCLI').
But that's Forth making calls to BBC BASIC. It's not a combined work,
any more than hosting Forth on Windows makes the Forth a combined work
with Windows.
Andrew.
Andreas
> I'll continue my attempts to fix some of the non-standard features of
> Jonesforth, and add some missing ones. I hope I may be allowed to
> seek advice here from time to time, without getting mired in another
> 'you really ought not to be doing that' debate.
Please, it's all just well meant opinions. There are good arguments PRO
following the ANS, of course. OTOH standards can kill creativity. Thus
some "anarchism" (meant in a positive sense) can open new creative
paths, which is a good argument CONTRA standards. BTW you would not be
alone with such attitude.
For example, Forth had had the chance to become what Lua is today. But
Forth is rather stagnant. However this is not bad at all, concerning
maintainability of existing code. In your case there is no old codebase,
so feel free, try to make is simpler and better!
Andreas
Gerry
> On 10 Sep, 16:01, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>
[...]
>
> I'll continue my attempts to fix some of the non-standard features of
> Jonesforth, and add some missing ones. I hope I may be allowed to
> seek advice here from time to time, without getting mired in another
> 'you really ought not to be doing that' debate.
>
Yes there is sometimes a bit too much of that attitude in this group.
It sounds like carrying on as you are is your best bet, and, if you
make it available, we all gain. As we do if it increases interest in
Forth in the BBC Basic community.
I presume you are aware of the Hayes tester for ANS Forth compliance,
that will tell you which JonesForth words are non-compliant.
Gerry
Richard Russell
wrote:
> Sure, but how does hosting Forth on BBC BASIC make it a combined work?
Simple. BBC BASIC for Windows can 'compile' programs to create a self-
contained Windows executable (actually consisting of a run-time engine
- including the BASIC interpreter - plus a compressed version of the
BASIC program). That would be my preferred method for distributing
the Forth, so the executable would contain *both* BBC BASIC *and*
Forth.
> But that's Forth making calls to BBC BASIC. It's not a combined work,
> any more than hosting Forth on Windows makes the Forth a combined work
> with Windows.
Only because you don't actually 'combine' the Forth with Windows. As
stated above, I really *will* be combining BBC BASIC and Forth to make
a single application which appears to the user to be Forth with some
fancy I/O capabilities, but also contains a full copy of the BBC BASIC
interpreter (and, vitally, the BBC BASIC assembler which builds the
Forth from assembler source code at run time).
Albert van der Horst
Richard Russell <ne...@rtrussell.co.uk> wrote:
>On 9 Sep, 20:05, Elizabeth D Rather <erat...@forth.com> wrote:
>> You do not specify what licensing conditions you require, but it seems
>> to me there are a lot of fairly standard implementations out there that
>> should be more useful to you.
>
>I've looked at ciForth, which is ISO-compliant and for which IA-32
>assembler source code is available, but the licensing conditions
>explicitly rule out its use as a "general purpose Forth system", which
>is precisely what I want to create (not in competition with all the
>others, but hosted in 'BBC BASIC for Windows' for use - principally -
>by the BBC BASIC community).
The only restriction that applies is that you create a work based
on my GPL-ed code, and hence must supply the source with distribution.
If you distribute the Forth e.g. as an OCR system, not a
"general purpose Forth System", an exception to the GPL is explicitly
granted beforehand, i.e. you are not restricted.
If you are not satisfied with those condition, you still have the
option to negotiate with the author (me) to accomodate your special
situation. You're welcome.
<SNIP>
>
>Regrettably the comments made here (no doubt with the best of
>intentions) have had a seriously demotivating effect.
Turning a non-iso Forth into an iso Forth is certainly doable. I did
it. Creating a target test set that you want full filled is a good
starting point. Comments of Elizabeth Rather about legacy code do not
apply. (There is none.)
>
>Richard.
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
Albert van der Horst
Richard Russell <ne...@rtrussell.co.uk> wrote:
>On 9 Sep, 11:42, Albert van der Horst <alb...@spenarnc.xs4all.nl>
>wrote:
>> You have now used up your data field to specify the dodoes action.
>> There is no way left to specify where the real data hangs out.
>> That is were the extra indirection was for.
>
>All I changed was:
>
>[original]
>
> VARIABLE dodoes
> Value dodoes !
> ....
> dodoes @
>
>[modified]
>
> Value CONSTANT dodoes
> ....
> dodoes
>
>So long as Value is 'read only' (it's a pointer to some assembler
>code, so never changes) surely these are equivalent?
Okay that makes sense.
>
>Richard.
>http://www.rtrussell.co.uk/
Richard Russell
wrote:
> If you distribute the Forth e.g. as an OCR system, not a
> "general purpose Forth System", an exception to the GPL is explicitly
> granted beforehand, i.e. you are not restricted.
The text in wina.pdf could have been clearer (even after reading it
again). It talks about "fair use" in a context that implies it refers
to the GPL, but when I looked at the GPL that phrase never appears.
Certainly I read the caveat as trying to impose additional
restrictions (even though you can't) *not* granting additional rights!
Anyway, the die is cast. I'm sticking with Jonesforth because there
are absolutely no restrictions on its use.
Richard.
http://www.rtrussell.co.uk/
Albert van der Horst
Richard Russell <ne...@rtrussell.co.uk> wrote:
>On 10 Sep, 11:22, Andrew Haley <andre...@littlepinkcloud.invalid>
>wrote:
>> free software, as does ciforth. =A0The licence seems to be GPL.
>
>This is what the ciforth documentation states (wina.pdf: Section 3.1
>'Legalese'): 'The GPL is interpreted in the sense that a system based
>on ciforth and intended to serve a particular purpose, that purpose
>not being a "general purpose Forth system", is fair use of the system,
>even if it could accomplish everything ciforth could, under the
>condition that the ciforth it is based on is available in accordance
>to the GPL rules, and this is made known to the user of the derived
>system'.
>
>I read that as meaning that a derived "general purpose Forth system",
>such as I wish to produce, is not "fair use of" ciforth.
You read wrongly. You should read that the above stipulation is not
applicable. Please not that the above is intended to grant
*extra* rights up and above GPL in deviation of what a naive
interpretation would allow. So I can't understand why you think
it restricts you.
>
>Another difficulty with the GPL is that it requires any derivative
>work also to be made available *in its entirety* under the GPL (with
>certain exceptions that I don't think apply here). If I create a
>system by combining BBC BASIC (a commercial product) with ciforth
>(GPL) then I can't do that, because the BBC BASIC part isn't 'free'
>software.
I as the sole author hereby grant permission to combine a derivation
of ciforth/lina with BBC BASIC. The net be my witness.
Now how hard was that?
(You have been trapped by anti-GPL propaganda. GPL-ers wants their
software be used, not hijacked. You can talk with them, and they
are mostly reasonable, especially if what you do is in line with
the reason they created the software in the first place.)
>
>> While I was figuring out how to write DOES> I found that JonesForth is
>> a tricky program to modify, so much so that I needed several tries to
>> get DOES> to work correctly, even though I'm an expert.
>
>I really feel DOES> is a special case. Yesterday I implemented DO ...
>LOOP (including +LOOP and the I and J words) in assembler and it
>*worked first time*.
>
>> Given that there is a standard Forth you can use, I simply can't
>> understand your motives for wanting to fix JonesForth.
>
>We haven't established that there is a "standard Forth" I can use.
At simtel's there is a 32 bit figForth. It even is fairly popular,
maybe because there are still figForth programs around, who knows.
>
>Richard.
>http://www.rtrussell.co.uk/
>To reply by email change 'news' to my forename.
Groetjes Albert
Richard Russell
that it has some far more serious (and stupid) errors than I
expected. Even something as fundamental as MOD and / are seriously
flawed: Jones creates a combined primitive /MOD (using the CPU's idiv
instruction) but gets hopelessly muddled between signed and unsigned
numbers. That's easily corrected, but then printing of unsigned
numbers (U. etc.) goes awry because it assumes MOD is an unsigned
operator!
What I don't understand is how such a serious fault has gone
uncorrected. Anybody using Jonesforth for even the simplest
arithmetic must have noticed it (for example dividing -4 by 4 gave
completely the wrong answer). I'll try contacting Richard Jones again
to get his take on it, but I'm not hopeful of a reply.
Ian Osgood
> To reply by email change 'news' to my forename.
Yeah, there is a lot of practical experience distilled into the
established choices of primitives found in the more experienced Forth
implementations. For example, the availability of both UM/MOD and SM/
REM primitives in the standard, the specification of signed/unsigned
behavior of most words, the pictured numeric output words as the basis
for . U. .R etc, and the implementation of CREATE/DOES>.
A similar literate Forth implementation, which drew upon the combined
man-centuries of Forth community experience instead of one author's
learning experience, would be of *immense* value. I don't know if
people realize, but JonesForth ended up getting a *lot* of publicity
on the programming social networks, thus becoming the public face of
Forth, for better or worse.
Ian
P.S. I submitted a patch to correct the ROT/-ROT reversal, but have
not yet had a response.
Andrew Haley
> A similar literate Forth implementation, which drew upon the
> combined man-centuries of Forth community experience instead of one
> author's learning experience, would be of *immense* value. I don't
> know if people realize, but JonesForth ended up getting a *lot* of
> publicity on the programming social networks, thus becoming the
> public face of Forth, for better or worse.
IMO it's a shame that the effort didn't go into documenting a somewhat
more standard system.
Thanks for the info. I had no idea JonesForth was well-known; I'd
never heard of it before a a few months ago. I'm not mad about all
the wordage myself, finding it a lot easier just to read the code.
Years ago Loeliger wrote "Threaded Interpretive Languages", a similar
idea, which a lot of people liked but was too long-winded for me.
Andrew.
Richard Russell
> Yeah, there is a lot of practical experience distilled into the
> established choices of primitives found in the more experienced Forth
> implementations.
I don't think there's much wrong with his choice of primitive as such
(as he says, combining MOD and / makes a lot of sense when the CPU's
native instruction provides both); it's purely a silly coding error.
To give Rich Jones credit, he did respond promptly to my report: "I
think you're in the best position to attempt to fix this (by supplying
a patch) since you will be much more familiar with the code. In
general, Jonesforth is a tutorial and not a live, maintained project".
Unfortunately it's tricky for me to supply a "patch", since I've had
to convert all the assembler code from 'Gas' to 'Intel' syntax for my
(Windows) implementation and therefore it's not directly suitable for
transplantation back into the original.
> P.S. I submitted a patch to correct the ROT/-ROT reversal, but have
> not yet had a response.
I've fixed this in my version, too (using a bit of pointer hackery so
that I can fix it in the Forth section whilst still using the native
code implementations).
One piece of positive news. Although when I first tried it I couldn't
get it to work (probably a typo) I've now got the 'alternative'
Jonesforth version of <BUILDS ... DOES> going properly.
Notwithstanding Andrew's comments, I still prefer it to his
implementation. In case anybody wants to try it this is what I ended
up with (Intel syntax again):
Assembler section:
defconst "dodoes", 6,,dodoes,_dodoes
_dodoes:
lea ebp,[ebp-4] ; PUSHRSP esi
mov [ebp],esi
mov esi,[eax+4] ; Load the threaded code pointer
add eax,8 ; Push the address of the start...
push eax ; ... of the user data area
lodsd : jmp [eax] ; NEXT
Forth section:
: <BUILDS WORD CREATE dodoes , 0 , ;
: DOES> R> LATEST @ >DFA ! ;
HIDE dodoes
Test it:
: CST <BUILDS , DOES> @ ;
9 CST FOO
FOO .
9
: VAR <BUILDS 0 , DOES> ;
VAR BAR
3 BAR !
BAR @ .
3
Richard.
Coos Haak
<snip>
And now for fun:
' BAR >BODY @ .
If it doesn't print 3, try rewriting >BODY
ciforth would be a much better choice, IMO.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Frank Buss
> Ian Osgood <ia...@quirkster.com> wrote:
>
>> A similar literate Forth implementation, which drew upon the
>> combined man-centuries of Forth community experience instead of one
>> author's learning experience, would be of *immense* value. I don't
>> know if people realize, but JonesForth ended up getting a *lot* of
>> publicity on the programming social networks, thus becoming the
>> public face of Forth, for better or worse.
>
> IMO it's a shame that the effort didn't go into documenting a somewhat
> more standard system.
Any suggestion which Forth implementation someone should take a look at for
a more standard system with man-centuries of Forth community experience?
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Bernd Paysan
> Any suggestion which Forth implementation someone should take a look at
> for a more standard system with man-centuries of Forth community
> experience?
What about Gforth?
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Elizabeth D Rather
Insofar as Albert has clarified his licensing policy, what keeps you
from going with that system?
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Frank Buss
> Frank Buss wrote:
>> Any suggestion which Forth implementation someone should take a look at
>> for a more standard system with man-centuries of Forth community
>> experience?
>
> What about Gforth?
Maybe this is a good idea. But do you have any documentation of the
internals? It has a good documentation for Forth programmers, but not for
Forth system writers, e.g. I didn't found the header structure for words.
Searching the source shows some interesting sounding things like "ghosts",
but I didn't found a nice high-level description of how the whole system
works.
Andrew Haley
Given that JonesForth's ' only works within a colon definition,
I wouldn't hold out much hope.
> If it doesn't print 3, try rewriting >BODY
> ciforth would be a much better choice, IMO.
Andrew.
Richard Russell
> Insofar as Albert has clarified his licensing policy, what keeps you
> from going with that system?
I'd already expended a lot of effort porting Jonesforth, and switching
horses mid-stream would have involved repeating much of it, with
relatively little benefit from my perspective (the feedback I've had
so far from BBC BASIC users doesn't indicate any dissatisfaction with
the result).
Also, as a extreme Forth novice, I felt the detailed explanations of
how Jonesforth works would make it easier to resolve any difficulties
that might arise with the implementation - and indeed that has proved
to be the case. It will never be ISO-compliant (or even close), but
at least I feel confident that I will be able to address any major
shortcomings should they be reported.
I did have a quick play with ciforth (WINA 4.0.6) but, no doubt out of
ignorance, was somewhat put off by the absence of some words I'd got
familiar with in Jonesforth (e.g. -ROT, SEE).
I've uploaded a preliminary version of my adapted Jonesforth here (MS
Windows only):
http://www.rtr.myzen.co.uk/bb4wforth.zip
Bear in mind that it's not intended to be much more than a toy.
There's a graphics example program included (access to BBC BASIC-style
graphics being a major reason for the exercise) which can be run
using:
S" fern.f" EXEC
Coos Haak
> On 14 Sep, 09:28, Elizabeth D Rather <erat...@forth.com> wrote:
>> Insofar as Albert has clarified his licensing policy, what keeps you
>> from going with that system?
>
> I'd already expended a lot of effort porting Jonesforth, and switching
> horses mid-stream would have involved repeating much of it, with
> relatively little benefit from my perspective (the feedback I've had
> so far from BBC BASIC users doesn't indicate any dissatisfaction with
> the result).
>
> Also, as a extreme Forth novice, I felt the detailed explanations of
> how Jonesforth works would make it easier to resolve any difficulties
> that might arise with the implementation - and indeed that has proved
> to be the case. It will never be ISO-compliant (or even close), but
> at least I feel confident that I will be able to address any major
> shortcomings should they be reported.
>
Being ISO-compliant make things simpler when using others's code.
> I did have a quick play with ciforth (WINA 4.0.6) but, no doubt out of
> ignorance, was somewhat put off by the absence of some words I'd got
> familiar with in Jonesforth (e.g. -ROT, SEE).
>
: -ROT ROT ROT ; (S3 cristallography group)
SEE is definitly present in wina.
Start with: wina -e or when in wina, 'REQUIRE SEE'
Albert van der Horst
Frank Buss <f...@frank-buss.de> wrote:
>Andrew Haley wrote:
>
>> Ian Osgood <ia...@quirkster.com> wrote:
>>
>>> A similar literate Forth implementation, which drew upon the
>>> combined man-centuries of Forth community experience instead of one
>>> author's learning experience, would be of *immense* value. I don't
>>> know if people realize, but JonesForth ended up getting a *lot* of
>>> publicity on the programming social networks, thus becoming the
>>> public face of Forth, for better or worse.
>>
>> IMO it's a shame that the effort didn't go into documenting a somewhat
>> more standard system.
>
>Any suggestion which Forth implementation someone should take a look at for
>a more standard system with man-centuries of Forth community experience?
ciforth?
Certainly ciforth is building on many, many man-years of effort.
I not only stole the fig-Forth layout, I copied the fig-Forth
implementation, copied documentation based on the fig Manual. I used
all assembler defined words of fig-Forth, studying 3 fig-forth's for
8086 and some others.
For 6809 I drew heavily upon what Brad Rodriguez did etc.
Only then I started changing it into 32 bits, ISO-fy it, incorporate tricks
from others (equally borrowed), improved and adapted the documentation
etc.
>Frank Buss, f...@frank-buss.de
Albert van der Horst
Richard Russell <ne...@rtrussell.co.uk> wrote:
>
>I did have a quick play with ciforth (WINA 4.0.6) but, no doubt out of
>ignorance, was somewhat put off by the absence of some words I'd got
>familiar with in Jonesforth (e.g. -ROT, SEE).
REQUIRE SEE \ In upcoming 5.x : WANT SEE
I will add -ROT (and ROLL) to my screen of "obscure stack
manipulations", effective of version 5.x.
Richard Russell
wrote:
> REQUIRE SEE \ In upcoming 5.x : WANT SEE
What am I doing wrong here:
80386 ciforth 4.0.6
REQUIRE SEE
REQUIRE ? ciforth ERROR # 12
Albert van der Horst
Richard Russell <ne...@rtrussell.co.uk> wrote:
>On 15 Sep, 11:41, Albert van der Horst <alb...@spenarnc.xs4all.nl>
>wrote:
>
>What am I doing wrong here:
>
>80386 ciforth 4.0.6
>REQUIRE SEE
>REQUIRE ? ciforth ERROR # 12
wina is a minimalist system.
Without an option you really only get the kernel.
Normal trying out of wina would be using
wina -e
This loads the elective screen 5.
(Screen 5 is intended to be adapted, for example add a line with
`` REQUIRE SEE ''
`` "C:\program files\ultraedit.exe" OS-IMPORT ua \ Your favorite editor
)
The same effect can be had by
80386 ciforth 4.0.6
^E LOAD
REQUIRE is available too (without much more) after
wina -r
or `` ^R LOAD ''
``wina /?'' should have informed you of the existence of a pdf
documentation, but apparently the use of options must be more
prominent in the tutorial section of that documentation.
(I'll look into that)
>Richard.
Richard Russell
wrote:
> Normal trying out of wina would be using
> wina -e
C:\bbcbasic\WINDOWS\programs\forth>wina -e
? ciforth ERROR # 8
> REQUIRE is available too (without much more) after
> wina -r
C:\bbcbasic\WINDOWS\programs\forth>wina -r
? ciforth ERROR # 8
> ``wina /?'' should have informed you of the existence of a pdf
> documentation
C:\bbcbasic\WINDOWS\programs\forth>wina /?
? ciforth ERROR # 8
Incidentally, in each case, I was left in ciforth rather than being
returned to the command prompt as would be normal in the case of an
invalid command-line syntax. It's a good thing I knew about BYE!
Albert van der Horst
Richard Russell <ne...@rtrussell.co.uk> wrote:
>On 15 Sep, 21:35, Albert van der Horst <alb...@spenarnc.xs4all.nl>
>wrote:
>> Normal trying out of wina would be using
>> wina -e
>
>C:\bbcbasic\WINDOWS\programs\forth>wina -e
>? ciforth ERROR # 8
ERROR # 8 means "can't find the library".
If you did :
cd C:\bbc ... \forth
pkunzip wna4d06d.zip
wina -e
this shouldn't happen, because the burnt in library name is
the local file "FORTH.LAB"
[Without the library forth.lab wina has no mnemonic messages
of errors, and can't execute options.]
Error 8 and its remedy is easy to find in the .pdf doc.
In short:
If you want a system wide install on modern MS-windows, you
must become administrator and specify path's in full:
cd c:\temp
pkunzip c:\...Downloads\wna4d06d.zip
wina -i C:\Prog...forth\wina.exe c:\Dat..forth\forth.lab %COMSPEC%
(I myself am lazy and put all stuff in the SYSTEM32 directory.
Windows is a mess anyway.)
Albert van der Horst
Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>Richard Russell <ne...@rtrussell.co.uk> wrote:
<SNIP>
>
>I think Jones started with LINA Forth
>(http://home.hccnet.nl/a.w.m.van.der.horst/lina.html) by Albert van
>der Horst. I reckon it may actually be easier to port, since stuff
>like this, although it's in an assembler source file, is very
>portable:
>
>N_WITHIN:
> .long 6
> .ASCII "WITHIN"
> .balign 4,0x90
>WITHIN:
> .long DOCOL
> .long WITHIN+HEADSIZE
> .long 0x0
> .long TSTOR
> .long N_WITHIN
> .long 0
> .long 0
>
> .long OVER, LSUB, TOR
> .long LSUB, FROMR
> .long ULESS
> .long SEMIS
In the generic system it is even better:
_HEADER({WITHIN},{WITHIN},DOCOL)
DC OVER, LSUB, TOR
DC LSUB, FROMR
DC ULESS
DC SEMIS
This is the same across all ciforth's and all assemblers.
Of course the _HEADER and DC macro's need adaptation,
but that is an effort at one place.
To be honest, learning the generic system is an investment.
It is documented though.
>I have no experience of LINA Forth, so I can't recommend it. I
>believe Albert when he says it's standard, though.
WARNING: I claim at most "largely standard".
- I couldn't live with >IN
ciforths have no REFILL to speak of.
- ciforths can't LOOP over the negative/positive boundary
- THROW is standard, but the throw codes are not
It is a minimalist Forth, so a lot of words are missing,
notably floating point. Partly the library compensates.
The standard requires a lot of "implementation defines".
Most of this is in ciforth documentation, but it has not been
systematically checked like in gforth where a chapter is
devoted to it.
>
>Andrew.
Andrew Haley
> <SNIP>
What are all these extra fields in the header for, anyway? There seem
to be six of them.
Andrew.
Richard Russell
wrote:
> Error 8 and its remedy is easy to find in the .pdf doc.
Unfortunately WINA.PDF is broken. If I click on any of the bookmarks
they take me to the wrong page, for example if I click on 'Errors' it
takes me to page 44 rather than 43 (most commonly the bookmarks lead
to the page *after* the correct one, but 'Concept Index' goes to 148
rather than 157!).
> (I myself am lazy and put all stuff in the SYSTEM32 directory.
> Windows is a mess anyway.)
With all due respect, I would not be inclined to use an application
developed by somebody with that attitude!
The more I learn about ciforth the more concerns I have about it. For
example, why isn't it a true 32-bit Console application (I noticed the
file extension was .COM rather than a .EXE, and I see from the docs
that it runs under DOS/DPMI)? That must make it almost impossible to
access the Windows API from a Forth program (which is straightforward
in my adaptation of Jonesforth because I've added words for
LoadLibrary and GetProcAddress).
Richard.
http://www.rtrussell.co.uk/
Albert van der Horst
Glad you asked :-) You're right, six.
DEA: (Dictionary Entry Address)
Code field
Data field
Flag field
Link field
Name field
Source field
You need executable code. You need data. You need a way to
remember the properties of this word. You need a link to
the next word. You need some pointer to a string that is the
name. You need some hint about where it is defined.
These fields are uniformly one cell.
You may configure an eXtra field to play with, after the Source
field. (For a total of 56 bytes.)
This order makes sense and, guess what, it is alphabetic too!
(A test for the generic system is to swap a random
pair of these fields. For the Renesas it was advantageous to
swap the data and flag field. A word is defined by its DEA,
so it's okay if the Code field is at an offset other than 0.)
Albert van der Horst
Richard Russell <ne...@rtrussell.co.uk> wrote:
<SNIP>
>
>> (I myself am lazy and put all stuff in the SYSTEM32 directory.
>> Windows is a mess anyway.)
>
>With all due respect, I would not be inclined to use an application
>developed by somebody with that attitude!
My Linux systems are in good shape. Life is about choices and
I choose not to try to keep up with Windows wims. There can be
quite a debate about what are the political correct directories
for putting programs in.
My installation procedure is extremely simple and can accomodate
any company policy.
>
>The more I learn about ciforth the more concerns I have about it. For
>example, why isn't it a true 32-bit Console application (I noticed the
>file extension was .COM rather than a .EXE, and I see from the docs
>that it runs under DOS/DPMI)? That must make it almost impossible to
>access the Windows API from a Forth program (which is straightforward
>in my adaptation of Jonesforth because I've added words for
>LoadLibrary and GetProcAddress).
This may mean that you made the right choice with Jonesforth.
DPMI is a conscious choice. The same Forth runs from Windows 3.11
through Vista and I do not link with any library. The executable is
build on linux and can even be tested under dosemu.
That comes at a price. I never missed accessing Windows API's,
but surely the restriction to 8+3 filenames is annoying.
>
>Richard.
>http://www.rtrussell.co.uk/
>
Greotjes Albert
Anton Ertl
>Bernd Paysan wrote:
>
>> Frank Buss wrote:
>>> Any suggestion which Forth implementation someone should take a look at
>>> for a more standard system with man-centuries of Forth community
>>> experience?
>>
>> What about Gforth?
>
>Maybe this is a good idea. But do you have any documentation of the
>internals?
There are a number of papers, but overall Gforth is probably too
complex for people wanting to learn to understand a Forth system
completely, and too much of a moving target for people who would help
such efforts by documenting the internals.
>Searching the source shows some interesting sounding things like "ghosts",
That's a feature of cross, so it's completely undocumented.
Anyway, here are the papers there are; many are about the inner
interpreter (and how it evolved), but there are also others:
@InProceedings{ertl93,
author = "M. Anton Ertl",
title = "A Portable {Forth} Engine",
booktitle = "EuroFORTH '93 conference proceedings",
year = "1993",
address = "Mari\'ansk\'e L\'azn\`e (Marienbad)",
url = "http://www.complang.tuwien.ac.at/papers/ertl93.ps.gz",
abstract = "The Forth engine discussed in this paper is written
in GNU C, which provides several extensions that are
important for Forth implementation. The indirect
threaded Forth engine is completely
machine-independent, direct threading requires a few
machine-specific lines for each machine. Using
a portable language like GNU C encourages producing
an engine with many primitives. In order to make the
development of primitives easier and less
error-prone, an automatic tool generates most of the
code for a Forth primitive from the stack effect
notation, even if the TOS is kept in a register. The
engine is combined with the parts of the system
written in Forth by loading a machine-independent
image file that contains the executable Forth code
in relocatable form."
}
@InProceedings{ertl94l,
author = "M. Anton Ertl",
title = "Automatic Scoping of Local Variables",
booktitle = "EuroForth~'94 Conference Proceedings",
year = "1994",
address = "Winchester, UK",
pages = "31--37",
url = "http://www.complang.tuwien.ac.at/papers/ertl94l.ps.gz",
abstract = "In the process of lifting the restrictions on using
locals in Forth, an interesting problem poses
itself: What does it mean if a local is defined in a
control structure? Where is the local visible? Since
the user can create every possible control structure
in ANS Forth, the answer is not as simple as it may
seem. Ideally, the local is visible at a place if
the control flow {\em must} pass through the
definition of the local to reach this place. This
paper discusses locals in general, the visibility
problem, its solution, the consequences and the
implementation as well as related programming style
questions."
}
@InProceedings{ertl98,
author = {M. Anton Ertl},
title = {\texttt{State}-smartness --- Why it is Evil and How
to Exorcise it},
booktitle = {EuroForth'98 Conference Proceedings},
year = {1998},
address = {Schlo\ss{} Dagstuhl},
url = {http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz},
abstract = {\texttt{State}-smart words provide a number of unpleasant
surprises to their users. They are applied in two
contexts, and they fail in both: 1) for providing an
arbitrary combination of interpretation and
compilation semantics; 2) for optimizing with a
special implementation of the (default) compilation
semantics. This paper discusses these issues and
shows programmers and system implementors how to
avoid \texttt{state}-smart words. It also reports our
experiences in converting the \texttt{state}-smart
words in Gforth into a clean solution: little work
and few problems.}
}
@InProceedings{ertl02,
author = {M. Anton Ertl},
title = {Threaded Code Variations and Optimizations (Extended
Version)},
booktitle = {Forth-Tagung 2002},
year = {2002},
address = {Garmisch-Partenkirchen},
url = {http://www.complang.tuwien.ac.at/papers/ertl02.ps.gz},
abstract = {Forth has been traditionally implemented as indirect
threaded code, where the code for non-primitives is
the code-field address of the word. To get the
maximum benefit from combining sequences of
primitives into superinstructions, the code produced
for a non-primitive should be a primitive followed
by a parameter (e.g., \code{lit} \emph{addr} for
variables). This paper takes a look at the steps
from a traditional threaded-code implementation to
superinstructions, and at the size and speed effects
of the various steps.\comment{It also compares these
variants of Gforth to various other Forth
implementations on contemporary machines.} The use
of superinstructions gives speedups of up to a
factor of 2 on large benchmarks on processors with
branch target buffers, but requires more space for
the primitives and the optimization tables, and also
a little more space for the threaded code.}
}
@InProceedings{ertl&gregg03euroforth,
author = {M. Anton Ertl and David Gregg},
title = {Implementation Issues for Superinstructions in
{Gforth}},
booktitle = {EuroForth 2003 Conference Proceedings},
OPTpages = {},
year = {2003},
URL = {http://www.complang.tuwien.ac.at/papers/ertl%26gregg03euroforth.ps.gz},
abstract = {Combining Forth primitives into superinstructions
provides nice speedups. Several approaches to
superinstructions were explored in the Gforth
project. This paper discusses the effects of these
approaches on performance, compilation time,
implementation effort, and on programming tools such
as the decompiler and backtracing.}
}
@InProceedings{ertl&gregg05,
author = {M. Anton Ertl and David Gregg},
title = {Stack Caching in {Forth}},
crossref = {euroforth05},
pages = {6--15},
url = {http://www.complang.tuwien.ac.at/papers/ertl%26gregg05.ps.gz},
pdfurl = {http://www.complang.tuwien.ac.at/anton/euroforth2005/papers/ertl%26gregg05.pdf},
OPTnote = {not refereed},
abstract = {Stack caching speeds Forth up by keeping stack items
in registers, reducing the number of memory accesses
for stack items. This paper describes our work on
extending Gforth's stack caching implementation to
support more than one register in the canonical
state, and presents timing results for the resulting
Forth system. For single-representation stack
caches, keeping just one stack item in registers is
usually best, and provides speedups up to a factor
of 2.84 over the straight-forward stack
representation. For stack caches with multiple stack
representations, using the one-register
representation as canonical representation is
usually optimal, resulting in an overall speedup of
up to a factor of 3.80 (and up to a factor of 1.53
over single-representation stack caching).}
}
@InProceedings{ertl07euroforth,
author = {M. Anton Ertl},
title = {Gforth's libcc {C} Function Call Interface},
crossref = {euroforth07},
pages = {7--11},
url = {http://www.complang.tuwien.ac.at/papers/ertl07euroforth.ps.gz},
pdfurl = {http://www.complang.tuwien.ac.at/anton/euroforth2007/papers/ertl.pdf},
OPTnote = {not refereed},
abstract = {A major problem in our earlier proposal for a C
interface was that a part of the interface was not
portable between platforms. The libcc interface
solves this problem by using a C compiler and its
\code{.h}-files. The \code{.h}-files contain
knowledge about the specific platform, and the C
compiler automatically inserts the necessary
conversions between Forth and C types. In this paper
we describe the libcc implementation and
interface. We also discuss how a Forth-C interface
might be standardized.}
}
- 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/
Anton Ertl
>To give Rich Jones credit, he did respond promptly to my report: "I
>think you're in the best position to attempt to fix this (by supplying
>a patch) since you will be much more familiar with the code. In
>general, Jonesforth is a tutorial and not a live, maintained project".
In that case I suggest that you take over the maintenance.
>Unfortunately it's tricky for me to supply a "patch", since I've had
>to convert all the assembler code from 'Gas' to 'Intel' syntax for my
>(Windows) implementation and therefore it's not directly suitable for
>transplantation back into the original.
Gas supports the Intel syntax in addition to the default AT&T syntax
(through the .intel_syntax directive or -msyntax=intel option; there
is also .intel_mnemonic, which you may need), so you could create a
version that works on his original GAS-based platform as well as on
your platform.
Anton Ertl
>In article <V6ydnaOvOsMD6jvX...@supernews.com>,
>Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
[on implementing DOES>]
>>A pointer from the code field directly to a jsr instruction in the
>>defining word has been standard in ITC Forths since about 1980, when
>>it was invented to replace the double indirection that was used in
>>fig-FORTH.
>
>You mean the code field of an ITC word contains a jsr to a
>defining word.
No, the code field contains an address (otherwise it would be DTC, not
ITC). But the address that it points to contains a jsr to the real
DODOES.
In this way we get a pointer to the data (through the CFA that's kept
in a register that is typically called W), a pointer to the Forth code
(on the stack or in the return-address register), and are executing
the DODOES that knows what to do with these things.
>The return address is left on the stack,
>and this is interpreted as a data pointer.
No, it's interpreted as threaded-code pointer (to the Forth code after
the DOES>).
>IMO it is an ugly hack, and considerably less clean, less simple
>and harder to understand then DTC.
It's certainly a hack, whether it's clean, ugly, or clever is in the
eye of the beholder.
As for DTC, you can use the same technique there. Indeed, in Gforth
we have two-cell code fields in order to avoid that trick in ITC
(which we wanted to be completely machine-independent); i.e., our ITC
implementation worked like <BUILDS ... DOES>.
But in DTC the jump to the native code often needs more than one cell
(because it just is longer on IA32, or because there is a delayed
branch on MIPS, SPARC, and HPPA), so for DTC we often implemented
DOES> using this hack.
Of course, since 0.6.x we use hybrid direct/indirect threaded code, so
we now avoid this hack
<http://www.complang.tuwien.ac.at/papers/ertl02.ps.gz>
So it's not really about DTC without this hack or ITC with this hack,
these questions are mostly independent.
> It mixes data and code in
>a messy way.
Any messier than DTC? It's just the same, only used in fewer places.
Ok, the decompiler will see some machine code after a (DOES>), but you
can special-case for that if you really want to; if you want a clean
decompiler result, you will decompile (DOES>) and maybe additional
stuff to DOES>, so you usually need a special case for that already.
BTW, the mixing of code and data in DTC leads to a significant
slowdown on application benchmarks in Gforth 0.5.0 on IA32. Take a
look at the "Overall performance" graph in
<http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl-slides.pdf>:
Note how the AMD64 binaries (green) on the Xeon and the Opteron
outperform the corresponding IA32 binaries (blue) in Gforth 0.5.0
(i.e., leftmost). That's because the IA32 binary uses DTC (and runs
into cache consistency trouble), whereas AMD64 uses ITC. The reason
for that is that 0.5.0 does not know anything about AMD64 (which was
not available at the time) and therefore falls back to ITC.
> It greatly restricts how headers can be laid out.
The hack does not reside in headers, so I don't see any restriction.
In contrast, the main alternative requires to add an additional cell
to the code field, which some may consider to be quite a restriction.
How do you solve it if you don't use this hack?
Anton Ertl
>I presume you are aware of the Hayes tester for ANS Forth compliance,
>that will tell you which JonesForth words are non-compliant.
Only for CORE words. Moreover, even for these words there is no
guarantee that it finds everything that's non-compliant ("Testing can
only prove the presence of bugs, not their absence.").
There are tests for some other words by Gerry.
Anton Ertl
>> I would add that it also gives Forth access to a number of other BBC
>> BASIC features, such as being able to change the text font, load and
>> save BMPs, select the printer, play a MIDI file, program the
>> function keys etc. (for those who know BBC BASIC, Forth has access
>> to 'VDU' and 'OSCLI').
>
>But that's Forth making calls to BBC BASIC. It's not a combined work,
>any more than hosting Forth on Windows makes the Forth a combined work
>with Windows.
That's not a good example, because there is the exception in the GPL
about libraries that come with the system, and Windows libraries would
fall under that clause. A better example would be Java, which, like
BBC Basic, does not come with the system.
Anton Ertl
>I'm not personally convinced that it would be as difficult to 'fix'
>Jonesforth as has been suggested here. I accept that a change in one
>place can have knock-on effects elsewhere, but I can go some way to
>avoiding that by making the 'fixes' a post-processing exercise. For
>example, ROT and -ROT are known to be reversed in Jonesforth;
>correcting them 'at source' would require changing every subsequent
>definition that uses them. But I don't need to do that; I can leave
>them reversed, and then at the very end when all the derivative words
>have been defined I can swap them (I think I can even do it in such a
>way that SEE will actually show the 'corrected' definitions of words
>using them!).
>
>Similarly with the other non-standard words; I can leave them alone
>whilst they are used in subsequent definitions and re-define them at
>the very end. Slightly wasteful of dictionary space, but it would
>work. Unfortunately in that case SEE wouldn't show a 'correct'
>definition, which could be misleading, but I'd live with that.
Even SEE would show the names you want to give these words if you
perform your changes by patching the names in the headers (instead of
by defining aliases). Of course, that requires that the new names fit
in the space of the old names.
But even if the standard name does not fit, you should just make sure
that the conflicting name is changed to a plain non-standard name.
E.g., if -ROT does not fit for the word performing ( a b c -- c a b ),
call it, say RO2 or something, just not ROT.
That approach still leaves the source code (and possibly LOCATE) in a
confusingly conflicting way. Then there's the option to change the
source code in the corresponding way. Depending on how active
maintenance of JonesForth is and whether you want to track that, you
may not want to do this, however.
The other question with either approach is if there are subtle
differences in the behaviour of stuff that you neither want to change
(because of possible knock-on effects) nor want to reimplement
(because then you would have to reimplement too much above it). In
that case, you may not be able to provide full standards
compatibility. But fixing the most obvious (and pointless) deviations
from the standard like the non-standard behaviour of ROT should be
doable and provide a good cost/benefit ratio.
Richard Russell
wrote:
> DPMI is a conscious choice. The same Forth runs from Windows 3.11
> through Vista
I can't disagree that if you need to retain compatibility with Windows
3.11 you've made the right choice. But do you really need that? BBC
BASIC for Windows (and hence BB4Wforth) is fully compatible right back
to Windows 95 (and up to Windows 7) and I'm often asked why I bother
supporting Win9x at all! In fact there are still a lot of Win9x
systems in use, but Windows 3.11? I greatly doubt it!
> and I do not link with any library.
BB4Wforth doesn't *statically* link with any libraries either, but it
does dynamically link (at run time) with a few of the standard Windows
DLLs, e.g. kernel32.dll, user32.dll etc.
> I never missed accessing Windows API's
How then do you cope with graphical output (above VGA resolution),
audio input/output (other than the motherboard speaker), video etc.
(indeed any kind of multimedia input/output)? How do you cope with
driving a USB 'Windows' printer (which the majority are these days) or
accessing a USB serial port adaptor? How would you create a 'proper'
Windows GUI interface to a Forth program? All these things require
access to the Windows API, and all are relatively easy to achieve in
BB4Wforth!
> This may mean that you made the right choice with Jonesforth.
I must say that, despite its known limitations, I am pleased with the
results I am achieving. I have listed below a program that plays a
short tune via Windows' MIDI synthesis capabilities. I don't claim
that it's well written (indeed it's probably terrible Forth) but it
does illustrate the ease with which the Windows API can be accessed
directly. Could you do that in ciforth?
Richard.
http://www.rtrussell.co.uk/
\ BB4Wforth program to play a tune using MIDI
1 CONSTANT Grand_Piano
Z" WINMM.DLL" LoadLibrary ( Load WinMM library )
DUP Z" midiOutOpen" GetProcAddress CONSTANT midiOutOpen
DUP Z" midiOutShortMsg" GetProcAddress CONSTANT midiOutShortMsg
DUP Z" midiOutClose" GetProcAddress CONSTANT midiOutClose
FreeLibrary DROP ( Free WinMM library )
Z" Kernel32.DLL" LoadLibrary ( Load Kernel32 library )
DUP Z" Sleep" GetProcAddress CONSTANT Sleep
FreeLibrary DROP ( Free Kernel32 library )
VARIABLE MidiHandle
: OpenMidi ( -- )
0 0 0 -1 MidiHandle midiOutOpen SYSCALL
IF
." Failed to open MIDI output device" CR
ABORT
THEN
;
: CloseMidi ( -- )
MidiHandle @ midiOutClose SYSCALL
DROP
;
: SendOutShortMsg ( msg -- )
MidiHandle @ midiOutShortMsg SYSCALL
DROP
;
: Delay ( time -- )
Sleep SYSCALL DROP
;
HEX
: StartNote ( note -- )
100 * 7F0090 +
SendOutShortMsg
;
DECIMAL
: StopNote ( note -- )
256 * 128 +
SendOutShortMsg
;
: PlayNote ( note time -- )
SWAP TUCK
StartNote
Delay
StopNote
;
HEX
: Instrument ( voice -- )
100 * 7F00C0 +
SendOutShortMsg
;
DECIMAL
: CE3K
OpenMidi
Grand_Piano Instrument
70 500 PlayNote
72 500 PlayNote
68 500 PlayNote
56 500 PlayNote
63 1000 PlayNote
1000 Delay
CloseMidi
;
CE3K
Ian Osgood
> : PlayNote ( note time -- )
> SWAP TUCK
> StartNote
TUCK == SWAP OVER, so SWAP TUCK == OVER
The factoring looks nice and simple otherwise. Happy trails!
Ian
Albert van der Horst
Richard Russell <ne...@rtrussell.co.uk> wrote:
<SNIP>
>
>> This may mean that you made the right choice with Jonesforth.
>
>I must say that, despite its known limitations, I am pleased with the
>results I am achieving. I have listed below a program that plays a
>short tune via Windows' MIDI synthesis capabilities. I don't claim
>that it's well written (indeed it's probably terrible Forth) but it
>does illustrate the ease with which the Windows API can be accessed
>directly. Could you do that in ciforth?
No.
<midi program SKIPped>
Groetjes Albert
Richard Russell
> On Sep 17, 6:41 am, Richard Russell <n...@rtrussell.co.uk> wrote:
> TUCK == SWAP OVER, so SWAP TUCK == OVER
Ah, thanks. I can't get my head around these stack manipulation
words!
Can I take this opportunity to check whether I've got the
implementation of ROLL right. I get:
1 2 3 4 5 6 7 8
5 ROLL .S
1 2 4 5 6 7 8 3
Is that correct?
Incidentally, is there any standardisation in the order in which .S
lists the stack contents? I've seen both!
Farlie A
On Sep 17, 2:41 pm, Richard Russell <n...@rtrussell.co.uk> wrote:
> On 17 Sep, 03:25, Albert van der Horst <alb...@spenarnc.xs4all.nl>
> wrote:
> > and I do not link with any library.
> BB4Wforth doesn't *statically* link with any libraries either, but
it
> does dynamically link (at run time) with a few of the standard
Windows
> DLLs, e.g. kernel32.dll, user32.dll etc.
Or potentially, given the 'flexibility' of FORTH syntax the ability to
make COM Calls (provided you know the offsets inside a
method table..)
BBW does this by a dual indirection, which should feasibly be possible
in FORTH as well using @ twice?
There are assembler driven libraries for accessing DirectX with BB4W,
There's nothing to stop those being ported to BB4WForth...
> > This may mean that you made the right choice with Jonesforth.
>
> > I must say that, despite its known limitations, I am pleased with the
> > results I am achieving. I have listed below a program that plays a
> > short tune via Windows' MIDI synthesis capabilities. I don't claim
> > that it's well written (indeed it's probably terrible Forth) but it
> > does illustrate the ease with which the Windows API can be accessed
> > directly.
>
A response to the MIDI program:
If you use Channel-10 (Which would be 9 in code) then with some
thought you can have a
simple drum pad, Assuming you know the right pitch values to feed it.
From other code I've seen, KEY seems to be the way to read the
keyboard, although maybe not in real-time,
BBB4W has a timed INKEY function, Does FORTH have a defined word for
something that performs that function?
An alternate way of handling 'realtime' key presses would be respond
to
'KeyDown' and 'KeyUp' events from Windows and run
appropriate FORTH code based on the values in those events....
In adapting the MIDI example, I did add a table for all the instrument
values, a 'map' for percussion sounds, both are currently
implemented as 'longish' list of directly defined constants.
My next aim, in terms of musical notes, would be to replace direct
pitch values with something like 'A' 'B' 'C' '^' for a simple 3 note
scale. Simplisticily these could be direct CONSTANT's. My thinking was
that it would be more appropriate to only define 'A' 'B' 'C' 'D' etc.
for a single octave and define words that modify the pitch values.
AMPLE (a BBC Micro music system) used uppercase note-names to indicate
rising notes, and lower case note name to indicate falling notes.
A simmilar approach would not be impossible in BB4WForth, but would
need some way of holding the last note value played.
A specfic word like 'A' would then check if there had been a LastNote
played, and go up or down an octave as needed.
Some very rough thinking follows, (I don't know how AMPLE does it.)
\ Variables
VARIABLE 'LastNote'
0 'LastNote' ! \ FIXME: This should have a 'flag' value to say no
last note played.
VARIABLE 'Octave'
5 'Octave' ! \ Default is Octave 5 - (i.e Middle C)
: 'A' (-- pitch_value ) \ Leave Pitch value for 'A' on stack, rising
note, go up an octave if needed.
LastNote @ 12 MOD \ Get Last note.
\FIXME: Hmm, need to check here for a last note
actually having been player.
9 \ Note value for 'A'
> \ Is Last note Greater than 9?
IF \
Octave @ 1 + ! \If it is , need to go up one octave
\FIXME: Bounds check on octave value ?
THEN ;
12 Octave @ * \Octave for next note. (base pitch value)
9 + \Note offset for 'A'
DUP \Duplicate because the note value on the stack
will be stored.
Lastnote ! \Record the note about to played
; \Leaves pitch value on the stack
'a' for a falling note would be similar the '>' being replaced with
'<' and 'Octave @ 1 + !' becoming 'Octave @ 1 - !'
There are of course presumably some short cuts that could be used.
Andrew Haley
> On 17 Sep, 20:14, Ian Osgood <i...@quirkster.com> wrote:
> > TUCK == SWAP OVER, so SWAP TUCK == OVER
> Ah, thanks. I can't get my head around these stack manipulation
> words!
I'm not surprised. I strongly recommend that you forget about PICK,
ROLL, NIP, and TUCK until you've got used to the basic set of DUP,
SWAP, OVER, ROT, DROP and 2DUP, 2SWAP, 2OVER, 2DROP. You'll also need
>R and R>. With these you can do almost anything, and you'll find it
much easier to learn without having to cope with a zoo of unusual
stack manipulation operators.
In particular, avoid ROLL is to be avoided like the plague.
> Can I take this opportunity to check whether I've got the
> implementation of ROLL right. I get:
> 1 2 3 4 5 6 7 8
> 5 ROLL .S
> 1 2 4 5 6 7 8 3
> Is that correct?
Yes.
> Incidentally, is there any standardisation in the order in which .S
> lists the stack contents?
As above. Anything else is wrong, although the standard doesn't say.
Andrew.
Andrew Haley
> In particular, avoid ROLL is to be avoided like the plague.
Err, ROLL is to be avoided like the plague.
Andrew.
Farlie A
> Or potentially, given the 'flexibility' of FORTH syntax the ability to
> make COM Calls (provided you know the offsets inside a
> method table..)
>
> BBW does this by a dual indirection, which should feasibly be possible
> in FORTH as well using @ twice?
>
== On Calling COM methods.... ==
This got me thinking...
Assuming you have a suitable interface presumably at a defined address
could you do something like the following?
\Untested - This is just my newbie thinking...
: COMCALL (interface method_offset)
SWAP ( method interface)
DUP ( method interface interface)
ROT ( interface interface method)
SWAP ( interface method interface)
@ \ Interface address.
+ \ add method offset.
@ (interface address_of_method) \ Actual address of method
SYSCALL \Call method.
;
interface is a pointer to a table containing the addresses of
methods...
method_offset is an offset from the start of this table.
== On Windows Messages ==
On handling Windows messages, assuming you can actually intercept
messages, I suppose you could have some kind of message dispatch
table , I don't yet know how this could be set up.
Each 'table' entry occupies 2 'cells' (ie each cell is 32bit in
BB4WForth). One for the msg_number and one for the relevant word to
execute when getting that message (code pointer?). The disadvantage
is that you would need to set up a table for each window (and thus in
Windows each control) you are using. If no message matches the routine
would forward the message onto a default procedure.
The Forth code could then on receiving a message search through this
'table' indexing on message numbers, pick up the relevant 'word'
from the next cell and jump to that code... Event driven FORTH with
message queues , hmmm....
Albert van der Horst
Richard Russell <ne...@rtrussell.co.uk> wrote:
>
>C:\bbcbasic\WINDOWS\programs\forth>wina /?
>? ciforth ERROR # 8
>
>Incidentally, in each case, I was left in ciforth rather than being
>returned to the command prompt as would be normal in the case of an
>invalid command-line syntax. It's a good thing I knew about BYE!
A forth is an interpreter, and you can fix things once in it.
>
? ciforth ERROR # 8
BLOCK-FILE $@ TYPE
... \ wrong
"c:\tryouts\wina\forth.lab" BLOCK-FILE $! \ fix
BLOCK-INIT \ install
...
^H LIST \ retry
... \ Showing help already
WANT DIR
...
DIR
... \ fail
"C:\SYSTEM32\command.com" SHELL $! \ fix
...
"DIR C:" SYSTEM \ retry
... \ Showing dir all-right
DIR
... \ Showing dir all-right
etc.
WANT SAVE-SYSTEM
"c:\temp\myforth.exe" SAVE-SYSTEM
BYE
\ Get your mouse and draw the fixed system to your desktop.
Richard Russell
wrote:
> I'm not surprised. I strongly recommend that you forget about PICK,
I did use PICK in the Towers of Hanoi program below, where I wanted to
make a recursive call to a word, but with the parameters in a
different order. I've no doubt PICK could have been avoided, but it
seemed the most obvious approach for a beginner.
Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
\ "The Towers of Hanoi"
\ Translated from BBC BASIC version by Richard Russell
VARIABLE PILES
3 CELLS ALLOT \ Non-standard array declaration
: DISC ( n -- )
DUP 128 + COLOUR
DUP 0 DO 32 EMIT LOOP
DUP .
1 ?DO 32 EMIT LOOP
128 COLOUR
;
: TABXY ( x y -- )
SWAP
31 EMIT
EMIT EMIT
;
: TABDISC ( disc pile -- )
2DUP ( d p d p )
1- 26 * 13 + SWAP - ( d p x )
-ROT ( x d p )
CELLS PILES + @ -1 * 20 + SWAP DROP ( x y )
TABXY
;
: PUT ( disc pile -- )
2DUP ( d p d p )
TABDISC ( d p )
SWAP ( p d )
DISC ( p )
CELLS PILES + DUP @ 1+ SWAP !
;
: TAKE ( disc pile -- )
2DUP DUP ( d p d p p )
CELLS PILES + DUP @ 1- SWAP ! ( d p d p )
TABDISC ( d p )
DROP ( d )
2 * 2 + 0 DO 32 EMIT LOOP
;
: HANOI ( a b c d -- )
3 PICK IF
3 PICK 1- 3 PICK 2 PICK 4 PICK RECURSE
3 PICK 3 PICK TAKE
3 PICK 2 PICK PUT
3 PICK 1- 1 PICK 3 PICK 5 PICK RECURSE
THEN
2DROP 2DROP
;
: TOWERS ( n -- )
3 MODE
DUP 1 SWAP DO I 1 PUT -1 +LOOP
0 0 TABXY
." Press return to start" KEY DROP
1 2 3 HANOI
0 23 TABXY
;
12 TOWERS
Coos Haak
<snip>
>: COMCALL (interface method_offset)
> SWAP ( method interface)
> DUP ( method interface interface)
> ROT ( interface interface method)
> SWAP ( interface method interface)
Uh oh, what is the stack before: interface method
What is the stack afterwards: interface method interface
So, one word answer: OVER
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Farlie A
> Op Fri, 18 Sep 2009 04:39:09 -0700 (PDT) schreef Farlie A:
>
> <snip>
>
> >: COMCALL (interface method_offset)
> > SWAP ( method interface)
> > DUP ( method interface interface)
> > ROT ( interface interface method)
> > SWAP ( interface method interface)
>
> Uh oh, what is the stack before: interface method
> What is the stack afterwards: interface method interface
> So, one word answer: OVER
>
HTH :(
Not one of my better moments...
So that makes it something more like this.
:METHOD_ADDR (index ptr_table -- ) \ Defining as word because it
might be useful elsewhere...
@ + @
;
:COMCALL (interface method)
OVER
METHOD_ADDR
SYSCALL
;
Stephen Pelc
<use...@gfarlie.demon.co.uk> wrote:
>Or potentially, given the 'flexibility' of FORTH syntax the ability to
>make COM Calls (provided you know the offsets inside a
>method table..)
Tom Dixon's FCOM library has already been ported to several Forths,
including VFX Forth. See Examples\Win32\FCOM.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Elizabeth D Rather
> On 18 Sep, 12:04, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> I'm not surprised. I strongly recommend that you forget about PICK,
>
> I did use PICK in the Towers of Hanoi program below, where I wanted to
> make a recursive call to a word, but with the parameters in a
> different order. I've no doubt PICK could have been avoided, but it
> seemed the most obvious approach for a beginner.
>
> Richard.
> http://www.rtrussell.co.uk/
> To reply by email change 'news' to my forename.
>
> \ "The Towers of Hanoi"
> \ Translated from BBC BASIC version by Richard Russell
>
> VARIABLE PILES
> 3 CELLS ALLOT \ Non-standard array declaration
>
> : DISC ( n -- )
> DUP 128 + COLOUR
> DUP 0 DO 32 EMIT LOOP
> DUP .
> 1 ?DO 32 EMIT LOOP
> 128 COLOUR
> ;
[etc.]
Repeating phrases like DO 32 EMIT LOOP should jump out at you as a red
flag: something that should be defined and given a name. And something
as common as wanting to display a bunch of spaces is likely to
pre-exist. And, as a matter of fact, it does: the word SPACES ( n -- )
is in CORE, and therefore should be present in all systems. If
Jonesforth doesn't have it, you should add it. And stay alert for
opportunities like that!
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Richard Russell
> Repeating phrases like DO 32 EMIT LOOP should jump out at you as a red
> flag: something that should be defined and given a name.
I don't entirely agree. In one place the space character is being
used to 'draw' the disc, and in another place to 'erase' it. It's
entirely possible that one might want to change the 'drawing'
character to some other symbol, but one would never want to change the
'erasing' character. So using a common word (or indeed SPACES)
throughout, whilst it would correctly reproduce the functionality of
the existing program, could misleadingly imply that the 'draw' and the
'erase' operations are necessarily the same, which they are not.
Probably I should have used a symbolic value, rather than 32, for the
'drawing' character but SPACES for the erasing.
> If Jonesforth doesn't have it, you should add it.
Hmm, I really don't think you're in any position to tell me what I
"should" or should not do! Fortunately I don't need to worry about
it, because my brief diversion from BBC BASIC to Forth is now at an
end; I will be pleased to return to a language with which I am more
comfortable.
Richard.
http://www.rtrussell.co.uk/
Jerry Avins
Actually, she is in an excellent position to tell you what you would be
wise to do. A tip: if Elizabeth's advise seems worthless, you probably
don't understand what's involved.
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Richard Russell
> Actually, she is in an excellent position to tell you what you would be
> wise to do. A tip: if Elizabeth's advise seems worthless, you probably
> don't understand what's involved.
Her "advice" is very welcome, and I respect it. However I do not
accept that I have any responsibility for 'improving' Jonesforth, in
the way that is implied by being told that I "should" make additions
to the code. Jonesforth already suffers from its author having been
relatively new to the language, and it could be made even worse by
being fiddled with by another novice!
In any case the issue raised by Elizabeth doesn't arise, because
Jonesforth already has SPACES.
The reason for listing the Towers of Hanoi program was not to elicit
petty criticisms, but to seek advice on whether my use of PICK was
appropriate (Andrew having said I should "forget about it"), and if
not how it could have been avoided.
MarkWills
I'm with Elizabeth on this one too ;-)
Richard, your point is a valid one, but with a little factoring you
could have a generic routine that draws a disc, which takes a colour
from the stack. With use of CONSTANTs, it could result in very
readable high-level Forth, something to which most Forth programmers
aspire. Having said that, I realise Forth is not your primary
language.
As a forth Newbie myself, I can't resist, so please allow me to
indulge myself...
10 CONSTANT DRAW \ choose your own colour here
0 CONSTANT ERASE \ screen background colour
: DISC ( x y colour -- ) ..... ..... ..... ; code to draw a disc on
screen
This would result in rather pleasing looking code like:
10 10 DRAW DISC
or
10 10 ERASE DISC
(for example)
(or maybe, even better)
X Y DRAW DISC
X Y ERASE DISC
Factoring is the kind of holy-grail in Forth programming. Although I
appreciate your main language is BBC Basic, so yes, I wouldn't spend
days refactoring either, sometimes you've just got to write the damned
code!
If you do find yourself bitten by the Forth Bug (!) both Elizabeth
Rather and Leo Brodie have written excellent books on the subject.
Regards
Mark