Jump to content

Photo

Machine Forth OMG

FORTH

36 replies to this topic

#26 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,344 posts
  • Location:Silver Run, Maryland

Posted Sat Mar 11, 2017 9:53 AM

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


#27 TheBF OFFLINE  

TheBF

    Moonsweeper

  • Topic Starter
  • 321 posts
  • Location:The Great White North

Posted Sat Mar 11, 2017 1:39 PM

 

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



#28 TheBF OFFLINE  

TheBF

    Moonsweeper

  • Topic Starter
  • 321 posts
  • Location:The Great White North

Posted Sat Mar 11, 2017 1:44 PM

 

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



#29 TheBF OFFLINE  

TheBF

    Moonsweeper

  • Topic Starter
  • 321 posts
  • Location:The Great White North

Posted Sat Mar 11, 2017 2:33 PM

 

 

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, Sat Mar 11, 2017 3:26 PM.


#30 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,012 posts
  • Location:Uzbekistan (no, really!)

Posted Sat Mar 11, 2017 2:37 PM

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). 

 

All explained here, Lee: http://www.bradrodri...ers/moving1.htm



#31 TheBF OFFLINE  

TheBF

    Moonsweeper

  • Topic Starter
  • 321 posts
  • Location:The Great White North

Posted Tue Mar 14, 2017 9:27 PM

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, Tue Mar 14, 2017 9:27 PM.


#32 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,261 posts
  • Location:Cookeville, TN

Posted Wed Mar 15, 2017 12:20 AM

GForth is cool...


DOSBox is cooler. :)

#33 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,012 posts
  • Location:Uzbekistan (no, really!)

Posted Wed Mar 15, 2017 8:06 AM

I'd say VFX Forth. There's a free version.

#34 TheBF OFFLINE  

TheBF

    Moonsweeper

  • Topic Starter
  • 321 posts
  • Location:The Great White North

Posted Thu Mar 16, 2017 7:00 AM

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



#35 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,012 posts
  • Location:Uzbekistan (no, really!)

Posted Thu Mar 16, 2017 8:30 AM

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 ;-)

#36 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,012 posts
  • Location:Uzbekistan (no, really!)

Posted Thu Mar 16, 2017 8:32 AM

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

*cough cough* :-)

#37 TheBF OFFLINE  

TheBF

    Moonsweeper

  • Topic Starter
  • 321 posts
  • Location:The Great White North

Posted Wed Mar 22, 2017 12:19 PM

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







Also tagged with one or more of these keywords: FORTH

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users