> At the moment, the library is essentially 'one large array'.jal. > Which is a fine thing, but perhaps not as generally useful as it might > be, with some refactoring. > > If you are going to take advantage of this 'automatic removal of > unused variables' feature of the compiler, then it seems to me you can > get rid of a huge amount of the code -- For example, for the large > 'byte' arrays, you can just use these same 8 arrays for all cases of > large 'byte' arrays: > > var byte large_array_byte_1h[256] > var byte large_array_byte_2h[256] > var byte large_array_byte_3h[256] > var byte large_array_byte_4h[256] > var byte large_array_byte_5h[256] > var byte large_array_byte_6h[256] > var byte large_array_byte_7h[256] > var byte large_array_byte_8h[256] > > And then, for example, in the 'get' and 'put' routines, if your > LARGE_ARRAY_SIZE is smaller than 1792, then large_array_byte_8h will > never be referenced, and so the compiler will not allocate any space > for it. Likewise, if LARGE_ARRAY_SIZE is smaller than 1536, then > large_array_byte_7h won't be referenced.
I think you may be right, at the time I had a reson for creating all these var's, but I try to get rid of most of them if the compiler allows. > Now, turning to some other points we've been discussing: You mention > that a person could make multiple copies of the library and thereby > have multiple large arrays-- not really, since almost every line of > the nearly 800 line library would need to be edited to prevent compile > errors - duplicate variable names, etc. That is why I was > brainstorming for ways to use some sort of template and generator > tool. It's simple... just do a string replace of large_array_ with large_array_2_ to get rid of vars with the same name, then copy the lib to another .jal file. In this case, I will change all large_array_ to large_array_1_ for the main lib. I can easily make an exe to do this, I don't have so much experience with scripting. Even the user can do it via notepad's "find/ replace all" feature. > Regarding breaking up the library into 3 smaller libraries, for byte, > word, and dword: How about this: make it a two-level library-- the > name 'large_array.jal' could simply be a wrapper that includes the 3 > lower-level libraries. yes, this could be done, but... then the main lib will have only 3 lines: include large_array_1_byte include large_array_1_word include large_array_1_dword --maybe more if large_array_2_____ As I said before... byte word and dword must all be named large_array_1___ so the user can choose it's var length (byte word dword). Therefore the vars in each smaller lib will be the same starting with large_array_1_. it will not produce an option to use more combinations of var lengths. maybe it's better if I just put a long "------------------------------------------" between byte word dword? We can either have more small files, or one large file. I think the others would prefer that we don't clutter svn & releases with too many files. If I split the lib up into 3 for byte word & dword, and if I make 4 large array's, that is a total of 12 lib files + 1 main. why hav 13 files when you can have just 4, or just one with a lib generator. If you split the lib, it is harder to do a variable replace via notepad. Matt. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jallib?hl=en -~----------~----~----~----~------~----~------~--~---
