TurboForth V1.2 (Beta)--Evolution & Arcana

[+Lee Stewart]

Rod,

 

What do I do with the words+ file in the zip file? I tried putting it in a classic99 DSK folder but classic99 can't process it.

 

What type of file is it?

 

Mark

 

It looks like a proper TI file, but the TI name does not match the DOS name. I opened it successfully in TI99DIR, but maybe the DOS name should be changed to WORDS++ or the TI name to WORDS+. I think this happened once before with files Rod posted.

 

...lee

[+Lee Stewart]

It looks like a proper TI file, but the TI name does not match the DOS name. I opened it successfully in TI99DIR, but maybe the DOS name should be changed to WORDS++ or the TI name to WORDS+. I think this happened once before with files Rod posted.

 

...lee

 

Yup! If you rename the file to WORDS++, you can open it with S" DSKn.WORDS++" USE . Then, 1 EDIT to edit it. It actually opens without renaming, but it has apparent disk header information on the first two block lines that shouldn't be there. Renaming the DOS file to the same name as the TI file straightens things out. I'm sure Rod will clear up the mystery when he gets back online.

 

...lee

[+Lee Stewart]

Floating Point Library (FPLTF)---

 

I was looking at instruction execution times for BLWP BL and RT (B *R11) to get a handle on whether I want to really worry about saving 256 bytes in the FPLTF library. It looks like those two branches will take on the order of 22µs 15µs! Is that right?! And, is that worth saving the 256 bytes? That works out to almost 40% 27% more execution time for the 4 MOV instructions. I assumed 2 wait states for each memory access---I don't know if that's correct. It probably isn't because the branches are in CPU 8-bit RAM and the MOV's are CPU 16-bit RAM for the registers ( *Rn+ and *Rn) with some of the referenced memory on the 16-bit bus and some on the 8-bit bus. @Tursi? @sometimes99er? @InsaneMultitasker? @Stuart? @matthew180? @Willsy?

 

...lee

Edited October 27, 2012 by Lee Stewart

[Willsy]

Well, I would just say that 22uS maybe sounds a lot, but its one of the faster instructions. IMHO it's only worth worrying about if those MOVs are in a loop somewhere... A 22uS overhead to them once, even twice? No problem... If it's 50 times in a loop... yeah... problem!

 

Just my 2 cents!

 

Did you try the loader?

[Willsy]

Loader....

 

 

Attached is the TF companion disk with the #3 loader added to blocks 48 and 49. If you are using your own personalised disk you can use the CPYBLK utility on block 22 to copy blocks 48 and 49 on the companion disk to your own disk.

 

With the debug stuff stripped out it's 682 bytes. Not bad.

 

Have at it!

 

BLOCKS.zip

[+Lee Stewart]

Well, I would just say that 22uS maybe sounds a lot, but its one of the faster instructions. IMHO it's only worth worrying about if those MOVs are in a loop somewhere... A 22uS overhead to them once, even twice? No problem... If it's 50 times in a loop... yeah... problem!

 

Just my 2 cents!

 

Did you try the loader?

 

I corrected my estimate. I had BLWP on the brain, but the more expensive branch is BL, which doesn't take quite as long. It looks like it takes about 15µs, 27% longer, not 40%. That's with 2 wait states for every memory access, which is probably not correct. And, none of these is in a loop IIRC.

 

I haven't tried your loader yet. I'll probably do that later today or tomorrow. I will probably dispense with most of the DEFs because I can't really see any use for them in the 4A except, possibly, for testing. The only one I may keep is the one I added for FPLLNK, which should allow me to avoid hard-wiring the BLWP from TF.

 

...lee

[+Lee Stewart]

Loader....

 

 

Attached is the TF companion disk with the #3 loader added to blocks 48 and 49. If you are using your own personalised disk you can use the CPYBLK utility on block 22 to copy blocks 48 and 49 on the companion disk to your own disk.

 

With the debug stuff stripped out it's 682 bytes. Not bad.

 

Have at it!

 

BLOCKS.zip

 

Thanks! :thumbsup:

 

I had a problem at first, but it was of my own making! I had renamed the file to "BLOCKS02", which resulted in the same problem we had with Rod's file, viz., disk header information in block 1, causing an offset on every block that renders the file useless. After using TI99DIR to rename the TI file to "BLOCKS02", everything is back in line!

 

...lee

[Rod Van Orden]

Mark and Lee:

I saw your posts here on files with the naming problem. With several emulators / simulators in use, we should

all be careful to check the names. As Lee has suggested, if the TI name and the PC name match (Use TiDir

and/or the Win994a Manager), then everything will run smoothly. I've caught myself several times now......

 

I want to name the words routine: WORDS+, not WORDS++. I worked up some fixes, as Lee suggested, and there

was some improvement; however, I am strongly considering completely rewriting the WORDS+ routine. I think the

original WORDS routine under Forth-83 should remain exactly the same, whenever it returns in the cart (or not).

My purpose in putting WORDS+ together is to come up with a more useful tool in addition to WORDS.

 

I have some deadlines I need to meet at work this week, so I'm totally shot until at least mid week. Back to you then.

 

Rod

[+Lee Stewart]

Floating Point Library (FPLTF)---

 

@Willsy...

 

I'm having a little trouble with a couple of things:

1. Executing #3LOAD ends with a "Can't read from file" message after it has apparently successfully loaded the file. I say apparently because I have not yet tested it, but the first and last 16 bits are correct and the one DEF results in a TF word of that name. It also leaves TF in HEX mode and displaying 4 digits with leading zeroes after "ok:" and .S . It increases to 5 digits after some stack use.
    
   
2. Attempting to LOAD block 36 (FP stuff) hangs Classic99. If I LOAD each block separately, it hangs at block 38. This one probably doesn't matter because I will be redoing most of it one word at a time while testing the FPLTF library. I would just like to run it to ground, however.
   

Any ideas?

 

...lee

Edited October 29, 2012 by Lee Stewart

[+Lee Stewart]

Floating Point Library (FPLTF)---

 

@Willsy...

 

I'm having a little trouble with a couple of things:

1. Executing #3LOAD ends with a "Can't read from file" message after it has apparently successfully loaded the file. I say apparently because I have not yet tested it, but the first and last 16 bits are correct and the one DEF results in a TF word of that name. It also leaves TF in HEX mode and displaying 4 digits with leading zeroes after "ok:" and .S . It increases to 5 digits after some stack use.
    
   
2. Attempting to LOAD block 36 (FP stuff) hangs Classic99. If I LOAD each block separately, it hangs at block 38. This one probably doesn't matter because I will be redoing most of it one word at a time while testing the FPLTF library. I would just like to run it to ground, however.
   

Any ideas?

 

...lee

 

H-m-m-m, the aborted #3LOAD also leaves HERE in low memory. My guess is that the end-of-file check is one read too far and the ABORT" leaves things in an unrestored state.

 

...lee

[Willsy]

H-m-m-m, the aborted #3LOAD also leaves HERE in low memory. My guess is that the end-of-file check is one read too far and the ABORT" leaves things in an unrestored state.

 

...lee

 

Seems to be, but I can't reproduce the error here (in classic99). Can you zip your object file and send it to me?

 

In the meantime here is the code I finished up with. Oh, and while I think of it, here is a new build... Check the fix list in the release note; I found an issue with EOF (actually while working on the loader) and that could very possibly be the source (no pun intended) of your problem. In fact, thinking about it, it almost certainly is. Sorry - I should have posted a build earlier. However it changed as recently as last night; I recommend you have a read through the release note. Nothing major, but continual improvements/refinements.

 

option 3 loader.txt <--- changed slightly

TF-V1.2-29-OCT-2012.zip

V1.2-ReleaseNote.pdf

BLOCKS.zip <--- has the #3 updated loader on blocks 48 and 49

[Willsy]

1. Attempting to LOAD block 36 (FP stuff) hangs Classic99. If I LOAD each block separately, it hangs at block 38. This one probably doesn't matter because I will be redoing most of it one word at a time while testing the FPLTF library. I would just like to run it to ground, however.
   

Good morning Lee!

 

Yes. Took me a while to find it though... Have a look at the definition of F0< on block 38. It's defined as follows:

 

: F0< >F 0 F< ;

 

So, it puts a floating point 0 on the fp stack to compare against*, then calls F<.

 

Now have a look at the definition of >F a few lines above it. It is an immediate word. Long story short: >F indirectly calls XMLLNK, which is implemented in assembly (defined in block 36) and the assembly code is out of date: The stacks' directions have been reversed since that code was written. So during compilation of F0< a call to >F is made, and we're into the weeds... That'll be the reason for the crash. A few pointers may also have moved (sigh) but their locations will be fixed once we have a stable build.

 

Do you want me to have a look at updating the assembly code? My opinion is that it's not worth it... I assume you will come up with your own Forth and assembly code to support the FPL, which may or may not be based on the existing Forth code in the current FP library. [ Irrelevant rambling: I was quite pleased with how I factored the code, it seems (even now, after months) quite readable. But there again, I wrote it - it might be gibberish to all but me! Wouldn't be the first time ]

 

* I wonder at the utility of comparing a floating point number to 0.000000000000000 etc. I imagine it could be fraught with pitfalls.

[+Lee Stewart]

Seems to be, but I can't reproduce the error here (in classic99). Can you zip your object file and send it to me?

 

In the meantime here is the code I finished up with. Oh, and while I think of it, here is a new build... Check the fix list in the release note; I found an issue with EOF (actually while working on the loader) and that could very possibly be the source (no pun intended) of your problem. In fact, thinking about it, it almost certainly is. Sorry - I should have posted a build earlier. However it changed as recently as last night; I recommend you have a read through the release note. Nothing major, but continual improvements/refinements.

...

 

Thank you, Sir!

 

Object file is attached: FPLTF_OBJ.zip

 

...lee

[Willsy]

Just tried the object code you attached (thanks!). It loads with the latest version of the loader (see earlier post from yours truly) with no errors. It appears to load starting at >2000 and defines a single word called FPLLNK.

 

[+Lee Stewart]

Good morning Lee!

 

Yes. Took me a while to find it though... Have a look at the definition of F0< on block 38. It's defined as follows:

 

: F0< >F 0 F< ;

 

So, it puts a floating point 0 on the fp stack to compare against*, then calls F<.

 

Now have a look at the definition of >F a few lines above it. It is an immediate word. Long story short: >F indirectly calls XMLLNK, which is implemented in assembly (defined in block 36) and the assembly code is out of date: The stacks' directions have been reversed since that code was written. So during compilation of F0< a call to >F is made, and we're into the weeds... That'll be the reason for the crash. A few pointers may also have moved (sigh) but their locations will be fixed once we have a stable build.

 

Thanks for finding the problem! :thumbsup:

 

Do you want me to have a look at updating the assembly code? My opinion is that it's not worth it... I assume you will come up with your own Forth and assembly code to support the FPL, which may or may not be based on the existing Forth code in the current FP library.

 

Nah. The only reason to maintain xmllnk in TurboForth is floating point math and number conversions (number-string and string-number). If you indeed incorporate our ALC floating point library into TF, that reason evaporates.

 

 

