View unanswered posts | View active topics It is currently Tue Jun 18, 2019 9:32 am



Reply to topic  [ 57 posts ]  Go to page Previous  1, 2, 3, 4
 FIgForth RTF6809 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 874
Location: Canada
I think (FIND) and FIND works, I put some code in to dump out the links as FIND traversed the dictionary. It seemed to trace down to the right link. (I had to fix a bad link in the list). I also made FIND slightly more bullet-proof. There was garbage in the input buffer with the high bit set, and that confused FIND. It wouldn't normally be a problem because there shouldn't be garbage in the input buffer. I also dumped keystrokes being entered into the input buffer and it seems to work now.
It's got to be close to working, I've traced it into INTER.

I suspect the message number is goofy because the numeric conversion routines aren't working properly. I had to code U/, used by MSMOD in numeric conversion, and I likely made a mistake somewhere. I'm just trying to dump the results now.

It's a pita because it takes about 20 min to re-build the system for each software change. I got tired of doing this and started working on another project (FT832) which has slowed me down even more.

I haven't tracked down why it hangs yet. Obviously there's a loop somewhere to be broken.

_________________
Robert Finch http://www.finitron.ca


Sun Nov 01, 2015 4:21 am
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 180
Quote:
I haven't tracked down why it hangs yet. Obviously there's a loop somewhere to be broken.

OK, it's INTERPRET that repeatedly uses WORD to get the next $20-delimited word from the input stream and then tries to FIND it or subject it to numeric conversion. But -- in FIG Forth at least -- INTERPRET uses not a LOOP but a BEGIN AGAIN construct, and accordingly has no exit (!). What happens instead is kinda mind-numbing.

The input stream comes from TIB (terminal input buffer), which is filled with zeroes before the command line is entered. Thus the final word always has zeroes after it -- and zero is an unconditional delimiter for WORD. After WORD has gone past the last normal, $20-delimited word in the input stream, the next invocation of WORD will look at the zeroes at the end of the buffer and return a word whose length is one and whose only character is zero. Forth searches the dictionary for such a word, and, incredibly enough, it exists! Known by the pseudonym X, its HL source code is on screen 45. X contains the sequence R> DROP which means that, after X has executed, control reverts not to X's caller but to the caller's caller. This is how we escape from the inescapable BEGIN AGAIN construct in INTERPRET. There's this bizarre, invisible word that Beams You Up. :shock: :roll: :ugeek:

WORD is written to accept zero as an unconditional delimiter -- and it views two or more zeroes as a one-character word delimited by the 2nd zero. (FIND) needs to deem the Name Field of X a match to the one-character word returned by WORD.

Zeroes also appear at the end of the disk buffers so X can do a similar job there. "Input stream temporarily exhausted -- time to get out of this rut." I don't know what to say about this extraordinary piece of coding -- whether to applaud or barf !!

(In the event of an error such as failed numeric conversion ERROR is executed which calls QUIT and reinitiates the system -- no escape from the BEGIN - AGAIN in INTERPRET is required.)

_________________
http://LaughtonElectronics.com


Sun Nov 01, 2015 5:48 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1188
Excellent digging!


Sun Nov 01, 2015 9:42 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 874
Location: Canada
I'm getting to know the internal workings of Forth fairly well. A few more years and I'll be an ace.

I'm getting further and further little bits at a time. It's all almost exclusively software mistakes when porting from the 6502 version of the code. The U/ routine had a fix to it because I forgot the carry sense is inverted for the 6809 with respect to the 6502. The latest fix was to the EXEC routine where I realized it was supposed to do a doubly indirect jump like the NEXT routine. I had coded only a singly indirect jump. The single level of indirection was causing a hang. So now that it's fixed what happens ? It still hangs elsewhere. It's tricky code to get right. For instance PLOOP was doing an extra iteration because the 6809 code wasn't ported quite right. In the 6502 code the carry is being cleared CLC'd before a subtract rather than the usual process of being set. This causes one extra to be subtracted during the compare. The code had to be properly mimicked for the RTF6809.

I'm not very fond of the stack manipulation trickery involved in getting things like INTER to exit. It's difficult to see how things work.

_________________
Robert Finch http://www.finitron.ca


Sun Nov 01, 2015 8:13 pm
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 180
BigEd wrote:
Excellent digging!
Thanks, but the secrets aren't that hard to unravel. Back in the 20th century I wandered wide-eyed through it all.
robfinch wrote:
It's difficult to see how things work.
In fairness, the trick is documented, although not extensively (and not in the assembly listing). If you haven't gotten a copy of the FIG Installation Manual and Glossary then I strongly recommend you do so -- without it you're under a drastic handicap. (I never read any book about Forth. Although not ideal the FIG docs were at least sufficient, I found. And I made lots of notes in the margins, thank goodness.)

The Glossary has this to say about X...

    "This is the pseudonym for the "null" or dictionary entry for a name of one character of ASCII null. It is the execution procedure to terminate interpretation of a line of text from the terminal or within a disc buffer, as both buffers always have a null at the end."

