The VM Limits upgrade makes it a lot easier to add new math opcodes to the BCH VM is a safe way 
. From a Reddit AMA with Jason:
- Can you expand on how the opcode accounting & bigint changes impacts the ideas for future math opcodes like EXP, LOG, ROOT, POW? Would they be significantly easier to add or the same as before? Does BigInt make these opcodes more useful?
Far easier, and yes. Native BigInt makes them even more useful: with only emulated precision, we wouldn’t be giving VM implementations the opportunity to use common internal optimizations on specific operations (e.g. Karatsuba multiplication). With native BigInt, we can get the maximum theoretical performance out of programs written in the VM bytecode.
The Limits CHIP takes the absolute, most-conservative possible approach to “computation cost” right now, but there are significant optimizations that future upgrades could essentially require of all VM implementations at some point in the future. Searching “optimization” in rationale: Retention of Control Stack Limit, Inclusion of Numeric Encoding in Operation Costs, Selection of Signature Verification Operation Cost
Or maybe now that emulation becomes more plausible it might become harder to add new opcodes natively?
Nope, still far easier. New opcodes can now come in with their own cost calculation matching their real-world performance cost (based on time complexity). Upgrade proposal adding new primitive math operations could now be extremely small and self-contained, and density-based limits ensure that they don’t knock over or interact with the worst-case performance of any other part of the VM.
In fact, these proposals will now have an easier time proving their necessity: if for example, lots of contracts are wasting bytes/opCost on
...OP_DUP OP_MUL..., we’ll have empirical on-chain evidence of both the bandwidth/storage and of the potential total reduction in the CPU utilization of all full nodes if those contracts switch toOP_EXP(e.g. Exponentiation by squaring).