Re: Interpreter info needed

Tony Jones <tony@odin.sunquest.com> writes:


>For op-code processing, I was planning to use some form of dispatch table
>instead of a big switch statement, but I'd rather avoid function
>call/return overhead [i.e array of function pointers], by jumping to sub
>code to process each op-code and threading back to the main dispatch code
>afterwards.


>I'll be writing in C, on DOS/UNIX and MacOS. Using GCC where possible but
>ThinkC on the Mac.


>Of course, I'd like to keep the amount of assembly code to an absolute
>minimum.


I think you've got a contradiction there. You don't want to use built-in
language facilities (switch or call/return) but you want to use a
compiler. And you'd probably like the code to be optimized, too. For a
compiler to properly assign registers and manage other data flows, it
needs to "understand" control flow, but you seem to be proposing to
somehow generate control flow that the compiler doesn't know about.


Frankly, either you should write it all in assembler (with calls to
compiler generated code for the complex stuff, I suppose), or you should
resign yourself to using a compiler for everything and using the
compiler-supplied control flow primatives.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.