I have already "unshrunk" Qforth source code sitting around that I downloaded from somewhere, the Ground archive I think. However, you might be able to save yourself a lot of trouble. (The header for each archived file contains the "NuFX" ID string.) Anyway, there's a C program out there specifically designed for creating/extracting these files on non-Apple systems. The header for the first (archived) file starts at the 48th byte, so those 4 bytes will be $4E $F5 $46 $D8, which is the string "NuFX", again with bit 7 alternating. NuFX files can be identified by the first 6 bytes: $4E $F5 $46 $E9 $6C $E5, which is the ASCII string "NuFile" with bit 7 alternating. Not sure where you downloaded it but there's a chance it's a NUFX archive (a.k.a a Shrinkit archive), which is a funky Apple II archive format (Shrinkit is the name of the application that creates and extracts these files). I use hashed chained linked list to hold the words. How much? I don't know- hopefully 5-10 times Obviously if the list were separated into, for example, a list of one-character names, another list of two-character names, another of three-character names, and so on, the searches would be much shorter, and the compilation would be much faster. I know my own 65c6 Forths' compilation is slowed way down by the fact that FIND has to look through possibly up to a thousand headers all in the same linked list to find a particular word. I'm usually not very interested in compilation speed because it does not take a high percentage of any given project's time but there are times I think it would be nice to be able to compile an entire large application in just a second.
Samuel has talked about ultra-fast Forth compilation. Is there another slick way I'm missing? Are there better ways to separate names in a vocabulary than by length?Ī. The increment for each hop would always be the same for the particular list.Īny other ideas I can come up with are just variations on these themes. It seems like it'd be better if FIND worked the same regardless of which list you're searching.Īnother possibility would be to anticipate a maximum amount of bank-1 memory you'd want to allocate for each list, keeping lists separate, so you don't need link fields to get from one header to the next in search of a match. There are so few names with ten or more characters that you could just about put all of those in the same list but then you'd have to check the length as you search, unlike the other lists. Link fields would tell where the next header of that name length is, since the lists would be intertwined. The first method that comes to mind would be similar to having various vocabularies, with addresses in a variable array pointing to the last header in each so the search through words of the particular name length desired can be started there. Now I don't remember which of these two things above that refers to. Now to put them together: Without the code itself having to be put with the headers, what sorts of arrangements have been used in other systems to optimize search speed? Samuel, in one of our previous E-mails which I lost due to a virus (not your fault), I used the term "dictionary hashing" incorrectly, and you set me straight on it. If I could put the headers in bank 1, there would be a lot more of bank 0 left for the application. The 65816's more efficient assembly language means it's more common with the '816 than it is with the '02 for a word's header to take more space than the code itself. With all the options loaded (math extensions, assembler, etc.) and an application with lots of headers, the headers could take 10-15K, which is a big chunk to take out of bank 0. I've wanted my 65816 ITC Forth to run in bank 0 only, requiring only two bytes per address for normal Forth running, and leaving other banks for data, huge look-up tables, perhaps long assembly-language routines or other non-Forth applications, etc. How much? I don't know-hopefully 5-10 times as fast.ī. I'm looking for ideas on two related things I'm considering for possible future implementation in my 65816 Forth:Ī.
0 kommentar(er)
