AnyCPU
http://anycpu.org/forum/

FIgForth RTF6809
http://anycpu.org/forum/viewtopic.php?f=8&t=241
Page 3 of 4

Author:  Dr Jefyll [ Sun Oct 25, 2015 3:05 pm ]
Post subject:  Re: FIgForth RTF6809

Quote:
The program gets into the PDOTQ routine then it seems it doesn't return properly.
If it has gotten to PDOTQ then that's probably the startup greeting trying to happen. You didn't actually mention whether the greeting appears but it sounds as if it didn't. Stating the obvious, perhaps, in this case PDOTQ is supposed to suck in the "Fig-Forth 1.0" (or whatever) that's stored inline as part of ABORT and EMIT all the characters in the string. Hmm, it might be the first time PLOOP (the low-level looping construct compiled by LOOP) is used.

Quote:
Unfortunately the processor doesn't support indirect jumps via a far address.
I suppose one solution would be to alter the processor to support this. But there's another idea that may yield more bang for the buck, and that's to add a very limited repertoire of 32-bit loads & stores. NEXT would be just one of many words that would benefit from this.

FWIW you could mebbe plagiarize a few of the 6309 instructions Hitachi created -- I understand there are 32-bit registers in that chip (which as you know is a super-6809). There's some good 6309 doc here on 6502.org.

(Edit: PLOOP remark)

Author:  robfinch [ Mon Oct 26, 2015 11:16 am ]
Post subject:  Re: FIgForth RTF6809

Quote:
If it has gotten to PDOTQ then that's probably the startup greeting trying to happen. ... it might be the first time PLOOP

It is indeed the startup greeting trying to happen. It spits out the first letter 'f'. And it is the first time PLOOP is used. It may also be the first time a backwards branch is taken. I found out PLOOP fails because the branch target is calculated incorrectly. The carry flag (cf) seems not to be taken into consideration during the ADCB/ADCA instructions. It's not as if I didn't code it, but I suspect it the ole bit extension problem. I did not manually extend the cf by adding zeros at the front, so I think the synthesizer has dropped it. I'm testing this now.
IF it's coded like this {a[7:0]} + {b[7:0]} + cf it doesn't work
but if it's coded like this {a[7:0]} + {b[7:0]} + {7'b0,cf} it does work.
(I had to do this on another project already to get things to work)

Quote:
I suppose one solution would be to alter the processor to support this. ...mebbe plagiarize a few of the 6309 instructions Hitachi created

The RTF6809 is coded with additional features including some 6309 support. But these features are completely untested, and there's no assembler to support them. I have the extras disabled. One of the features is a true 32 bit mode where all the regs are 32 bits but there is no 'D' register.

I've been pondering a 32 bit accumulator cpu core design. If all that is going to be run by the cpu is a virtual machine to support a high-level interpreted language, then a simple accumulator based design might work well. The big push for register oriented designs is mainly efficient support of HLL's like 'C'.

Author:  barrym95838 [ Tue Oct 27, 2015 3:51 am ]
Post subject:  Re: FIgForth RTF6809

robfinch wrote:
... I've been pondering a 32 bit accumulator cpu core design. If all that is going to be run by the cpu is a virtual machine to support a high-level interpreted language, then a simple accumulator based design might work well. The big push for register oriented designs is mainly efficient support of HLL's like 'C'.

I love 'em! Programming accumulator CPUs in assembly is such a treat for my brain, I have to watch out, or it'll take over and interfere with the rest of my life. I'm getting so sick and tired of fixing broken cars to pay the bills ... I'm going to try prying myself out of this rut, and taking some night classes to get back up to speed for a career change, hopefully IT-related. It's gonna be stressful, but it has to be done.

Mike B.

Author:  robfinch [ Tue Oct 27, 2015 3:56 am ]
Post subject:  Re: FIgForth RTF6809

Milestone reached: fig-Forth 1.0 prompt appears. It even accepts a line of input before it hangs now. It looks to me like the EXPECT routine executed during a QUERY only terminates once 80 characters have been typed. This is the way it works when run. One would think it should quit when a CR is entered, but it doesn't look like that's the way it's coded. I wonder if this is intentional.

