Jump to content

Photo

Camel99 Forth Information goes here

Camel99 Forth Concatentive Programming ANS Forth

190 replies to this topic

#126 RXB OFFLINE  

RXB

    River Patroller

  • 3,320 posts
  • Location:Vancouver, Washington, USA

Posted Sun Jul 15, 2018 1:08 PM

deleted


Edited by RXB, Sat Jul 28, 2018 4:23 PM.


#127 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,297 posts
  • Location:Oklahoma CIty.

Posted Sun Jul 15, 2018 4:02 PM

First sentence: You make no sense that I can see.

Second sentence: Absolutely not.

Third sentence: what was implied was that your constant injecting RXB into threads was wearing thin. I don't know what a post name means so again you make no sense.

Fourth and fifth: All threads tend to run off topic. That's the nature of the game. You have the unbelievably annoying habit though of trying to inject your RXB into threads that have absolutely nothing to do with you or your one trick pony.

Lastly I don't believe in deleting posts but if that's your thing then try to match the post to the current conversation.


Sorry for brutalizing the Camel Forth thread. I'll step aside.

#128 RXB OFFLINE  

RXB

    River Patroller

  • 3,320 posts
  • Location:Vancouver, Washington, USA

Posted Sun Jul 15, 2018 4:37 PM

Do I tell you what to do? Or tell you what you can talk about?

How about you offer the same free speech rules as I afford others?

 

Unless there are some strict rules here I never knew about, if so what are they?

 

This all started with the AMS (SAMS) which I was the first person outside of Asgard to support.

So when I make a comment about it are there rules on what and how I say it?

 

Or is a special rule not to annoy you?


Edited by RXB, Sun Jul 15, 2018 4:39 PM.


#129 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,297 posts
  • Location:Oklahoma CIty.

Posted Sun Jul 15, 2018 6:19 PM

I'm not telling you what to do. I am letting you know that your constant and incessant RXB butinskis are really fucking annoying. Can you not take a hint dammit ?

#130 RXB OFFLINE  

RXB

    River Patroller

  • 3,320 posts
  • Location:Vancouver, Washington, USA

Posted Sun Jul 15, 2018 9:25 PM

deleted


Edited by RXB, Sat Jul 28, 2018 4:23 PM.


#131 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,297 posts
  • Location:Oklahoma CIty.

Posted Mon Jul 16, 2018 4:50 PM

Drop it ? I didn't start this mess Rich, you did by quoting my post and lecturing me using the exact same logic and similar language as my post you were quoting. I cannot tell if you are really this dense or this is some kind of trolling expedition or both.

Go back. Read them again and get some clarity.

My stance on you trying to inject RXB into subjects that have nothing to do with you or your BASIC modifications stands. It's a ridiculous and ever annoying occurance that I and others wish you would stop. It goes way past the normal off topic meanderings of threads. RXB has it's place, just not everywhere and in every situation. It's petulant to constantly do this.

Food for thought.

#132 RXB OFFLINE  

RXB

    River Patroller

  • 3,320 posts
  • Location:Vancouver, Washington, USA

Posted Mon Jul 16, 2018 5:34 PM

Drop it ? I didn't start this mess Rich, you did by quoting my post and lecturing me using the exact same logic and similar language as my post you were quoting. I cannot tell if you are really this dense or this is some kind of trolling expedition or both.

Go back. Read them again and get some clarity.

My stance on you trying to inject RXB into subjects that have nothing to do with you or your BASIC modifications stands. It's a ridiculous and ever annoying occurance that I and others wish you would stop. It goes way past the normal off topic meanderings of threads. RXB has it's place, just not everywhere and in every situation. It's petulant to constantly do this.

Food for thought.


Edited by RXB, Sat Jul 28, 2018 4:22 PM.


#133 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,297 posts
  • Location:Oklahoma CIty.

Posted Mon Jul 16, 2018 6:54 PM

That's fine and all. Just stop the RXBpalooza everywhere. That would neat.

#134 RXB OFFLINE  

RXB

    River Patroller

  • 3,320 posts
  • Location:Vancouver, Washington, USA

Posted Tue Jul 17, 2018 10:15 AM

Sensible I blocked Marc.hull as suggested. 

I am told he is a problem for many not just me.



#135 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,297 posts
  • Location:Oklahoma CIty.

Posted Tue Jul 17, 2018 6:02 PM

Good. Now you won't be tempted to spread you special brand of crazy on my posts. Now expand that idea to include everyone else and you're golden.

#136 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sat Jul 28, 2018 9:34 AM

Strange Forth thought for the day.

 

