Getting started in Forth

Dr Jefyll · Post by **Dr Jefyll** » Sun Oct 09, 2011 4:03 pm

8BIT wrote:

I was trying to enter a double number by just typing it in. I found that it only loaded the upper 16 bits onto the data stack, not the entire 32 bits.

IIRC, with Fig Forth what you do is include a decimal point as part of the number string. This'll result in a double value (32 bits) being placed on stack.

-- Jeff

8BIT · Post by **8BIT** » Sun Oct 09, 2011 5:28 pm

I just tried it and it worked just like you said.

Thanks!!!

Daryl

Dr Jefyll · Post by **Dr Jefyll** » Sun Oct 09, 2011 6:03 pm

8BIT wrote:

it worked

Glad to hear it!

DPL (a User Variable) will retain the position of the decimal (radix?) point in case you actually need to interpret it somehow -- for fixed-point arithmetic, perhaps. But Forth makes no assumption -- you're on your own! (As usual

) Check out the Fig word NUMBER btw.

Re: tracing down the '816 wrinkle, I recall Fig has a JSR Trace that can optionally be included with NEXT. Using that, maybe you could determine approximately where things went off the rails, thus narrowing your search for the bug.

-- Jeff

8BIT · Post by **8BIT** » Sun Oct 09, 2011 7:27 pm

I had removed the trace functions but might put them back.

There is only 1 TXS instruction in the source and I replaced that with the 65816 equivalent code and now I get the Fig Forth 1.0 splash. After that, it does not respond.

Using Trace might help now.

thanks for the suggestions!

Daryl

8BIT · Post by **8BIT** » Mon Oct 10, 2011 2:09 pm

I found the page wrapping problem in two places. On a 65c02, an LDA $FE,X will wrap around back into page 0. The 65816 in emulation mode will too. However, in native mode, it will advance into page 1.

Example: X=$10, LDA $FE,X The address pointed to:
65C02 = $0E
65816 = $0E (emulation mode)
65816 = $10E (native mode)

Here's the offending code:

Code: Select all

ZBRAN     .WORD *+2
          INX
          INX
          LDA $FE,X
          ORA $FF,X
          BEQ BRAN+2

and here

Code: Select all

PPLOO     .WORD *+2
          INX
          INX
          STX XSAVE
          LDA $FF,X
          PHA
          PHA
          LDA $FE,X

Corrected code adds just one instruction:

Code: Select all

ZBRAN     .WORD *+2
          LDA $00,X
          ORA $01,X
          INX
          INX
          CMP #$00         ; <--- added 
          BEQ BRAN+2

Code: Select all

PPLOO     .WORD *+2
          LDA $01,X
          PHA
          PHA
          LDA $00,X
          INX
          INX
          STX XSAVE

The other fix I mentioned, a TXS replacement, is here:

Code: Select all

