6502.org • View topic - Transportability between Forths

View unanswered posts | View active topics

Board index » 6502.org Users Forum » Forth

All times are UTC

Transportability between Forths

Page 1 of 1

[ 4 posts ]

Previous topic | Next topic

Author

Message

IamRob

Post subject: Transportability between Forths

Posted: Sat Jan 30, 2021 8:13 pm

Joined: Sun Apr 26, 2020 3:08 am
Posts: 357

Code:

                    DEFINITION FIELD ADDRESS CONVERSION OPERATORS

                                         by

                                    Kim R. Harris

          A.  INTRODUCTION

          The standard provides a transportable way to obtain the
          compilation address of a definition in the dictionary of a FORTH
          system (cf., FIND and ' ).  It also provides an operator to
          convert a compilation address to its corresponding parameter
          field address.  However, the standard does not provide a
          transportable way to convert either of these addresses to the
          other fields of a definition.  Since various FORTH
          implementations have different dictionary structures, a standard
          set of conversion operators would increase transportability and
          readability.

          A set of words is proposed which allows the conversion of any
          definitions field address to any other.

          B.  GLOSSARY

          In the following words, the compilation address is either the
          source or the destination, so it is not indicated in the names.

          >BODY        addr1 -- addr2                            "to-body"
               addr2 is the parameter field address corresponding to the
               compilation address addr1.

          >NAME        addr1 -- addr2                            "to-name"
               addr2 is the name field address corresponding to the
               compilation address addr1.

          >LINK        addr1 -- addr2                            "to-link"
               addr2 is the link field address corresponding to the
               compilation address addr1.

          BODY>        addr1 -- addr2                          "from-body"
               addr2 is the compilation address corresponding to the
               parameter field address addr1.

          NAME>        addr1 -- addr2                          "from-name"
               addr2 is the compilation address corresponding to the name
               field address addr1.

          LINK>        addr1 -- addr2                          "from-link"
               addr2 is the compilation address corresponding to the link
               field address addr1.


          The previous set of words is complete, but may be inefficient for
          going between two fields when one is not the compilation address.
          For greater efficiency, additional operators may be defined which
          name both the source and destination fields.

          N>LINK       addr1 -- addr2                       "name-to-link"
               addr2 is the link field address corresponding to the name
               field address addr1.

          L>NAME       addr1 -- addr2                       "link-to-name"
               addr2 is the name field address corresponding to the link
               field address addr1.


          C.  DISCUSSION

          The previous words provide a complete, consistent, and efficient
          set of definition field address conversion operations.  They can
          be implemented in a FORTH system which uses any combination of
          the following options for its dictionary structure:

               Link fields first or second.
               Fixed or variable length name fields.
               Additional fields in the definitions structure.
               Heads contiguous or separated from bodies.
               Indirect, direct, subroutine, or token threaded code.

          The words are compatible with this standard; their inclusion
          would not require other changes to be made to the standard.

Thanks Jim Boyd for posting this in another thread. It goes a long way to helping understand the thinking used in some of the more advanced Forths. It pretty much covers every instance of every way the header could be organized and how each field is accessed.

Are there any other words or contradiction of words between computers that should be mentioned?

For instance, Is a word always 16-bits or on a 32-bit computer, a word is considered 32-bits and on a 64-bit computer a word is considered 64-bits? Same question with a double word?

Is [/b]CELLS[/b] always 2 * or on a 32-bit computer it is 4 * and 64-bit computer is 8 *?

Personally, I think there should be a word for Computer Bit Width (CBW), then you just have to changed one word, and all the other words automatically calculate.

16 constant CBW

Instead of changing CELLS to 2*, 4* or 8*, one just changes the constant CBW according to the computer one is using.
Now any word that needs the bit width calculated, becomes like this:

: CELLS CBW 8 / * ;

Any other words any one can think of to help in transportability can be listed in this thread for reference. I am also looking for the words that anyone has thought of themselves and may not be a part of any standard that can help in transportability, or if there are other references to new standards like the one above can be posted here. I think it is just as important to have forward compatibility as it is to have backward. Pointing out those references helps older Forth users to adopt the wording used in the newer Forths.

If it wasn't for the patient people in this forum, I still don't think I would have understood the context in which >BODY was being used.

Thanks for all contributions.

Top

GARTHWILSON

Post subject: Re: Transportability between Forths

Posted: Sat Jan 30, 2021 8:33 pm

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California

I myself have not been too interested in portability, because of the way I use Forth. If you want to do a search though, you'll probably get better results if you search for "portability" or "portable" than you will with "transportability" or "transportable." Although there are things about ANS that I don't think are suitable for 65xx, I know that one thing impeding the acceptance of Forth has been that we independent-minded, free-thinking Forthers all tend to do things our own way. That's a strength of Forth, that it allows us to do that possibly more than any other HLL; but it makes it harder for someone who wants to get into it and is looking over the options and just finds more confusion because he can't find agreement between versions. I remember letters to the editor in Forth Dimensions magazine in the early 1990's lamenting that a problem standing in the way of acceptance of Forth is that there was no effective standard. That was before ANS Forth. The X3J14 committee had a huge task on their hands which was not easy. They did the best they could, I believe, and still ruffled a lot of feathers because there was no way to make everyone happy in some areas. Jack Woehr of Vesta Technologies who was on the X3J14 committee says in his book "Forth: The New Model", "When Forth, which some hold to be inextricably wedded to hardware, takes responsibility for cross-platform portability, a certain light-footedness and grace will be surrendered." He admits that optimum portability and optimum efficiency don't come at the same point. Fortunately he also says it's not the committee's intention to force anyone to comply with the standard.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Top

IamRob

Post subject: Re: Transportability between Forths

Posted: Sun Jan 31, 2021 3:55 am

Joined: Sun Apr 26, 2020 3:08 am
Posts: 357

GARTHWILSON wrote:

[color=#000000]I myself have not been too interested in portability, because of the way I use Forth.

If the way use Forth is not some secret for work, I'd like to hear more about it. Other peoples ideas gives me ideas.

Quote:

If you want to do a search though, you'll probably get better results if you search for "portability" or "portable" than you will with "transportability" or "transportable." Although there are things about ANS that I don't think are suitable for 65xx, I know that one thing impeding the acceptance of Forth has been that we independent-minded, free-thinking Forthers all tend to do things our own way. That's a strength of Forth, that it allows us to do that possibly more than any other HLL; but it makes it harder for someone who wants to get into it and is looking over the options and just finds more confusion because he can't find agreement between versions. I remember letters to the editor in Forth Dimensions magazine in the early 1990's lamenting that a problem standing in the way of acceptance of Forth is that there was no effective standard.

Probably because too many people involved wanted to have a say in the standard. When Microsoft Basic was written, I don't think Gates went out and asked a whole bunch of people their opinion. He just wrote it and got a patent so nobody could copy his code easily making him the only boss in town that could change Basic.

Quote:

That was before ANS Forth. The X3J14 committee had a huge task on their hands which was not easy. They did the best they could, I believe, and still ruffled a lot of feathers because there was no way to make everyone happy in some areas. Jack Woehr of Vesta Technologies who was on the X3J14 committee says in his book "Forth: The New Model", "When Forth, which some hold to be inextricably wedded to hardware, takes responsibility for cross-platform portability, a certain light-footedness and grace will be surrendered." He admits that optimum portability and optimum efficiency don't come at the same point. Fortunately he also says it's not the committee's intention to force anyone to comply with the standard.

I am not looking for so much of meeting the standard of more modern Forth's. Just understanding and using some/most/all of the words that are supported by newer Forths.

I wouldn't consider words linked to direct hardware calls should be a part of any standard, but I think those words could have at least be given a mention where flexibility, hence the light-footedness, might be needed.

You are probably the most advanced Forth user in this Forum, Garth, and I thank you for sticking around to answer silly questions. I imagine once most people get to a certain expertise level, they drift away from the forums.

I have found quite a bit of reading material for the 83 and Ansi standards, but my problem is that if I don't understand its function or use case and it doesn't mention if the word is being used, as in most cases to aid in portability, or if it is a new word with a totally different meaning from other Forths, then I get lost trying to port some programs to my Forth. Most of the listings of games/programs I have found so far follow the Ansi standard. For the most part, I think I can re-create them in my Forth. I just need to be able to understand the intent or function of some of the words.

Top

GARTHWILSON

Post subject: Re: Transportability between Forths

Posted: Sun Jan 31, 2021 5:03 am

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California

IamRob wrote:

GARTHWILSON wrote:

I myself have not been too interested in portability, because of the way I use Forth.

If the way use Forth is not some secret for work, I'd like to hear more about it. Other people's ideas gives me ideas.

My pages on my workbench computer will give a good idea of it, at http://wilsonminesco.com/BenchCPU/, which I put a fair amount of work into. Someone else on this forum said it was a "Swiss army knife of the workbench." It started with a 65c02, and later WDC sent me a couple of 65802's when they were still producing them, so I put that in. The '802 is an '816 where at one of the final stages of the wafer fab, they make a small change (kind of like selecting jumper options) that makes it able to drop into an '02 socket. Obviously then you won't get the 16MB memory addressing, but the other capabilities of the '816 are there except the VDA and VPA pins and probably a couple of other minor things I'm forgetting. I wrote my '816 Forth on this but still have not had a chance to run it on something with the 16MB memory map, only the first 64KB. I wrote this Forth to take advantage of the extra capabilities of the '816 though. A year ago I had another chance to work on it further, so I had that EPROM in the workbench computer, and forgot, and loaded an application I had developed for the '02 Forth. IIRC, it all compiled, and mostly ran.

Quote:

My main use of Forth has been with my one-of-a-kind workbench computer, and before that, with the automated test equipment I designed, built, and programed at my last place of work around 1990 (see http://6502.org/users/garth/projects.php?project=6), so yes, it is very hardware-oriented. I am aware of (but have not used) modern high-end Forths for 64-bit machines that have many thousands of words. We really don't have room (or use) for that on a 6502. As for standards though, there are of course many words in common usage that are not part of any official standard; so when I found that various words I wrote were in common usage but had different names, I changed my names to match common usage. One example is RANGE, which tells if n1 is in the range of n2 to n3, which of course I used a lot in the automated production test equipment, to see if a test result was within acceptable limits. I found that others did the same thing and called it BETWEEN, and that it almost made it into ANS Forth under that name; so I changed the name of mine to match. So in a way, common usage itself becomes a standard.

Quote:

You are probably the most advanced Forth user in this Forum, Garth, and I thank you for sticking around to answer silly questions. I imagine once most people get to a certain expertise level, they drift away from the forums.

You're welcome; but I think that credit would have to go to Dr. Brad Rodriguez, forum name, Brad R. (See a list of his Forth publications, with links, at https://www.bradrodriguez.com/papers/ .) He was a regular contributor to Forth Dimensions magazine when it was being published. Jim Boyd obviously knows his C64 Forth super well, and then there's Jeff Laughton ("Dr Jefyll"), Samuel Falvo ("kc5tja" who's quite involved with the SVFIG, ie, Silicon Valley Forth Interest Group), Bruce Clark ("dclxvi"), and others. However, we all have experience and knowledge that the others don't have; so it's good that we can bounce ideas off each other, and find answers we hadn't thought of. The answers I'm sure we all like the most are where it's obvious how it works, and right away you say, "Wow, of course! Why didn't I think of that?!"

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Top

Page 1 of 1

[ 4 posts ]

Board index » 6502.org Users Forum » Forth

All times are UTC

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum