How do I enter a 1-byte literal from the keyboard?

[IamRob]

This one has me stumped as I can't seem to figure out how to get the compiler to compile a number entered at the keyboard into a 1-byte Cliteral and not a 2-byte literal. I am playing with Fig Forth.

[GARTHWILSON]

I have not been using fig-Forth, but something very similar; so this explanation should fit. It almost deserves a flowchart with your particular scenario highlighted; but this will have to do for now. Hopefully it's clear enough.

Numbers are entered in the input stream as strings separated by spaces. The text interpreter INTERPRET scans the input stream looking for space-delimited strings. It looks up the string in the dictionary. In the case of a number that's not a pre-defined word, it won't find it; so then it calls NUMBER . Assuming it's a valid number, it is put on the stack (otherwise you get the error message "<string> is undefined," and it aborts. In your case, it sounds like you're talking about COMPILER being off (IOW, you're not compiling a colon definition), so the number stays on the stack until you tell it to do something with it. So in your case, you'll want to do C, ("see comma") to compile it as a single byte, or character, where the dictionary pointer DP is pointing, and advance the pointer by one. If you use , ("comma") instead of C, , it will compile two bytes, ie, a standard cell, and advance the dictionary pointer by two. OTOH, if this is in executable code and you're compiling a colon definition and you want it to put a number on the stack when the instruction pointer IP gets to it, just a number by itself won't do it. It must be preceded by lit . When lit executes, it grabs the cell following it and puts that on the stack, then advances the instruction pointer past it so NEXT won't try to use that number as if it were the code field address of a word it's supposed to execute.

Clear as mud? The short version is use C, rather than , .

[IamRob]

I understand all that. I am not looking to store a single byte at HERE.

I am talking a colon definition. I wrote a decoder that decodes each word. Some words like VLIST have CLIT followed by a single byte. 2 bytes follow LIT.

When creating a colon definition, when I enter a number, I want it to compile as CLIT (followed bye 1-byte), but it always compiles as LIT (followed by 2 bytes).

Is it supposed to be automatic that when a number is less than 256, it will compile it as a single byte? Or how do I force it to do that.

[GARTHWILSON]

The normal thing is to use lit and compile two bytes, with the high byte zeroed. I thought Fig-Forth required colon definitions' cells to start at even addresses. Having a single byte following a Clit (which I've never heard of) would violate that.

[IamRob]

For the most part FigForth is a 16-bit Forth. The version that was ported to the Apple was renamed to ProForth, and is closely based on FigForth. Everything mimics FigForth almost exactly except this one addition of a single byte literal called CLIT.

Quite a few system words use CLIT to define a single byte within the word definition, but I can't seem to find a way to replicate it from the keyboard. It is no real biggy, as about all it does is save a byte in each word it is used.

Since the system words contain CLIT, and since I can't find a way to duplicate it when defining a word definition, I can only assume that the words that use it, were assembled that way. That annoys the heck out me to see something being used and I can't use it.

I could probably write a word definition that collapses the word that I want use CLIT in. The word-containing-CLIT would just need to be closed up by one byte where the zero is, the LIT address converted to a CLIT address, and the word would have to be at the end of the dictionary.

I am still in the process of disassembling ProForth, so haven't come across a solution yet. Was hoping someone had a quick and easy answer.

[handyandy]

Is this the source code you're looking for?

https://sites.google.com/site/drjohnbma ... 2/proforth

Cheers,
Andy

[Dr Jefyll]

IamRob wrote:

Since the system words contain CLIT, and since I can't find a way to duplicate it when defining a word definition, I can only assume that the words that use it, were assembled that way.

Yup, for FIG Forth that seems to be the case. By using an assembler to create the system they were able to do some optimizing that wouldn't be possible if the system had been created using its own compiler.

Check out the Forth source code for the word INTERPRET (found in Screen 52 of the source code included in the FIG Forth Installation Manual). Interestingly, INTERPRET will make accommodation for a double (ie, 32-bit value) by compiling DLITERAL instead of the usual LITERAL. But it doesn't check whether CLIT could be used (for an 8-bit value). You might wanna consider altering INTERPRET -- it'd be the cleanest way of solving the problem... if it is a problem. The changes to INTERPRET would easily cost a dozen or two dozen bytes, and it would take just as many subsequent invocations of CLIT before you'd recoup that cost and begin to show a net memory saving.

GARTHWILSON wrote:

I thought Fig-Forth required colon definitions' cells to start at even addresses.

What needs to be at an even address (to accommodate the old NMOS $6C bug) is the Code Field that appears in every word header.

BTW, welcome, IamRob !

-- Jeff

[Dr Jefyll]

IamRob wrote:

Or how do I force it to do that.

To do it within a colon definition I think what you need is something like this. Notice how the nasty bit is bookended by [ and ] (to suspend then resume compilation).

Code: Select all

