Hi Seb, I think we will learn the revival of the preprocessing discussion deserves it's own thread...
First of all, there seems to be a need for preprocessing. Stef used preprocessing in his IDE and I used the M4 preprocessor in some projects. But some argued that preprocessors are evil and they might be right. At least I learned that the generic M4 preprocessor is not that easy to handle. Stefs preprocessor was, but since it was part of his IDE and thus required the use of that IDE. In addition, since both preprocessors where not integrated, you get two 'source' files. The first one is input to the preprocessor, the second one is the output of the preprocessor and input for the compiler. If the compiler generates errors or warnings, you need the intermediate file to see what's wrong and probably need to go back to the first source and search for the corresponding code (since line numbers are changed). So in my experience, preprocessing should be integrated in the compiler. It can be an external program, but there need to be one source and corresponding line numbering. And if the preprocessor is an external program, it must be an executable like the compiler and supplied with the compiler, so it is transparently available for all users. Otherwise, you will introduce different dialects of JAL... @Rob, I vote for inline, just like port and pin. Joep 2010/3/2 Sebastien Lelong <[email protected]>: > Hi guys, > I've implemented an "api" command in jallib.py. This commands parses jal > content, and extracts include statements, procedures, etc... It's used in > Jaluinoide for autocompletion for instance. > So, what's the relation with this "inline or not" ? With parsing , it might > be possible, with some more work, to analyze code, extract a tree of > callstack (or directly from the ASM), add/remove pragma inline, compile, > compare stack size and memory usage, etc... A kind of > preprocessing... Preprocessing needs parsing, that's why I was thinking > about that, while playing with jal code... A more advanced parser, like the > one William's done with Antlr, may be more powerful for this task. > Well, that's just some thoughts. This "inline"/not inline is yet another > "preprocessing jal code" topic IMO. We should be able to switch inline or > not, depending on our needs. > > Cheers, > Seb > > 2010/3/2 Rob Hamerling <[email protected]> >> >> >> Rob Hamerling wrote: >> >>> I'll make the nibble routines inline and make a comparison of the results >>> for a few programs (before committing the device files!). Programs using the >>> 4-bit LCD library will probably give sufficient info. >> >> I've compiled several sample programs for which 'inline' for nibbles >> appears to save 1 stack level and about 15 words of code memory. >> However with a 'real' - though not very large - program the stack level >> remained the same and more code memory was used. >> I did not count instruction cycles, but I expect that will probably lower >> with 'inline' for all programs. >> >> So consistency with ports and pins may be the decisive argument in favour >> of 'inline'. >> >> Comments? >> >> >> Regards, Rob >> >> >> -- >> Rob Hamerling, Vianen, NL (http://www.robh.nl/) >> >> -- >> 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. >> > > > > -- > Sébastien Lelong > http://www.sirloon.net > http://sirbot.org > > -- > 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. > -- 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.
