On 2/25/21 7:18 AM, Alessandro Di Federico wrote: > +Now let's have a quick look at the generated code, line by line. > + > +:: > + > + tcg_gen_movi_i32(RdV, 0); > + > +This code starts by initializing ``RdV``, since reading from that register > +without initialization will cause a segmentation fault by QEMU. This is > emitted > +because a declaration of the ``RdV`` register was parsed, but no reading of > the > +``RdV`` register was found.
This is odd, as is the description of why. Yes, if RdV is read without initialization, TCG middle-end will abort (at least with --enable-debug-tcg enabling the assertions). But you've just said that "no reading" was found. So why did you perform this dummy initialization, which will be eliminated later? > +Another example that highlight the limitation of the flex/bison parser can be > +found even in the add operation we already saw: > + > +:: > + > + TCGv_i32 tmp_0 = tcg_temp_new_i32(); > + tcg_gen_add_i32(tmp_0, RsV, RtV); > + tcg_gen_mov_i32(RdV, tmp_0); > + > +The fact that we cannot directly use ``RdV`` as the destination of the sum > is a > +consequence of the syntax-driven nature of the parser. In fact when we parse > the > +assignment, the ``rvalue`` token, representing the sum has already been > reduced, > +and thus its code emitted and unchangeable. We rely on the fact that QEMU > will > +optimize our code reducing the useless move operations and the relative > +temporaries. So, I take it from this that you're emitting tcg directly from within the parser, and not generating any kind of abstract syntax tree? A little disappointing, but not critical. Even what you have is an improvement. > +A more radical improvement will use the parser, not to generate directly the > +tinycode generator code, but to generate an intermediate representation like > the > +LLVM IR, which in turn could be compiled using the clang TCG backend. I sincerely doubt this is worth it. r~