Hardware error: The problem was in carry calculation for non-immediate mode instructions. I forgot to register the 'a' operand during the CALC state in order to allow for carry and overflow calcs.

I experimented with double-indirect addressing, but decided to put it on the back burner after the initial test failed. Indirect-indirect indexed addressing (eg LDD [[W],Y] ) could be useful as follows: A variable in memory ('W') acts as a pointer to a table of addresses. The final effective address is selected by indexing into the table and retrieving the address value. The table could be a method address table for virtual functions in an objected oriented style. Methods could be invoked like: JSR [[W],Y] where the Y register contains the table index.

Author:  Dr Jefyll [ Tue Oct 27, 2015 2:20 pm ]
Post subject:  Re: FIgForth RTF6809

robfinch wrote:
One would think it should quit when a CR is entered, but it doesn't look like that's the way it's coded.
QUERY calls EXPECT which is what tests for the CR and, if it finds one, executes a LEAVE. LEAVE sets the loop index to the loop limit, which means next time we hit the bottom of the loop PLOOP will decide no further iterations are required. (Ie: LEAVE doesn't leave immediately -- it lets the current iteration complete.)

EXPECT is listed in screen 45 of the HL source code -- the Forth that *is* Forth. If you don't have this doc then I suggest you get it. I believe it's included with the FIG "Installation Manual."

barrym95838 wrote:
I'm going to try prying myself out of this rut, and taking some night classes to get back up to speed for a career change, hopefully IT-related.
Maybe the place to start would be with an investigation of the job market. In some areas there's growth in the alternative-energy industry -- solar, geothermal, what-have-you. Not exactly accumulator-based but more rewarding than fixin Joe's jalopy... Just a suggestion. (I'm assuming what interests me will interest you. Might not be the case! :roll: ) But certainly your extensive hands-on experience and technical & troubleshooting skills would serve you well in other industries.

Edit: clarify LEAVE

Author:  Garth [ Tue Oct 27, 2015 7:49 pm ]
Post subject:  Re: FIgForth RTF6809

Dr Jefyll wrote:
LEAVE sets the loop index to the loop limit, which means next time we hit the bottom of the loop PLOOP will decide no further iterations are required. (Ie: LEAVE doesn't leave immediately -- it lets the current iteration complete.)

I don't remember where I got my LEAVE--probably from Forth Dimensions. I did just check the ANS Forth spec though, and it says LEAVE discards the loop control parameters and continues execution immediately with the first instruction after the loop; ie, it does not finish the current iteration. That's the way I've always done it (ie, leave immediately).

Author:  Dr Jefyll [ Tue Oct 27, 2015 7:58 pm ]
Post subject:  Re: FIgForth RTF6809

Thanks Garth for pointing out that the ANSI version of LEAVE differs from the FIG version I described (and which Rob is using). I suppose each version has its strengths & weaknesses. FIG is my "native language" when it comes to Forth, so that's what I'm most familiar with!

I did make a slight boo-boo. The FIG version of LEAVE sets the limit to equal the current index, not vice versa.

Author:  robfinch [ Wed Oct 28, 2015 4:21 pm ]
Post subject:  Re: FIgForth RTF6809

I made a booboo in the LEAVE function in that I had it manipulating the wrong stack. The loop arguments are on the return stack, not the data stack! It caused all sorts of nastiness. Now LEAVE works as it does for Fig forth in the manner Dr. Jeff. described.

Author:  Garth [ Wed Oct 28, 2015 8:01 pm ]
Post subject:  Re: FIgForth RTF6809

I should have added something that might be helpful albeit non-standard. Sometimes I need to easily be able to tell later if the loop completed or was exited with LEAVE, so I use a flag I call LOOP_LEAVE. leave (the internal compiled by LEAVE) sets the flag. loop and +loop (the internals compiled by LOOP and +LOOP) clear it. Since do and ?do leave it alone, you can use it with nested loops, and it's always valid for the last loop exited or finished, and can be again for more nested loops as you work your way out of the nesting. You can also use it in words with loops that get called from within a loop, including being able to test it after they return.

I also use ?LEAVE to shorten IF LEAVE THEN.

Author:  robfinch [ Thu Oct 29, 2015 2:52 pm ]
Post subject:  Re: FIgForth RTF6809

Quote:
so I use a flag I call LOOP_LEAVE.

It seems like a reasonable idea, and shouldn't be that hard to implement. The LEAVE statement reminds me of 'C''s 'break' statement. Although the 'break' statement also acts to end case statements in a switch.

One thing that has impressed me is that Forth uses very little state. It hardly uses any zero page locations at all.

I allocated a 1k return stack and 1k data stack at $BC00-$BFFF and $B800-$BBFF respectively. With all the 32 bit values passed on the stack I figured it might be a good idea to expand the stacks a little bit. They are placed at the top of a 48kB region in bank 0 that's RAM.

One of the things I'm wondering about is how to extend the keyword list. I'd like to add words at $01000000 and above where the DRAM is located. It looks like a part of Forth would have to be placed in RAM then patched. (I currently have Forth running in a ROM memory).

I really should get a good book on Forth.

Author:  Dr Jefyll [ Thu Oct 29, 2015 4:29 pm ]
Post subject:  Re: FIgForth RTF6809

Sounds like you've gotten things working well enough for simple interactions on the command line. Eg: BASE @ . <CR> should respond with 10 and 1234 DUP . . <CR> should respond with 1234 1234

Quote:
It looks like a part of Forth would have to be placed in RAM then patched.
The 8K footprint includes the Forth compiler! So adding new words is a capability taken for granted. I suppose a mixed RAM/ROM implementation is possible but it won't help your learning curve, so I suggest you arrange to get running from RAM ASAP!

There are various defining words but : (colon) is simplest.
Code:
: MYTEST ." Hello world!!" ;
Normally after entering this you would be able to then enter MYTEST <CR> and see the result.

Edit to previous edit: :oops: FIG has two sorts of variables. "User variables" have their data in a special RAM area not embedded in the dictionary. Data-storage for ordinary (non-User) variables is embedded in the dictionary along with the NFA CFA etc. If the dictionary's in ROM then these "variables" can't be altered.

User variables include DP CURRENT and CONTEXT which define the extent of the dictionary. I've never run FIG from ROM but it looks like it'd maybe let you define new words. (They'd be lost on re-start of course.)

Author:  Dr Jefyll [ Thu Oct 29, 2015 5:03 pm ]
Post subject:  Re: FIgForth RTF6809

I wrote:
I've never run FIG from ROM but it looks like it'd maybe let you define new words.
You'd need to relocate DP (the dictionary pointer) first. So we have:
Code:
HEX 1000000 DP !  : MYTEST ." Hello world!!" ;

New territory for me. Hope I'm not giving you wrong or incomplete info!

Author:  Garth [ Thu Oct 29, 2015 8:03 pm ]
Post subject:  Re: FIgForth RTF6809

robfinch wrote:
I really should get a good book on Forth.

There are several on Forth, Inc's website.

Author:  robfinch [ Fri Oct 30, 2015 3:27 pm ]
Post subject:  Re: FIgForth RTF6809

Well, I got a little bit further but not much. When I enter something at the prompt I get the message back " ? MSG #@" and then it hangs.
Software problems....

Author:  Dr Jefyll [ Fri Oct 30, 2015 4:05 pm ]
Post subject:  Re: FIgForth RTF6809

Sounds like you're getting really close! When you hit return Forth is gonna take the command-line string and, using $20 as the delimiter, break it into individual words. For each word, it'll search the dictionary using FIND which calls (FIND). If found, the word'll be executed (unless you're compiling, but worry about that later). If not found, Forth tries to evaluate the word as a number. Success causes the number to be placed on stack. Failure yields the message you report. (Hmm - thought it should be MSG # 0, though. Msg 0 means "Not recognized").

Can you trace or single-step as it tries to (FIND) a word? If you choose a word that appears at or near the end of the dictionary then the search will be brief.

BTW there's some hanky panky about how bit6 and bit7 are used -- purposeful, although kinda strange. I mean in the name's length byte and its final character. This could easily foul up a FIND. (But even so, a number ought to be recognized... unless there's a separate problem there, which of course is possible.)

J:o)

ETA: It shouldn't hang after delivering the msg. IIRC it should just let you input a new cmd-line string.

Page 3 of 4 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/