Add :NONAME word about taliforth2 HOT 12 CLOSED

The problem with this word in Tali Forth will probably be that ; assumes we want to write the new definition to the Dictionary, which is exactly not the case with :NONAME

from taliforth2.

:NONAME can use the the WORKWORD variable, setting it to zero so ; (semicolon) can check if the word being defined is to go in the Dictionary or :NONAME. Zero allows a quick and easy check with

lda workword
ora wordword+1
beq ...

and is not in danger of being used. Other words that must be changed are RECUSE, which can also use WORKWORD. Testing RECURSE and :NONAME requires CASE for the ANSI examples.

from taliforth2.

Looking at the code for : and ;, it looks like :NONAME really just needs to push HERE, set WORKWORD to zero, and change to compile state. Then, ; needs to be modified to skip the code that modifies the header (setting the end address) and the code that makes this word the first in the dictionary. ; should still put the RTS in the dictionary and change the state back to interpret mode.

EDIT: I just noticed your mention of RECURSE. That certainly makes it more exciting because any immediate words between :NONAME and RECURSE might push values on top of the data stack, hiding the return address that :NONAME put there. I'm thinking especially of IF, which you really need to stop the recursion. Can I hide the address on the return stack for RECURSE to find?

I'm interested in giving it a shot.

from taliforth2.

I see DOES> is also allowed in a :NONAME. I'm thinking that's going to be fine, even though I don't have a really good understanding of that word. That's going to become the runtime of a later word created with this one, and doesn't need a name token for that.

from taliforth2.

This of course got me wondering what happens if you use RECURSE in a DOES> in a :NONAME. Apparently the forth folks wondered this too, as they say it's ambiguous in the standard. I think I'll leave it at that, as there are enough non-ambiguous things in forth to wrap one's mind around.

from taliforth2.