This paraphrased statement came from Charles Moore, the inventor of Forth.

 

I now had an interpreter which could interpret assembler, which could assemble a compiler, which could compile an interpreter

 

  ;) 



#137 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sat Jul 28, 2018 2:18 PM

Dutch Flag Problem using Dijkstra's 3 Colour Algorithm

 

Well if we ever needed proof that the correct algorithm will outperform poor ones here it is.

 

I notice that Rosetta Code did not have a Forth entry for the Dutch Flag. In the posting I found a paper on Diijkstra's method with pseudo-code.

So I re-did my COMBSORT version with the algorithm.  It's  SEVEN times faster!

 

See the new version run here: 

https://github.com/b...JKSTRAFLAG .mp4

 

*EDIT*  Added a GIF here for simpler viewing

 

Here is the code: 

Spoiler

Attached Files


Edited by TheBF, Sun Jul 29, 2018 11:46 AM.


#138 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Fri Aug 3, 2018 7:55 AM

PROGRAMMING

A PROBLEM-ORIENTED

LANGUAGE 

 

http://www.forth.org/POL.pdf

 

This old document is very interesting for anyone who would like to know how and why Forth is the unusual language that it is.

It is also a little amusing for younger people to read when you see references to 80 column punched cards and tape I/O.

Although 99ers are familiar with tape in a special way.

 

Personally I like these words from the book:

 

"So to offer guidance when the trade-offs become obscure, I am going to define the Basic Principle:

 

Keep it Simple
 
As the number of capabilities you add to a program increases, the complexity of the program increases exponentially. The problem of maintaining compatibility among these capabililties, to say nothing of some sort of internal consistency in the program, can easily get out of hand. You can avoid this if you apply the Basic Principle.
 
You may be acquainted with an operating system that ignored the Basic Principle."  ;-) 


#139 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sat Aug 4, 2018 10:37 AM

Recent updates to CAMEL99 Forth

Aug 4, 2018 V2.0.20

 

  • Kernel is 16 bytes smaller
  • Removed word INCLD from kernel and put code in body of INCLUDED to save space
  • Change INIT code to use structured assembler loop
  • Comment improvements here and there.
  • Move DATA stack reset in COLD word to just before QUIT. This fixed the first error bug. (First bad word entered at console gave "empty stack" error)
  • Removed SPRITE support word DXY from KERNEL, moved to DIRSPRIT (direct sprite control) as a machine code word.
  • Added SEE.F to DSK1 which is a Forth decompiler.
  • Changes to PONG.F game to use INCLUDE from library files.


#140 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Tue Aug 7, 2018 2:30 PM

Crack the "Bullwhip" on the Camel

 

HI level languages are great for getting work done, but sometimes they don't let us use cool features of a specific CPU.

The 9900 has the cool memory to memory architecture and the BLWP instruction let's us put our registers anywhere that's convenient. 

 

I had to add a BLWP "WORD" to CAMEL99 Forth to link to device service routines and I wondered if I could use it somewhere else.

(I probably should get a life...) 

 

It was pretty efficient to add BLWP to the Camel99 KERNEL because it keeps the top of the Forth stack cached in Register 4.

So here is all I had to do using the XFC99 Cross-compiler/Assembler.

 

"TOS" below is just an alias for R4  and TOS POP,  is macro for :   *SP+ TOS MOV,   

CODE: BLWP  ( vector -- )  \ "BULLWHIP" takes a vector address as input arg.
           *TOS BLWP,      \ loads the workspace and program counter into CPU and branch
            TOS POP,       \ refill Forth TOS when we get back from our journey...
            NEXT,
            END-CODE

It needs a TMS9900 vector address on the Forth stack as the input argument and when you say BLWP … the machine goes off to another world... well umm workspace. 

 

I wondered where this would be useful so I imagined a program  needing to sum 12 numbers really fast. Perhaps they were 12 variables in a game that determine total Health.

 

So here is a way you might do it Forth (It could be made a little faster but for demonstration this is clearer)

DECIMAL
CREATE ARGS   \ this is our workspace
        0 ,         \ will contain the answer
        2 , 2 , 2 , \ 12 numbers we want to sum
        2 , 2 , 2 ,
        2 , 2 , 2 ,
        2 , 2 , 2 ,
        0 ,         \ R13  reserved so we can get back to Forth
        0 ,         \ R14
        0 ,         \ R15
        
\ expose ARGS as an array for 12 ints.
\ Note: 0 ]ARG is reserved for the SUM, 13,14,15 cannot be used
: ]ARG ( n -- addr ) CELLS ARGS + ;

: FORTHSUM  ( -- )        
       0              \ this is an accumulator on stack
       13  1
       DO
          I ]ARG @ +  \ add values into accumulator
       LOOP
       0 ]ARG !       \ put accumulator back into memory
; 

The FORTHSUM routine took 249 ticks of the TSM9901 timer.  That is 5.3 milli-seconds. Not shabby, but what happens if we crack the bullwhip.

 

Using the same ARGS data I did this:

CODE SUM ( -- )   \ the fast summing program
        R1  R0 ADD,
        R2  R0 ADD,
        R3  R0 ADD,
        R4  R0 ADD,
        R5  R0 ADD,
        R6  R0 ADD,
        R7  R0 ADD,
        R8  R0 ADD,
        R9  R0 ADD,
        R10 R0 ADD,
        R11 R0 ADD,
        R12 R0 ADD,
        RTWP,      \ get back home to Forth
        ENDCODE

\ Familiar BLWP Vector is a workspace and address of the code just like Assembler.
\ ARGS returns it's own address onto the Forth stack 
\  The comma compiles the number into memory and bumps the mem pointer

\ Forth ' looks up the "execution token" of a Forth word.
\ Forth >body converts the execution token into address of real code

CREATE SUMVECT   ARGS ,  ' SUM >BODY ,

: FASTSUM  ( -- ) SUMVECT BLWP ; 

The FASTSUM program ran in 17 TMS9901 timer ticks or .362 milli-seconds!

That's a speed up of over 14 times. 

 

Cracking the Bullwhip makes that old Camel run.



#141 Willsy OFFLINE  

Willsy

    River Patroller

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

Posted Tue Aug 7, 2018 3:20 PM

Nice. The BLWP instruction is somewhat shunned but I've never really bought into that mindset. You get a lot of work done for a single instruction!

#142 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Tue Aug 7, 2018 3:55 PM

For sure.  It makes interrupt handlers a thing of beauty compared to other machines.

 

*EDIT*  and also a pretty cool multi-tasking context switcher. 

RTWP does it in one instruction if you preset the workspaces correctly. 

Sooooo cool.


Edited by TheBF, Tue Aug 7, 2018 6:56 PM.

  • RXB likes this

#143 Willsy OFFLINE  

Willsy

    River Patroller

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

Posted Wed Aug 8, 2018 3:10 AM

 

*EDIT*  and also a pretty cool multi-tasking context switcher. 

RTWP does it in one instruction if you preset the workspaces correctly. 

Sooooo cool.

 

Okay, so you're pre-loading R13,R14 and R15 as appropriate and then executing a RTWP to jump to the new task, yes? That's a little counter-intuitive. Isn't that what BLWP is for? :D

 

How do you get back from the second task to the first task?



#144 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Wed Aug 8, 2018 5:38 AM

 

Okay, so you're pre-loading R13,R14 and R15 as appropriate and then executing a RTWP to jump to the new task, yes? That's a little counter-intuitive. Isn't that what BLWP is for? :D

 

How do you get back from the second task to the first task?

At first I thought I could use BLWP but I realized that I would need to keep a separate table of vectors because BLWP overwrites the contents of R13 R14 R15. That ticked me off because those registers could hold the state perpetually.

 

The only instruction that can jump to a new workspace and NOT destroy the context registers is... RTWP.

So by changing context with RTWP, you don't need any extra memory to store the task vectors.

 

The graphic is an illustration from the doc.

The latest code version is here: 

https://github.com/b....TI/MTASK99.FTH

 

Here how the code changes context.

CODE: YIELD  ( -- )  
              BEGIN,                
                 RTWP,               \ one instruction switches context        14
\ ---------------------------------------------------------------------------------
 l: _TSTAT       R1  STWP,           \ NEXT TASK: store NEW workspace in R1     8
                 32 (R1) R0 MOV,     \ Read local TFLAG to see if I am awake   28
              NE UNTIL,              \ loop thru tasks until TFLAG is <> 0     10
              NEXT,                  \ if task is awake, run next            \ 60 *.333 = 20uS
              END-CODE

Two other counter-intuitive things here:

  1. The label _TSTAT is plugged into R14 of every task when they are FORKed. This routine checks the TFLAG variable to see it if is awake.
  2. TFLAG is a USER variable. Where TurboForth puts code in PAD-RAM, I have put the USER variable table. This lets me use the CPU WP register as the Forth User pointer (UP) register, another space saving.

Here is the code for user Variables when you use WP for as the UP register. It's pretty efficient.

(this was stuff I dreamt about 30... years ago so it's been festering for a long time) ;-)

CODE: DOUSER ( -- addr)    \ Executor for a "USER VARIABLE" (local to each task)
              TOS PUSH,   
              TOS STWP,    \ store workspace register WP in TOS
             *W TOS ADD,   \ add the offset stored in the USER variable's parameter field
              NEXT,
              END-CODE

Attached Files


Edited by TheBF, Wed Aug 8, 2018 5:43 AM.


#145 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Wed Aug 8, 2018 5:49 AM

Oh one more cool thing about using WP as the user pointer.

 

All the CPU registers become user variables !

 

So I can define the Forth Virtual machine registers like this:

 
  12 USER 'SP    \ the task's Forth SP register ( R6)
  14 USER 'RP    \ the task's Forth RP register ( R7)
  18 USER 'IP    \ the task's Forth IP register ( R8)
  20 USER 'R10   \ address of R10 (holds the NEXT routine)

I kinda love the 9900 


Edited by TheBF, Wed Aug 8, 2018 6:02 AM.

  • RXB likes this

#146 RXB OFFLINE  

RXB

    River Patroller

  • 3,320 posts
  • Location:Vancouver, Washington, USA

Posted Wed Aug 8, 2018 10:01 AM

Me too, do not see why so many wanted BL @address over BLWP @address, BL has limited number of Registers which means in big programs you waste more time

trying to swap out or switch out variables. Yea BLWP uses 32 more bytes but it is like CALL SUB in XB with extra variables that do not need to interact with main ones.



#147 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,383 posts
  • Location:Germany

Posted Wed Aug 8, 2018 10:08 AM

When you learn about other architectures, and what a context switch really means, you gotta love BLWP.



#148 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Wed Aug 8, 2018 1:28 PM

Me too, do not see why so many wanted BL @address over BLWP @address, BL has limited number of Registers which means in big programs you waste more time

trying to swap out or switch out variables. Yea BLWP uses 32 more bytes but it is like CALL SUB in XB with extra variables that do not need to interact with main ones.

 

That's a good point.  I am contemplating writing a driver for the serial ports and I thought of making a receive queue so as not to miss characters without using interrupts. (work in progress)

My current view is to allocate 32 extra bytes at the end of the rcv buffer and use it as the workspace to house the queue's input/output pointers.

The code will be super simple and all the circular queue data and registers will be in one block.

 

I also realized yesterday that by not refilling the Forth TOS register when I do BLWP *TOS ,  I can return a single item back to Forth's top of stack with just  a move indexed-indirect through R13.

So I can use that to get character out of the Q back to Forth.  

 

There is a temptation inside Forth to just use the stacks because they are there, but with a BLWP Forth instruction the world opens up nicely. 

 

Here is the previous example using the parameter return back to Forth mechanism.

\ Using Forth to make a macro to name the code: 8@(R13) 
\ ie: the Forth TOS register that called the function
: [TOS]     8 R13 () ; 

\ *NEW*  BLWP() leaves TOS register un-touched. (no refill)
\  Return 1 arg to Forth TOS
CODE BLWP() ( addr -- arg)        
            *TOS BLWP,
             NEXT,
             ENDCODE

CODE SUM ( -- )   \ the fast summing program
        R1  R0 ADD,
        R2  R0 ADD,
        R3  R0 ADD,
        R4  R0 ADD,
        R5  R0 ADD,
        R6  R0 ADD,
        R7  R0 ADD,
        R8  R0 ADD,
        R9  R0 ADD,
        R10 R0 ADD,
        R11 R0 ADD,
        R12 R0 ADD,
        R0 [TOS] MOV,  \ *NEW* R0 to Forth TOS register
        RTWP,
        ENDCODE

CREATE SUMVECT   ARGS ,  ' SUM >BODY ,

: FASTSUM  ( -- answer) SUMVECT BLWP() ; 

\ Usage at Forth console

FASTSUM .  24 ok

Edited by TheBF, Wed Aug 8, 2018 1:29 PM.

  • RXB likes this

#149 Willsy OFFLINE  

Willsy

    River Patroller

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

Posted Thu Aug 9, 2018 5:17 AM

I'm barely able to keep with the innovation that is going on here! TurboForth is looking very out of date! I need to get back in the saddle! :)


  • RXB likes this

#150 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Thu Aug 9, 2018 6:57 AM

I'm barely able to keep with the innovation that is going on here! TurboForth is looking very out of date! I need to get back in the saddle! :)

 

 

Sometimes I think my innovating is almost out to 1987!  :D







Also tagged with one or more of these keywords: Camel99, Forth, Concatentive Programming, ANS Forth

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users