Forth on 6502 
Author Message
 Forth on 6502

I'm new to Forth.  Actually I know nothing about it.  I am building a robot
that uses a 6504 CPU (similar to a 6502 but only 8K of memory).  Someone
suggested using Forth as an OS.  They said I could get a small version of
it that would fit inside 2K.  Does anyone know of such a thing?

Please reply by e-mail as I do not frequent this group.

Thank you.
--
Robb Bates
Computer Cures



Wed, 19 Jan 2000 03:00:00 GMT  
 Forth on 6502

I have been in my own little corner, using my own little FORTH. For the
Strong Arm I want an ans standard forth. So I really need to discuss
problems I dealt with last time around by simple rewriting words to suit
myself. I would like to use some sort of standard solution if there is
one.

First is this the right place or is the some other list somewhere?

My questionas are.

FIND

As it is, FIND is tied to CONTEXT and the vocabulary structure. There is
need for a word to search an arbitary linked list ( would help for
instance in dealing with LOCALS and MODULES), but is also useful when
dealing with data structures not related directly to forth. FIND could
be based on this word.

My proposal is:

\ c-addr = count string to find.
\ wid    = head of linked list
\ lfa    = link field address of word matching
LOCATE ( c-addr wid -- lfa )

Is there any other standard convention.

WORD

My problems with WORD have been delt with in part by PARSE. I would have
used something that placed, where I told it, a counted string
representing the next token. PARSE gives you the data needed for sush a
word so it's a better alternative. Further you can tidy up the
characters as required for a speedy search.

It would be also nice if you had the option of altering the rules from:
" look for a single termination character " to something more complex.

To this end I think I will vector to PARSE through a word caller PARSER.

I couldn't find in the standard anything that says I have to use WORD to
get the token used by FIND. So I can't see why I then couldn't use
LOCATE and PARSER to build up the method I want.

\ method-code = char for PARSE
\ method = 0 for PARSE
\ c-addr length = describes next token.
\
PARSER ( method_code method -- c-addr length )

Once again any other convention.



Thu, 20 Jan 2000 03:00:00 GMT  
 Forth on 6502



Quote:
>I have been in my own little corner, using my own little FORTH. For
>the Strong Arm I want an ans standard forth. So I really need to
>discuss problems I dealt with last time around by simple rewriting
>words to suit myself. I would like to use some sort of standard
>solution if there is one.

Consider the reasons you might want a standard Forth instead of some
other.

1.  You might want to sell it or sell applications using it, and those
who buy might value standard label.

2.  You might want to make it easier to import code from other sources;
a standard compiler can easier import standard code.

3.  You might want to make it easier to export your code to other Forth
systems; if you're careful to use only standard features then your code
will be much easier to export to other standard systems.

4.  You might want to make it easier for other programmers to write
code for your system or read your code; the closer it is to standard
the easier this will be for programmers who're familiar with the
standard.

I can't think of any other reasons to make it standard.  (Maybe others
will share some other reasons.)  If the reasons don't apply, then don't
feel constrained to the standard.

Quote:
>My questionas are.
>FIND
>As it is, FIND is tied to CONTEXT and the vocabulary structure. There
>is need for a word to search an arbitary linked list ( would help for
>instance in dealing with LOCALS and MODULES), but is also useful when
>dealing with data structures not related directly to forth. FIND could
>be based on this word.

There's no standard way to search both a vocabulary and an arbitrary
linked list.  Vocabularies don't have to be linked lists.  If you
assume they are and assume that something you build using standard
parts will do both of these, you have an "environmental dependency".
Your code will only run on systems that do it your way, and some
standard systems won't.  If you _can_ do it and you choose to do it,
then just write up what it is you're depending on and keep going.

Quote:
>My proposal is:
>\ c-addr = count string to find.
>\ wid    = head of linked list
>\ lfa    = link field address of word matching
>LOCATE ( c-addr wid -- lfa )
>Is there any other standard convention.

There's an optional standard word SEARCH-WORDLIST that does part of
what you want.

SEARCH-WORDLIST ( ca len wid -- xt -1 | xt 1 | 0 )

wid is not necessarily the head of a linked list, but if you always
want to start with a wordlist it will work.  You can't depend on it
working with other system's locals or linked lists.  It uses a
string-and-count instead of a counted string, which should be no
problem.  It returns the execution token rather than the lfa.  It's the
standard tool that's available, and if you can build what you want out
of it then you're set --  build LOCATE with it, and you can port LOCATE
to other systems.