... and, to a trained eye, the inclusion of R> DROP (in the source-code for X on screen 45) is about as likely to go unnoticed as if your Sunday-School teacher uttered the F-word! =8-o

J. :)

_________________
http://LaughtonElectronics.com


Mon Nov 02, 2015 9:24 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 874
Location: Canada
Quote:
If you haven't gotten a copy of the FIG Installation Manual and Glossary then I strongly rec

I found a copy ! The glossary has been really helpful.

Fixed a problem with Forth hanging. I got the byte order mixed up in one spot. 6809 is big endian, not little endian, another issue to contend with in porting the 6502 version. Forth works much better now and I can enter "BASE @ ." and get the response "10 OK" back. However, converting numbers isn't working. If I enter in something like "5 3 * ." It responds with "0 OK" Last time I check 5 * 3 wasn't zero. Well I just entered in "1 2 + ." and got back "3 OK"

_________________
Robert Finch http://www.finitron.ca


Tue Nov 03, 2015 1:34 am
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 180
robfinch wrote:
Well I just entered in "1 2 + ." and got back "3 OK"
There was no numeric conversion involved in inputting 1 and 2. Forth has a constant named 1 whose value is 1 -- ditto for a few others (0 2 3 IIRC). But apparently the output conversion (to yield 3) worked.

Glad to hear about the progress!

_________________
http://LaughtonElectronics.com


Tue Nov 03, 2015 1:43 am
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 180
For troubleshooting when the numeric stuff isn't yet working reliably, you might consider coding a word called HEX. (or whatever). It does what . does but always in hex.

HEX. simply splits your value into 4-bit nibbles and prints the nibbles by direct conversion to ASCII. It's crude, but at least you can know with certainty what the number is you have on stack. :roll:

_________________
http://LaughtonElectronics.com


Tue Nov 03, 2015 1:49 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 874
Location: Canada
Quote:
For troubleshooting when the numeric stuff isn't yet working reliably, you might consider coding a word called HEX. (or whatever). It does what . does but always in hex.

HEX. simply splits your value into 4-bit nibbles and prints the nibbles by direct conversion to ASCII. It's crude, but at least you can know with certainty what the number is you have on stack.

I've tried placing a value on the stack (123456578) then calling . And it works, . correctly displays the value. I think it's on the input side that it doesn't scan a number correctly from the text buffer. I've modified the TRACE routine to dump the top four elements on stack if the letter 's' is pressed. When I trace through the number routine I can see the current character being picked up from DIGIT and the base 10 on the stack, but there are also a couple of zeros on the stack and the number doesn't seem to accumulate digits correctly. I've looked at SWAP and ROT and a few others, but I can't see them not working. I'm convinced it has to be a problem somewhere with the converted assembler code and not the code written in Forth.

_________________
Robert Finch http://www.finitron.ca


Wed Nov 04, 2015 5:24 am
Profile WWW

Joined: Tue Dec 31, 2013 2:01 am
Posts: 98
Location: Sacramento, CA, United States
robfinch wrote:
... If I enter in something like "5 3 * ." It responds with "0 OK" Last time I check 5 * 3 wasn't zero ...


That's where I would concentrate my efforts, if I was in your shoes. Perhaps another "endian" issue, this time in U* ?

Mike B.


Wed Nov 04, 2015 7:14 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 874
Location: Canada
Quote:
That's where I would concentrate my efforts, if I was in your shoes. Perhaps another "endian" issue, this time in U* ?

Studying U* some more and comparing to the 6502 version, I realized it produces a 64 bit result analogous to the 32 bit result for the '02. I noticed that the high order bits of the product are dropped in a couple of places, but not in PNUM. In PNUM, DPLUS is used. I had to write a 64 bit DPLUS routine I called D64PLUS for use in PNUM. Using a 64 bit add routine now things seem to work. It's interesting to note that the 6502 version places the high order 16 bits of the product at the lowest memory address. This is a kind of confused big-endian format where elsewhere in the 6502 version little endian is used.
I type in "31 21 * ." and got back "651 OK" Hurray!
I need a more sophisticated test routine now. But I have no way to save / restore it from some media. I need to get the SD card going again.

_________________
Robert Finch http://www.finitron.ca


Wed Nov 04, 2015 6:12 pm
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 180
Hurray, indeed!

As for "endianness," FIG implements a virtual machine. The host CPU could be big- or little-endian, but detail like that are hidden as much as possible -- FIG has nothing to say on the subject.

FIG does expect the most-significant word of a double to be most accessible on stack. But FIG doesn't even assume that stacks grow "down" in memory! What if the host CPU has a stack that grows up? FIG makes no assumptions.

SP@ will return the host CPU's SP, but any program that makes use of that value is tinkering under the hood, so to speak, and may fail when run on FIG hosted by a different CPU.

_________________
http://LaughtonElectronics.com


Thu Nov 05, 2015 12:25 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 57 posts ]  Go to page Previous  1, 2, 3, 4

Who is online

Users browsing this forum: No registered users and 1 guest


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

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software