For some reason I can't formally assign you if I opened the issue, which is weird, but please do go ahead -- with luck I'll get some longer time at the computer Friday evening. DOES> always makes me nervous as well (I still can't get over the double use in that one test of >BODY). I've actually never made much use of :NONAME, which is probably wrong, it pops up a lot with other people.

from taliforth2.

The test for COMPILE, requires :NONAME. I'll add the testing code, commented out, until this works.

from taliforth2.

I had a couple of implementation thoughts I wanted to discuss.
I need to have the xt address available for RECURSE without being able to use the nt to get to it. If I store a 0 into WORKWORD as a flag, that wastes a memory location that could have held the xt address I need.

Thought1

Because a NONAME: xt will always be in RAM, and because Tali2 has ROM at $8000 and above, I could use the most significant bit in WORKWORD to indicate if it holds a : or NONAME: address. RECURSE and ; could then look at that bit and respond correctly.

I don't like this idea because it makes Tali2 less portable.

Thought 2

I have spare bits available in histinfo as I currently only use bits 2-0 for the current history buffer and bit 7 for making CTRL-N recall the CURRENT buffer the first time you use it. I could use a bit there (like bit 6) to keep track of what the address in WORKWORD is. RECURSE and ; can refer to that bit to see which behavior they should use.

I like this better. The histinfo memory location should probably be renamed to something like internal_status or something like that (todo - think of clever name for a multi-use byte)

Any thoughts?

from taliforth2.

I hadn't thought of the combination of RECURSE and :NONAME. Ugh. I don't like Though1 either, though it's clever, for the reason you stated. Thought2 sound good, and we might figure out some use for the other bytes later. Just "status" as a name, or is that too simple?

from taliforth2.

I think "status" is fine. I technically reserved 16-bits for histinfo (because all of the other variables there were 16-bit), even though ACCEPT only uses the lower byte. The code for ACCEPT currently assumes it has full control of that lower byte (eg it zeros bits it doesn't want), and I'm already sad at how large ACCEPT is, so I think the easiest path is to just make a label for the high byte separately as "status". I'll use bit 7 for this application because it's easy/quick to test.

EDIT: I totally forgot I was using the upper half of histinfo to keep track of the length in the history buffer. Looks like I will need to squish this bit into the lower byte. There is room, but I'll need to modify ACCEPT so it doesn't clobber it.

from taliforth2.

In the future, it might be nice to move state (also a binary) into a bit in status and free up an extra word for the data stack. I think state would make more sense as bit 7 (easier to test), so I'll move put :NONAME status in bit 6 (still easy to test with BIT). If that sounds like a good idea to you, we can plan it as a separate issue as there are several words that use state.

from taliforth2.

I've got initial code for :NONAME, :, and ; (haven't made it to recurse yet) and I'm trying to get the test (found in core.fs) to run:

 :noname dup + ; constant dup+  ( works as expected )
 { : q dup+ compile, ; -> } ( this one looks weird to me)
 { : as [ q ] ; -> } ( this one fails with No such xt found in Dictionary)
 { 123 as -> 246 }

see q gives:

 nt: 1828  xt: 1831  NN 
 size (decimal): 277 
 
1831  20 23 18 E0 77 30 03 4C  D6 B6 B5 01 48 B5 00 48 
1841  20 28 8C B5 00 85 28 B5  01 85 29 F6 00 D0 02 F6 
1851  01 A1 00 85 24 29 02 F0  0D A5 28 95 00 A5 29 95 
1861  01 20 17 9A 80 1C A5 24  29 08 F0 03 4C BE 85 A5 
1871  28 95 00 A5 29 95 01 20  17 9A 18 C5 1A 90 03 4C 
1881  BE 85 CA CA CA CA B5 04  95 00 B5 05 95 01 68 95 
1891  04 68 95 05 A5 00 95 02  A5 01 95 03 A0 00 B9 AC 
18A1  85 D5 04 D0 09 C8 B9 AC  85 D5 05 F0 0D 88 B9 AC 
18B1  85 19 AD 85 F0 27 C8 C8  80 E4 88 98 4A A8 B9 B8 
18C1  85 85 28 18 75 04 95 04  B5 05 69 00 95 05 06 28 
18D1  38 B5 00 E5 28 95 00 B5  01 E9 00 95 01 A5 1C 05 
18E1  1D F0 20 A5 24 29 10 F0  1A 18 B5 04 69 07 95 04 
18F1  B5 05 69 00 95 05 38 B5  00 E9 07 95 00 B5 01 E9 
1901  00 95 01 B5 01 48 B5 00  48 20 BC 8E 18 68 65 00 
1911  85 00 68 65 01 85 01 80  2C CE 92 B9 92 E4 96 3E 
1921  98 B4 97 00 00 04 04 04  06 06 00 A9 20 92 00 A0 
1931  01 68 91 00 C8 68 91 00  A9 03 18 65 00 85 00 90 
1941  02 E6 01 E8 E8

which seems rather large to me for a word that puts a constant on the stack and then compiles it into the dictionary, but most of it is compile,. The 20 23 18 is a call to the dup+ "constant" code that puts the address of my :noname word on the stack. The rest is a direct copy of compile,. I can test that the constant and :noname are working correctly by doing 2 dup+ execute . which shows 4 ok, so I'm thinking the issue is in compile,.

Oh... now that I look at the code for compile,, it's way more complicated than I thought.
Uh oh... compile, expects to be able to look up the name token. Looking in xt_int_to_name shows where that error message is coming from.

I think I want to make it so that looking up an xt that isn't in the dictionary doesn't create an error, but rather just returns some sort of flag to indicate it's not in the dictionary. The fact that it wasn't in the dictionary is important because it means compile, should just compile it as a jsr and not even bother looking at status info in the nt. I was originally concerned that I might break int_to_name, but I see that it's a Tali2 word.

I checked with gforth, and it returns 0 when >NAME is run on a :NONAME word.
I'm going to try using gforth's behavior (INT>NAME returns 0 for an xt without an nt). COMPILE, already saves the xt on the return stack, so I will still have a copy of it if INT>NAME returns 0.

from taliforth2.