: PRINT-A-ZERO  ( --- )
[ 0 ' CLIT CFA ,  C, ]
. ;

[IamRob]

Dr Jefyll wrote:

IamRob wrote:

Or how do I force it to do that.

To do it within a colon definition I think what you need is something like this. Notice how the nasty bit is bookended by [ and ] (to suspend then resume compilation).

BTW, welcome, IamRob !

Thanks, I was trying to slip under the radar and look like I have been here all along.
I actually got bored of programming in assembly and when I got a taste of Forth, I was hooked.


: PRINT-A-ZERO ( --- )
[ 0 ' CLIT CFA , C, ]

Yep that works, but slightly modified for real numbers that are not words, but your example shows how I can do it for 0, 1, 2, 3 as well. Thanks.

: TEST CLIT [ 80 C, ] OUT C! ;


It took a little bit to wrap my head around DOES>, and the LBRACKET and RBRACKET were on my to-do list. Now that I got an example of that, just got one more mis-understood word, ";CODE".

I understand what it does, I just don't understand how to enter it, and the code that follows, from the keyboard.

POSTPONE was a common word used a lot to make other words on other platforms, and was finally able to duplicate it in ProForth.

Things are slowly coming together and I enjoy reading everyone's posts here on efficient programming and ideas for words. I look forward to adapting some of your words to the ProForth model I am working on.

And one last thing, is there a resource for source listings of any applications that were written in Forth?
So far I have collected 2 games, 2 applications and 1 demo written in forth and am greedy for more.

I will probably stay mostly in the background since I am no where near your levels of expertise and will pop in with a question now and again. But thanks! Great group of people.

[JimBoyd]

Dr Jefyll wrote:

IamRob wrote:

Since the system words contain CLIT, and since I can't find a way to duplicate it when defining a word definition, I can only assume that the words that use it, were assembled that way.

Yup, for FIG Forth that seems to be the case. By using an assembler to create the system they were able to do some optimizing that wouldn't be possible if the system had been created using its own compiler.

Check out the Forth source code for the word INTERPRET (found in Screen 52 of the source code included in the FIG Forth Installation Manual). Interestingly, INTERPRET will make accommodation for a double (ie, 32-bit value) by compiling DLITERAL instead of the usual LITERAL. But it doesn't check whether CLIT could be used (for an 8-bit value). You might wanna consider altering INTERPRET -- it'd be the cleanest way of solving the problem... if it is a problem. The changes to INTERPRET would easily cost a dozen or two dozen bytes, and it would take just as many subsequent invocations of CLIT before you'd recoup that cost and begin to show a net memory saving.

What is easier still is to change LITERAL , especially if you are building your own Forth. This will also help words like ASCII that use LITERAL .

Code: Select all

HEX
: LITERAL  ( N -- )
   DUP 100 U<
   IF  COMPILE CLIT C, EXIT  THEN
   COMPILE LIT , ; IMMEDIATE

Dr Jefyll wrote:

GARTHWILSON wrote:

I thought Fig-Forth required colon definitions' cells to start at even addresses.

What needs to be at an even address (to accommodate the old NMOS $6C bug) is the Code Field that appears in every word header.

Actually the code field can be at an odd address as long as it doesn't straddle a page boundary. One way to deal with this is to have CREATE check to see if the code field will straddle a page boundary. If it will, CREATE allots one byte before laying down the header ( the link and name fields ) .

[GARTHWILSON]

JimBoyd wrote:

Dr Jefyll wrote:

GARTHWILSON wrote:

I thought Fig-Forth required colon definitions' cells to start at even addresses.

What needs to be at an even address (to accommodate the old NMOS $6C bug) is the Code Field that appears in every word header.

Actually the code field can be at an odd address as long as it doesn't straddle a page boundary. One way to deal with this is to have CREATE check to see if the code field will straddle a page boundary. If it will, CREATE allots one byte before laying down the header ( the link and name fields ) .

I have the assembly source listing paper book here from FIG from before all this stuff was online, but I couldn't take the time to dig into the details again to make sure I wasn't missing implications here or there. When I did my own extensive modifications and did it for 65c02, I kept the alignment because it made it easier for SEE (the de-compiling word), FIND, and >NAME showing names with special characters whose high bit was set. The CFA, BTW, is not part of the header. You can compile headerless code but you still need the CFA in ITC Forth.

[IamRob]

handyandy wrote:

Is this the source code you're looking for?

https://sites.google.com/site/drjohnbma ... 2/proforth

Cheers,
Andy

I have been working off of that source code. What I am trying to do is create a bare minimum source that is the bare minimum of words that can create a word definition followed by a few OS calls to load a text file. All other words will be collected in a main dictionary type text file that can be copy/pasted to a working text file of an application or game that can then be compiled.

This would have the result that after an application or game is completed it will only contain the words that are used and not have any non-used words bloating the application.

[Dr Jefyll]

JimBoyd wrote:

Dr Jefyll wrote:

What needs to be at an even address (to accommodate the old NMOS $6C bug) is the Code Field that appears in every word header.

Actually the code field can be at an odd address as long as it doesn't straddle a page boundary.

Yup, of course that's right. Somehow I got thinking that FIG went even further, and aligned *all* Code Fields (even though it's only the page boundary that matters).

[JimBoyd]

GARTHWILSON wrote:

The CFA, BTW, is not part of the header. You can compile headerless code but you still need the CFA in ITC Forth.

I know. Fleet Forth is an ITC Forth and it has seven headless ( headerless? ) words in the kernel.

[Dr Jefyll]

I think Garth's correction was aimed at me, since I did refer to the CFA as part of the header. To me, "header" has always simply meant the fields that routinely begin a word's entry in the dictionary. But I won't quibble with the notion it should only be taken to mean the Name Field and Link Field. That'd be consistent with what's meant by headerless definitions.