RPSTO     .WORD *+2
          STX XSAVE      ; load return stack pointer (machine
          LDY #8         ; stack pointer) from silent user
          LDA (UP),Y     ; VARIABLE R0
          TAX
          TXS

This get fixed to:

Code: Select all

RPSTO     .WORD *+2
          STX XSAVE      ; load return stack pointer (machine
          LDY #8         ; stack pointer) from silent user
          LDA (UP),Y     ; VARIABLE R0
          TAX
;          TXS
          lda  #$01      ; 65816 native mode fix
          .byte $eb      ; XBA
          txa	         ; 
          .byte $1b      ; TCS    (16 bit equiv to TXS)

FigForth now runs on a 65816 in native mode. I can now work on the disk interface.

Daryl

Dr Jefyll · Post by **Dr Jefyll** » Mon Oct 10, 2011 3:43 pm

8BIT wrote:

FigForth now runs on a 65816 in native mode.

That's terrific, Daryl -- a fine bit of debugging, and a significant contribution that others can benefit from! I wonder what's the best way to make this information find-able for someone who needs it?

BTW, re Fig FORTH, you should (if you haven't already) get your hands on the fig-FORTH INSTALLATION MANUAL by William F. Ragsdale. The Glossary he includes is invaluable. Amazon lists this document; mebbe it's downloadable somewhere as well; dunno. (Copyright permitting, it'd be a worthwhile addition to the 6502.org library!)

-- Jeff

8BIT · Post by **8BIT** » Mon Oct 10, 2011 4:02 pm

Dr Jefyll wrote:

BTW, re Fig FORTH, you should (if you haven't already) get your hands on the fig-FORTH INSTALLATION MANUAL by William F. Ragsdale. The Glossary he includes is invaluable. Amazon lists this document; mebbe it's downloadable somewhere as well; dunno. (Copyright permitting, it'd be a worthwhile addition to the 6502.org library!)

-- Jeff

I found a plain text copy online. I have been using the glossary already to help figure words out. Thanks!

GARTHWILSON · Post by **GARTHWILSON** » Mon Oct 10, 2011 6:15 pm

Daryl, I should have thought of that for you so you could save some time, but it has been years since I worked on my '816 Forth. What I did on that for 0branch (which won't work on the '02 though) is:

Code: Select all

         HEADER "0branch", NOT_IMMEDIATE
0branch: PRIMITIVE
         INX2
         LDA   FFFE,X
         BEQ   branch+2
          .
          .
          .

where HEADER is a macro that makes the header (which you omitted for brevity), PRIMITIVE is a macro which does the same thing as your ".WORD *+2", and INX2 is a macro that just puts a pair of INX's in since that's done in so many places in the kernel.

8BIT · Post by **8BIT** » Mon Oct 10, 2011 11:16 pm

That code works too.

I compared bytes used and cycles used and both your way and mine are the same - 10 cycles and 6 bytes (just affected opcodes, not entire subroutine).

Thanks Garth. Down the road, I may try to optimize this Forth for the 816, unless you find time to publish your's first. In the mean time, I still have a lot to learn.

Daryl

GARTHWILSON · Post by **GARTHWILSON** » Tue Oct 11, 2011 1:27 am

Quote:

Down the road, I may try to optimize this Forth for the 816, unless you find time to publish yours first.

I'll send you mine whenever you're ready. It's just that the explanations are not not all cleaned up as tidy as I would like it to be, especially for those who have no significant prior Forth experience. Wally Daniels (who's a member here but rarely checks in) has used it on the 65265 though. This '816 Forth is a complete re-write, not a slight modification from the '02 Forth. I was pleased to find that many of the words are not only faster as primitives (as expected), but even more memory-efficient as primitives (contrary to the situation with the '02) and sometimes even easier to write-- and certainly easier than writing the same primitives on the '02. This makes it worth having hundreds of primitives in the '816 Forth, whereas many more of the words kind of have to remain as secondaries on the '02 Forth to avoid taking up too much memory. It also results in the '816 Forth running 2-3x as fast as the '02 Forth at a given clock speed.

And again--for those who are afraid of the 816's mode bits-- You almost never take it out of 16-bit accumulator and 8-bit index registers. You leave it in those modes almost all the time. When you do change it, you use a macro so it's clear what you're doing, like "INDEX_16" instead of whatever the cryptic REP or SEP instruction is.

8BIT · Post by **8BIT** » Tue Oct 11, 2011 3:11 am

GARTHWILSON wrote:

I'll send you mine whenever you're ready. It's just that the explanations are not not all cleaned up as tidy as I would like it to be, especially for those who have no significant prior Forth experience.

I'll take you up on that in a few weeks to few months ... once I've digested the Fig-Forth installation manual and that online book.

Thanks!

Daryl

GARTHWILSON · Post by **GARTHWILSON** » Tue Oct 11, 2011 6:10 am

I should add:

It is heavily commented, including plenty of use of the DOS/ANSI [Edit: that should say IBM437] characters that were so good for drawing smooth charts and diagrams. (I know I might have to replace those characters now since few people use DOS anymore.) A documentation file gives a lot of general info about the Forth, reasons for doing various things certain ways, some philosophy, etc..
has the more-readable Forth equivalent code corresponding to the assembler source for each word. This Forth equivalent code is in kind of like shaddow-screen files (although they're text files, not screen files) with .FTH extensions instead of .ASM
has graphic explanations of parts that tend to be more confusing; for example, what the program-structure words compile, and how DOES works
various parts are in INCLude files, so for example you may want to omit math extensions or mostly replace the 816HDWR.ASM file with your own since your hardware may be quite different from mine, for example, an entirely different keypad/keyboard or display

I might come back and edit this without notice if I think of other things.

If I were a millionaire in terms of time, I would like to do another Forth, this time STC (subroutine-threaded code) which would run faster. Bruce gave a discussion here and here (two posts in the same topic) on how it is considerably more memory-efficient than initially meets the eye.

And one more thing: My fix for the UM* bug that's common in public-domain 6502 Forth is at viewtopic.php?t=689 . The bug rarely shows up, which is why I used it for 15 years without realizing it was there; but an FFT has a ton of multiplies, and it was getting messed up by the bug. I think I mentioned it recently but did not find it in the source-code repository to quickly direct you to the fix.

8BIT · Post by **8BIT** » Tue Oct 11, 2011 12:24 pm

Perfect timing - I was just searching for the fix for that. I've made those changes as well.

Thanks Garth!

dclxvi · Post by **dclxvi** » Wed Oct 12, 2011 2:19 am

The FIG site:

http://www.forth.org

links to the Taygeta archive:

ftp://ftp.taygeta.com/pub/Forth

which has a ton of interesting stuff, but it can be hard to find things. IMO, it's worth spending some time looking through it, though.

The FIG-Forth Installation Manual is here:

ftp://ftp.taygeta.com/pub/Forth/Archive ... IGINST.ZIP

The FIG-Forth 6502 assembler is here:

ftp://ftp.taygeta.com/pub/Forth/Archive ... sm6502.txt

which can be used to write CODE words (i.e. primitives). It appears to be OCR'd since the letter O appears in several places where the number zero should be, and a lowercase L appears where the number one should be. I made some fixes to a copy of this file, but have not tested those fixes.

Also of interest is this FIG-Forth implementation for the 8086, not so much the 8086 assembly source code, but specifically the block file FORTH.SCR (.lzh is an old compression/archive format, like .zip):

ftp://ftp.taygeta.com/pub/Forth/Archive/ibm/fig86.lzh

Although it looks almost like a text file, it actually consists of 64 character * 16 line blocks (and hence its length is a multiple of 1024); there are no CRLF line terminators, so your favorite text editor may barf on it. In DOS/Windows EDIT /64 FORTH.SCR does the trick. I found it helpful to turn it into a real text file containing CRLFs (I probably used awk or perl or somesuch for this, I don't really remember).

GARTHWILSON wrote:

If I were a millionaire in terms of time, I would like to do another Forth, this time STC (subroutine-threaded code) which would run faster. Bruce gave a discussion here and here (two posts in the same topic) on how it is considerably more memory-efficient than initially meets the eye.

To be clear, I should point out that any old STC implementation is not necessarily more space efficient than you'd think, but it's possible to create an implementation that is, without sacrificing too much of the speed advantages of STC.

dclxvi · Post by **dclxvi** » Sat Oct 15, 2011 7:27 pm

GARTHWILSON wrote:

Code: Select all

         HEADER "0branch", NOT_IMMEDIATE
0branch: PRIMITIVE
         INX2
         LDA   FFFE,X
         BEQ   branch+2
          .
          .
          .

By the way, you might want to make that $FFFFFE,X (i.e. long,X addressing) since abs,X will cross bank boundaries, so this will read from bank 1 (assuming the DBR is 0). I am guessing you're using this on a 64k 65C816 which ignores the bank byte.