IT STARTS! (somewhat)
So this is basically a bunch of random additions and fixes. I feel like this is how it's going to be for a while now.
buffering
When I create C bindings, I store the 'addWord' calls and the FORTH wrapper words in buffers. These must obviously be big enough to fit all the code. I don't want them to be too big tho, as they take from the total memory accessible to the user. This is when you use heap memory allocation.
Yes, from what I understand, the entire memory space for words and allot is allocated on the stack, or at least in a continous memory block allocated at the start (so stack). This is required for FORTH to work properly. You can however allocate on the heap with 'ALLOCATE'. So I do this.
: INIT-ALL ( -- ) \ average bind +- 120 chars? \ -> 100 funcs = 12_000 chars 12000 allocate throw to addWords-body 12000 allocate throw to wrap-words ;
I allocate in 'C-LIBRARY' and I free in 'END-C-LIBRARY'. Nothing that special, but it is a improvement.
Also if you ask what happens if you include too many functions, shit breaks. Don't do that. It might get fixed in further stages of production.
SF! SF@
Words for storing and fetching single precision (32-bit) floats. I don't know much about IEEE floats, so I decided to just implement them in C. Float words are defined in 'exinnrfp.h'. (don't name your files like this)
Here I copied F! and F@ and modified them to use single floats. I also had to modify few more functions, but it wasn't all that exciting.
File operations
In short, I used Gforth's 'EMIT-FILE' and 'SLURP-FILE'. 'EMIT-FILE' writes a single char to a file and 'SLURP-FILE' reads file contents from a file name.
: EMIT-FILE ( c fileid -- ior )
swap pad c!
pad 1 rot write-file
;
: SLURP-FILE ( c-addr1 u1 -- c-addr2 u2 ) \ requires FREE
r/o open-file throw { f }
f file-size throw
drop \ TODO: add SLURP-FILE double support
dup allocate throw
dup rot
\ u u c-addr
f read-file throw
f close-file throw
;
I don't think there is that much to talk about, I just used exeisting words to make these. I feel like this is how FORTH is supposed to work. 'FILE-SIZE' returns double cell integer, but I only use the single part at this time.
Might change this later.
It boots and stuff
So now it didn't crash at compile time. This is a great success, but ex:froth does not have any nice crash message telling me what went wrongat runtime, so I'm stuck with the good old print statement everywhere from now on.
It might be a good idea to work on the debug words next, but I really just want do the first release, which I decided will be once I can run Gforth-tetris.
Anyways, turns out 'SOURCEFILENAME' was not working. Why was it not working? Pointers! What else would it be. Always double check when passing pointers around. I didn't notice that I was storing pointer that was changed later. Oh, well, I just have to get good at C I guess.
Also 'DIRNAME' was not working, but that was just me being dumb or something. I don't know what was I doing back then, but it works now.
By this time, I got to the main screen!! (well, or at least something close to it)
'PLAY' did crash the game, but I was able to change the themes just fine. It really looks like some glitches in old games. neat! I kinda miss those, it rewarded you for thinking out of the box hard enough. Now everything just crashes.
One last ting I changed. Gforth resolves includes relative to current file, but file operations relative to users location. I was just doing everthing relative to the file. After a bunch of hacking and few global variables later, I was able to make it possible to switch path resolving method at runtime. It only throws a bunch of ifs at few places and things should work now.
The game no longer lasts long enough to display anything tho. I feel like it's something config-reading related.
in the end...
I know that I'm probably getting close to finishing, but I will probably take a short break from this project. (I say this like someone reads these, heh)
I have a few other things I would like to do and I feel like I could use some more high-level programming for once. It might be some LISP, or I might do a full 180 and try some shell scripting.
I want to continue the work before christmas, but we'll see.