Front page | perl.perl6.internals |
Postings from February 2006
Joshua Isom wrote: > I guess this is one place where being CISC really is better than being > RISC. It really depends on the hardare you are running. E.g. add I0, I1, 20 translates either to something like: lea %ecx, 20(%edx) # not yet but in case .. or ori r11, r31, 20 # r31 is 0 add r3, r4, r11 # a 2nd oris is needed for constants > 0xffff If x86 were not the leading instruction set, I'd toss the opcode variants with constants almost all. > ... But how much improvement with outputting to a pbc first? If you are gonna running the code multiple times, you save a few cycles compilation time. JIT code is still created at runtime. > ... But a > couple notes, there's no --help-optimize like --help-debug, and as far > as I know, perldoc docs/runnning.pod - but these optimizations aren't settled nor finished. You can ignore them for now. > there's no way to disable optimizations completely, e.g. this > pir > > .sub main :main > $N0 = pow 2.0, 5.0 > .end > > Is always converted to this. > > main: > set N0, 32 > end This isn't an optimization. The 'pow' opcode is just run at compiletime. > Which can lead to misleading test results for when pow's actually broken. If 'pow' is broken then it's borken. The only case where that would matter is, when you are compiling a PBC on a machine with a broken 'pow' and ship that PBC. leoThread Previous | Thread Next