On Wed, 22 May 2024, at 19:04, Kautuk Consul wrote: > Hi Segher/Alexey/Thomas, > > > > > If you want to improve engine.in, get rid of it completely? Make the > > > > whol thing cross-compile perhaps. Everything from source code. The > > > > engine.in thing is essentially an already compiled thing (but not > > > > relocated yet, not fixed to some address), which is still in mostly > > > > obvious 1-1 correspondence to it source code, which can be easily > > > > "uncompiled" as well. Like: > > > > > > :-). Getting rid of it completely and making the whole thing > > > cross-compile would require more time that I'm not so sure that I or > > > even my manager would be able to spare in our project. > > > > > > > > > > > col(+COMP STATE @ 1 STATE +! 0BRANCH(1) EXIT HERE THERE ! COMP-BUFFER DOTO HERE COMPILE DOCOL) > > > > col(-COMP -1 STATE +! STATE @ 0BRANCH(1) EXIT COMPILE EXIT THERE @ DOTO HERE COMP-BUFFER EXECUTE) > > > > > > > > : +comp ( -- ) > > > > state @ 1 state +! IF exit THEN > > > > here there ! > > > > comp-buffer to here > > > > compile docol ; > > > > : -comp ( -- ) > > > > -1 state +! > > > > state @ IF exit THEN > > > > compile exit > > > > there @ to here > > > > comp-buffer execute ; > > > > > > > > "['] semicolon compile," is not something a user would ever write. A > > > > user would write "compile exit". It is standard Forth, it works > > > > anywhere. It is much more idiomatic.. > > > > > > Okay, I can accept the fact that maybe we should use EXIT instead of > > > SEMICOLON. But at least can we remove the invocation of the "COMPILE" > > > keyword in +COMP and -COMP ? The rest of the compiler in slof/engine.in > > > uses the standard "DOTICK <word> COMPILE," format so why cannot we use > > > this for -COMP as well as +COMP ? > > > > Do you all agree with the above reasoning as well as the fact that I think > we would all here (in the KVM team) appreciate even this small > improvement in performance ? > Can I send a v3 patch with the "DOTICK EXIT COMPILE," "DOTICK DOCOL COMPILE," changes ? > > Or should I just abandon this patch ? My point is that when we aren't > doing anything unorthodox in/with the slof/engine.in code then why not > go in for a useful optimization in SLOF as this is part of the KVM Over > PowerVM product ? Is this optimization even measurable? :) There is one thing which SLOF could do much faster (seconds or tens of seconds) - it is PCI scan where SLOF walks through all busses and slots even though it is all in the device tree already. But this "dotick" business does not scream for optimization imho. Thanks,
