CHAPTER 13. SPECIAL LIBRARIES 216
That’s all! Before you can use an FSM, you first have to activate it and set the initial state.
Note that upon definition the FSM already is activated with state zero, but is a good habit to explicitly initialize it: fixed.pt to fsm.current
0 fsm.state !
We only have to transform the character to the appropriate class in order to make this baby fly:
0 enum ’other’ enum ’digit’ enum ’sign’ constant ’point’ create categorize char 0 , ’digit’ , char 1 , ’digit’ , char 2 , ’digit’ , char 3 , ’digit’ , char 4 , ’digit’ , char 5 , ’digit’ , char 6 , ’digit’ , char 7 , ’digit’ , char 8 , ’digit’ , char 9 , ’digit’ , char + , ’sign’ , char - , ’sign’ , char . , ’point’ , does>
2 num-key row if cell+ @c else drop ’other’ then nip
; char , , ’point’ ,
NULL ,
Time to execute, which is hardly rocket science either: s" bad-345.rubbish4467invalid" begin dup while over c@ dup categorize fsm.run
chop repeat 2drop cr
Mission accomplished. Note you can define as many FSMs as you need. If you want to switch between them just activate them before use. Since the state is part of the FSM, it will remain unchanged between calls.
13.11
Virtual memory
Although computers have lots of memory nowadays, you may find yourself in a situation where you don’t have enough memory to cater for your needs. In that case you may resort to using 4tH’s virtual memory library.
4tH’s virtual memory library uses block files, so you may need to create one before you can use it. Since block files are character-oriented you need to include another library if you need numerical data: include lib/vmem.4th
include lib/ncoding.4th
CHAPTER 13. SPECIAL LIBRARIES
That’s all so let’s define some variables and open the block file we created previously: variable n1 nell vallot latest ! does> paging ; variable s1 32 vallot latest ! does> paging ; variable s2 128 vallot latest ! does> paging ; variable s3 512 vallot latest ! does> paging ; variable s4 512 vallot latest ! does> paging ; s" vmemtest.scr" open-blockfile
217
When setting this up, you have to take three things in consideration:
1. Although it isn’t required, you’d better define virtual memory variables in order, from the smallest to the largest;
2. The size of a virtual memory variable may not exceed "B/BUF" address units;
3. You have to make sure that all data fits in the block file. Take into consideration that no variable can span two blocks, so there’ll be some overhead. The easiest solution is not to take any risks and simply oversize it - disk space is relatively cheap.
Now you can access them like any other variable:
2960 n1 n! & s" This is a virtual memory string" s1 place &
It looks (almost) completely normal, doesn’t it? Except for that ampersand, of course. This ampersand has to be added every time you write to a virtual memory variable. It signals to the underlying block management system that the block is now "dirty". If you think that’s too cumbersome for your taste, you may adopt another solution - it’s not that complicated.
Reading a variable is no problem at all: do as you’ve always done: n1 n@ . s1 count type cr
And what about arrays? Well, first of all they have to be character based. And they’re restricted to "B/BUF" address units. Or are they? As a matter of fact, they don’t - but they do need some special treatment.
First of all, you have to think of the element size, which must be a power of two and may not exceed "B/BUF" address units. Second, you need to know how many rows you require.
Now we can define it:
64 constant /row
80 constant #row variable a1 20 nells vallot latest !
does> swap nells +paging ; variable a2 /row #row * vallot latest !
does> swap /row * +paging ;
So "a1" is an integer arrays and "a2" is a string array. So far, so good. But what have we defined at the ’DOES>’ part? Well, to address an array we’re going to write:
5 a1 10 a2
