- Special link-list algorithm help - 10 Updates
- Special link-list algorithm help - 1 Update
- High-tech, higher calling was: Onwards and upwards - 1 Update
- Some C++14 code - 3 Updates
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 07 08:15PM -0400 On 7/7/2018 6:09 PM, Bart wrote: > and are of no further interest. > Certainly you wouldn't retain tokens for parentheses which only exist in > source code. I do until the operators are parsed in their orders of precedence. They serve as an expression to resolve down to the form. So in your example "a=(b+c)*d" here it would be: a = (b + c) * d; // Inside parenthesis first a = t0 * d; // Multiply a = t1; // Store t2; // Final result, discarded if not used > b > c > d There is more than one way to accomplish a goal. I used to use a tree-like way, but I have changed that plan for this one I have now. I have additional reasons for doing this as well, which relate to the ability to step into an expression (when not in assembly mode), and the ability to set a breakpoint on a portion of the expression. By doing them in stages like this, and storing temporary values, there are new features in debugging which are exposed. And, those temporary values can be removed for the final release (optimized) build. > straight from linear tokens to linear code might be done in a simpler > translator, but you still wouldn't bother reorganising token sequences. (That > only happens when dealing with C's macro expansion.) I accomplish essentially the same thing without the tree, and without levels. I handle levels using an order of precedence for the expression, but it's not done in the same way, but it accomplishes the same goal. > instead of having actual modules? I notice this post is in the C++ group and > that language is rapidly heading that way. I think you need to be ahead of > the game. I am. There is a huge source code base written in C, and I have no intention whatsoever to abandon that legacy development and debugging effort. > Forget c90 and c99 support in your own language. That is, being able to write > it amongst the same source code as the new language. Why would anyone want to > when they have a sparkling new language to use? CAlive will allow both. Code can be compiled in a ca {..} block for new CAlive code added to an existing C source file compiled with -c90 or -c99. It allows them to step forward, while maintaining the portions from the past which work and have no need to be re-written or altered. > Apart from which I can see endless problems, the prime one being stifling > development of the new language. Don't use it. CAlive sounds like it's not for you. -- Rick C. Hodgin |
| Bart <bc@freeuk.com>: Jul 07 11:09PM +0100 On 07/07/2018 12:03, Rick C. Hodgin wrote: > a = saturate_f64_to_f32(b + c); > So you wind up injecting operations in your tokens: > [a][=][saturate_f64_to_f32][(][b][+][c][)] I'm not sure if this is how it's normally done. That is, by doing everything at the level of a linear series of tokens. Usually a parser reads a stream of tokens, and outputs a tree representing the static structure of the program. At this point tokens can be discarded and are of no further interest. Certainly you wouldn't retain tokens for parentheses which only exist in source code. Source code of 'a=(b+c)*d' could result in a structure which might be displayed like this: Assign a Mul Add b c d The entries for a,b,c,d nodes contain references back to a symbol table which is the other major data structure. But notice: no parentheses. And the structure specifies how it is to be evaluated rather than having to deduce it from a token sequence. Eventually this is flattened again to some sort of generated code. Going straight from linear tokens to linear code might be done in a simpler translator, but you still wouldn't bother reorganising token sequences. (That only happens when dealing with C's macro expansion.) > thing for the compilation is loaded, including those things which branch > into unused #ifdef.. 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment