> On Thu, Sep 20, 2001 at 11:11:42AM -0400, Dan Sugalski wrote:
> > Actually the ops=>C conversion was conceived to do exactly what's being
> > done now--to abstract out the body of the opcodes so that they could be
> > turned into a switch, or turned into generated machine code, or TIL'd. If
> > you're finding that this isn't working well it's a sign we need to change
> > things some so they will. (Better now than in six months...)
>
> The problem is that the conversion currently done by process_opcodes.pl
> translates the op definitions into functions, and leaves the remainder
> of the file untouched. This is useful, because it allows the opcode
> file to include headers, declare file-scope variables, and the like.
> Unfortunately, when translating the ops into a switch statement in a
> header file, there is no place to put this non-opcode code.
I didn't have a problem with this. It just took some clever perl5
programming (namely outputting to separate streams and combining them at
the very end). It's not fool-proof, but works for the important stuff
(like includes / globals).
>
> There are a few approaches we can take. The simplest, I think, is to
> ignore the problem when generating inline ops; given that these ops
> are going to be compiled at Perl build time (they can never be
> dynamically loaded for obvious reasons), we can manually put any
> required #includes in interpreter.c. Files containing dynamically-
> loaded ops can be generated in the same way that process_opcodes.pl
> does now, preserving the file-scope code.
>
> Another approach would be to include a means of defining information
> that must be included by the file implementing the ops. For example:
>
> HEADER {
> #include <math.h>
> }
>
> This would then be placed into interp_guts.h. (Possibly surrounded
> by a conditional guard (#ifdef PARROT_OP_IMPLEMENTATION), so no file
> other than interpreter.h will pick up that code.)
>
> - Damien
>
- /= |_ |_| /= /= \./