Converting from counted string to string-and-count is easy, what's
harder is to go the other direction.

: LOCATE ( ca wid -- xt -1 | xt 1 | 0 )
     >R COUNT R> SEARCH-WORDLIST ;

If you really need an lfa then you're out of luck with the standard,
some standard systems may not have such a thing.  But you could do it
Forth-83 standard and it should run on Forth-83 systems.  There are a
lot of them.  It would be easy to document that you need standard
systems that use Forth-83 headers.  That's simple to explain.

Quote:
>WORD
>My problems with WORD have been delt with in part by PARSE. I would
>have used something that placed, where I told it, a counted string
>representing the next token. PARSE gives you the data needed for sush
>a word so it's a better alternative. Further you can tidy up the
>characters as required for a speedy search.

Yes, I like PARSE too.  Note though that if you do BL PARSE it will
stop at the first blank, not the first blank after a word.

Quote:
>It would be also nice if you had the option of altering the rules
>from: " look for a single termination character " to something more
>complex.

You can write something more complex using words from the optional
String wordset.  SEARCH is useful, it lets you find one string inside
another.  There are various pattern-recognition things available.
There's a certain overhead to doing that sort of thing, but it can be
done using standard commands.  If that part of your system can be
written in standard code, then user code that depends on it is portable
if that chunk of the system is ported too.

Quote:
>FIND
>I couldn't find in the standard anything that says I have to use WORD
>to get the token used by FIND. So I can't see why I then couldn't use
>LOCATE and PARSER to build up the method I want.

You can.  But it's easier if you don't _have_ to build a counted string
before you search.  FIND needs the counted string.  You can rewrite
FINDER using SEARCH-WORDLIST to use a string-and-count.  The high-level
code is portable but likely slow.  OK, if you supply high-level code
and actually use an optimised form that has the same result but faster,
everything's fine.  It's portable to other systems, and your system
will run it better.  8-)  FINDER might be defined something like:

: FINDER ( ca len -- xt 1 | xt -1 | ca len 0 )
   2>R GET-ORDER BEGIN
     ?DUP WHILE

     2R> 2DROP ELSE
     2R> 0
   THEN ;

This simple routine has obvious problems, like if you have the same
wordlist present multiple times it will get searched again each time,
but it should get the idea across.

\ method-code = char for PARSE
\ method = 0 for PARSE
\ c-addr length = describes next token.
\ PARSER ( method_code method -- c-addr length )

\ Once again any other convention.

What I described is pretty much what's available for standard Forth,
and it uses optional words.  It doesn't do quite what you want.  If you
include the standard commands in your system, your users can use them.
If you make those be integral parts of your system, they might limit
you a bit.

Let's go back to our reasons to make a standard system:

1.  Customers might want it, independent of the good it does them.
2.  Ease import of standard code.
3.  Ease export of user code.
4.  Ease programmer adaptation to your system.

None of these require you to build your system any particular way,
except that some ways make it hard to implement some of the standard
words.  Maybe the thing to do is to look carefully at what the standard
requires that you *can* do, and then build your system however you like
that lets you do those things.

The standard is not intended to be either an execution standard or a
publication standard -- it's an interface standard.



Thu, 20 Jan 2000 03:00:00 GMT  
 Forth on 6502

Quote:



> >       <snip>
> Yes, I like PARSE too.  Note though that if you do BL PARSE it will
> stop at the first blank, not the first blank after a word.

The IEEE Open Firmware Standard includes the word

        PARSE-WORD ( "<spaces>text<space>" - ca cc )

which skips leading whitespace before marking a non-whitespace token.
Very useful 8-)

John Rible
===
SandPiper Technology, 317 California St, Santa Cruz, CA 95060-4215
408-458-0399

408-471-0175



Sat, 22 Jan 2000 03:00:00 GMT  
 Forth on 6502


writes:

Quote:



>> >   <snip>
>> Yes, I like PARSE too.  Note though that if you do BL PARSE it will
>> stop at the first blank, not the first blank after a word.
>The IEEE Open Firmware Standard includes the word
>    PARSE-WORD ( "<spaces>text<space>" - ca cc )
>which skips leading whitespace before marking a non-whitespace token.
>Very useful 8-)

Thank you, particularly for that stack diagram.  Wasn't there a
disagreement here recently about how that should go?  It makes sense to
me that the ones who use the word differently should change their name,
unless they have such a big body of code built up that it's not
practical.


Sat, 22 Jan 2000 03:00:00 GMT  
 Forth on 6502



Quote:


>> writes:
>>...
>> >The IEEE Open Firmware Standard includes the word
>> >   PARSE-WORD ( "<spaces>text<space>" - ca cc )
>> >which skips leading whitespace before marking a non-whitespace
>> >token.  Very useful 8-)
>> Thank you, particularly for that stack diagram.  Wasn't there a
>> disagreement here recently about how that should go?  It makes sense
>> to me that the ones who use the word differently should change their
>> name, unless they have such a big body of code built up that it's
>> not practical.
>    The other logic is to have the more low-level word have the more
>compact word. You can use PARSE in writing PARSE-WORD, but not
>conversely, which is just what the names would suggest.

I'm not sure I understand.  I thought there was a clash here among
people who had words named PARSE-WORD that did different things.  I
don't remember now exactly, maybe one of them took a delimiter and the
other (like the Open Firmward versin) used blank.


Sun, 23 Jan 2000 03:00:00 GMT  
 Forth on 6502


Quote:

> writes:
>...
> >The IEEE Open Firmware Standard includes the word

> >       PARSE-WORD ( "<spaces>text<space>" - ca cc )

> >which skips leading whitespace before marking a non-whitespace token.
> >Very useful 8-)

> Thank you, particularly for that stack diagram.  Wasn't there a
> disagreement here recently about how that should go?  It makes sense to
> me that the ones who use the word differently should change their name,
> unless they have such a big body of code built up that it's not
> practical.

        The other logic is to have the more low-level word have the more
compact word. You can use PARSE in writing PARSE-WORD, but not conversely,
which is just what the names would suggest.

Virtually,

Bruce R. McFarling, Newcastle, NSW



Sun, 23 Jan 2000 03:00:00 GMT  
 Forth on 6502

Quote:



> > The IEEE Open Firmware Standard includes the word

> >         PARSE-WORD ( "<spaces>text<space>" - ca cc )

> Is the IEEE Open Firmware standard on line somewhere, if not does anyone
> know the number so I can order a copy.

Yes, but I forget the address.  There's a link from our site (see
below).
In any case, it's IEEE 1275.

Cheers,
Elizabeth

--
===============================================
Elizabeth D. Rather              1-800-55-FORTH
FORTH Inc.                         310-372-8493
111 N. Sepulveda Blvd.        Fax: 310-318-7130
Manhattan Beach, CA 90266
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
===============================================



Sun, 23 Jan 2000 03:00:00 GMT  
 Forth on 6502



Quote:


> > The IEEE Open Firmware Standard includes the word

> >         PARSE-WORD ( "<spaces>text<space>" - ca cc )

> Is the IEEE Open Firmware standard on line somewhere, if not does anyone
> know the number so I can order a copy.

As it is an official publication of IEEE I would doubt that a copy will exist
on-line. They want to make their money on it.

The numbers:

  "IEEE Standard for Boot (Initialization Configuration) Firmware: Core
  Requirements and Practices" IEE Std 1275-1994 published 28th October 1994.
  ISBN 1-55937-426-8

     IEEE Computer Society
     The Institute of Electrical and Electronic Engineers Inc.
     345 East 47th Street
     New York
     NY 10017-2394
     USA

     Tel: 1-800-678-IEEE
          1-908-981-1393 (From outside USA and Canada)
     Fax: 1-908-981-9667
     Web: http://www.ieee.org

--

Transport Control Technology Ltd.   <http://www.tcontec.demon.co.uk/>

Going Forth Safely



Mon, 24 Jan 2000 03:00:00 GMT  
 Forth on 6502

Quote:

> >The IEEE Open Firmware Standard includes the word

> >       PARSE-WORD ( "<spaces>text<space>" - ca cc )

> >which skips leading whitespace before marking a non-whitespace token.
> >Very useful 8-)

> Thank you, particularly for that stack diagram.  Wasn't there a
> disagreement here recently about how that should go?

Not really a disagreement IIRC, but Gforth contains a word PARSE-WORD
that does something different from the PARSE-WORD of Open Firmware and
the (nonnormative) Section A.6.2.2008 of the standard.

Given the weight of these standards, we may change the name of our
PARSE-WORD into something that does not conflict. Is there any Gforth
user that has a problems with that solution?

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed

http://www.complang.tuwien.ac.at/anton/home.html



