AnyCPU http://anycpu.org/forum/ |
|
FIgForth RTF6809 http://anycpu.org/forum/viewtopic.php?f=8&t=241 |
Page 1 of 4 |
Author: | robfinch [ Wed Oct 07, 2015 2:44 pm ] |
Post subject: | FIgForth RTF6809 |
I started porting FigForth to the RTF6809. I plan on making use of 32 bit addressing and data values. Some of the code should be easy to port and other portions much more difficult. Easy: Code: ; ; EXCECUTE ; SCREEN 14 LINE 11 ; L75 .BYTE $87,'EXECUT',$C5 .WORD L35 ; link to CLIT EXEC .WORD *+2 LDD 0,X STD W LDD 2,X STD W+2 LEAX 4,X JMP FAR [W] ; to JMP (W) in z-page More difficult to do is setting the address of Forth words because of the way that the NEXT routine will work. NEXT is discussed here: http://forum.6502.org/viewtopic.php?f=9&t=3100#p40725 |
Author: | barrym95838 [ Wed Oct 07, 2015 3:15 pm ] |
Post subject: | Re: FIgForth RTF6809 |
Hey, Rob. Is there a good reason for avoiding the auto-increment address mode here, namely ,x++ ? It might not be any faster, but it would be shorter by getting rid of that leax ... Mike B. |
Author: | robfinch [ Wed Oct 07, 2015 8:46 pm ] |
Post subject: | Re: FIgForth RTF6809 |
Quote: Hey, Rob. Is there a good reason for avoiding the auto-increment address mode here, namely ,x++ ? It might not be any faster, but it would be shorter by getting rid of that leax ... Nope, there isn't a reason not to. And shorter is probably faster too on the RTF6809. Souped up code: Code: ; ; EXCECUTE ; SCREEN 14 LINE 11 ; L75 .BYTE $87,'EXECUT',$C5 .WORD L35 ; link to CLIT EXEC .WORD *+2 LDD ,X++ STD W LDD ,X++ STD W+2 JMP FAR [W] ; to JMP (W) in z-page The RTF6809 and 65c816 are actually very similar processors. The 6809 has 16 bit A,X,Y regs like the 65816, and the RTF6809 adds post indexed addressing. It's also very similar to the 65org16. |
Author: | Dr Jefyll [ Wed Oct 07, 2015 9:22 pm ] |
Post subject: | Re: FIgForth RTF6809 |
From your EXECUTE code I see you've gone 32-bit all the way. IMO 16-bit tokens (and 32-bit data) would've been adequate but there are reasons for sticking with 32 all the way. FIG Forth has this weird -- I'm tempted to be blunt and just say dumb -- policy of using relative addressing for branches. So if 0BRANCH for instance meets its condition and needs to branch then its inline parameter is added to IP rather than replacing IP. It's a lose-lose situation, IMO -- all cost, no benefit. If you felt like optimizing, you could tweak FIG to avoid this inefficiency. Maybe I shouldn't've mentioned it. Your machine is gonna be so fast that the needless extra work hardly matters. -- Jeff |
Author: | barrym95838 [ Thu Oct 08, 2015 3:30 am ] |
Post subject: | Re: FIgForth RTF6809 |
Dr Jefyll wrote: ... So if 0BRANCH for instance meets its condition and needs to branch then its inline parameter is added to IP rather than replacing IP. It's a lose-lose situation, IMO -- all cost, no benefit. If you felt like optimizing, you could tweak FIG to avoid this inefficiency ... ... unless you happen to have a hypothetical situation in which IP is in Y, and have access to a hypothetical machine instruction like ADY ,Y+ which takes the same time and space as LDY ,Y ... but that's pure fantasy at this moment in time ... I just like speaking hypothetical! Mike B. |
Author: | Dr Jefyll [ Thu Oct 08, 2015 3:57 am ] |
Post subject: | Re: FIgForth RTF6809 |
Fair enough, but breaking even is the best you can do. The effort/clock count to load and add the inline parameter to IP can't be less than that to simply load the inline parameter to IP. Hypothetically, of course! |
Author: | robfinch [ Thu Oct 08, 2015 7:16 am ] |
Post subject: | Re: FIgForth RTF6809 |
Quote: From your EXECUTE code I see you've gone 32-bit all the way. IMO 16-bit tokens (and 32-bit data) would've been adequate but there are reasons for sticking with 32 all the way. Quote: FIG Forth has this weird -- I'm tempted to be blunt and just say dumb -- policy of using relative addressing for branches. So if 0BRANCH for instance meets its condition and needs to branch then its inline parameter is added to IP rather than replacing IP. It's a lose-lose situation, IMO -- all cost, no benefit. If you felt like optimizing, you could tweak FIG to avoid this inefficiency. When I started I was going to do a more or less direct port of fig forth, but now that I've looked at it far a bit I'm changing it around somewhat. Fig uses the .X register for the data stack, I changed to using the .U register on the 6809. I then use .X as the low order word of a 32 bit accumulator (D,X). |
Author: | Dr Jefyll [ Thu Oct 08, 2015 1:56 pm ] |
Post subject: | Re: FIgForth RTF6809 |
Quote: I found that bit of code and was wondering why they did that. IF it doesn't matter at a high level, I'll be sure to change it. BTW FIG has @ and ! for the native word size (16 bits) and also C@ and C! for byte operations. The native size on your "stretch" FIG will be a DWord (32 bits), so you may wanna create W@ and W! ("word fetch" & "word store") to allow 16-bit operations. Quote: I wanted to be able to position code anywhere in memory which really requires 32 bit links and also be able to break the 64k limit code size. Quote: There's not much hope for using 16 bit tokens without changing the basic dictionary mechanism Quote: Fig uses the .X register for the data stack, I changed to using the .U register on the 6809. I then use .X as the low order word of a 32 bit accumulator (D,X). -- Jeff |
Author: | robfinch [ Sun Oct 11, 2015 6:55 pm ] |
Post subject: | Re: FIgForth RTF6809 |
Today I am not understanding how Fig Forth bootstraps. It looks to me like the ORIG area must be setup prior to running FIG Forth. IS there a template for this somewhere ? Is there documentation on the structure of the ORIG and USER pointer areas ? Code: L2423 .BYTE $84,'COL',$C4 .WORD L2406 ; link to ABORT COLD .WORD *+2 LDA ORIG+$0C ; from cold start area STA FORTH+6 LDA ORIG+$0D STA FORTH+7 LDY #$15 BNE L2433 WARM LDY #$0F L2433 LDA ORIG+$10 STA UP LDA ORIG+$11 STA UP+1 L2437 LDA ORIG+$0C,Y STA (UP),Y DEY BPL L2437 LDA #>ABORT ; actually #>(ABORT+2) STA IP+1 LDA #<ABORT+2 STA IP CLD LDA #$6C STA W-1 JMP RPSTO+2 ; And off we go ! |
Author: | Dr Jefyll [ Sun Oct 11, 2015 7:04 pm ] |
Post subject: | Re: FIgForth RTF6809 |
Do you have the FIG "Installation Manual and Glossary"? It pertains to the FIG model in general (isn't CPU-specific). You can download it, or borrow my (pencil-annotated) printed copy if you like. |
Author: | robfinch [ Sun Oct 11, 2015 7:51 pm ] |
Post subject: | Re: FIgForth RTF6809 |
Quote: Do you have the FIG "Installation Manual and Glossary"? I found one on the web but it's not very extensive. I think I need information more specific to the 6502 Fig Forth. But, I have to get the 6809 system working before I can test any code. Unless I write an emulator. Currently the system just clears the screen and then hangs. I'm running the 6809 core at 66MHz! (Could be why it hangs). |
Author: | Dr Jefyll [ Sun Oct 11, 2015 8:21 pm ] |
Post subject: | Re: FIgForth RTF6809 |
Try running it slower, then! Or patch in the TRACE routines so you can see what's going on. (I assume these routines exist in the 6809 version as they do in 6502.) IIRC there's a trace that can be patched into NEXT, and another for DOCOL. Sounds like you found a machine-readable copy of the 6809 assembly source for FIG. Can you send me that, pls, or a link? Thinking of non-machine-readable source code reminds me of my first Forth -- FIG for 6502, running on my KIM-1 circa 1980. I manually entered about 8KB of hex (!) so obviously there were some typos. The debugging was... interesting (I knew almost nothing about Forth). |
Author: | robfinch [ Mon Oct 12, 2015 12:38 am ] |
Post subject: | Re: FIgForth RTF6809 |
Quote: Sounds like you found a machine-readable copy of the 6809 assembly source for FIG. Can you send me that, pls, or a link? Oops, I sidetracked on the topic a little bit. The clearscreen routines is a separate part of simple monitor routines I was trying to boot; not a part of the forth system. I didn't manage to find a machine-readable copy, I've only found an optically scanned copy of the fig forth fro the 6809. I decided not to use that and instead am just porting the 6502 version since I've got a lot of changes to convert to a 32 bit forth. I've got to change the forth memory map for the rtf6809 since bank zero space is valuable like zero page memory is on the 6502. It's the only place there can be indirect pointers, and also the stacks must be located in bank 0, just like the 65c816. Quote: Thinking of non-machine-readable source code reminds me of my first Forth -- FIG for 6502, running on my KIM-1 circa 1980. I manually entered about 8KB of hex (!) so obviously there were some typos. The debugging was... interesting (I knew almost nothing about Forth). I hope you had a way to save your work part way through. Yes, there's lot of debugging to do. I'm hoping to learn some Forth that way. |
Author: | Dr Jefyll [ Mon Oct 12, 2015 3:15 am ] |
Post subject: | Re: FIgForth RTF6809 |
Quote: am just porting the 6502 version since I've got a lot of changes to convert to a 32 bit forth Quote: I hope you had a way to save your work part way through I don't miss cassette-tape storage! Getting that floppy working was a liberating experience. |
Author: | robfinch [ Mon Oct 12, 2015 3:50 am ] |
Post subject: | Re: FIgForth RTF6809 |
I figured out why the SoC hangs, I ported the code for a Spartan6 version to Artix7, but left out the DDR ram controller. I didn't think it was in use, but it was. Thus a hang when the cpu tried to access an unsupported memory address. It'll take some work to fix. Either re-writing the BIOS or incorporating a DDR controller. Quote: Might be useful to you as a reference to have some known-good 6809 code, albeit 16-bit. Quote: Yes -- audio cassette tape! At the time, tape was my only mass storage (although later I built a floppy-disk subsystem). All of this predated my first DOS machine. There was no ubiquitous PC host that could just squirt out whatever you need on demand. |
Page 1 of 4 | All times are UTC |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |