Le ven. 18 janv. 2019 à 14:42, Marcus Denker <[email protected]> a écrit :
> > > > On 18 Jan 2019, at 14:26, ducasse <[email protected]> wrote: > > > > I simply love the dynamic rewriting this is just too cool. We should > systematically use it. > > I will continue to use it in any deprecation. > > > > On my TODO is to make it stand-alone and provide is as a “compatibility > transform”, too. > > So we can add it to methods that we want to keep for compatibility, but > they will nevertheless transform the code automatically. > (this then might be disabled in production to not transform) > > > Now I have a simple question (You can explain it to me over lunch one of > these days). > > > > I do not get why RBAST would not be a good representation for the > compiler? > > I would like to know what is the difference. > > > I think it is a good one. I have not yet seen a reason why not. But > remember, Roel left Squeak because his visitor pattern for the compiler was > rejected as a dumb idea… so there are definitely different views on core > questions. > > E.g. the RB AST is annotated and the whole things for sure uses a bit more > memory than the compiler designed for a machine from 1978. > > > You mean that before going from BC to AST was difficult? > > You need to do the mapping somehow, the compiler needs to remember the BC > offset in the code generation phase and the AST (somehow) needs to store > that information (either in every node or some table). > > > How opal performs it? It does not use the source of the method to > recreate the AST but he can do it from the BC? > > > > It uses the IR (which I still am not 100% sure about, it came from the old > “ClosureCompiler” Design and it turned out to be quite useful, for example > for the mapping: every IR node retains the offset of the BC it creates, > then the IR Nodes > retain the AST node that created them. > > -> so we just do a query: “IRMethod, give me the IRInstruction that > created BC offset X. then “IR, which AST node did create you? then the AST > Node: what is your highlight interval in the source? > > The devil is in the detail as one IR can produce multiple byte code > offsets (and byte codes) and one byte code might be created by two IR > nodes, but it does seem to work with some tricks. > Which I want to remove by improving the mapping and even the IR more… > there is even the question: do we need the IR? could we not do it simpler? > > The IR was quite nice back when we tried to do things with byte code > manipulation (Bytesurgeon), now it feels a bit of an overkill. But it > simplifies e.g. the bc mapping. > > Marcus > > > agree! IR is super when we want to manipuate the byte codes (decompiling, instrumenting, etc...). But if it's just for generating the CompiledMethod byte codes (compiling), it's a bit too much and is one contributor of compilation slowdown. Maybe we could have another polymorphic kind of IRBuilder that would be a DirectByteCodeGenerator
