tag:blogger.com,1999:blog-35609023.post2267781055141390288..comments2022-04-08T20:26:13.393+02:00Comments on nominolo's Blog: Implementing Fast InterpretersThomas Schillinghttp://www.blogger.com/profile/04274984206279511399noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-35609023.post-89780074239652691392012-07-24T12:51:14.293+02:002012-07-24T12:51:14.293+02:00I'm not sure it makes sense to expend so much ...I'm not sure it makes sense to expend so much effort optimizing an interpreter. I'd expect a splat compiler to be simpler and faster...Jon Harrophttps://www.blogger.com/profile/11059316496121100950noreply@blogger.comtag:blogger.com,1999:blog-35609023.post-50147835347556307242012-07-23T19:33:45.738+02:002012-07-23T19:33:45.738+02:00Thomas Schilling: Thanks for the answer!Thomas Schilling: Thanks for the answer!Alessandrohttps://www.blogger.com/profile/09982648951796142381noreply@blogger.comtag:blogger.com,1999:blog-35609023.post-85719312282044548082012-07-23T14:47:12.744+02:002012-07-23T14:47:12.744+02:00Nicely explained. These are some of the very techn...Nicely explained. These are some of the very techniques, albeit in Java--that are used in the highly customizable GPVM that I designed for my Computer Organization and Assembly Lanuguage students. Well Done.Jim Perryhttps://www.blogger.com/profile/12863050182181171076noreply@blogger.comtag:blogger.com,1999:blog-35609023.post-9947013114447952392012-07-23T12:10:41.959+02:002012-07-23T12:10:41.959+02:00Alessandro: The design goal is that it shouldn'...Alessandro: The design goal is that it shouldn't. The main idea is to remove unnecessary repetition if the code is the same or very similar on different architectures. If it isn't, then you still use architecture-specific code instead of compromising performance.<br /><br />TerryD: Yes, there are many ways to remove interpreter overhead, but they all start going into JIT territory. E.g., for the MemCpy technique, you need to manage extra memory, possibly flush instruction caches, make sure to dispatch execution to the generated code, possibly invalidate them if the execution mode changes, etc. <a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.1271" rel="nofollow">Context-threading</a> uses a similar idea to improve branch prediction.<br /><br />If you're fine with an interpreter and just want a little bit more performance, then going this route is fine and the additional complexity is probably worth it. If you want a better-optimising JIT on top, then it's probably fine to use a simple interpreter and not have an additional proto-JIT.<br /><br />aweasd: AFAIK, the LLVM JIT is relatively slow. As above, you'll also have to manage the memory for the compiled code. If you care more about ease of implementation than performance, I'd go with a direct-threaded interpreter in C. I'm not sure if LLVM is ready as a full JIT these days. I know the Unladen Swallow (Python JIT) project had it's issues and concluded that LLVM wasn't ready, yet.<br /><br />hsm: I assume you mean the RISC-like MMIX, since the original MIX is an abomination by today's standard. That said, using MMIX would probably hide too many important details. For example, MMIX has 256 registers, but for our purposes we want to optimise register use for each architecture and not rely on having 256 of them. Since ultimately performance is the main goal, we shouldn't try to hide all the implementation details, but just automate the boring parts.Thomas Schillinghttps://www.blogger.com/profile/04274984206279511399noreply@blogger.comtag:blogger.com,1999:blog-35609023.post-5162711199482096472012-07-23T04:49:44.902+02:002012-07-23T04:49:44.902+02:00This wasn't new when Charles Moore invented Fo...This wasn't new when Charles Moore invented Forth. Good idea then, good idea now. I wonder if at some point Knuth's MIX, had multiple back ends, would that help with the portability problem?Anonymoushttps://www.blogger.com/profile/03122007227690269066noreply@blogger.comtag:blogger.com,1999:blog-35609023.post-5561272949200498692012-07-23T03:39:59.208+02:002012-07-23T03:39:59.208+02:00What about LLVM bitcode? Seems like a reasonable c...What about LLVM bitcode? Seems like a reasonable compromise between portability and assembly-level flexibility.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-35609023.post-39476398173632403892012-07-23T03:37:04.804+02:002012-07-23T03:37:04.804+02:00If you have ASM code for the different operations ...If you have ASM code for the different operations and you want to do a little more work, you can use your table as a template and MemCpy the code together. Then, patch the operations that have constants. Presto! From interpreter to compiler! You can spend a year doing little optimizations.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-35609023.post-52800882650265129462012-07-23T02:22:50.405+02:002012-07-23T02:22:50.405+02:00Loved your post ; ).
Assembly, Interpreters, spee...Loved your post ; ).<br /><br />Assembly, Interpreters, speed... Very cool!<br /><br />Does the "portable assembly" solution through DSL incurs a significant speed penalty?Alessandrohttps://www.blogger.com/profile/09982648951796142381noreply@blogger.com