Mon, 24 Jan 2000 03:00:00 GMT  
 Forth on 6502



Quote:
>1.  You might want to sell it or sell applications using it, and those
>who buy might value standard label.

1a. You might *need* to port to multiple targets, standard systems
reduce the cost involved. Do it well enough, and you eliminate 99% of
porting costs.

---
Visit www.dukepsx.com: see what I do all day.
Paul Shirley: my email address is 'obvious'ly anti-spammed



Wed, 26 Jan 2000 03:00:00 GMT  
 Forth on 6502

Quote:





> > > The IEEE Open Firmware Standard includes the word

> > >         PARSE-WORD ( "<spaces>text<space>" - ca cc )

> > Is the IEEE Open Firmware standard on line somewhere, if not does anyone
> > know the number so I can order a copy.

> As it is an official publication of IEEE I would doubt that a copy will exist
> on-line. They want to make their money on it.

It was on the web in May of this year, but doesn't seem to be now.  I don't
remember whether somebody already posted this URL for the Open Firmware home page:

  http://playground.Sun.COM/1275/

IEEE charges about $90 for nonmembers.

--David
 _  _________________________________________________________________
(_\(__
 _|__)  David N. Williams          Phone:  1-(313)-764-5236
__|___  University of Michigan     Fax:    1-(313)-763-2213

 \|     Ann Arbor, MI 48109-1120



Wed, 26 Jan 2000 03:00:00 GMT  
 Forth on 6502


writes:

Quote:


>>1.  You might want to sell it or sell applications using it, and
>those who buy might value standard label.
>1a. You might *need* to port to multiple targets, standard systems
>reduce the cost involved. Do it well enough, and you eliminate 99% of
>porting costs.

Thank you.

Those were my reasons 2 & 3, importing and exporting code.  You can of
course make your own standard and then _your_ code will be portable to
every system _you_ build a compiler for.  You can set a collection of
options the standard leaves open.

Similarly, you can choose a single vendor that already has a wide range
of compilers.  If you use FORTH Inc's chipFORTH, for example, your
Forth code will port to a very wide range of processors.  And if you
need a chipFORTH that they don't have yet, for a reasonable fee they
can build it for you.  If you use a feature that only chipFORTH
provides, you'll still have a tremendous portability available.

If you use standard Forth, your code will be more portable to other
systems whether they're from the same vendor or not.  You may want to
optimise it on the new system, but it's easier to optimise something
that works than to get something working that doesn't.  And if you have
a standard system, it will be easier to import other people's code.
Vendors are heading toward ANS compatibility because they want their
customers to be able to import code easier.

When programming, the choice of just how standard to make your code
depends on other questions:

Do you intend to publish?
Do you intend to port to other systems from different sources?
Will someone else need to maintain your code, someone who perhaps isn't
  very familiar with your system?
Does your client want standard code for his own reasons?

There may be other criteria, too.



Wed, 26 Jan 2000 03:00:00 GMT  
 Forth on 6502



Quote:
>Vendors are heading toward ANS compatibility because they want their
>customers to be able to import code easier.

>When programming, the choice of just how standard to make your code
>depends on other questions:

>Do you intend to publish?
>Do you intend to port to other systems from different sources?
>Will someone else need to maintain your code, someone who perhaps isn't
>  very familiar with your system?
>Does your client want standard code for his own reasons?

I think this is one of the major reasons for Forths lack of popularity.
Too many Forth users (and importantly Forth advocates) simply don't care
about portability. In many of the niches Forth currently fills thats not
a problem because the hardware never changes, but in a world where
portability matters to so many markets that lack of care guarantees
Forth will not be sold to the users that matter.

I initially learnt Forth because it promised portability between systems
with nearly the speed of assembler. Sadly the speed was missing ;)
(which is why all my games ended up in assembler)

---
Visit www.dukepsx.com: see what I do all day.
Paul Shirley: my email address is 'obvious'ly anti-spammed



Thu, 27 Jan 2000 03:00:00 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Forth for 6502?

2. Forth for 6502

3. 6502-related Forth Article

4. 6502 forth compiler ?

5. fig forth listing for 6502

6. fig-Forth 6502 listings

7. 6502 fig-forth asm source

8. Forth to generate 6502 code from PC

9. 6502 PD Forth Kernel

10. Forth for c64/6502

11. 6502 Forth question

12. 6502 figFORTH -- download me now.

 

 
Powered by phpBB® Forum Software