[ Irrelevant rambling: I was quite pleased with how I factored the code, it seems (even now, after months) quite readable. But there again, I wrote it - it might be gibberish to all but me! Wouldn't be the first time ]

 

As well you should be! I will most certainly be hewing to the line you have established with your code in any of my modifications of it.

 

* I wonder at the utility of comparing a floating point number to 0.000000000000000 etc. I imagine it could be fraught with pitfalls.

 

I am not sure what the problem could be...unless wrong assumptions are made. After all, only the first cell (16 bits) of each number should be compared because of the way floating point numbers on the 4A are configured:

• POSITIVE: A non-zero floating point number's first radix-100 digit (2nd byte of 1st cell) must never be 0.
  
• NEGATIVE: A negative floating point number must be the absolute value of the number with only the 1st cell complemented, i.e., NEGed, resulting in the only instance in which the 1st word's sign bit is set.
  
• ZERO: A floating point zero's first cell must be 0 and the remaining 3 cells can be anything, though the 4A's number conversion routine appears to zero the first 2 cells. This means that the result of comparing the following 2 floating point numbers (expressed as 4 hex cells each) is that they are equal and both equal to 0: [0000h 0000h 0000h 0000h] and [0000h FFFFh FFFFh FFFFh]!
  

...lee

Edited November 6, 2012 by Lee Stewart

[+Lee Stewart]

Just tried the object code you attached (thanks!). It loads with the latest version of the loader (see earlier post from yours truly) with no errors. It appears to load starting at >2000 and defines a single word called FPLLNK.

 

 

Cool beans!

 

Regarding the TF definitions of ALC DEFs: I think I would prefer that they be defined as CONSTANTs so that any of the TF assembler branch instructions can be used. I am currently doing a BLWP, to FPLLNK (2000h), so I can't use the defined FPLLNK from #3LOAD .

 

...lee

[Willsy]

Actually that's a good idea. Consider it done. Executing a DEF'd address would be no more complex than <name> EXECUTE so no functionality is lost. Like it!

[+Lee Stewart]

Actually that's a good idea. Consider it done. Executing a DEF'd address would be no more complex than <name> EXECUTE so no functionality is lost. Like it!

 

...and, another thing... I will not want to keep the loader once the object file is loaded. FORGETting LAddr will, of course, undo your DEF definitions. Even were I to keep the loader, I would want them to start back in the original dictionary space, not backed up against where I loaded my object file. I know you restored HERE to follow the loader in the original dictionary space; but, if I FORGET the DEF definitions, I'm right back after my object code for adding new words.

 

...lee

[Willsy]

Okay, here we go!

 

Attached:

• New build *
  
• Release note for above
  
• Blocks file with updated loader (creates CONSTANTs for DEF'd entries) on blocks 48 & 49.
  

*since we're creating constants at run-time we need to get a reference to DOCON - but it's headerless, therefore I created a pointer to it. See release note. Threw in a pointer to CREATEs run-time code while I was at it (variables are implemented via CREATE).

 

TF-V1.2-30-Oct-2012.zip

V1.2-ReleaseNote.pdf

BLOCKS.zip

[+Lee Stewart]

Okay, here we go!

 

Attached:

• New build *
  
• Release note for above
  
• Blocks file with updated loader (creates CONSTANTs for DEF'd entries) on blocks 48 & 49.
  

*since we're creating constants at run-time we need to get a reference to DOCON - but it's headerless, therefore I created a pointer to it. See release note. Threw in a pointer to CREATEs run-time code while I was at it (variables are implemented via CREATE).

 

Thanks, Mark! :thumbsup: I know I'm gettin' to be a royal pain in the ass! Thanks for your good-natured perseverance.

 

...lee

[Willsy]

Well, this will get you halfway there: BLOCKS.zip

 

It creates the definitions in high memory, right after the loader.

 

Verify it thus:

 

FPLLNK $.

' FPLLNK $.

 

To remove the loader, you now have to move (using CMOVE or COPYW) the FPLLNK definition up memory, over the top of the loader, then adjust LATEST and H. I'll leave you to ponder on that one!

 

Oh, by the way, the loader, despite being more useful than the first incarnation on Saturday is now 42 bytes shorter, weighing in at 640 bytes. Not bad

[+Lee Stewart]

Well, this will get you halfway there: BLOCKS.zip

 

It creates the definitions in high memory, right after the loader.

 

Verify it thus:

 

FPLLNK $.

' FPLLNK $.

 

To remove the loader, you now have to move (using CMOVE or COPYW) the FPLLNK definition up memory, over the top of the loader, then adjust LATEST and H. I'll leave you to ponder on that one!

 

Oh, by the way, the loader, despite being more useful than the first incarnation on Saturday is now 42 bytes shorter, weighing in at 640 bytes. Not bad

 

Very cool! I'll work on it a little later.

 

...lee

[Tursi]

 

 

Yup! If you rename the file to WORDS++, you can open it with S" DSKn.WORDS++" USE . Then, 1 EDIT to edit it. It actually opens without renaming, but it has apparent disk header information on the first two block lines that shouldn't be there. Renaming the DOS file to the same name as the TI file straightens things out. I'm sure Rod will clear up the mystery when he gets back online.

 

...lee

 

I just noticed this, and yeah, I wanted to note, this was why I deprecated V9T9 files in my emulator. The V9T9 file contains the TI version of the filename in its header (and certain characters mangle the DOS filename). However, if you rename the DOS filename, the TI filename doesn't stay in sync. Classic99 uses matching between the DOS filename and the TI filename to confirm it's a valid V9T9 file, and the debug window should complain if it can't tell. So if you want to rename a V9T9 file, you have to change both the DOS filename and the filename in the header, and keep it 10 chars or less.

 

TIFILES files don't have these problems (excluding name-in-header extensions which I don't support). The name is not inside the file so you are free to change the DOS filename to anything you like, anytime.

 

[+Lee Stewart]

...

To remove the loader, you now have to move (using CMOVE or COPYW) the FPLLNK definition up memory, over the top of the loader, then adjust LATEST and H. I'll leave you to ponder on that one!

...

 

Well...If there is only one DEF, here is a way to do it without knowing the word's format ahead of time:

 

' LAddr >LINK \ get the link address (LFA) of the destination word (DW)

\ (stack: dw_lfa)

DUP 2+ LATEST @ 2+ \ copy DW's LFA + 2; get last word's (LW) LFA + 2

\ (stack: dw_lfa

dw_lfa+2 l

w_lfa+2

)

SWAP OVER OVER \ swap order; copy LW's LFA+2; copy DW's LFA+2

\ (stack: dw_lfa lw_lfa+2 dw_lfa+2

lw_lfa+2 dw_lfa+2

)

- HERE DUP \ get byte distance to DW from LW; get HERE address and copy it

\ (stack: dw_lfa

lw_lfa+2 dw_lfa+2

distance

here here

)

ROT - H ! \ rotate distance to top; calculate new HERE; update it

\ (stack: dw_lfa

lw_lfa+2 dw_lfa+2 here)

LATEST @ 2+ - \ get LW's LFA again; calulate number of bytes to copy

\ (stack: dw_lfa

lw_lfa+2 dw_lfa+2

bytes

)

CMOVE \ copy last word to new location

\ (stack: dw_lfa)

LATEST ! \ store DW's LFA in LATEST

 

If there's more than 1 DEF, it's a bit more complicated, but I'll work on it.

 

...lee

[+Lee Stewart]

Floating Point Library (FPLTF)---

 

Just a quick update: I expect to start testing the FPLTF library later today! I've defined the words I need to call the library and am working, at the moment, on redefining the high-level TF FP functions.

 

...lee