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. Quote: Unfortunately the processor doesn't support indirect jumps via a far address. 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. 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. 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. There are various defining words but : (colon) is simplest. Code: : MYTEST ." Hello world!!" ; Edit to previous edit: 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. 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/ |