Jump to content
TheBF

Machine Forth OMG

Recommended Posts

So although machine Forth is nice to play with I am still longing to create a threaded system that uses the BL instruction based calling system with the return stack  keeping old R11 values.

I know it will get bigger than ITC so what about "indirect sub-routine threading"  Where we keep the Forth instruction pointer but DOCOL is looks more like:

 

( I am making this up here)

MOV R11 *RP

MOV *IP+ W

BL    *W

 

I don't have the details clear in my head but does it inspire any thoughts from you guys?

 

BF

 

Here is fbForth’s inner interpreter (sans DODOES):

 

DOCOL  DECT R
       MOV  IP,*R
       MOV  W,IP
$NEXT  MOV  *IP+,W
DOEXEC MOV  *W+,R1
       B    *R1
$SEMIS MOV  *R+,IP
       MOV  *IP+,W
       MOV  *W+,R1
       B    *R1
 
Obviously, this is indirect threading, but I show it for comparison because it is going to take me awhile to wrap my head around direct threading and machine Forth (mainly, because I have never thought about them seriously).  At the risk of stating the obvious, B *NEXT (NEXT contains $NEXT most of the time) ends ALC bodies and the cfa of ; ends all : word bodies, causing execution to continue at $SEMIS.  Pardon any ineptitude in my attempts to understand what you are doing.  I promise to try harder.
 
...lee

Share this post


Link to post
Share on other sites

 

Same here—though I am not sure what you mean by “ms timing value”.  If you mean the 4.096 value, that was just >1000/1000 = 4096/1000 = 4.096, which should be the comparison factor for how Mark first ran the program in TF.

 

...lee

 

Ahh... 4096 = 2^12  DUH

 

BF

Share this post


Link to post
Share on other sites

 

I think direct threaded might be better suited to the 9900:

 

Let R0 be instruction pointer. So, you'd have:

next:
    b *r0+

That's it.

 

High level and low-level Forth words would appear the same. No difference. You'd still have DOCOL and EXIT but they would just be the addresses of the routines, just like DUP etc.

 

There would be no CFA. The first cell of a definition is the address (direct address) of some executable code.

 

So direct threading would add 2 bytes to every header for a Branch instruction vs ITC  right?

 

That is definitely smaller than push R11 and BL in the header.

 

I should be able to coax the cross-compiler to do that once I get my head around it...

 

And why R0 for IP versus any other register?

 

 

BF

Share this post


Link to post
Share on other sites

 

 

Here is fbForth’s inner interpreter (sans DODOES):

 

DOCOL  DECT R
       MOV  IP,*R
       MOV  W,IP
$NEXT  MOV  *IP+,W
DOEXEC MOV  *W+,R1
       B    *R1
$SEMIS MOV  *R+,IP
       MOV  *IP+,W
       MOV  *W+,R1
       B    *R1
 
Obviously, this is indirect threading, but I show it for comparison because it is going to take me awhile to wrap my head around direct threading and machine Forth (mainly, because I have never thought about them seriously).  At the risk of stating the obvious, B *NEXT (NEXT contains $NEXT most of the time) ends ALC bodies and the cfa of ; ends all : word bodies, causing execution to continue at $SEMIS.  Pardon any ineptitude in my attempts to understand what you are doing.  I promise to try harder.
 
...lee

 

 

 

I am playing games really.   I am creating assembler macros to simulate Forth words and tieing it all together with yet another macro called "CALL"

and ending each sub-routine with RT, .  I was just amazed at how much faster native code goes.

CALL    RP DECT
        MOV R11 *RP
        BL  @> "some code"
        MOV *RP+ R11 

The fun thing is that the Forth Assembler is so flexible that you can do this with little effort.

 

The other piece that you need is a target compiler.

It works just like the Forth compiler.

 

And for your interest a basic target compiler starts like this:

VARIABLE TARGMEM   64k ALLOT
VARIABLE TDP          \ target dictionary pointer

: THERE    ( -- addr)    TARGMEM TDP @ + ;  \  Target memory so not HERE but THERE :-)
: TALLOT   ( u -- )      TDP +!  ;
: T!       ( n addr -- ) TARGMEM +  ! ;
​: TC!      ( n addr -- ) TARGMEM + C! ;
: T,       ( n addr -- ) THERE  !   2 TALLOT ;  \ like "comma"
: TC,      ( c addr -- ) THERE  C!  1 TALLOT ;  \ like C, 
​

That's about it. That's the basic framework for a target compiler.

Rewrite the basic parts of Forth but use T, and TC, and you have a system in a new memory space.

 

*edit* Actually re-write your FORTH assembler first, and using T, and TC, etc... 

 

At MPE they name these things like this:    ,(t)    C,(t)    HERE(t)   ALLOT(t)

Pretty, but more typing.

 

B

Edited by TheBF

Share this post


Link to post
Share on other sites

I spent some time reworking the my cross-compiler to compile the little code fragments into the word headers (B DOVAR  B DOCOL etc)  for DIRECT threaded code, but it's not running yet.

The Kernel compiles and loads but in the debugger I can see that I am not pulling the correct addresses yet as the code travels through next.

Which is only 2 instructions now! It did make the kernel with tools installed ,go from 7022 bytes to 7124 (or so),

I am away from home at the moment so I don't have the exact numbers in front of me.

 

Thanks Willsy, now I have ANOTHER project to complete.

 

But thanks for real because it forced me to re-organize the cross-compiler code.

 

QUESTION:

 

This cross compiler is running on DOS because I am using my almost ANS Forth update of HsForth for DOS.

 

If I was to port this for general usage should I go with GForth or Win32Forth or just release it to the world for DOSBOX?

 

 

BF

Edited by TheBF

Share this post


Link to post
Share on other sites

LOL!

 

So the answer is ALL of the above + VFX.  OK.  Sounds like for some, I could release it for DOSBOX first.

 

(VFX is pretty amazing.  I always liked MPE products but they are bleeding edge of Forth these days)

 

BF

Share this post


Link to post
Share on other sites
Well it's a cross-compiler, right? Runs on a PC? In that case I'd target MPE's free version of VFX and only write it once ;-)

Share this post


Link to post
Share on other sites
There again, if it's written in ANS Forth then it *should* run on all of the big-name compilers.

*cough cough* :-)

Share this post


Link to post
Share on other sites

There again, if it's written in ANS Forth then it *should* run on all of the big-name compilers.

*cough cough* :-)

 

Thanks be to G_d we are not on comp.lang.forth :-)))  

 

Battle plans would be in progress.

 

B

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...