fbForth fbForth—TI Forth with File-based Block I/O [Post #1 UPDATED: 06/09/2023]

[+Lee Stewart]

42 minutes ago, TheBF said:

Looks like you can book about 15% better on the transcendentals. That's damned good. 

 

How did you end up handling the FAC ARG thing.  Is ARG taken from the data stack?

 

I have several headerless words that do work like this—and I implemented them when I first ported the MDOS L10 Floating Point Library to fbForth 2.0. I don’t think I was planning to eventually do what I have just done—just figured it was the easiest use of workspace, etc. These words were inherited from TI Forth. I just took the headers off because they really weren’t necessary to the user like they were in TI Forth (I don’t think they were necessary then, either—just there because it was all defined in high-level Forth). TOFAC and TOARG (cfas), indeed, pop FP numbers from the data stack to FAC and ARG, respectively—and two others do the reverse.

 

I have only needed to change a few things to allow the console ROM routines to work and for my other routines to use their results. Among those items were scratchpad locations used for FP sign (>8375) and exponent (>8376). Previously, I was using my own variables. And on it goes....

 

...lee

[+TheBF]

OK. 

What I was wondering about was would it be possible to point both FAC and ARG to positions on the DATA stack by setting the registers in the ROM code, thereby reducing data movement for Floating point routines to just one move, onto the DATA stack. 

I am thinking about something like SP@(x)  and SP@(y) being fed into the two appropriate registers used by the ROM code. 

 

I got the sense that since you were jumping into the code downstream so-to-speak, you had direct access to where FAC  ARG could be stored.

(But I know nothing about these ROM routines.)

 

Just a crazy thought. But all that copying from the stack to memory and back seems a waste when you have a stack.

(Are FAC and ARG in CPU RAM? Maybe I am talking trash, if they are in VDP RAM.) 

 

[+Lee Stewart]

15 minutes ago, TheBF said:

OK. 

What I was wondering about was would it be possible to point both FAC and ARG to positions on the DATA stack by setting the registers in the ROM code, thereby reducing data movement for Floating point routines to just one move, onto the DATA stack. 

I am thinking about something like SP@(x)  and SP@(y) being fed into the two appropriate registers used by the ROM code. 

 

I got the sense that since you were jumping into the code downstream so-to-speak, you had direct access to where FAC  ARG could be stored.

(But I know nothing about these ROM routines.)

 

Just a crazy thought. But all that copying from the stack to memory and back seems a waste when you have a stack.

(Are FAC and ARG in CPU RAM? Maybe I am talking trash, if they are in VDP RAM.) 

 

I am doing exactly that, where my code calls into a single routine for FCOMP , but only for ARG. I don’t have control over where some of the routines expect to find the value(s) no matter where I might jump into them. However, I will take another look at that.

 

As to FAC and ARG, they are, indeed, in scratchpad RAM as are all of my temporary buffers and workspaces (believe it or not). Nearly all of the transcendentals use polynomials and those are shuffled around, 8 bytes at a time, like you wouldn’t believe! Oftentimes, there is a threesome with interleaved copying among three buffers!

 

...lee

[+TheBF]

1 minute ago, Lee Stewart said:

 

I am doing exactly that, where my code calls into a single routine for FCOMP , but only for ARG. I don’t have control over where some of the routines expect to find the value(s) no matter where I might jump into them. However, I will take another look at that.

 

As to FAC and ARG, they are, indeed, in scratchpad RAM as are all of my temporary buffers and workspaces (believe it or not). Nearly all of the transcendentals use polynomials and those are shuffled around, 8 bytes at a time, like you wouldn’t believe! Oftentimes, there is a threesome with interleaved copying among three buffers!

 

...lee

Ah.  Yes it only worked for FCOMP.  Shame.  

I am always surprised by some of what we find in the old 99. But I guess when the gun is to your head you make it work and make it better later. 

Those corporate execs are brutal. (Used to be one for a time   ) 

[+Lee Stewart]

On my TODO list for fbForth 2.1 is adding a couple of synonyms ( R@ EXIT ). I already have other synonyms ( BYE THEN ASM: ). Because space is at the greatest premium in Bank #0 (76 bytes), where the Code Field and Parameter Field of each word in the resident dictionary reside, I am making each of the above synonym’s pfa point to the original word’s parameter field. You can still successfully tick the synonym’s name, but the returned pfa will be that of the original word and, of course, the words ( CFA NFA LFA ) run against that pfa will return the respective pointers to the original word, not the synonym.

 

So far, the only problem I have run into is with VLIST . VLIST walks the dictionary, essentially, with

\ nfa of last word is on the stack
PFA LFA @      \ gets next nfa

 

Of course, as soon as it gets to a synonym, it gets into an infinite loop. The solution is simple:

\ nfa of last word is on the stack
2- @      \ gets next nfa by backing up to Link Field

 

which is much more efficient, anyway. I will definitely need to see if there are other gotchas before I settle on the way of managing synonyms detailed at the top of this post.

 

Thoughts?

 

...lee

[+TheBF]

2 hours ago, Lee Stewart said:

On my TODO list for fbForth 2.1 is adding a couple of synonyms ( R@ EXIT ). I already have other synonyms ( BYE THEN ASM: ). Because space is at the greatest premium in Bank #0 (76 bytes), where the Code Field and Parameter Field of each word in the resident dictionary reside, I am making each of the above synonym’s pfa point to the original word’s parameter field. You can still successfully tick the synonym’s name, but the returned pfa will be that of the original word and, of course, the words ( CFA NFA LFA ) run against that pfa will return the respective pointers to the original word, not the synonym.

 

So far, the only problem I have run into is with VLIST . VLIST walks the dictionary, essentially, with

\ nfa of last word is on the stack
PFA LFA @      \ gets next nfa

 

Of course, as soon as it gets to a synonym, it gets into an infinite loop. The solution is simple:

\ nfa of last word is on the stack
2- @      \ gets next nfa by backing up to Link Field

 

which is much more efficient, anyway. I will definitely need to see if there are other gotchas before I settle on the way of managing synonyms detailed at the top of this post.

 

Thoughts?

 

...lee

Since you understand the dictionary structure and you are traversing using 2- @  then I can't see how that would be a problem. 

 

[+TheBF]

In ANS Forth synonyms are based on the CFA.

 

Would that be a better way?

 

\ synonym for NON-CODE words   BJF Sept 27, 2018

: SYNONYM   ( <newname>  <oldword> )
           CREATE   '  ,  DOES> @ EXECUTE ;

 

[+Lee Stewart]

11 hours ago, TheBF said:

In ANS Forth synonyms are based on the CFA.

 

Would that be a better way?

 

\ synonym for NON-CODE words   BJF Sept 27, 2018

: SYNONYM   ( <newname>  <oldword> )
           CREATE   '  ,  DOES> @ EXECUTE ;

 

 

That works for CODE words as well, but for fbForth, that would be

: SYNONYM   ( IS:<new name> <old name> )
   <BUILDS [COMPILE] ' CFA , DOES> @ EXECUTE ;

 

That said, I was actually doing that by hand for non-CODE words, but, as I indicated, I am trying to avoid the extra space used in the resident dictionary for that method.

 

...lee

[+TheBF]

Just to exhaust the topic, I found this fancier version of synonym that deals with proper action for Immediate synonyms.

I had never consider this before. Of course a commercial system maker would have to cover all the bases. 

 

\ From "reference implementation". Used by VFX Forth

 : SYNONYM \ "newname" "oldname" --
\ Create a new definition which redirects to an existing one.
   CREATE IMMEDIATE
     HIDE ' , REVEAL
   DOES>
     @ STATE @ 0= OVER IMMEDIATE? OR
     IF EXECUTE ELSE COMPILE, THEN
;

 

 

[+Lee Stewart]

Aha! I think I’ve found a (clever?) way to manage synonyms with no additional Bank #0 code that will also give the proper nfa for the synonym. All I need to do is to add one to the pfa of the original word. The pfa and cfa will be odd, but their usage will always be even (and addresses of the original word), as near as I can tell. The nfa and lfa will be properly even, with the nfa referencing the proper name of the synonym! I think this should work just as long as I don’t use the pfa for byte access on any synonym that occurs in the resident dictionary. I see that only ever happening for VARIABLE or CONSTANT definitions and those should not ever need synonyms in the resident dictionary. I could even ( to coin a phrase  ) force the cfa to even, if necessary.

 

...lee

[+Lee Stewart]

5 hours ago, Lee Stewart said:

I could even ( to coin a phrase  ) force the cfa to even, if necessary.

 

It appears necessary to have an even cfa. I set up WORDS as a synonym for VLIST .  VLIST worked fine, but WORDS listed all the words and then went off into the weeds. I didn’t look very hard for the reason. I just added an instruction to CFA to zero the LSb to force it even and so far, so good.

 

...lee

[+TheBF]

So did you do something like

 

ANDI *SP,>FFFE

 

[+Lee Stewart]

1 hour ago, TheBF said:

So did you do something like

 

ANDI *SP,>FFFE

 

 

Unfortunately, that won’t work or I definitely would have used it. Immediate instructions only work on registers proper. I searched for an unchanging location in low RAM that contained >0001 and used the Set Zeros Corresponding ( SZC ) instruction:

       SZC  @INT2+6,*SP    ;insure it is even (INT2+6 contains >0001)

 

This effectively ANDs the inverse (ones’ complement) of the source operand with the destination operand, making it identical to the spirit of your suggested operation.

 

...lee

Edited July 14, 2023 by Lee Stewart
clarification

[+Lee Stewart]

To give you an idea of the magnitude (so far) of my upgrade effort for fbForth 2.0, I’ve attached my current TODO list. All items completed are in past tense:

fbForth2100_TODO.txt

 

I am seriously considering making this next release fbForth 3.0. Do you think the changes are significant enough to warrant that distinction?

 

...lee

[+TheBF]

That's a healthy list. :-)  (and one evil ELSE removed) 

 

I seems like there are some operational changes like the loop stuff that mean the new version works a little different than the previous version so a new major number is probably a good idea.

 

I always wondered why FBFORTH asks me if I want white on blue screen colours rather than just doing it. ?

 

[+Lee Stewart]

41 minutes ago, TheBF said:

I always wondered why FBFORTH asks me if I want white on blue screen colours rather than just doing it. ?

 

Good point. When I first developed fbForth, I wanted to use a different color scheme from that of TI Forth and TurboForth, so I did. I have always liked blue and white, so I just reversed them. Well, lots(?) of folks preferred the white on blue, which led to my putting in the choice. As time passed, I found myself opting almost exclusively for the white on blue. All that to say that I agree with you and will, indeed declutter the opening block of FBLOCKS by removing that choice.

 

...lee

[+FarmerPotato]

On 7/17/2023 at 8:19 AM, Lee Stewart said:

 

Good point. When I first developed fbForth, I wanted to use a different color scheme

 

...lee

Jerry Pournelle once reviewed Microsoft Word for Windows, and complained it was no longer white-on-blue like in DOS.  He claims that Microsoft then added an obscure checkbox just for him. 
 

When I heard that (90s?), I immediately looked in Word-- it was indeed there. 

[+Vorticon]

On 7/20/2023 at 5:44 PM, FarmerPotato said:

Jerry Pournelle once reviewed Microsoft Word for Windows, and complained it was no longer white-on-blue like in DOS.  He claims that Microsoft then added an obscure checkbox just for him. 
 

When I heard that (90s?), I immediately looked in Word-- it was indeed there. 

Loved Pournelle's articles in Byte (RIP). He actually introduced me to Windows Commander in the late 90's through one of his reviews, and it's the best file manager for Windows I've ever had. Still being updated (now called Total Commander) and I keep getting free upgrades to this day as my original license is still valid. How many software packages still do that? Single author program who actually responds to Email within a few hours. The only file manager I use. Even available on Android.

[+Lee Stewart]

One of the changes I am seriously considering for fbForth 3.0 is revamping the file management system—especially, how DSRLNK works. I am looking  into an implementation of Paolo Bagnaresi’s version as modified by Bill R. Sullivan. I am not sure I want to include Bill’s optional use of CPU RAM PABs and buffers, but I definitely want to use the 5 saved parameters after the first call to DSRLNK so CRU and device/program searches can be minimized with subsequent DSRLNK calls. Whereas Bill suggests a stack for multiple open files, I am thinking of adding those parameters to the head of each PAB.

 

I am also considering using a linked list of PABs, much as TI Basic does—we’ll see.

 

...lee

[+TheBF]

3 hours ago, Lee Stewart said:

One of the changes I am seriously considering for fbForth 3.0 is revamping the file management system—especially, how DSRLNK works. I am looking  into an implementation of Paolo Bagnaresi’s version as modified by Bill R. Sullivan. I am not sure I want to include Bill’s optional use of CPU RAM PABs and buffers, but I definitely want to use the 5 saved parameters after the first call to DSRLNK so CRU and device/program searches can be minimized with subsequent DSRLNK calls. Whereas Bill suggests a stack for multiple open files, I am thinking of adding those parameters to the head of each PAB.

 

I am also considering using a linked list of PABs, much as TI Basic does—we’ll see.

 

...lee

I like where you are going.

 

I have considered adding fields to the PAB as well.  I also feel like there are things that could better use Forth. 

If you pull code that finds the DOT in the device string and replace it with SCAN in ALC you get a reusable word and no speed reduction. 

 

I am not sure which 5 parameters you are referring to but the one that seems to be missing in a standard PAB is the address of the "." character.

I call that the "real pab address" since it is used to reference the pab if I recall correctly. 

 

[GDMike]

1 hour ago, TheBF said:

I like where you are going.

 

I have considered adding fields to the PAB as well.  I also feel like there are things that could better use Forth. 

If you pull code that finds the DOT in the device string and replace it with SCAN in ALC you get a reusable word and no speed reduction. 

 

I am not sure which 5 parameters you are referring to but the one that seems to be missing in a standard PAB is the address of the "." character.

I call that the "real pab address" since it is used to reference the pab if I recall correctly. 

 

And can be used multiple times in tipi as a separator.

In my old program I would start at pos 40 and count "." All the way left to see how many there were.

Edited September 16, 2023 by GDMike

[+Lee Stewart]

On 9/16/2023 at 6:01 PM, TheBF said:

I am not sure which 5 parameters you are referring to but the one that seems to be missing in a standard PAB is the address of the "." character.

I call that the "real pab address" since it is used to reference the pab if I recall correctly. 

 

The five parameters are 

SAVCRU DATA 0    CRU Address of the Peripheral
SAVENT DATA 0    Entry Address of DSR or Subprogram
SAVLEN DATA 0    Device or Subprogram name length
SAVPAB DATA 0    Pointer to Device or Subprogram in the PAB
SAVVER DATA 0    Version # of DSR

 

from the files in this WHTech directory, which are various versions of Paolo’s DSRLNK routine. Of course, they are also present in the DSRLNK from TI Forth (pretty much identical to the E/A version), but I am not sure if they are actually reused anywhere (I will check).

 

I need to parse one of them very carefully to make more descriptive comments as a starting point for fleshing out what I want to do. With “DSK1.FBLOCKS” as an example, SAVLEN seems to be correctly described in that “DSK1” would have a length of 4. However, SAVPAB appears to point to the position after the ‘.’ following the device name (not relevant for subprogram name), which is the actual filename of “FBLOCKS” following “DSK1.” in my example. Just before the DSR/subprogram is called >8356 also has that filename pointer. I guess that is what the DSR needs for level 3 calls. Of course, it would be irrelevant for level 1 and level 2 calls. I have work to do!

 

...lee

Edited September 19, 2023 by Lee Stewart
CLARIFICATION AND CORRECTION

[+TheBF]

19 hours ago, GDMike said:

And can be used multiple times in tipi as a separator.

In my old program I would start at pos 40 and count "." All the way left to see how many there were.

Here is the one I am using with lot of comments as I tried to grok it.

 

I hesitate to offer it since it might add to confusion.

It's written in my cross-compiler Forth it has some odd additions.

I also changed how I manage the workspace and the little name buffer.

 

If nothing else it might help understand some sections as I changed some of the jumps to structured loops.

And I even found one instruction inside a loop that could be removed to the top of the loop.

 

CAMEL99-ITC/Compiler/cc9900/SRC.ITC/DSRLINKA.HSF at master · bfox9900/CAMEL99-ITC · GitHub

 

 

[GDMike]

I see it here

8356 @@ R0 MOV, \ [PAB FNAME] to R0

       R0 R9 MOV, \ dup R0 to R9

[+TheBF]

18 hours ago, GDMike said:

I see it here

8356 @@ R0 MOV, \ [PAB FNAME] to R0

       R0 R9 MOV, \ dup R0 to R9

LOL. Now you are making try to re-understand this thing. 

 

I think the one I was thinking of was somewhere further down.